3. 网络适应性优化：NACK与RTX重传机制优化、FEC前向纠错策略、带宽估计与码率自适应、Jitter Buffer自适应调整
网络适应性，说白了就是让WebRTC在烂网络里也能活下去。我做了这么多年RTP优化，最深的体会是：没有万能的算法，只有合适的组合策略。这一章我们重点拆解四个核心模块——重传、纠错、带宽估计、抖动缓冲，看看它们怎么协同工作。
核心观点：网络适应性不是单个技术的堆砌，而是NACK、FEC、GCC、Jitter Buffer四者的闭环联动。任何一个环节掉链子，整个通话质量都会崩。
3.1 NACK与RTX重传机制优化
NACK（Negative ACKnowledgment）是WebRTC最基础的重传手段。接收端发现丢包了，就发一个NACK包回去，告诉发送端“序号X的包我没收到，赶紧补发”。
但这里有个坑——NACK风暴。我曾经在一个弱网项目中遇到过：网络抖动导致大量丢包，接收端疯狂发NACK，发送端拼命重传，结果重传包又把网络堵死了，形成恶性循环。
3.1.1 NACK触发条件与频率控制
WebRTC默认的NACK触发逻辑是这样的：
- 收到一个RTP包后，检查序列号是否连续
- 如果发现跳号（比如收到10号，但8号还没到），就生成NACK
- NACK不会立即发送，而是攒一小段时间（通常20-40ms）批量发送
我个人习惯在弱网场景下调整两个参数：
| 参数 | 默认值 | 弱网推荐值 | 说明 |
|---|---|---|---|
max_nack_list_size |
100 | 50 | 单次NACK包携带的序列号上限，减少控制包大小 |
nack_interval_ms |
20 | 40 | NACK发送间隔，避免高频冲击 |
max_nack_retransmissions |
10 | 5 | 同一个包最多重传次数，防止死循环 |
避坑指南：我曾经遇到过NACK重传次数设得太大，结果一个视频帧的某个包重传了8次才成功，但整个帧的解码时间已经超了。后来我把max_nack_retransmissions降到3次，配合FEC，效果反而更好。
3.1.2 RTX（Retransmission）流优化
RTX是RTP协议的一个扩展，专门用于重传。它使用独立的SSRC和payload type，和原始媒体流分开传输。这样做的好处是：
- 接收端可以区分原始包和重传包
- 重传包可以走不同的QoS策略（比如更高优先级）
- 便于统计重传丢包率
RTX的格式很简单：
// RTX包结构
// 原始RTP序列号被放在RTX头的payload中
// 接收端通过原始序列号关联到对应的NACK请求
RTX Header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTX SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OS SN (Original Sequence Number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
嗯，这里要注意：RTX流和原始流共享同一个带宽预算。如果你把重传流量算进发送码率里，GCC会误判网络状况。我建议把RTX流量单独统计，不参与GCC的码率计算。
3.2 FEC前向纠错策略：ULP FEC vs FlexFEC
NACK需要来回一个RTT才能恢复丢包，对于实时性要求高的场景（比如视频通话），这个延迟太致命了。FEC（前向纠错）就是干这个的——发送端提前发送冗余数据，接收端即使丢了一些包，也能直接恢复。
WebRTC里主要有两种FEC方案：ULP FEC和FlexFEC。
3.2.1 ULP FEC（Uneven Level Protection）
ULP FEC是WebRTC早期的FEC方案。它的核心思想是：对不同重要性的数据提供不同级别的保护。
比如一个视频帧，I帧比P帧重要，关键帧比非关键帧重要。ULP FEC可以做到：
- 对I帧使用(10, 8) RS码——每8个数据包生成2个冗余包，能恢复任意2个丢包
- 对P帧使用(5, 4) RS码——每4个数据包生成1个冗余包，只能恢复1个丢包
但ULP FEC有个硬伤：它只能保护连续的RTP包序列。如果丢包是分散的，保护效率会大幅下降。
3.2.2 FlexFEC（Flexible FEC）
FlexFEC是WebRTC后来引入的改进方案，我强烈推荐在新项目中使用。它的灵活性体现在：
| 特性 | ULP FEC | FlexFEC |
|---|---|---|
| 保护范围 | 连续序列号 | 任意指定包集合 |
| 掩码支持 | 不支持 | 支持位掩码精确指定 |
| 多流保护 | 单流 | 跨流（音频+视频） |
| 开销控制 | 固定比例 | 动态可调 |
| 兼容性 | 旧版浏览器 | Chrome 50+ |
FlexFEC使用FEC掩码来指定哪些包需要保护。举个例子：
// FlexFEC掩码示例
// 保护序列号 100, 101, 103, 105 这四个包
// 掩码长度 = 4字节，每bit代表一个包
FEC Mask: 0b11010100
^ ^ ^ ^
| | | +-- 序列号105
| | +----- 序列号103
| +-------- 序列号101
+----------- 序列号100
注意：FlexFEC虽然灵活，但掩码本身也会占用带宽。如果保护集合太大（比如超过16个包），掩码开销会显著增加。我一般建议每个FEC组不超过8个数据包。
3.3 带宽估计与码率自适应：GCC算法
GCC（Google Congestion Control）是WebRTC的带宽估计引擎。它负责回答一个问题：当前网络能承受多大的发送码率？
GCC有两种模式：
- 基于延迟的估计（Delay-based）：通过RTT和单向延迟变化判断网络是否拥塞
- 基于丢包的估计（Loss-based）：通过丢包率判断网络是否过载
实际工作中，GCC会把两者结合起来。我个人习惯用延迟估计作为主要依据，丢包估计作为兜底——因为丢包率往往滞后于网络变化。
3.3.1 GCC的核心公式
GCC的带宽调整逻辑可以简化为：
// 伪代码：GCC带宽调整
if (overuse_detected) {
// 网络过载，降低码率
bitrate = bitrate * (1 - 0.1);
} else if (underuse_detected) {
// 网络空闲，增加码率
bitrate = bitrate * (1 + 0.08);
} else {
// 正常状态，保持或微调
bitrate = bitrate * (1 + 0.02);
}
// 丢包率阈值
if (loss_rate > 0.1) {
// 丢包超过10%，强制降码率
bitrate = bitrate * (1 - loss_rate);
}
你想想看，这个算法其实挺朴素的。但实际部署时，我遇到过一个问题：GCC对突发丢包反应过激。有一次网络抖动导致瞬间丢包20%，GCC直接把码率砍到原来的30%，结果画面质量骤降，用户直接投诉。
我的优化方案：给GCC加一个平滑滤波器。丢包率不直接用瞬时值，而是用指数加权移动平均（EWMA）：loss_avg = 0.7 * loss_avg + 0.3 * loss_instant。这样能过滤掉毛刺，避免码率剧烈抖动。
3.4 Jitter Buffer自适应调整
Jitter Buffer（抖动缓冲）是接收端的最后一道防线。网络延迟的波动会导致包到达时间不均匀，Jitter Buffer的作用就是把这些包“捋顺”了再交给解码器。
WebRTC使用自适应Jitter Buffer，它会根据网络状况动态调整缓冲深度：
- 网络好时：缓冲浅（20-40ms），延迟低
- 网络差时：缓冲深（100-200ms），抗抖动能力强
3.4.1 Jitter Buffer的调整策略
自适应调整的核心是延迟梯度：
// Jitter Buffer调整逻辑
// 计算每个包的到达间隔与发送间隔的差值
delay_gradient = (arrival_time_n - arrival_time_n-1) -
(send_time_n - send_time_n-1);
if (delay_gradient > threshold) {
// 网络抖动增大，增加缓冲深度
jitter_buffer_depth += 10ms;
} else if (delay_gradient < -threshold) {
// 网络恢复，减少缓冲深度
jitter_buffer_depth -= 5ms;
}
我曾经在项目中遇到过一个问题：Jitter Buffer调整得太快，导致播放速度忽快忽慢，用户能明显感觉到声音在“变速”。后来我加了一个最小调整间隔——每次调整后至少等500ms才能再次调整，效果好了很多。
3.4.2 与NACK/FEC的协同
Jitter Buffer不是孤立工作的。它需要和NACK、FEC配合：
| 场景 | Jitter Buffer行为 | NACK/FEC行为 |
|---|---|---|
| 轻微丢包（<5%） | 等待重传，缓冲深度不变 | NACK重传，FEC恢复 |
| 中度丢包（5-15%） | 增加缓冲深度，等待重传 | NACK+FEC同时工作 |
| 严重丢包（>15%） | 放弃等待，直接播放已有数据 | 停止NACK，仅用FEC |
关键点：Jitter Buffer的等待时间不能超过播放阈值。比如音频的播放阈值通常是200ms，如果重传包在200ms内没到，就直接跳过，否则会导致音频卡顿。
3.5 四者协同：一张图看懂
下面这张图展示了NACK、FEC、GCC、Jitter Buffer四者的协作关系：
从这张图可以看出，整个流程是闭环的：
- GCC根据网络状况决定发送码率
- FEC在发送端生成冗余包，提供前向保护
- NACK在接收端检测丢包，发起重传请求
- Jitter Buffer缓冲并平滑数据，最终交给解码器
说白了，这四个模块就像四个齿轮，任何一个卡住，整个系统都会出问题。我在实际项目中见过太多“只调NACK不管FEC”或者“只调GCC不管Jitter Buffer”的案例，结果都是事倍功半。
总结：网络适应性优化的核心不是追求单个模块的极致性能，而是让NACK、FEC、GCC、Jitter Buffer四者形成协同。弱网环境下，建议优先保证FEC的覆盖率（至少20%冗余），然后用NACK兜底，GCC做码率平滑，Jitter Buffer做最后缓冲。这套组合拳打下来，大部分网络问题都能扛住。