一、GCC算法：WebRTC拥塞控制的基石
说实话，做WebRTC开发这些年，我遇到最多的问题就是：「为什么视频卡成PPT了？」「为什么通话突然断断续续？」。这些问题背后，十有八九都和带宽估计与拥塞控制有关。
GCC（Google Congestion Control）算法，就是WebRTC用来解决这个问题的核心武器。它不是一个单一算法，而是一套完整的带宽估计与拥塞控制体系。我习惯把它理解为WebRTC的「交通调度员」——实时监控网络这条「路」能跑多少数据，然后决定发多少、怎么发。
GCC的核心目标：在保证低延迟的前提下，最大化吞吐量。说白了就是——别让网络堵车，也别让路空着。
1.1 GCC的两大组件
GCC算法由两个关键部分组成，它们分工明确：
- 基于延迟的带宽估计（Delay-based Estimator）：通过观察数据包到达时间的延迟变化，判断网络是否开始拥塞。这部分工作在接收端完成。
- 基于丢包的带宽估计（Loss-based Estimator）：通过统计丢包率，判断网络是否已经严重拥塞。这部分工作在发送端完成。
你可能会问：「为什么需要两个？一个不够吗？」嗯，我在项目中踩过这个坑。只靠延迟估计，遇到无线网络抖动时容易误判；只靠丢包估计，等发现丢包时网络已经堵死了。两者配合，才能做到「防患于未然」和「亡羊补牢」兼顾。
1.2 带宽估计的完整流程
我画了一张图，帮你理清GCC的整体工作流程：
这张图展示了GCC的核心闭环：发送端发数据 → 接收端计算延迟 → 反馈REMB → 发送端结合丢包率 → 最终决策。我当年第一次看这个流程时，觉得「不就一个反馈循环吗？」后来自己实现才发现，每个环节都有坑。
二、带宽估计策略：延迟与丢包的双重判断
2.1 基于延迟的带宽估计
这个策略的核心思想是：网络延迟的变化能提前反映拥塞。就像你开车上高速，还没到收费站，看到前面车流慢下来了，就知道要堵了。
具体怎么做的呢？接收端会记录每个数据包的到达时间，然后计算一个叫「到达时间差」（Inter-arrival Time）的指标。我简化一下：
// 伪代码：延迟梯度计算
delta_t = 当前包到达时间 - 上一个包到达时间
delta_s = 当前包发送时间 - 上一个包发送时间
// 延迟变化量
delay_delta = delta_t - delta_s
// 如果 delay_delta 持续增大 → 网络正在拥塞
// 如果 delay_delta 稳定或减小 → 网络正常这里有个关键点：不是看单次延迟，而是看趋势。网络抖动是常态，偶尔一次延迟增大不代表拥塞。GCC使用了一个叫「过载检测器」（Overuse Detector）的模块，通过卡尔曼滤波或趋势判断来识别真正的拥塞信号。
我的经验：在实际部署中，无线网络的延迟抖动非常剧烈。我曾经遇到一个场景，WiFi信号不好时，延迟忽高忽低，GCC的延迟估计频繁误判为「过载」。后来我们调整了过载检测器的阈值参数，才稳定下来。这个调参过程，说白了就是「试错」。
2.2 基于丢包的带宽估计
如果说延迟估计是「预防」，那丢包估计就是「抢救」。当网络已经严重拥塞，数据包开始被丢弃时，延迟估计已经来不及了。
GCC的丢包策略很简单：
| 丢包率范围 | 带宽调整策略 | 调整幅度 |
|---|---|---|
| 0% - 2% | 不调整或轻微增加 | +5% ~ +10% |
| 2% - 10% | 保持当前带宽 | 0% |
| 10% - 40% | 降低带宽 | -10% ~ -20% |
| > 40% | 大幅降低带宽 | -50% 或更多 |
你可能会问：「为什么丢包率2%以下还要增加带宽？」嗯，这里有个细节——网络中的随机丢包（比如无线信号干扰）并不代表拥塞。GCC会区分「随机丢包」和「拥塞丢包」。不过说实话，这个区分在实际中很难做到完美，我见过不少误判案例。
三、拥塞控制机制：从检测到恢复的完整闭环
3.1 三种网络状态
GCC把网络状态分为三种：
- 过载（Overuse）：延迟持续增大，或丢包率超过阈值。需要降低发送速率。
- 正常（Normal）：网络稳定，可以尝试增加带宽。
- 欠载（Underuse）：延迟下降，说明网络有富余带宽。可以尝试增加发送速率。
这三种状态之间的切换，由「速率控制状态机」管理。我习惯把它想象成一个自动变速箱——根据路况自动换挡。
3.2 速率控制状态机
GCC的速率控制分为两个阶段：
- 启动阶段（Startup）：刚建立连接时，快速探测网络容量。这个阶段带宽会指数增长，直到出现延迟增加或丢包。
- 稳态阶段（Steady State）：进入稳定传输后，使用 AIMD（加性增乘性减）策略。简单说就是：没问题时慢慢加，出问题时快速减。
注意：启动阶段的指数增长很容易导致网络瞬间拥塞。我曾经在弱网环境下测试，启动阶段直接把网络打爆了，导致后续几分钟都无法恢复。后来我们给启动阶段加了「上限保护」，才解决了这个问题。
3.3 带宽平滑与决策融合
最后一步，GCC需要把延迟估计和丢包估计的结果融合起来。规则是：
- 取两个估计值中的较小值作为最终带宽
- 对最终结果做平滑处理，避免带宽剧烈波动
- 平滑后的带宽传给编码器和发送模块，调整实际发送速率
为什么要取较小值？你想想看，如果延迟估计说「只能跑1Mbps」，丢包估计说「可以跑5Mbps」，你信哪个？当然信延迟估计——因为丢包还没发生，等丢包发生时已经晚了。保守一点，总比把网络搞崩了好。
一句话总结GCC：用延迟变化提前感知拥塞，用丢包率确认拥塞，两者结合做出保守但可靠的带宽决策。
好了，这一章的内容就到这里。GCC算法是WebRTC网络穿透中非常核心的一环，理解它的工作原理，能帮你解决很多实际中的音视频卡顿问题。下一章我们会深入GCC的代码实现，看看这些策略在源码中是怎么落地执行的。