服务器向客户端发送通知的核心机制包括轮询、长轮询、WebSocket和SSE，其中WebSocket和SSE因实时性强且资源占用低，已成为现代应用实现实时通知的主流选择。
服务器怎么向客户端发送通知？四种主流方案对比
从早期的网页聊天到如今实时协作工具，服务器向客户端发送通知的需求一直存在，不同技术方案在实时性、资源消耗和实现复杂度上各有取舍,以下逐一拆解。
轮询：客户端的主动拉取
轮询是最直观的方式，客户端每隔几秒向服务器发送HTTP请求，询问是否有新通知，服务器收到请求后，无论是否有新数据，都立即返回响应，这种方案实现简单，兼容性极好，几乎适用所有浏览器环境，但代价也很明显：大量无效请求造成带宽和服务器资源浪费，通知延迟取决于轮询间隔，无法做到真正的实时，多数情况下，轮询仅用于实时性要求不高的场景，比如非关键数据的状态刷新，或作为其他方案的备用降级手段，实际开发中，轮询间隔通常设置在3到60秒之间，太短则服务器压力剧增,太长则延迟过大。
长轮询：等待通知再返回
长轮询是对轮询的改进，客户端发起请求后，服务器不立即返回，而是将连接保持打开，直到有新通知产生或超时，一旦有数据，服务器才返回响应，客户端处理完后立即发起下一次长轮询，这种方式显著减少了无效请求，通知延迟也大幅降低，但仍需频繁建立HTTP连接，对服务器并发连接数有一定压力，在WebSocket尚未普及时，长轮询是实时推送的常用方案，实现时需要注意设置合理的超时时间（通常30-60秒）,并配合心跳机制防止中间代理断开连接。
WebSocket：全双工通信
WebSocket在客户端和服务器之间建立一条持久化的TCP连接，支持双向实时数据传输，一旦连接建立，双方可以随时互发消息，不需要重复HTTP握手，WebSocket的实时性极佳，延迟通常控制在毫秒级，且每个连接仅需少量资源开销，据统计，相比轮询，WebSocket能减少相当一部分不必要的网络流量，尤其在消息频繁的场景下，目前主流浏览器均支持WebSocket，是实现实时聊天、协同编辑、在线游戏等场景的首选，生产环境中，需要实现心跳检测（ping/pong）来维持连接,并处理断线重连逻辑。
SSE（Server-Sent Events）：服务器主动推送
SSE是一种基于HTTP的单向推送技术，客户端通过EventSource接口订阅某个URL，服务器可以持续发送文本数据流，SSE使用简单，原生支持断线重连，且自动处理消息ID，由于是单向推送，SSE非常适合通知类应用，如新闻推送、股票行情、系统告警，但SSE只支持从服务器到客户端的单向传输，且部分老旧浏览器不兼容，需要引入polyfill，SSE的消息格式基于文本，通常以data:开头，服务器可以指定事件类型和ID,客户端通过JavaScript监听特定事件。
WebSocket和SSE选型：服务器实时推送通知该怎么选
当需要服务器实时推送通知时，WebSocket和SSE往往是最纠结的两个选项,它们的核心区别在于通信方向。
双向通信 vs 单向推送
如果应用需要客户端也向服务器发送大量消息（如聊天、游戏），WebSocket更适合，如果只是服务器向客户端推送通知、状态更新，SSE完全够用，且实现更轻量，SSE不需要额外协议栈，调试也更方便,因为它是纯文本的HTTP流。
浏览器兼容性
WebSocket在几乎所有现代浏览器中原生支持，SSE在IE和部分旧版Edge中不支持，如果目标用户群体包含大量IE用户，需要额外处理,或者使用polyfill结合长轮询降级。
连接复用和资源占用
WebSocket使用单一TCP连接，且支持多路复用（通过HTTP/2），但需要自定义协议，SSE基于HTTP，天然与HTTP/2兼容，可在同一连接上复用多个流，从资源角度看，SSE的自动重连和ID管理机制减少了开发工作量，在并发连接数超过一万时，WebSocket和SSE的内存占用差异不大,但WebSocket的协议解析开销略高。
服务器通知方案价格与性能权衡
从服务器成本角度看，WebSocket的长期连接占用更多内存和CPU，但消息传输效率高，SSE保持连接的开销略低，但不支持双向，在并发量较大时，推荐使用WebSocket，配合消息队列和集群扩展，能有效控制成本，如果只是小规模应用，SSE的开发和维护成本更低，一台中等配置的云服务器即可支撑数千并发连接，具体价格取决于云服务商的计算实例规格，但多数情况下，WebSocket和SSE的带宽成本高于计算成本,因此优化消息体积比优化连接数更重要。
长轮询实现服务器通知的优缺点
长轮询作为WebSocket普及前的过渡方案，至今仍有应用场景,尤其在内网环境或对兼容性要求苛刻的系统中。
优点：兼容性好，无需额外协议
长轮询仅使用标准HTTP，任何浏览器和服务器都支持，不需要升级协议或安装额外库，对于银行、政务等安全要求极高的内网系统,长轮询往往是唯一可用的实时推送方案。
缺点：延迟和资源消耗的折中
长轮询虽然降低了无效请求，但每次连接都有TCP握手开销，且在高并发下服务器需要维护大量半连接，吞吐量受限，业内专家指出，长轮询在消息到达率中等且并发数千连接时表现尚可，但超过万级连接时，资源消耗会急剧上升，甚至导致服务器雪崩，长轮询的延迟受超时时间影响，在无消息时段，客户端必须等待超时才能发起新请求,造成不必要的空白期。
服务器通知实现步骤：从轮询到WebSocket
以下以Node.js为例，展示如何从零实现一个简单的WebSocket通知服务,并对比轮询方式的代码差异。
环境准备
安装Node.js和npm，创建项目目录,安装ws库。
npm init -y npm install ws
服务端代码
创建server.js文件,示例代码：
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', function connection(ws) {
console.log('客户端已连接');
// 定时发送通知
const interval = setInterval(() => {
ws.send('服务器通知：' + new Date().toLocaleTimeString());
}, 5000);
ws.on('close', () => {
clearInterval(interval);
});
});
客户端代码
在浏览器中创建WebSocket连接并接收消息。
const socket = new WebSocket('ws://localhost:8080');
socket.onmessage = function(event) {
console.log('收到通知：', event.data);
};
socket.onclose = function() {
console.log('连接断开，尝试重连...');
setTimeout(() => { / 重连逻辑 / }, 3000);
};
轮询实现的对比
轮询的客户端代码更为简单,但服务器需要处理大量请求：
// 客户端每5秒请求一次
setInterval(() => {
fetch('/notify')
.then(res => res.json())
.then(data => { if(data.message) console.log(data.message); });
}, 5000);
生产环境注意事项
- 为WebSocket添加心跳检测,防止僵尸连接。
- 使用sticky session或独立的WebSocket集群处理负载均衡。
- 结合消息队列（如Redis Pub/Sub）实现跨服务器通知广播。
- 对消息频率进行限流,防止单个客户端导致服务器过载。
服务器通知性能优化建议
- 合理设置心跳间隔，避免频繁无效检测,通常每30秒发一次心跳。
- 对推送消息进行压缩，减少传输体积，WebSocket支持permessage-deflate扩展。
- 使用连接池和内存复用，降低GC压力，对于长连接,避免在回调中创建大量临时对象。
- 监控连接数，设置连接上限，防止雪崩，当超过阈值时,可以拒绝新连接或降级为轮询。
- 采用异步非阻塞I/O模型（如Node.js、Netty）处理大量连接,避免线程阻塞。
选择服务器通知方案时，需根据实时性要求、并发规模、成本预算和兼容性综合判断，WebSocket和SSE在处理实时通知时表现最优，是多数现代应用的首选；长轮询和轮询则在特定兼容性场景下仍有价值。
服务器发送通知常见问题解答
服务器怎么向客户端发送通知最可靠？
使用WebSocket或SSE，并实现客户端重连机制，同时在后端设置消息持久化，确保通知不会因网络抖动丢失，当连接断开时,客户端可以自动重连并补发未确认的消息。
WebSocket和长轮询在并发场景下哪个更省资源？
在并发量较大时，WebSocket更省资源，长轮询每个连接都需要重复建立HTTP请求，消耗更多CPU和带宽，WebSocket只在连接建立时进行一次握手，之后的长连接占用的资源相对固定,适合大规模实时推送。
如何降低服务器通知的延迟？
选择合适的推送协议，优化网络路径，使用CDN边缘节点或分布式服务器，在应用层，采用异步消息队列减少主线程阻塞，并利用多线程或协程处理推送任务，同时合理设置超时时间和重试策略,避免无效等待。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/537276.html
