服务器主动通知客户端，本质是让服务器具备实时推送数据的能力，WebSocket和SSE是当前最成熟的两大方案，选型必须结合业务场景与网络环境。
传统上,客户端通过轮询获取数据，但这种方式存在延迟高、资源浪费的问题，服务器主动通知技术解决了这些痛点，近年来，随着Web实时交互需求的增长，主动通知方案逐渐成为标配，下面从技术选型、实现步骤、场景适配和成本考量四个维度拆解，帮你理清这条路该怎么走。
服务器主动通知客户端长轮询与WebSocket哪个好？
长轮询和WebSocket是两种核心机制,但实现原理和适用场景差异明显，很多团队在选型时纠结，其实把各自特点拆开看就清楚了。
长轮询的原理与局限
长轮询是轮询的改进版,客户端发起请求，服务器保持连接直到有数据返回或超时，然后客户端再发起新请求，这套机制在HTTP协议下完成，兼容性好，但本质上还是“客户端拉取”。
- 延迟问题：即使服务器有数据，也要等到下一个请求才能返回，做不到真正的实时。
- 资源消耗：每个长轮询连接都会占用服务器线程，并发量上去后，线程数容易成为瓶颈。
- 复杂场景吃力：多客户端、高频率更新时，长轮询的效率和可靠性明显下降。
行业共识认为,长轮询适合数据更新频率低、客户端数量可控的场景，比如后台管理系统的定时刷新。
WebSocket的双向通信优势
WebSocket建立一次TCP连接后,服务器和客户端可以随时双向推送数据，延迟极低。
- 真正的实时：数据到达后立即推送，无轮询间隔。
- 连接复用：单个TCP连接维持全双工通信，减少握手开销。
- 二进制支持：可以传输二进制帧，适合多类型数据。
但WebSocket的缺点也很明显：需要单独升级协议栈，兼容性依赖浏览器支持；反向代理和防火墙可能需要额外配置；连接数过多时，服务器内存和文件描述符压力较大。
SSE的轻量级单向推送
SSE（Server-Sent Events）基于HTTP协议，服务器单向推送数据到客户端，相比WebSocket，它更轻量。
- 使用简单：客户端用EventSource API，服务端用标准HTTP响应头（Content-Type: text/event-stream）。
- 自动重连：内置断线重连机制，无需额外编码。
- 文本优先：只支持文本数据，相比WebSocket功能受限。
多数情况下,SSE适合数据流向单一、不需要客户端回传的实时场景，比如行情推送、通知提醒。
| 特性 | 长轮询 | WebSocket | SSE |
|---|---|---|---|
| 通信方向 | 单向（客户端拉取） | 双向 | 单向（服务器推） |
| 实时性 | 中 | 高 | 高 |
| 实现复杂度 | 低 | 高 | 低 |
| 浏览器兼容 | 全兼容 | 现代浏览器 | 现代浏览器（IE不支持） |
| 资源消耗 | 线程成本高 | 连接成本高 | 低 |
| 典型场景 | 低频更新 | 即时通讯、游戏 | 实时监控、通知 |
如何实现服务器主动推送消息到客户端？
选好方案后,实现步骤是关键，以WebSocket和SSE为例，给出具体代码思路和操作路径。
WebSocket实现步骤
WebSocket在Node.js中可以用ws库，前端用原生WebSocket对象。
-
服务端建立WebSocket服务
- 安装
ws库，创建WebSocket.Server实例，绑定端口。 - 监听
connection事件，拿到客户端socket。 - 使用
ws.send()推送数据，设置ping/pong心跳保持连接。
- 安装
-
前端连接与监听
- 创建
new WebSocket('ws://...')。 - 监听
onmessage事件接收数据。 - 监听
onclose和onerror触发重连逻辑。
- 创建
-
心跳机制
- 服务端定期发送心跳包,客户端回复pong。
- 超过阈值未响应则关闭连接,触发重连。
SSE接入示例
SSE服务端在Node.js中只需设置响应头，并持续写入数据流。
- 服务端：设置
res.writeHead(200, {'Content-Type': 'text/event-stream'})
res.write('data: 消息内容nn')发送。 - 客户端：
new EventSource('/stream')，监听onmessage事件。 - 注意：SSE默认支持重连，服务端可通过
retry字段指定重连间隔。
兼容性处理
- 对于不支持WebSocket或SSE的旧浏览器,可以降级到长轮询。
- 使用
SockJS或Socket.IO这类库，它们自动做协议降级。 - 注意：大多数现代浏览器已原生支持WebSocket，SSE在IE中不支持，需考虑polyfill。
实时数据推送场景下服务器主动通知方案选择
不同场景对实时性、连接数、数据流量的要求不同，方案选择需要具体分析。
即时通讯场景
即时通讯要求双向实时通信,用户间频繁发送消息，WebSocket是首选。
- 每个用户维持一个长连接,服务器需要管理大量连接。
- 心跳机制和重连策略必须设计好,避免断线后消息丢失。
- 群聊场景下,广播消息时注意控制服务器负载，可采用分片发送或延迟合并。
实时数据监控
监控面板需要从服务器拉取指标数据,更新频率通常以秒级为单位，SSE是最佳选择。
- 数据流向单向,服务器推送，客户端展示。
- SSE自动重连特性在监控场景中很实用,网络波动后能自动恢复。
- 如果监控数据量大,可以在服务端做数据聚合，减少推送频率。
弱网环境下服务器主动通知客户端方案
弱网（移动网络、Wi-Fi不稳定）下，连接频繁断开，方案需要特别优化。
- 重连策略：采用指数退避算法，避免频繁重连加剧网络拥塞。
- 数据压缩：对推送内容进行gzip压缩，减少传输体积。
- 消息去重：客户端维护消息序列号，防止重复处理。
- 本地缓存：如果网络断开，将数据缓存到本地，恢复后同步。
业内专家指出,弱网环境下，SSE的重连机制比WebSocket更易维护，因为SSE的EventSource API自带重连逻辑，而WebSocket需要手动实现。
服务器主动通知客户端成本与性能考量
选型不仅要看功能,还要考虑服务器资源和运维成本。
连接数对服务器资源的影响
- WebSocket：每个连接占用一个文件描述符，长连接维持需要内核内存，并发上万时，进程数或线程数需要调整，建议使用事件驱动模型（如Node.js、Netty）。
- SSE：同样基于HTTP长连接，但连接数高时，服务器分发压力较大，可以使用多进程或异步IO。
- 长轮询：每个请求持续占用线程，并发上千后性能急剧下降，必须配合异步框架。
云服务商方案对比
- 云厂商提供的消息队列（如简米云MQ、酷番云CMQ）和即时通讯服务（如酷番云IM）可以直接集成，减少自建复杂度。
- 自建方案成本：WebSocket服务需要公网IP和备案，SSE只需HTTP服务器。
- 如果业务量不大,SSE的服务器成本更低；如果连接数超过十万，建议使用云服务商的长连接网关。
服务器主动通知客户端，核心是平衡实时性、资源消耗和开发成本，WebSocket适合双向通信，SSE适合单向推送，弱网环境优先考虑SSE的重连优势。
关于服务器主动通知客户端的常见问题
服务器主动通知客户端和轮询相比，哪个更节省带宽？
轮询每次请求都会携带完整HTTP头,即使没有数据，也会消耗带宽，服务器主动通知（如SSE或WebSocket）在建立连接后，后续推送数据只传输实际内容，头开销小很多，在数据更新频繁的场景下，主动通知更省带宽。
实现服务器主动通知客户端时，如何保证消息不丢失？
主要靠三点：客户端维护消息序列号，服务端做消息持久化，断线后拉取缺失数据，WebSocket可以配合消息队列实现可靠投递；SSE自动重连后，可以设置Last-Event-ID字段让服务端重发丢失的消息。
弱网环境下服务器主动通知客户端方案，哪种技术更稳定？
SSE在弱网环境更稳定,因为它的EventSource API内置了重连和心跳，浏览器自动处理断线恢复，WebSocket需要开发者手写重连逻辑，但可以通过指数退避和心跳保活来提升稳定性，实际测试表明，SSE在丢包率高的网络下，恢复连接的成功率高于WebSocket手动实现。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%a6%82%e4%bd%95%e4%b8%bb%e5%8a%a8%e9%80%9a%e7%9f%a5%e5%ae%a2%e6%88%b7%e7%ab%af%ef%bc%8c%e6%9c%89%e5%93%aa%e4%ba%9b%e5%ae%9e%e7%8e%b0%e6%96%b9%e5%bc%8f/
