SSE 和 WebSocket 有什么区别？

简化版

SSE 是基于 HTTP 的服务端单向推送，适合消息通知、日志流、AI 流式输出；WebSocket 是全双工通信，适合聊天室、协同编辑、实时游戏。SSE 简单、自动重连、走 HTTP；WebSocket 能双向低延迟通信，但连接管理更复杂。

详细版

SSE 特点：

服务端到客户端单向推送。
基于 HTTP。
浏览器 EventSource 支持自动重连。
文本流格式简单。
不适合客户端高频发消息。

WebSocket 特点：

客户端和服务端全双工通信。
建立后保持长连接。
延迟低。
可传文本或二进制。
需要心跳、重连、鉴权和连接管理。

选择时看通信方向和复杂度。

完整版教学

一、SSE 适合什么

SSE 的全称是 Server-Sent Events。它适合服务端持续向浏览器推送文本消息。

例如：

通知消息。
日志输出。
任务进度。
AI 回答流式返回。

客户端如果只需要发起一次请求，然后持续接收服务端数据，SSE 很合适。

二、WebSocket 适合什么

WebSocket 建立连接后，双方可以随时互发消息。

适合：

聊天室。
实时协同。
在线游戏。
实时行情。
需要客户端高频发送数据的场景。

但 WebSocket 需要更多工程处理，如心跳保活、断线重连、消息确认、权限续期。

三、网络和部署差异

SSE 基于 HTTP，更容易穿透代理和网关。WebSocket 需要协议升级，某些代理、负载均衡和网关需要额外配置。

SSE 默认是文本流，如果需要二进制或复杂双向通信，WebSocket 更合适。

四、面试追问与工程落地

面试官可能问：“AI 流式回答为什么常用 SSE？”

因为 AI 输出通常是服务端持续向客户端推送 token，客户端只需要接收和渲染，通信方向主要是单向的。SSE 简单、兼容 HTTP、天然适合文本流。

工程中如果只是通知或流式文本，不要为了“实时”就上 WebSocket，复杂度会更高。

五、协议细节决定工程能力

SSE 响应使用 text/event-stream，事件以 UTF-8 文本和空行分隔；EventSource 会按 retry 和断线情况重连，并可用 id/Last-Event-ID 帮助服务端续传。

id: 42
event: progress
data: {"percent":75}

维度	SSE	WebSocket
方向	服务端 → 客户端	双向全双工
数据	UTF-8 文本事件	文本或二进制帧
建连	普通 HTTP 流	HTTP 握手后升级/扩展连接
自动重连	EventSource 内建基础能力	应用自行实现
背压接口	能力有限	浏览器 API 也需监控缓冲量
认证	Cookie/URL 等受 API 约束	握手 Cookie、协议或首消息方案

原生 EventSource 构造器不能像 fetch 那样自由设置任意请求头，Authorization 方案要结合 Cookie、短期 URL 凭证或使用 fetch 流式读取。凭证放 URL 会进入日志，必须短期且避免敏感长 token。

选型先看消息方向与可靠性合同，再看“实时”二字；连接建立只是起点，重连后的补发和去重才决定数据是否正确。

六、容量、心跳和消息语义

若 10000 个在线用户每 15 秒发送一次心跳，服务端约每秒处理 667 次心跳，还不含业务消息。WebSocket 集群要考虑连接落点、负载均衡、广播扇出、鉴权过期和节点下线迁移；SSE 也同样占长连接与文件描述符。

消息至少带递增 id。客户端记录最后处理 id，重连时请求续传；服务端若只能保留最近 1000 条，而客户端离线越过窗口，应返回快照而不是假装连续。网络重连可能重复投递，所以消费逻辑要幂等。

WebSocket 的 bufferedAmount 持续增长说明发送速度超过网络消耗，继续无界发送会占内存。SSE 经代理时要关闭不合适的缓冲、发送心跳注释，并验证 CDN/网关的空闲超时。

连接 → 鉴权 → 心跳 → 消息 id/确认 → 断线 → 退避重连 → 补发/快照

七、常见误区与追问

误区：只要是实时需求就应该使用 WebSocket。 单向日志、通知和 AI 文本流通常用 SSE 更简单。
误区：EventSource 自动重连就不会丢消息。 仍需事件 id、服务端保留窗口和续传协议。
误区：WebSocket 建连成功后无需 HTTP 基础设施配置。 网关升级头、空闲超时、负载均衡和代理都要支持。
追问：SSE 能发送二进制吗？ 原生事件流是 UTF-8 文本，二进制需编码会增加体积，通常不合适。
追问：为什么 AI 输出常选 SSE？ 用户请求一次后主要由服务端连续推送文本 token，方向和数据类型吻合。
追问：WebSocket 如何处理背压？ 监控 bufferedAmount、限速/丢弃非关键消息，并在应用层设计队列上限。
追问：扩容后如何广播？ 连接节点通过消息总线或专用网关协调，并用用户/房间路由控制扇出。

八、加强记忆

方向选型：服务端单向文本推送优先 SSE，双向高频通信考虑 WebSocket。
续传基础：消息有 id，客户端记位置，服务端能补发或返回快照。
连接治理：鉴权、心跳、超时、退避重连和节点下线都要设计。
容量意识：长连接、心跳和广播按在线用户数计算成本。
流量控制：监控缓冲量，设队列上限和丢弃/降级策略。
部署验收：浏览器、网关、CDN、负载均衡和服务端整链路测试。

简化版

详细版