简介
WebSocket和SSE都是实时通信技术，本文将他们进行对比。
备注：随着AI兴起，SSE的热度开始上升。
对比
| 对比项 | WebSocket | SSE |
| 通信方向 | 全双工（双向通信）：客户端 <=>服务端。可双向同时发送数据。 | 单向通信：服务端 => 客户端。客户端向服务端通信需借助HTTP。 |
| 连接类型 | 基于WebSocket协议（TCP层的长连接），协议标识符为ws（非加密）/wss（加密）。 | 基于HTTP的长连接，复用HTTP协议（复用HTTP代理、防火墙规则等）。需HTTP1.1以上。 |
| 数据格式 | 支持：文本、二进制、JSON、Protobuf等，灵活性极高 | 仅支持UTF-8编码的文本数据（如需传输二进制需手动编码为Base64等格式）。 |
| 连接建立机制 | 通过HTTP握手升级：客户端发送Upgrade: websocket请求头，服务端响应101状态码完成协议升级。 | 无需协议升级：客户端通过普通HTTP请求（设置Accept: text/event-stream）建立持久连接，服务端持续向客户端输出数据流。 |
| 心跳重连机制 | 无内置心跳机制，需手动实现（如通过ping/pong帧）维持连接，避免被网关/防火墙断开。 | 内置重连机制：客户端可通过retry字段设置重连间隔，连接断开后自动重试。 |
| 浏览器兼容性 | IE10+、所有现代浏览器（Chrome、Firefox、Safari等 | IE不支持、所有现代浏览器（Chrome、Firefox、Safari等），兼容性略优于WebSocket。 |
| 实现复杂度 | 较高。服务端和客户端均需实现WebSocket协议（处理握手、帧解析、心跳、重连等），需依赖专门的库（如Java的Netty、Node.js的ws库）。 | 极低。客户端原生支持EventSource API（一行代码即可建立连接），服务端无需特殊协议，仅需持续输出指定格式的文本流即可。 |
| 资源占用 | 单连接资源占用较低（二进制帧开销小），但服务端需维护大量长连接，对并发处理能力要求高。 | 基于HTTP长连接，头部开销略高于WebSocket，但实现简单，服务端开发成本低。 |
| 代理/防火墙穿透 | 部分老旧代理/防火墙可能不支持WebSocket协议升级，需额外配置（如Nginx转发ws请求） | 基于HTTP协议，可直接穿透大部分HTTP代理/防火墙，无需额外配置。 |
请先 ！