服务器推送技术主要有短轮询、长轮询、WebSocket、SSE，以及MQTT over WebSocket、WebTransport等补充方案；选型时先看消息是单向还是双向，再看连接规模、客户端环境和运维成本。 如果你正在做实时通知、聊天、行情或协同编辑，下面这套技术谱系和落地细节可以直接拿去对照。
服务器推送技术有哪些？先把技术谱系摊开
服务器推送的本质,是服务器在消息产生后主动把数据送到客户端，而不是等客户端每次来问，业内常把它分成“轮询家族”和“长连接家族”，再把长连接家族按协议拆开。
按连接保持方式分四类
- 短轮询：客户端每隔几秒发一次HTTP请求，服务器有数据就返回，没有就返回空，实现最简单，缺点是延迟取决于轮询间隔，空请求多。
- 长轮询：客户端发请求后，服务器先挂起，等有数据或超时才返回，Comet时代常用，兼容老浏览器，但每个连接都占资源，高并发下连接管理压力大。
- WebSocket：一次HTTP握手升级到101 Switching Protocols，之后全双工通信，据IETF RFC 6455定义，它适合聊天、协同编辑、实时行情这类双向高频场景。
- SSE：Server-Sent Events，基于HTTP的text/event-stream，只做服务器到客户端的单向推送，据WHATWG HTML标准，浏览器EventSource自带断线重连，还支持Last-Event-ID做消息续传。
还有哪些“偏门但有用”的推送通道
- HTTP/2 Server Push：它推送的是静态资源，不是业务消息，近年来主流浏览器已陆续移除支持，新项目不要把它当实时消息方案。
- MQTT over WebSocket：IoT和弱网场景常见，浏览器通过WebSocket连MQTT Broker，走发布订阅模型，需要额外维护Broker。
- WebTransport：基于HTTP/3，支持双向流，适合低延迟场景，但浏览器兼容性和网关支持要实测。
- gRPC streaming：多用于服务间流式通信，浏览器端直接使用门槛较高。
- Socket.IO、SignalR：它们是库或框架，不是协议，内部会封装WebSocket、SSE、长轮询降级逻辑。
| 技术 | 通信方向 | 底层协议 | 实时性 | 兼容与运维注意点 | 典型场景 |
|---|---|---|---|---|---|
| 短轮询 | 客户端拉 | HTTP | 取决于间隔 | 实现简单，空请求多 | 低频状态刷新 |
| 长轮询 | 客户端拉，服务器hold | HTTP | 中等 | 连接占用高，代理超时要配 | 老系统兼容 |
| WebSocket | 双向 | HTTP Upgrade | 高 | 代理要支持Upgrade，需自己做重连 | 聊天、协同、行情 |
| SSE | 服务器到客户端单向 | HTTP | 高 | 注意缓冲、连接数限制 | 通知、日志、进度 |
| MQTT over WS | 双向发布订阅 | WebSocket承载MQTT | 高 | 要维护Broker和主题权限 | IoT、弱网设备 |
服务器推送和轮询有什么区别？一张表看懂
短轮询和长轮询常被叫“假推送”，因为请求始终由客户端发起，区别不在名字，而在连接是否被挂起、空请求有多少、代理层会不会提前掐断。
短轮询和长轮询不是“假推送”吗
是客户端拉取模型,短轮询按固定间隔问，长轮询让服务器把请求按住，长轮询减少了空响应次数，但服务器要同时维护大量挂起连接，你如果在Nginx后面做长轮询，记得把proxy_read_timeout调大，否则代理会先断。
实时性与资源消耗怎么权衡
- 消息频率低、能容忍几十秒延迟：短轮询够用。
- 消息频率中等、需要较快到达：长轮询或SSE。
- 高频双向交互：WebSocket。
- 单向通知且客户端是浏览器：优先评估SSE。
| 对比项 | 短轮询 | 长轮询 | SSE | WebSocket |
|---|---|---|---|---|
| 请求次数 | 多 | 中等 | 一次连接长期保持 | 一次握手长期保持 |
| 延迟 | 取决于间隔 | 较低 | 低 | 低 |
| 双向通信 | 否 | 否 | 否 | 是 |
| 断线重连 | 客户端自己控制 | 客户端自己控制 | EventSource自动重连 | 业务层自己实现 |
| 代理兼容 | 好 | 需调超时 | 需关闭缓冲 | 需支持Upgrade |
WebSocket和SSE哪个更适合实时消息推送？
先别比较库的流行度,先看消息模型，单向通知和双向交互是两条路，行业共识认为，单向通知优先SSE，双向交互优先WebSocket。
先看“单向还是双向”
- 服务器只发通知、日志、任务进度、股价更新：SSE更轻，走现有HTTP鉴权、日志和网关。
- 客户端也要频繁发消息,比如聊天、协作光标、游戏指令：WebSocket更合适。
再看“运维和网络中间件”
SSE在HTTP/1.1下会受浏览器同域连接数限制，常见是6个左右；多标签页同时开SSE容易占满，HTTP/2多路复用可以缓解，但网关要正确配置，WebSocket需要代理支持Upgrade头，云负载均衡的空闲超时要大于心跳间隔。
实操：SSE最小验证路径
Nginx关键配置项：
location /events {
proxy_pass http://127.0.0.1:8080;
proxy_buffering off;
proxy_cache off;
proxy_read_timeout 3600s;
add_header X-Accel-Buffering no;
}
浏览器侧：
const es = new EventSource('/events');
es.onmessage = (e) => console.log(e.data);
命令行验证：
curl -N -H "Accept: text/event-stream" http://localhost:8080/events
如果返回被缓冲,先检查proxy_buffering off和X-Accel-Buffering no是否生效。
实操：WebSocket握手验证
curl -i -N \ -H "Connection: Upgrade" \ -H "Upgrade: websocket" \ -H "Sec-WebSocket-Version: 13" \ -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \ http://localhost:8080/ws
返回101 Switching Protocols才说明升级成功，线上还要检查负载均衡是否透传Upgrade头。
服务器推送技术方案价格大概多少？别只看软件授权
价格差异通常不在“协议”本身，而在连接规模、消息频率、是否需要商业网关和国内多地域接入，开源方案软件授权为零，但人力、带宽、压测和运维都要算进去。
成本构成拆开看
- 软件授权：开源WebSocket库、SSE服务端通常免费；商业消息网关按连接数或实例收费。
- 服务器与带宽：长连接吃内存和文件描述符，出口流量按消息大小和频率增长。
- 运维投入：监控连接数、重连率、消息延迟，做压测和扩容。
- 安全合规：TLS证书、鉴权、日志脱敏、审计留存。
| 成本项 | 开源自建 | 云服务/商业网关 | 询价时要问清 |
|---|---|---|---|
| 软件费用 | 低 | 按连接数/消息量计费 | 是否独享实例 |
| 带宽 | 自付 | 常含在套餐 | 超额怎么计费 |
| 运维 | 自己承担 | 厂商分担 | SLA和故障响应 |
| 扩容 | 手动加机器 | 控制台调整 | 单实例连接上限 |
小规模项目常见做法是单机Nginx加SSE或WebSocket,主要花开发人力，连接规模上来后，预算会明显转向带宽、压测和商业网关，询价时把峰值连接数、消息频率、消息大小、是否需要双向、是否要国内多地域接入列清楚，比只问“多少钱一年”有效。
国内服务器推送技术服务怎么选？看这三个硬指标
国内选型不只看协议支持,还要看合规、网络覆盖和可观测性，业内专家指出，长连接系统的瓶颈往往不在协议，而在连接状态管理和出口带宽。
合规与数据落地
- 确认数据存储和传输是否符合数据安全法、个人信息保护法及等保要求。
- 日志脱敏,鉴权token不要长期放在URL里。
- TLS要覆盖全链路,网关到后端也别裸奔。
网络覆盖与弱网优化
- 是否支持国内多地域接入和BGP线路。
- 心跳间隔要小于负载均衡空闲超时。
- 移动端后台挂起后,重连要能补消息，不能只重连不补偿。
可观测性与压测
- 看连接数、消息延迟P99、重连率、错误率四个指标。
- 压测前先查ulimit -n和sysctl net.core.somaxconn，文件描述符不够会直接限制连接数。
- 用k6的WebSocket模块或自写脚本压测,重点看内存增长和断线后的恢复行为。
落地时容易踩的坑：推送不是连上就完事
鉴权与Token刷新
EventSource标准不支持自定义请求头,所以SSE常用同域Cookie或短时token放URL，token放URL要确保日志脱敏，WebSocket可以在握手URL带token，也可以连上后首帧发认证消息，重连时换新token，别把过期token一直重试。
断线重连与消息补偿
SSE自带重连,并会带Last-Event-ID，服务端可以按事件ID补发，WebSocket要自己做指数退避重连，业务层用消息游标或ack做补偿，只重连不补消息，用户会看到“跳消息”。
代理超时与连接数
Nginx的proxy_read_timeout、云负载均衡的空闲超时都要大于心跳间隔，浏览器HTTP/1.1同域连接数通常只有6个，多个SSE标签页会互相挤占，能用HTTP/2就用HTTP/2，或者把SSE连接收敛到SharedWorker里共享。
选型先画消息模型,再算连接规模和运维边界，协议没有绝对高低，能把重连、补偿、鉴权和压测做扎实的方案，才是能上线的方案。
服务器推送技术常见问题Q&A
服务器推送技术有哪些常见选型误区？
常见误区有四个：所有场景都上WebSocket；忽略代理超时和缓冲；只做重连不做消息补偿；把HTTP/2 Server Push当成业务消息推送，前者会增加双向通道的运维成本，后三者会在线上表现为断连、延迟和消息丢失。
服务器推送技术一定要用WebSocket吗？
不一定,单向通知、日志流、任务进度用SSE更轻，能复用HTTP鉴权和日志链路，低频状态刷新用短轮询就够，只有高频双向交互才需要WebSocket，选型看消息模型，不看技术热度。
服务器推送技术在国内做合规要注意什么？
和传输安全：TLS全链路、鉴权token短时化、日志脱敏、数据落地符合国内法规要求，截至公开标准，SSE由WHATWG维护，WebSocket由IETF RFC 6455定义，二者都不规定业务层消息补偿和合规策略。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/782835.html
