4、丢包率分析：丢包如何导致卡顿、使用 Wireshark 抓包分析丢包、丢包容忍度阈值
说到推流卡顿，很多人第一反应是带宽不够。其实我这些年排查下来，丢包才是真正的隐形杀手。带宽低顶多是画面模糊，丢包一上来，画面直接卡成幻灯片，甚至黑屏。今天我们就来把丢包这件事彻底讲透。
4.1 丢包是如何导致卡顿的？
先看一个最简单的场景。你正在推流，每帧视频数据被切成一个个 RTP 包发出去。假设一帧有 10 个包，第 5 个包丢了。
接收端拿到第 1-4 个包，等第 5 个包。等了一会儿没等到，继续收第 6-10 个包。但解码器需要完整的一帧才能解码。缺了第 5 个包，这一帧就解不出来。
结果是什么？要么这一帧直接丢弃，画面出现跳帧；要么解码器等待重传，造成延迟累积。 你想想看，如果丢包率是 5%，每 20 个包就丢 1 个，那画面基本就是一步一卡。
核心结论：丢包导致卡顿的根因在于 数据不完整 → 解码失败 → 帧等待/丢帧 → 播放节奏被打乱。这不是带宽问题，是数据完整性问题。
我在项目中遇到过一种情况：客户反馈推流卡顿，但带宽测出来有 50Mbps，完全够用。后来抓包一看，丢包率高达 8%。运营商线路质量差，带宽再大也没用。
4.2 使用 Wireshark 抓包分析丢包
Wireshark 是我排查丢包问题的首选工具。说白了，它就是网络世界的显微镜。下面我带你走一遍完整的抓包分析流程。
4.2.1 抓包前的准备
- 确定抓包点：最好在推流端和接收端同时抓包。如果条件有限，至少在被怀疑有问题的节点上抓。
- 设置过滤条件：只抓推流相关的流量，避免数据太多看花眼。
- 保存抓包文件：抓个 30 秒到 1 分钟就够了，文件太大反而不好分析。
我个人习惯用这个过滤表达式：
udp.port == 1935 || udp.port == 8080 || rtp这样只保留 RTMP 或 RTP 相关的 UDP 包，干净利落。
4.2.2 如何从抓包中识别丢包
抓完包之后，怎么判断有没有丢包？我教你三个最实用的方法。
方法一：看 RTP 序列号
每个 RTP 包都有一个序列号（Sequence Number），从 0 开始递增。如果序列号出现跳变，比如从 100 直接跳到 103，中间缺了 101 和 102，那就是丢包了。
在 Wireshark 里，你可以把 RTP 序列号列出来：
- 选中一个 RTP 包，右键 → Follow → UDP Stream
- 在弹出窗口里，找到 Sequence Number 列
- 观察是否有跳变
方法二：用 Wireshark 的 RTP 分析工具
Wireshark 自带 RTP 分析功能，非常方便：
Statistics → RTP → Show All Streams选中你的推流流，点击 Analyze。Wireshark 会直接告诉你：
- 总包数
- 丢包数
- 丢包率
- 抖动（Jitter）
小技巧：如果丢包率超过 1%，Wireshark 会用红色标记。一眼就能看出问题。
方法三：看 RTCP 的丢包反馈
RTCP 包里有接收端报告的丢包统计。找到 RTCP Sender Report (SR) 或 Receiver Report (RR)，里面有个 Fraction Lost 字段，直接就是丢包率。
4.2.3 实战案例：一次典型的丢包分析
我记得有一次帮客户排查卡顿，抓包后看到这样的数据：
| 时间戳 | RTP 序列号 | 包大小 (Bytes) | Delta (ms) |
|---|---|---|---|
| 0.000 | 1000 | 1350 | 0 |
| 0.010 | 1001 | 1350 | 10 |
| 0.020 | 1002 | 1350 | 10 |
| 0.035 | 1004 | 1350 | 15 |
| 0.045 | 1005 | 1350 | 10 |
看到没有？序列号从 1002 直接跳到 1004，中间缺了 1003。这就是一个丢包。而且 1004 包的到达时间比预期晚了 5ms，说明网络已经出现拥塞。
继续往下看，丢包率统计：
Total packets: 1500
Lost packets: 45
Loss rate: 3.0%
Jitter: 12.3ms3% 的丢包率，加上 12ms 的抖动，卡顿是必然的。
4.3 丢包容忍度阈值
丢包率多少算正常？多少会卡顿？我直接给你一个经验值表：
| 丢包率范围 | 用户体验 | 建议措施 |
|---|---|---|
| < 0.1% | 几乎无感知 | 正常，无需处理 |
| 0.1% - 0.5% | 偶尔轻微卡顿 | 建议开启 FEC 或 ARQ |
| 0.5% - 2% | 明显卡顿，画面跳帧 | 必须启用抗丢包策略 |
| 2% - 5% | 严重卡顿，无法观看 | 降低码率 + 启用重传 |
| > 5% | 画面冻结或黑屏 | 建议切换网络或降分辨率 |
注意：这个阈值是针对视频推流的。如果是音频，容忍度会高一些，因为音频可以用 PLC（丢包隐藏）技术补偿。但视频不行，丢一个关键帧的包，可能导致后面几百毫秒的画面都受影响。
我曾经遇到一个极端案例：客户在弱网环境下推流，丢包率到了 7%。画面基本是黑的，偶尔闪一下。我建议他开启 FEC（前向纠错），丢包率降到 2%，画面虽然模糊但至少能看了。这就是阈值的作用——知道什么时候该用什么策略。
4.4 丢包与码率的关系
丢包率和码率之间有个微妙的关系。很多人以为丢包了降码率就行，其实不一定。
丢包率高的时候，如果强行降低码率，反而可能让问题更严重。为什么？因为低码率意味着每帧的数据量更小，丢一个包损失的比例更大。
举个例子：
- 码率 5Mbps，每帧 50 个包，丢 1 个包损失 2%
- 码率 1Mbps，每帧 10 个包，丢 1 个包损失 10%
所以正确的做法是：先解决丢包问题，再考虑码率调整。丢包率降下来之后，码率调整才有意义。
我的经验法则：
- 丢包率 < 1%：正常推流，码率可以保持
- 丢包率 1%-3%：开启 FEC，码率适当降低 10%-20%
- 丢包率 > 3%：必须启用 ARQ 重传，码率降低 30% 以上
4.5 本章知识体系
下面这张图总结了丢包分析的完整链路：
嗯，这张图把丢包分析的三个核心维度串起来了。从左到右，从原因到分析再到策略，每一步都不能跳。
4.6 避坑指南
最后分享几个我踩过的坑：
- 不要只看平均丢包率：有时候平均丢包率只有 0.5%，但突发丢包集中在某几秒，那几秒的卡顿就足以毁掉整个直播体验。要看峰值丢包率。
- 不要忽略抖动：抖动大的时候，即使不丢包，接收端也可能因为缓冲区溢出而主动丢包。这叫「被动丢包」，比网络丢包更难排查。
- 不要在推流端和接收端用同一个 Wireshark 过滤条件：推流端抓到的包是完整的，接收端抓到的包可能已经丢了。对比两边的序列号，才能准确判断丢包发生在哪一段。
我曾经有一次排查了三天，发现丢包率忽高忽低。后来才发现是推流端的网卡驱动有问题，导致发包时出现微秒级的延迟，被中间路由器判定为异常流量直接丢弃。换了个网卡驱动就好了。所以，丢包不一定是网络问题，也可能是端侧的问题。