丢包率统计分析方法：从抓包到定位问题

视频会议卡顿、游戏突然掉线、下载速度忽高忽低——这些现象背后，常常藏着一个沉默的“捣蛋鬼”：丢包。它不报错，也不弹窗，但就是让网络体验一落千丈。要揪出它，光看“ping通了”远远不够，得靠一套靠谱的丢包率统计分析方法。

丢包率不是“一锤定音”，而是动态快照

很多人习惯用 ping 命令测一次，看到 0% 丢包就放心了。但现实里，丢包常是间歇性的：高峰时段路由器缓存溢出、Wi-Fi 信道被隔壁老王家的智能音箱霸占、某条骨干链路瞬时拥塞……这些都可能只在几秒内发生。所以，单次 ping 的结果就像拍照，而真实丢包更像一段监控录像——得连续采样、分段统计，才能看出趋势。

常用统计方法，按场景选

1. 连续长 ping + 日志汇总
Windows 下可以这样执行：

ping -n 300 -w 1000 www.example.com > ping_log.txt

Linux/macOS 则用：

ping -c 300 -i 0.5 www.example.com | tee ping_log.txt

然后用脚本或 Excel 统计 “Request timed out” 或 “100% packet loss” 出现次数，算出实际丢包率（比如 300 次中失败 6 次 → 2%）。

2. 使用 mtr（My Traceroute）看路径级分布
mtr 同时结合了 traceroute 和 ping 的能力，能显示每一跳的丢包率。运行：

mtr --report-cycles 50 www.example.com

输出里如果第 4 跳丢包率高达 15%，而前后跳都是 0%，那问题大概率出在那个中间节点（比如你家光猫后的二级交换机）。

3. 抓包后深度分析（适合进阶排查）
用 Wireshark 抓一段时间的 TCP 流量，过滤出目标 IP 的数据包：

ip.addr == 192.168.1.100 && tcp

再打开 “Statistics → Flow Graph”，选 TCP Flows，观察有没有大量重传（Retransmission）或重复确认（Dup ACK）。TCP 层频繁重传，往往意味着底层 IP 层已发生不可见丢包——这时丢包率可能远高于 ping 显示的数值。

别只盯着数字，多问一句“在哪丢的”

一次测试发现丢包率 8%，但真正关键的是：这 8% 是发生在你家到光猫之间？还是光猫到运营商机房？又或是跨省骨干网某段？用 mtr 对比白天和凌晨的结果，或者换不同目标域名（如本地 DNS、CDN 节点、海外网站）分别测试，就能大致圈定故障域。曾有个用户抱怨“看视频总卡”，mtr 显示到本地 DNS（114.114.114.114）丢包率 0%，但到腾讯视频 CDN 却达 12%，最后发现是 ISP 的某台缓存服务器异常，而非他家网络问题。

小技巧：用时间窗口平滑噪声

实时丢包率波动大，直接看容易误判。建议按 30 秒为一个窗口统计：每 30 秒发 60 个 ICMP 包，记录该窗口内的丢包数。连续跑 10 分钟，得到 20 个样本点，画成折线图——突起的尖峰往往对应某个具体事件（比如微波炉启动、手机切频、后台自动更新）。