前面几篇已经讲到 RTCP、NACK/RTX、GCC/TWCC 和发送端码率控制。现在还缺一个非常关键的问题：编码器输出了一堆 RTP 包之后，为什么 WebRTC 不直接循环 sendto 全部发出去？答案就是 Pacer。
Pacer 可以理解为发送端的“交通信号灯”和“快递分拣员”。编码器有时很冲动，尤其是关键帧来了，一下子吐出几百 KB 数据；RTX 重传来了，也可能突然插队；带宽探测时还要故意发一些 padding 包试探网络。如果这些包一股脑冲进 UDP socket，短时间内可能把本机队列、路由器队列、运营商链路都塞满。用户看到的结果就是 RTT 升高、丢包增加、NACK 更多、PLI 更多，然后系统像堵车时大家一起按喇叭，越按越堵。
1. Pacer到底解决什么问题
Pacer 的核心职责是把突发数据摊平成可控的发送节奏。编码器负责“生产包”，拥塞控制负责“告诉你大概能发多快”，Pacer 负责“按这个速度把包发出去”。如果说 GCC 给的是限速牌，Pacer 就是司机脚下的油门。
订阅专栏 解锁全文
扫一扫
1759
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
