数据与服务 · 运行与可靠性

实时连接WebSocket

WebSocket 先用一次 HTTP Upgrade 握手把 TCP 连接升级成持久的双向通道，之后双方随时互发帧，直到关闭——这就是实时双向通信的基础，还要配心跳保活与客户端重连。

握手一次，双向随时收发：WebSocket 帧控制台

WebSocket 把一条 TCP 连接变成持久的双向通道：点「建立连接」走一次 HTTP Upgrade 握手，之后双方随时互发帧；服务器还能主动往下推。每一次 ↑/↓ 都由你的点击产生——这就是 HTTP 一问一答模型做不到的实时双向。

未连接 DISCONNECTED无通道—

未连接。点「建立连接」发送 HTTP Upgrade 握手；握手完成后才能收发帧。每一条 ↑/↓ 都由你的点击产生，服务器不会自动推送。

给刚才操作过的部件命名，方便后面讲边界。

HTTP Upgrade 握手：连接先发 HTTP 请求，服务器回 101 Switching Protocols，同一条 TCP 连接就此升级为 WebSocket——握手只发生一次。
持久 + 全双工：握手后连接一直开着，双方都能随时发帧，不用反复建连；「发送消息」的 ↑ 和「服务器推送」的 ↓ 就跑在这同一条通道上。
服务器可主动推送：「服务器推送」按下才出现 ↓，客户端没有先发请求——这是 HTTP 请求/响应模型难以做到的实时推送。
帧是基本单位：日志里每一行就是一帧，带方向、类型和负载；业务消息、心跳、关闭都是帧。
心跳保活：ping ↑ / pong ↓ 探测连接是否还活着，避免空闲连接变成没人发现的「半开」死连接。
客户端重连：连接会断，客户端必须实现重连；真实场景里重连后通常先拉最新快照或增量，补齐断线期间错过的状态。

不是所有「实时」都该用 WebSocket；按方向和频率选协议。

用 WebSocket

双向实时：聊天、协同编辑、多人游戏、实时仪表盘且需要客户端也回传、推送通知带交互。需要双方随时互发帧时首选。

换 SSE（Server-Sent Events）

只需要服务器单向推送、客户端不用回传时（行情、通知流、日志尾随）。SSE 比 WebSocket 轻，跑在普通 HTTP 上。

换普通 HTTP / Streaming

偶尔拉一下数据用 fetch 就够；大模型生成那种「边产生边输出」的单向流，可以用 HTTP streaming 或 SSE，不必上 WebSocket。

把一条实时通道从打开到恢复串起来。

用 WebSocket 时要盯这些：断线能被感知并有重连策略、重连后数据能补齐（快照或版本号幂等）、消息有 schema/版本/幂等 id 避免重复应用、失败有降级（轮询或提示离线），连接状态有文字和 aria-live 反馈而不只靠绿点。

同一个「多人协同编辑里同步 A 同学的光标给 B 同学」的目标，关键差别在协议选不对。

正例WebSocket 双向推送 + 版本号 + 重连补快照

UPGRADE → 101 · server ↓ cursor(v=42)

一条持久连接，服务器主动把光标 ↓ 推给所有人；每条消息带版本号，B 断线重连后先拉快照再继续收新帧，重复版本号直接丢弃。结果：延迟低、不丢光标、不重复画线。

反例用 HTTP 每 2 秒轮询 /cursors 拉最新

GET /cursors → 200 · (每 2s 一次)

没有真正的「推送」：服务器有新光标也得等下一次轮询才能被拉走，延迟最高 2 秒；空闲时还在不停发空请求浪费流量；多人快速移动时还会乱序。这是把 HTTP 当万能锤的典型反例。

实时白板里，服务器要把 A 的光标推给 B，但 B 刚好断网 3 秒后重连。要让 B 不丢光标、也不把同一条画两遍，哪种做法对？

术语的技术定义和行为以这些一手或权威资料为准。

和本知识点经常一起出现的概念。