15、带宽估计与拥塞控制：GCC算法、Transport-CC、码率自适应策略
各位同学，欢迎来到第十五章。今天聊的话题，说白了就是WebRTC的“交通管制系统”——带宽估计与拥塞控制。
你想想看，实时通信最怕什么？画面卡成PPT，声音断断续续。我早期做项目时，就遇到过这种尴尬：明明网络带宽够，但视频就是糊成一团。后来才发现，是拥塞控制没做好。嗯，这节课我们就来彻底搞懂它。
15.1 为什么需要带宽估计？
WebRTC不像普通视频播放，可以提前缓存几秒数据。它必须实时传输，而且网络环境千变万化。Wi-Fi、4G、5G，甚至地铁里信号忽强忽弱。如果没有带宽估计，发送端就会盲目发包，结果就是：
- 发太多 → 网络拥塞 → 丢包、延迟飙升
- 发太少 → 带宽浪费 → 画质模糊
所以，带宽估计的核心任务就是：动态探测当前网络能承载多少数据，然后告诉编码器和发送端“你悠着点”。
一句话总结：带宽估计是WebRTC的“油门”，拥塞控制是“刹车”。两者配合，才能让视频通话既流畅又清晰。
15.2 GCC算法：Google的拥塞控制方案
GCC（Google Congestion Control）是WebRTC默认的拥塞控制算法。它分为两个部分：
- 基于延迟的估计：通过观察数据包到达时间的延迟变化，判断网络是否开始拥塞。
- 基于丢包的估计：通过统计丢包率，判断网络是否已经过载。
我个人习惯把GCC比作“双传感器系统”。延迟传感器提前预警，丢包传感器事后确认。两者结合，决策更稳健。
15.2.1 基于延迟的估计（Delay-based）
核心思想很简单：如果网络开始排队，数据包到达的间隔就会变长。GCC会计算每个数据包的“到达时间差”与“发送时间差”的差值，这个差值叫单向延迟梯度（One-way Delay Gradient）。
当梯度持续增大，说明队列在堆积，网络要堵了。这时候GCC会降低发送码率。反之，如果梯度平稳，说明网络通畅，可以尝试提高码率。
避坑指南：我曾经在弱网环境下测试，发现延迟估计经常误判。后来排查发现，是发送端和接收端的时钟不同步导致的。解决办法是使用NTP时间戳，或者用相对时间差来消除时钟偏差。
15.2.2 基于丢包的估计（Loss-based）
丢包率超过某个阈值（比如2%），GCC就会认为网络已经拥塞，立刻降低码率。这个反应比较激进，但能快速止损。
不过要注意：丢包不一定是拥塞引起的。Wi-Fi干扰、信号衰减也会导致丢包。所以GCC会把丢包和延迟结合起来判断，避免误杀。
15.3 Transport-CC：更精细的带宽反馈
GCC的延迟估计依赖接收端计算，然后通过RTCP反馈给发送端。但RTCP反馈频率有限（通常每100ms一次），而且只能报告聚合信息。
Transport-CC（Transport-wide Congestion Control）是WebRTC后来引入的改进方案。它把反馈粒度从“每流”细化到“每包”。
具体做法是：
- 发送端给每个数据包打上一个唯一的序列号（Transport-wide sequence number）。
- 接收端收到后，记录每个包的到达时间。
- 接收端定期（比如每10ms）生成一个反馈报文，包含所有收到包的序列号和到达时间。
- 发送端根据这些信息，精确计算每个包的延迟，从而更准确地估计带宽。
说白了，Transport-CC就是给GCC装上了“高清摄像头”，让带宽估计更精准。
我的经验：在移动端项目中，我强烈建议开启Transport-CC。因为移动网络波动频繁，细粒度的反馈能让码率调整更及时，避免画面突然卡顿。
15.4 码率自适应策略
有了带宽估计，接下来就是怎么调整码率。WebRTC的码率自适应策略，简单来说就是：
- 带宽充足时：提高编码码率，提升画质。
- 带宽紧张时：降低编码码率，保证流畅度。
- 带宽严重不足时：丢帧、降分辨率，甚至暂停视频。
但具体怎么调，有很多细节。我给大家画个流程图，方便理解。
你看，整个策略是一个闭环。带宽估计不断输出结果，码率自适应不断调整，然后继续监测网络变化。这就是WebRTC能自适应各种网络环境的秘密。
15.5 实战中的码率调整策略
理论讲完了，来点实际的。我在项目中常用的码率调整策略有几种：
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 快速下降 | 网络突然变差（如进电梯） | 快速止损，避免卡死 | 可能过度降低，影响画质 |
| 缓慢上升 | 网络恢复后 | 避免频繁波动 | 恢复速度慢 |
| 阶梯式调整 | 网络波动频繁 | 平滑过渡，用户体验好 | 实现复杂 |
| 基于预测的调整 | 有历史数据时 | 提前调整，减少卡顿 | 需要机器学习模型 |
注意：不要频繁调整码率。我曾经见过一个项目，码率每秒钟变化十几次，结果视频画面忽好忽坏，用户投诉不断。后来我们加了“死区”逻辑——带宽变化在10%以内，不调整码率。问题就解决了。
15.6 总结与个人心得
带宽估计与拥塞控制，是WebRTC实时通信的基石。没有它，再好的编码器也白搭。
我个人觉得，学习这部分内容，最重要的是理解“延迟”和“丢包”这两个信号。它们就像汽车的仪表盘，告诉你网络是“畅通”还是“拥堵”。而GCC和Transport-CC，就是帮你解读这些信号的算法。
最后分享一个经验：不要迷信默认参数。WebRTC的默认配置适合通用场景，但你的业务可能有特殊需求。比如，在线教育可能更看重流畅度，而远程医疗可能更看重画质。这时候，你需要调整GCC的参数，甚至自己实现部分逻辑。
好了，这一章就到这里。记住，带宽估计不是万能的，但没有带宽估计是万万不能的。