服务器推送消息给客户端的主流技术包括WebSocket、SSE和长轮询,其中WebSocket凭借全双工通信和低延迟成为实时应用首选,SSE则适合服务端单向推送场景,长轮询作为兼容方案仍保留在特定场景中。
服务器推送消息方式对比
选择推送方案前,先理清每种技术的核心差异,常见的方式有三种:WebSocket、SSE、长轮询,它们在工作原理、通信方向、性能表现上各有侧重。
WebSocket:双向实时通信的标杆
WebSocket通过一次HTTP握手升级为TCP长连接,实现客户端与服务端的全双工通信,建立连接后,双方可以随时互发消息,头部开销极小,延迟通常在毫秒级。
- 适用场景:在线聊天、协同编辑、实时游戏、金融行情等需要双向频繁交互的应用。
- 优点:实时性强,消息推送效率高,支持双向通信,浏览器兼容性较好(主流浏览器均已支持)。
- 缺点:需要服务器端维护长连接,连接数较多时资源消耗较大;部署时需考虑代理服务器对WebSocket的支持。
据统计,绝大多数即时通讯类应用都采用WebSocket作为核心推送通道,它在实时性要求高的场景中占据主导地位。
SSE:轻量级的服务端单向推送方案
SSE(Server-Sent Events)是HTML5标准的一部分,允许服务端通过HTTP连接主动向客户端发送文本数据,客户端使用EventSource对象接收,支持自动重连和事件流控制。
- 适用场景:新闻推送、股票价格更新、系统通知、日志流等以服务端到客户端单向推送为主的场景。
- 优点:基于原生HTTP协议,部署简单,无需额外协议升级;支持自定义事件类型;浏览器自动处理重连逻辑。
- 缺点:只能从服务端到客户端单向推送,不支持客户端主动发消息;最大并发连接数受浏览器限制(通常每个域名6个);只能传输文本数据(二进制需编码)。
行业共识认为,在只需要服务端推送且不需要双向通信的场合,SSE是比WebSocket更轻量、更易维护的选择。
长轮询:传统HTTP的妥协方案
长轮询是早期为实现实时推送而采用的技术,客户端发送请求后,服务器保持连接直到有数据返回或超时,客户端收到响应后立即发起下一次请求,模拟类似推送的效果。
- 适用场景:兼容老旧浏览器或无法升级WebSocket的环境,如部分企业内部系统、物联网设备管理。
- 优点:兼容性极好,任何支持HTTP的浏览器和设备都能使用。
- 缺点:实时性受轮询间隔影响,延迟较高;频繁创建和销毁连接,服务器开销大;代码逻辑相对复杂,需处理超时和重连。
三种方式核心对比
| 特性 | WebSocket | SSE | 长轮询 |
|---|---|---|---|
| 通信方向 | 双向 | 服务端→客户端 | 双向(模拟) |
| 实时性 | 极高(毫秒级) | 高(秒级) | 中等(依赖轮询间隔) |
| 连接开销 | 较低(长连接) | 低(HTTP长连接) | 高(频繁请求) |
| 浏览器支持 | 所有现代浏览器 | 现代浏览器,IE不支持 | 所有浏览器 |
| 实现复杂度 | 中等 | 简单 | 中等 |
| 典型场景 | 聊天、游戏 | 通知、行情 | 兼容性优先 |
WebSocket和SSE选哪个
这是开发者在规划实时推送时最常纠结的问题,选择的关键在于业务是否需要双向通信,以及对服务器资源的要求。
双向通信决定技术方向
如果客户端需要向服务器发送指令或数据,比如聊天室中用户发送消息,或者游戏中的操作同步,WebSocket是唯一合理的选择,SSE只能接收,无法主动发送,若强行搭配额外HTTP请求会增加复杂度,业内专家指出,在双向交互频繁的场景下,WebSocket的延迟和吞吐量表现远优于任何基于HTTP的模拟方案。
服务器资源与连接数考量
当连接数增长到万级或十万级时,WebSocket的长连接会占用大量内存和文件描述符,而SSE也是长连接,但只负责单向数据流,实现上更容易控制,有些团队会采用WebSocket加SSE的组合:WebSocket负责双向通信,SSE专门用于推送通知,以此分担连接压力。
实际场景下的选择建议
- 实时消息推送场景(如资讯推送、广播):选SSE,部署简单,浏览器自动重连,开发成本低。
- 双向实时交互场景(如白板协作、远程控制):必须选WebSocket。
- 兼容老旧系统:如果客户端跨越多个浏览器版本,且无法控制升级,长轮询仍是备选方案,但多数情况下建议优先考虑WebSocket,再通过SSE降级方案处理不支持的情况。
关于服务器推送消息价格,主要取决于服务器带宽和并发连接数,WebSocket和SSE都属于长连接,对带宽消耗相对较低,但连接数越多,服务器内存和CPU开销越大,长轮询的HTTP请求头部较大,带宽消耗更高,同等规模下的服务器成本可能更高,在预算有限时,SSE和WebSocket的差异不大,主要看业务需求;如果追求极致性价比,SSE在单向推送场景下更具优势。
实现服务器推送消息的实操步骤
以Node.js搭建WebSocket服务器为例,演示如何快速实现推送功能,这里使用ws库,一个轻量级且性能稳定的WebSocket实现。
搭建WebSocket服务器
-
初始化项目并安装依赖
npm init -y npm install ws
-
创建
server.js,编写代码const WebSocket = require('ws'); const server = new WebSocket.Server({ port: 8080 }); server.on('connection', (ws) => { console.log('客户端已连接'); // 推送消息给客户端 ws.send('欢迎连接WebSocket服务器!'); ws.on('message', (message) => { console.log('收到客户端消息:', message.toString()); // 可以广播给其他客户端 server.clients.forEach((client) => { if (client.readyState === WebSocket.OPEN) { client.send(message.toString()); } }); }); }); -
启动服务器
node server.js
-
客户端连接(浏览器控制台测试)
const ws = new WebSocket('ws://localhost:8080'); ws.onmessage = (event) => console.log('收到消息:', event.data); ws.send('你好,服务器');
实现SSE推送
SSE无需额外库,直接用Node.js原生HTTP模块即可。
const http = require('http');
http.createServer((req, res) => {
res.writeHead(200, {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
'Connection': 'keep-alive'
});
// 每隔2秒推送一条消息
setInterval(() => {
res.write(`data: 当前时间 ${new Date().toLocaleTimeString()}nn`);
}, 2000);
}).listen(3000);
客户端接收:
const eventSource = new EventSource('http://localhost:3000'); eventSource.onmessage = (event) => console.log('SSE消息:', event.data);
长轮询的简单实现
长轮询通常由客户端发起请求,服务器端挂起请求直到有数据,以Node.js为例,可以用事件队列实现。
const http = require('http');
const clients = [];
http.createServer((req, res) => {
if (req.url === '/poll') {
clients.push(res);
// 模拟有数据时响应
// 实际场景中,当数据到达时,会从队列中取出res并发送数据
}
}).listen(4000);
// 假设有新消息到来
function notifyAll(data) {
clients.forEach(res => res.end(data));
clients.length = 0;
}
客户端采用循环请求的方式,每次请求完成后立即发起下一次请求,具体代码需处理超时和错误重连。
服务器推送消息常见问题解答
WebSocket连接不稳定怎么办
检查网络环境是否支持WebSocket,代理服务器如Nginx需配置WebSocket代理(设置Upgrade和Connection头),客户端应实现心跳机制,周期性发送ping帧,服务端回复pong,若超时则主动重连,多数问题源于防火墙或代理对长连接的超时设置,可以尝试缩短心跳间隔。
SSE在IE浏览器中无法使用,如何兼容
IE和部分旧版Edge不支持EventSource对象,替代方案包括使用polyfill库(如eventsource-polyfill),或者回退到长轮询,在服务端判断用户代理,对不支持SSE的浏览器自动切换为长轮询,保证功能一致,行业共识认为,SSE的兼容性在逐渐改善,但面向企业级应用时仍需要降级方案。
长轮询与WebSocket相比,服务器压力差异有多大
长轮询的每次请求都会携带完整的HTTP头部,并且频繁创建和销毁TCP连接,对服务器CPU和内存的消耗远高于WebSocket长连接,在相同并发量下,长轮询需要的服务器资源可能高出数倍,具体数据因实现而异,但一般认为,当连接数超过1000时,WebSocket的优势会变得非常明显,对于预算有限的中小规模应用,SSE或WebSocket的长连接模式能显著降低服务器推送消息价格。
选择哪种推送方式,取决于业务对实时性、双向通信、兼容性和服务器成本的具体要求,WebSocket适合全双工场景,SSE适合单向推送,长轮询则在兼容性上保底,明确需求后,用上述步骤快速实现原型,即可验证方案是否满足线上环境。
首发原创文章,作者:王坚,如若转载,请注明出处:https://idctop.com/article/510823.html


