带宽估计与拥塞控制：WebRTC的“交通指挥官”

做音视频通信，最怕什么？

画面卡成PPT，声音断断续续，对方问你“你刚才说什么了？”——嗯，这些我都经历过。而且不止一次。

说白了，网络就像一条公路。有时候宽，有时候窄，有时候还堵车。WebRTC的带宽估计与拥塞控制，就是那个帮你规划路线、控制车速的“交通指挥官”。

今天我们就来聊聊这个指挥官是怎么工作的。

为什么需要带宽估计？

你想想看，发送端如果一股脑地把高清视频往网络里塞，而接收端网络只有1Mbps，会发生什么？

丢包、延迟、卡顿，三连击。用户体验直接崩盘。

所以，WebRTC必须知道当前网络能“吃下”多少数据。这个能力，就是带宽估计。

GCC：WebRTC的带宽估计核心算法

GCC，全称是Google Congestion Control。这是WebRTC默认使用的拥塞控制算法。我个人习惯叫它“谷歌交通管制”。

GCC主要做两件事：

• 基于延迟的估计：通过观察数据包到达时间的延迟变化，判断网络是否开始拥堵。
• 基于丢包的估计：通过统计丢包率，判断网络是否已经过载。

两者结合，给出一个最终的带宽估计值。

基于延迟的估计（Delay-based）

这个思路很有意思。它不直接看丢包，而是看“排队”。

当网络开始拥堵时，数据包会在路由器的缓冲区里排队。排队时间越长，延迟就越大。GCC通过计算“到达时间差”和“发送时间差”的差值，来判断延迟趋势。

如果延迟持续增加，说明网络快撑不住了，得降速。

基于丢包的估计（Loss-based）

这个就直观多了。丢包率超过一定阈值，说明网络已经过载，必须降速。

WebRTC里有一个丢包率阈值，默认是10%。超过这个值，带宽估计值会直接减半。

// GCC中丢包率处理的简化逻辑
if (loss_rate > 0.1) {
    estimated_bitrate = estimated_bitrate * 0.5;
} else if (loss_rate < 0.02) {
    estimated_bitrate = estimated_bitrate * 1.05;
}

嗯，代码看着简单，但实际调优时坑不少。我曾经因为丢包率统计窗口设置得太短，导致带宽估计频繁抖动，画面一会儿清晰一会儿模糊。后来把窗口从500ms调整到1s，才稳定下来。

拥塞控制策略：不只是降速

很多人以为拥塞控制就是“发现堵了，降速”。其实没那么简单。

WebRTC的拥塞控制策略包含几个关键动作：

• 码率调整：降低视频编码器的目标码率。
• 帧率调整：减少每秒发送的帧数。
• 分辨率调整：降低视频画面的尺寸。
• FEC（前向纠错）调整：增加冗余数据，对抗丢包。

这些动作不是同时进行的，而是有优先级。WebRTC会优先调整码率，如果还不够，再降帧率，最后才降分辨率。

码率自适应：让视频“随网而变”

码率自适应，说白了就是让视频的码率跟着网络带宽走。

WebRTC的码率自适应是通过编码器接口实现的。当带宽估计值变化时，WebRTC会调用编码器的SetRateControl()方法，动态调整目标码率。

// 码率自适应的核心调用
video_encoder->SetRateControl(
    estimated_bitrate,   // 当前估计带宽
    max_bitrate,         // 编码器支持的最大码率
    min_bitrate          // 编码器支持的最小码率
);

这里有个细节：编码器不是瞬间就能调整到新码率的。它需要一个“反应时间”。我记得有一次调试，发现带宽下降后，编码器花了将近2秒才把码率降下来，这期间丢包率飙升。后来我加了一个“码率平滑过渡”的逻辑，让编码器在500ms内逐步调整，问题就解决了。

Simulcast与SVC：多流与分层

当网络条件很差时，光靠码率自适应可能还不够。这时候就需要Simulcast或SVC上场了。

Simulcast：同时发送多个流

Simulcast的意思是，发送端同时编码出多个不同分辨率的视频流。比如一个720p、一个360p、一个180p。接收端根据自身网络条件，选择最合适的一路。

优点：接收端可以独立选择，灵活性高。

缺点：发送端带宽和CPU消耗大，因为要同时编码多路。

SVC：可伸缩视频编码

SVC则不同。它只编码一个流，但这个流包含多个“层”。

• 基础层：最低质量，但必须收到才能解码。
• 增强层：在基础层之上，提升质量或分辨率。

接收端可以根据网络情况，决定接收多少层。网络好，全收；网络差，只收基础层。

我个人在实际项目中更倾向于Simulcast，因为硬件编码器对Simulcast的支持更成熟。但如果你用的是软件编码器，SVC的带宽节省优势就很明显了。

知识体系总览

下面这张图，帮你把本章的核心逻辑串起来：

避坑指南

最后，分享几个我踩过的坑：

• 带宽估计抖动：我曾经遇到过带宽估计值在1秒内上下波动50%的情况。后来发现是丢包率统计窗口太小。建议窗口至少1秒。
• Simulcast流切换延迟：接收端切换Simulcast流时，会有短暂的画面冻结。这是因为新流的I帧还没到达。我建议在切换前，先请求一个关键帧。
• SVC层间依赖：SVC的增强层依赖基础层。如果基础层丢了，增强层再多也没用。所以网络差时，优先保证基础层的传输。

嗯，带宽估计与拥塞控制这块，内容确实不少。但只要你理解了GCC的核心逻辑，再结合Simulcast或SVC，大部分网络问题都能搞定。

---

公众号:蓝海资料掘金营，微信deep3321