WebRTC 标准不规定信令协议。这一节回答：信令该怎么设计、ICE 怎么工作、TURN 怎么部署、Perfect Negotiation 怎么写。
阅读顺序（计划）
| 顺序 | 文件 | 解决的问题 |
|---|
| 1 | 信令协议设计.md | 房间模型、消息类型、Offer/Answer 状态机 |
| 2 | Perfect-Negotiation模式.md | glare 处理、polite/impolite 角色 |
| 3 | ICE全流程.md | 候选类型、Trickle、连通性检查、ICE Restart |
| 4 | coturn部署实战.md | 配置、短期凭据、TLS、TCP 兜底 |
| 5 | 企业网与移动网穿透.md | 对称 NAT、IPv6 双栈、4G/Wi-Fi 切换 |
本目录详细内容尚在补全中。在补完前，先看 02-浏览器三大API/RTCPeerConnection.md 的 Perfect Negotiation 模板。
信令的最小职责
| 职责 | 必做 | 备注 |
|---|
| 加入/离开房间 | ✅ | 房间是逻辑分组 |
| 转发 SDP（offer/answer） | ✅ | 不解析内容，直接转 |
| 转发 ICE 候选 | ✅ | 高频，注意限流 |
| 鉴权 | ✅ | JWT / 短期 token |
| 断线重连 | ✅ | 客户端要保留 sequence |
| 状态广播 | 可选 | 谁在房间、谁举手 |
| 持久化 | 可选 | 消息历史看业务 |
推荐选型
| 规模 | 协议 | 推荐实现 |
|---|
| 1v1 / Demo | WebSocket (raw) | ws（Node）/ FastAPI WebSocket |
| 多人会议 | Socket.IO / WebSocket | LiveKit 自带 / mediasoup 用 protoo |
| 大规模 | Socket.IO + Redis 适配器 / 自研 | 横向扩展 |
| 跨平台 | MQTT | 与 IoT 共栈 |
反模式
| 反模式 | 后果 |
|---|
| 信令 = WebRTC | 把信令协议塞进 WebRTC 标准 |
| 不处理 glare | 双方同时 offer 卡死 |
| 信令断了立刻销毁 PC | 媒体本来还能跑，被白白杀掉 |
| 不限速 ICE 转发 | 攻击者刷信令拖垮服务端 |
权威资料