2、网络基础与丢包模型：IP网络丢包原因、随机丢包与突发丢包模型、延迟与抖动的关联

做WebRTC开发，说白了就是在跟网络的不确定性打交道。你写的代码再漂亮，编码效率再高，一旦丢包，一切都白搭。我刚开始接触实时通信时，总觉得丢包是网络设备的问题，跟我没关系。直到有一次线上会议，用户反馈画面直接卡成PPT，我才意识到——不了解丢包，就没法做好抗丢包。

这一章，咱们就把网络底层的那些事儿掰扯清楚。你只有知道包是怎么丢的，才能知道怎么去防、怎么去补。

2.1 IP网络丢包的根本原因

丢包不是随机事件，它背后一定有原因。我总结下来，无非就这几种情况：

• 网络拥塞：这是最常见的。路由器或交换机的缓存满了，新来的包只能扔掉。就像高速堵车，收费站入口直接关闭。
• 链路质量差：无线网络、Wi-Fi、4G/5G环境下，信号衰减、干扰、多径效应都会导致比特错误。底层检测到错误后，直接丢弃这个包。
• 设备性能瓶颈：路由器CPU过载、防火墙规则过多、NAT转换压力大，都可能导致设备来不及处理，直接丢包。
• MTU限制与分片丢失：当IP包超过链路MTU时，会被分片。只要其中一个分片丢了，整个原始包都无法重组，等于全丢。

我在项目中遇到过一种情况：用户用4G网络，信号满格，但丢包率高达15%。排查了半天，发现是运营商基站侧的拥塞控制策略太激进，对UDP流量做了限速和丢包。嗯，这种问题你代码写得再好也解决不了，只能靠抗丢包策略硬扛。

2.2 随机丢包模型

随机丢包，也叫独立丢包。每个包是否丢失，跟其他包没有关系。就像抽奖，每个包都有固定的概率被丢掉。

这个模型用数学语言描述就是：

丢包率 p = 常数
每个包丢失的概率 = p，且相互独立

在WebRTC的仿真测试中，我经常用这个模型来模拟无线网络环境。为什么？因为无线链路的误码率通常是随机的，跟前后包没有强关联。

随机丢包对WebRTC的影响很直接：丢包率越高，视频质量下降越明显。但好消息是，FEC（前向纠错）在这种模型下效果很好，因为丢包是独立的，冗余包可以精准覆盖。

2.3 突发丢包模型

突发丢包就麻烦多了。它指的是丢包在时间上呈现聚集性——要么不丢，一丢就是连续好几个包。就像高速路上连环追尾，一撞就是一大片。

这个模型通常用Gilbert-Elliott模型来描述：

两个状态：
- Good状态：丢包率低（比如 0.1%）
- Bad状态：丢包率高（比如 20%）

状态之间以一定概率切换

为什么会这样？我遇到过的情况包括：

• Wi-Fi信号瞬间被遮挡（人走过、门关上）
• 路由器缓存瞬间填满后批量丢弃
• 4G/5G基站切换时的短暂中断

突发丢包对WebRTC的杀伤力更大。因为连续丢包会导致视频帧完全丢失，解码器无法参考，画面直接卡住。这时候，单纯靠FEC已经不够了，需要结合NACK（重传请求）和参考帧策略。

2.4 延迟与抖动的关联

延迟和抖动，是丢包的“孪生兄弟”。它们之间有着千丝万缕的联系。

指标	定义	与丢包的关系
延迟	数据包从发送端到接收端的单向时间	延迟增加往往意味着网络拥塞，拥塞会导致丢包
抖动	延迟的变化量（标准差或差值）	抖动大说明网络不稳定，不稳定就容易出现突发丢包

你想想看，当网络出现拥塞时，路由器缓存开始堆积，延迟就会上升。缓存满了之后，新来的包被丢弃，丢包率飙升。这时候，延迟和丢包是同步恶化的。

抖动呢？它反映的是网络状态的波动。比如Wi-Fi信号时好时坏，延迟一会儿10ms，一会儿200ms。这种波动会导致接收端的Jitter Buffer（抖动缓冲）频繁调整，要么增加延迟来吸收抖动，要么因为缓冲溢出而丢包。

我记得有一次优化一个实时视频通话项目，用户抱怨延迟太高。我尝试减小Jitter Buffer的大小，结果丢包率从2%飙升到8%。最后只能通过动态调整缓冲大小，结合FEC和NACK，才把体验拉回来。

2.5 本章知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以把它当作一个思维导图来理解。

这张图把本章的核心逻辑串起来了。从IP网络丢包的三个主要原因出发，引出两种丢包模型，再关联到延迟和抖动。你会发现，所有问题最终都指向同一个目标——在延迟、抖动、丢包之间找到最优平衡。