9、网络传输优化：带宽估计与拥塞控制、丢包重传策略、Jitter Buffer原理
做WebRTC开发，绕不开网络传输优化。说白了，实时通信的体验好不好，就看你能不能把音视频数据在恶劣的网络环境下稳稳地送过去。我刚开始接触WebRTC时，以为只要把数据发出去就行了，结果一上公网测试，卡顿、花屏、延迟飙升……嗯，那场面真是惨不忍睹。
这一章，我们来聊聊WebRTC网络传输优化的三个核心模块：带宽估计与拥塞控制、丢包重传策略、Jitter Buffer原理。这三个东西，是WebRTC能在弱网环境下保持通话质量的基石。
核心观点：WebRTC不是靠蛮力传数据，而是靠智能的“感知-决策-调整”闭环来适应网络变化。带宽估计告诉你“路有多宽”，拥塞控制告诉你“别堵车”，丢包重传帮你“找回丢失的包裹”，Jitter Buffer则负责“把乱序的包裹排好队”。
9.1 带宽估计：摸清网络的“底牌”
带宽估计，说白了就是搞清楚当前网络到底能传多少数据。你想想看，如果不知道路有多宽，你开再好的车也白搭。WebRTC的带宽估计主要分两种思路：基于延迟的估计和基于丢包的估计。
我个人习惯把带宽估计比作“试水”。你不能一下子把数据全怼出去，得先发一点试试，看看网络的反应。如果延迟没增加，说明路还宽，可以加码；如果延迟开始飙升，说明快堵车了，得减速。
9.1.1 基于延迟的估计（GCC算法）
Google Congestion Control（GCC）是WebRTC里最核心的带宽估计算法。它的原理其实不复杂：通过观察数据包从发送到接收的延迟变化，来判断网络是否开始拥塞。
具体来说，GCC会计算每个数据包的单向延迟差（Inter-arrival time）。如果延迟差持续增大，说明网络缓冲区开始堆积，这就是拥塞的前兆。这时候，GCC会果断降低估计带宽。
我的经验：我在项目中遇到过一个问题——GCC在WiFi环境下经常误判。因为WiFi的延迟抖动本身就很大，GCC会把正常的抖动当成拥塞信号，导致带宽估计偏低。后来我们调整了GCC的阈值参数，才解决了这个问题。嗯，这里要注意，GCC的参数不是万能的，得根据实际网络环境调优。
9.1.2 基于丢包的估计（LCC）
基于丢包的估计更直接——如果发现丢包率超过某个阈值（比如5%），就认为网络已经拥塞了，需要降低发送速率。这个方法简单粗暴，但有个问题：丢包是拥塞的“结果”，不是“原因”。等你发现丢包时，网络可能已经堵死了。
所以，WebRTC通常把LCC作为GCC的补充。GCC负责“预防”，LCC负责“兜底”。两者配合使用，效果更好。
9.1.3 Transport-CC与REMB
WebRTC早期用的是REMB（Receiver Estimated Maximum Bitrate），由接收端做带宽估计。后来升级到了Transport-CC（Transport-wide Congestion Control），把估计逻辑移到了发送端。
为什么这么改？因为发送端掌握的信息更全。接收端只能看到自己收到的数据，而发送端知道实际发了多少、哪些包丢了、延迟是多少。Transport-CC通过RTCP反馈报文，把接收端的观测数据传回发送端，由发送端统一做决策。
关键点：Transport-CC是目前WebRTC推荐的带宽估计方案。它更精准，响应更快。如果你在开发新项目，建议直接用Transport-CC，别再用REMB了。
9.2 拥塞控制：别让网络“堵死”
带宽估计告诉你“路有多宽”，拥塞控制则负责“别让车流堵死”。WebRTC的拥塞控制，核心是AIMD算法（Additive Increase Multiplicative Decrease）。
AIMD的逻辑很简单：
- 加性增：网络状况好时，每次RTT增加一小部分带宽（比如10%）。
- 乘性减：检测到拥塞时，直接砍掉一半带宽。
你想想看，这种“慢升快降”的策略，就是为了避免网络突然过载。我曾经在项目中看到过一种情况：带宽估计突然飙升，发送端跟着猛发数据，结果网络瞬间崩溃，丢包率冲到30%以上。这就是没有做好Pacing（平滑发送）的后果。
9.2.1 Pacing：让数据“匀速”发送
Pacing是拥塞控制里容易被忽视的一环。很多开发者以为，带宽估计出来多少，就按这个速率发就行了。但实际网络对“突发流量”非常敏感。如果你一下子发一大波数据，网络缓冲区会瞬间填满，延迟飙升，丢包随之而来。
Pacing的作用，就是把数据均匀地分散到每个时间片里发送。WebRTC内部有一个Pacer模块，它会根据当前估计带宽，计算每个5ms时间片能发多少数据，然后排队发送。
// WebRTC Pacer 伪代码示例
class PacedSender {
public:
void SetEstimatedBitrate(int bps) {
// 每5ms允许发送的字节数
int bytes_per_interval = bps * 0.005 / 8;
pacing_rate_ = bytes_per_interval;
}
void OnSendInterval() {
// 从队列中取出不超过pacing_rate_的数据发送
int sent = SendFromQueue(pacing_rate_);
// 记录实际发送量，用于后续调整
}
};注意：Pacing不是越慢越好。如果Pacing太保守，会导致带宽利用率不足，视频清晰度下降。我见过一些团队把Pacing间隔设得过大，结果视频一直模糊，用户投诉不断。Pacing的节奏要和带宽估计匹配，这是个精细活。
9.3 丢包重传策略：找回丢失的“包裹”
网络丢包是不可避免的。WebRTC提供了多种丢包恢复手段，最常用的就是NACK重传和FEC前向纠错。
9.3.1 NACK重传
NACK（Negative Acknowledgment）是接收端发现丢包后，主动通知发送端“这个包我没收到，请重传”。发送端收到NACK后，会从历史缓存中找到对应的包，重新发送一次。
NACK的优点是带宽利用率高——只在丢包时才消耗额外带宽。但缺点也很明显：重传需要时间，会增加延迟。如果网络RTT很大（比如200ms以上），重传回来的数据可能已经过了播放时间，那就白传了。
我记得有一次做跨国会议项目，用户从中国连到美国，RTT经常在300ms以上。NACK重传回来的数据基本都过期了，视频卡得没法看。后来我们启用了FEC，才勉强把体验拉回来。
9.3.2 FEC前向纠错
FEC的思路是：发送端在发送原始数据时，额外发送一些冗余数据。即使部分原始数据丢了，接收端也能通过冗余数据恢复出来。
WebRTC常用的FEC是ULP FEC（Uneven Level Protection）和FlexFEC。FlexFEC更灵活，可以针对不同的媒体流设置不同的保护级别。
| 策略 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| NACK重传 | 带宽利用率高 | 增加延迟，依赖RTT | 低延迟、低丢包率网络 |
| FEC前向纠错 | 低延迟恢复 | 增加带宽开销 | 高丢包率、高RTT网络 |
| NACK+FEC混合 | 兼顾延迟和带宽 | 实现复杂 | 大多数生产环境 |
我的建议：不要只用一种策略。我习惯的做法是：丢包率低于5%时，只用NACK；丢包率在5%-15%时，启用FEC保护关键帧；丢包率超过15%时，同时降低视频码率并加大FEC保护力度。这叫“分层防御”。
9.4 Jitter Buffer原理：让数据“排队”
Jitter Buffer，中文叫“抖动缓冲”，是WebRTC接收端的一个关键模块。它的作用，说白了就是把网络传输中产生的抖动抹平。
网络传输不是匀速的。数据包到达的时间可能忽早忽晚，甚至乱序。如果没有Jitter Buffer，播放器就会一会儿快一会儿慢，用户体验极差。
9.4.1 自适应抖动缓冲
WebRTC的Jitter Buffer是自适应的。它会根据网络抖动的程度，动态调整缓冲区的深度。网络抖动大时，缓冲区加深，以吸收更多的抖动；网络稳定时，缓冲区变浅，以降低延迟。
这个自适应过程，是通过统计每个数据包的到达时间差来完成的。WebRTC内部维护了一个抖动估计器，它会计算到达时间的方差，然后根据方差设置缓冲区大小。
// Jitter Buffer 自适应调整伪代码
class JitterBuffer {
public:
void OnPacketArrived(uint32_t timestamp, int64_t arrival_time_ms) {
// 计算到达时间差
int64_t inter_arrival = arrival_time_ms - last_arrival_time_;
// 更新抖动估计
jitter_estimate_ = UpdateJitter(inter_arrival);
// 根据抖动设置缓冲区目标深度
target_depth_ = jitter_estimate_ * kSafetyFactor;
// 调整缓冲区大小
ResizeBuffer(target_depth_);
}
private:
int64_t jitter_estimate_;
int target_depth_;
};9.4.2 音频与视频的Jitter Buffer差异
音频和视频对Jitter Buffer的要求不一样。音频对延迟更敏感，缓冲区不能太大，否则说话会有“回音感”。视频对延迟相对宽容一些，但缓冲区太小会导致画面频繁卡顿。
WebRTC把音频和视频的Jitter Buffer分开管理。音频Jitter Buffer通常更浅（比如50ms-100ms），视频Jitter Buffer可以更深（比如200ms-500ms）。
避坑指南：我曾经犯过一个错误——把音频Jitter Buffer设得和视频一样深。结果用户反馈说“说话有延迟，像对讲机”。后来我才意识到，音频的实时性要求比视频高得多。音频Jitter Buffer的深度，一定要单独调优。
9.4.3 时间戳校准与播放控制
Jitter Buffer的另一个重要功能是时间戳校准。每个RTP包都带有一个时间戳，Jitter Buffer会根据这个时间戳，把数据包按正确的顺序排列好，然后交给解码器。
如果数据包乱序了，Jitter Buffer会先缓存起来，等前面的包到齐了再一起送解码。如果某个包一直没到（比如丢了），Jitter Buffer会等待一个超时时间，然后跳过这个包，继续播放后面的数据。
这个超时时间怎么设？设短了，画面容易出现“跳帧”；设长了，延迟会变大。WebRTC的默认策略是：等待一个RTT的时间，如果还没收到，就放弃。
总结一下：Jitter Buffer是WebRTC网络传输优化的“最后一公里”。它把网络的不确定性挡在门外，给解码器提供一个稳定、有序的数据流。没有Jitter Buffer，再好的带宽估计和拥塞控制都是白搭。
好了，这一章的内容就到这里。网络传输优化是个系统工程，带宽估计、拥塞控制、丢包重传、Jitter Buffer，这四个模块环环相扣，缺一不可。你在实际项目中，一定要根据网络环境做针对性调优，不要指望一套参数打天下。