WebSocket和SSE怎么选？

核心定位

面向后端/AI服务面试，重点讲解大模型流式输出（打字机效果）场景下 SSE(Server-Sent Events) 与 WebSocket 选型，破除网上浅层答案，讲清工程落地边界。

常识

1. SSE（服务器推送事件）

1. 基于 HTTP/1.1 协议，单向通信：只能服务端→客户端发消息；客户端只能发一次初始请求。

2. 天然支持断线自动重连，浏览器原生支持 EventSource API。

3. 只能传输文本，无法直接二进制；协议规定 text/event-stream 响应流。

4. 无双向交互能力。

2. WebSocket

1. HTTP握手后升级为 独立持久TCP连接，全双工双向通信，客户端和服务端随时互发数据。

2. 需要额外实现断线重连、心跳保活逻辑。

3. 支持文本、二进制数据。

网上通用浅层结论

只需要服务端单向推送（大模型流式回答）→选SSE；
客户端、服务端需要持续互相收发消息→选WebSocket。

这个结论不完全正确，忽略大量生产环境痛点

深度

场景聚焦：大模型对话流式输出（LLM打字机效果，当下最常考场景）

场景需求：用户提问一次，大模型持续逐字返回token；绝大多数时候不需要客户端持续上行发送数据。

1. SSE 的隐藏致命短板

1. 浏览器并发连接限制（重中之重考点）
   浏览器对同一个域名的HTTP并发连接有限制（Chrome：6个）。
   如果页面同时开多个SSE长连接（多标签、多对话窗口），连接直接排队阻塞。
   WebSocket不受该HTTP连接数限制，因为升级后不属于普通HTTP连接。

2. 无法自定义请求头（原生EventSource限制）
   浏览器原生EventSource不能携带自定义Header。
   👉 痛点：项目用 Token放在Header鉴权（Authorization） 时，原生SSE直接无法使用。

   两种妥协方案：token拼URL参数（安全风险，日志泄露凭证）、自己封装Fetch流式模拟SSE。

3. HTTP代理、中间件兼容问题
   部分老旧网关、Nginx、防火墙对text/event-stream流式支持差，容易异常断流；很多运维不熟SSE长连接超时配置。

2. WebSocket 在LLM单向场景下的争议点

网上误区：“双向通道浪费资源”
视频纠正：

• TCP连接开销极低；现代框架（Spring WebSocket、FastAPI WebSocket、Go WebSocket）连接资源消耗差距极小，资源几乎不是瓶颈。

• 最大优势：灵活性拉满
  ✅ 随意自定义鉴权Header
  ✅ 不受浏览器HTTP并发限制
  ✅ 未来需求迭代：一旦增加客户端实时上行交互（中断生成、中途修改参数、多轮实时交互）不用重构通信层

3. 反向误区纠正

❌ 误区：SSE性能一定优于WebSocket
✅ 真相：单纯单向推送，二者理论性能接近；瓶颈几乎永远是大模型推理速度，不是传输协议。

生产环境选型决策树

方案A：优先选 SSE 的场景

1. 前端只需要纯单向推送，确定未来不会增加客户端实时上行消息；

2. 鉴权方式允许 URL传参/cookie鉴权，不需要自定义Authorization请求头；

3. 用户几乎不会同时打开大量并发对话窗口，不存在多连接拥堵；

4. 追求最简实现，不想维护心跳、断线重连逻辑；

   典型：简单demo、内部后台、单会话AI网页。

方案B：优先选 WebSocket（企业级项目首选，绝大多数商用AI产品选择）

1. 使用Header携带Token鉴权（主流规范，不想把凭证放url）；

2. 用户会同时打开多个对话、多标签访问，存在大量并发长连接；

3. 需求有迭代可能性：需要支持中断生成、暂停、客户端随时下发指令；

4. 后端网关、微服务架构复杂，希望统一一套长连接方案（消息通知、聊天、AI流式复用WebSocket框架）。

补充备选方案（很多大厂在用）

Fetch + ReadableStream（流式fetch，模拟SSE能力）
规避原生EventSource不能加请求头的缺陷，基于普通HTTP流，单向通信。本质是手动实现简化版SSE，介于SSE和WebSocket中间方案。

追问

追问1：Nginx 部署两者分别需要什么配置？

• SSE：需要开启响应缓冲关闭 proxy_buffering off，拉长超时时间；

• WebSocket：需要配置 Upgrade 头、开启tcp保活，支持协议升级。

追问2：移动端APP怎么选？

APP没有浏览器EventSource限制，不必受原生SSE约束。
移动端一般两种都可以；移动端经常弱网，需要自主实现重连，两者差距进一步缩小。

追问3：大模型场景如何中断流式输出？

• SSE：前端关闭HTTP连接，服务端感知连接断开终止LLM推理；

• WebSocket：两种方式：前端主动发“停止”指令 ｜ 直接关闭连接；可控性更强。

总结

1. 新手只看：单向选SSE，双向选WS；

2. 工程师要看：鉴权方案、浏览器并发限制、业务未来迭代、网关兼容性；

3. 商用面向公网的AI对话产品，大部分最终选择WebSocket，不是SSE；不要想当然认为单向推送就一定上SSE。

要点整理