大模型推理主战场：什么才是通信协议标配？

• SSE 和 WebSocket 是什么？
• 大模型应用出现前的主流网络通信协议是什么？
• 为什么大模型应用没有沿用 Web 类应用的主流通信协议？
• 为什么 SSE 和 WebSocket 更适合支持大模型应用？
• 实时通信协议的技术挑战和应对方案

• What’s Next？

• 高效的单向通信：转为服务端到客户端的单向通信所设计，完美匹配大模型场景（客户端发送一次请求，服务端持续返回流式结果）。
• 低延迟：每次生成一个逻辑段落或标记（token）即可立即推送，避免传统 HTTP 请求-响应模式的长等待。
• 轻量协议：基于HTTP/HTTPS，无需额外协议握手（如 WebSocket 的双向协商），减少连接开销。

• 全双工通信：客户端和服务器可以同时发送和接收数据。

• 持久连接：连接建立后保持打开状态，直到主动关闭。
• 低延迟：数据可以即时传输，适合实时应用。

• 基于请求-响应模型。

• 无状态：每次请求都是独立的，服务器不会保存客户端的状态。
• 数据加密，防止数据被窃听或篡改；身份验证，确保客户端与正确的服务器通信；数据完整性，防止数据在传输过程中被修改。（HTTP 是明文传输）

• 简单易用：HTTP 协议设计简单，易于实现和使用。

• 广泛支持：几乎所有浏览器、服务器和开发框架都支持 HTTP。
• 灵活性：支持多种数据格式（如 JSON、XML、HTML）和内容类型。
• 无状态：简化了服务器的设计，适合分布式系统。

• 安全和合规性：通过加密技术保护数据传输，防止窃听和篡改；符合现代网络安全标准（如 GDPR、PCI DSS）。

• 实时对话：用户与模型进行连续交互，模型需要即时响应。例如通义千问，HIgress 官网的答疑机器人，都是需要依据客户问题，即时做出响应。

• 流式输出：大模型生成内容时，逐字或逐句返回结果，而不是一次性返回。但是钉钉、微信等应用，两个人相互对话时，采用的就不是流式输出了，文字等内容都是一次性返回的。
• 长时任务处理：大模型可能需要较长时间处理复杂任务，同时需要向客户端反馈进度，尤其是处理长文本、以及图片、视频等多模态内容；这是因为依赖大模型计算的响应，要比依赖人为写入的业务逻辑的响应，消耗的资源多的多，这也是为什么大模型的计算要依靠 GPU，而非 CPU，CPU 在并行计算和大规模矩阵计算上远不如 GPU。
• 多轮交互：用户与模型之间需要多次往返交互，保持上下文。这是大模型应用保障用户体验的必备能力。

• 仅支持单向通信，即请求-响应模型，必须是客户端发起时，服务端才能做出响应，无法进行双向通信，导致无法支持流式输出，无法处理长时任务。

• 客户端每次发出请求都需要重新建立连接，延迟增加，导致无法支持实时对话。
• HTTPS 是一种无状态的通信协议，每次请求都是独立的，服务端不会保存客户端的状态，即便客户端可以在每次请求时重复发送上下文信息，但会带来额外的网络开销，导致无法高效的支持多轮交互场景。

1. 客户端发起 SSE 连接

• 客户端通过 JavaScript 的 EventSource API 向服务器发起 HTTP 请求。

• 请求头中包含 Accept: text/event-stream，表明客户端支持 SSE 协议。
• 示例代码：

const eventSource = new EventSource('https://example.com/sse-endpoint');

2. 服务器返回 HTTP 响应

• 服务器响应头中必须包含以下字段：

• Content-Type: text/event-stream：表明响应内容为 SSE 数据流。

• Cache-Control: no-cache：禁用缓存，确保数据实时更新。
• Connection: keep-alive：保持长连接。

• 示例响应头：

HTTP/1.1 200 OKContent-Type: text/event-streamCache-Control: no-cacheConnection: keep-alive

• 服务器通过 HTTP 长连接持续推送数据，每条消息以 data: 开头，以两个换行符 nn 结束。
• 示例数据流：

data: {"message": "Hello"}
data: {"message": "World"}

4. 客户端处理数据

• 客户端通过 EventSource 的 onmessage 事件监听服务器推送的数据。
• 示例代码：

eventSource.onmessage = (event) => {    console.log('Received data:', event.data);};

5. 连接关闭或错误处理

• 如果连接中断（如网络问题），客户端会自动尝试重新连接。

• 服务器可以通过发送 retry: 字段指定重连时间（毫秒）。

• 示例重连设置：

retry: 5000

• 调用 API 并检查响应头：
  使用 stream=True 参数请求流式响应，通过开发者工具或 curl 查看返回的 Content-Type，若为 text/event-stream，则明确为 SSE。
  示例命令： 

curl -X POST "https://api.deepseek.com/v1/chat/completions"   -H "Authorization: Bearer YOUR_KEY"   -H "Content-Type: application/json"   -d '{"model":"deepseek-chat", "messages":[{"role":"user","content":"Hello"}], "stream":true}'   -v  # 查看详细响应头

< HTTP/1.1 200 OK< Content-Type: text/event-stream< Transfer-Encoding: chunked

• 数据格式验证：
  流式响应的数据体格式为 data: {...}nn，符合 SSE 规范[1]。
  示例响应片段： 

data: {"id":"123","choices":[{"delta":{"content":"Hi"}}]}data: [DONE]

1. 客户端发起 WebSocket 握手请求

• 客户端通过 HTTP 请求发起 WebSocket 握手，请求头中包含以下字段：

• Upgrade: websocket：表明客户端希望升级到 WebSocket 协议。
• Connection: Upgrade：表明客户端希望升级连接。
• Sec-WebSocket-Key：随机生成的 Base64 编码字符串，用于握手验证。

• 示例请求头：

GET /ws-endpoint HTTP/1.1Host: example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==Sec-WebSocket-Version: 13

2. 服务器返回 WebSocket 握手响应

• 服务器验证客户端的握手请求，并返回 HTTP 101 状态码（Switching Protocols），表示协议升级成功。
• 响应头中包含以下字段：

• Upgrade: websocket：确认协议升级。
• Connection: Upgrade：确认连接升级。
• Sec-WebSocket-Accept：基于客户端的 Sec-WebSocket-Key 计算的值，用于验证握手。

• 示例响应头：

HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

3. WebSocket 连接建立

• 握手成功后，HTTP 连接升级为 WebSocket 连接，客户端和服务器可以通过 WebSocket 协议进行双向通信。
• 连接基于 TCP，支持全双工通信。

4. 数据传输

• 客户端和服务器通过 WebSocket 协议发送和接收数据帧（Frame）。数据帧可以是文本或二进制格式。
• 文本帧：用于传输 JSON、字符串等文本数据。

{"message": "Hello"}

• 二进制帧：用于传输图片、音频、视频等二进制数据。

[0x01, 0x02, 0x03]

5. 连接关闭

• 客户端或服务器可以主动发送关闭帧（Close Frame）来终止连接。
• 关闭帧包含关闭状态码和原因（可选）。
• 示例关闭帧：

Close Frame:  - Code: 1000 (Normal Closure)  - Reason: "Connection closed by client"

• 基于事件的通信：Realtime API 通过 WebSocket 进行有状态的事件驱动交互，客户端和服务器之间通过发送和接收 JSON 格式的事件进行通信135。
• 持久连接：WebSocket 协议使得 API 能够保持一个持续的双向连接，允许即时的数据流动，这对于实时对话和交互至关重要。
• 多模态支持：该 API 不仅支持文本输入，还可以处理音频数据，提供更加丰富和自然的用户体验。

• 越是高速发展的应用，越是新兴应用，软件变更频率越高，网关升级是软件变更的重要组成部分。但是，网关的升级通常涉及服务重启、配置变更或网络切换等作用，这会直接影响 SSE 和 WebSocket 连接的稳定性。
• 服务扩容过程中（增加实例），现有的 SSE 和 WebSocket 可能无法连接到新实例，服务缩容过程中（减少实例），现有的 SSE 和 WebSocket 可能会因服务的下线而被强制关闭，这些对实时性要求比较高的应用，例如游戏、大模型实时聊天，都会带来用户体验的下降。

• 无损上下线能力：该能力在微服务变更时，应用比较广泛，可以有效降低版本发布和扩缩容的稳定性风险。常见于云产品的商业能力。例如，阿里云的云原生 API 网关提供了面向 HTTPS/WebSocket 的微服务治理能力。
• 客户端重连机制：在客户端设计自动重连机制，减少中断影响，和无损上下线一样，使用心跳包检测连接状态，一旦中断自动重连，此外，还可以在服务器端记录已发送的数据，实现断点续传。
• 协议切换机制：在 SSE 和 WebSocket 不可用时，回退到长轮询（Long Polling），不过这个依赖于网关本身是否支持这些长连接。
  

• 认证鉴权：对来自客户端的请求，进行合规性的校验。基于具体的业务需求，选择第三方的认证协议，从我们服务的客户经验上看，选择 OAuth2、JWT 的居多。

• 安全防护：通过 IP 限制，或者基于URL、请求头等特征，设计安全防护措施。
• 流量管控：基于 URL 参数、HTTP 请求头、客户端 IP 地址、消费者名称或 Cookie 中的 Key，进行 token 级别的限流。