13、带宽估计与拥塞控制：GCC算法详解、Transport-CC机制、Trendline滤波器
带宽估计与拥塞控制，说白了就是WebRTC的「交通警察」。没有它，视频通话就会卡成幻灯片，音频断断续续。我最早接触WebRTC时，以为只要把音视频数据打包发出去就行了。结果第一次上线测试，用户反馈「画面像PPT翻页」——嗯，从那以后我才真正重视起这个模块。
今天咱们就深入聊聊GCC算法、Transport-CC机制和Trendline滤波器。这三个东西，是WebRTC拥塞控制的灵魂。
13.1 GCC算法：WebRTC的拥塞控制大脑
GCC全称是Google Congestion Control，它其实是两个控制器的组合：一个基于丢包，一个基于延迟。我习惯把前者叫「粗调」，后者叫「微调」。
为什么需要两个？你想想看，丢包率上升时，网络可能已经严重拥塞了，这时候必须大幅降速。但丢包率还没变化时，延迟可能已经在悄悄增加——这就是Trendline滤波器发挥作用的地方。
核心思想：GCC通过两个独立的控制器，分别检测丢包和延迟变化，最终取两者的最小值作为发送码率。
丢包控制器比较简单：当丢包率超过某个阈值（比如2%），就认为网络拥塞，开始降速。延迟控制器则复杂得多，它需要从RTP时间戳和到达时间中，计算出延迟变化趋势。
我在项目中遇到过一个问题：WiFi信号不好时，丢包率忽高忽低，导致码率剧烈抖动。后来发现是丢包控制器的阈值太敏感了。调整之后，视频质量稳定了很多。
13.2 Transport-CC机制：延迟信息的搬运工
Transport-CC全称是Transport-wide Congestion Control。它解决了一个关键问题：如何让发送端知道每个数据包的实际到达时间？
传统的RTCP SR/RR报告，只能提供统计信息，粒度太粗。Transport-CC则通过一个扩展头，给每个RTP包打上一个传输序列号。接收端收到后，会定期发送Transport-CC反馈报文，告诉发送端：「第100到200号包，分别在时间T1到T2到达」。
| 特性 | 传统RTCP | Transport-CC |
|---|---|---|
| 反馈粒度 | 秒级 | 毫秒级 |
| 延迟信息 | 统计平均 | 逐包到达时间 |
| 带宽开销 | 较低 | 略高（但可控） |
有了这些逐包的到达时间，发送端就能精确计算每个包的延迟变化。这就是Trendline滤波器的输入数据。
避坑指南：我曾经在实现Transport-CC时，忽略了反馈报文的丢失处理。结果一旦网络抖动，反馈报文丢了，发送端就收不到任何延迟信息，码率控制直接失效。后来加了一个超时重传机制，问题才解决。
13.3 Trendline滤波器：延迟趋势的侦探
Trendline滤波器，名字听起来很唬人，其实核心思想很简单：通过线性回归，判断延迟是在上升还是下降。
具体做法是：
- 计算每个包的「单向延迟差」——也就是包的实际到达时间与期望到达时间的差值
- 将这些差值按时间排序，形成一个时间序列
- 对这个序列做线性回归，得到斜率
- 如果斜率超过某个阈值，就认为网络正在拥塞
为什么要用线性回归？因为网络延迟本身就有随机波动。如果只看单个包的延迟，很容易误判。线性回归相当于一个低通滤波器，能滤掉噪声，抓住真正的趋势。
我习惯把Trendline的阈值设得稍微保守一点。太敏感的话，网络稍微波动就降速，视频质量反而不好。太迟钝的话，拥塞已经发生了才反应，画面就会卡顿。
注意：Trendline滤波器依赖准确的时钟同步。如果发送端和接收端的时钟不同步，计算出的延迟差就是错的。实际部署时，建议用NTP或者WebRTC内置的时钟同步机制。
13.4 三者的协作流程
说了这么多，咱们用一张图来总结GCC、Transport-CC和Trendline是怎么配合的。
流程其实很清晰：
- 发送端给每个RTP包打上Transport-CC序列号，发出去
- 接收端收到后，记录每个包的到达时间
- 接收端定期发送Transport-CC反馈报文，告诉发送端每个包啥时候到的
- 发送端收到反馈后，一方面计算丢包率，丢给丢包控制器；另一方面把延迟数据喂给Trendline滤波器
- Trendline滤波器算出延迟趋势斜率，判断是否过载
- GCC综合丢包和延迟两方面的判断，最终决定目标码率
这个闭环每几十毫秒就执行一次，所以WebRTC能快速响应网络变化。我见过一些自研的拥塞控制方案，要么反应太慢，要么太激进。GCC在两者之间找到了一个不错的平衡点。
13.5 实际调优经验
最后分享几个我在实际项目中踩过的坑：
- Trendline的窗口大小：窗口太小，噪声大；窗口太大，反应慢。我一般设20-30个包，效果比较均衡。
- 丢包控制器的阈值：2%的丢包率阈值是Google的默认值。但在无线网络环境下，偶尔丢包很正常。我建议根据实际网络情况微调，比如WiFi下可以放宽到3%。
- Transport-CC的反馈频率：反馈太频繁，带宽开销大；反馈太少，延迟信息滞后。我习惯每收到20-30个包发一次反馈，或者每50ms发一次，取两者中较快的。
小技巧：调试GCC时，可以用WebRTC自带的统计接口，把码率、丢包率、延迟趋势斜率都打印出来。画成曲线图，一眼就能看出问题在哪。
好了，关于GCC、Transport-CC和Trendline，今天就聊到这儿。这三个东西是WebRTC拥塞控制的核心，理解了它们，你就掌握了WebRTC在弱网下保持通话质量的关键。
公众号:蓝海资料掘金营，微信deep3321