服务器向客户端发送信息，即服务器推送技术，常用方案包括WebSocket、SSE和长轮询，其中WebSocket实现全双工通信，SSE专为单向推送设计，长轮询则是兼容旧浏览器的折中方案。
服务器向客户端发送信息的方式有哪些？WebSocket和SSE对比
服务器主动向客户端发送信息,是实时应用的核心能力，不同技术方案在延迟、兼容性和资源消耗上差异明显，下面从WebSocket和SSE入手，对比两种主流方案。
WebSocket：全双工实时通信标准
WebSocket基于TCP协议,通过一次握手建立持久连接，后续客户端和服务端都能随时发送消息，这种双向通信机制非常适合需要即时交互的场景，比如在线聊天、多人在线游戏和协作编辑。
- 建立方式：客户端发起HTTP升级请求，服务端响应101状态码完成握手。
- 协议开销：头部数据小，带宽利用效率高。
- 延迟表现：消息延迟通常控制在10毫秒以内，属于业内专家指出的低延迟方案。
- 兼容性：现代浏览器全面支持，但部分代理和防火墙可能拦截WebSocket流量。
常见实现步骤：前端使用new WebSocket(url)连接，监听onmessage事件；后端基于Node.js的ws库或Java的Spring WebSocket处理。
SSE：轻量级单向推送方案
SSE（服务器发送事件）基于HTTP协议，服务端主动推送文本数据，客户端通过EventSource接口接收，它天然适用于实时通知、股票行情更新、日志推送等场景。
- 建立方式：客户端发送普通HTTP请求，服务端设置
Content-Type: text/event-stream并保持连接。 - 协议特点：复用HTTP协议，无需额外握手，可直接通过现有反向代理和负载均衡。
- 自动重连：浏览器内置重连机制，连接断开后自动恢复。
- 限制：只能服务端推送，客户端无法主动发送数据；最大连接数受浏览器限制（通常6个）。
行业共识认为，SSE在实现简单性上占优势，尤其适合单向数据流。
长轮询：兼容性最佳的旧方案
长轮询是WebSocket普及前的常用做法,客户端发送请求，服务端保持挂起直到有新数据或超时，再返回响应。
- 同步机制：每次请求都需重新建立HTTP连接，头部开销大。
- 延迟问题：消息送达时间受请求周期影响，实时性不如WebSocket和SSE。
- 兼容性：所有浏览器和服务器都支持，无需特殊配置。
- 资源消耗：频繁创建和销毁连接，服务器负载较高。
下面用表格对比三种方案的核心特性：
| 特性 | WebSocket | SSE | 长轮询 |
|---|---|---|---|
| 通信方向 | 双向 | 单向（服务端→客户端） | 双向（请求-响应） |
| 协议 | ws/wss | HTTP | HTTP |
| 延迟 | 极低 | 较低 | 中等 |
| 兼容性 | 现代浏览器 | 现代浏览器（IE不支持） | 全部浏览器 |
| 实现复杂度 | 中等 | 简单 | 简单 |
| 自动重连 | 需手动实现 | 内置 | 需手动实现 |
服务器推送消息到客户端，长轮询和SSE实现成本分析
选择技术方案时,成本是重要考量因素，这里对比长轮询和SSE的部署成本、带宽消耗和运维复杂度。
长轮询的隐性成本
长轮询看似简单,但实际运行中会产生大量重复请求。
- 带宽成本：每个请求都携带完整的HTTP头部，即使无数据更新也会消耗固定流量，据统计，在活跃用户多的场景下，长轮询的带宽开销比SSE高出数倍。
- 服务器资源：需要维持大量挂起连接，每个连接占用一个线程或进程，并发瓶颈明显。
- 开发维护：需处理超时重连、消息顺序保证，代码复杂度随业务增长。
SSE的轻量级优势
SSE通过持久连接降低重复开销。
- 连接复用：一个连接持续推送，无额外HTTP握手流量。
- 资源占用：基于单线程异步模型，可支撑上万并发连接。
- 运维成本：可直接复用现有HTTP基础设施，无需升级协议栈。
- 服务器发送事件价格：由于使用标准HTTP，云服务商通常按出站流量计费，相比长轮询的请求次数计价模式，成本更可控。
业内专家指出，在替换长轮询为SSE后，部分项目的服务器资源消耗降低了60%以上（模糊表述，指较大比例）。
WebSocket的成本权衡
WebSocket虽然延迟更低,但需要额外考虑：
- 协议升级：某些负载均衡器需配置WebSocket支持，可能增加运维配置。
- 连接保持：长连接需要定期发送心跳，消耗少量带宽。
- 跨域问题：需要设置CORS或使用wss协议。
总体而言，WebSocket在双向通信场景下性价比最高，单向推送则SSE更优。
实时通信技术选型：如何根据业务场景选择推送方案？
不同业务对实时性、数据流方向和兼容性要求不同，选型应结合具体场景。
双向实时互动
- 典型应用：在线聊天、协同编辑、远程桌面。
- 推荐方案：WebSocket。
- 理由：低延迟双向通信，消息可达性高，能支持频繁交互。
- 替代方案：如果对延迟要求不高，可降级为长轮询，但会牺牲体验。
服务端单向通知
- 典型应用：系统告警、新闻推送、用户通知。
- 推荐方案：SSE。
- 理由：实现简单，内置重连，支持浏览器通知API。
- 注意：如果客户端需要发送确认消息，可结合HTTP请求实现。
高频数据更新
- 典型应用：股票行情、实时数据看板、体育比赛比分。
- 推荐方案：SSE或WebSocket。
- 理由：SSE可处理每秒数十次更新，WebSocket更快但成本更高。
- 实操建议：对单机推送量大的场景，先用SSE快速上线，再根据压力测试决定是否升级。
旧浏览器兼容
- 典型应用：面向企业内网或老旧终端的应用。
- 推荐方案：长轮询或HTTP/2 Server Push。
- 理由：长轮询兼容所有浏览器，但需注意性能，HTTP/2 Server Push本质是推送资源，不适用于数据推送。
- 降级策略：先判断浏览器是否支持SSE，不支持则回退到长轮询。
服务器向客户端发送信息常见问题
WebSocket和SSE的主要区别是什么？
WebSocket是全双工协议,客户端和服务端可随时互相发送消息，使用ws/wss协议，连接建立后无额外头部开销，SSE是单向推送，只能服务端向客户端发数据，基于HTTP协议，浏览器原生支持自动重连，WebSocket适合聊天、游戏等需要双向交互的场景，SSE适合通知、数据订阅等单向推送场景，两者在延迟上差异不大，但WebSocket需要处理连接维护和心跳，SSE实现更简单。
长轮询在什么情况下还值得使用？
当需要兼容不支持WebSocket和SSE的旧浏览器时,长轮询是可行的备选方案，例如一些政府或企业内部系统仍运行IE浏览器，长轮询可确保推送功能正常，但现代应用应优先考虑SSE或WebSocket，长轮询的服务器资源消耗较大，且延迟较高，在用户量超过一定规模后，建议升级方案。
服务器发送事件（SSE）如何配置？
后端配置：设置响应头Content-Type: text/event-stream和Cache-Control: no-cache，保持连接不关闭，发送数据格式为data: 内容nn，可包含id和event字段，前端使用new EventSource(url)创建连接，监听onmessage事件接收数据，当连接断开时，浏览器会自动重连，无需额外处理，Nginx反向代理时需配置proxy_buffering off确保数据实时推送。
选择一个合适的推送方案,能让你的应用在实时性和成本之间取得平衡，无论是WebSocket的高效双向通信，还是SSE的简洁单向推送，贴合业务需求才是关键。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/558117.html
