基础与协议
WebRTC 的复杂度不在 API，而在协议族。这一节回答两件事：它在做什么，以及为什么需要这么多协议。
阅读顺序
| 顺序 | 文件 | 解决的问题 |
|---|---|---|
| 1 | WebRTC定位与边界.md | 与 WebSocket、HLS、RTMP、SIP 怎么区分，什么时候选 WebRTC |
| 2 | 一次通话的完整时序.md | 从 getUserMedia 到 SRTP 的全链路时序图 |
| 3 | 核心协议族速查.md | ICE、STUN、TURN、SDP、DTLS、SRTP、SCTP 的职责与边界 |
| 4 | SDP结构详解.md | m-line、a-line、bundle、rtcp-mux、ssrc 等关键字段 |
| 5 | 安全模型与权限.md | HTTPS 强制、权限、IP 泄露、设备指纹 |
一句话定义
WebRTC 是浏览器和原生客户端之间直接交换实时音视频和任意数据的标准化能力，由 W3C（JS API）和 IETF（线协议）共同定义。
心智模型
应用层 MediaStream / RTCPeerConnection / RTCDataChannel
协商层 SDP（Offer/Answer）+ 信令通道（业务自定义）
传输层 ICE → STUN（发现公网映射）/ TURN（中继兜底）
安全层 DTLS-SRTP（媒体加密）/ SCTP-over-DTLS（数据通道）
四层全部需要，缺一不可。
为什么这么复杂
- 要穿透 NAT：90% 的客户端在 NAT 后面，必须有 ICE/STUN/TURN。
- 要端到端加密：浏览器强制 DTLS-SRTP，没办法关。
- 要对齐能力：发送方和接收方的编解码、分辨率、扩展头协商靠 SDP。
- 要实时：丢包优先丢、不要重传超时；这导致它选了 UDP 而不是 TCP。
- 要标准化：跨厂商互通需要 IETF 一系列 RFC，而不是 vendor-specific 协议。
标准沿革
| 年份 | 里程碑 |
|---|---|
| 2011 | Google 收购 GIPS，开源 webrtc.org |
| 2012 | W3C WebRTC 1.0 工作草案 |
| 2017 | RFC 8445（ICE bis）发布 |
| 2018 | Unified Plan 取代 Plan B |
| 2021 | W3C WebRTC 1.0 成为 Recommendation |
| 2022+ | WebRTC-NV：Insertable Streams、WebCodecs、WebTransport |
| 2023 | WHIP/WHEP 标准化（IETF）：低延迟直播标准 |
| 2024+ | AV1 在 Chrome / Edge 默认开启，Safari 仍以 H.264 为主 |
与相邻技术的边界
| 技术 | 适用场景 | 与 WebRTC 的关系 |
|---|---|---|
| WebSocket | 双向消息 | 信令层常用，不能传媒体 |
| HLS / DASH | 大规模点播/直播 | 高延迟（3~30s），WebRTC 用于亚秒级实时 |
| LL-HLS | 低延迟直播 | 1~3s 延迟，比 WebRTC 简单但延迟更高 |
| RTMP | 推流 | 已被浏览器淘汰，常用于 OBS 推到 SFU |
| SIP | 传统电话 | 通过网关与 WebRTC 互通（如 FreeSWITCH） |
| WebTransport | 双向数据传输 | 未来可能取代 DataChannel 的部分场景 |
失败模式（这一层最常见的坑）
| 现象 | 根因 | 排查 |
|---|---|---|
getUserMedia 直接报错 | 非 HTTPS 环境 | 浏览器要求安全上下文，localhost 例外 |
| ICE 收集为空 | 浏览器扩展拦截 / Firefox 隐私模式 | 看 chrome://webrtc-internals |
候选只有 mDNS（*.local） | Chrome 默认隐藏本地 IP | 服务器侧无法解析时需要部署 TURN |
| Offer 设置成功但无 ICE 候选 | 没监听 icecandidate 事件 | 必须等 Trickle ICE 完成或 iceGatheringState === 'complete' |
| DTLS 失败 | 证书指纹不匹配 / 时间不同步 | 看 connectionState 与 webrtc-internals 的 DTLS 握手日志 |