实时音视频 rtc 的拥塞控制算法到底有哪些？

周末和朋友视频聊天的时候，你有没有遇到过这种情况：画面突然卡住，声音断断续续，过几秒钟又自己恢复了？很多人第一反应是"网不好"，但实际上，这背后涉及到一项非常关键技术——拥塞控制。它就像一个智能交通指挥员，当网络发生拥堵时，决定哪些数据该优先通行，哪些可以稍后再说。

对于做实时音视频的开发者来说，拥塞控制算法选对了，视频通话流畅清晰；选错了，用户体验就会大打折扣。今天这篇文章，我想用一种比较接地气的方式，跟大家聊聊目前主流的拥塞控制算法类型，以及它们各自的优缺点。文章不会堆砌太多公式概念，力求让非技术背景的朋友也能看个大概。

什么是拥塞控制？为什么要重视它？

在展开具体算法之前，我们先来简单理解一下拥塞控制的核心目标。想象一下早晚高峰的北京二环，车流量巨大但道路容量有限，如果所有车都拼命往里挤，最后结果就是堵死谁也走不了。网络传输也是一样的道理：当发送方数据量超过网络承载能力时，就会出现丢包、延迟飙升等问题。

拥塞控制的作用，就是在保证传输质量的前提下，尽可能高效地利用网络带宽。它需要回答三个关键问题：当前网络能承载多大的数据量？怎么判断网络是否开始拥堵？发现拥堵后该怎么调整？不同的算法流派，对这三个问题有着截然不同的回答方式。

拥塞控制算法的分类体系

如果从大的分类维度来看，主流的拥塞控制算法可以按照以下几个维度来划分。我整理了一个概览表，帮助大家先建立整体认知：

分类维度	主要类型	核心判断依据
基于反馈信号	丢包-based、延迟-based、带宽-based	丢包率、延迟变化、带宽探测
控制模型	AIMD、基于模型、基于强化学习	线性增减、数学模型、机器学习
部署方式	发送端控制、接收端控制、协同控制	控制逻辑所在位置

这个分类表只是一个粗略的划分，实际应用中很多算法会融合多种思路。比如现在应用最广泛的 GCC 算法，就是结合了丢包检测和延迟检测的混合方案。接下来我们逐一展开聊聊。

基于丢包的拥塞控制算法

这是最经典也是最早出现的一类算法流派。它们的核心理念非常直观：丢包了，说明网络堵了；没丢包，说明还有余地。TCP 的经典拥塞控制算法基本都属于这个流派，比如 Reno、CUBIC 等。

这类算法的工作模式通常采用 AIMD（加性增乘性减）策略：没丢包时就慢慢增加发送速率，一旦检测到丢包就大幅降低速率。这种方式优点是实现简单、稳定性好，但它有一个明显的缺陷——它把丢包当作拥塞的唯一信号。而在实际网络环境中，丢包可能由很多原因造成：无线网络信号干扰、硬件故障、缓冲区溢出等等。

更重要的是，对于实时音视频场景来说，等丢包发生后再做反应往往已经慢了半拍。因为从丢包到检测到丢包，再到调整策略，这个过程可能已经导致了几百毫秒的延迟，用户在这期间已经感受到卡顿了。所以纯丢包-based 的算法在 rtc 领域并不是最优选择。

基于延迟的拥塞控制算法

延迟-based 算法的思路就聪明多了。它们认为，拥塞的发生是有预兆的——当网络开始变得拥挤时，数据在路由器缓冲区里排队的时间就会变长，延迟就会开始上升。如果我们能在延迟刚刚开始上升时就察觉到问题，就可以比等到丢包发生更早地做出反应。

这类算法的代表是 TCC（Transport Congestion Control）和 SCReAM。它们通过持续监测接收端延迟的变化趋势，来判断网络是否即将发生拥塞。具体来说，会计算往返延迟的变化率（也叫延迟梯度），如果延迟开始持续增长，就认为网络出现拥塞风险，需要降低发送速率。

这种方式的优点是反应更及时，可以做到"拥塞未发生，我先调整好"。但它也有自己的挑战：延迟变化的因素很多，除了网络拥塞，可能还有路由变化、无线信号波动等其他原因，如何准确区分这些因素是一个技术难点。另外，在某些高带宽低延迟的网络环境下，延迟的变化可能不够明显，导致算法不够敏感。

基于带宽估计的拥塞控制算法

还有一类算法走的是另一个路线——主动探测。它们不等待网络"出事"，而是定期主动探测：我当前这条路最多能承载多大的流量？

这类算法的典型代表是 BBR（Bottleneck Bandwidth and Round-trip propagation time）。BBR 的核心思想是：通过持续测量两个关键指标——瓶颈带宽（管道最窄处的容量）和往返传播延迟（不受排队影响的物理延迟），建立起网络管道的精确模型。然后让发送速率始终维持在由这两个指标决定的"最佳甜蜜点"附近。

BBR 的优势在于它的目标不是把缓冲区塞满，而是精确找到物理带宽的边界。这让它在长肥网络（高带宽高延迟的网络）上表现尤为出色。但它的缺点是在带宽竞争场景下可能比较"激进"，与传统的 CUBIC 等算法共存时可能互相干扰。这也是为什么在实际部署中，BBR 通常需要配合其他机制一起使用。

RTC 领域的明星：GCC 算法

说到 RTC 领域的拥塞控制，就不得不提 GCC（Google Congestion Control）。这是谷歌开源的一个拥塞控制算法，目前被广泛应用于 webrtc 项目中，也可以说是 RTC 行业的事实标准之一。

为什么 GCC 能成为主流？因为它是一个混合方案，融合了丢包-based 和延迟-based 两种思路。具体来说，它包含两个并行工作的控制器：

• 丢包率控制器：当检测到丢包时，根据丢包率来调整目标码率。丢包率越高，目标码率降得越低。
• 延迟控制器：通过分析接收端延迟的变化趋势，在延迟开始上升时就提前调整码率。

最终的目标码率由这两个控制器的输出取最小值决定。这种设计让 GCC 既能在明显丢包时快速响应，又能在延迟刚有苗头时就提前预防，可以说兼顾了可靠性和及时性。

不过，GCC 也不是没有缺点。它的参数调优相对复杂，在不同的网络环境下可能需要针对性地调整。而且它的延迟检测机制在某些弱网环境下可能不够稳定，导致码率波动较大。这也是为什么很多团队会在 GCC 基础上进行二次开发和优化。

其他值得关注的技术方向

除了上面介绍的几类主流算法，还有一些新兴方向值得关注。

基于强化学习的拥塞控制是近年来的研究热点。传统的拥塞控制算法通常基于固定的规则或模型，面对复杂多变的网络环境可能不够灵活。而强化学习算法可以"学习"不同网络状态下的最佳响应策略，从而实现更智能的控制。目前已经有一些研究尝试将强化学习应用于 RTC 场景，并取得了一些积极成果。但这类方法目前在工业界的大规模应用还面临挑战，主要是因为模型训练成本高、可解释性差、在极端网络环境下可能出现意外行为。

跨层优化的拥塞控制也是一个重要趋势。传统上，拥塞控制主要在传输层工作，但实际上，物理层、链路层都包含丰富的网络状态信息。如果能综合利用这些跨层信息，就可以更准确地感知网络状况。目前有一些算法尝试结合 LTE/5G 的信道状态信息、WiFi 的信号强度等数据来辅助拥塞决策，在特定场景下取得了不错的效果。

声网的实践与思考

作为全球领先的实时音视频云服务商，声网在拥塞控制领域有着深厚的积累。我们深知，拥塞控制不是孤立的技术点，而是需要与音视频编解码、网络传输、抗丢包策略等多个模块协同配合的系统工程。

声网的技术团队在拥塞控制算法上的探索从未停止。我们的目标是让用户在各种网络环境下都能获得尽可能好的通话体验，无论是稳定的办公室 WiFi，还是信号不太好的地铁车厢里。

在技术实现上，声网采用了多维度感知 + 分层响应的策略。除了传统的丢包率、延迟等指标，我们还会综合考虑网络类型切换、抖动模式识别、用户行为特征等信息，力求更全面地理解当前的网络状况。在响应策略上，我们会根据不同的场景特点动态调整——比如直播场景和通话场景对延迟的敏感度不同，相应的调控策略也会有所差异。

值得一提的是，声网的服务覆盖全球超过 60% 的泛娱乐 APP，这意味着我们需要面对极其多样化的网络环境。从一线城市的千兆光纤到偏远地区的移动网络，从稳定的桌面环境到复杂的移动场景，这种广泛的覆盖让声网积累了丰富的网络适应经验，也驱动着我们在拥塞控制技术上不断迭代优化。

写在最后

聊了这么多，相信大家对 RTC 拥塞控制算法有了更全面的认识。回顾一下：我们介绍了基于丢包、延迟、带宽估计的几种主流算法，也聊了聊 GCC 这个行业标准，以及一些新兴的技术方向。

技术在发展，算法也在演进。5G 网络的普及、边缘计算的兴起、多人互动场景的丰富，都在给拥塞控制提出新的挑战。可以预见，未来的拥塞控制算法会更加智能化、场景化，能够更好地适配不同的应用需求。

如果你正在开发音视频相关的产品或应用，建议根据自己的场景特点多做一些测试。不同的算法在不同的网络环境下表现差异可能很大，没有放之四海而皆准的最优解。只有深入理解自己的用户场景，才能做出最合适的技术选择。

希望这篇文章对你有帮助。如果有什么问题或者想法，欢迎交流讨论。