46 篇博文 含有标签「深度解析」

"我们早期押注多播，但公网教会了我们：你需要的是 packet shufflers，不是 multicast routers。" — Serge Lachapelle，Curious 历史访谈

本系列从 P2P（Ch2）走来，现在进入多人会议的架构选型。Marratech 是瑞典最早的 Web 视频会议公司之一，2009 年被 Google 收购——Serge Lachapelle 随之加入 Google，成为 WebRTC 标准化的核心推动者。他在 Curious 访谈中回忆：Marratech 早期押注 IP 多播，后来行业转向 packet shufflers——即今天的 SFU（Selective Forwarding Unit）。

配套 Lab：examples/webrtc-lab/client/ch12-sfu-client（LiveKit 客户端）+ examples/webrtc-lab/signaling/。

"从多播幻想到 packet shufflers——SFU 是 WebRTC 多人会议的必然归宿。" — WebRTC for the Curious 历史

Ch9 Simulcast 入门 介绍了三档发布。本章深入 SFU 如何根据订阅者带宽选择转发层——这是从 P2P 跃迁到多人会议的核心机制。

Marratech 早期押注 IP 多播（Multicast），Serge Lachapelle 在 Curious 访谈 中回忆：公网多播从未真正落地，行业最终转向 packet shufflers（SFU）——Simulcast + 选择性订阅是 SFU 的标配能力。Google 2010 年收购 Marratech 后，这套架构在 Meet 中大规模验证。

配套 Lab：examples/webrtc-lab/client/ch02-p2p-basic 扩展 Simulcast + client/ch12-sfu-client（LiveKit）。

"拥塞控制不是可选项——它是实时通信能否在公网上存活的核心。" — webrtcH4cKS

Ch8 RTCP 介绍了 TWCC、REMB 等反馈机制。本章深入 Google Congestion Control（GCC）——WebRTC 发送端如何根据网络状况动态调整码率。GCC 由 Google 在 2010 年代为 Hangouts / Meet 打磨，Serge Lachapelle 在 Curious 历史访谈 中回忆：Marratech 时代网络质量波动极大，自适应码率是从「能通」到「能用」的分水岭。

配套 Lab：基于 examples/webrtc-lab/client/ch02-p2p-basic 扩展带宽监控脚本；信令服务见 examples/webrtc-lab/signaling/server.js。

Ch4 SDP 协商的核心是编解码器选择——a=rtpmap 行的背后，是数十年来视频压缩技术的积累。Ron Frederick 在 1992 年为实现 nv 工具而手写软件视频压缩（Curious — RTP 历史），因为 MPEG-1 当时无法实时编码——今天 WebRTC 的 Codec 选择同样是在压缩率、延迟、专利、硬件加速之间权衡。

音频方面，Opus 的故事同样精彩：Skype 团队在收购后于 2010 年 IETF 会议上推动 Opus 标准化，Maastricht 午餐会时已完成大部分工作（Curious 历史）。Opus 继承了 Skype 的 SILK 和 Xiph 的 CELT 两条技术路线，成为 WebRTC 唯一的「指定音频编解码器」。

本章覆盖 RFC 7587 Opus、VP8/VP9/H.264/AV1 对比、Simulcast 三档发布与 RTCRtpEncodingParameters 实战配置。

Ch7 DTLS/SRTP 建立加密通道后，音频和视频以 RTP 包在 UDP 上传输。RFC 3550 定义了 RTP/RTCP——它的历史可追溯到 1992 年 Ron Frederick 的 nv 工具与 MBONE 多播实验（详见 Curious — RTP 历史）。

Frederick 在访谈中说：「如果一个东西需要实时数据流，又无需精确时序传输，它就可以从 RTP 中受益。」他最初为 MBONE 多播场景设计 RTP，后来 RTP 成为互联网实时音视频的事实标准。WebRTC 在 RTP 之上叠加了 SRTP 加密、AVPF 反馈 profile 和 TWCC 拥塞控制，但 RTP 包头结构与核心语义 thirty 年来未曾改变。

本章覆盖 RFC 3550 RTP 包头、RTCP SR/RR/NACK/PLI/TWCC、Jitter Buffer、FEC 策略，以及 getStats() 诊断实战。

Ch5 ICE 连通 UDP 通道后，媒体并非明文传输。WebRTC 强制走 DTLS 握手 → 导出 SRTP 密钥 → 加密 RTP，这是 RFC 8827 WebRTC Security Architecture 的核心要求。

理解这一层的设计意图：Gmail 语音视频聊天时代，安全是事后补丁；WebRTC 从标准化之初就将 默认加密 作为不可协商的底线（参见 Curious — WebRTC 历史 中「安全是重中之重」）。Google 工程师在 2010 年前后推动 DTLS-SRTP 成为唯一媒体保护方案，彻底告别了早期 VoIP 明文 RTP 的惯例。

Curious 历史 中，Serge Lachapelle 回忆：收购 GIPS 后，团队内部曾激烈讨论「是否允许开发者关闭加密」。最终结论是一刀切——媒体必须加密，没有开关。这一决策直接写进了 RFC 8827：a=crypto（SDES）被废弃，DTLS-SRTP 是唯一允许的密钥协商方式。对开发者而言，这意味着你永远不会在 chrome://webrtc-internals 里看到明文 RTP 载荷——除非主动做 E2EE 之上的二次加密。

本章覆盖 RFC 6347 DTLS 握手、RFC 5764 密钥导出、RFC 3711 SRTP 包处理、Certificate Fingerprint 验证，以及 Insertable Streams 端到端加密入门。

"媒体走 RTP，数据走 SCTP——WebRTC 用两条逻辑通道完成实时通信的全部载荷。"

WebRTC 三大核心 API：getUserMedia（Ch1 采集媒体）、RTCPeerConnection（Ch2 建立连接）、RTCDataChannel（本章 传输任意数据）。Data Channel 让你在已建立的 DTLS 加密通道 上，以 P2P 方式传输文本、二进制、文件——无需额外服务器中转。

与 MBONE 多播时代「一份数据广播给所有人」不同（见 Curious — 历史），Data Channel 是单播 P2P 模型：每个 PeerConnection 只有两端，数据经 ICE 选出的最优路径直达对端——或经 TURN 中继（Ch5）。Ron Frederick 曾设想用 RTP + IP 多播做文件传输——「原始的做种者可以立即将多播流发送到所有接收者」——但 WebRTC 选择了更务实的路径：在已建立的 DTLS 通道上用 SCTP 做可靠/部分可靠的消息传输。

本章覆盖 RTCDataChannel API、SCTP over DTLS 协议栈、DCEP 建立协议、有序/无序传输、背压控制、文件分片传输，以及与 WebSocket 的架构对比。

配套代码：examples/webrtc-lab/client/ch06-data-channel/

"70% 的 WebRTC bug 与 NAT 有关。" — 业界经验总结

Ch4 SDP 中的 a=ice-ufrag、a=ice-pwd 只是凭证；真正让两个浏览器在 NAT 后面找到彼此、建立 UDP 通道的，是 ICE（Interactive Connectivity Establishment）——RFC 8445 定义的标准算法。

1990 年代 MBONE 多播时代，发送者只需向多播组发一次包，路由器负责复制给所有订阅者。Ron Frederick 在 WebRTC for the Curious — 历史 中回忆：他和同事都是 IP 多播研究者，用 nv 工具向整个 Internet 广播会议视频——一份数据包，数百个子网同时接收。Serge Lachapelle 则描述了另一条演进路线：他创办的 Marratech 最初也依赖多播网络，「服务器可以非常简单，因为网络负责把视频包复制给通话中的每一个人」——但「必须设计网络以适配多播模式」这一致命缺点，最终推动行业从多播转向 SFU（packet shufflers）。

WebRTC 运行在没有多播的公网上。IPv4 地址耗尽催生了 NAT 的大规模部署，每个参与者必须找到与对端通信的具体 IP:Port 路径。从「一对多广播」到「点对点单播」的设计转折，是理解 ICE 存在原因的关键背景。

本章深入 ICE 状态机、Candidate 类型、STUN/TURN 协议细节、Trickle ICE 优化，以及生产环境中最常见的穿透失败排查路径。

配套 Lab：examples/webrtc-lab/docker/coturn/ + client/ch02-p2p-basic/

"Offer/Answer 里那一大段文本，就是整个 WebRTC 会话的「合同」。"

Ch3 信令 负责传递 SDP，但 SDP 本身是什么？Ch2 中 createOffer() 产出的字符串，遵循 RFC 8866 SDP 格式。它描述了：用什么编解码器、用什么 ICE 凭证、用什么 DTLS 指纹、媒体方向是什么。

本章逐行解剖 WebRTC 中的 SDP，理解 Unified Plan、BUNDLE、rtcp-mux，以及 RTCRtpTransceiver 与 m-line 的对应关系。

"WebRTC 只标准化媒体通道，信令 deliberately 留给应用层。" — WebRTC for the Curious

Ch2 我们用手工复制 JSON 完成了 Offer/Answer 和 ICE Candidate 交换——这足以理解原理，但无法支撑生产。Serge Lachapelle 在 Curious 历史访谈中明确提到：IETF 刻意不对信令重新标准化，因为 SIP 等方案已存在，重新标准化只会引发政治斗争且「不会创造有价值贡献」。

因此，每一个 WebRTC 应用都必须实现自己的信令层。本章从设计原则出发，构建一套可扩展的 WebSocket 信令服务器，并讨论生产环境的安全、重连与 Room 状态管理。

配套代码：examples/webrtc-lab/signaling/