晚上十一点，网络运维群里突然炸了。丢包有人甩了张监控截图，测试某台服务器的工具延迟曲线像心电图一样乱跳。第一反应是网络网络抖动，第二反应是丢包——丢包了。但丢了多少？测试在哪一跳丢的？没人说得清。这时候你需要的工具不是猜，是网络工具。

ping 是丢包最顺手的。一条命令下去，测试看回包率。工具比如 ping -c 100 10.0.1.5，网络跑一百个包，丢包最后给你一行统计。测试丢个百分之几，心里就有数了。但它太粗，只知道终点丢没丢，不知道路上哪个节点干的。而且 ICMP 包经常被防火墙区别对待，路由器控制面丢几个 ICMP 不代表转发面也丢。所以 ping 的结果只能当参考，不能当判决。

真要定位，得上 traceroute 或者它的现代替代品 mtr。mtr 把 ping 和 traceroute 揉在一起，持续探测每一跳，实时刷新丢包率和延迟。我习惯用 mtr -r -c 100 目标IP 跑报告模式，一百个包一轮，看每一跳的 Loss% 列。如果从某一跳开始丢包率突然从 0 跳到 20%，而后面几跳也维持这个水平，那问题大概率出在那台路由器或者它前面的链路。有个坑要注意：中间跳丢包但终点不丢，可能是路由器限速 ICMP 回复，不代表转发有问题。判断标准是看丢包是否持续到终点。

还有一种情况，丢包不是均匀的，是阵发性的。比如每十几秒丢一串，然后又恢复正常。这种用 ping 和 mtr 都容易漏掉，因为它们的统计窗口太粗。这时候 tcpping 或者 hping3 更合适。hping3 能构造自定义包，指定间隔、包大小、TCP 标志位。hping3 -S -p 80 -i u100000 目标IP 每 100 毫秒发一个 SYN 包，模拟真实 TCP 握手。如果对方是 Web 服务器，这比 ICMP 更接近实际业务流量。有些云厂商的虚拟网络对 ICMP 和 TCP 的丢包策略不一样，用 hping3 能看出差别。

应用层丢包更隐蔽。TCP 有重传机制，丢一两个包用户基本无感，但重传本身会拖慢速度。用 tcpdump 抓包，然后看 Wireshark 里的 Expert Information，它会标出重传、重复 ACK、零窗口。有一次我帮人查一个“网页打开慢”的问题，ping 和 mtr 都正常，最后 tcpdump 抓到大量 TCP Retransmission，原因是中间一台负载均衡器会话表满了，随机丢新连接。这种丢包 ping 根本测不出来。

还有一类工具走的是主动探测路线，比如 SmokePing 和 Zabbix 的 fping 模块。SmokePing 画出的延迟和丢包图特别直观，适合长期观察。我见过一个案例，某条专线每天下午两点准时丢包，SmokePing 的图上一清二楚，后来发现是隔壁部门在跑定时备份，把带宽占满了。没有历史图表，这种规律根本抓不住。

选工具看场景。快速确认——ping。定位路径——mtr。模拟业务——hping3。抓细节——tcpdump + Wireshark。长期监控——SmokePing。别指望一个工具解决所有问题。网络丢包这事，跟破案一样，得交叉验证。单看一个指标就下结论，多半会跑偏。

最后说个真事。有次客户咬定我们机房丢包，我让他同时从三个地方 ping 同一个目标，结果只有他那边丢。问题出在他本地交换机的某个端口，双工模式协商错了。工具不会说谎，但用工具的人得知道它在测什么。