详解AI大模型实时通信为什么选SSE，而不是WebSocket和WebRTC

本文由ArchSynapse AI分享，即时通讯网有修订和重新排版。

1、引言

在为大型语言模型（LLM）应用构建实时前后端通信系统时，选择正确的底层技术至关重要。

本章节将深入剖析三种主流技术的核心原理：

• 1）Server-Sent Events (SSE)：它作为服务器主导的单向数据流的黄金标准；
• 2）WebSocket：作为通用的全双工通信解决方案；
• 3）WebRTC：专注于媒体流和点对点数据交换。
  

理解它们的技术设计哲学和技术细节，是做出明智技术选型的关键基础。

本文将为读者剖析 SSE、WebSocket、WebRTC 的技术原理，并对比三者在性能、安全与架构方面的优劣势，详解了AI大模型（LLM）在实时通信协议方面的综合技术考量以及最终选择。

2、AI大模型实时通信技术专题

技术专题系列文章目录如下，本文是第 5 篇：

• 《全民AI时代，大模型客户端和服务端的实时通信到底用什么协议？》
• 《大模型时代多模型AI网关的架构设计与实现》
• 《通俗易懂：AI大模型基于SSE的实时流式响应技术原理和实践示例》
• 《ChatGPT如何实现聊天一样的实时交互？快速读懂SSE实时“推”技术 》
• 《AI大模型爆火的SSE技术到底是什么？万字长文，一篇读懂SSE！ 》
• 《详解AI大模型实时通信为什么选SSE，而不是WebSocket和WebRTC》（☜ 本文）
  

3、SSE是什么？

Server-Sent Events (SSE) 是一种基于标准 HTTP 协议的技术，专为服务器向客户端推送单向事件流而设计。



其工作流程始于客户端创建一个 EventSource 对象，该对象会自动发起一个持久的 HTTP GET 请求。服务器接收到请求后，不立即关闭连接，而是保持响应打开，并以特定格式发送数据]。

这个格式要求服务器设置 Content-Type 头部为 text/event-stream。

每个事件由一系列字段组成，包括：

• 1）必需的 data: 字段用于承载消息内容；
• 2）可选的 event: 字段用于定义事件类型；
• 3）id: 字段用于标识事件以便在连接中断后恢复；
• 4）以及 retry: 字段用于指定重新连接前的等待时间。
  

消息之间必须以两个换行符 \n\n 分隔。

这种机制使得服务器能够在一个长连接上持续不断地推送增量数据，非常适合 LLM 流式传输等场景。SSE 的一大优势在于其天然地融入了现有的 HTTP 生态，能够无缝通过反向代理、负载均衡器和防火墙，无需特殊配置。

4、WebSocket是什么？

WebSocket 则提供了一种更为强大和灵活的全双工通信协议。它通过一次性的 HTTP 握手来“升级”一个标准的 TCP 连接。



握手过程涉及客户端发送一个包含 Upgrade: websocket 和 Connection: Upgrade 等特定头部的 HTTP 请求。如果服务器支持 WebSocket，它会返回一个状态码为 101 (Switching Protocols) 的响应，从而完成协议切换。

一旦连接建立，客户端和服务器就可以随时独立地向对方发送消息，而无需像 HTTP 那样每次都发起新的请求。

WebSocket 消息被封装在轻量级的帧中进行传输，支持文本和二进制数据，极大地降低了网络开销。

这种持久且双向的特性使其成为聊天应用、在线游戏和实时协作工具的理想选择。然而，其复杂性也远超 SSE，因为它是一个独立的协议栈，需要专门的服务器库和客户端处理逻辑。

5、WebRTC是什么？

WebRTC (Web Real-Time Communication) 是一个更为复杂的生态系统，旨在实现浏览器间的直接音视频通话和任意数据交换。



它的核心思想是尽可能地建立点对点（Peer-to-Peer, P2P）连接，从而绕过中间服务器传输大量媒体数据，以达到最低的延迟。

WebRTC 的整个通信过程分为三个阶段：

• 1）首先是通过信令服务器交换初始信息；
• 2）其次是通过 ICE (Interactive Connectivity Establishment) 框架进行 NAT 和防火墙穿越；
• 3）最后才是建立 P2P 数据通道。
  

ICE 框架依赖于 STUN (Session Traversal Utilities for NAT) 服务器来帮助设备发现自己的公网 IP 地址，如果直接连接失败，则会降级到 TURN (Traversal Using Relays around NAT) 服务器进行中继。

TURN 服务器虽然能保证连接成功，但会消耗大量带宽，因为所有流量都需要经过它转发。

WebRTC 的另一个关键组件是 RTCDataChannel API，它允许在两个浏览器之间建立一个类似 WebSocket 的 P2P 数据通道，用于传输非媒体数据。

由于其架构的复杂性，WebRTC 通常需要一个额外的信令层（常由 WebSocket 或 SSE 实现）来协调连接的建立。

6、兼容性、性能与开发复杂度对比

在为 LLM 应用选择实时通信技术时，必须在兼容性、性能和开发复杂度这三个关键维度上进行权衡。本章节将对 Server-Sent Events (SSE)、WebSocket 和 WebRTC 进行全面的横向对比，以揭示它们在不同方面的优劣，从而为技术选型提供数据驱动的依据。

6.1兼容性与平台支持

首先，在兼容性与平台支持方面，SSE 和 WebSocket 拥有非常广泛的浏览器支持，几乎覆盖了所有现代浏览器，包括 Chrome、Firefox、Safari 和 Edge。Opera Mini 是少数不支持 WebSocket 和 SSE 的例外。IE 浏览器则完全不支持这两种技术。

相比之下，WebRTC 的支持范围稍窄一些，IE 不支持，旧版的 Edge 也不支持，但同样广泛应用于其他现代浏览器及其移动端版本。

对于 LLM 应用而言，这意味着 SSE 和 WebSocket 能够触及更广泛的用户群体。然而，值得注意的是，随着 HTTPS 成为网页标配，HTTP/2 得到了普及，这彻底解决了过去 SSE 在 HTTP/1.1 下因浏览器并发连接数限制（通常是6个）而导致的性能瓶颈，使得 SSE 在现代 Web 架构中表现得更加稳健和高效。

6.2延迟性能

其次，延迟性能是衡量实时通信技术优劣的核心指标。

理论上，WebSocket 具有最低的延迟，因为它在握手完成后就建立了一个纯粹的、无头开销的数据通道。WebRTC 在 P2P 模式下可以实现极低的延迟，因为它避免了服务器中转。

然而，WebRTC 的延迟受到 NAT/防火墙穿越过程的影响，可能需要 fallback 到较慢的 TURN 中继服务器。

SSE 的延迟取决于底层的 HTTP 版本。在 HTTP/1.1 下，由于队头阻塞（Head-of-Line Blocking），多个 SSE 连接可能会相互阻塞。但在 HTTP/2 下，得益于其强大的多路复用能力，SSE 的性能得到了极大提升，可以与常规 HTTP 请求并行，延迟接近 WebSocket。

一项针对真实世界数据流的测试表明，SSE 和 WebSocket 在 EPS（每秒事件数）方面表现出相当的性能，WebSocket 在高并发下略占优势，但差异在实践中往往可以忽略不计。

因此，对于大多数 LLM 文本流式传输场景，SSE 在 HTTP/2 下已经提供了足够低的延迟。

6.3开发复杂度

最后，开发复杂度是决定项目成本和上线速度的关键因素。

在这三者中，SSE 的开发复杂度最低。它基于标准的 HTTP，开发者可以利用现有的 Web 服务器和工具链，客户端代码也极为简洁，只需几行 JavaScript 即可启动 EventSource 并监听事件。

WebSocket 的复杂度显著更高。除了协议本身，开发者还需要处理连接管理、状态同步、手动实现心跳包和自动重连逻辑、应对粘性会话（Sticky Sessions）带来的负载均衡挑战，以及在分布式系统中使用 Redis Pub/Sub 等消息队列来广播消息。

WebRTC 的开发复杂度最高，它不仅包含了上述 WebSocket 的所有挑战，还引入了信令、ICE 候选者收集、STUN/TURN 服务器的配置和维护等一系列全新的难题。此外，WebRTC 的安全模型也更为复杂，需要同时保护信令通道和媒体通道。



综上所述：SSE 在兼容性、性能和开发复杂度之间取得了最佳平衡，尤其是在 HTTP/2 得到普及的今天。WebSocket 提供了更高的灵活性和更低的理论延迟，但代价是巨大的开发和运维复杂性。WebRTC 则因其固有的复杂性，仅适用于特定的 P2P 和媒体流场景。

7、安全性考量与风险缓解策略

在 LLM 应用中采用实时通信技术时，安全性是不可忽视的核心要素。本章节将深入探讨 Server-Sent Events (SSE)、WebSocket 和 WebRTC 在安全性方面的关键考量、潜在风险及相应的缓解策略。

7.1Server-Sent Events

对于 Server-Sent Events (SSE)，其安全性很大程度上继承自标准的 HTTP 安全模型。

首要的安全措施是强制使用 HTTPS，因为 SSE 的长期连接窗口使其更容易受到中间人攻击（Man-in-the-Middle），窃听或篡改流中的数据。

身份验证是另一个关键环节。由于 EventSource API 不支持自定义 HTTP 头部，传统的 JWT 令牌传递变得困难。常见的解决方案是通过 URL 查询参数传递短时效的访问令牌，但这存在安全隐患，因为令牌可能被记录在服务器日志或浏览器历史中。

另一种更安全的方式是利用带有 SameSite=Strict 属性的 Cookie 来进行认证，这种方式能自动随请求发送，但需要注意 CSRF（跨站请求伪造）攻击的风险，可以通过检查 Origin 头部来缓解。

此外，SSE 端点容易受到 DoS（拒绝服务）攻击，攻击者可以通过建立大量连接耗尽服务器资源。对此，应实施严格的速率限制，限制来自同一 IP 或用户的并发连接数。

7.2WebSocket

WebSocket 的安全性挑战更为复杂。

虽然 WSS (WebSocket Secure) 使用 TLS 加密来保护数据传输，但其状态化的性质带来了新的攻击面。

首先，WebSocket 缺乏标准化的身份验证机制，开发者必须自行实现，例如在握手阶段通过 Cookie 或查询参数传递凭证。如果未正确验证 Origin 头部，应用将面临 Cross-Site WebSocket Hijacking (CSWSH) 攻击，恶意网站可以在未经授权的情况下建立 WebSocket 连接并访问敏感数据。

其次，WebSocket 容易受到 DoS 攻击，特别是通过 Flood 攻击（发送大量小消息或建立海量连接）来耗尽服务器 CPU 或内存。有效的防御措施包括要求连接前进行认证、限制消息大小和频率、以及实施精细的速率控制 [89]。输入数据也可能导致注入攻击，如 SQL 注入或 XSS，因此所有传入的消息都必须经过严格的验证和清理。

最后，由于 WebSocket 连接是持久的，如果令牌在连接期间过期，可能会导致会话劫持，因此需要实现 token 刷新机制。

7.3WebRTC

WebRTC 的安全性设计更为严格，其核心理念是端到端加密。

所有媒体流都默认使用 SRTP (Secure Real-time Transport Protocol) 加密，而数据通道则使用 DTLS (Datagram Transport Layer Security) 加密，确保只有通信双方可以解密数据。

然而，WebRTC 的安全性并非万无一失，其脆弱性主要集中在基础设施层面。最著名的安全问题是 IP 地址泄露。由于 ICE 协商需要交换候选者的 IP 地址，即使用户使用了 VPN，其真实的本地和公网 IP 仍可能暴露给通信的另一方，这严重损害了隐私。

缓解此问题的方法是在网络拓扑中强制使用 TURN 服务器中继，从而隐藏客户端的真实 IP。信令通道的安全性至关重要，如果信令服务器未使用 WSS (WebSocket Secure) 或 HTTPS，攻击者可以拦截信令消息，从而发起会话劫持或拒绝服务攻击。

此外，TURN 服务器若配置不当，可能被滥用进行 DDoS 攻击或数据窃取。

最后，尽管 WebRTC 协议本身很安全，但其浏览器实现可能存在漏洞，需要及时更新浏览器以修补已知的安全问题。

8、架构设计与可扩展性挑战

为 LLM 应用选择实时通信技术不仅关乎功能实现，更深刻地影响着系统的整体架构设计和未来的可扩展性。本章节将深入探讨使用 Server-Sent Events (SSE)、WebSocket 和 WebRTC 时面临的架构挑战，特别是在大规模生产环境下的可扩展性问题。

8.1Server-Sent Events

使用 Server-Sent Events (SSE) 的架构相对简单且更具弹性。

由于 SSE 基于标准的 HTTP，它可以轻松地与现有的无状态微服务架构集成。服务器可以水平扩展，因为每个 SSE 连接都是独立的，负载均衡器可以将新连接分发到任何可用的服务器实例。

然而，当需要向所有订阅用户广播消息时，简单的无状态架构会遇到挑战。解决这个问题的常见模式是引入一个中央消息代理，如 Redis Pub/Sub 或 Kafka。所有服务器实例都订阅同一个 Redis 频道，当有新消息需要广播时，只需将消息发布到该频道，Redis 会将其高效地分发给所有相关的 SSE 客户端。这种发布/订阅（Pub/Sub）模式极大地简化了广播逻辑，并提高了系统的可扩展性。

此外，SSE 的 stateless nature 使其非常适合在云原生环境中运行，例如 Kubernetes 或 serverless 平台，因为它不需要在节点间共享会话状态。

8.2WebSocket

相比之下，WebSocket 的架构设计则充满了挑战，其根本原因在于连接的有状态性。

每个 WebSocket 连接都会占用服务器的一个文件描述符，并持续消耗内存和 CPU 资源。当用户数量从数百增加到数万甚至数百万时，这种状态化特性会迅速成为瓶颈。

传统的负载均衡策略（如轮询或最少连接）无法有效分配 WebSocket 连接，因为客户端断线重连后很可能需要回到最初的服务器实例以保持会话状态。

为了解决这个问题，通常需要采用“粘性会话”（Sticky Sessions）或“会话亲缘性”（Session Affinity）的负载均衡策略，但这会导致负载分布不均，并形成单点故障。

更高级的解决方案是构建一个全局状态管理系统，例如将所有连接状态存储在 Redis 等外部数据库中。当服务器 A 接收到需要路由到服务器 B 上某个用户的 WebSocket 消息时，它可以从 Redis 获取目标用户的连接信息并进行转发。这种方法虽然可行，但极大地增加了系统的复杂性和延迟。因此，许多团队最终会选择使用专门的实时通信平台（如 Ably 或 Pusher）来托管这部分基础设施，从而将焦点重新放回业务逻辑上。

8.3WebRTC

WebRTC 的可扩展性问题则源于其点对点（P2P）的本质。

纯 P2P 架构在小规模群组（例如，最多 4-5 人）内工作良好，因为每个参与者只需要与其他成员建立连接即可。然而，当参与者数量增加时，连接数量会呈二次方增长（N² problem），导致每个客户端的带宽和 CPU 负载急剧上升，很快就会超出个人设备的处理能力 [67]。

为了实现 WebRTC 的规模化，必须引入中心化的媒体服务器。

目前主要有两种架构：

• 1）MCU（Multipoint Control Unit，多点控制单元）；
• 2）SFU（Selective Forwarding Unit，选择性转发单元）。
  

MCU 会接收所有参与者的媒体流，进行解码、混音/拼接，然后重新编码成一个新的流再分发给所有人，这样客户端只需接收一个流，但 MCU 承担了巨大的计算压力。

SFU 则是一种更高效的架构，它只负责将每个参与者发送的媒体流转发给其他所有人，而不进行任何处理，从而将计算负担分散到各个客户端。SFU 是现代大规模 WebRTC 应用（如 Zoom、Google Meet）的首选架构。

然而，无论是 MCUs 还是 SFUs，都需要大量的服务器资源和复杂的网络基础设施来支持，这对于许多团队来说是一笔巨大的投资。



总而言之：

• 1）SSE 在可扩展性方面提供了最大的灵活性和成本效益；
• 2）WebSocket 的扩展性挑战巨大，通常需要借助第三方服务或投入大量内部工程资源；
• 3）WebRTC 的扩展性则最为昂贵和复杂，是专门为媒体流设计的，不适合用于普通的文本数据通信。
  

9、最终决策与综合建议”

在对 Server-Sent Events (SSE)、WebSocket 和 WebRTC 进行了全面的原理、性能、安全性和可扩展性分析之后，本章节将整合所有信息，为 LLM 应用的前后端实时通信提供一个清晰的决策框架，并给出具体的选型建议。

选择何种技术，最终取决于您的 LLM 应用的具体需求、团队的技术栈和预算。我们可以将 LLM 应用的实时通信场景划分为几个典型的层级，每个层级对应不同的技术最优解。

9.1第一层级：流式文本展示 (Streaming Text Presentation)

这是最常见的 LLM 应用场景，用户输入一个问题，然后看到答案逐字或逐词地动态呈现出来。这种模式的核心特征是服务器主导的单向数据流。

在这个场景下，Server-Sent Events (SSE) 是无可争议的最佳选择。

其理由非常充分：

1）首先，SSE 的设计初衷就是为此类单向推送而优化的，它比 WebSocket 更加轻量和简单。

2）其次，得益于现代浏览器对 EventSource API 的原生支持，客户端实现极其简单，且内置了可靠的自动重连机制，极大地提升了用户体验和应用的健壮性。

3）再者，SSE 基于标准 HTTP，在部署和运维上非常友好，可以无缝融入现有的 web 服务生态，无需为实时通信单独搭建一套复杂的基础设施。

Shopify 在其 2022 年黑色星期五活动中的 BFCM Live Map 成功案例，就是一个有力的证明，他们通过 SSE 将毫秒级的数据更新推送给数十万用户，展现了其在生产环境下的强大能力和可扩展性。

9.2第二层级：双向实时互动 (Bidirectional Real-Time Interaction)

当应用的需求超越了单向展示，进入真正的“对话”或“协作”阶段时，就需要选择能够支持客户端和服务器双向通信的技术。在这种情况下，WebSocket 是唯一的选择。

典型的用例包括：

1）语音 I/O：OpenAI 的 Realtime API 就是一个绝佳的例子，它利用 WebSocket 实现了低延迟的语音对话，允许用户在 AI 说话时打断，并即时获得反馈。这种场景需要双向的音频流和命令流，是 WebSocket 的典型应用。

2）多智能体系统：当多个 AI Agent 需要在后台协同工作，并需要向前端实时同步各自的思考过程、工具调用结果或状态变化时，WebSocket 提供了必要的双向通道。

3）实时协作编辑：当 LLM 作为协作者与用户共同编写代码、文档或进行头脑风暴时，WebSocket 可以确保用户的每一次修改都能被实时同步给 LLM，反之亦然。

选择 WebSocket 的代价是显著增加的开发和运维复杂度。您需要投入资源来构建和维护一个能够处理成千上万个并发长连接的系统，并解决由此带来的一系列可扩展性问题。

9.3第三层级：点对点媒体流与数据交换 (P2P Media Streaming & Data Exchange)

这是 WebRTC 的专属领域。虽然 WebRTC 也能传输数据，但它的核心价值在于绕过服务器直接传输高质量的音视频流。

在 LLM 应用中，WebRTC 的应用场景非常具体且有限：

1）高级语音交互：当需要处理原始的、高保真的音频流，而不是经过编码的文本或语音片段时，WebRTC 可能是必要的底层传输协议。

2）P2P 文件共享：如果 LLM 应用涉及到用户之间直接通过浏览器共享由 LLM 生成的大文件，WebRTC 的 DataChannel 可以提供一条绕过服务器的高速通道。

除非您的应用明确属于上述范畴，否则不应轻易选择 WebRTC。它的高昂复杂性和成本使其成为一个非常规的选择。

9.4综合决策框架

9.5最终结论与建议

对于绝大多数 LLM 应用的前后端通信需求，我们强烈建议从 Server-Sent Events (SSE) 开始。

它足够强大，足以满足当前主流的流式文本展示需求，同时又足够简单，能让团队快速迭代产品。不要为了所谓的“先进性”或过度设计而一开始就选择更复杂的 WebSocket。只有当业务发展到确实需要双向、低延迟的实时互动时，才应该评估并投入资源迁移到 WebSocket。

记住，没有一种技术是完美的，最好的技术是那个能够以最低的成本和复杂度解决你当前问题的技术。

10、参考资料

[0] EventSource API Docs
[1] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
[2] SSE技术详解：一种全新的HTML5服务器推送事件技术
[3] 使用WebSocket和SSE技术实现Web端消息推送
[4] 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket
[5] 使用WebSocket和SSE技术实现Web端消息推送
[6] 一文读懂前端技术演进：盘点Web前端20年的技术变迁史
[7] WebSocket从入门到精通，半小时就够！
[8] 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket
[9] 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE
[10] WebRTC实时音视频技术基础：基本架构和协议栈》
[11] 零基础入门：基于开源WebRTC，从0到1实现实时音视频聊天功能》
[12] 实时音视频入门学习：开源工程WebRTC的技术原理和使用浅析》
[13] 零基础快速入门WebRTC：基本概念、关键技术、与WebSocket的区别等》
[14] 大模型时代多模型AI网关的架构设计与实现
[15] 全民AI时代，大模型客户端和服务端的实时通信到底用什么协议？
[16] 通俗易懂：AI大模型基于SSE的实时流式响应技术原理和实践示例
[17] Web端实时通信技术SSE在携程机票业务中的实践应用
[18] ChatGPT如何实现聊天一样的实时交互？快速读懂SSE实时“推”技术