实时通信机制（Polling / SSE / WebSocket）

1. 传统 HTTP 的局限性 link

HTTP 协议的设计初衷是用于文档检索，它具有无状态（Stateless）和由客户端单向发起的特点：

1. 客户端发起 HTTP 请求。
2. 服务端处理请求并返回响应。
3. 连接完成任务后通常会释放对应的逻辑请求（HTTP/1.1 虽然支持长连接复用，但业务层面的请求-响应模型并未改变）。

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

2. 短轮询（Polling） link

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

技术特点与局限：

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

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

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

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

技术特点与局限：

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

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

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

WebSocket 是一种独立的网络通信协议。它精妙地借助了 HTTP 协议来完成初始建连：

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

技术特点与局限：

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

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

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