实时通信机制（Polling / SSE / WebSocket）
核心导读
浏览器如何实现数据的实时更新？ 传统的 HTTP 协议基于“请求-响应”模型，客户端必须主动发起请求，服务端才能返回数据。如果我们需要实现聊天室、股票行情推送等实时场景，这种模型将面临挑战。
本章将介绍前端应对实时数据通信的三种主要技术：短轮询（Polling）、服务器推送事件（SSE）与全双工 WebSocket，并探讨它们的原理与适用场景。
1. 传统 HTTP 的局限性
HTTP 协议的设计初衷是用于文档检索，它具有无状态（Stateless）和由客户端单向发起的特点：
- 客户端发起 HTTP 请求。
- 服务端处理请求并返回响应。
- 连接完成任务后通常会释放对应的逻辑请求（HTTP/1.1 虽然支持长连接复用，但业务层面的请求-响应模型并未改变）。
在此模式下，服务端无法主动将状态的改变随时通知正在等待的客户端。为了获取最新数据，必须寻找其他技术架构方案。
2. 短轮询（Polling）
最直接的解决方案是短轮询。即客户端利用定时器（如 setInterval），每隔一段固定的时间，自动向服务端发送 HTTP 请求，询问是否有新数据到达。
技术特点与局限：
- 优点：实现机制极其简单，完全依赖标准的 HTTP 协议和 AJAX/Fetch 技术。
- 缺点：可能产生巨大的网络开销与资源浪费。大多数时间里，服务端的响应可能是“无新数据”。无论有无数据，每次请求都需要携带完整的 HTTP 头部（Headers、Cookies 等），在并发量较高的场景下，会导致网络资源被大量无意义的查询占据。
3. 服务器推送事件（Server-Sent Events）
为了降低频繁建立 HTTP 连接的开销，Server-Sent Events (SSE) 提供了一种轻型的单向数据流推送架构。
SSE 建立在 HTTP 协议之上。客户端发起一个包含特殊请求头（Accept: text/event-stream）的 HTTP 请求后，服务端在返回响应时会保持底层的 TCP 连接不断开。随后，服务端可以通过这条持久的通道，持续不断地向客户端推送文本格式的数据。
技术特点与局限：
- 优点：连接持久化，网络开销小；浏览器原生支持断线自动重连机制；非常适合从服务端向客户端单向传输流式数据（例如大语言模型的文本逐字输出、实时交易行情推送）。
- 缺点：通信通道是单向的。如果客户端需要向服务端发起控制指令或发送新数据，必须另外建立普通的 HTTP 请求。
4. WebSocket：全双工通信协议
当应用场景涉及高频的双向交互（如多人在线动作游戏、精密的协同文档编辑）时，我们需要一种既能降低通信开销，又能实现真正双工通信的技术——WebSocket。
WebSocket 是一种独立的网络通信协议。它精妙地借助了 HTTP 协议来完成初始建连：
- 握手阶段：客户端发送一个特殊的 HTTP 请求，声明希望将其升级为新协议（携带
Upgrade: websocket头部）。 - 连接质变：服务端若支持并同意该协议，则回复
101 Switching Protocols状态码。 - 彻底自由：此时 HTTP 的规范使命结束，底层的 TCP 连接被移交给 WebSocket 协议。此后，客户端与服务端享有平等的全双工（Full-Duplex）通信权利，双方可随时收发极简格式的数据帧。
技术特点与局限：
- 优点：支持真正意义上的双向实时通信；数据帧的头部信息极小，通信延迟低、吞吐效率高；支持原生二进制数据（ArrayBuffer）的传输。
- 缺点：架构与开发复杂性较高；由于维护着持久长连接，对服务器端的系统架构、负载均衡策略和心跳监测设计提出了更严格的工程要求。
5. 总结：技术选型对比
| 维度 | 短轮询 (Polling) | 服务器推送事件 (SSE) | WebSocket |
|---|---|---|---|
| 通信方向 | 客户端主动轮询拉取 (单向) | 服务端持续主动推送 (单向) | 客户端与服务端享有平等收发权 (双向全双工) |
| 底层协议 | 标准 HTTP | 标准 HTTP | 独立的 WebSocket 协议 (基于 TCP) |
| 数据开销 | 极高 (包含完整的 HTTP 头部) | 较低 | 极低 (极简的数据帧头部) |
| 典型应用场景 | 定时检查后台异步任务的完成状态 | 大模型对话单向流输出、新闻或系统通知推送 | 实时音视频信令、多人在线对战、协同白板与编辑 |
在实际工程中，开发者应依据具体业务场景对实时性与双向交互频率的要求，在系统的维护复杂度和通信效率之间取得平衡，选择最契合的技术栈。