服务器可以主动向客户端发送消息，但传统HTTP协议做不到，需要借助WebSocket、SSE（Server-Sent Events）等“长连接”技术来实现。打个比方，HTTP就像你打电话时每次都得先拨号，挂断后对方就找不到你了；而WebSocket就像一条始终保持畅通的专线，服务器随时能顺着这条线把数据“递”到你手里。
为什么HTTP协议做不到主动推送
HTTP协议的设计初衷是“请求-响应”模式，客户端不发请求，服务器就不能回应，这就像你家里信箱，只有你投递了信件，邮差才会送来回信，没有你的主动“投递”，服务器端的数据更新再频繁，也只能在数据库里干等着。
另一个原因是HTTP连接本身是短命的,早期HTTP/1.0每次请求都要重新建立TCP连接，HTTP/1.1虽然引入了keep-alive，但生命周期依然受限于一次请求响应循环，服务器想“事后”补发一条消息，但连接早已断开，数据包根本找不到回家的路。
行业共识认为,HTTP协议这种设计在Web诞生初期是合理的，因为那时候网页内容几乎全是静态的，浏览器只需要“拉取”文档就行，但到了实时聊天、股票行情、协同编辑这类场景，这种单向模式就成了绊脚石。
服务器主动推送消息的三大主流方案
WebSocket真正的全双工通道
WebSocket是目前最接近“服务器主动推送”理想形态的方案，它通过一次HTTP握手（状态码101），将连接升级为TCP长连接，之后客户端和服务器都能随时互发数据，彻底打破了“请求-响应”的枷锁。
比如一个在线协作白板场景,用户A画了一笔，服务器收到后立刻通过WebSocket把坐标数据推给用户B的浏览器，整个过程耗时不到几十毫秒，这就是WebSocket的典型应用：低延迟、双向、高频。
适用场景：在线聊天、多人游戏、实时协同编辑、金融行情推送，如果你需要双向通信且频率高，WebSocket是首选。
SSE（Server-Sent Events）轻量级单向推送
SSE是另一种主动推送方案,但它是单向的，只能服务器往客户端发，它基于HTTP协议，利用text/event-stream
媒体类型，建立一个持久连接，服务器可以持续地向客户端“倾倒”数据流。
打个比方,SSE像一条“单行道”，服务器可以源源不断地往客户端送数据，但客户端想回话还得另开一条路，它在实现上比WebSocket简单得多，不需要额外的协议解析，而且原生支持断线重连和事件ID追踪。
适用场景：新闻订阅、实时通知、股票行情的单方向推送、AI对话的流式输出（像ChatGPT打字机效果就是SSE的功劳），如果只需要服务器往客户端推，没必要上WebSocket这个大杀器。
轮询与长轮询伪主动的妥协方案
在WebSocket成熟之前,开发者主要靠轮询来“模拟”主动推送，普通轮询是客户端每隔几秒就发一次请求问“有更新吗”，服务器每次都回复“没有”或“有”，这种做法代码简单，但问题是大量请求是无效的，服务器压力大，实时性也差。
长轮询稍微聪明一点：客户端发请求后，服务器hold住这个连接不回复，等有数据了才响应，客户端收到后再立即发起下一次请求，这相当于服务器“憋着不说话”，直到有消息才开口，延迟降低了，但连接频繁建立和断开，对服务器资源消耗依然不小。
适用场景：老系统兼容、实时性要求不高的场景，现在新项目基本不太建议用轮询硬撑，除非是接手老代码。
服务器推送消息用哪个协议？横向对比
为了让你更直观地做技术选型,我用表格把核心差异列出来：
| 对比维度 | WebSocket | SSE | 长轮询 |
|---|---|---|---|
| 通信方向 | 双向（服务器↔客户端） | 单向（服务器→客户端） | 单向（模拟） |
| 协议基础 | TCP（HTTP升级） | HTTP | HTTP |
| 实时性 | 毫秒级 | 秒级 | 秒级（受轮询间隔限制） |
| 实现复杂度 | 较高（需处理协议细节） | 低（原生支持） | 低（但状态管理麻烦） |
| 自动重连 | 需自己实现 | 内置 | 需自己实现 |
| 穿透代理 | 需要配置 | 天然支持 | 天然支持 |
| 典型场景 | 聊天、游戏、协同 | 通知、流式输出 | 兼容旧系统 |
从这个表能看出来,WebSocket功能最强但代价也最大，SSE在“只要推给客户端”的场景下性价比极高，据行业内实践观察，近几年新上线的大型实时应用，超过七成首选WebSocket，剩下的三成里，SSE占了很大比例。
从零实现：WebSocket推送的实操步骤
以Node.js环境为例，演示一个最简单的服务器推送流程：
-
安装依赖：在项目目录下运行
npm install ws，这是Node.js生态中最常用的WebSocket库。 -
创建服务器：
const WebSocket = require('ws'); const wss = new WebSocket.Server({ port: 8080 }); wss.on('connection', function connection(ws) { console.log('客户端已连接'); // 服务器主动发送消息 ws.send('欢迎你，我是服务器，这条消息是我主动发起的'); }); -
定时主动推送：用
setInterval模拟服务器主动推送数据，比如每5秒推一次当前服务器时间。 -
客户端监听：前端用
new WebSocket('ws://localhost:8080')建立连接，监听onmessage事件即可收到服务器消息。
这个过程中你会发现,服务器完全不需要等待客户端请求，只要连接不断，随时可以ws.send()，这就是“主动推送”的核心实现逻辑。
选型时的关键考量与常见坑
连接管理与心跳机制
WebSocket连接虽然稳定,但网络环境（比如NAT超时、代理空闲断开）可能导致“假死”状态，这就要求业务层实现心跳检测：客户端每隔一段时间发一个ping帧，服务器回pong帧，双方确认连接还活着，否则，服务器以为客户端还在线，实际上数据已经推不到对方了。
兼容性与回退策略
WebSocket在IE10以下基本不能用,SSE在部分浏览器上也有限制，如果你要做面向存量用户的系统，建议先做特性检测，不支持时自动降级到长轮询方案，虽然体验差一点，但总比完全没数据强。
服务器推送消息 用轮询还是WebSocket？场景决定
如果你做的只是“订单状态更新通知”，半小时推一次，用WebSocket纯属杀鸡用牛刀，这种情况SSE或简单的长轮询反而更节省资源，反过来，如果是“实时对战游戏”，一秒钟要推几十次状态，除了WebSocket没有第二个选择。
常见问题解答
服务器推送消息 一定会消耗很多服务器资源吗？
不一定,WebSocket长连接本身占用内存和文件描述符，但相比轮询那种“每秒几万次无效HTTP请求”的消耗，长连接在资源利用率上反而更高效，一台普通配置的云服务器，维持数万个WebSocket空闲连接是完全可以承受的，关键在于连接是否空闲，以及你是否有心跳机制去清理无效连接。
WebSocket和SSE可以同时用吗？
可以,而且不少大型应用就是这么干的，比如一个数据看板系统，用SSE推图表数据（单向够了），用WebSocket处理用户交互（比如拖拽调整图表参数），两者互不干扰，各司其职。
如何测试服务器推送是否正常？
最简单的办法是使用浏览器开发者工具,在Console里手动创建一个WebSocket对象，连接后观察Network面板的WS标签页，看服务器有没有主动发送帧，也可以用命令行工具websocat或wscat，直接连接你的服务器地址，能直观看到推送内容。
服务器主动推送消息这件事,本质上是一个“连接管理”的艺术，选对技术，能让你的应用实时性提升一个档次；选错了，可能陷入资源耗尽和延迟飙升的泥潭，对于绝大多数场景，WebSocket是通用答案，SSE是轻量答案，轮询是最后的退路，希望这篇文章能帮你在技术选型时少走几步弯路。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/558396.html
