服务器可以主动向客户端发送消息，这主要通过WebSocket、Server-Sent Events及长轮询等服务器推送技术实现，为即时通讯、实时数据更新等场景提供了基础。 在传统Web应用中，客户端需要主动请求才能获取数据，但许多业务要求服务器实时推送更新，比如IM消息的接收、订单状态通知等，了解这些技术的原理和适用场景,能帮助你构建更高效的实时通信系统。
服务器主动向客户端发送消息的实现方式
传统轮询与主动推送的对比
在主动推送出现之前，客户端通过轮询定期向服务器发送请求，询问是否有新数据，这种方式简单但效率低下，大量请求浪费带宽和服务器资源，主动推送则允许服务器在有数据时直接发送,大大减少了无谓的通信。
WebSocket：全双工通信的基石
WebSocket协议在客户端和服务器之间建立一条持久连接，允许双方随时发送数据，它被广泛用于即时通讯、在线游戏等实时性要求高的场景，据统计，多数主流浏览器早已全面支持WebSocket，使其成为实时应用的标配，使用WebSocket的典型流程：客户端发起HTTP升级请求，服务器响应101状态码,连接建立后双方可以发送数据帧。
Server-Sent Events：单向推送的轻量方案
如果只需要服务器向客户端发送消息，SSE是一个更轻量的选择，它基于HTTP协议，实现简单，自动重连，适合新闻推送、日志流等场景，但SSE不支持客户端向服务器发送数据,仅用于单向推送。
长轮询与短轮询的适用场景
长轮询是轮询的改进：客户端发起请求后，服务器保持连接直到有新数据或超时，再返回响应，这样减少了无数据时的请求次数，短轮询则是定期请求，无论有无数据都立即返回，长轮询在WebSocket不可用时可作为降级方案,但实时性略逊于WebSocket。
| 技术 | 方向 | 连接类型 | 实时性 | 资源消耗 | 适用场景 |
|---|---|---|---|---|---|
| 短轮询 | 客户端请求 | 无状态 | 低 | 高 | 历史兼容 |
| 长轮询 | 客户端请求 | 模拟保持 | 中 | 中 | 降级方案 |
| Server-Sent Events | 服务器→客户端 | 长连接 | 高 | 低 | 单向推送 |
| WebSocket | 全双工 | 长连接 | 高 | 中 | 双向实时通信 |
IM消息推送与分享的服务器端架构
消息路由与分发机制
在IM系统中，服务器需要将消息准确路由到目标用户，通过消息队列（如RabbitMQ、Kafka）异步处理，保证消息不丢失并支持高并发，服务器根据用户ID与连接ID的映射关系，将消息推送至对应的客户端连接，IM消息推送的服务器端实现通常包括连接管理、路由表维护和失败重试机制。
消息持久化与离线消息处理
当用户不在线时，服务器需要将消息存储下来，待用户上线后重新推送，行业共识认为，离线消息的存储策略直接影响系统可靠性，常用做法是使用数据库或缓存存储，并在用户登录时拉取未读消息，对于离线消息的推送，服务器会检查用户连接状态，如果连接断开则标记为离线,等用户重新建立连接后再投递。
分享消息的实现逻辑
分享IM消息是常见功能，服务器需要复制原始消息并生成新的消息，发送给分享目标，分享消息的服务器端逻辑需要处理消息复制和权限校验,具体步骤包括：
- 接收客户端分享请求,验证用户身份和分享目标。
- 根据消息ID从存储中查询原始消息，检查分享权限（如是否允许跨群分享）。
- 创建新消息对象，复制原始消息内容,并附加分享来源信息。
- 将新消息插入目标会话的消息队列,并触发推送通知。
- 推送通道将新消息发送给目标会话的所有在线成员,同时更新离线存储。
实际应用场景中的操作路径
即时通讯软件中的消息推送
在微信、钉钉等应用中，消息的实时推送依赖WebSocket或自研协议，当用户A发送消息给用户B，服务器收到后立即推送给B的客户端，整个过程在毫秒级完成，如果B离线，服务器将消息存入离线库，待B上线后推送，服务器主动向客户端发送消息的优点在于实时性高、节省带宽,这也是IM系统选择推送而非轮询的原因。
电商平台订单状态通知
用户在电商平台下单后，需要实时了解订单状态更新，服务器通过SSE或WebSocket将订单状态变更推送给用户，无需用户手动刷新，支付成功、发货提醒等，都是典型的服务器主动推送场景，在实现时，服务器将订单ID与用户连接关联,当状态变更时通过事件驱动推送更新。
协同办公系统的消息分享
在协同办公中，用户需要将聊天记录或文件分享给群组或其他成员，服务器端实现分享时，需要保留原始消息的上下文，并确保分享后接收方能正确查看，操作路径包括：用户点击分享，触发API请求，服务器验证权限，创建新消息，并推送给目标会话成员，对于文件分享,服务器还需处理文件附件的复制和引用。
技术选型对比与常见问题
在选择推送技术时，需要综合考虑实时性要求、客户端兼容性、服务器成本等因素，业内专家指出，对于实时性要求高的IM系统，WebSocket是首选；对于单向通知场景，SSE更为简洁；对于需要兼容老旧浏览器的情况,长轮询可作降级。
常见问题
- 服务器主动推送是否会增加服务器压力？长连接会占用更多连接资源，但现代服务器通过异步I/O和连接池可以高效管理大量连接,整体资源消耗通常低于高频率的轮询。
- 如何保证消息不丢失？通过消息队列持久化、确认机制和离线存储,可以在网络波动或客户端离线时确保消息最终送达。
服务器主动向客户端发送消息常见问题
服务器主动推送需要客户端保持长连接吗？
是的，无论是WebSocket还是SSE，都需要客户端与服务器之间维持一条长连接，长轮询虽然每次请求后连接会断开，但客户端会立即发起新请求，模拟出持续连接的效果，如果客户端无法保持长连接（如HTTP/1.1的限制）,则无法实现真正的主动推送。
如何实现IM消息的实时分享？
分享IM消息时，服务器需要先拉取原始消息，然后根据分享目标创建新消息，并写入目标会话的消息队列，最后通过推送通道将新消息发送给目标会话的所有在线成员，整个过程需要保证消息顺序和完整性,通常借助消息队列和分布式锁实现。
服务器主动推送与客户端轮询哪个更高效？
主动推送在实时性和资源利用率上通常优于轮询，轮询会产生大量无效请求，尤其是在消息频率低时，浪费带宽和计算资源，而主动推送只在有数据时传输，网络开销小，但需要维护长连接，连接数较多时对服务器内存和连接管理有更高要求，从整体效率看，对于实时性要求高的场景,主动推送是更优选择。