4、接收端码率控制：基于延迟梯度的带宽估计原理与实现
接收端码率控制，说白了就是让接收方根据网络状况，动态告诉发送方「你该降速了」或者「可以再快一点」。WebRTC 里最核心的算法就是基于延迟梯度的带宽估计，也叫 GCC（Google Congestion Control）的接收端部分。
我个人习惯把这一块称为「网络的眼睛」。没有它，发送端就是个瞎子，要么把网络撑爆，要么浪费带宽。
4.1 为什么需要延迟梯度？
先想一个问题：怎么判断网络是不是快堵了？
丢包率当然是一个指标。但丢包是个「事后」信号——等你发现丢包，网络已经堵死了。延迟不一样，它是「事前」信号。网络开始拥塞时，队列会变长，延迟会先上升。
延迟梯度，就是看延迟的变化趋势。不是看绝对值，而是看「这次比上次多了多少」。
核心思想：如果延迟持续增加，说明网络队列在堆积，拥塞正在发生。如果延迟稳定或下降，说明网络通畅。
我在项目中遇到过一种情况：某次测试中丢包率一直为 0，但视频卡成 PPT。后来发现是延迟梯度已经飙到 200ms 以上，接收端早就该降码率了。嗯，只看丢包是不够的。
4.2 延迟梯度的数学原理
延迟梯度的计算其实不复杂。我们看两个关键量：
- 到达时间差：两个包到达接收端的时间间隔
- 发送时间差：这两个包在发送端发出的时间间隔
延迟梯度 = 到达时间差 - 发送时间差
如果这个值大于 0，说明包在路上被「拖慢」了。如果持续大于 0，说明网络在变差。
举个例子：
包1 发送时间: 1000ms, 到达时间: 1100ms
包2 发送时间: 1020ms, 到达时间: 1130ms
发送时间差 = 1020 - 1000 = 20ms
到达时间差 = 1130 - 1100 = 30ms
延迟梯度 = 30 - 20 = 10ms > 0这个 10ms 就是延迟的增加量。如果连续几个包都这样，基本可以断定网络在恶化。
4.3 卡尔曼滤波：让估计更平滑
直接算出来的延迟梯度噪声很大。网络抖动、CPU 调度、时钟偏差都会引入干扰。这时候就需要卡尔曼滤波上场了。
WebRTC 里用的是一阶卡尔曼滤波器，专门用来平滑延迟梯度序列。我刚开始看这段代码时也觉得头大，后来发现核心就两个步骤：
- 预测：根据上一帧的状态，预测当前帧的延迟梯度
- 更新：用实际测量值修正预测值
说白了就是「猜一个值，然后拿真实数据修正它」。卡尔曼滤波的厉害之处在于，它会根据噪声大小动态调整修正力度——噪声大就少信测量值，噪声小就多信测量值。
避坑指南：我曾经在调参时把卡尔曼滤波的过程噪声设得太小，结果滤波器反应迟钝，带宽估计跟不上网络变化。后来把噪声协方差矩阵调大了一些，效果立竿见影。
4.4 状态机：从趋势到决策
平滑后的延迟梯度还不能直接用。WebRTC 定义了一个状态机，把连续的梯度值映射为三种网络状态：
| 状态 | 含义 | 触发条件 |
|---|---|---|
| Normal | 网络正常 | 延迟梯度接近 0 或负值 |
| Overuse | 网络过载 | 延迟梯度持续超过阈值 |
| Underuse | 网络空闲 | 延迟梯度持续为负 |
状态切换不是简单的阈值比较，而是用了一个自适应阈值。阈值会随着网络状况动态调整——网络抖动大时阈值放宽，稳定时阈值收紧。这个设计很巧妙，避免了频繁的状态抖动。
你想想看，如果阈值固定，WiFi 环境下稍微抖一下就触发 Overuse，那视频质量就没法看了。
4.5 带宽估计：从状态到码率
有了网络状态，接下来就是算带宽了。WebRTC 接收端用的是 AIMD（加性增乘性减）策略：
- Normal 状态：带宽增加，增加量是当前带宽的 8% 左右
- Overuse 状态：带宽减少，减少到当前带宽的 85% 左右
- Underuse 状态：带宽保持，等待网络恢复
这个 8% 和 85% 不是拍脑袋定的。我做过实验，8% 的增速率在大多数网络环境下能快速收敛到可用带宽，又不会太激进。85% 的降速比能迅速缓解拥塞，避免丢包。
注意：带宽估计结果会通过 RTCP REMB（Receiver Estimated Maximum Bitrate）报文反馈给发送端。如果 REMB 报文丢了，发送端就收不到降速指令。所以实际部署时，建议把 REMB 的发送间隔设短一些，比如 200ms 一次。
4.6 整体流程：一张图说清楚
下面这张图展示了接收端码率控制的完整链路：
4.7 实现要点与常见坑
讲完了原理，说说实现时容易踩的坑。我踩过不少，挑几个典型的：
- 时钟同步问题：发送端和接收端的时钟可能不同步。WebRTC 用 NTP 时间戳来对齐，但如果 NTP 不准，延迟梯度就会漂移。我建议在代码里加一个时钟偏差补偿逻辑。
- 突发流量处理：视频关键帧（I帧）会导致瞬间数据量暴增，延迟梯度会突然变大。如果不做处理，会误判为 Overuse。WebRTC 的做法是检测到突发时暂时跳过梯度计算。
- 阈值初始化：自适应阈值的初始值很关键。设太大，拥塞检测迟钝；设太小，频繁误报。我一般从 10ms 开始，然后让算法自己调整。
个人经验：调试延迟梯度算法时，建议先把原始梯度值和卡尔曼滤波后的值都打印出来。对比着看，能快速定位问题是出在滤波参数上，还是状态机逻辑上。
4.8 小结
接收端码率控制的核心就是一句话：用延迟梯度感知网络，用卡尔曼滤波去噪，用状态机决策，用 AIMD 调整码率。
这套机制在 WebRTC 里跑了十几年，经过了无数场景的验证。理解它，你就能看懂 WebRTC 在网络自适应方面的大部分设计思路。