2 posts tagged with "STUN/TURN"

"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

"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/