实时通信的那些事儿：短轮询、长轮询、SSE 和 WebSocket 到底怎么选？

大家好，我是老码小张，一个喜欢刨根问底、琢磨技术背后原理的程序员。平时不仅喜欢研究各种新技术，还爱思考怎么用它们解决实际开发中的麻烦事。今天咱们聊聊前后端实时通信的几种常见方案：短轮询、长轮询、SSE 和 WebSocket。相信不少朋友在做聊天室、推送、监控等场景时都遇到过"怎么让前端实时拿到后端数据"这个老大难问题。别急，今天我就用接地气的方式，带你一口气搞明白这些技术的来龙去脉和实战要点。

为什么前端想要实时？

我们都知道，HTTP 协议是典型的"请求-响应"模式，浏览器（客户端）主动发起请求，服务器才能响应。也就是说，服务器没法主动"推送"消息给浏览器。这就导致了一个问题：如果后端有新消息，前端怎么第一时间拿到？这也是咱们今天要聊的核心。

方案一：短轮询（Short Polling）

原理和流程

短轮询其实很简单，前端每隔一段时间（比如 2 秒）就给后端发一次请求，问一句："有新消息吗？"如果有，后端就返回数据；没有就返回个空。

ini 复制代码

javascript
setInterval(() => {
  fetch('/api/messages')
    .then(res => res.json())
    .then(data => {
      // 处理新消息
    });
}, 2000);

优点：

实现简单，兼容性好，所有浏览器都支持。

缺点：

太"勤快"了，明明没新消息还一直问，浪费带宽和服务器资源。
实时性受限，最多只能做到轮询间隔那么快。

流程图：

sequenceDiagram participant Client as 前端 participant Server as 后端 loop 每2秒 Client->>Server: 有新消息吗？ Server-->>Client: 有/没有 end

方案二：长轮询（Long Polling）

原理和流程

长轮询是短轮询的"进阶版"。前端发请求后，如果没有新消息，后端不会立刻返回，而是"挂起"这个请求，等有新消息了再返回。前端收到响应后，立刻再发一个请求，形成"接力"。

scss 复制代码

javascript
function longPoll() {
  fetch('/api/messages')
    .then(res => res.json())
    .then(data => {
      // 处理新消息
      longPoll(); // 再发一次
    });
}
longPoll();

优点：

实时性比短轮询好，消息来了就能收到。
兼容性依然很好。

缺点：

服务器要维持大量挂起的连接，对资源消耗大。
还是 HTTP 请求，头部开销大。

流程图：

sequenceDiagram participant Client as 前端 participant Server as 后端 Client->>Server: 有新消息吗？ alt 没有新消息 Server--xClient: 等待... else 有新消息 Server-->>Client: 返回新消息 Client->>Server: 再次发起请求 end

方案三：SSE（Server-Sent Events）

原理和流程

SSE 是 HTML5 标准，允许服务器通过单向通道"推送"消息到浏览器。前端用 EventSource 建立连接，服务器只要有新消息就推送。

ini 复制代码

javascript
const evtSource = new EventSource('/api/stream');
evtSource.onmessage = function(event) {
  // 处理新消息
};

优点：

实现简单，浏览器原生支持。
只用一个 HTTP 连接，节省资源。

缺点：

只能单向（服务器到客户端），不能客户端发消息给服务器。
不支持所有浏览器，比如 IE。
只支持 HTTP/1.x，不适合 WebSocket 场景。

流程图：

sequenceDiagram participant Client as 前端 participant Server as 后端 Client->>Server: 建立 SSE 连接 loop 有新消息 Server-->>Client: 推送新消息 end

方案四：WebSocket

原理和流程

WebSocket 是一种全双工通信协议，前后端可以互相主动发消息。连接建立后，数据可以实时双向传递，非常适合聊天室、游戏、协同编辑等高实时场景。

ini 复制代码

javascript
const ws = new WebSocket('ws://yourserver.com/ws');
ws.onmessage = function(event) {
  // 处理新消息
};
ws.send('hello server!');

优点：

真正的实时、双向通信。
连接建立后数据包很小，效率高。

缺点：

服务器实现稍复杂，需要专门的 WebSocket 服务。
对代理、防火墙等网络环境有一定要求。

流程图：

sequenceDiagram participant Client as 前端 participant Server as 后端 Client->>Server: 建立 WebSocket 连接 Server-->>Client: 连接确认 loop 任意时刻 Client-->>Server: 发送消息 Server-->>Client: 推送消息 end

实战选型建议

短轮询：适合简单、对实时性要求不高的场景，比如定时刷新数据。
长轮询：兼容性好，适合对实时性有要求但不能用 WebSocket 的场景。
SSE：适合服务器单向推送，比如新闻、股票行情，且客户端是现代浏览器。
WebSocket：强实时、双向通信场景首选，比如 IM、游戏、协同编辑。

实践干货：如何选型和优化

业务优先：先看你的业务场景到底需不需要"实时"，别一上来就用 WebSocket。
资源评估：长轮询和 WebSocket 都会占用服务器资源，量大时要考虑扩容、负载均衡。
网络环境：WebSocket 在某些公司网络、老旧代理下可能被阻断，SSE 兼容性也要注意。
降级方案：可以优先尝试 WebSocket，失败后自动降级为长轮询或短轮询。
安全性：记得用 wss（加密 WebSocket）和 https，保护数据安全。

小结

实时通信方案没有银弹，只有适合不适合。了解每种方案的原理和优缺点，结合实际场景做出选择，才是靠谱的架构师思路。希望这篇文章能帮你理清思路，选出最适合你项目的实时通信方案。如果你有更好的实践经验，欢迎留言一起交流！

-- 老码小张