前端实时推送技术解析：轮询、SSE与WebSocket对比选型-北京尧图网络

1. HTTP协议为什么做不了真正的服务器主动推送搞实时推送之前得先把一个基础问题聊透HTTP协议本质上是一个请求-响应模型。客户端发一个请求服务端返回一个响应连接结束。很多业务开发的同事对这块理解比较粗总觉得服务端主动推个数据给我是理所当然的事其实在HTTP的世界里服务器连怎么主动开口的能力都没有。举个生活化的例子。快递员服务器有包裹要送给你客户端但快递员不知道你家的门铃HTTP连接什么时候能响。HTTP的规则是快递员只能在有人按门铃、门打开的时候把包裹递过去。如果门一直不开快递员就算手里攥着包裹也只能等着。实时推送要解决的本质上就是怎么让门铃响得足够频繁或者干脆把门一直留着。这个门就是连接。有三种思路一是把门铃按得很勤短轮询每次问一句有包裹吗二是按一次门铃之后不松手快递员在门口等着包裹一到立刻递进去长轮询三是干脆不关门快递员直接站在门口有包裹随时给WebSocket、SSE。理解了这三句话后面所有优缺点、选型逻辑都能顺下来。1.1 请求-响应模型与主动推送的天然冲突先看HTTP协议本身的限制。一次普通HTTP请求从客户端发出到服务端返回走完就断了。哪怕用HTTP/1.1的keep-alive也只是让TCP连接复用减少重复握手开销但语义上仍然是一问一答。服务端眼瞅着有新数据也只能干等下一次请求来的时候在响应里把数据捎带回去。这就带来一个尴尬事实服务端能推送的唯一时机是客户端请求到来时。所以实时程度完全取决于客户端问得多勤快。这里有一个容易忽略的副作用推送消息没有请求没有响应但为了不错过消息客户端必须持续发送请求这些请求大部分时候是无效的。HTTP/1.1还有一个隐藏限制浏览器对同一域名的并发连接数有限制一般在6个左右。如果业务里图片、接口、日志等请求本来就不少再给实时推送占上几个长连接很容易把连接池挤爆页面加载都变慢。HTTP/2和HTTP/3虽然在这方面好很多但很多业务系统目前还是HTTP/1.1这个限制是现实存在的。1.2 三种方案的共性思路把等待放到哪里轮询、WebSocket、SSE这仨方案放在一起讨论是因为它们解决的是同一个问题服务端有了新数据怎么尽量及时地让客户端知道。区别在于等待放在哪里。短轮询等待放在客户端。客户端每隔几秒问一次服务端秒回。长轮询把等待放在服务端。客户端发一次请求服务端把请求挂住直到有新数据或者超时再返回。SSE服务端把连接敞开着有新数据就顺着这条连接往客户端写客户端被动接收。WebSocket双向的连接完全敞开着双方随时都可以发数据。理解了等待位置的差别很多特性就能推导出来。比如短轮询为什么实时性差、为什么费请求长轮询为什么能实现低延迟推送但服务器连接数压力大SSE为什么叫Server-Sent Events以及它和WebSocket体验上的差异在哪里。2. 轮询方案拆解短轮询、长轮询与真实成本2.1 短轮询实现最简单代价也最直接短轮询应该是很多前端同学接手实时数据需求时写的第一个方案。代码大概长这样setInterval(async () { const res await fetch(/api/notifications); const data await res.json(); // 处理新消息 renderMessages(data); }, 5000);每5秒拉一次逻辑简单到不需要任何额外依赖后端也只需要一个普通接口。这套方案的问题可以拿数字说话。假设有1000个在线用户每人5秒轮询一次每秒就是200个请求。单个请求再轻也扛不住这种规模。实际项目里我见过一个更夸张的之前某项目的消息通知用3秒轮询1500个活跃用户挂在那后端接口服务平时只有几十QPS轮询一开直接飙到500 QPS数据库和日志系统都受到了明显压力。而且轮询的方案实时性还不好保证。服务端可能在第1秒就有新数据了但客户端要等到下一轮第5秒的请求才能拿回来。极端情况下消息从产生到用户看到延迟接近一个轮询周期。还有一层容易被忽略的成本是带宽。HTTP请求每次都要带完整的请求头Cookie、User-Agent、各种自定义Header几百字节起步。如果每秒几百上千个请求光是请求头消耗的流量就很可观。移动端的流量套餐在这种方案下会掉得特别快。所以我对短轮询的态度很明确只在消息实时性要求低比如几秒延迟可以接受、并发量小、后端不想做任何额外工作的情况下才用。绝大多数后台管理系统里的轮询刷新就是典型场景——用户就那几十个人也没人盯着毫秒级延迟没必要为这个上长连接。2.2 长轮询用挂起绕过推送限制长轮询和短轮询只差一个细节服务器收到请求后不立即返回而是把请求挂住一直等到有新数据可返回或者等待超时比如30秒到60秒才返回结果。客户端收到响应后立刻发起下一次请求。前端代码反而更简单async function longPoll() { try { const res await fetch(/api/notifications/long); const data await res.json(); renderMessages(data); } catch (e) { // 超时或网络错误都走这里稍后重连 } finally { longPoll(); // 拿到响应后立刻重新发起请求 } } longPoll();后端的实现思路用Node.js的伪代码可以看得很清楚app.get(/api/notifications/long, async (req, res) { const timeout setTimeout(() { res.json({ state: timeout, messages: [] }); }, 45000); const messages await waitForNewMessages(); clearTimeout(timeout); res.json({ state: ok, messages }); });服务端hold住请求这段时间是不是白白占着一个线程这要看服务器模型。传统多线程模型比如早期J2EE风格一个请求占一个线程长轮询挂几万个请求就挂几万个线程内存和上下文切换开销巨大。而用事件驱动模型比如Node.js、Go挂起的请求不会阻塞线程成本主要就是一条TCP连接和一个内存里的等待任务。单从延迟角度看长轮询是能做到准实时的——数据一到请求马上返回消息立刻就推到客户端了。所以长轮询其实是WebSocket普及之前很多IM应用采用的推送方案包括不少早期网页版聊天工具。代价是一条请求从发出到返回整个生命周期里连接始终占用着。在HTTP/1.1下浏览器并发连接数有限长轮询占用的连接数会直接影响同域其他资源的加载。另外服务端需要管理大量挂起的请求超时时间、断线清理、消息顺序这些细节都要处理。2.3 轮询方案的工程代价与适用边界补充一点实际工作里的判断思路。轮询方案最大的优点是客户端和服务端之间完全是普通HTTP这意味着任何后端语言都能实现不需要额外协议支持穿越各种代理、网关、防火墙最省心鉴权、日志、监控等都复用既有HTTP中间件前端代码零学习成本。这四点意味着如果项目里不能上WebSocket或SSE比如受限的云环境、老旧的内部系统、第三方API网关不支持长连接长轮询仍然是很好的退路。很多消息推送SDK实际底层就是长轮询加短轮询混合策略。但在并发量真正大的场景里轮询方案无论长短都会碰到瓶颈。长轮询虽然没有无效请求的开销但连接挂起数量上来之后服务端需要为每条连接维护一个等待状态而且只要有新数据需要从等待列表里把对应请求挑出来惊扰一遍。用户量级到了几十万这里面的复杂度和资源成本会上涨得非常快。这就是为什么现在业务系统做实时消息第一选择已经很少是轮询了。轮询更多作为兜底策略存在而不是主力方案。3. WebSocket真正的全双工长连接3.1 握手升级与协议特点WebSocket和前面两种方案最大的区别是它彻底跳出了请求-响应的循环建立了一条真正的全双工TCP连接。客户端和服务端谁想发消息都可以直接发不需要等对方先开口。WebSocket连接建立过程是一次HTTP握手升级。客户端发一个带着Upgrade: websocket头的HTTP请求服务端返回101 Switching Protocols连接协议就从HTTP切换成了WebSocket。之后两边策马奔腾互不等待。GET /ws/notifications HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw Sec-WebSocket-Version: 13服务端返回HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk这个Sec-WebSocket-Key的验证过程本质上是让客户端确认我连的确实是个支持WebSocket的服务端防止代理缓存把旧HTTP响应返回给你。协议细节不用背但对前端来说理解一点就够握手完成之前走的是HTTP规则之后走的是WebSocket自己的帧格式。WebSocket帧头只有2字节未掩码时16进制的结构非常轻量。对比一下HTTP/1.1的请求光头部就有300-800字节即便用HTTP压缩头也远重得多。这意味着高频双向消息场景里WebSocket的带宽效率是碾压级的。它还支持二进制数据帧。图片、音频、二进制协议数据可以直接以二进制帧发过去不需要像HTTP那样非得用Base64编码再传。做在线文档协同、实时白板之类需要传二进制数据的场景这是实实在在的优势。3.2 前端的正确使用姿势浏览器端的WebSocket API很干净const ws new WebSocket(wss://example.com/ws/notifications); ws.onopen () { console.log(连接建立); // 连接建立后发送鉴权信息 ws.send(JSON.stringify({ type: auth, token })); }; ws.onmessage (event) { const data JSON.parse(event.data); handleNotification(data); }; ws.onclose (event) { console.log(连接关闭code:, event.code); // 触发重连 reconnectWithBackoff(); }; ws.onerror (error) { console.error(WebSocket错误, error); // 注意onerror后通常会跟着onclose };API简单坑都在使用策略上。最多的坑有三个。第一个是断线重连。WebSocket连接一旦断开不会自动恢复和后面的SSE不同需要自己实现重连逻辑。且不能简单粗暴地无脑重连否则服务端动荡时会引发重连风暴——几千个客户端同时断线同时重连瞬间把服务端压垮。正确的做法是带退避的延迟重连第一次断开等1秒第二次2秒第三次4秒最大30秒同时加一点随机抖动。let retryCount 0; const maxRetryTime 30000; async function reconnectWithBackoff() { const delay Math.min(1000 * 2 ** retryCount, maxRetryTime) Math.random() * 1000; retryCount; await sleep(delay); connectWebSocket(); }第二个是心跳保活。网络中的中间设备比如NAT网关、负载均衡器往往会清理长时间空闲的TCP连接。如果客户端30分钟内没发任何数据连接可能在服务端和客户端都不知道的情况下被静默杀掉。解决方法是约定一个Ping/Pong消息客户端每30秒或45秒发一个{type: ping}服务端回{type: pong}。如果在规定时间内没收到pong就主动断开重连。setInterval(() { if (ws.readyState WebSocket.OPEN) { ws.send(JSON.stringify({ type: ping })); } }, 30000);第三个是鉴权方式。HTTP有完善的Header承载鉴权信息但WebSocket握手请求能不能带自定义Header在浏览器里是受限的表头Sec-开头的由浏览器管控。常见做法是把token放进query参数wss://example.com/ws?tokenxxx。弊端是token会出现在日志、代理记录里有效期必须设短一点或者握手成功后立刻换发一个短期有效的新token。3.3 WebSocket在实际项目中的隐藏门槛前端的坑填完还得看到服务端那一侧的门槛。这也是很多项目放弃WebSocket的真实原因。WebSocket是长连接连接建立后请求就不走普通的HTTP请求处理链了。服务端所有节点必须能感知到所有连接。假如你的服务是水平扩展的客户端A连在节点1上客户端B连在节点2上A想给B发消息节点1必须通过某种方式把消息转发到节点2才能推给B。这就需要一个消息路由层或者推送网关。同时连接状态是有状态的。服务端挂了连接就没了客户端的离线消息能不能接住又涉及消息持久化的问题。这些都不是加个库能解决的需要架构上的设计。代理层也会带来麻烦。Nginx默认不识别WebSocket升级协议需要额外配置location /ws/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; }那个proxy_read_timeout如果忘改默认60秒空闲连接就会被Nginx默默掐断。很多前端排查WebSocket一会儿就断查到最后发现根本不是代码问题是代理层的超时配置。另外WebSocket服务端的实现水平参差不齐有的库在空闲内存控制、心跳管理、数据帧碎片处理上做得不够好连接一多就出现内存泄漏或者CPU飙高。选型的时候不能光看能打通要看它是不是在生产级项目里被长期使用过。4. SSE被低估的服务器单向推送利器4.1 EventSource API的基本用法SSEServer-Sent Events在WebSocket的光环下一直是个被低估的方案。它本质上就是HTTP长连接服务端按约定格式text/event-stream把数据持续写给客户端。浏览器原生支持连SDK都不需要。前端代码极其简单const eventSource new EventSource(/api/stream); eventSource.onmessage (event) { console.log(收到消息:, event.data); }; eventSource.addEventListener(custom-event, (event) { console.log(收到自定义事件:, event.data); }); eventSource.onerror (event) { console.log(连接出错EventSource会自动重连); };后端的实现Node.js里大概这样app.get(/api/stream, (req, res) { res.writeHead(200, { Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive, }); const sendEvent (data) { res.write(data: ${JSON.stringify(data)}\n\n); }; const timer setInterval(() { sendEvent({ time: Date.now() }); }, 5000); req.on(close, () { clearInterval(timer); }); });关键在数据格式每一条消息以data:开头结束标志是双换行符\n\n。如果消息里要传多行文本可以用多个data:行拼接。服务端还能通过event:字段指定事件类型客户端用addEventListener监听对应类型相当于在一条连接上区分不同频道这个非常实用。最让我惊喜的是它的自动重连是原生行为。连接断开后浏览器会自动重新发起请求不需要写一行重连代码。而且服务端可以发送id:字段浏览器重连时会把Last-Event-ID带到请求头里服务端据此判断上次发到哪条了实现断点续传。GET /api/stream HTTP/1.1 Host: example.com Last-Event-ID: 1024这个机制让SSE在弱网环境下的表现比WebSocket从容不少。4.2 SSE与WebSocket的真实差异很多人一听单向推送就摇头觉得肯定不如WebSocket。但业务场景里服务端给客户端推消息其实已经覆盖了绝大多数需求。下方表格可以直观看到差异对比维度SSEWebSocket协议基于HTTP普通请求升级独立的协议需握手升级通信方向服务端到客户端单向全双工双向数据格式纯文本流按约定格式文本帧、二进制帧自动重连原生支持且支持断点续传需要自己实现二进制数据不直接支持原生支持浏览器兼容性主流现代浏览器均支持主流现代浏览器均支持服务端实现难度极低普通HTTP接口即可需要支持WebSocket协议的服务端代理穿透容易就是HTTP长连接需要额外配置Upgrade和超时鉴权复用HTTP的Header、Cookie机制鉴权不便一般靠query参数SSE不能从客户端往服务端发数据这个说法需要更精确地理解。浏览器这个EventSource对象确实只有接收功能但你的应用完全可以另外用普通fetch/POST请求给服务端发信息。所以单向限制的是同一条连接上的方向不是整个应用的通信能力。另外SSE发的是文本流。如果你的业务主要传JSON字符串这个限制完全不是问题。要说真有限制是它不能当作数据传输通道来传视频帧、文件块这类二进制数据那就得老老实实上WebSocket。4.3 SSE适合哪些业务我在实际项目里用SSE最多的场景有三类。第一类是AI对话式的流式返回。大模型生成结果是逐字流式输出的通过SSE一条一条把token推到前端就是现在很多聊天机器人的打字机效果实现方式。第二类是行情和状态实时刷新。比如股票价格、在线人数、后台任务进度。这类数据量不大、更新频率高、但不需要客户端上传任何东西SSE的轻量特质非常合适。第三类是服务端通知广播。比如系统公告、订单状态变化、用户收到新消息推送是主要诉求偶尔需要回执确认SSE加上POST配合也完全能搞定。之前在一个模拟项目X里我用SSE做过一个后台任务看板。任务执行进度、日志流、结果汇总都用SSE一条条推到前端后端只需要一个写日志时顺便往流里写一行的函数整套方案比引入消息队列、WebSocket网关轻了不止一个量级。生产环境跑了很久非常稳定。5. 从浏览器、服务器、业务三个维度做选择5.1 关键对比表格三种方案的完整对比合并在一张表里方便收藏维度短轮询长轮询SSEWebSocket实时性差有轮询间隔延迟好请求挂住等待好连接常驻最好双工即时服务端压力高大量无效请求中大量挂起连接低低但需高并发连接管理客户端开销高频繁请求中低浏览器维护连接低但需自己处理重连逻辑二进制支持支持任意数据支持任意数据不支持仅文本支持二进制帧自动重连天然每次请求独立需手动处理浏览器原生支持需自行实现实现难度最低中低高典型场景后台页面低频刷新兼容性优先的准实时推送服务端推送通知、流式数据聊天、协同、高频双向通信5.2 决策思路先问这四个问题选型的时候与其找一张万能对照表不如按下面的问题顺序自查一遍。第一问客户端需要实时给服务端发消息吗如果只是服务端推数据给客户端别急着上WebSocket。聊天室、实时游戏、白板协同这类强交互场景才真正需要全双工。第二问数据格式里有二进制吗如果只是JSON文本SSE够用。要传图片流、音频流、视频流之类的直接选WebSocket。第三问服务端有没有能力维护大量长连接如果没有专门的推送服务设计SSE和长轮询是更现实的选择至少它们对服务端的要求是普通HTTP 事件循环而不是一套独立的协议支撑系统。第四问要不要考虑兼容性极端的Web环境某些企业内部浏览器、特定WebView对EventSource支持可能存在问题或者网络环境不允许长连接这时候最保险的还是长轮询。实际项目里我通常建议能用SSE就不上WebSocket能用长轮询就不上SSE。不是说WebSocket不好而是它解决的是双向高频低延迟二进制的组合问题如果你的需求没有到这个强度引入它带来的服务端架构复杂度是纯增量。5.3 真实业务中的组合拳与兜底策略一个常见的选型错误是全站WebSocket。整个站点所有实时需求都用WebSocket实现导致服务端复杂度暴涨前端还要处理大量无关消息。更好的思路是按需拆层。举个例子。某个社交类Web应用消息列表要实时更新聊天窗口也有实时通信需求。我的方案是全局通知、系统广播、消息列表刷新——SSE走全部代码量极小服务端维护一条HTTP连接即可。聊天对话——WebSocket单独做只给聊天模块用协议、心跳、重连都围绕这一个场景设计。极低优先级的页面比如后台报表刷新——长轮询甚至短轮询反正本身就不需要秒级时效性。同时准备兜底策略。SSE连接的onerror触发时记录一下重试次数如果连续多次失败自动降级为长轮询。这个降级逻辑不用写得很复杂几行代码的事情let sseFailedCount 0; const eventSource new EventSource(/api/stream); eventSource.onerror () { sseFailedCount; if (sseFailedCount 3) { eventSource.close(); switchToLongPolling(); } }; eventSource.onmessage () { sseFailedCount 0; };5.4 一个偏架构的劝告别忽略业务形态本身做推送选型时最容易犯的错不是技术选错了而是为了实时而实时。很多业务根本没有实时需求比如用户角色权限变了要立刻反映到前端这种场景完全可以等下一次刷新或者操作时顺便拉取最新数据。把实时推送铺到每一个角落只会让系统的复杂度和故障率同时上升。我的经验是在给某个业务加推送能力之前先问一问产品同学这个实时性是不是必要的是不是用户感知不到几秒的延迟。所谓选型最终还是围绕需求该用多贵的方案去满足这个朴素问题展开。6. 实战中的坑与总结6.1 三个每次都见得到的坑长连接场景的实战坑几乎是可以预判的我把自己踩过的、或者看别人踩过的问题集中列一下。第一个移动端锁屏后连接时不时就断。手机系统的省电策略会在锁屏或应用进入后台后主动断开空闲网络连接。表现为锁屏一段时间再解锁所有长连接都处在半死状态——连接还在但消息已经不推了。解决方案是在visibilitychange事件里重新检查连接状态document.addEventListener(visibilitychange, () { if (document.visibilityState visible) { if (ws ws.readyState ! WebSocket.OPEN) { reconnect(); } if (eventSource eventSource.readyState EventSource.CLOSED) { reconnectSSE(); } } });主动检查比被动等onerror触发更及时用户解锁页面时基本能瞬间看到最新数据。第二个服务端重启或者发布时瞬间大量断线。WebSocket和SSE都是常驻连接服务端一重启连接全灭。如果几百个客户端同时尝试重连服务端刚起来就又被流量打懵。这个只能用退避策略缓解同时可以考虑在服务端发布流程中增加集群分批重启连接迁移机制让服务端主动给客户端推一个请延迟重连的信号。前端能做的是把断线分类服务端正常关闭code 1000/1001和异常关闭code 1006等走力度不同的重连策略。第三个心跳参数的设定。心跳发得太频繁带宽有压力间隔太长又容易被中间设备清理。我一般把心跳定为30秒到60秒之间。但要注意如果服务端本身就有空闲连接超时比如上面提到的Nginxproxy_read_timeout那么前端心跳间隔必须小于这个超时时间否则还是会断。实际操作中我习惯把心跳间隔设置为服务端空闲超时的一半比如Nginx配了120秒前端就每60秒发一次心跳。6.2 指标衡量怎么知道当前方案是否合格最后想说一下怎么量化评估推送方案的效果。上线前可以先定几个核心指标灰度一段时间再回看指标说明健康值参考连接数当前活跃长连接数量需与在线用户数基本匹配连接掉线率每段周期内异常断线次数/连接数低于5%且分布均匀消息推送延迟服务端消息产生到客户端接收到的时间差常规业务小于1秒无效请求率轮询/长轮询中无新数据返回的请求占比短轮询会偏高可接受即可服务端资源占用CPU、内存、连接数趋势随在线用户数线性增长且无泄漏有的团队上线了WebSocket结果只关注连接能不能建立完全不管掉线率和消息延迟出了问题也定位不到。建议从一开始就把这些指标接进监控系统长连接涉及的环节多出了问题没有指标很难缩小范围。6.3 我的选择经验做了这么多年前端聊消息推送的技术方案时我的核心体会是四个字够用就好。真实业务里纯WebSocket的占比其实远没有技术文章渲染的那么高SSE在大量推送场景里是一个性价比非常高的选择而长轮询在兼容受限的环境里永远值得留一手。选型时先想清楚业务是哪种形态再决定采用什么方案最后为每种方案准备好兜底和降级逻辑这个思路比追逐最先进的技术稳妥得多。前端实时消息推送这块没有一种方案是万能的。把三种方案各自的成本和适用边界摸清楚遇到具体业务场景时判断起来就快很多。这也是我希望这篇内容能帮你解决的核心问题。

前端实时推送技术解析：轮询、SSE与WebSocket对比选型

相关推荐

Poly-YOLO深度解析：重构YOLOv3，mAP提升40%的轻量实例分割方案

SRGAN图像超分重建Python实践：从网络结构到训练避坑指南

ASP.NET C# SqlServer打造数据库驱动轮播图，动态加载告别改代码

更多资讯

自托管PS5聚合面板AnyPS5：统一管理状态、折扣、截图与奖杯

阿里云国际站云服务器费用怎么算？企业预算规划指南

JupyterLab 4.5环境部署与性能优化指南

线性表实战：图书管理系统中的性能陷阱与工业级优化

如何看待河北大学博士论文被举报AI生成？科研人该如何安全使用AI？

在职大龄考生高效通过法考的系统方法论

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？