3、GCC算法总览：Google Congestion Control的架构
聊到WebRTC的拥塞控制，GCC（Google Congestion Control）是绕不开的核心。说实话，我在做实时音视频通信的早期，也踩过不少坑——比如网络抖动时画面卡成PPT，或者明明带宽够用却莫名其妙降码率。后来深入研究了GCC，才真正理解了它背后的设计哲学。
GCC的全称是Google Congestion Control，它是WebRTC默认的拥塞控制算法。你想想看，视频通话的场景有多复杂：Wi-Fi信号忽强忽弱、4G/5G切换、甚至有人在下载大文件抢带宽……GCC要做的，就是在这些场景下，尽可能保证视频流畅、不卡顿。
GCC的整体架构
GCC的核心思路是“双引擎驱动”。它同时使用两个独立的控制器：
- 基于延迟的控制器：通过RTT（往返时间）和延迟梯度来判断网络是否开始拥塞
- 基于丢包的控制器：通过实际的丢包率来调整发送码率
这两个控制器各自独立工作，最终取它们计算出的码率中的较小值，作为实际发送码率。嗯，这里要注意：不是简单的取平均，而是取最小值——说白了就是“谁更保守听谁的”。
核心设计原则：延迟控制器负责“预防”，丢包控制器负责“止损”。两者互补，避免单一指标误判。
基于延迟的控制器
这个控制器是我个人觉得最巧妙的部分。它不直接看丢包，而是通过观察数据包到达时间的“抖动”来判断网络是否开始变差。
具体原理是这样的：发送端会记录每个数据包的发送时间，接收端则记录到达时间。通过对比这两个时间差，可以计算出“延迟梯度”。如果延迟梯度持续增大，说明网络正在变拥塞——就像高速公路上的车流，车速越来越慢。
我的经验：我在项目中遇到过一种情况——Wi-Fi信号弱但没丢包，延迟控制器先于丢包控制器做出了反应，提前降码率。结果视频虽然清晰度降了一点，但全程没卡顿。如果只靠丢包判断，等丢包率上来再降码率，画面早就卡成马赛克了。
延迟控制器的核心算法是“趋势检测”。它维护一个延迟梯度的滑动窗口，计算趋势值m(t)：
m(t) = 延迟梯度(t) - 延迟梯度(t-1)
趋势值 = 滑动平均(m(t))当趋势值超过某个阈值时，就认为网络进入“过载”状态，需要降低码率。反之，如果趋势值稳定或下降，可以尝试增加码率。
基于丢包的控制器
丢包控制器就直观多了。它直接根据接收端反馈的丢包率来调整码率。但这里有个坑：丢包率怎么算？
WebRTC使用的是“加权丢包率”，不是简单的丢包数除以总包数。它会给予近期丢包更高的权重，这样能更快响应网络变化。
| 丢包率范围 | 码率调整策略 | 调整幅度 |
|---|---|---|
| 0% - 2% | 尝试增加码率 | +8% / 秒 |
| 2% - 10% | 保持当前码率 | 不变 |
| 10% 以上 | 降低码率 | 按比例下降 |
注意：丢包率超过10%时，GCC会快速降低码率。我曾经调试过一个场景，丢包率突然飙到30%，GCC在1秒内把码率从2Mbps降到了500kbps。虽然画面变模糊了，但至少没断流——这就是“止损”策略的价值。
GCC的优缺点
聊完了架构，咱们来客观评价一下GCC。没有完美的算法，GCC也不例外。
优点
- 双控制器互补：延迟控制器提前预警，丢包控制器兜底，覆盖了大部分网络场景
- 收敛速度快：通常在2-3个RTT内就能完成码率调整
- 公平性好：多个GCC流共存时，能相对公平地分配带宽
- 实现成熟：WebRTC社区有大量实践和优化，踩坑成本低
缺点
- 对延迟抖动敏感：在Wi-Fi等不稳定链路上，延迟控制器可能误判，导致码率频繁波动
- 丢包控制器滞后：等丢包率上来再反应，对于实时性要求极高的场景（如云游戏）可能不够快
- 参数调优困难：阈值、窗口大小等参数需要根据实际网络环境调整，没有万能配置
一句话总结：GCC是一个“够用但不够完美”的拥塞控制方案。对于大多数实时音视频场景，它表现良好。但如果你追求极致体验，还需要结合具体场景做定制优化。
我个人习惯在项目中保留GCC作为默认方案，同时预留一个“快速降码率”的旁路逻辑——当检测到网络剧烈抖动时，直接跳过GCC的平滑调整，一步到位降到安全码率。这个做法虽然粗暴，但在某些极端场景下确实能救命。