服务器实时推送消息给客户端，最可靠的方案是WebSocket，它解决了HTTP轮询的延迟和资源浪费问题，但在高并发场景下仍需结合消息队列和连接管理做架构优化。
服务器推送消息方案选型：从轮询到WebSocket的演进路径
实时推送需求在IM、在线协同、行情播报、物联网设备状态同步等场景中非常普遍，早期开发人员习惯用HTTP轮询模拟推送，客户端每隔几秒向服务器发一次请求，服务器有数据就返回，没有就空响应，这种方式实现简单，但存在两个硬伤：一是实时性受轮询间隔限制，间隔太短会放大服务器压力，间隔太长用户感知明显延迟；二是大量无意义的空请求浪费带宽和CPU资源，行业共识认为，在连接数超过万级、消息频率较高的场景下,轮询方案很快会触及性能瓶颈。
长轮询改进了轮询的缺陷：客户端发请求后，服务器保持连接挂起，直到有新消息或超时才返回，这样减少了空响应，但服务器需要维护大量挂起的请求，每个连接占用一个线程或协程，连接数上来后内存和线程开销依然很大，而且长轮询在移动网络环境下,频繁断连重连会带来额外的握手消耗。
WebSocket从根本上改变了通信模式，它通过HTTP Upgrade握手建立一条全双工长连接，服务器可以随时主动向客户端推送数据，不需要客户端反复请求，客户端只需要完成一次握手，后续消息走同一个TCP连接，头部开销小，实时性接近毫秒级，对于绝大多数业务系统,WebSocket是服务器实时推送消息的主流选择。
服务器推送消息方案选型对比：WebSocket、SSE与轮询
| 方案 | 连接方向 | 实时性 | 客户端兼容性 | 服务端资源占用 | 适用场景 |
|---|---|---|---|---|---|
| HTTP轮询 | 单向请求 | 取决于间隔 | 极好 | 高（大量空请求） | 低频、非关键通知 |
| 长轮询 | 单向请求 | 较好 | 极好 | 较高（挂起连接） | 兼容老浏览器时的过渡 |
| SSE | 服务器到客户端单向 | 秒级 | 现代浏览器均支持 | 低（单连接） | 股票行情、公告推送 |
| WebSocket | 双向全双工 | 毫秒级 | 现代浏览器均支持 | 中等（需维护连接） | 聊天、协同编辑、实时控制 |
SSE是另一个值得考虑的方案，它基于HTTP协议，服务器端通过长连接持续向客户端发送文本数据流，实现服务器到客户端的单向推送，相比WebSocket，SSE的协议更简单，自带断线重连和事件ID机制，且不需要额外的心跳包，如果业务只需要服务器向客户端单向推送，不需要客户端发消息给服务器，SSE是更轻量的选择，但SSE的缺点是仅支持文本数据，且浏览器并发连接数有限制（HTTP/1.1下每个域名最多6个）。
服务器推送消息延迟高：先排查这三个环节
用户反馈“消息总是晚到”，不要急着调代码，服务器推送消息延迟高，通常不是单一原因，而是链路中某一段出现了堵点，按从客户端到服务器的顺序排查,效率最高。
第一步：确认网络链路是否被代理或防火墙干扰
移动端App或网页在公网环境下，会经过运营商NAT、CDN、反向代理等中间节点，某些代理服务器会主动关闭空闲的WebSocket连接，导致消息到达时连接已断开，客户端需要重连后才能收到，这会造成明显的延迟，检查方法很简单：在服务器端抓包，查看TCP连接是否有异常RST包或FIN包；在客户端日志里记录连接状态，如果发现频繁的onclose事件,大概率是中间链路断连。
第二步：检查服务端消息分发逻辑是否串行阻塞
推送服务最常见的延迟瓶颈出现在消息分发环节，如果所有客户端的推送任务都排在一个单线程队列里，一旦某个客户端写缓冲区满，后续所有消息都会堆积，业内专家指出，多数推送延迟问题源于没有做好“慢消费者”隔离，建议将客户端的连接按负载或地域分片，每个分片独立线程池；同时为每个连接设置独立的发送队列，队列长度超过阈值时直接断开该连接,避免拖垮整个服务。
第三步：确认客户端是否在后台被系统挂起
移动端操作系统对后台App有严格的资源限制，iOS的VoIP推送和Android的厂商推送通道，本质上并不是WebSocket长连接，而是系统级推送通道，如果App退到后台后WebSocket被系统冻结，服务器发送的消息只能等App回到前台才能收到，此时需要对接APNs或FCM，由系统通道唤醒App，再恢复WebSocket，很多团队只做了前台实时推送，忽略了后台保活，导致用户切后台后消息延迟到达,体验很差。
服务器推送消息推送失败怎么办，按顺序检查这五步
推送失败是实时系统的常态，关键是能不能快速定位失败原因，消息推送失败通常表现为三种情况：客户端没收到、客户端收到但无法解析、客户端收到但顺序错乱，按以下顺序排查,能覆盖绝大多数问题。
检查连接是否真的建立成功
WebSocket握手成功不代表连接可用，服务端在握手完成后应该主动发送一个ping帧或业务心跳包，客户端收到后回复pong，如果客户端在应用层没有回应，说明连接可能只是一个半开连接，在服务端维护每个连接的最后心跳时间，超过阈值（比如60秒）就主动断开,防止僵尸连接占用资源。
检查消息是否进入了正确的发送通道
很多推送失败是因为消息投递到了错误的连接或错误的用户ID上，在分布式部署下，用户可能连接在服务器A，而消息路由到了服务器B，需要确认服务端是否实现了连接注册表，并且每个节点都能通过Redis或数据库查询到用户当前所在的节点，常见错误是使用了本地内存保存连接，导致跨节点转发失败，排查时可以打印消息投递的目标节点和实际连接节点,对比是否一致。
检查消息格式是否与客户端协议兼容
服务端推送的数据格式通常为JSON或二进制协议，如果客户端升级了协议版本，而服务端还在发老版本消息，或者两端字段命名不一致，客户端解析时会直接报错，建议在消息头中增加协议版本号，客户端收到无法识别的版本时，主动请求服务端下发最新配置,而不是静默丢弃。
检查消息是否有重复或丢失
网络抖动时，WebSocket底层TCP可能会重传，但应用层不一定保证消息只投递一次，如果业务要求严格顺序且不重复，需要引入消息序号机制，服务端为每个连接维护递增的seq，客户端校验seq连续性，发现跳号就主动请求补发，如果是推送给客户端后客户端崩溃,重启后需要靠增量拉取接口补齐缺失消息。
检查服务端是否限制了推送频率或并发
部分云服务商或自建网关会设置连接数上限、消息速率限制，如果单连接每秒推送超过一定数量，网关会直接断开连接或丢弃消息，查阅服务端日志，看是否有流控触发记录，设计上，推送服务应该做削峰填谷，比如把瞬时的大量消息先写入本地队列，再按固定速率发送,避免触发限流。
服务器推送消息的并发架构与连接管理
单机WebSocket的并发连接数受限于文件描述符和内存，一台8核16G的服务器，理论上可以支撑约5万到10万空闲连接，但每个连接如果都要维护发送缓冲区，内存消耗会随活跃度上升，要支撑百万级连接,必须做水平扩展。
连接状态怎么保存
分布式推送架构中，每个服务器节点只维护与该节点建立的连接，但业务逻辑需要知道“用户张三当前连接在哪台机器”，通常用Redis保存用户ID到节点ID的映射，节点启动时注册，连接断开时删除，消息发送时，先查Redis定位节点,再通过内部RPC或消息队列转发。
消息可靠性如何保证
推送消息的可靠性要求低于数据库事务，但也不能随意丢失，常见的做法是：业务服务把消息写入消息队列（如Kafka或RabbitMQ），推送服务消费队列后，先更新用户会话状态，再执行实际发送，如果发送失败，重试3次，仍失败则进入死信队列，由人工或补偿任务处理，对于需要持久化的消息（如离线消息）,在用户上线时从存储中拉取补偿。
心跳与断线重连怎么设计
客户端应该主动发送心跳，而不是依赖服务端，心跳间隔建议设为30秒到60秒，服务端在两次心跳内没收到数据就判定连接失效，客户端检测到连接断开后，使用指数退避策略重连，比如1秒、2秒、4秒、8秒，最大间隔不超过30秒，重连成功后，客户端需要重新认证,并主动拉取离线消息。
服务器推送消息安全与常见坑
WebSocket虽然好用，但如果不做安全加固，很容易被滥用或攻击，连接建立时，必须校验客户端的身份令牌，不能只靠Origin头判断，推送通道的认证应该独立于HTTP登录态，使用短期有效的token,token过期后强制重新握手。
防止消息注入和越权
服务端推送消息时，要严格校验客户端是否有权限接收该消息，很多开发者只校验了握手时的身份，却没有在业务消息层面做权限判断，导致用户可以订阅任意主题或接收其他用户的消息，建议在推送服务中增加订阅关系校验,消息发送前检查发送者与接收者的会话关系。
心跳与代理的兼容性
部分企业防火墙会关闭长时间空闲的TCP连接，如果只靠应用层心跳，可能不足以维持连接，解决方案是设置合理的TCP keepalive参数，同时缩短应用层心跳间隔，WebSocket的ping/pong帧是协议层的心跳，比业务心跳更轻量,建议同时使用。
服务器推送消息的价格考量
如果选择云厂商的WebSocket服务或消息推送产品，价格通常按连接数、消息数和流量三部分计费，自建方案的成本主要是服务器和带宽，但需要投入开发维护人力，对于初期项目，建议先自建简单的WebSocket服务，配合云厂商的移动推送通道做后台唤醒，等用户量上来后再评估是否采购商业版推送服务，国内云厂商的推送服务价格差异较大，按消息量计费的产品在峰值突发时费用会明显上升,需要根据业务量级做预算估算。
服务器推送消息的常见问题解答
问：服务器推送消息延迟高，是不是应该换成更贵的云服务？
不一定，延迟高首先要定位是网络问题、服务端处理问题还是客户端被系统挂起，多数情况下，通过优化心跳策略、增加消息队列、分片处理慢消费者，就能显著降低延迟，盲目更换云服务或增加带宽，可能解决了表象,却掩盖了架构层的问题。
问：服务器推送消息推送失败，客户端需要怎么设计重试机制？
客户端收到服务端消息后，应该返回一个应用层ACK，服务端在超时未收到ACK时，将消息状态标记为待重推，并存入本地队列，客户端重连成功后，先请求增量接口，按消息序号从服务端拉取未确认的消息，重试间隔要递增,避免重连风暴加重服务端压力。
问：WebSocket和SSE在服务器推送消息场景下如何取舍？
如果只需要服务器向客户端单向推送，且客户端是浏览器环境，SSE更简单，自带重连和事件ID，不需要处理心跳和二进制协议，如果需要双向通信，比如聊天、游戏、协同编辑，WebSocket是唯一选择，移动端原生应用建议使用WebSocket,同时配合系统推送通道处理后台状态。
服务器实时推送消息的核心在于连接管理、消息可靠性和延迟控制，选型时优先WebSocket，需要单向推送时考虑SSE，后台场景必须接入系统推送通道，架构上做到连接注册、消息队列、心跳检测、断线补拉，就能覆盖绝大多数业务需求，技术方案没有银弹，但把基础链路做扎实,推送体验自然稳定。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/558203.html
