四种实时通信技术：短轮询、长轮询、WebSocket和SSE的特点与应用

这篇文章，我们聊聊 四种实时通信技术：短轮询、长轮询、WebSocket 和 SSE 。 # 1 短轮询 浏览器 **定时**（如每秒）向服务器发送 HTTP 请求，服务器立即返回当前数据（无论是否有更新）。  - **优点**：实现简单，兼容性极佳 - **缺点**：高频请求浪费资源，实时性差（依赖轮询间隔） - **延迟**：高（取决于轮询频率） - **适用场景**：兼容性要求高，延迟不敏感的简单场景。 笔者职业生涯印象最深刻的短轮询应用场景是**比分直播**：  如图所示，用户进入比分直播界面，浏览器定时查询赛事信息（比分变动、黄红牌等），假如数据有变化，则重新渲染页面。 这种方式实现起来非常简单可靠，但是频繁的调用后端接口，会对后端性能会有影响（主要是 CPU）。同时，因为依赖轮询间隔，页面数据变化有延迟，用户体验并不算太好。 # 2 长轮询 浏览器发送 HTTP 请求后，服务器 **挂起连接** 直到数据更新或超时，返回响应后浏览器立即发起新请求。  - **优点**：减少无效请求，比短轮询实时性更好 - **缺点**：服务器需维护挂起连接，高并发时资源消耗大 - **延迟**：中（取决于数据更新频率） - **适用场景**：需要较好实时性且无法用 WebSocket/SSE 的场景（如消息通知） 长轮询最常见的应用场景是：配置中心，我们耳熟能详的注册中心 Nacos 、阿波罗都是依赖长轮询机制。  > > > 客户端发起请求后，Nacos 服务端不会立即返回请求结果，而是将请求挂起等待一段时间，如果此段时间内服务端数据变更，立即响应客户端请求，若是一直无变化则等到指定的超时时间后响应请求，客户端重新发起长链接。 > # 3 WebSocket 基于 TCP 的全双工协议，通过 HTTP 升级握手（**`Upgrade: websocket`**）建立持久连接，**双向实时通信。**  - **优点**：最低延迟，支持双向交互，节省带宽 - **缺点**：实现复杂，需单独处理连接状态 - **延迟**：极低 - **适用场景**：聊天室、在线游戏、协同编辑等 **高实时双向交互** 需求 笔者曾经服务于北京一家电商公司，参与直播答题功能的研发。  直播答题整体架构见下图：  Netty TCP 网关的技术选型是：Netty、ProtoBuf、WebSocket ，选择 WebSocket 是因为它支持双向实时通信，同时 Netty 内置了 WebSocket 实现类，工程实现起来相对简单。 # 4 Server Send Event(SSE) 基于 HTTP 协议，服务器可 **主动推送** 数据流（如`Content-Type: text/event-stream`），浏览器通过`EventSource` API 监听。  - **优点**：原生支持断线重连，轻量级（HTTP协议） - **缺点**：不支持浏览器向服务器发送数据 - **延迟**：低（服务器可即时推送） - **适用场景**：股票行情、实时日志等 **服务器单向推送** 需求。 SSE 最经典的应用场景是 ： DeepSeek web 聊天界面 ，如图所示：  当在 DeepSeek 对话框发送消息后，浏览器会发送一个 HTTP 请求 ，服务端会通过 SSE 方式将数据返回到浏览器。  # 5 总结 | **特性** | **短轮询** | **长轮询** | **SSE** | **WebSocket** | | --- | --- | --- | --- | --- | | **通信方向** | 浏览器→服务器 | 浏览器→服务器 | 服务器→浏览器 | 双向通信 | | **协议** | HTTP | HTTP | HTTP | WebSocket（基于TCP） | | **实时性** | 低 | 中 | 高 | 极高 | | **资源消耗** | 高（频繁请求） | 中（挂起连接） | 低 | 低（长连接） | **选择建议**： - 需要 **简单兼容性** → 短轮询 - 需要 **中等实时性** → 长轮询 - 只需 **服务器推送** → SSE - 需要 **全双工实时交互** → WebSocket