关于WebSocket承载大体积数据的问题：慢链路下心跳误杀 + 整窗重发风暴

[ClouderSky]

环境

• dsh web（0.1.2-rc.1）。
• 自建反向网关（含身份认证）部署在一台公网云服务器上，总出网带宽仅 1 Mbps；
  通过该网关远程访问 dsh web，在家庭宽带、办公网络、移动网络下均能复现。

现象

• 远程使用中连接频繁断开重连，控制台反复出现 [connection] connection lost, retry #1；
• 提问/审批弹窗出现瞬间消失（断连导致在途 waterfall 事件被 abort）；
• 刷新页面后近期内容能成功渲染出来，但随后 WS 仍反复拉取同一份大快照，直至长时间"静默死等"，只能再次手动刷新；
• 公网带宽越紧张、会话历史越大，现象越严重。

复现与证据（headless Chromium + CDP 逐帧抓取）

场景	结果
空闲 WS（不跟随会话），公网路径	10+ 分钟零断连
跟随大会话，本地直连服务端	零断连
跟随大会话，公网路径	每次重连后收到单条 ~1.6MB 快照帧，约 13s（≈1.6MB @ 1Mbps）后连接被异常终止 → retry #1 → 整窗重发 → 循环
跟随小会话，公网路径	零断连

• 快照帧实为**会话尾窗（最近 ≤50 条 user/assistant 消息）**的序列化，非整场历史；体积只取决于尾窗真实载荷，可到 MB 级。
• 将心跳间隔从默认 2000ms 调到 30000ms 后断连消失，公网带宽占用随之下降（重连风暴停止）。

根因分析

1. 心跳与数据同队列、无优先级：WS Ping/Pong 控制帧与数据帧在同一个 TCP 发送队列里排队。链路满载超过约 4–6s（心跳 2000ms × 连丢 2 次即 socket.terminate()）时，Ping 被大帧压后，服务端按"发出时间"判定超时 → 误杀"慢但健康"的连接。
2. 会话跟随快照无分帧、无体积上限、无 WS 压缩：每条流 item 整体序列化、单条 WS 消息写出；日志 append-only，compaction/pruner 只做表层遮蔽、不删已落字节 → 帧大小无官方旋钮可限。
3. 断连后重连整窗重发：无逐段 ack/resume，慢链路下形成"重连 → 大帧 → 再断"的正反馈风暴。

观点（欢迎讨论）

坚持"WS 传信号、HTTP 传数据"的分层原则：体积不可预知/可能很大的批量内容（会话尾窗快照、历史分页）应走 HTTP（dsh 已有 session/page 分页接口与 SSE 先例），WS 只承载有界、实时、交互性的信号与增量；快照与增量之间用 cursor 握手衔接，保证有序、无缝隙、可续传。

退而求其次的近期可选改动：

• 心跳超时应感知数据是否仍在推进（有字节流动时不计 miss）；
• 为单条 WS 帧设体积上限，或对超大窗口做分片下发；
• 客户端重连携带已收 seq，做增量续传而不是整窗重发。

临时止血（已在生产验证）

在 profile 补丁层（$DSH_HOME/profiles/web/cordis.patch.yml）覆盖 typert-gateway：

- id: typert-gateway
  config:
    websocketHeartbeatIntervalMs: 30000

注：心跳仍保留兜底（约 60s 内可感知死连接），只把误杀窗口放宽到慢链路的安全区。