不靠运气建连：WebRTC 信令状态机的生产级设计与治理

WebRTC 信令本身不在标准里强制规定传输协议，但这并不意味着你可以“随便发 JSON”。在真实业务中，建连失败、重协商打架、多人房间状态漂移，几乎都源于信令模型不完整。把信令做成显式状态机，是从“能跑”到“可生产”的分水岭。本文给出一个偏工程治理的方案：不只讲 Offer/Answer，还覆盖发布策略、容量成本和故障处置。

一、问题本质：信令不是消息流，而是受约束的状态迁移

很多实现把信令写成事件回调拼接：收到 offer 就 setRemoteDescription，收到 candidate 就 addIceCandidate。这种写法在理想网络下能工作，但在乱序、重试、断线重连场景会快速失控。典型故障包括：

旧会话的 candidate 混入新会话，导致 ICE 一直 checking。
双端同时发起重协商（glare），彼此覆盖 SDP。
信令重放后重复应用，出现 InvalidStateError。
会话恢复时缺少版本号，端上状态和服务端状态发生漂移。

这些问题的共同点是：消息处理缺乏前置条件校验。状态机的价值就在这里，它把“允许什么动作”定义成规则，任何越界动作都可拒绝并记录原因。

二、架构设计：控制面、传输面、执行面三层解耦

建议把信令系统拆成三层：

控制面（Session Controller）：维护会话生命周期、版本号、角色（polite/impolite）。
传输面（Signal Transport）：负责投递、重试、去重、顺序控制，可用 WebSocket 或 QUIC 通道。
执行面（Peer Executor）：把合法动作映射到 WebRTC API 调用，并回填结果事件。

分层收益有三点：

业务规则变更不必改底层传输。
传输切换（如从 WS 到 MQ 网关）不影响状态逻辑。
排障时可以定位“规则错”还是“投递错”。

三、核心状态机：把 Offer/Answer 与重协商规则固定下来

下面是一个可实战的精简模型。你可以按业务扩展，但不建议删掉守卫条件。

stateDiagram-v2
    [*] --> Idle
    Idle --> CreatingOffer: start_call
    Idle --> WaitingOffer: incoming_call

    CreatingOffer --> LocalOfferSet: setLocal(offer)
    LocalOfferSet --> WaitingAnswer: send_offer
    WaitingAnswer --> Stable: setRemote(answer)

    WaitingOffer --> RemoteOfferSet: setRemote(offer)
    RemoteOfferSet --> Answering: create_answer
    Answering --> Stable: setLocal(answer)+send

    Stable --> Renegotiating: onnegotiationneeded
    Renegotiating --> CreatingOffer: polite_or_retry

    Stable --> RestartIce: ice_failure
    RestartIce --> CreatingOffer: createOffer(iceRestart)

    state Conflict {
      [*] --> GlareDetected
      GlareDetected --> RollbackLocal: polite
      GlareDetected --> IgnoreRemote: impolite
      RollbackLocal --> WaitingOffer
      IgnoreRemote --> Stable
    }

    CreatingOffer --> Conflict: remote_offer_while_have_local_offer
    Renegotiating --> Conflict: simultaneous_offer
    Stable --> Closed: hangup_or_timeout

状态机落地时要配套三类守卫：

版本守卫：每条信令附带 session_version，只接受新版本。
会话守卫：call_id 与 peer_id 必须匹配当前上下文。
状态守卫：仅在允许状态执行 API，越界动作进入死信队列。

四、冲突处理：Perfect Negotiation 不是示例代码，而是生产准则

MDN 的 Perfect Negotiation 模式本质是角色协作协议。建议固定两类角色：

polite：发生 glare 时执行 rollback，接纳对端 offer。
impolite：发生 glare 时忽略冲突 offer，坚持本地流程。

注意三点工程细节：

角色要随会话确定，不能频繁切换。
rollback 成功后必须清理待发队列，避免旧 candidate 污染新 SDP。
glare 事件要单独监控，突增通常意味着重协商触发条件失控。

五、传输协议设计：幂等、顺序、重试窗口缺一不可

信令通道不可靠时，系统必须靠协议补全可靠性。推荐信令消息统一字段：

message_id：全局唯一，用于幂等去重。
call_id：会话标识。
seq：会话内单调递增序号。
type：offer/answer/candidate/bye/ack。
ts：发送时间戳。
ttl：过期时间，超时后丢弃。

处理规则：

小于等于已处理 seq 的消息直接丢弃。
超过窗口上限的乱序消息进入暂存区，超时后清理。
关键消息（offer/answer）必须 ACK，失败后指数退避重试。

这套规则的目标不是“绝不丢”，而是“丢了也可收敛”。

六、质量治理：把建连成功率拆成可运营指标

建议建立四层指标树：

会话层：建连成功率、首帧时延、重协商成功率。
协议层：offer/answer 往返时延、candidate 收敛时长、ACK 超时率。
状态层：非法状态迁移次数、rollback 次数、死信队列长度。
体验层：通话中断率、用户主动重连率、投诉率。

发布治理上，任何状态机规则变更都必须有“前后对比报告”：

是否降低建连失败。
是否引入新的长尾时延。
是否影响特定平台（iOS Safari、低端安卓 WebView）。

没有这一步，信令改造很容易变成“看似优雅、实则不可验证”。

七、容量与成本：信令看似轻量，扩容做错会很贵

信令流量本身不重，但错误设计会放大平台成本：

无幂等导致重复消息风暴，网关连接数激增。
缺少会话过期回收，内存中残留大量僵尸状态。
重协商过频触发 SDP 计算和日志写入，抬高 CPU 与存储成本。

容量规划建议关注三条线：

每秒新建会话峰值（决定控制面吞吐）。
平均会话时长与在线连接数（决定网关连接池）。
每会话消息量分布（决定日志与消息队列成本）。

要特别防范“异常风暴日”：比如某区域网络抖动，客户端批量重连，会让信令系统瞬时放大数十倍流量。必须预置限流和降级策略，例如暂停非关键重协商，优先保障新建会话。

八、生产排障：把复杂故障压缩成标准决策树

1) 建连失败率突升

优先检查：

是否某版本客户端上线后 setRemoteDescription 报错增加。
是否信令 ACK 超时突增，提示传输层拥塞。
是否 ICE gather 超时，提示候选采集异常。

2) 重协商失败集中

优先检查：

onnegotiationneeded 是否被业务逻辑高频触发。
glare 指标是否上升，角色分配是否失效。
轨道移除/新增顺序是否破坏状态机守卫。

3) 区域性故障

优先检查：

该区域信令接入点健康度与延迟。
会话粘滞策略是否失效导致跨区漂移。
证书或时间同步异常导致 DTLS 相关流程失败。

排障过程中，务必把“错误码 + 状态快照 + 最近 20 条消息”做成一键导出。没有最小上下文，排障只会反复猜测。

九、实施路线：三阶段替换旧信令，不做一次性重构

包裹旧逻辑：先引入状态守卫与日志，不立即改传输。
灰度新状态机：按会话分桶启用，失败自动回旧链路。
收敛历史负担：下线无用事件类型，清理兼容分支。

每阶段都要定义可验收指标，而不是“代码完成”。例如阶段二至少要看到：

非法状态迁移下降 50% 以上。
重协商失败率不高于旧逻辑。
平均建连时延不劣化。

十、结语：信令状态机是实时系统的“法律”

WebRTC 的媒体面再强，如果信令面无序，最终体验依然不可控。最有效的做法不是写更多补丁，而是建立一个有边界、有守卫、有观测的状态机体系。它会在平时让系统更稳定，在事故时让团队更快定位，在业务增长时让容量更可预测。