3、丢包原因分析（上）：网络带宽不足、网络抖动与延迟

各位好，我是老周。今天咱们聊聊推流丢包最核心的三个原因：带宽不足、网络抖动和延迟。这三个家伙，说白了就是流媒体传输路上的「三座大山」。我在一线摸爬滚打这么多年，遇到的丢包问题里，十有八九都能归到这三类里。

你可能会问：「丢包不就是网络不好吗？」嗯，没那么简单。不同的原因，解决思路完全不同。搞错了方向，你调再多的参数也是白费力气。咱们一个一个拆开看。

3.1 网络带宽不足：最直接的「路太窄」

带宽不足，理解起来最简单。你的视频流就像一辆大卡车，网络管道就是公路。公路太窄，卡车过不去，自然就堵在那了——数据包被路由器或交换机直接丢弃。

我记得有一次帮一家直播平台排查问题。他们的主播上行带宽明明是 50Mbps，推流码率只设了 8Mbps，按理说绰绰有余。但实际推流时，每隔几秒就丢包。后来一查，发现主播用的是 4G 路由器，共享给十几个人用。高峰期实际可用带宽连 5Mbps 都不到。这就是典型的「假带宽」问题。

带宽不足导致的丢包，有几个明显特征：

• 持续性丢包：不是偶尔丢一个，而是一丢丢一串
• 码率越高丢得越狠：降低码率后丢包率明显下降
• 拥塞窗口频繁减小：TCP 连接会反复进入慢启动

怎么判断是不是带宽问题？我个人的习惯是，先做一次带宽摸底测试。用 iperf3 或者简单的 HTTP 下载测试，看看实际可用带宽到底是多少。别信运营商给你的数字，那都是理论峰值。

3.2 网络抖动：忽快忽慢的「过山车」

抖动，英文叫 Jitter。它描述的是数据包到达时间的不一致性。你想想看，如果每个包都准时到达，哪怕延迟高一点，接收端也能稳稳地播放。但问题是，网络不是这样的。

抖动产生的原因很多：路由器的队列调度、无线信号的干扰、链路上的突发流量……说白了，就是网络设备的处理能力跟不上数据流的节奏。包一会儿来得快，一会儿来得慢，接收端的缓冲区就乱了。

我在项目中遇到过最夸张的一次抖动，是在一个大型体育赛事直播中。现场几万个手机同时连网，基站负载极高。我们的推流设备测出来的抖动值高达 200ms 以上。这是什么概念？正常直播的抖动应该在 10ms 以内。200ms 的抖动，接收端的 jitter buffer 根本扛不住，要么延迟爆炸，要么大量丢包。

抖动导致的丢包，特征也很明显：

• 间歇性丢包：丢包不是连续的，而是突然丢几个，然后恢复正常
• 与码率关系不大：降低码率不一定能改善
• 接收端缓冲区频繁溢出或欠载：播放器会频繁出现卡顿或快进

3.3 网络延迟：绕远路的「快递员」

延迟，就是数据包从发送端到接收端所花的时间。它本身不会直接导致丢包，但高延迟会引发一系列连锁反应，间接造成丢包。

为什么？因为大多数传输协议（比如 TCP 和基于 TCP 的 RTMP）都有超时重传机制。如果延迟太高，发送端迟迟收不到 ACK 确认，就会认为包丢了，然后重传。重传的包又增加了网络负载，进一步加剧拥塞，最终导致真正的丢包。

我记得有一次排查一个跨国直播的丢包问题。服务器在东京，主播在纽约。物理距离摆在那，延迟至少 150ms。但问题在于，中间的路由路径绕路了——数据包从纽约到东京，居然先去了伦敦，再绕到新加坡，最后才到东京。延迟直接飙到 400ms。结果就是，TCP 连接频繁超时，重传风暴把链路打爆了。

延迟导致的丢包，特征如下：

• RTT 持续偏高：ping 值长期在 100ms 以上
• 重传率上升：抓包能看到大量重复的序列号
• 与物理距离正相关：跨洲、跨洋的链路更容易出现

3.4 三者关系：一张图看懂

说了这么多，咱们用一张图把这三个概念的关系理清楚。我画了一个简单的流程图，展示从推流端到接收端，带宽、抖动、延迟分别在哪个环节起作用。

3.5 如何快速定位主导因素？

在实际排障中，你不可能每次都做全面分析。我总结了一套快速定位的方法，用一张表格就能说清楚。

现象	可能的主导因素	快速验证方法
降低码率后丢包率明显下降	带宽不足	用 iperf3 测实际带宽，对比推流码率
丢包呈间歇性，与码率无关	网络抖动	抓包计算 jitter 值，超过 20ms 就要警惕
RTT 持续偏高，重传率上升	高延迟	ping 服务器，看 RTT 是否稳定在 100ms 以上
丢包集中在特定时间段	带宽不足（高峰期）	对比不同时段的带宽测试结果
跨地域推流丢包严重	高延迟 + 抖动	用 traceroute 看路由跳数和路径