6.1 拥塞控制与带宽估计

6.1 拥塞控制与带宽估计

本节摘要：会前测试一切正常，一开摄像头全员卡顿——这类事故的根源，是发送速率超过了网络的承载能力，而应用对此一无所知。带宽估计器就是 WebRTC 的「网速仪表盘」：综合延迟变化与丢包信号，持续算出当下能安全发送的码率。本节拆解 Google 拥塞控制算法的双通道设计，比较 remb 与 TWCC 两种反馈机制，并回答「为什么实时媒体不能照搬 TCP 的拥塞控制」。

读完本节你能

阅读完本节，你应当能够：

1. 解释网络拥塞的两种表现（延迟攀升、丢包）与各自作为信号的优劣；
2. 说出 GCC 算法基于延迟与基于丢包两条通道的分工与合成规则；
3. 区分 remb 与 TWCC 反馈机制，按场景选择；
4. 描述探测机制（padding 探测）如何快速摸清带宽上界；
5. 用统计接口读出当前目标码率并验证估计器工作正常。

一、问题与直觉：网络不说话，谁来告诉发送端

TCP 的拥塞控制是全世界的成功故事，但它的策略对实时媒体是毒药：丢包即减半、窗口慢增长，代价是把延迟越推越高——对下载只是慢，对通话是「人还在说、声音三秒前的事」。实时媒体需要另一种拥塞控制：宁可主动降画质，也不肯积压延迟。

难点在于信号本身。网络不会主动说「我拥塞了」，发送端只能从两种间接现象推断。丢包：路由器队列溢出，包被扔掉——信号明确，但出现得晚，等到丢包时拥塞已经发生。延迟梯度：队列开始积压时，包的往返时间先缓缓上涨——信号微妙，但它早于丢包出现，是「事前预警」。两者结合，才既有灵敏度又有确认。

二、核心原理：GCC 的双通道与两种反馈

Google 拥塞控制（GCC，WebRTC 的默认实现）把两条信号通道并行运转：

延迟通道盯着包对的到达间隔：如果相邻包组的到达间隔持续大于发送间隔，说明链路正在积压，估计器下调；反之缓慢上调。它用状态机收敛——过度使用、正常使用、低负载三态，防止单个毛刺引发震荡。丢包通道是保守的护栏：丢包率超过一成左右下调，低于半成则每秒温和上调几个百分点。合成规则上，延迟通道给出主预判，丢包通道保底——哪边更悲观听哪边。

反馈机制有新旧两代。remb（接收端最大码率）由接收端算好估计值，经 RTCP 主动告诉发送端「你别超过这个数」——智能在接收端，一路流一条反馈。TWCC（传输层拥塞控制）反过来：接收端只回报每个包的到达时刻，估计全在发送端算——智能集中在发送端，好处是能同时评估多路媒体（音视频一起看）且算法可以独立升级。新实现首选 TWCC，remb 保留作兼容。

探测机制解决「上调慢」的问题。仅靠温和上调，从低码率爬回高带宽要很久；GCC 会主动发 padding 探测包（无内容、只占带宽）试探 higher 速率是否有响应，快速摸清上界。这解释了一个现象：网络恢复后，画质往往在两秒内弹回——探测机制在起作用。

💡 关键直觉：带宽估计的成品不是「网速快慢」的数字，而是一个每时每刻都在变的目标码率。它下调时你的画质就该变糊——这是系统在替你减负，不是出了故障。

图：GCC 双通道估计与反馈回路

三、工程实践要点：配置、观测与两个反直觉

工程上直接可用的三件事。开启 TWCC：连接配置里带相应扩展，SDP 里确认 extmap 声明存在（第 3 章的对账方法正好用上）；观测目标码率：统计接口的可用带宽字段持续记录，调优前先画曲线——没有基线的调优都是猜；音频路径独立估计：音频对延迟最敏感，其估计逻辑与视频分开，别拿视频的降级拖累音频。

两个反直觉的认知值得单独点出。其一，带宽高不等于该发满。估计器给出的目标码率通常只敢用到实际带宽的八成左右，留出余量防震荡——看到「明明有十兆只发八兆」不要当成 bug。其二，卡顿未必是带宽不足。延迟通道的频繁下调可能由 Wi-Fi 干扰抖动引发，此时码率一降再降、画质糊了但延迟照样高——对症手段是改善链路（换频段、走有线），而不是继续压码率。

完整案例：会议开启瞬间的「全员马赛克」

背景：某产品反馈：十人会议开启瞬间，画面集体马赛克十几秒才恢复；人越多越严重。

操作：记录目标码率曲线后发现：入会时每个人的编码器以默认高码率起播，十路流叠加瞬间把会议室上行链路（常见规格仅数兆）打爆，延迟通道持续下调，但下调速率受「温和上调防震荡」逻辑拖累，收敛耗时与人数正相关。修复组合拳：入会时以保守码率起播（台阶式爬升）；启用 TWCC 让服务器端集中估计，把十路独立估计合并为对链路的整体判断；同时对入会时刻做了错峰（随机延迟数百毫秒起播）。

结果：马赛克时长从十几秒压缩到一两秒，大会议室场景的入会体验达标。

解读：这类「系统正确但集体不理性」的问题在带宽估计里很典型：每一路的估计器都工作正常，但多路独立估计对同一条链路叠加后互相打架。解法的共同思路是把估计的「视角」抬高一层——从每路各自为战，变成链路级的集中判断。

变式：如果产品主要跑在带宽极不稳的移动网络，还可以把「估计的输入」前移：客户端在网络切换事件（第 2 章的设备与网络监听）时主动把码率拉回保守档，避免估计器从错误的乐观状态慢慢爬下来。主动先手加被动闭环，是移动端弱网优化的常见组合。

本节要点回顾

• 两种信号两种脾气：丢包明确但滞后，延迟梯度微妙但先知，GCC 双通道合成两者。
• remb 与 TWCC 的分工：智能在收端还是发端的选择，新实现首选 TWCC，多路场景收益最大。
• 探测解决上调慢：padding 包主动试速，画质恢复的速度感来自它。
• 目标码率是唯一指挥棒：编码器、降级、探测都听它的，观测它等于观测系统心跳。
• 卡顿有两种病：带宽不足与链路抖动，处置方向相反，先分清再动手。