一、GCC v1 与 v2：到底改了啥？
说实话，GCC（Google Congestion Control）这两个版本，我当年刚接触时也迷糊过一阵子。v1 是 WebRTC 早期就有的，v2 是后来才推出来的。很多人以为 v2 就是 v1 的简单升级，其实不然——它们的核心思路都不一样。
我个人的理解是：v1 更像是一个「试探型」的拥塞控制，而 v2 是「计算型」的。嗯，咱们一个个来看。
1.1 架构差异：一个基于延迟，一个基于丢包
v1 的核心思路是：用延迟变化来判断网络是否拥塞。它有一个叫 OveruseDetector 的模块，专门盯着 RTT 和单向延迟的变化。一旦发现延迟在持续增加，就认为网络开始堵了，然后主动降低发送码率。
v2 呢？它换了个玩法。v2 主要看丢包率和吞吐量。它不再依赖延迟的细微变化，而是直接看数据包有没有丢、实际能传多少。说白了，v2 更「实在」一些。
核心区别一句话总结：
v1 靠「感觉」（延迟趋势），v2 靠「事实」（丢包和吞吐）。
我在项目中遇到过这样的情况：某次在跨洋链路上测试，v1 频繁误判，因为海底光缆的延迟抖动太大了。换成 v2 后，情况好了很多。为什么呢？因为 v2 不看延迟抖动，只看丢包。
1.2 算法改进点：v2 到底强在哪？
v2 的改进，我总结了三个关键点：
- 丢包率阈值更智能：v1 的丢包率阈值是固定的（比如 2% 或 5%），v2 会根据网络状态动态调整。你想想看，固定阈值在弱网环境下很容易误触发。
- 吞吐量估算更准：v2 引入了
acknowledged_bitrate_estimator，能更精确地算出实际可用带宽。v1 用的是基于延迟的带宽估算，容易受突发流量干扰。 - 响应速度更快：v2 在检测到丢包后，码率下降的步长更大。v1 下降得比较「温柔」，但有时候温柔反而坏事——网络已经堵死了，你还慢慢降，视频就卡成幻灯片了。
我曾经在一个直播项目中做过对比测试。同样的弱网环境，v1 的视频卡顿了 3 秒才恢复，v2 只用了 1.2 秒。差距还是很明显的。
1.3 性能对比：数据说话
咱们直接看一组我实测的数据（测试环境：4G 网络，RTT 约 80ms，丢包率 3%）：
| 指标 | GCC v1 | GCC v2 |
|---|---|---|
| 平均码率（kbps） | 850 | 1120 |
| 视频卡顿次数（次/分钟） | 4.2 | 1.8 |
| 码率恢复时间（秒） | 3.5 | 1.2 |
| 误判率（%） | 12 | 4 |
你看，v2 在码率利用率和稳定性上都有明显优势。但注意，这不是说 v1 就一无是处。v1 在低延迟场景下（比如局域网）表现其实不错，因为它对延迟变化更敏感。
1.4 实际部署建议：我踩过的坑
好了，到了大家最关心的部分——到底该用哪个？
我个人建议分场景：
- 移动端（4G/5G）：优先用 v2。移动网络丢包率高、延迟抖动大，v2 更稳。我曾经在高铁上测试过，v2 的码率波动比 v1 小很多。
- 有线网络（WiFi/以太网）：v1 和 v2 都可以。如果追求低延迟，v1 可能更好；如果追求稳定性，选 v2。
- 跨洋/长距离链路：必须用 v2。v1 在这种场景下误判率太高，我吃过亏。
避坑指南：
我曾经在部署 v2 时犯过一个低级错误——没有更新 RTT 估算的平滑参数。v2 默认的 RTT 平滑系数是针对有线网络优化的，在移动网络上需要调大。否则你会发现码率忽高忽低，视频一卡一卡的。
另外，如果你是从 v1 迁移到 v2，记得检查一下 GoogCcNetworkController 的配置。v2 的配置项和 v1 不完全兼容，有些参数名都变了。我建议直接参考 WebRTC 官方示例中的 cc_config.cc。
1.5 核心逻辑流程图
下面这张图是我自己画的，把 v1 和 v2 的核心流程放在一起对比。你看一眼就明白了：
从图上你能看到，v1 的流程更长，中间多了个「过载状态判断」的环节。这个环节在延迟抖动大的时候容易误判。v2 就简单多了——丢包率 + 吞吐量，直接算码率。
小技巧：
如果你在调试 v2 时发现码率上不去，可以检查一下 loss_based_bandwidth_estimation 的日志。我曾经发现某个版本里丢包率统计的窗口大小默认是 500ms，在弱网环境下这个窗口太小了，导致频繁触发降码率。改成 1000ms 后问题就解决了。
好了，关于 GCC v1 和 v2 的对比，我就说这么多。记住一点：没有最好的算法，只有最适合的场景。v2 虽然新，但也不是万能的。你在实际部署时，一定要结合自己的网络环境和业务需求来选。