在基于 Server-Sent Events（SSE） 的 Web 应用中，你是否遇到过这样的困惑：单条数据流一切正常，但同一页面内同时建立多条流时，延迟陡增，新请求长时间挂起？这很可能不是后端处理慢，而是浏览器的同域并发连接限制在"作祟"。本文将深入剖析这一现象背后的原理，并提供一套从前端到架构的通用解决方案。
一、问题现象：容易被误判的"慢"
当你的应用出现以下情况时，应当优先排查 SSE 连接管理问题，而非直接归咎于后端性能：
- 并发流延迟 ：单个 SSE 连接响应迅速，但页面内对同一域名 同时发起两条或以上 SSE 连接时，延迟显著增加，甚至请求被挂起。
- "僵尸"连接阻塞：用户已取消上一个操作或切换了筛选条件，新的 SSE 请求需要等待很长时间才能建立，仿佛在排队。
- 监控与体感不符：服务端监控显示接口耗时极短，但用户从点击到看到数据反馈的端到端体验却非常"慢"。
这些现象常被误判为网关超时或后端服务瓶颈，实则根源多在网络连接层。
二、核心原理：为何"同域"会成为瓶颈？
1. 浏览器的连接池限制
在 HTTP/1.1 环境下，浏览器对同一 host （协议+域名+端口）通常会维护一个数量有限的并行 TCP 连接池（常见上限为6个）。短请求会快速释放连接，而 SSE 作为长连接，会持续占用其中一个名额。当多个 SSE 连接与常规的 XHR/Fetch 请求、静态资源加载共享同一域名时，极易触达上限，新请求只能排队等待。
2. 按"域"非按"路径"限制
关键一点：此限制是基于域名 的。同一域名下的不同 API 路径（如 /api/streamA和 /api/streamB）共享同一个连接池，无法通过增加路径来绕过限制。
3. 连接释放的滞后性
即使前端调用了 EventSource.close()或 AbortController.abort()主动关闭连接，底层的 TCP 连接可能进入 TIME_WAIT状态，或者经过 HTTP 代理、CDN 时，上游连接的回收存在延迟。这会导致短时间内连续建立新连接时，仍能感受到"排队"现象。
4. 代理与 HTTP/2 的影响
- 反向代理 ：如果代理服务器对
text/event-stream类型的响应启用了缓冲，或设置了不合理的读写超时，会直接引发卡顿、断连等问题。 - HTTP/2：其多路复用特性可以有效缓解 HTTP/1.1 的连接数限制压力。但 SSE 在 HTTP/2 上的实际表现，需在目标部署环境下具体验证。
三、问题根因排查清单
遇到 SSE 延迟问题时，可对照下表快速定位可能的原因：
| 根因类型 | 具体表现与说明 |
|---|---|
| 同域多路长连接 | 页面内多个独立模块各自创建 SSE 连接，快速耗尽同 host 连接池。 |
| 未及时释放连接 | 组件销毁、路由切换后，未调用关闭方法，连接存活直至超时，持续占用名额。 |
| 重复建连 | 发起新请求前未取消旧的流，导致针对同一数据源存在多条并行流。 |
| 重连风暴 | 连接断开后，无退避机制的高频重试逻辑短时间发起大量请求，占满连接池。 |
| 部署环境问题 | 网关、代理或负载均衡器对 SSE 长连接的支持策略（如缓冲、超时、连接限制）配置不当。 |
四、分层解决方案
层级 1：架构与产品设计（优先考虑）
- 合并连接（首选） ：评估是否能让页面内的多个消费方共用一条 SSE 连接。服务端推送不同类型的事件，前端再根据事件类型分发。从源头上减少连接数。
- 拆分域名 ：如果必须使用多条独立连接，可将它们分配至不同的子域（如
stream-a.example.com,stream-b.example.com）。每个子域拥有独立的浏览器连接池。需注意 CORS、Cookie 作用域和运维成本。 - 降低非核心流实时性：对实时性要求不高的数据更新，改用短轮询或长轮询，将稀缺的长连接资源留给核心实时流。
层级 2：前端连接生命周期管理（必须遵守）
- 卸载即释放 ：在 SPA 或组件化框架中，务必在组件销毁的生命周期钩子（如
onBeforeUnmount,useEffect的清理函数）中，调用EventSource.close()或AbortController.abort()。 - 新请求前取消旧请求 ：在同一数据源发起新的 SSE 请求前，必须确保先取消（
abort）上一次的请求，防止旧的连接未被清理。 - 整页退出处理 ：监听
pagehide或beforeunload事件，主动关闭所有 SSE 连接，确保资源及时回收。
层级 3：实现模式参考
无论是使用原生的 EventSource还是基于 fetch的封装库（如 @microsoft/fetch-event-source），都应遵循以下模式：
scss
// 伪代码示例：基于 AbortController 的管理模式
let currentAbortController = null;
async function startNewSSEStream(url) {
// 1. 发起新请求前，先取消可能存在的旧请求
if (currentAbortController) {
currentAbortController.abort();
}
// 2. 创建新的控制器并发起请求
currentAbortController = new AbortController();
try {
const response = await fetch(url, {
signal: currentAbortController.signal
});
// ... 处理 SSE 流
} catch (err) {
if (err.name === 'AbortError') {
// 请求被正常取消，无需处理
return;
}
// 处理其他错误
}
}
// 3. 在组件卸载时清理
function onComponentUnmount() {
if (currentAbortController) {
currentAbortController.abort();
}
}最佳实践：将上述连接管理逻辑（创建、取消、清理）封装成可复用的 Hook、Composable 或高阶函数，避免在业务代码中散落重复的样板代码。
层级 4：重连策略
- 无需自动重连：对于一次性的流式请求（如导出、报告生成），失败后应由用户手动重试，无需在前端实现自动重连。
- 需要自动重连 ：对于需持久化的订阅型连接，应实现指数退避重试，并增加随机抖动，避免所有客户端同时重连形成"重连风暴"。同时设定最大重试次数上限。
层级 5：部署与协议优化
- 在 Nginx、HAProxy 等代理配置中，为 SSE 路径禁用响应缓冲，并设置适合长连接的、更长的超时时间。
- 确保生产环境启用了 HTTPS 并正确支持 HTTP/2，以利用多路复用特性提升连接效率。
五、总结
当使用 SSE 遇到性能问题时，请按以下思路排查：
- 首先检查连接层 ：通过浏览器开发者工具的 Network 面板，查看是否存在对同一域名的多个长时间存活的 SSE 连接（
Pending或Stalled状态）。 - 坚守前端纪律 ：务必做到"先取消，后新建"和"卸载即释放"。这是避免连接泄漏和排队的基础。
- 评估架构优化：优先考虑合并连接；若不可行，再评估拆分子域或调整非核心数据同步方式。
- 合理配置环境：与运维同事协作，检查网关和代理配置，确保其对 SSE 友好，并验证 HTTP/2 是否生效。
通过系统性地应用以上实践，可以有效解决 SSE 同域连接排队问题，提升流式应用的稳定性和用户体验。