WebRTC 最初是为 1对1实时通信 设计的，但由于其极低的延迟（<500ms）优势，它正越来越多地被应用于 1对多、多对多 的广播型直播场景。本文将深入解析WebRTC低延迟直播的核心方案、架构选型及最新技术演进。
一、为什么选择 WebRTC 做直播？
与传统的 RTMP、HLS 等协议相比，WebRTC 在延迟方面有压倒性优势：
| 协议 | 典型延迟 | 核心特点 |
|---|---|---|
| RTMP | 3-5秒 | 推流主流，但需转封装 |
| HLS | 6-30秒 | 兼容性好，但延迟高 |
| LL-HLS | 2-4秒 | 延迟优化，但仍不如WebRTC |
| WebRTC | < 500ms | 原生低延迟，浏览器直接支持 |
WebRTC 的核心优势包括：
浏览器原生支持：无需安装插件，Chrome、Firefox、Safari 等主流浏览器均已支持
基于 UDP 传输：避免 TCP 队头阻塞，网络抖动时表现更优
内置自适应机制：可根据带宽动态调整码率和帧率
原生硬解：利用 GPU 解码，CPU 占用远低于纯软件解码方案
二、核心架构选型：Mesh vs SFU vs MCU
构建WebRTC直播系统时，最关键的架构决策是选择媒体路由拓扑。这个选择直接影响系统的扩展性、成本和用户体验。
2.1 三种架构对比
| 架构 | 工作原理 | 客户端带宽 | 服务器负载 | 适用规模 |
|---|---|---|---|---|
| Mesh (P2P) | 每个参与者与其他人建立直接连接 | 随人数增加指数级上升 | 无 | 2-4 人小会 |
| SFU | 服务器转发流，不处理内容 | 上行 1份，下行 N-1 份 | 低（仅路由） | 5-100+ 人 |
| MCU | 服务器混合多路流为单路 | 上行 1 |
