网络基础与丢包模型：IP网络丢包原因、随机丢包与突发丢包模型、网络仿真工具介绍

做WebRTC的人，最怕什么？

不是编码器崩了，不是摄像头坏了，而是——丢包。

我入行那会儿，第一次做实时通话测试，明明码率、延迟都调好了，一上公网测试，画面直接碎成马赛克。查了半天，发现是运营商网络在高峰期随机丢了3%的包。3%啊，听起来不多，但对实时音视频来说，已经够要命了。

所以，想搞懂丢包恢复算法，得先搞清楚一个问题：包到底是怎么丢的？

IP网络丢包的根本原因

IP网络本身是"尽力而为"的。它不保证你的包一定能到，也不保证按顺序到。说白了，网络层只管转发，丢不丢是另一回事。

丢包的原因，我归纳为三类：

• 拥塞丢包：最常见。路由器或交换机的缓存满了，新来的包直接扔掉。我在项目中遇到过，某运营商晚高峰时段，丢包率能从0.1%飙到8%，就是因为骨干网带宽被占满了。
• 链路层错误：无线网络（Wi-Fi、4G/5G）里特别多。信号衰减、干扰、多径效应，都会导致比特翻转或帧校验失败，底层直接丢弃。我记得有一次调试，发现用户在电梯里通话，丢包率忽高忽低，其实就是信号波动导致的。
• 路由震荡：BGP路由表更新时，某些路由器暂时找不到下一跳，包就被黑洞了。这种情况不常见，但一旦发生，丢包是成片成片的。

两种丢包模型：随机丢包 vs 突发丢包

搞清楚了原因，接下来要建模。为什么需要模型？因为你要在仿真环境里测试算法，不能每次都上公网碰运气。

业界最常用的两种模型：

1. 随机丢包模型（Bernoulli模型）

每个包独立地以概率p被丢弃。简单、数学上好处理。适合模拟无线链路上的随机错误。

举个例子：p=0.05，意味着每个包有5%的概率丢失，且前后不相关。

但现实世界没这么理想。你想想看，网络拥塞往往是持续一段时间的，丢包会扎堆出现。这时候就需要第二种模型。

2. 突发丢包模型（Gilbert-Elliott模型）

这是一个两状态马尔可夫链：

• 好状态（Good）：丢包率很低，比如0.1%
• 坏状态（Bad）：丢包率很高，比如20%

状态之间按概率切换。这样就能模拟"一阵一阵"的丢包。

我个人的习惯是：测试FEC（前向纠错）时用随机丢包模型，测试NACK（重传）和PLC（丢包隐藏）时用突发丢包模型。因为FEC对连续丢包很敏感，而NACK在突发丢包下延迟会飙升，两种场景都要覆盖。

特性	随机丢包（Bernoulli）	突发丢包（Gilbert-Elliott）
丢包分布	独立同分布	状态相关，扎堆出现
数学复杂度	低	中
适用场景	无线随机错误	拥塞、路由震荡
对FEC的影响	恢复率较高	恢复率显著下降
对NACK的影响	延迟可控	延迟抖动大

网络仿真工具介绍

理论说完了，上工具。你不能每次都跑到真实的弱网环境里去测，成本太高。仿真工具就是你的"实验室"。

我常用的几个：

1. netem（Linux内置）

最轻量、最常用。直接加在网卡上，可以模拟延迟、抖动、丢包。

# 模拟5%随机丢包
sudo tc qdisc add dev eth0 root netem loss 5%

# 模拟突发丢包（25%概率进入坏状态，坏状态丢包率50%）
sudo tc qdisc add dev eth0 root netem loss 25% 50%

# 模拟延迟+丢包
sudo tc qdisc add dev eth0 root netem delay 100ms 20ms loss 5%

注意：netem的突发丢包模型是简单的两状态，但参数含义和Gilbert-Elliott不完全一样。我建议你读一下内核文档，别想当然。

2. WebRTC自带的仿真框架

在webrtc/modules/audio_coding/neteq/tools/和webrtc/modules/video_coding/下面，有现成的丢包仿真器。它们直接操作RTP包序列，不需要走网卡。

优点是可以精确控制每个包的丢与不丢，还能记录日志。我调试FEC时最喜欢用这个。

3. 商业工具（如Shunra、WANem）

如果你需要更逼真的网络模型（比如模拟3G/4G的时变信道），可以考虑商业工具。不过我个人觉得，前期用netem+WebRTC自带仿真器就够了，等做产品级测试再上商业工具。

本章知识体系

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

嗯，这张图把本章的脉络理清楚了。从丢包原因出发，到两种数学模型，再到仿真工具，每一步都是为后面的丢包恢复算法打基础。