SSE 的局限性是什么

P0 · agent_architecture · 🏢 字节

🏷 标签：sse, streaming, protocol

1️⃣ 考察意图

面试官想考察你对 SSE（Server-Sent Events）的深度理解，而非简单背诵“单向/文本/连接数限制”。这是典型的 工程取舍 + 系统设计 题，刁钻点在于：SSE 看似简单，但在高并发、双向通信、二进制流等场景下会暴露致命短板。答好了能展示你对协议底层（HTTP/1.1 vs HTTP/2）、浏览器限制、以及实际落地中与 WebSocket / gRPC 流式方案的对比能力，体现“选型不是抄文档，而是算账”的工程思维。

2️⃣ 标准答

SSE 的局限性可以从 协议层、传输层、生态层 三个维度拆解，每个维度都有具体的坑和取舍。

协议层：单向 + 文本，天然残疾

单向性：SSE 只允许服务器向客户端推送，客户端无法通过同一连接发送数据。这导致任何需要双向交互的场景（如聊天、实时协作编辑）都必须额外开一个 HTTP 请求通道，增加延迟和复杂度。取舍：如果业务 90% 是服务器推送（如股票行情、日志流），SSE 比 WebSocket 更轻量（无需握手升级）；但一旦需要双向，WebSocket 或 gRPC 流式是更好的选择。
纯文本限制：SSE 协议基于 text/event-stream，只能传输 UTF-8 文本。二进制数据（如音频流、图像帧）必须 Base64 编码，体积膨胀约 33%，且解码增加 CPU 开销。实际坑：某实时语音转写项目用 SSE 传 PCM 音频块，Base64 后带宽翻倍，延迟从 200ms 升到 350ms，最终切到 WebSocket 的二进制帧解决。

传输层：连接数瓶颈 + HTTP/2 兼容性

浏览器连接数限制：HTTP/1.1 下，每个域名最多 6-8 个并发连接（Chrome 为 6）。如果页面同时打开多个 SSE 流（如监控面板有 5 个实时图表），很容易占满连接池，导致其他请求（CSS/JS/API）被阻塞。解法：要么用 HTTP/2 多路复用（单个连接承载多个流），要么合并 SSE 流（一个事件流带多个数据通道，用 event 字段区分）。
HTTP/2 下的“假兼容”：虽然 SSE 在 HTTP/2 上能跑，但浏览器实现有坑。例如，Chrome 的 HTTP/2 实现会强制对 SSE 流启用“服务器推送”缓存，导致重复事件被丢弃。实际坑：某广告实时竞价系统用 HTTP/2 SSE 推送出价结果，发现 30% 的事件被浏览器静默丢弃，排查两天才发现是 Cache-Control: no-cache 头没加，加上后恢复。
重连机制脆弱：SSE 的 EventSource API 自带自动重连，但重连间隔是浏览器硬编码的（3 秒），且无法自定义退避策略。如果服务器负载高，3 秒重连会引发“惊群效应”，瞬间打满连接。取舍：手动实现 WebSocket 重连（指数退避 + jitter）更可控，但需要额外代码。

生态层：工具链缺失 + 调试困难

无原生二进制支持：相比 WebSocket 的 Blob 和 ArrayBuffer，SSE 只能靠 JSON.parse 或自定义分隔符解析。对于高频二进制流（如游戏状态同步），解析开销不可忽略。
调试工具匮乏：Chrome DevTools 的 Network 面板能看 SSE 事件，但无法像 WebSocket 那样实时查看帧内容。生产环境排查丢事件时，只能靠服务端日志 + 客户端 onerror 回调，效率低。
代理/网关兼容性：Nginx 默认对 SSE 有 1 分钟超时（proxy_read_timeout），且会缓冲响应体，导致客户端收不到实时事件。解法：必须显式设置 proxy_buffering off; 和 proxy_read_timeout 3600s;，否则 SSE 在反向代理后直接失效。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从协议层、传输层、生态层三个层面回答。协议层，SSE 单向且纯文本，无法处理双向交互和二进制流，Base64 编码会膨胀带宽；传输层，HTTP/1.1 下连接数限制严重，HTTP/2 有兼容性坑，重连机制不可控；生态层，调试工具少，Nginx 代理需要特殊配置。总结一句：SSE 只适合低频、单向、文本的服务器推送场景，高并发或双向场景必须换 WebSocket 或 gRPC 流式。”

4️⃣ 高频追问 & 应对

追问 1：那如果业务就是需要双向通信，但客户端是浏览器，你会怎么选型？为什么不用 WebSocket？

选型取决于延迟要求和连接数。如果延迟容忍度在 100ms 以上，且连接数 < 1000，我会用 SSE + HTTP POST 组合（SSE 推送，POST 发送），因为 SSE 天然支持 HTTP/2 多路复用，而 WebSocket 在 HTTP/2 下会退化为独立连接，浪费端口。如果延迟要求 < 50ms 或连接数 > 5000，必须上 WebSocket，因为 SSE 的 HTTP 头部开销（每次重连都带 Cookie/Token）在大量连接下会压垮服务器。实际案例：某实时协作白板，初期用 SSE + POST，连接数到 3000 时服务器 CPU 飙升到 90%，切到 WebSocket 后降到 30%。

追问 2：SSE 在移动端有什么特殊限制？比如 iOS Safari 或 Android WebView？

移动端有两个坑。第一，iOS Safari 在后台标签页时会自动暂停 SSE 连接，切回前台才恢复，导致事件丢失。解法是监听 visibilitychange 事件，在页面可见时手动 EventSource.close() 再 new EventSource()，但会引入 3 秒重连延迟。第二，Android WebView 默认不支持 EventSource，需要 polyfill（如 eventsource-polyfill），但 polyfill 基于 XHR 轮询，失去了 SSE 的实时性。所以移动端高实时场景（如直播弹幕）更推荐 WebSocket。

追问 3：如果我要用 SSE 传二进制数据，除了 Base64 还有别的方案吗？

有，但都不完美。方案一：用 Uint8Array 转成 UTF-8 字符串（通过 TextDecoder），但只适用于小数据（< 1MB），且浏览器对 UTF-8 编码有性能瓶颈。方案二：分块传输，将二进制数据切成多个 SSE 事件，客户端用 ArrayBuffer 拼接，但需要自己实现序列号校验，复杂度高。方案三：放弃 SSE，改用 WebSocket 的 Blob 或 ArrayBuffer 帧，这是标准做法。实际取舍：如果二进制数据占比 < 10%，Base64 的 33% 膨胀可以接受；如果占比 > 50%，必须换协议。

5️⃣ 避坑 · 常见错误答法

❌ 只答“SSE 是单向的，不能双向通信” → ✅ 补充具体场景：比如聊天室需要双向，但股票行情只需要单向，所以 SSE 适合后者。同时点出“单向”带来的工程代价：客户端必须额外开 HTTP 连接发数据，增加延迟和复杂度。
❌ 说“SSE 连接数限制是浏览器的锅，没办法” → ✅ 给出解法：用 HTTP/2 多路复用或合并 SSE 流，并说明 HTTP/2 下需要设置 Cache-Control: no-cache 避免事件被丢弃。
❌ 忽略代理层问题，只谈协议本身 → ✅ 主动提 Nginx 的 proxy_buffering off 和超时配置，展示整条链路思维。

6️⃣ 简历呼应

如果你有实时通信项目：从“SSE 在 N 个连接下的性能瓶颈”切入，对比你项目中用 WebSocket 或 gRPC 的选型理由，强调连接数、延迟、二进制支持等 trade-off。
如果你只做过传统 HTTP 服务：用“SSE 与长轮询的对比”类比，说明 SSE 如何减少 HTTP 头部开销，但暴露了连接数限制和重连问题，展示你对协议演进的理解。
如果你是校招无项目：聚焦“浏览器 EventSource API 的坑”，比如重连间隔、HTTP/2 兼容性，结合 MDN 文档和 Chrome 源码分析，体现钻研能力。

7️⃣ 延伸阅读

《High Performance Browser Networking》第 13 章：Server-Sent Events 与 WebSocket 的协议对比
MDN 文档：EventSource API 的浏览器兼容性表（注意 Safari 和 Android WebView 的差异）
Nginx 官方博客：Buffering and Server-Sent Events（配置 proxy_buffering off 的详细说明）
Chrome 源码：EventSource 的 HTTP/2 实现（搜索 EventSourceImpl::OnResponseStarted）
论文《A Comparison of WebSocket and SSE for Real-Time Web Applications》（2019，IEEE）

—— 本场面试完 ——