SSE、WebSockets 与轮询对比

WebSockets 会在客户端与服务器之间建立持久的 TCP 连接。双方都可以随时发送消息，因此 WebSockets 非常适合真正的交互式实时通信，例如聊天应用、协作文档编辑、多人游戏和实时光标。连接会一直保持打开状态，直到任一方明确将其关闭。

SSE（服务器推送事件）使用普通 HTTP 连接，服务器通过一系列事件将数据持续发送给客户端。该连接是单向的：只有服务器可以发送数据。客户端无法通过 SSE 连接发回消息，而是要为此单独发起 HTTP 请求。SSE 通过浏览器的 EventSource API 实现。

短轮询是指客户端按照固定间隔发送 HTTP 请求（例如每 5 秒一次）：“有更新吗？”服务器立即使用当前数据进行响应。这是最简单的实现方式，但也是最浪费资源的方式——即使没有新内容，客户端仍会发送大量请求。它只适用于变化非常缓慢的数据。

长轮询改进了短轮询：客户端发出请求后，服务器会保持连接打开，直到有新数据可用。新数据到达后，服务器发送响应，客户端立即发起下一次请求。这样可以减少不必要的响应，但它的开销仍高于 SSE，因为每次响应都需要重新建立 TCP 连接。

与 WebSockets 相比，SSE 在服务器向客户端推送数据方面具有多项实用优势：它通过普通 HTTP 工作，无需协议升级，因此无需特殊配置即可通过企业代理和负载均衡器。EventSource 内置了自动重新连接功能。基于文本的协议也易于在浏览器的网络标签页中调试。

SSE 存在一些实际局限：它只能传输文本（二进制数据必须进行 base64 编码），它是单向的（客户端无法反向推送），并且 HTTP/1.1 将每个域名的并发 EventSource 连接数限制为 6 个（HTTP/2 会通过一条连接进行多路复用，从而消除这一限制）。要实现双向通信，SSE 需要配合 REST 调用。

SSE 非常适合以下场景：显示实时指标的实时仪表板、推送新提醒的通知流、显示长时间运行的服务器进程进度的进度条、实时社交媒体动态、股票价格行情，以及消息只从服务器流向客户端的聊天界面（消息需要单独使用 POST 发送）。这些场景的共同点是由服务器发起更新。

当您需要低延迟的双向通信时，必须使用 WebSockets，例如通过一条连接双向传递消息的实时聊天、协同编辑（类似 Google Docs）、客户端操作和服务器更新都快速发生的多人游戏、实时拍卖以及交易平台。双向通信带来的价值足以证明其复杂性是合理的。

HTTP/2 显著提升了 SSE 的实用性。连接多路复用意味着来自同一域名的所有 SSE 流共享一条 TCP 连接，从而消除了每个域名的连接数限制。如果您的服务器支持 HTTP/2，那么对于包含多个同时数据流的仪表板，SSE 会更加实用。

决策框架：如果您需要低延迟的双向通信 → 使用 WebSockets。如果服务器推送更新而客户端只读取数据 → 使用 SSE。如果您只需要偶尔更新且重视简单性 → 使用轮询。如果服务器 API 已经存在且无法添加 SSE → 使用轮询。请从能够满足延迟要求的最简单方案开始。

初始握手完成后，WebSocket 帧会为每条消息增加 2-14 个字节。SSE 会在每条连接建立时添加一次 HTTP 标头，之后传输以换行符分隔的文本。短轮询则会在每次轮询时都包含完整的 HTTP 请求/响应标头。对于高频数据，WebSockets 的开销更低。对于不频繁的服务器推送，SSE 更简单，而且开销也在可接受范围内。

SSE 与 WebSockets 在方向性上的关键区别是什么？

WebSockets：双向持久 TCP 连接（聊天、游戏、协同编辑）。SSE：通过 EventSource API 实现的单向服务器到客户端 HTTP 推送（通知、仪表板、动态流）。短轮询：固定间隔请求（最简单但最浪费资源）。长轮询：服务器保持响应，直到有数据可用（请求更少，但延迟更高）。SSE 的优势：可以通过代理，支持自动重新连接。SSE 的局限：仅支持文本、单向通信，以及 HTTP/1.1 的连接数限制。