4. 丢包问题：丢包的原因、丢包对视频流的影响、如何检测丢包

说到推流卡顿，丢包绝对是头号嫌疑人。我做了这么多年流媒体，遇到过的卡顿案例里，十有八九都能追溯到丢包。说白了，视频数据在网络里就像快递包裹，丢了一个，收件人就拼不完整了。

4.1 丢包的原因

丢包不是随机发生的。它背后一定有原因。我个人习惯把丢包原因分成三类：网络链路问题、设备性能瓶颈、以及协议本身的限制。

4.1.1 网络链路问题

这是最常见的。你想想看，数据包从你的编码器出发，要经过交换机、路由器、光猫、运营商骨干网，最后到达CDN节点。中间任何一段出了问题，都会丢包。

• 带宽不足：推流码率超过了上行带宽上限。比如你家宽带只有10Mbps上行，你非要推8Mbps的流，高峰期一拥塞，路由器就开始丢包了。
• 物理线路质量差：网线接触不良、光衰过大、Wi-Fi信号干扰。我在项目中遇到过，用户换了根六类网线，丢包率直接从5%降到了0.1%。
• 运营商限速或QoS策略：有些运营商会优先保障网页浏览，限制P2P和视频上传的带宽。
• 跨国/跨运营商传输：数据包要经过多个自治系统，路由跳数多，丢包概率成倍增加。

4.1.2 设备性能瓶颈

嗯，这里要注意。有时候不是网络不行，是设备扛不住了。

• 路由器/交换机缓存溢出：当瞬间流量超过设备转发能力时，数据包会被强制丢弃。
• 编码器CPU过载：软件编码器如果CPU跑满，来不及处理网络栈的发送请求，也会导致丢包。
• 网卡驱动或硬件故障：我曾经遇到过一块千兆网卡，跑满速就丢包，降速到百兆反而正常。最后发现是网卡芯片虚焊。

4.1.3 协议层面的丢包

这个很多人会忽略。你用的传输协议本身就会导致丢包。

• UDP丢包：RTMP、SRT、QUIC底层都用UDP。UDP本身不保证可靠传输，网络拥塞时直接丢弃。
• TCP重传超时：TCP虽然可靠，但如果重传超时时间设置不合理，应用层感知到的就是数据迟迟不到，效果跟丢包一样。
• FEC（前向纠错）恢复失败：有些协议会用冗余包来对抗丢包，但如果丢包率超过了FEC的纠错能力，照样恢复不出来。

4.2 丢包对视频流的影响

丢包到底会造成什么后果？我直接说结论：丢包率不同，表现完全不同。下面这张表是我在实际项目中总结的对应关系。

丢包率范围	用户感知	技术表现
0% - 0.1%	几乎无感	偶发一帧花屏，人眼不易察觉
0.1% - 1%	偶尔卡顿	画面出现马赛克、轻微跳帧
1% - 5%	明显卡顿	频繁花屏、声音断续、播放器缓冲
5% - 10%	几乎不可看	画面冻结、音画不同步、频繁重连
> 10%	完全无法播放	连接断开、推流失败

为什么会这样？我给你拆解一下。

4.2.1 视频层面的影响

视频编码用的是帧间预测。I帧是关键帧，P帧和B帧依赖前面的帧来解码。如果丢了一个P帧里的关键数据，后面一连串帧都解不出来。这就是为什么有时候丢包率只有1%，但画面卡顿却持续好几秒。

• 花屏/马赛克：丢失的数据块在解码时无法重建，表现为画面上的彩色方块。
• 跳帧：播放器检测到丢包后，会主动丢弃后续依赖帧，导致画面跳跃。
• 音画不同步：音频包和视频包丢包率不一致，时间戳对不上，嘴型就对不上了。

4.2.2 协议层面的连锁反应

丢包还会引发协议层面的连锁反应，这个很多人没意识到。

• TCP拥塞控制：TCP检测到丢包后，会主动降低发送窗口，导致推流码率骤降。你明明推的是8Mbps，丢包后可能被降到2Mbps，画质瞬间变差。
• 重传风暴：丢包率高了，重传包占用了大量带宽，进一步加剧拥塞，形成恶性循环。
• RTT增加：丢包导致重传，重传导致延迟增加。我见过一个案例，丢包率3%，RTT从20ms飙升到800ms，直播延迟直接爆炸。

4.3 如何检测丢包

检测丢包是排查的第一步。我常用的方法有四种，从简单到深入，你可以根据场景选择。

4.3.1 使用 ping 命令

这是最基础的方法。ping命令会发送ICMP包，通过返回结果判断丢包。

# 持续ping目标服务器，统计丢包率
ping -c 100 -i 0.1 rtmp.example.com

# Windows下用 -t 持续ping
ping -t rtmp.example.com

但要注意，ICMP丢包不代表UDP/TCP也丢包。有些路由器会优先丢弃ICMP包。所以ping只能作为参考，不能完全依赖。

4.3.2 使用 iperf 测试带宽和丢包

我个人更推荐用iperf。它能模拟真实的UDP或TCP流量，测试结果更接近实际推流场景。

# 服务端
iperf -s -u -p 5001

# 客户端，模拟推流码率
iperf -c server_ip -u -p 5001 -b 5M -t 60 -i 1

输出结果里会明确显示丢包率。我习惯把码率从1M逐步提升到10M，观察丢包率的变化曲线，找到带宽瓶颈点。

4.3.3 抓包分析

这是最精确的方法。用Wireshark或tcpdump抓取推流数据包，然后分析重传和丢包。

# 抓取RTMP推流数据
tcpdump -i eth0 -s 0 -w push_stream.pcap host rtmp.example.com and port 1935

# 在Wireshark中分析
# 使用分析菜单 -> 专家信息 -> 查看重传和丢包统计

抓包能告诉你丢包的具体时间点、丢的是哪个序列号的数据包、以及是否有重传。我曾经靠抓包发现，某个CDN节点在每小时的整点会丢一批包，最后定位到是定时任务触发了路由表更新。

4.3.4 推流端日志和SDK统计

很多推流SDK都内置了丢包统计。比如OBS、FFmpeg、以及各厂商的推流库。

# FFmpeg推流时输出统计信息
ffmpeg -i input.mp4 -c:v libx264 -f flv rtmp://example.com/live/stream \
  -stats_period 1 -loglevel info 2>&1 | grep "lost"

在OBS里，你可以打开高级模式，在状态栏看到实时丢包率。我建议在推流过程中持续观察，如果丢包率超过0.5%，就要开始排查了。

4.4 丢包排查知识体系

下面这张图是我自己整理的丢包排查知识体系。你可以把它当作排查时的路线图。

这张图把丢包问题的三个维度串起来了。你从原因入手，找到根因；再评估影响，判断严重程度；最后用检测方法验证。按这个流程走，大部分丢包问题都能在半小时内定位。