4、GCC算法深度解析：Trendline滤波器与过载检测机制
GCC（Google Congestion Control）是WebRTC最核心的拥塞控制算法。很多开发者调了半天的码率、改了一堆参数，效果还是不行——说白了，就是没搞懂GCC内部那两个关键模块：Trendline滤波器和过载检测器。
我个人习惯把GCC拆成三块来看：延迟梯度估算、过载状态机、码率调整。今天咱们重点啃前两块。你想想看，如果连网络是“变堵了”还是“变好了”都判断不准，后面的码率调整全是瞎蒙。
4.1 延迟梯度：GCC的“眼睛”
GCC不依赖丢包来判断拥塞——它看的是延迟变化趋势。为什么？因为丢包是拥塞的晚期症状，等丢包了再降码率，用户体验已经崩了。
延迟梯度的核心公式很简单：
d(i) = t_r(i) - t_s(i) - (t_r(i-1) - t_s(i-1))其中：
t_r(i)：第i个包组的接收时间t_s(i)：第i个包组的发送时间d(i)：第i个包组相对于前一个包组的延迟变化
嗯，这里要注意：GCC不是对每个包算延迟，而是按包组来算。一个包组通常是同一时间戳内发送的一批包。我在项目中遇到过有人把包组大小设成1，结果延迟抖动大得离谱，Trendline直接废了。
4.2 Trendline滤波器：从噪声中找趋势
原始延迟梯度d(i)噪声很大——WiFi抖动、CPU调度、NIC中断，都会让d(i)忽正忽负。Trendline做的就是从噪声中提取真实趋势。
它本质上是一个线性回归模型，用最近一组延迟梯度样本拟合一条直线：
斜率 = (n * Σ(i * d(i)) - Σi * Σd(i)) / (n * Σ(i²) - (Σi)²)这个斜率就是Trendline的输出值。斜率 > 0，说明延迟在增长，网络可能正在变堵；斜率 < 0，说明延迟在下降，网络在变好。
但直接拿原始斜率做决策会出问题——我见过斜率在正负之间来回跳的情况。所以GCC又加了一层平滑：
smoothed_slope = 0.9 * prev_smoothed_slope + 0.1 * raw_slope这个0.9的衰减系数，说白了就是个低通滤波器。系数越大，对趋势变化越迟钝，但越稳定。
4.3 过载检测器：状态机与阈值
Trendline输出的是平滑斜率，过载检测器根据这个斜率判断网络状态。它是个三状态机：
| 状态 | 含义 | 触发条件 |
|---|---|---|
| Normal | 网络正常，无需调整 | |smoothed_slope| < threshold |
| Overuse | 网络过载，需要降码率 | smoothed_slope > threshold |
| Underuse | 网络空闲，可以升码率 | smoothed_slope < -threshold |
这里有个关键参数——threshold（阈值）。它决定了GCC对延迟变化的敏感度。阈值太小，GCC会过度反应，码率频繁波动；阈值太大，GCC反应迟钝，拥塞了也不降码率。
GCC的阈值不是固定的，它会根据当前码率动态调整：
threshold = max(6, min(600, k * bitrate / 1000))其中k是配置系数，默认12.5。码率越高，阈值越大——因为高码率下延迟波动本来就大，需要更大的阈值来避免误判。
4.4 状态机转换逻辑
光看单次比较还不够，GCC用了状态机来避免频繁切换。我画了张图，你看一眼就明白了：
状态机有个重要特性：每次触发Overuse或Underuse后，必须回到Normal才能再次触发。为什么？防止连续触发导致码率震荡。我见过有人把阈值设得太小，结果状态在Normal和Overuse之间来回跳，码率像过山车一样。
4.5 关键参数调优指南
说了这么多理论，来点实际的。下面是我在多个项目中总结的参数调优表：
| 参数 | 默认值 | 调大效果 | 调小效果 | 适用场景 |
|---|---|---|---|---|
| 包组时间窗口 | 5ms | 延迟检测更平滑，但反应慢 | 延迟检测更灵敏，但噪声大 | 弱网环境建议保持默认 |
| Trendline窗口大小 | 20个样本 | 趋势更稳定，但滞后严重 | 趋势反应快，但容易误判 | 高码率场景可适当增大 |
| 平滑系数 | 0.9 | 斜率更平滑，但延迟大 | 斜率更敏感，但抖动多 | WiFi环境建议保持默认 |
| 阈值系数k | 12.5 | 阈值更大，不易触发Overuse | 阈值更小，容易触发Overuse | 高码率场景可适当调大 |
4.6 调试实战：如何验证Trendline工作正常
理论讲完了，咱们来点实际的。你在调试GCC时，怎么知道Trendline和过载检测器工作正常？
我个人习惯看三个指标：
- 延迟梯度原始值：看d(i)的分布范围。正常网络下，d(i)应该在±5ms以内。如果经常超过±20ms，说明网络抖动很大，或者包组设置有问题。
- Trendline斜率：看smoothed_slope的变化趋势。正常网络下，斜率应该在0附近波动。如果斜率持续大于0，说明网络在变堵。
- 过载状态切换频率：看状态机在Normal/Overuse/Underuse之间的切换次数。正常情况下，每分钟切换不超过5次。如果频繁切换，说明阈值设置不合理。
你可以通过WebRTC的统计回调获取这些数据：
// 获取延迟梯度统计
const stats = pc.getStats();
stats.forEach(report => {
if (report.type === 'candidate-pair') {
console.log('延迟梯度:', report.availableOutgoingBitrate);
// 实际项目中需要从RTCInboundRtpStreamStats中提取
}
});嗯，这里要注意：WebRTC标准API没有直接暴露Trendline斜率，你需要自己实现日志埋点。我在项目中通常会在GCC模块的源码里加几个LOG语句，把smoothed_slope和当前状态打印出来。
最后说一句：GCC的Trendline和过载检测是整个拥塞控制的基石。你花时间把这部分搞透，后面码率调整、带宽估计那些东西，理解起来就顺理成章了。别急着调参数，先把状态机跑通，看看你的网络环境下斜率到底长什么样。