2、GCC算法总览：Google Congestion Control的演进历史与设计哲学

聊WebRTC的码率控制，GCC（Google Congestion Control）是绕不开的核心。说白了，它就是WebRTC里那个负责“看路况踩油门”的模块。网络好就多发包，网络差就少发包，目标只有一个——在不让视频卡成PPT的前提下，尽可能把带宽用满。

我最早接触GCC是在2015年，那时候还在做一款互动直播产品。线上经常出现“画面突然糊掉，然后又突然清晰”的锯齿现象。后来追根溯源，发现是GCC的响应速度跟不上网络抖动。嗯，从那以后我就开始认真啃这个模块了。

2.1 GCC的演进时间线

GCC不是一天建成的。它经历了几个关键版本，每个版本都解决了一类核心问题。我整理了一张简表，方便你快速建立全局认知。

版本/阶段	核心机制	主要问题	出现时间
GCC v1（基于丢包）	丢包率 + AIMD	延迟敏感度低，Bufferbloat	2012-2014
GCC v2（基于延迟）	延迟梯度 + Kalman滤波	计算开销大，收敛慢	2015-2017
GCC v3（Trendline）	延迟趋势 + 过载检测	对突发丢包误判	2018-2020
GCC v4（混合+自适应）	丢包+延迟+带宽探测	参数调优复杂	2021-至今

你看，从单纯依赖丢包，到引入延迟梯度，再到现在的混合模型，GCC的演进其实就是一条“更早、更准地感知网络拥塞”的路径。

2.2 设计哲学：为什么GCC选择了“延迟”而不是“丢包”？

这个问题我当年也困惑了很久。你想想看，丢包明明是网络拥塞最直接的信号，为什么GCC不把它作为主要依据？

原因其实很简单：丢包是“已经发生”的拥塞，而延迟是“即将发生”的拥塞。

当网络设备的缓冲区开始堆积数据包时，延迟会先升高。等到缓冲区满了，才开始丢包。如果你等到丢包了再降码率，用户已经体验了好几秒的卡顿。我曾在一次线上事故中亲眼看到：一个WiFi路由器缓冲区堆积了300ms的数据，GCC v1版本完全没反应，直到缓冲区溢出开始丢包，码率才骤降——但画面已经卡成幻灯片了。

2.3 GCC的核心架构：两个检测器 + 一个控制器

GCC的整体架构其实不复杂。我习惯把它拆成三个模块：

• 丢包检测器（Loss-based Detector）：统计接收端反馈的丢包率，采用AIMD（加性增乘性减）策略调整码率。
• 延迟检测器（Delay-based Detector）：计算数据包到达时间的延迟梯度，判断网络是否即将拥塞。
• 码率控制器（Rate Controller）：综合两个检测器的结果，输出最终的码率建议。

下面这张图展示了它们之间的协作关系：

注意看图中的反馈路径。接收端通过RTCP包把丢包率和到达时间信息反馈给发送端。发送端收到后，丢包检测器和延迟检测器各自算出一个码率建议，最终码率控制器取两者的最小值。为什么取最小值？因为任何一个检测器认为网络有问题，我们都应该保守一点。

2.4 从AIMD到Trendline：算法演进的背后逻辑

早期的GCC v1用的是经典的AIMD（Additive Increase Multiplicative Decrease）。简单说就是：没丢包就线性增加码率，丢包了就乘性减半。这个策略在传统TCP里用了三十年，很成熟。

但问题来了——WebRTC的场景和TCP不一样。TCP是文件传输，丢包重传就行。WebRTC是实时通信，你重传一个视频帧，它已经过期了。所以GCC需要更灵敏的拥塞检测手段。

于是有了延迟梯度（Inter-arrival Delay）的思路。我记得第一次看到这个算法时，觉得它很巧妙：通过比较相邻数据包的到达时间间隔，判断网络是否出现了排队延迟。如果排队延迟在持续增加，说明网络正在变拥塞。

到了GCC v3，引入了Trendline滤波器。它不再只看单次延迟，而是分析延迟的变化趋势。这个改进让GCC对网络抖动的适应性大幅提升。我曾在模拟环境下对比过：在同样的弱网场景中，v2需要3-5秒才能收敛到稳定码率，v3只需要1-2秒。

2.5 设计哲学总结：三个核心原则

回顾GCC的整个演进过程，我总结出三条设计哲学：

1. 保守优先：当丢包检测器和延迟检测器给出不同结论时，取最小值。宁可牺牲一点带宽利用率，也要保证通话不中断。
2. 渐进式调整：码率变化是平滑的，不会出现断崖式下跌。GCC内部有专门的平滑滤波器，防止码率突变导致画面闪烁。
3. 闭环反馈：发送端、网络、接收端形成一个完整的控制环路。每个RTT周期（约100-200ms）都会进行一次调整。