In-depth technical articles
View all tags
"TURN 是 WebRTC 基础设施中带宽成本最高的组件——relay 流量约占 10–30%。" — 生产运维共识
Ch5 ICE/STUN/TURN 讲了 TURN 原理。本章落地生产级 coturn 集群——从单机 Docker 到多区域 GeoDNS 部署，覆盖凭证安全、带宽成本建模与容量规划。
Serge Lachapelle 在 Curious 历史访谈 中回忆：Marratech 时代企业网内 ICE 几乎总是成功，但扩展到公网后 TURN relay 成为必需品——Today Meet/LiveKit 全球部署中，TURN 集群的运维复杂度不亚于 SFU 本身。
配套 Lab：examples/webrtc-lab/docker/coturn/docker-compose.yml
"理解协议意图，才能高效 Debug。" — WebRTC for the Curious
WebRTC 的调试难度在于：媒体走 UDP 直连，信令走 WebSocket，加密层覆盖全链路——传统 HTTP 调试工具几乎无用。Serge Lachapelle 在 Curious 历史访谈 中提到，Marratech 时代最大的工程挑战不是编解码，而是在不可控的公网环境中定位连接失败——这个问题今天依然有效。
本章汇总生产排障工具链，回顾 Ch5 ICE、Ch7 DTLS、Ch8 RTCP、Ch10 GCC 所有失败模式，建立系统化的可观测性体系。
配套 Lab：examples/webrtc-lab/ 全模块 + 故障注入脚本。
"我们早期押注多播，但公网教会了我们：你需要的是 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/。
本章涉及 LiveKit 作为 SFU 参考实现。建议先阅读本站 LiveKit 介绍，了解 Room/Participant/Track 模型与 SDK 选型。
"从多播幻想到 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 时代网络质量波动极大，自适应码率是从「能通」到「能用」的分水岭。
GCC 的 IETF 草案（draft-ietf-rmcat-gcc）从未最终发布为 RFC。BWE 领域存在多种实现（GCC、NADA、SCReAM），但 GCC + TWCC 是 Chrome/WebRTC 生态的事实标准。
配套 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 年来未曾改变。
RTP 不要求数据按精确时序到达——它面向实时而非可靠。丢包用 FEC/NACK/PLC 补偿，而非 TCP 式重传阻塞。这正是 Ron Frederick 所说「如果一个东西需要实时数据流，又无需精确时序传输，它就可以从 RTP 中受益」。
本章覆盖 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/