服务器主动向客户端发消息，核心是通过WebSocket、SSE或长轮询等推送技术，实现服务端实时下发数据，无需客户端反复请求。 本文梳理了各类推送方案的实现逻辑、选型要点和成本考量，帮助你快速找到适合自己场景的消息推送路径。
为什么需要服务器主动推送：传统轮询的痛点
在Web早期,客户端想获取最新数据只能靠轮询每隔几秒发一次请求问服务器“有新消息吗”，这种模式在简单场景下能用，但请求量大、延迟高、带宽浪费明显。
轮询的三种常见形态
- 短轮询：客户端定时发送HTTP GET请求，服务器立即返回响应（有或无新数据），每次请求都携带完整HTTP头，高频率下服务器压力大。
- 长轮询：客户端发请求后，服务器保持连接打开，直到有新数据或超时才返回，请求次数减少，但连接长时间占用，对反向代理配置有要求。
- iframe流：利用隐藏的iframe持续加载，服务器不断写入数据，这种方式兼容性好，但浏览器标签页会显示“加载中”，用户体验差。
轮询的根本问题是“客户端主动，服务端被动”，服务器无法在数据产生瞬间直接推送，而服务器主动推送技术让服务端拥有主动权，数据实时性大幅提升。
主流服务器主动推送方案对比
目前实现服务器主动向客户端发消息的技术主要有三种：WebSocket、Server-Sent Events（SSE）和长轮询（作为降级方案），它们各有侧重，适合不同场景。
WebSocket：全双工通信的王者
WebSocket是HTML5标准定义的协议,通过一次HTTP升级握手后，建立持久化的TCP连接，客户端和服务端可以随时互相发送数据，它适合需要双向通信的场景，比如在线聊天、协作编辑、实时游戏。
优点：实时性最高，双向通信，协议开销小（相比HTTP轮询）。
缺点：需要服务器和客户端都支持WebSocket协议；反向代理（如Nginx）需额外配置；连接保持需要心跳机制。
Server-Sent Events（SSE）：单向推送的轻量选择
SSE是HTML5的另一个特性,客户端通过EventSource接口订阅服务器事件流，服务器端以文本流形式持续发送数据，客户端自动接收，SSE只支持服务器向客户端推送，客户端不能通过同一连接发送数据（但可以额外发HTTP请求）。
优点：基于HTTP协议，不需额外升级；内置断线重连；浏览器原生支持；服务器实现简单。
缺点：只支持单向推送；不支持二进制数据（但可以发送文本）；最大并发连接数限制（浏览器通常限制每个域名6个连接）。
长轮询：兼容性最强的降级方案
长轮询本质上仍是HTTP请求,但服务器端不立即返回，而是挂起请求直到有新数据，它兼容所有浏览器和HTTP库，适合作为不支持WebSocket/SSE时的备选方案。
优点：兼容性极好，不需特殊协议，防火墙友好。
缺点：消息延迟受限于请求超时设置；服务器端需要处理大量挂起连接；比WebSocket占用更多资源。
三种方案横向对比
| 特性 | WebSocket | SSE | 长轮询 |
|---|---|---|---|
| 通信方向 | 双向 | 服务器→客户端 | 客户端→服务器（轮询） |
| 协议 | 独立协议（ws/wss） | HTTP | HTTP |
| 浏览器支持 | 所有现代浏览器 | 大多数现代浏览器 | 所有浏览器 |
| 实时性 | 极高 | 高 | 中等（取决于轮询间隔） |
| 资源消耗 | 低（连接持久） | 低（HTTP长连接） | 高（频繁请求/挂起） |
| 断线重连 | 需自行实现 | 内置 | 需自行实现 |
| 服务端复杂度 | 中 | 低 | 高（需管理挂起连接） |
如何根据场景选择推送方案
选型不是单纯比技术优劣,而是看业务场景、团队技术栈和基础设施成本，以下三个维度帮你做决策。
实时聊天与协同编辑
这类场景要求双向通信,用户既收消息也发消息，WebSocket是唯一合理选择，SSE无法满足上行需求，长轮询延迟不可接受，很多在线文档和即时通讯工具都采用WebSocket，并配合消息队列处理高并发。
消息通知与数据监控
如果只需要服务器推送消息到客户端（比如通知、股票行情、系统日志），SSE是最轻量的方案，它不需要额外库，简短的JS代码就能实现，对于实时性要求稍低的通知，也可以先用SSE，未来如果需要双向通信再升级到WebSocket。
考虑成本与地域因素
服务器推送技术成本主要体现在带宽和服务器资源上，WebSocket连接持久，单个连接占用内存小，但长时间保持带内连接会消耗TCP资源，SSE基于HTTP，每个连接也是持久占用，但实现简单，维护成本低，长轮询虽然请求数多，但连接时间短，适合短期内大量轻量推送。
地域因素在国内云服务器和海外服务器之间也有差异，国内运营商对HTTP长连接的支持普遍较好，但WebSocket的升级请求有时会被防火墙干扰，如果目标用户集中在海外，WebSocket的兼容性更好，对于国内服务器主动推送场景，不少团队选择SSE作为主要方案，因为HTTP协议兼容性高，运维团队更容易排查问题，如果用户群体跨地域，建议在WebSocket和SSE之间做自动降级，优先使用WebSocket，不支持时回退到SSE或长轮询。
从零搭建WebSocket推送服务：实操步骤
以下以Node.js为例，演示如何建立简单的WebSocket服务器，并让客户端接收主动推送。
环境准备
- 安装Node.js（推荐LTS版本）
- 使用npm安装ws库（
npm install ws） - 一台可运行Node.js的服务器（国内主流云服务商均支持）
服务端实现
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', function connection(ws) {
console.log('新客户端连接');
// 每5秒主动推送一条消息
const interval = setInterval(() => {
ws.send('服务器时间：' + new Date().toISOString());
}, 5000);
ws.on('close', () => {
clearInterval(interval);
});
});
客户端连接
const ws = new WebSocket('ws://你的服务器IP:8080');
ws.onmessage = function(event) {
console.log('收到消息：', event.data);
};
将以上代码部署后,打开浏览器控制台即可看到实时推送的时间戳。
生产环境配置：Nginx反向代理
WebSocket连接需要Nginx正确转发Upgrade头,否则连接会失败，在站点配置文件中添加：
location /ws/ {
proxy_pass http://websocket_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
建议设置心跳超时,避免僵尸连接占用资源。
推送服务常见问题与优化
连接稳定性：断线重连与心跳
WebSocket和SSE都可能因网络波动断开,客户端应实现重连逻辑，最好带指数退避，服务器端需要定期发送心跳包（ping/pong），清理超时连接。
安全性：WSS与身份验证
WebSocket使用ws://是明文传输，线上必须升级为wss://（WebSocket over TLS），SSE同样建议使用HTTPS，在连接建立时，可以通过token验证身份，避免未授权访问。
性能调优：连接上限与消息队列
单台服务器能承载的WebSocket连接数受限于操作系统（端口数、内存、CPU），对于超过几千并发的场景，建议使用消息队列（如Redis Pub/Sub）解耦业务逻辑和推送服务，通过水平扩展提高并发能力。
服务器主动推送消息常见问题
WebSocket和SSE在服务器推送消息时，哪个更省带宽？
WebSocket握手后只传输数据帧,头部开销很小（2-14字节），SSE的数据格式是文本流，每行以data:开头，单条消息额外开销在20字节左右，如果推送频率很高且消息体小，WebSocket更省带宽；如果推送频率低且消息体大，两者差异不大，多数情况下，SSE的带宽略高于WebSocket，但实现和维护成本更低。
服务器主动推送技术在国内服务器上部署需要注意什么？
国内云服务器对HTTP长连接支持良好,但WebSocket使用非标准端口（如8080）时，运营商可能有限制，建议使用wss://（443端口）或通过Nginx反向代理，国内部分防火墙会拦截WebSocket的Upgrade请求，此时可以降级到SSE或长轮询作为备选方案，对于企业级消息推送，许多团队选择双通道方案：WebSocket优先，检测到异常时自动切换至SSE。
长轮询方案还有必要保留吗？
在绝大多数现代浏览器环境中,WebSocket和SSE都已原生支持，长轮询主要作为向后兼容的降级方案，用于老旧浏览器或网络环境受限的场景，如果用户群体中IE11及以下版本占比较大，建议保留长轮询作为备选；否则可以直接采用WebSocket或SSE，开发成本更低，体验也更好。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/554161.html
