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

• 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: 开头，以两个换行符 \n\n 结束。
• 示例数据流：

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: {...}\n\n ，符合 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 格式的事件进行通信 1 3 5 。
• 持久连接：WebSocket 协议使得 API 能够保持一个持续的双向连接，允许即时的数据流动，这对于实时对话和交互至关重要。
• 多模态支持：该 API 不仅支持文本输入，还可以处理音频数据，提供更加丰富和自然的用户体验。