用 SSE 承载多模型流式补全：断线续传与超时参数

在多模型流式补全场景中，Server-Sent Events (SSE) 因其基于 HTTP 的简单性、浏览器原生支持以及自动重连能力，成为比 WebSocket 更轻量且更易集成的选择。然而，要确保在复杂网络环境和长时间会话中提供稳定、连续的用户体验，必须对连接管理、超时控制和断线续传机制进行精细化的工程化设计。本文将聚焦于可落地的参数配置、服务端实现要点与客户端健壮性策略，而非复述协议基础。

首先，理解 SSE 的自动重连机制是设计的基础。浏览器原生的 EventSource API 在连接意外断开（如网络抖动或服务器重启）后，默认会以 3 秒的间隔尝试重新连接。这个行为是自动的，但过于简单。在生产环境中，我们需要对其进行增强。关键的第一步是服务端通过发送 retry: <milliseconds> 字段来动态调整客户端的重连间隔。例如，在服务器负载较高时，可以发送 retry: 10000，指示客户端 10 秒后再重试，避免雪崩式重连压垮服务。更重要的是，客户端应实现指数退避算法。初始重连延迟可设为 1 秒，每次失败后延迟时间翻倍（2秒、4秒、8秒...），直至达到一个上限（如 60 秒）。这能有效防止在网络持续不稳定时对服务器造成过大压力。同时，应设置一个“退避重置阈值”，例如，如果连接稳定保持超过 60 秒，则将重连计数器归零，以便下次断开时从最小延迟开始，恢复快速响应能力。

其次，维持长连接的活性是防止被中间件（如 Nginx、防火墙或云服务商的负载均衡器）主动断开的关键。这些中间件通常有默认的空闲超时设置（如 60 秒）。解决方案是在服务端实现心跳机制。这并非发送业务数据，而是定期（如每 15-25 秒）发送一个特殊的注释行（Comment Line），其格式为以冒号开头，后跟任意内容并以双换行结束，例如 : heartbeat\n\n。客户端会忽略这些注释行，但它们能有效重置中间件的空闲计时器，保持 TCP 连接的活跃状态。心跳间隔的设置至关重要：它必须小于所有路径上中间件中最短的 proxy_read_timeout 或 keepalive_timeout。一个保守的工程实践是将心跳间隔设为 25 秒，这通常能兼容大多数默认配置为 30-60 秒超时的环境。

第三，实现真正的“断线续传”依赖于服务端对 Last-Event-ID 请求头的支持。当客户端因断线而重连时，浏览器会自动在新的 HTTP 请求中带上 Last-Event-ID 头，其值为上次成功接收的消息的 id 字段。服务端必须在每次发送消息时，为每条消息分配一个唯一的、递增的 id 字段（例如 id: 12345\n）。在收到带有 Last-Event-ID 的请求时，服务端应从该 ID 之后的消息开始推送，确保客户端不会丢失任何中间数据，也不会重复接收已处理的消息。这对于流式补全过程至关重要，可以保证用户看到的文本是连贯的，不会出现跳跃或重复。若服务端未实现此功能，则所谓的“续传”只是从头或从当前最新位置开始，会破坏用户体验。

最后，工程化部署离不开对关键参数的配置和监控。在服务端，Nginx 或其他反向代理的配置是重中之重。必须设置 proxy_buffering off; 和 proxy_cache off; 以确保事件流能实时透传，而非被缓冲。同时，proxy_read_timeout 和 proxy_send_timeout 应设置为远大于心跳间隔的值，例如 300s（5分钟），以适应长连接特性。在客户端，除了前述的指数退避，还应监听 onerror 事件，不仅用于触发重连，还应记录错误日志，区分是网络错误、HTTP 4xx/5xx 错误还是致命的协议错误（如内容类型不匹配），以便进行不同的处理（例如，对于 401 或 404 错误，应永久关闭连接而非重试）。监控方面，应追踪三个核心指标：一是“平均连接存活时间”，若远低于预期（如小于5分钟），则表明存在频繁断开问题；二是“5分钟内非正常关闭次数”，用于告警；三是“每个连接的内存占用”，防止资源泄漏。通过结合这些参数、机制与监控，SSE 方能真正胜任多模型流式补全的高要求场景，提供稳定、可靠、连续的用户体验。