为何最近谈论 SSE 和 WebSocket 的人越来越多了？

目录：

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

• What's Next？

SSE（Server-Sent Events，服务器推送事件）是一种基于 HTTP 的网络通信协议，允许服务器向客户端单向推送实时数据。户端和服务端之间需要频繁地传输生成的内容。支持服务器可以一边生成结果，一边分块发送给客户端，这样用户就能逐步看到生成的内容，而不是等待服务端处理完所有内容才能看到。主要特点：

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

WebSocket 是一种网络通信协议，允许在客户端和服务器之间建立全双工、持久的连接，实现实时、双向的数据传输。不同于 SSE，WebSocket 连接一旦建立，双方可以随时发送数据，实效性更强，即无须等待服务端返回内容，客户端就能发起请求，适用于多人在线游戏操作实时同步、社交软件的聊天室、在线文档多人同时编辑等。主要特点是：

• 全双工通信：客户端和服务器可以同时发送和接收数据。
• 持久连接：连接建立后保持打开状态，直到主动关闭。

• 低延迟：数据可以即时传输，适合实时应用。

大模型应用出现前，互联网在线应用以 Web 类应用为主，基于浏览器运行，通常通过 HTTP/HTTPS 协议与服务器通信，例如电商应用、新零售/新金融/出行等交易类应用，教育、传媒、医疗等行业应用，以及公共网站、CRM 等企业内部应用，适用范围非常广泛。其中，HTTPS 是 HTTP 的安全版本，通过 SSL/TLS 协议，对传输数据进行加密保护，加解密过程中会带来一些性能损耗。

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

优势是：

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

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

这里我们以 TLS 1.3 为例，通过一张图了解下 HTTPS 在客户端和服务端之间的握手过程。（TLS 1.3 简化了以往的握手过程，性能损耗更小、响应更快。）

不同类型的大模型应用，对网络通信的需求不尽相同，但几乎都离不开以下需求：

• 实时对话：用户与模型进行连续交互，模型需要即时响应。例如通义千问，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

我们可以通过下方方式验证大模型 APP 使用的网络通信协议： 

• 调用 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]

• 客户端通过 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

• 服务器验证客户端的握手请求，并返回 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=

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

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

{"message": "Hello"}

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

[0x01, 0x02, 0x03]

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

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

例如 OpenAI 的 Realtime API（适用于对实时性要求更高的场景，客户端在不需要等待服务端发送完内容后就能发起请求），推荐基于 WebSocket 协议，以支持低延迟的多模态交互，包括文本和音频输入输出。具有以下特征：[2]

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

可见，SSE 和 WebSocket 均能较好的支持大模型应用的实时性需求，前者更加轻量化，后者因为是双向通信在实时性要求更高的场景更有优势。这里我们通过一张表来比对下各个协议的特点。

总结来看，HTTP/1.1 适合传统网页和简单 API 请求，但性能较低。HTTP/2 适合现代高性能网页，解决了 HTTP/1.1 的队头阻塞问题，SSE 适合服务器主动推送实时数据的场景，如一问一答的大模型应用，WebSocket 适合需要双向实时通信的场景如在线游戏、多人协作、实时性要求更高的大模型应用场景（随时可以打断生成过程进行追问的场景，例如大模型实时辩论平台）。

此外，WebRTC 也广泛应用于大模型应用场景，例如，当调用 Realtime API 时，OpenAI 官方推荐使用 WebSocket 或 WebRTC[3]。

虽然 SSE 和 WebSocket 的特点，天然适合处理游戏、社交、大模型应用等有处理实时通信的场景。但是用户体量扩大后，依旧会遇到一些工程化上的技术挑战。

以下罗列了具体的挑战和网关层的应对方案，方案部分仅供参考，工程上的问题没有唯一的答案，应结合业务和技术团队的实际情况，选择适合自己的方案。

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

应对方案：

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

• 协议切换机制：在 SSE 和 WebSocket 不可用时，回退到长轮询（Long Polling），不过这个依赖于网关本身是否支持这些长连接。
  

应对方案：选择支持流式处理的网关（如 Higress），将生成的内容分块传输，减少单次传输的数据量。同时，采用压缩算法（如 Gzip），减少数据传输量，控制带宽成本。阿里云云原生 API 网关即将上线软硬一体化的内容压缩方案，带宽传输成本可下降 20%+。

• 认证鉴权：对来自客户端的请求，进行合规性的校验。基于具体的业务需求，选择第三方的认证协议，从我们服务的客户经验上看，选择 OAuth2、JWT 的居多。
• 安全防护：通过 IP 限制，或者基于URL、请求头等特征，设计安全防护措施。
• 流量管控：基于 URL 参数、HTTP 请求头、客户端 IP 地址、消费者名称或 Cookie 中的 Key，进行 token 级别的限流。

Higress 和商业版云原生 API 网关提供了丰富的开箱即用的插件，降低了用户的开发、适配和维护成本。如下是产品的插件市场。

这些防护措施，不仅能提升面对恶意攻击系统的健壮性，在面对外部不规则流量时，还能提升系统的稳定性。

大模型应用除了带来了 SSE 和 WebSocket 的使用频率越来越高，也在助推 API First 的理念。以往，在线应用都是通过 Service 来对外暴露提供能力，但大模型应用将通过 API 对外提供服务能力，除了基模类厂商已经通过提供 API 来服务广大开发者群体，大模型应用类厂商也开始提供 API 服务。

随着国内大模型应用的成熟，相信这一趋势会越加明显，本文的姊妹篇将聊一聊《为何最近谈论 API 管理的人越来越多了？》，敬请期待。

相关链接：

[1] https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events

[2] https://platform.openai.com/docs/guides/realtime-websocket

[3] https://platform.openai.com/docs/guides/realtime

[4]《Perplexity 的新动作》