3. 丢包原因分析：网络拥塞、信号衰减、路由器缓存溢出、无线网络干扰
做WebRTC的人，最怕的就是丢包。我刚开始搞实时通信那会儿，一看到丢包率往上飙，心里就发慌。后来踩的坑多了，才慢慢摸清楚——丢包不是随机事件，它背后一定有原因。你搞清楚了原因，才能对症下药。
这一章，咱们就把丢包的四个主要元凶掰开揉碎讲清楚。网络拥塞、信号衰减、路由器缓存溢出、无线网络干扰。每个我都结合项目里的真实案例来说。
3.1 网络拥塞——最常见的丢包元凶
网络拥塞，说白了就是路太窄，车太多。数据包在链路上堵成一锅粥，路由器没办法，只能扔掉一部分。
我记得有一次做跨国会议项目，用户从上海连到洛杉矶。白天还好，一到晚上高峰时段，丢包率直接飙到15%。查了半天，就是国际出口带宽被占满了。
核心判断标准：
- 丢包率与网络负载正相关（越忙越丢）
- 丢包通常是突发性的，不是均匀分布
- 伴随明显的RTT（往返时延）增大
拥塞导致的丢包，有个典型特征——它不会只丢一个包，而是一丢丢一串。因为拥塞是持续状态，不是瞬间事件。你想想看，如果链路已经满了，你发10个包过来，可能前3个过去了，后7个全被丢掉。
怎么判断是不是拥塞？我个人习惯看两个指标：
- RTT变化趋势：如果RTT从50ms慢慢涨到200ms，然后突然丢包，基本就是拥塞
- 丢包模式：连续丢包 + 丢包间隔短，拥塞可能性大
我的经验：WebRTC内置的GCC（Google Congestion Control）算法就是专门对付拥塞的。但别完全依赖它，我建议你在应用层也做一层拥塞检测，双重保险。
3.2 信号衰减——无线场景的隐形杀手
信号衰减这事儿，做有线通信的人可能不太敏感。但搞WebRTC的，尤其是做移动端、Wi-Fi场景的，几乎天天碰到。
信号衰减不是突然断网，而是信号强度慢慢变弱，误码率逐渐升高。物理层会尝试纠错，但纠不过来的时候，就只能丢包了。
我在项目中遇到过最典型的场景——用户在高铁上开视频会议。列车穿过隧道时，信号从4格掉到1格，画面直接变成马赛克。这不是网络拥塞，是信号衰减导致物理层丢包。
| 信号强度 | 典型丢包率 | 表现 |
|---|---|---|
| -50 dBm（强） | < 0.1% | 流畅 |
| -70 dBm（中） | 1% - 3% | 偶尔卡顿 |
| -85 dBm（弱） | 5% - 15% | 频繁花屏 |
| -95 dBm（极弱） | > 20% | 连接可能断开 |
信号衰减的丢包有个特点——它是随机的、均匀的。不像拥塞那样一丢一大片，而是这里丢一个，那里丢一个。这种丢包模式，对FEC（前向纠错）来说反而好处理，因为FEC擅长恢复随机丢包。
注意：信号衰减导致的丢包，单纯靠增大码率是没用的。你发得越多，物理层丢得越多。这时候应该降码率、降分辨率，或者切换到更鲁棒的编码模式。
3.3 路由器缓存溢出——Bufferbloat现象
这个坑，我估计很多工程师都踩过，但未必知道它叫Bufferbloat。
简单说，现在的路由器缓存越做越大。厂商觉得缓存大是好事，能减少丢包。但缓存太大反而坏事——数据包在路由器里排队排半天，等排到的时候，已经超时了。接收端等不及，直接当丢包处理。
我曾经帮一个客户排查问题。他们的视频通话在局域网内都卡，但ping路由器延迟才1ms。查来查去，发现是路由器开启了QoS队列，缓存深度设成了默认的1024个包。视频流进去，排队排到天荒地老。
Bufferbloat的典型症状：
- RTT忽高忽低，波动剧烈
- 丢包率不高，但用户体验极差
- 用大包ping延迟正常，小包ping延迟也正常，但混合流量时延迟飙升
怎么测Bufferbloat？
我常用的方法：同时跑一个TCP下载和一个UDP ping。如果下载时ping延迟暴涨，基本就是Bufferbloat。工具推荐用netperf + ping组合，或者直接用flent。
对付Bufferbloat，WebRTC的GCC算法其实有内置的延迟梯度检测。但说实话，效果有限。因为路由器缓存是网络设备的问题，应用层能做的只有两点：
- 降低发送速率，减少排队
- 启用NACK（否定确认）快速重传，而不是等超时
3.4 无线网络干扰——看不见的敌人
无线网络干扰，是Wi-Fi和4G/5G场景下最头疼的问题。它不像拥塞那样有规律，也不像信号衰减那样可预测。干扰是随机的、突发的、难以定位的。
我做过一个项目，在写字楼里部署视频会议系统。平时好好的，一到中午就卡。后来发现是楼里的微波炉——微波炉工作频段是2.4GHz，和Wi-Fi完全重叠。微波炉一开，Wi-Fi丢包率直接翻倍。
无线干扰的常见来源：
- 同频干扰：隔壁AP用同一个信道，互相抢时间片
- 邻频干扰：相邻信道的信号泄漏过来
- 非Wi-Fi干扰：蓝牙、微波炉、无线摄像头、ZigBee设备
- 多径衰落：信号反射、折射导致相位抵消
无线干扰导致的丢包，模式很乱。有时候连续丢，有时候间隔丢，有时候还带重传乱序。我建议你在做抗丢包设计时，把无线干扰当作最恶劣的情况来考虑。
避坑指南：我曾经在Wi-Fi环境下做过测试，发现2.4GHz频段在密集住宅区的干扰强度，比5GHz高3-5倍。如果你的用户场景是公寓、写字楼，强烈建议优先用5GHz。当然，前提是用户设备支持。
3.5 四种丢包原因对比总结
讲到这里，我把四种原因放在一起对比一下。这样你排查问题时，能快速定位。
| 丢包原因 | 丢包模式 | 伴随现象 | 排查方法 | WebRTC应对 |
|---|---|---|---|---|
| 网络拥塞 | 突发连续丢包 | RTT升高 | 看带宽利用率 | GCC降码率 |
| 信号衰减 | 随机均匀丢包 | 信号强度低 | 看RSSI/SNR | FEC + 降分辨率 |
| 缓存溢出 | 延迟抖动大 | RTT波动剧烈 | 测Bufferbloat | NACK快速重传 |
| 无线干扰 | 模式混乱 | 频谱占用高 | 频谱分析仪 | 多路径冗余 |
嗯，这张表我建议你截图保存。以后线上出问题，对着症状查原因，能省不少时间。
3.6 丢包原因分析知识图谱
下面这张SVG图，把四种丢包原因的核心特征、排查手段和应对策略串起来了。你可以把它当作一个快速参考框架。
这张图我画的时候，特意把排查手段放在最下面。因为实际工作中，你遇到丢包问题，第一步不是想怎么恢复，而是先定位原因。定位对了，后面的事就好办了。
好了，这一章的内容就到这里。四种丢包原因，每种都有它的脾气。你摸透了它们的规律，后面学抗丢包编码时，就知道什么时候该用FEC，什么时候该用NACK，什么时候该降码率。