# 实时通信原理：Polling/SSE/WebSocket

::: tip 核心导读
**浏览器如何实现数据的实时更新？** 
传统的 HTTP 协议基于“请求-响应”模型，客户端必须主动发起请求，服务端才能返回数据。如果我们需要实现聊天室、股票行情推送等实时场景，这种模型将面临挑战。

本章将介绍前端应对实时数据通信的三种主要技术：短轮询（Polling）、服务器推送事件（SSE）与全双工 WebSocket，并探讨它们的原理与适用场景。
:::

---

## 1. 传统 HTTP 的局限性

HTTP 协议的设计初衷是用于文档检索，它具有**无状态（Stateless）**和**由客户端单向发起**的特点：
1. 客户端发起 HTTP 请求。
2. 服务端处理请求并返回响应。
3. 连接完成任务后通常会释放对应的逻辑请求（HTTP/1.1 虽然支持长连接复用，但业务层面的请求-响应模型并未改变）。

在此模式下，服务端无法主动将状态的改变随时通知正在等待的客户端。为了获取最新数据，必须寻找其他技术架构方案。

---

## 2. 短轮询（Polling）

最直接的解决方案是**短轮询**。即客户端利用定时器（如 `setInterval`），每隔一段固定的时间，自动向服务端发送 HTTP 请求，询问是否有新数据到达。

<PollingDemo />

**技术特点与局限：**
- **优点**：实现机制极其简单，完全依赖标准的 HTTP 协议和 AJAX/Fetch 技术。
- **缺点**：可能产生巨大的网络开销与资源浪费。大多数时间里，服务端的响应可能是“无新数据”。无论有无数据，每次请求都需要携带完整的 HTTP 头部（Headers、Cookies 等），在并发量较高的场景下，会导致网络资源被大量无意义的查询占据。

---

## 3. 服务器推送事件（Server-Sent Events）

为了降低频繁建立 HTTP 连接的开销，**Server-Sent Events (SSE)** 提供了一种轻型的单向数据流推送架构。

SSE 建立在 HTTP 协议之上。客户端发起一个包含特殊请求头（`Accept: text/event-stream`）的 HTTP 请求后，服务端在返回响应时会保持底层的 TCP 连接不断开。随后，服务端可以通过这条持久的通道，持续不断地向客户端推送文本格式的数据。

<SSEDemo />

**技术特点与局限：**
- **优点**：连接持久化，网络开销小；浏览器原生支持断线自动重连机制；非常适合从服务端向客户端**单向**传输流式数据（例如大语言模型的文本逐字输出、实时交易行情推送）。
- **缺点**：通信通道是单向的。如果客户端需要向服务端发起控制指令或发送新数据，必须另外建立普通的 HTTP 请求。

---

## 4. WebSocket：全双工通信协议

当应用场景涉及高频的双向交互（如多人在线动作游戏、精密的协同文档编辑）时，我们需要一种既能降低通信开销，又能实现真正双工通信的技术——**WebSocket**。

WebSocket 是一种独立的网络通信协议。它精妙地借助了 HTTP 协议来完成初始建连：
1. **握手阶段**：客户端发送一个特殊的 HTTP 请求，声明希望将其升级为新协议（携带 `Upgrade: websocket` 头部）。
2. **连接质变**：服务端若支持并同意该协议，则回复 `101 Switching Protocols` 状态码。
3. **彻底自由**：此时 HTTP 的规范使命结束，底层的 TCP 连接被移交给 WebSocket 协议。此后，客户端与服务端享有平等的全双工（Full-Duplex）通信权利，双方可随时收发极简格式的数据帧。

<WebSocketDemo />

**技术特点与局限：**
- **优点**：支持真正意义上的双向实时通信；数据帧的头部信息极小，通信延迟低、吞吐效率高；支持原生二进制数据（ArrayBuffer）的传输。
- **缺点**：架构与开发复杂性较高；由于维护着持久长连接，对服务器端的系统架构、负载均衡策略和心跳监测设计提出了更严格的工程要求。

---

## 5. 总结：技术选型对比

| 维度 | 短轮询 (Polling) | 服务器推送事件 (SSE) | WebSocket |
| :--- | :--- | :--- | :--- |
| **通信方向** | 客户端主动轮询拉取 (单向) | 服务端持续主动推送 (单向) | 客户端与服务端享有平等收发权 (双向全双工) |
| **底层协议** | 标准 HTTP | 标准 HTTP | 独立的 WebSocket 协议 (基于 TCP) |
| **数据开销** | 极高 (包含完整的 HTTP 头部) | 较低 | 极低 (极简的数据帧头部) |
| **典型应用场景** | 定时检查后台异步任务的完成状态 | 大模型对话单向流输出、新闻或系统通知推送 | 实时音视频信令、多人在线对战、协同白板与编辑 |

在实际工程中，开发者应依据具体业务场景对实时性与双向交互频率的要求，在系统的维护复杂度和通信效率之间取得平衡，选择最契合的技术栈。