实时音视频 rtc 的拥塞控制算法到底有哪些？一位工程师的实战视角

去年做音视频项目的时候，我第一次真正意识到网络拥塞控制这事儿有多让人头疼。那时候我们用了一个开源方案，在办公室测试环境里效果挺好，结果一到真实网络环境，视频就开始疯狂卡顿、马赛克不断。后来深入研究才发现，问题的根源就在于拥塞控制算法没选对。这篇文章就来聊聊，实时音视频领域里到底有哪些主流的拥塞控制算法，它们各自是什么来头，适合什么场景。

先搞明白：为什么 rtc 这么依赖拥塞控制？

在展开算法之前，我觉得有必要先说清楚为什么实时音视频对拥塞控制这么敏感。你想啊，我们平时看在线视频，如果网络卡了，顶多缓冲几秒钟，体验虽然不好但还能接受。但实时音视频不一样，它是「实时」的——你跟朋友视频通话，对方说的话必须立刻传到你这里，晚个几百毫秒就会明显感觉不自然，要是丢包严重了那画面更是没法看。

这就决定了 RTC 场景下的拥塞控制必须在极短时间内做出反应，不能像传统 TCP 那样等个几百毫秒再重传。它需要在保证低延迟的前提下，尽可能利用可用带宽，同时还得对网络状况的变化保持敏感。说白了就是要在「激进」和「保守」之间找平衡，既不能太贪心把网络撑爆，也不能太怂导致视频质量下降。

当下主流的拥塞控制算法大致可以分为几类，我分别来说说。

基于时延的拥塞控制算法

这类算法的核心思路很简单：网络一旦发生拥塞，数据包在路由器里的排队时间就会变长，端到端延迟就会上升。通过监测延迟的变化趋势，算法就能判断网络是否开始拥塞，进而调整发送速率。

Google 提出的 GCC（Google Congestion Control）是这类算法里最具代表性的一个。它把拥塞控制分成两个部分：发送端的速率控制和接收端的拥塞控制。接收端会计算丢包率和接收延迟的变化，然后把这两个信号发送给发送端，发送端根据这些信号来调整码率。

GCC 的延迟变化检测做得挺精细的。它会用卡尔曼滤波器来估算当前的端到端延迟，然后计算延迟的变化率。如果延迟突然上升，说明可能开始排队了，算法就会降低码率；反之如果延迟稳定甚至下降，就可以适当提高码率。这种方法的优势在于它比丢包信号更敏感，往往能在真正发生丢包之前就开始调整，起到预防作用。

不过基于时延的算法也有它的软肋。最大的问题是怎么区分「网络拥塞导致的延迟上升」和「端到端路径本身延迟的波动」。比如有时候 wifi 信号不稳定，或者对方手机打开了一个大应用导致处理延迟，这些都会让延迟测量值出现波动，如果算法把这些误判为拥塞信号，就会过于保守地降码率，反而浪费了带宽。

SCReAM 是另一个比较有意思的基于时延的算法。它的设计思路更侧重于保持队列长度稳定。SCReAM 会维护一个目标队列长度，当实际队列长度超过目标值时就降速，低于目标值时就提速。这种主动队列管理的方法在某些场景下效果不错，特别是对于那些对延迟抖动比较敏感的应用。

基于丢包的拥塞控制算法

这类算法相对传统一些，它的核心逻辑是：丢包说明网络已经出现了拥塞，必须降低发送速率。最典型的就是 TCP 那种 AIMD（加性增、乘性减）策略——发现丢包就把窗口减半，没丢包就慢慢增加窗口。

在 RTC 领域，纯丢包驱动的算法用得其实不算多。原因很简单：等到检测到丢包的时候，网络拥塞可能已经比较严重了，这时候再调整可能已经错过了最佳时机。特别是对于实时音视频来说，丢包往往意味着视频帧缺失，直接影响画质，而基于时延的算法可以更早地做出预警。

不过这并不意味着丢包信号没用。实际上，很多成熟的方案都会把丢包率和时延变化结合起来使用，各自取长补短。比如当检测到轻微丢包时，可能只是稍微降一点码率；但如果丢包率突然飙升，那就得大幅降低发送速率甚至暂停发送。

BBR：谷歌的另一个大招

BBR（Bottleneck Bandwidth and Round-trip propagation time）是谷歌在 2016 年提出来的算法，它跟传统算法有本质的区别。传统算法关注的是「网络里有多少数据在排队」，而 BBR 关注的是「网络实际能承载多大的流量」。

BBR 的核心思想是测量两个关键指标：瓶颈带宽（BtlBw）和往返传播时延（RTT）。瓶颈带宽指的是管道最窄处的容量，而传播时延是数据包在网络里「裸奔」不受排队影响的时间。有了这两个值，BBR 就能精确地知道当前的发送速率应该控制在什么范围内——既不会让管道溢出，也不会让管道空闲。

具体来说，BBR 会持续探测这两个参数。在稳态下，它会把发送速率控制在瓶颈带宽左右，同时让队列保持在一个很短的稳定状态。这样做的好处是既能充分利用带宽，又能把延迟控制在较低水平。对于 RTC 来说，这种特性其实是挺理想的。

不过 BBR 在实现上复杂度比较高，需要持续进行带宽探测，这在某些场景下可能会导致瞬时的速率波动。另外，在跨运营商、跨国的复杂网络环境下，BBR 的探测结果可能不太稳定。国内有些团队在使用 BBR 时会做一些定制化的调优，比如调整探测周期、添加平滑滤波等等。

声网在拥塞控制上的实践

说到 RTC 领域的实际应用，不得不说声网在这个方向上的积累确实挺深厚的。他们在拥塞控制上的策略并不是简单地选某一个算法，而是根据实际网络环境动态调整。

声网的方案会实时监测网络状况，包括丢包率、延迟、抖动、可用带宽等多个维度。当检测到网络开始拥塞时，系统会综合判断当前的拥塞程度，然后选择合适的应对策略。如果只是轻微的带宽波动，可能只是适当降低帧率或分辨率；如果拥塞比较严重，那可能需要切换到更保守的编码策略甚至改变传输方案。

他们特别提到过一点我挺认同的：拥塞控制不能只看网络指标，还得考虑人的感知。比如音频和视频的优先级怎么分配，不同场景下用户对画质和延迟的敏感度如何，这些都需要在算法之外做大量的体验调优。毕竟技术是为人服务的，最终的评判标准还是用户的主观感受。

还有哪些值得关注的方向？

除了上面说的几类主流算法之外，还有一些新兴的思路值得关注。

基于机器学习的拥塞控制这几年有不少研究。传统的算法都是基于固定的规则，比如「丢包了就降速」，但真实网络环境太复杂了，规则很难覆盖所有情况。机器学习的方法可以学习历史数据中的模式，对复杂的网络状况做出更智能的响应。不过目前这类方案在 RTC 领域的实际落地案例还不是特别多，主要是模型的泛化能力和实时性还需要进一步验证。

另外，SVC（可分层编码）和拥塞控制的结合也是一个有趣的方向。传统的拥塞控制是调整整体的发送码率，但有了 SVC 之后，可以只传输基本层保证流畅度，有余量的时候再传输增强层。这种细粒度的控制方式在某些场景下可能比单纯的码率调整更高效。

最后说几句

聊了这么多，其实我想表达的核心观点是：拥塞控制没有银弹，不存在一个算法能在所有场景下都表现得最好。不同的网络环境、不同的应用场景、不同的性能要求，都可能需要不同的解决方案。

在实际项目中，我的经验是先搞清楚自己的核心诉求是什么——是更低的延迟，还是更稳定的画质，还是更高的带宽利用率？然后再根据这些诉求去选择和调优算法。最后，务必在实际网络环境下充分测试，因为实验室里的数据和真实环境的表现往往差距很大。

希望这篇文章能帮你对 RTC 拥塞控制有一个更全面的认识。如果正在做相关的技术选型，建议多结合自己的实际场景做些 POC 测试，毕竟只有实践才能告诉你哪个方案真正适合你。