在当今互联网应用日益追求实时交互的背景下，服务器推送技术成为开发者的核心议题。从股票行情、即时聊天到在线协作，实时数据推送的需求无处不在。而其中，SSE（Server-Sent Events，服务器发送事件）与 WebSocket 作为两种主流的实时通信方案，常被开发者拿来比较。那么，两者究竟有何异同？各自适用于哪些场景？本文将为您详细解析。
什么是SSE？
SSE 是基于 HTTP 协议的单向通信技术。它允许服务器主动向客户端（通常是浏览器）推送数据，而客户端只能接收，不能通过同一连接向服务器发送数据。SSE 本质上是 HTTP 长连接，通过设置 Content-Type: text/event-stream 和特定的数据格式实现。它支持自动重连、事件 ID 和自定义事件，且天然兼容标准的 HTTP 缓存和代理。
什么是WebSocket？
WebSocket 则是全双工通信协议，在客户端和服务器之间建立持久连接后，双方可以随时相互发送数据。它通过 HTTP 升级握手（101 Switching Protocols）建立连接，之后使用自定义帧格式，传输效率高。WebSocket 广泛应用于需要双向实时交互的场景，如在线游戏、金融交易、协同编辑等。
核心差异对比
1. 通信方向
- SSE：单向（服务器→客户端）。当客户端需要向服务器发送数据时，必须另开 HTTP 请求（如 AJAX）。
- WebSocket：双向（客户端↔服务器）。一次连接即可完成双方通信。
2. 协议与复杂性
- SSE：基于 HTTP，无需额外协议。前端使用
EventSourceAPI，后端仅需编写流式响应，实现简单。 - WebSocket：独立的协议（ws/wss），需要专门的 WebSocket 实现库，握手和帧解析稍复杂。
3. 自动重连机制
- SSE：内置自动重连，客户端断开后会自动尝试重新连接，并可通过
Last-Event-ID恢复断点。 - WebSocket：无内置重连，需开发者自行实现心跳、重连逻辑。
4. 浏览器兼容性
- SSE：主流浏览器（Chrome、Firefox、Edge、Safari）均支持，但 IE 不支持（可通过 polyfill 解决）。
- WebSocket：几乎所有现代浏览器（包括 IE10+ 及以上）原生支持，兼容性更好。
5. 消息格式
- SSE：纯文本/UTF-8 编码，支持自定义事件类型和 ID。二进制数据需额外编码（如 Base64）。
- WebSocket：支持文本和二进制帧（Blob 或 ArrayBuffer），更灵活。
6. 连接数限制
- SSE：浏览器对同一域名的连接数有限制（通常 HTTP/1.1 为 6-8 个），但 HTTP/2 下可大幅提升。
- WebSocket：无特别限制，一个域名可建立数百个连接。
应用场景分析
SSE 适合的场景： - 单向实时推送：如新闻实时推送、股票行情报价、系统监控日志、社交媒体通知。 - 需要简单实现的场景：后端已运行 HTTP 服务，无需额外协议栈。 - 以文本数据为主，无需频繁双向交互。 - 需要自动重连恢复断点（如长轮询替代）。
WebSocket 适合的场景： - 双向实时通信：如在线聊天、多人协作、实时白板、在线游戏。 - 需要低延迟交互：如游戏帧同步、高频交易数据。 - 需要传输二进制数据：如流媒体、文件上传/下载进度反馈。 - 前端需要频繁主动发消息：如即时聊天中的打字提醒、消息撤回。
性能与资源
WebSocket 在建立连接后，头部开销极小（仅 2 字节的帧头），适合高频小数据量传输。而 SSE 基于 HTTP 流，每个数据块都带有 HTTP 头部（即使使用 chunked 编码），在长连接下长尾开销略大。然而，对于大多数中低频率推送场景（如每秒几次），差异可忽略。SSE 背靠 HTTP/2 多路复用技术，可在单个 TCP 连接上同时处理多个流，而 WebSocket 在 HTTP/2 下需通过隧道或单独连接。
结论与展望
SSE 和 WebSocket 并非竞争关系，而是互补。若你的应用仅需服务器向客户端推送文本事件，希望实现简单、自动重连，SSE 是最佳选择。若需要全双工、二进制、低延迟，则 WebSocket 当仁不让。
有趣的是，在一些场景中两者可混合使用：用 WebSocket 实现主体双向通信，同时用 SSE 作为辅助推送通道（例如用于系统通知）。随着 HTTP/3 (QUIC) 的普及，基于 UDP 的多路复用技术可能进一步改变实时通信的格局，但短期内，SSE 与 WebSocket 仍将各司其职。
作为开发者，选择技术时应综合考虑业务需求、团队技术栈、运维成本。不必盲目追求“全双工”，实时通信的本质是“及时”，单向足够时，SSE 的简洁就是最大的生产力。