网络基础与丢包模型：IP网络丢包原因、随机丢包与突发丢包模型、网络抖动与延迟、带宽估计基础
各位同学，咱们今天聊点实在的。做WebRTC，说白了就是在跟网络较劲。你写的代码再漂亮，算法再精妙，网络一抖，全白搭。我刚开始做实时通信那会儿，总觉得把编码器调好就万事大吉了，结果线上跑起来，用户反馈卡成PPT。后来才明白——不懂网络，就别谈实时通信。
这一章，咱们把地基打牢。我会从IP网络为什么丢包讲起，然后带你看看两种典型的丢包模型，再聊聊抖动和延迟这对冤家，最后给带宽估计开个头。嗯，内容不少，但都是干货。
1. IP网络为什么会丢包？
先问个问题：IP网络的设计初衷是什么？尽力而为。说白了，路由器会尽量帮你把数据包送到目的地，但它不保证一定能送到。为什么会这样？
我总结了几种最常见的丢包原因：
- 队列溢出（Buffer Overflow）：这是最常见的。路由器或交换机的缓存是有限的，当瞬间流量超过缓存容量，新来的包就只能被丢弃。我在项目中遇到过，某个节点在晚高峰时丢包率从0.1%飙升到5%，查了半天，就是一台老交换机缓存太小。
- 链路层错误：物理介质的问题，比如Wi-Fi信号干扰、网线接触不良、光纤老化。这种丢包通常是随机的，而且跟信号质量强相关。
- 路由环路：路由表配置错误，导致数据包在几个路由器之间来回转圈，直到TTL耗尽被丢弃。嗯，这个在大型网络里偶尔会遇到，配置BGP时尤其要小心。
- 拥塞控制主动丢弃：比如RED（Random Early Detection）算法，在队列还没满的时候就随机丢一些包，让发送端感知到拥塞，主动降速。这其实是网络的一种自我保护机制。
- 防火墙/NAT策略：某些安全策略会直接丢弃不符合规则的包，比如非标准端口的UDP流量。WebRTC用的就是UDP，经常被企业防火墙误杀。
核心认知：丢包不是bug，是网络的一种正常行为。WebRTC要做的是在丢包发生时，依然提供可用的通信质量。
2. 随机丢包 vs 突发丢包
搞清楚了丢包原因，咱们得给丢包分个类。为什么？因为不同的丢包模式，需要用不同的恢复策略去应对。
我个人习惯把丢包模型分成两种：随机丢包和突发丢包。你想想看，这两种模型背后的物理意义完全不同。
2.1 随机丢包模型
随机丢包，也叫独立丢包。每个包被丢弃的概率是独立的，跟前后包没有关系。这种模型通常用丢包率（p）一个参数就能描述。
什么场景下会出现随机丢包？
- 无线网络中的信号衰落
- RED算法的主动丢弃
- 链路层比特错误导致的CRC校验失败
数学上，随机丢包可以用伯努利过程来建模。每个包到达的概率是1-p，丢失的概率是p。简单，但很实用。
我的经验：在Wi-Fi环境下，随机丢包率通常在0.5%~3%之间。如果你测出来丢包率超过5%，那大概率不是随机丢包，而是有更严重的问题。
2.2 突发丢包模型
突发丢包就复杂多了。它指的是丢包在时间上呈现聚集性——要么连续好几个包都丢了，要么一个都不丢。这种模型通常用Gilbert-Elliott模型来描述，有两个状态：好状态（Good）和坏状态（Bad）。
在好状态下，丢包率很低（比如0.1%）；在坏状态下，丢包率很高（比如20%~50%）。状态之间的切换由转移概率控制。
什么场景下会出现突发丢包？
- 路由器队列溢出：瞬间流量高峰导致连续丢包
- Wi-Fi信号瞬间中断：比如你拿着手机从客厅走到卧室
- LTE切换：基站切换时会有几十到几百毫秒的中断
| 特性 | 随机丢包 | 突发丢包 |
|---|---|---|
| 丢包分布 | 独立、均匀 | 聚集、成簇 |
| 典型丢包率 | 0.1%~3% | 5%~50%（突发期间） |
| 适用场景 | 有线网络、稳定Wi-Fi | 移动网络、拥塞链路 |
| 恢复策略 | FEC（前向纠错）效果好 | 重传（NACK/RTX）更可靠 |
注意：不要把随机丢包的恢复策略直接套用到突发丢包上。我曾经在一个项目中，用FEC去对抗4G网络的突发丢包，结果发现FEC开销巨大，但恢复效果很差——因为突发长度超过了FEC的保护范围。
3. 网络抖动与延迟
丢包之外，还有两个指标直接决定了用户体验：延迟和抖动。
延迟好理解，就是数据包从A到B花的时间。但WebRTC里我们更关心的是端到端延迟，包括编码延迟、网络传输延迟、解码延迟、渲染延迟。网络传输延迟只是其中一环。
抖动呢？说白了就是延迟的变化量。同一个流里，包1花了10ms，包2花了50ms，包3花了15ms——这种波动就是抖动。
为什么抖动比延迟更致命？
- 延迟高，用户能感觉到「慢」，但画面还是连续的。
- 抖动大，音频会断断续续，视频会卡顿，因为接收端不知道下一个包什么时候到。
WebRTC怎么对抗抖动？答案就是JitterBuffer（抖动缓冲）。接收端维护一个缓冲区，把收到的包先存起来，等缓冲区积累到一定量再开始播放。这样就能平滑掉网络抖动。
但这里有个trade-off：缓冲区越大，抗抖动能力越强，但延迟也越大。WebRTC的NetEQ（针对音频）和视频JitterBuffer会动态调整缓冲区大小，在延迟和抗抖动之间找平衡。
关键指标：对于实时通信，我们通常要求单向延迟 < 150ms，抖动 < 30ms。超过这个范围，用户就能明显感觉到「不实时」了。
4. 带宽估计基础
最后，咱们聊聊带宽估计。这是WebRTC拥塞控制的核心，也是后面几章的重点。这里先打个基础。
带宽估计要回答一个问题：当前网络能承载多少码率？
WebRTC的带宽估计主要分两类：
- 基于延迟的估计（GCC - Google Congestion Control）：通过观察数据包延迟的变化趋势来判断网络是否拥塞。延迟在增加？说明队列在堆积，带宽可能不够了，要降码率。
- 基于丢包的估计：丢包率超过一定阈值（比如5%），就认为网络拥塞，主动降码率。
实际实现中，WebRTC会把两者结合起来。我记得在Chrome的早期版本里，GCC主要依赖延迟信号，后来发现纯延迟估计在无线网络下不太准，又加入了丢包反馈作为辅助。
带宽估计的输出是一个目标码率，编码器会根据这个码率调整编码参数。如果估计得太乐观，网络会持续拥塞，丢包飙升；如果估计得太悲观，视频质量会不必要地下降。所以，准确、及时的带宽估计是WebRTC质量的基石。
一个小技巧：调试带宽估计时，我习惯在接收端打印两个值：target_bitrate（估计的目标码率）和actual_receive_rate（实际接收速率）。如果两者差距超过20%，说明估计模型可能有问题。
本章知识体系
下面这张图，我把本章的核心逻辑串起来了。你可以把它当作一个思维导图来用。
这张图把本章的四个核心模块串在了一起。从丢包原因出发，到丢包模型分类，再到抖动延迟的影响，最后落到带宽估计——每一步都是为后面的丢包恢复技术做铺垫。