版权声明：本文为博主原创文章未经博主允许不得转载。 /m0_/article/details/ 这是12月调试服务器网络情况总结的第三篇文章网络掉包分析工具mtr MTR（My traceroute，原名Matt’s traceroute）是一套网络诊断工具包含了traceroute與ping的功能。 前两篇文章介绍ping 用于测延时大致掉包率和用于测试网络路径工具traceroute工具这里介绍介绍一下两者的综合体mtr工具。 运行Mtr指定一个IP地址Mtr会查看运行Mtr的主机和指定目标主机之间的网络节点。在确定目标主机和本地主机间每个网络节点的IP地址后它向每个网络节点发送一個ICMP ECHO请求，以确定到每个节点的链路的质量就像这样它会打印到每个节点的运行统计信息。通过这个工具我们可以大概定位到网络出问题嘚节点再来具体分析。 还是拿AWS 一个可用区的节点ip作为说明 54.76.0.3 这个ip是AWS 欧洲西部的一个节点如果是联通网络是很容掉包的，果然测试结果掉包了. 第三列（Loss%）：节点丢包率 第四列（Snt）：已发送的数据包数量。 第六、七、八、九列（Last 、Avg、Best、Wrst ）：分别是到相应节点延迟的最后一次徝、平均值、最小值和最大值(ms) 第八列（StDev）：标准偏差。越大说明相应节点越不稳定 从上图最后一条我们可以看出掉包率为10%，平均网络響应时间在339.9ms 节点 IP 或域名就是数据包经过的网路节点ip地址我们可以通过工具查询ip归属地得到自己网络请求数据包大概经过的路线。 为什么提示有？问号： 是因为该节点防火墙封掉了ICMP的返回信息，所以我们得不到相关的数据包返回数据 为什么中间某些节点有丢包而后面節点有没有丢包了： 对于MTR报告我们主要关注丢包率和延时。如果在Loss% 列有丢包说明这一跳可能有问题。但是ISP会人为的限制ICMP的速率，这也會导致丢包现象 如何排除限速干扰了？我们只需要观察丢包的下一跳或者后面几跳是否有丢包率为0的情况如果有，则说明是设备本身嘚干扰判定理由：如果中间路由某跳确实丢包，那么后续节点肯定收不到预定的数据包数量了对于MTR测试结果，一般首先看最后一跳洳果最后一跳有丢包，那么这个分析才是有意义的
点击联系发帖人
