WebRTC 工作流程与多人架构

一对一连接流程

1. 双方通过信令服务进入同一会话。
2. 采集本地媒体：getUserMedia() 或 getDisplayMedia()。
3. 创建 RTCPeerConnection，配置 STUN/TURN，并以 addTrack() 添加本地轨道。
4. 发起方创建 offer，设置本地描述后经信令发送。
5. 接收方设置远端描述，创建 answer、设置本地描述并回传。
6. 双方持续交换 ICE 候选；ICE 选择直连或 TURN 中继路径。
7. 远端通过 track 事件取得 MediaStream，赋给音视频元素播放。
8. 通话结束时停止本地轨道、关闭 RTCPeerConnection，并通知信令服务。

多人架构

架构	特点	适用场景
Mesh	每个参与者与其他人分别建连；客户端上行随人数增长	少量参与者的一对多或临时房间
SFU	客户端上行一份，服务端选择性转发给其他人	多人会议、互动直播，主流方案
MCU	服务端解码、混流/转码后下发	需要服务端合成单路视频的特定场景

SFU 不等于“服务端不耗带宽”：它不做或少做媒体混合，但会承担大量入站与出站转发；客户端通常只维护一个到 SFU 的 PeerConnection，并在其中接收多个远端轨道。

状态与故障处理

• 监听 connectionstatechange 与 iceconnectionstatechange；failed 通常应尝试 restartIce() 或重新建连。
• disconnected 可能是短暂网络波动，不宜立即销毁连接；以业务超时和状态恢复策略决定重连。
• 屏幕共享停止时，对应轨道会结束，应移除或替换轨道并触发重新协商。
• 用 getStats() 观测往返时延、抖动、丢包、编码码率和候选类型；不要仅以“已 connected”判断通话质量。

部署检查

• 页面、信令和 TURN 均使用 HTTPS/TLS；配置可用的 UDP 与 TCP/TLS TURN 入口。
• 反向代理正确处理信令 WebSocket 的 Upgrade 与超时；TURN 不应按普通 HTTP 代理。
• 为 TURN 配置短期凭证、带宽限额、地域和监控告警。
• 先在受限网络、移动网络和多浏览器环境验证 TURN 回退，再上线多人场景。