网络丢包原因分析：从现象到根因
做流媒体的人，谁没被丢包折磨过？
我记得刚入行那会儿，一看到推流端报丢包，第一反应就是「网络又卡了」。后来踩的坑多了才明白——丢包的原因远不止网络那么简单。你想想看，同样的网络环境，有的设备丢包率 0.1%，有的能飙到 5%，这能全怪网络吗？
这一章，我把丢包的根因拆成四类来讲。每类我都用实际项目中的案例来说明，希望能帮你少走弯路。
一、网络拥塞：最常见的丢包元凶
说白了，网络拥塞就是「路太窄，车太多」。数据包在路由器或交换机里排队，队列满了，后面的包就直接被扔掉。
核心机制：路由器/交换机的缓冲区（Buffer）是有限的。当入端口速率 > 出端口速率时，数据包在缓冲区排队。队列满 → 尾丢弃（Tail Drop）。
我在项目中遇到过最典型的场景：某安防项目，32 路摄像头同时向中心推 RTSP 流。白天正常，一到傍晚就大面积花屏。抓包一看，核心交换机出端口丢包率高达 8%。
原因是什么？傍晚是人员进出高峰期，门禁、考勤、访客系统都在用同一台交换机，瞬时流量把上行端口打满了。
| 拥塞类型 | 典型场景 | 丢包特征 |
|---|---|---|
| 瞬时拥塞 | 多路同时推流、突发流量 | 丢包集中在几毫秒内，突发性强 |
| 持续拥塞 | 上行带宽长期不足 | 丢包率稳定在 1%~5%，持续存在 |
| 微突发拥塞 | 视频 I 帧瞬间数据量暴增 | 每 2~3 秒出现一次丢包高峰 |
我的排查习惯：先看丢包是否呈周期性。如果是每 2~3 秒丢一次，大概率是 I 帧导致的微突发拥塞。这时候调小 GOP 大小或启用 I 帧切片，效果立竿见影。
二、带宽不足：不是所有丢包都叫拥塞
很多人把带宽不足和网络拥塞混为一谈。其实它们有本质区别：
- 网络拥塞：网络设备内部排队溢出，跟链路带宽不一定直接相关
- 带宽不足：链路本身的传输能力不够，数据发出去就丢了
举个例子。我曾经帮一个客户排查问题：他们用 4G 模块推 1080p 视频，码率设了 8 Mbps。4G 上行实际带宽只有 5 Mbps 左右，结果就是疯狂丢包。这不是拥塞，是带宽根本不够用。
注意：带宽不足导致的丢包，调整 QoS 或缓存策略都没用。唯一的解法是降低码率或换用更高带宽的链路。
我建议你在做 RTSP 推流前，先做一次带宽摸底测试。用 iperf 或简单的 UDP 打流工具，测一下端到端的实际可用带宽。别信运营商标称值，实测才是王道。
三、信号干扰：无线环境下的隐形杀手
做无线推流的朋友，对信号干扰应该不陌生。Wi-Fi、4G/5G、微波、蓝牙……这些无线信号在 2.4GHz 和 5GHz 频段上互相打架，丢包就成了家常便饭。
我记得有一次在展会现场做演示，RTSP 推流每隔十几秒就卡一下。查了半天，发现展馆里同时有十几个 Wi-Fi 热点，信道重叠严重。2.4GHz 频段上，干扰信号强度比我们的信号还高 10 dBm。
| 干扰类型 | 常见来源 | 对 RTSP 推流的影响 |
|---|---|---|
| 同频干扰 | 相邻 Wi-Fi AP、蓝牙设备 | 随机丢包，重传率高 |
| 邻频干扰 | 微波炉、无线摄像头 | 周期性丢包，信号质量波动 |
| 多径衰落 | 金属货架、混凝土墙 | 突发性丢包，RSSI 正常但丢包率高 |
避坑指南：我曾经在仓库项目里遇到多径衰落问题。RSSI 显示 -65 dBm，信号强度完全正常，但丢包率就是下不来。后来用频谱仪一看，反射信号比直射信号还强。解决方案很简单——换用 5GHz 频段，避开 2.4GHz 的反射干扰。
四、设备性能瓶颈：被忽视的丢包源头
这个原因最容易被忽视。很多人一看到丢包就怪网络，其实问题可能出在设备本身。
我遇到过最离谱的一次：某款网络摄像头的 CPU 主频只有 400 MHz，H.264 编码已经占用了 90% 的 CPU。当码率波动时，编码器来不及处理，直接把 RTP 包丢弃了。抓包一看，丢包发生在发送端，根本不是网络问题。
设备性能瓶颈的常见表现：
- CPU 过载：编码器丢帧，RTP 包序号不连续
- 内存不足：发送缓冲区溢出，数据包被强制丢弃
- 网卡驱动问题：中断处理不及时，DMA 缓冲区溢出
- USB 带宽限制：外接 USB 网卡时，USB 总线成为瓶颈
怎么判断是设备性能问题？我个人的经验是：在设备本地抓包。如果本地抓包已经出现丢包，那就不用查网络了，问题出在设备本身。
知识体系总览
下面这张图把四种丢包原因的关系和排查路径梳理清楚了。你可以把它当作一个快速诊断的参考框架。
如何快速定位丢包根因？
说了这么多，你可能会问：实际项目中，我怎么快速判断是哪种原因？
我个人的排查顺序是这样的：
- 先看丢包发生在哪一端。在推流端和接收端同时抓包。如果推流端已经丢包，查设备性能；如果只有接收端丢包，查网络。
- 再看丢包模式。周期性丢包 → 查 I 帧或信号干扰；随机丢包 → 查带宽或拥塞；持续稳定丢包 → 查带宽是否够用。
- 最后做交叉验证。换一台设备推同样的流，如果丢包消失，那就是设备问题；如果依然存在，那就是网络问题。
我曾经踩过的坑：有一次排查了三天，换了交换机、换了网线、甚至换了服务器，丢包依然存在。最后发现是推流设备的网卡驱动有 bug，在特定 MTU 下会随机丢包。升级驱动后问题解决。所以，别忽略软件层面的问题。
嗯，这一章的内容就到这里。四种丢包原因——网络拥塞、带宽不足、信号干扰、设备性能瓶颈——每一种都有其独特的特征和排查方法。掌握了这些，你至少能解决 90% 的丢包定位问题。