技术深度剖析
协议幻觉：为什么SSE的简洁性是个陷阱
SSE被W3C定义为基于HTTP的单向文本协议。服务器发送`data: ...\n\n`帧，客户端的EventSource API自动解析它们。这在演示环境中完美运行——一个Node.js服务器向本地浏览器流式传输数据。但生产系统引入了多层基础设施，打破了这种模式。
代理缓冲： 大多数反向代理（Nginx、Envoy、AWS ALB）默认缓冲HTTP响应。对于SSE，这意味着代理会等待整个响应完成后再转发——完全破坏了流式传输。工程师必须显式禁用缓冲（Nginx中为`proxy_buffering off`），但这常被忽略，导致客户端在LLM完成生成前什么也收不到——静默失败。
负载均衡器超时： 云负载均衡器（例如AWS ALB、Google Cloud HTTP(S) LB）设有空闲超时设置，通常为60秒。LLM生成长响应——比如10,000令牌的代码分析——可能超过此限制，导致连接断开。解决方案包括增加超时时间（通常设为3600秒）或使用TCP级负载均衡器，但这增加了复杂性。
浏览器连接限制： HTTP/1.1规范将每个域名的并发连接数限制为6个。每个SSE流占用一个连接。在一个同时显示GPT-4o、Claude 3.5和Gemini 2.0实时输出的多模型仪表盘中，三个连接已用掉一半预算。为其他功能添加WebSocket连接会迅速耗尽限制，导致排队和延迟。
背压真空：一个关键架构缺口
最严重的缺陷是缺乏原生背压。在标准HTTP请求-响应中，客户端通过发送请求控制流量。而在SSE中，服务器单方面推送数据。当LLM以每秒100令牌的速度生成令牌，但客户端的UI每秒只能渲染50令牌（由于DOM更新或繁重计算），客户端的接收缓冲区会填满。没有背压，浏览器要么断开连接（超时后），要么在内存中累积数据，导致内存溢出崩溃。
这在智能体工作流中尤其危险。考虑一个系统：智能体A（一个LLM）将分析流式传输给智能体B（一个代码执行器），然后B将结果流式传输回A。如果B比A慢，从A到B的SSE流要么溢出B的内存，要么导致B丢失令牌。开发者通常被迫在应用层实现流量控制——通过单独的HTTP请求发送确认——这增加了延迟和复杂性。
相关开源项目：
- `eventsource-parser`（GitHub，约2000星）：一个JavaScript库，用于在缺乏原生EventSource的环境（如Node.js）中解析SSE流。它提供`createParser`函数处理分块数据，但仍缺乏背压。
- `sse-channel`（GitHub，约500星）：一个Node.js库，管理多个SSE连接并带有重连逻辑。它使用`last-event-id`机制实现恢复，但未实现背压。
- `fastify-sse`（GitHub，约300星）：一个Fastify插件，用于SSE端点。它支持自定义头和压缩，但同样没有背压控制。
基准数据：SSE vs. WebSocket vs. WebTransport
| 特性 | SSE | WebSocket | WebTransport (HTTP/3) |
|---|---|---|---|
| 方向 | 仅服务器→客户端 | 双向 | 双向 |
| 背压 | 无（需应用层实现） | 原生通过`bufferedAmount` | 原生通过流控 |
| 浏览器支持 | 所有现代浏览器 | 所有现代浏览器 | Chrome、Edge（有限） |
| 连接限制 (HTTP/1.1) | 每域名6个 | 每域名6个（与SSE共享） | 无限制（HTTP/3多路复用） |
| 重连 | 内置（`last-event-id`） | 手动实现 | 手动实现 |
| 延迟 (p95, 1KB消息) | ~50ms（含代理缓冲） | ~10ms | ~5ms |
| 内存开销 (每连接) | ~10KB | ~50KB | ~20KB |
| 复杂度 | 低（协议层面） | 中（握手、帧结构） | 高（需HTTP/3） |
数据要点： SSE提供最低的协议复杂度和内置重连，但缺乏背压且因代理缓冲导致更高延迟。WebSocket提供双向通信和原生背压，但需要手动实现重连逻辑。WebTransport提供最佳性能和无限制连接，但尚未广泛支持。对于AI流式传输，选择取决于规模和实时性要求：SSE适用于简单聊天演示，但生产级智能体系统需要WebSocket或WebTransport。
关键玩家与案例研究
OpenAI：带补丁的SSE先驱
OpenAI的API从一开始就使用SSE进行流式补全。他们的Python客户端库（`openai`包）实现了一个自定义`Stream`类，读取SSE事件并生成令牌。