网络掉包分析工具mtr

这是12月调试服务器网络情况总结的第三篇文章，网络掉包分析工具mtr

MTR（My traceroute，原名Matt’s traceroute）是一套网络诊断工具，包含了traceroute与ping的功能。 前两篇文章介绍ping 用于测延时大致掉包率和用于测试网络路径工具traceroute工具，这里介绍介绍一下两者的综合体mtr工具。

运行Mtr指定一个IP地址，Mtr会查看运行Mtr的主机和指定目标主机之间的网络节点。在确定目标主机和本地主机间每个网络节点的IP地址后，它向每个网络节点发送一个ICMP ECHO请求，以确定到每个节点的链路的质量。就像这样它会打印到每个节点的运行统计信息。通过这个工具我们可以大概定位到网络出问题的节点，再来具体分析。

1 如何使用

ubuntu安装 ： apt install mtr

mtr + 目标ip

2 举例

还是拿AWS 一个可用区的节点ip作为说明
命令;

mtr 54.76.0.3

54.76.0.3 这个ip是AWS 欧洲西部的一个节点，如果是联通网络是很容掉包的，果然测试结果掉包了.

说明一下图中参数：
第一列（Hostname）：节点 IP 或域名。
第三列（Loss%）：节点丢包率。
第四列（Snt）：已发送的数据包数量。
第六、七、八、九列（Last 、Avg、Best、Wrst ）：分别是到相应节点延迟的最后一次值、平均值、最小值和最大值(ms)。
第八列（StDev）：标准偏差。越大说明相应节点越不稳定。

3 分析

从上图最后一条我们可以看出掉包率为10%，平均网络响应时间在339.9ms

节点 IP 或域名就是数据包经过的网路节点ip地址，我们可以通过工具查询ip归属地得到自己网络请求数据包大概经过的路线。

为什么提示有？？？问号：
是因为该节点防火墙封掉了ICMP的返回信息，所以我们得不到相关的数据包返回数据。

为什么中间某些节点有丢包而后面节点有没有丢包了：
对于MTR报告我们主要关注丢包率和延时。如果在Loss% 列有丢包，说明这一跳可能有问题。但是，ISP会人为的限制ICMP的速率，这也会导致丢包现象。
如何排除限速干扰了？我们只需要观察丢包的下一跳或者后面几跳是否有丢包率为0的情况，如果有，则说明是设备本身的干扰。判定理由：如果中间路由某跳确实丢包，那么后续节点肯定收不到预定的数据包数量了。对于MTR测试结果，一般首先看最后一跳，如果最后一跳有丢包，那么这个分析才是有意义的。

4 参考链接：

https://blog.csdn.net/hankerzero/article/details/67062617
ping文章：https://blog.csdn.net/m0_37263637/article/details/85232092
traceroute文章：https://blog.csdn.net/m0_37263637/article/details/86096686