实时通信技术选型：轮询、WebSocket与SSE全解析

开头就直接切正题。

2026年了，如果你还在用定时轮询给聊天应用拉消息，那确实有点说不过去。实时通信这块，从最原始的HTTP轮询，到长轮询、SSE、WebSocket，技术路线已经非常成熟，选型也不该再纠结“会不会”的问题，而是该想清楚“为什么用、什么时候用、用错了会付出什么代价”。我过去几年做过不少带实时交互的系统，聊天室、消息推送、大模型流式输出都碰过，轮询、WebSocket、SSE这三条路线也都踩过坑。这篇文章就把它们的原理、适用场景、实际配置和疑难杂症一次说透，希望对正在做技术选型或排查线上问题的你有帮助。

1. 先算一笔账：轮询为什么该退休了

1.1 轮询的工作原理：HTTP请求-响应模型的“笨办法”

轮询的本质是让客户端按照固定时间间隔，不停向服务器发HTTP请求，问一句“有新消息吗”。服务器每次收到请求，就去查一下数据源，有数据就返回数据，没数据就返回空结果。客户端拿到响应之后，再等一个定时器到期，继续发下一次请求。

用代码表达就是这样一个循环：

javascript复制setInterval(async () => {
  const res = await fetch('/api/messages?since=lastId');
  const data = await res.json();
  if (data.length > 0) renderMessages(data);
}, 3000);

这个逻辑非常简单，几乎不需要任何服务端特殊能力，普通Web服务器、CDN、负载均衡都能直接扛住。早期很多IM类应用、工单系统、订单状态页，都是这么硬写出来的。对当时的业务量来说，它确实能跑，而且跑得很稳。

但问题是：轮询的“实时”是假实时。你设了3秒一次，那消息平均延迟就是1.5秒，最坏情况3秒。如果为了降低延迟把间隔改成500毫秒，请求量直接翻6倍，服务端压力立刻上来了。而WebSocket和SSE这类真正具备服务端主动推送能力的方案，消息到达延迟可以压缩到毫秒级，请求频率和实时性之间不用再互相打架。

1.2 轮询的三宗罪：延迟、带宽浪费、服务器压力

延迟问题前面已经说了，接下来重点说开销。HTTP请求不是只有业务数据本身，每个请求都要带上完整的请求头、响应头，经过DNS解析、TCP握手、TLS握手、连接建立这一整套流程。即使你用了Keep-Alive复用连接，应用层上仍然有大量无效请求在消耗资源。

举个具体例子。一个中等规模的聊天应用，在线用户1000人，轮询间隔3秒。那每秒就有约333个请求打到服务端。每个请求就算50ms处理完，服务器同时要处理的QPS也就是333，对于很多后端来说并不算高。但如果用户量涨到10万，每秒就是3.3万个请求，这就不只是应用服务器压力的问题了，数据库、缓存、网关全都会被拖下水。而这里面绝大多数请求，返回的只是“没有新消息”这种空结果。

从带宽角度看也很浪费。每个HTTP请求的报文头部少说几百字节，一个空响应加上响应头又是几百字节。一次轮询来回将近1KB的无效传输，1万个用户、每天轮询28800次，算下来流量非常可观。移动端用户还会因此白白消耗电量，这对体验影响很大。

1.3 长轮询：一个“中间态”方案

为了解决轮询“频繁空转”的问题，出现了长轮询。长轮询的思路是：客户端发一个请求到服务器，服务器先不返回，而是把这个请求“挂住”，等确实有新消息了才返回；客户端收到返回后，立刻发下一个请求继续挂着。

javascript复制async function longPoll() {
  const res = await fetch('/api/poll');
  const data = await res.json();
  renderMessages(data);
  longPoll();
}

长轮询把“频繁问”变成了“等通知”，消息延迟大幅降低，服务端的无效请求也少了很多。但它的代价也很明显：连接被长期占据，服务端需要维护大量挂起请求，每一次消息返回后都要重新建立上下文，服务器资源和连接管理复杂度反而更高。而且长轮询本质上仍然是“一问一答”的半双工模式，协议层面并没有真正的服务端主动下发能力。

轮询、长轮询、WebSocket、SSE这几种方案的核心差异，可以用下面这个表格看清楚：

如果业务对实时性要求不高，比如每天只有几次低频提醒，轮询依然是可接受的方案，没必要过度设计。但一旦是聊天应用、在线协作、实时行情这类强实时场景，轮询就是纯粹的“拿资源换简单”，用户规模一大就会精准爆炸。

2. WebSocket：真正意义上的全双工实时通道

2.1 握手与协议升级：从HTTP升级到WS

WebSocket和HTTP并不是完全割裂的两套协议。它的设计巧妙之处在于，先借助HTTP完成一次握手，然后通过协议升级切换到WebSocket通道。这就是为什么几乎所有WebSocket客户端和服务端，都天然兼容HTTP的握手端口和网关配置。

一次典型的握手请求长这样：

http复制GET /ws HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

服务端收到之后，如果同意升级，会返回状态码101 Switching Protocols，同时带上Sec-WebSocket-Accept响应头。这个响应头的值基于请求里的Sec-WebSocket-Key做一次SHA-1加Base64编码计算得出，既是握手校验，也是防止普通HTTP请求误升级的机制。

握手完成后，客户端和服务端之间的连接就变成了一个“管道”，双方可以随时往管道里写数据。Node.js里的实现大概是这样的：

javascript复制const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  ws.on('message', (data) => {
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(`echo: ${data}`);
      }
    });
  });
});

2.2 帧格式与消息机制：为什么WebSocket开销那么低

WebSocket能实现双向通信、且开销低，关键在于它的帧格式。WebSocket帧是一个紧凑的二进制结构，头部只有2到14字节，远远小于HTTP请求头。它通过操作码区分文本帧、二进制帧、关闭帧、Ping/Pong帧等类型：文本帧用0x1表示，二进制帧用0x2表示，Ping和Pong分别用0x9和0xA。

这带来两个直接优势。一是消息延迟很低，因为不需要反复建立连接、不需要每次带一大堆头部信息。二是它天然支持二进制数据，文件分片、音视频流、游戏状态同步这类数据可以直接通过二进制帧传输，不需要像HTTP那样用Base64编码把数据膨胀三分之一。

Ping/Pong帧还有个重要作用是心跳。TCP连接本身没有“这个连接还活着”的语义，如果客户端或网络设备静默地把连接掐断了，双方在很长一段时间内都感知不到。通过周期性Ping，服务端可以快速发现死连接并清理资源，客户端也可以根据Pong是否超时来决定是否重新连接。

2.3 什么时候选WebSocket：场景与成本

WebSocket强的场景，通常是双向、高频、低延迟这一类需求：

• 在线聊天：用户发消息、收消息、输入状态、已读回执，全都要实时双向流动。
• 多人协作：在线文档、白板、图编辑器的光标位置和操作同步。
• 实时游戏：多人在线对战的状态同步，位置、动作、技能释放。
• 金融行情：交易客户端需要推送行情快照和逐笔成交，同时要能发送指令。

但WebSocket不是银弹。它维护的是有状态长连接，服务端要保存每个连接的状态，连接的建立、心跳、关闭、重连都要自己管理。横向扩展时更麻烦：一个用户连在节点A，另一个用户连在节点B，消息在两个节点之间怎么传递？通常需要引入Redis Pub/Sub或者消息队列做广播。也就是说，业务复杂度腾挪到了基础设施层面。

还有一点，WebSocket协议本身不处理消息的ack、不保证顺序、不提供重发机制，这些都得应用层自己做。如果项目团队对状态同步和消息可靠性没有足够经验，很容易写出“连接在但消息丢了”的诡异问题。

2.4 常见陷阱：代理、断线重连、心跳

WebSocket最常见的线上问题，大多不是协议本身的问题，而是代理和网络环境造成的。很多企业网络、云厂商负载均衡、CDN，默认只处理HTTP流量，遇到WebSocket升级请求要么直接掐断，要么因为超时设置导致连接被定期断开。

Nginx作为反向代理时，需要显式配置Upgrade和Connection头，否则Nginx会按普通HTTP请求处理，WebSocket连接根本建立不起来。核心配置是这样的：

nginx复制map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

upstream ws_backend {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name ws.example.com;

    location /ws {
        proxy_pass http://ws_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
    }
}

这几个配置项里，proxy_http_version必须设为1.1，因为HTTP/1.0不支持Upgrade机制；proxy_set_header Upgrade和Connection是保证升级请求能透传到后端服务的核心；proxy_read_timeout控制的是连接空闲多久会被Nginx断开，如果业务里心跳频率是30秒一次，那这个超时时间至少要放在75秒以上，否则Nginx会在两次心跳之间把连接掐掉。

断线重连这块也需要应用层兜底。很多客户端库只负责建立连接和收发消息，断线之后不会自动恢复。标准做法是在连接关闭事件里做一个带退避的重试机制，同时检查心跳超时，避免出现“客户端以为自己还连着，服务端早就把连接清了”的情况。

3. SSE：一条被低估的“单向推流”大通道

3.1 SSE是什么：EventSource与text/event-stream

SSE的全称是Server-Sent Events，翻译过来就是“服务端推送事件”。它和WebSocket不同，是单向的：只能服务端往客户端推，客户端没法通过同一个连接往服务端发数据。它在HTTP协议之上工作，媒体类型是text/event-stream，客户端的标准API是EventSource。

一个最简SSE响应看起来是这样的：

http复制HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

data: {"message":"hello"}\n\n

客户端这样接收：

javascript复制const es = new EventSource('/api/stream');
es.onmessage = (event) => {
  console.log(JSON.parse(event.data));
};

SSE的核心优势有三点。第一是协议简单，不需要额外的握手升级，普通HTTP服务端就能覆盖，也不需要处理像WebSocket那么多帧格式和状态。第二是自带重连机制，EventSource在连接断开之后会自动重新连接，并且通过Last-Event-ID字段告诉服务端“我断到哪了”，服务端可以接着往下推。第三是天然支持HTTP协议的所有能力，比如Nginx可以直接缓存、代理、压缩SSE响应，这是WebSocket做不到的。

3.2 SSE与WebSocket的对比：不是替代关系，是取舍关系

很多初学者会陷入“SSE和WebSocket谁更强”的争论，其实这两个东西压根不在同一个维度上。SSE是单向的、基于HTTP的、自带重连的推送方案；WebSocket是双向的、自成一派的、需要自己管理连接状态的全双工协议。选择的标准很简单：你只需要服务端推数据给客户端，还是客户端也要高频往服务端发数据？

拿聊天场景举例。如果只是做“机器人给用户发通知”，SSE完全够用；但如果是两个真人之间互发消息，就必须要WebSocket，因为每个客户端既要收也要发。反过来，如果业务是股票行情、日志流、大模型输出这类以服务端为主的推送，SSE可以显著降低实现复杂度，少写一半代码。

3.3 SSE最火的场景：LLM流式输出与Markdown渲染

最近一两年SSE使用率暴涨，最大的推动力就是大语言模型的流式输出。大模型的回答是一个字一个字、一个token一个token生成的，如果等全部生成完再一次性返回，用户要盯着空白页面看好几秒甚至几十秒，体验非常差。流式输出则让服务端通过SSE连接，把每个增量token生成出来就立刻推给前端，用户能看到文字一个接一个地浮现出来。

前端要做的事，就是接收SSE流，把累积的增量文本拼起来，再用Markdown渲染器实时渲染。很多前端项目踩过的坑是：直接对完整Markdown文本做整段渲染，每收到一个token就全量重渲染一次，结果页面卡顿、光标跳动、渲染闪烁。正确做法是做一个速率受限的增量渲染，或者用虚拟滚动优化长文本渲染路径。

一个简单的流式渲染器逻辑大概是这样的：

javascript复制const es = new EventSource('/api/chat-stream');
let markdownText = '';

es.onmessage = (event) => {
  const token = JSON.parse(event.data).content;
  markdownText += token;
  renderer.update(markdownText);
};

es.onerror = () => {
  // EventSource 会自动重连，这里只需处理业务层提示
};

除了大模型流式输出，SSE还非常适合服务端状态通知、故障告警、定时任务进展推送这类“我要把一件事从头推到尾”的场景。因为它的实现成本和排查成本都低得多，很多时候你不需要引入WebSocket那套重型机制，一个EventSource就能把产品需求解决得很漂亮。

4. 2026年选型：Spring Boot与Node.js的实战路线

4.1 服务端实现WebSocket：Spring Boot配置与示例

Spring Boot从很早就支持WebSocket，实现套路很固定：一个配置类注册WebSocket端点，一个Handler类处理连接和消息。下面是一种常见写法：

java复制@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(new ChatHandler(), "/ws/chat").setAllowedOrigins("*");
    }
}

java复制public class ChatHandler extends TextWebSocketHandler {

    private static final CopyOnWriteArraySet<WebSocketSession> sessions = new CopyOnWriteArraySet<>();

    @Override
    public void afterConnectionEstablished(WebSocketSession session) {
        sessions.add(session);
    }

    @Override
    protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {
        for (WebSocketSession s : sessions) {
            if (s.isOpen()) {
                s.sendMessage(message);
            }
        }
    }

    @Override
    public void afterConnectionClosed(WebSocketSession session, CloseStatus status) {
        sessions.remove(session);
    }
}

这里有几个关键点。setAllowedOrigins必须结合前端实际域名配置，生产环境别直接用*。sessions集合为了线程安全，我习惯用CopyOnWriteArraySet，它很适合读多写少的场景，如果并发量特别大，建议改为基于Redis Pub/Sub的广播方案，把所有实例的会话统一管理。

Spring Boot下还有一个容易被忽略的配置：WebSocket握手是借助HTTP请求完成的，如果项目里写了过滤器或拦截器，务必确认它们没有拦截WS升级请求。很多GitHub issue里反馈的“WebSocket握手失败、403”，排查到最后都是被Spring Security或自定义Filter拦截了。

4.2 服务端实现SSE：Spring Boot与Node.js的两种姿势

Spring Boot实现SSE有好几种API，最简洁的是利用SseEmitter：

java复制@RestController
public class SseController {

    private final CopyOnWriteArraySet<SseEmitter> emitters = new CopyOnWriteArraySet<>();

    @GetMapping("/api/stream")
    public SseEmitter stream() {
        SseEmitter emitter = new SseEmitter(0L); // 0L 表示不超时
        emitters.add(emitter);
        emitter.onCompletion(() -> emitters.remove(emitter));
        emitter.onTimeout(() -> emitters.remove(emitter));
        return emitter;
    }

    public void push(String data) {
        for (SseEmitter emitter : emitters) {
            try {
                emitter.send(SseEmitter.event().data(data));
            } catch (IOException e) {
                emitters.remove(emitter);
            }
        }
    }
}

Node.js这边则非常简单，Express里直接res.write就能实现SSE：

javascript复制app.get('/api/stream', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
  });

  const timer = setInterval(() => {
    res.write(`data: ${JSON.stringify({ time: Date.now() })}\n\n`);
  }, 1000);

  req.on('close', () => clearInterval(timer));
});

两者对比下来，Node.js的SSE实现更直接，因为Node.js的流模型天然适合做持续推送；Spring Boot的SseEmitter则需要自己管理emitter集合，并且在分布式环境下要注意多实例的emitter不在同一个内存空间，跨节点推送需要借助Redis或MQ解决。

4.3 Nginx反向代理WebSocket与SSE配置

前面提到的Nginx配置是WebSocket场景。SSE场景下的Nginx配置有个关键的坑：默认情况下Nginx会缓冲upstream的响应，也就是说服务端推过来的数据会先攒在Nginx缓冲区里，攒到一定大小才发给客户端。这样一来SSE就失去了流式效果，前端收到的数据会一顿一顿的，无法做实时渲染。

解决办法是关闭SSE响应路径的缓冲：

nginx复制location /api/stream {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 3600s;
}

proxy_set_header Connection这里设置为空字符串，是为了让Nginx不自动追加Connection: keep-alive头，避免影响SSE长连接。同时建议在服务端响应头里也设置X-Accel-Buffering: no，这个响应头是Nginx专门用来控制是否缓冲的，优先级比配置高，服务端可以按接口灵活控制。

4.4 连接生命周期管理：心跳、重连、业务级保活

无论是WebSocket还是SSE，长连接都不能“连上就不管”。线上最常见的故障就是连接被中间设备静默切断，比如云厂商的负载均衡默认空闲超时60秒，如果60秒内没有任何数据传输，它会在中间把TCP连接关掉。两边谁都没收到关闭通知，就出现了“假连接”。

WebSocket场景下，我建议客户端每30秒发一次Ping，服务端收到后回Pong；如果服务端连续60秒没收到任何消息，就判定这个连接失效，主动关闭并清理资源。客户端收到关闭或心跳超时后，用指数退避策略重连，比如1秒、2秒、4秒、8秒...最多退避到30秒。

SSE场景因为EventSource自带重连，这个过程是自动的，但要注意服务端需要设法拿到Last-Event-ID。如果业务要求重连后补发断点消息，服务端就要根据这个ID做数据续传。标准的SSE客户端断线后会自动带上Last-Event-ID请求头，服务端读取它即可。

5. 问题排查实录：那些线上连接崩溃和流断开的坑

5.1 常见错误速查表：连接失败、流断开、崩溃

这几年在社区里逛，经常看到类似的报错。我把高频问题整理成了一个速查表，方便遇到问题时直接对照排查：

5.2 排查WebSocket连接故障的方法

排查WebSocket问题，我的习惯是分三层看：网络层、协议层、应用层。

网络层先用终端命令测试TCP握手是否正常，比如用curl发起一次握手请求：

bash复制curl -v -i \
  -H "Connection: Upgrade" \
  -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -H "Sec-WebSocket-Version: 13" \
  http://your-server/ws

如果curl都能拿到101切换协议响应，说明网络、Nginx、服务端握手链路都没问题，问题大概率出在客户端代码或业务逻辑上。如果握手失败，就看响应码：404说明路径不对，403说明被安全过滤拦了，502说明后端服务没启动或负载均衡把请求路由到了不健康的节点。

协议层排查最常用的是Chrome DevTools的Network面板，勾选WS过滤器，点开一条WebSocket连接的Messages标签，能看到双向发送的帧数据。连接被断开时，这里也会显示关闭帧的状态码。1000是正常关闭，1006是异常关闭，1001是服务端主动断开，500-2999之间的状态码是业务自定义的。

应用层就要看日志了。服务端WebSocket框架一般都有onClose回调，打印出关闭状态码和原因。如果看到很多1011或1006，说明服务端进程内部报错或连接被外部因素切断，需要结合服务端错误堆栈判断。

5.3 浏览器崩溃与连接数限制

“websocket导致浏览器崩溃”这个现象，我见过不少次。绝大多数情况下，问题不是WebSocket协议本身，而是前端代码在连接管理和数据渲染上失控了。

比如浏览器对每个域名的HTTP/1.1并发连接数有限制，通常是6个。WebSocket连接也占用这个配额，如果页面同时打开了多个WebSocket连接，或者连接没有在页面销毁时关闭，持续累积下去，浏览器会逐渐耗尽网络资源。

另一个常见崩溃原因是前端拿到消息后直接做DOM操作。如果服务端推送频率很高，前端每条消息都触发一次重绘，很快页面就会卡死，最终浏览器会弹“页面无响应”。正确做法是对消息做批量处理，用requestAnimationFrame或防抖节流的方式合并渲染，把高频数据流变成低频DOM更新。

还有一类问题出在内存泄漏。WebSocket的事件回调里如果引用了外部的闭包变量，而连接没有正确关闭，旧对象就无法被垃圾回收。长时间挂着页面，内存会慢慢涨上去，直到浏览器崩溃。

5.4 SSE使用注意事项：自动重连与断点续传的真相

SSE虽然自带重连，但这个重连是“无脑”重连，它只负责重新建立连接，不负责恢复业务状态。如果你的业务场景要求断线后能补发消息，就必须自己实现基于Last-Event-ID的服务端对齐逻辑。

举个例子。服务端按顺序推送事件ID 1到10，客户端收到1到5后断网了。EventSource重连时，请求头里会自动带上Last-Event-ID: 5，服务端收到这个值，就可以从6开始继续推送。但前提是服务端要保存至少最近一段时间的消息ID和内容，否则客户端重新连上之后，中间丢失的消息就找不回来了。

SSE还有一个容易踩的坑：某些浏览器在后台标签页会限制定时器的执行频率，EventSource的自动重连虽然基于网络API不受影响，但如果你的SSE业务逻辑里依赖JavaScript定时器做心跳或界面更新，切后台超过一定时间后，重连和界面状态可能会对不上。这种情况建议在页面重新可见时，主动做一次数据同步，而不是完全依赖SSE的自动行为。

写在最后的经验之谈

做了这么多年实时通信，我最大的感触是：选型不是选“最先进”的，而是选“最匹配”的。如果只是服务端单向推送，别犹豫，直接SSE，省一半代码；如果是双向高频互动，WebSocket值得投入，但必须把心跳、重连、代理配置、分布式消息广播这些基础设施一次性搭好。轮询也并不是历史垃圾，在某些低频率、低并发的内部系统里，用轮询反而更省事、更好维护。我自己现在做实时模块，会先问产品“你到底需不需要双向”，再决定技术路线，而不是一上来就上全套WebSocket。这个习惯帮我避掉了很多无谓的复杂度，也希望对你选型有用。