#实时通信：WebSocket、SSE 与轮询对比

传统的 HTTP 协议是基于请求-响应模型的，服务端无法主动向客户端推送数据。为了实现实时通信，前端通常有以下技术方案：

#1. 轮询

• 短轮询：前端通过定时器每隔一段固定时间向服务端发送请求。
  • 缺点：如果数据没有频繁更新，会产生大量无效的请求，造成带宽和服务器资源的冗余开销。
• 长轮询：客户端发送请求后，服务端如果没有新数据，会将请求挂起阻塞。直到有数据产生或达到超时时间，服务端才返回响应。客户端收到响应后立即再次发起挂起请求。
  • 特点：相比短轮询相对减少了请求次数，但服务端需要维护大量的挂起并发连接状态。

#2. Server-Sent Events

SSE 是一种基于 HTTP 的单向通信机制。允许服务端单向向客户端持续推送文本数据流。

• 原理：客户端发起一个普通 HTTP 请求，服务端返回头中包含 Content-Type: text/event-stream，并保持网络连接不断开，持续下发数据片段。
• 优势：
  • 基于标准 HTTP 协议。
  • 浏览器原生提供了直接封装好的 EventSource API。
  • 内置了断线自动重连和机制。
• 劣势：仅支持服务端向客户端传输单向通信流。
• 场景：适用于只需单方向接收数据的场景，如实时统计展示、日志分析滚动。

#3. WebSocket

WebSocket 是一种独立的、基于 TCP 的协议，提供了客户端和服务端之间的全双工通信能力。

• 原理：通过 HTTP 协议发起握手请求获取协议切换同意，服务端同意后，协议升级为 WebSocket。之后的通信不再包含 HTTP 请求头部，直接进行双向数据交换。
• 优势：长链接且彻底平等的双向通信，通信开销较小，延迟低。
• 劣势：
  • 需要独立的 WebSocket 服务器实现支持。
  • 遇到网络断开或切后台时连接维护成本较高，通常需要在应用层实现心跳包检测与断线重连逻辑。
• 场景：适用于高频次、低延迟的双向交互应用场景，如同屏协作、即时聊天。

#4. 选型总结

在实际系统搭建中，不同业务特点应选用不同方案。对于只需向前端下发展示实时数据的状态更新，SSE 的易用性和标准重连特性可以在很多时候替代 WebSocket 的实现成本。而对于需要极频密数据上报与交互的即时通讯模块，全双工的 WebSocket 则是首选项。