面经策

什么是 SSE？为什么 AI 应用接口选择 SSE 而不是 WebSocket？ ​

  • 标签：后端、编程导航

🏛 业务架构师 ​

SSE（Server-Sent Events）：基于 HTTP 的服务器单向推送协议——响应头 Content-Type: text/event-stream，服务器持续写 data: ... 事件块，浏览器/客户端逐块接收。

AI 应用选 SSE 而不是 WebSocket 的三个理由：

  1. 通信模型匹配：LLM 对话是"一问一答的流式输出"——请求上行一次、答案下行流式。WebSocket 的双向全双工能力在这里是闲置资产（我们不需要服务端随时主动推）——用单向通道满足单向需求，简单即正确；
  2. 基础设施友好：SSE 就是 HTTP——CDN、Nginx、网关、鉴权、负载均衡全部原生兼容（header/token 照常用）；WebSocket 需要 Upgrade 握手，中间件的兼容性坑多（代理不支持、超时断连、粘性会话要求）——AI 应用多为云原生部署，SSE 的"零改造接入"价值巨大；
  3. 失败与重连简单：SSE 自带重连机制（Last-Event-ID 断点续传），断线恢复轻量；WebSocket 断连后的状态重建复杂得多。

WebSocket 的适用边界（技术选型要讲对侧）：真正的双向实时——协作白板、多人聊天室、游戏、语音助手的全双工音频流——这些场景 SSE 无能为力，别为了"更先进"选 WebSocket，也别为了"更简单"错用它。

工程提醒：SSE 长连接占住一个 Servlet/网关连接——异步 Servlet（SseEmitter 本身是异步的）+ 网关超时调大 + 心跳注释行防中间层掐断（每 15s 发 : ping）。

一句话：LLM 流式输出的形态是"单向流"，SSE 是它的自然选择——协议选型的第一原则是匹配通信模型，不是追逐协议先进性。

🏗 系统架构师 ​

SSE（Server-Sent Events）= 服务器向浏览器单向推送事件流的 HTTP 协议：响应 Content-Type: text/event-stream，连接保持，服务器按 data: xxx\n\n 格式持续推送分片，浏览器 EventSource/fetch 消费。

AI 应用选 SSE 而非 WebSocket 的理由（架构权衡）：

  1. 通信模型匹配：AI 对话是"一次请求 → 持续单向流式回包"，SSE 的单向下行正好；WebSocket 的全双工能力（双向实时）在这里是浪费——用户的输入就是普通 HTTP 请求，不需要在流通道里上行；
  2. 协议简单、基础设施友好：SSE 就是 HTTP——网关、Nginx、鉴权、限流、CDN 全部复用现有 HTTP 设施；WebSocket 是升级协议（Upgrade），代理/防火墙配置复杂、部分企业网络拦截；
  3. 连接管理轻：HTTP/1.1 长连接或 HTTP/2 多路复用即可；断线自动重连（EventSource 内建 retry）；WebSocket 要自己做心跳、重连、状态同步；
  4. 服务端实现简单：SseEmitter / Flux 下游就是响应式流，与 LLM 的 token 流天然对接；
  5. 性能足够：LLM 生成速度（几十 token/s）远低于两协议的吞吐差异，WebSocket 的低延迟优势在此场景无意义。

SSE 的局限与对策：单向（够用）；HTTP/1.1 下浏览器 6 连接限制（用 HTTP/2 解决）；需要上行中断时（用户停止生成）用普通 HTTP 请求发取消指令。

一句话：按通信需求选协议——单向流式用 SSE，双向低延迟（IM、协作、游戏）才上 WebSocket，杀鸡不用牛刀。

💻 全栈开发专家 ​

SSE（Server-Sent Events）= 基于 HTTP 的服务端单向推送协议，响应头 Content-Type: text/event-stream，服务器持续写 data: xxx\n\n 格式的事件，浏览器/客户端顺序接收。

AI 应用选 SSE 而不是 WebSocket 的理由：

  1. 通信模型匹配：LLM 对话的流量本质是"一问一答中的流式下发"——用户发一次请求，服务端持续推 token。是单向流，WebSocket 的双向能力是浪费；
  2. 基础设施友好：SSE 就是普通 HTTP——过 Nginx/网关/CDN/代理不需要特殊配置（WebSocket 要 Upgrade 支持，老网关经常掐）；HTTP/2 下天然多路复用；
  3. 自带重连：浏览器 EventSource 内置断线重连 + Last-Event-ID 续传；WebSocket 断线要自己实现重连状态机；
  4. 简单：服务端就是不断写响应流，Spring MVC 一个 SseEmitter 搞定；客户端 fetch/EventSource 即可，不需要额外的协议库；
  5. 鉴权复用：走 HTTP 就能用现有的 header/Cookie/网关鉴权体系。

什么时候才需要 WebSocket：真正的双向实时——协同编辑、语音对话（边说边识别）、多人房间。我们的 AI 助手后续加了"打字中"实时态，用 SSE 也够了。

一个必答的坑：原生 EventSource 只支持 GET 且不能自定义 header，POST + Authorization 场景要用 fetch 流式读取（下一题展开）——这个细节决定前后端方案落地方式。