服务器主动往客户端发送消息的核心在于建立长连接通道，通过WebSocket或Server-Sent Events（SSE）技术打破传统HTTP请求-响应的单向限制，实现服务端数据的实时推送。
在传统的Web开发模式中，客户端（浏览器或App）就像是一个总是处于等待状态的服务员，只有当它主动向服务器发起请求时，服务器才会给出回应，这种“轮询”机制不仅浪费带宽，还导致数据延迟严重，随着移动互联网向物联网（IoT）和实时协作场景的深度渗透，这种被动等待的模式已无法满足需求，业内专家指出，构建低延迟、高并发的实时通信能力,已成为现代应用架构的标配。
为什么传统轮询无法胜任实时推送
要理解服务器主动推送的价值，首先需要看清传统方案的痛点，在早期的Web应用中，开发者常采用短轮询（Short Polling）或长轮询（Long Polling）技术，短轮询就像是你每隔一分钟就打电话问老板“有消息吗”，即使老板一直不说话，你也得一直打，这极大地消耗了服务器资源和客户端电量，长轮询虽然稍好，客户端发起请求后，服务器会保持连接直到有数据返回或超时,但这依然需要客户端不断发起新的握手过程。
资源消耗与延迟的矛盾
在移动端场景下，频繁的网络请求会导致设备发热和电量快速耗尽，据工信部相关数据显示，近年来移动应用对后台保活和实时通知的需求呈指数级增长，对于即时通讯（IM）或股票行情类应用,秒级的延迟都是不可接受的。
- 短轮询：实现简单，但无效请求多,服务器压力大。
- 长轮询：减少了部分连接开销,但仍存在HTTP头部冗余和握手延迟。
- 服务器主动推送：连接建立后，服务端可随时下发数据，无额外握手开销,延迟低至毫秒级。
主流实时推送技术选型对比
目前业界实现服务器主动推送主要有三种技术路径：WebSocket、Server-Sent Events (SSE) 和 MQTT，选择哪种方案,取决于具体的业务场景和对双向通信的需求。
WebSocket：双向通信的首选
WebSocket 是目前最流行的实时通信协议，它在客户端和服务器之间建立了一个持久的、全双工的数据通道，一旦连接建立，双方都可以随时发送数据,互不干扰。
- 适用场景：在线聊天室、多人在线游戏、实时协同编辑文档。
- 优势：支持二进制数据，协议开销极小（头部仅2字节）,延迟极低。
- 劣势：实现相对复杂，需要处理断线重连、心跳检测等逻辑,且穿透防火墙的能力略弱于HTTP。
SSE：单向推送的高效方案
Server-Sent Events (SSE) 是一种基于HTTP的单向推送技术，服务器可以向客户端发送文本流，但客户端不能通过SSE向服务器发送数据,它本质上是HTTP长连接的一种标准化封装。
- 适用场景：新闻推送、股票行情更新、系统日志监控、通知中心。
- 优势：基于标准HTTP协议，易于穿透防火墙和代理服务器，原生支持重连机制,代码实现比WebSocket简单得多。
- 劣势：仅支持文本数据,不支持双向通信。
技术选型决策树
| 需求特征 | 推荐方案 | 理由 |
|---|---|---|
| 需要双向实时交互 | WebSocket | 全双工通信，性能最优 |
| 仅需服务端推送通知 | SSE |
实现简单，兼容性好，自动重连 |
| 物联网设备低功耗场景 | MQTT | 轻量级，支持QoS等级，适合弱网环境 |
如何构建高可用的实时推送服务
仅仅选择协议是不够的，构建一个稳定的推送系统还需要考虑架构设计、状态管理和异常处理。
连接管理与心跳机制
网络环境是不稳定的，移动设备可能在电梯或地铁中失去信号，必须实现心跳机制（Heartbeat）。
- 客户端心跳：每隔固定时间（如30秒）向服务器发送一个空消息或Ping包,证明连接存活。
- 服务端心跳：服务器定期向客户端发送Pong包,确认客户端在线。
- 超时断开：如果超过一定时间（如90秒）未收到心跳，服务器主动关闭连接,释放资源。
分布式架构下的会话保持
在微服务架构中，用户可能连接在不同的应用服务器上，当服务器A收到消息需要推送给用户时,它需要知道用户当前连接在服务器B上。
- Redis Pub/Sub，利用Redis的发布订阅功能，应用服务器之间通过Redis进行消息广播，所有连接该用户的服务器都会收到消息,并推送给对应的客户端。
- 消息队列，使用Kafka或RabbitMQ作为中间件，将推送任务写入队列，由专门的推送网关消费并分发，这种方式解耦更彻底,适合高并发场景。
断线重连策略
客户端必须实现指数退避重连算法，当连接断开时，不要立即重试，而是等待1秒、2秒、4秒、8秒…直到达到最大重试次数或连接成功，这能避免在网络恢复瞬间产生大量并发请求,导致服务器雪崩。
不同场景下的最佳实践
不同的业务场景对实时性的要求不同,选择合适的技术方案能事半功倍。
即时通讯（IM）场景
对于微信、钉钉这类应用，WebSocket是绝对的主流，由于需要发送图片、语音、视频等多媒体数据，WebSocket的二进制支持至关重要，还需要实现消息确认机制（ACK）,确保消息必达。
金融行情与监控大屏
对于股票K线图或服务器监控大屏，数据流向主要是单向的，此时使用SSE更为合适，SSE基于HTTP，无需额外的协议栈，且浏览器原生支持,前端代码只需几行即可实现接收推送。
前端SSE代码示例
const eventSource = new EventSource('/api/stock-price');
eventSource.onmessage = function(event) {
const data = JSON.parse(event.data);
updateUI(data);
};
eventSource.onerror = function() {
console.log('连接错误，尝试重连...');
};
常见问题解答
服务器主动往客户端发送消息有哪些常见实现方式？
主要实现方式包括WebSocket、Server-Sent Events (SSE) 和 MQTT协议，WebSocket适用于需要双向通信的场景，如即时通讯；SSE适用于单向推送，如新闻通知；MQTT则常用于物联网设备,具有低功耗和弱网适应性强的特点。
WebSocket和SSE有什么区别？
WebSocket是全双工通信协议，支持客户端和服务端双向发送数据，适合复杂的交互场景；SSE是单向推送协议，仅支持服务端向客户端发送数据，基于HTTP实现，兼容性更好，实现更简单，如果只需要服务端推送数据,SSE是更轻量级的选择。
如何处理服务器主动推送时的断线重连问题？
客户端应实现指数退避重连算法，即在连接断开后，按照1秒、2秒、4秒等递增的时间间隔尝试重连，避免频繁请求，服务端应维护连接状态，通过心跳机制检测连接有效性，并在客户端异常断开时及时清理资源,防止内存泄漏。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%a6%82%e4%bd%95%e4%b8%bb%e5%8a%a8%e6%8e%a8%e9%80%81%e6%b6%88%e6%81%af%e7%bb%99%e5%ae%a2%e6%88%b7%e7%ab%af%ef%bc%9fwebsocket%e5%ae%9e%e6%97%b6%e9%80%9a%e4%bf%a1%e5%8e%9f/
