在多模型协同推理场景中，Server-Sent Events（SSE）凭借其轻量级、基于 HTTP 的单向通信特性，成为流式补全的优选方案。相较于 WebSocket 的双向复杂性，SSE 依托现有 HTTP 基础设施，能更高效承载 LLM、TTS 等多模型输出流。然而，网络波动导致的连接中断会破坏用户体验，需通过断线续传机制与精细化参数配置保障服务连续性。
SSE 的断线续传核心在于 Last-Event-ID 机制。当客户端因网络问题断开连接，浏览器会自动携带最后接收到的事件 ID 发起重连请求。服务端通过解析 Last-Event-ID 头部，定位到中断位置并继续推送后续数据。MDN 明确指出："服务器可通过 ID 字段标记事件，客户端在重连时自动发送该 ID"。这一特性使多模型服务无需维护长连接状态，仅需在内存或缓存中保留最近 10 秒的事件队列，即可实现精准续传。例如，当用户同时调用文本生成与语音合成模型时，服务端为每个会话分配唯一 ID，断连后通过 ID 恢复双模型输出流。
工程化落地需重点关注三个参数阈值：
- 重连间隔（retry）：SSE 协议允许服务端通过
retry: 2000 指令设定客户端重试延迟。默认值 3000ms 过长，建议根据模型响应速度压缩至 1500-2500ms。对于延迟敏感的语音流场景，可动态调整为 800ms，但需权衡服务器压力。
- 连接超时（timeout）：Nginx 等反向代理需设置
proxy_read_timeout 60s，避免空闲连接被提前切断。若模型推理耗时波动大（如图像生成），应将超时阈值提升至 120s，同时客户端设置 90s 心跳检测。
- 事件缓冲深度：服务端应限制单连接事件缓存数量，推荐保留最近 50 条事件（约 50KB）。当用户连续断连 3 次后，触发回滚策略——切换至分块传输（chunked transfer）降级输出，确保基础功能可用。
监控层面需建立两级预警：当单节点连接重试率超过 15% 时，自动扩容 SSE 处理实例；若 Last-Event-ID 匹配失败率突增至 5% 以上，立即检查事件 ID 生成逻辑是否冲突。某电商客服系统实践表明，通过将重连间隔压缩至 1800ms 并设置 30s 心跳包，流式响应中断率从 7.2% 降至 1.3%，同时服务器资源消耗降低 22%。
最后需注意 SSE 的固有局限：单连接仅支持服务器到客户端通信，且最大并发连接数受浏览器限制（通常 6 个/域名）。对于需要双向交互的复杂场景，建议采用 SSE + WebSocket 混合架构——用 SSE 承载模型输出流，WebSocket 处理控制指令。通过 Nginx 的 sub_filter 模块统一域名，可规避连接数瓶颈。当前主流云服务商已提供 SSE 连接管理中间件，开发者仅需配置参数即可实现企业级流式服务。
参考资料：MDN Web Docs《Using server-sent events》详细说明了协议规范与实现细节，是构建可靠 SSE 服务的基础依据。