做者:苏欣php
校队:https://cloud.tencent.com/developer/article/1491610git
经常使用的 ping,tracert,nslookup 通常用来判断主机的网络连通性,其实 Linux 下有一个更好用的网络联通性判断工具,它能够结合ping nslookup tracert 来判断网络的相关特性,这个命令就是 mtr。mtr 全称 my traceroute,是一个把 ping 和 traceroute 合并到一个程序的网络诊断工具。github
traceroute默认使用UDP数据包探测,而mtr默认使用ICMP报文探测,ICMP在某些路由节点的优先级要比其余数据包低,因此测试获得的数据可能低于实际状况。数组
安装方法服务器
1.Windows系统能够直接在https://cdn.ipip.net/17mon/besttrace.exe下载BestTrace工具并安装。也能够在https://github.com/oott123/WinMTR/releases GitHub上下载MTR专用工具,该工具为免安装,下载后能够直接使用。网络
2.Linux能够直接运行命令进行安装。ide
# Debian/Ubuntu 系统 apt install mtr # RedHat/CentOS 系统 yum install mtr
3.Apple客户端能够在App store搜索Best NetTools下载安装工具
4.Android客户端:能够在Google Play上下载TracePing,可是因为国内Google Play没法访问,笔者自行下载下来,能够直接访问 https://dwz.cn/KCdNPH4c 下载TracePing。测试
使用spa
MTR使用很是简单,查看本机到 qq.com 的路由以及链接状况直接运行以下命令:
mtr qq.com
具体输出的参数含义为:
第一列是IP地址
丢包率:Loss
已发送的包数:Snt
最后一个包的延时:Last
平均延时:Avg
最低延时:Best
最差延时:Wrst
方差(稳定性):StDev
参数说明
-r or --report
使用 mtr -r qq.com 来打印报告,若是不使用 -r or --report 参数 mtr 会不断动态运行。使用 report 选项, mtr 会向 qq.com 主机发送 10 个 ICMP 包,而后直接输出结果。一般状况下 mtr 须要几秒钟时间来输出报告。mtr 报告由一系列跳数组成,每一跳意味着数据包经过节点或者路由器来达到目的主机。
通常状况下 mtr 前几跳都是本地 ISP,后几跳属于服务商好比 腾讯数据中心,中间跳数则是中间节点,若是发现前几跳异常,须要联系本地 ISP 服务提供上,相反若是后几跳出现问题,则须要联系服务提供商,中间几跳出现问题,则须要联系运营商进行处理
默认使用 -r 参数来生成报告,只会发送10个数据包,若是想要自定义数据包数量,可使用 -c 参数
-s or --packetsize
使用 -s 来指定ping数据包的大小
mtr -s 100 qq.com
100 bytes 数据包会用来发送,测试,若是设置为负数,则每一次发送的数据包的大小都会是一个随机数。
-c
指定发送数量
mtr -c 100 qq.com
-n
不进行主机解释
使用 -n 选项来让 mtr 只输出 IP,而不对主机 host name 进行解释
mtr -n qq.com
MTR结果分析
当咱们分析 MTR 报告时候,最好找出每一跳的任何问题。除了能够查看两个服务器之间的路径以外,MTR 在它的七列数据中提供了不少有价值的数据统计报告。
Loss% 列展现了数据包在每一跳的丢失率。Snt 列记录的多少个数据包被送出。
使用 –report 参数默认会送出10个数据包。若是使用 –report-cycles=[number-of-packets] 选项,MTR 就会按照 [number-of-packets] 指定的数量发出 ICMP 数据包。
Last, Avg, Best 和 Wrst 列都标识数据包往返的时间,使用的是毫秒( ms )单位表示。Last 表示最后一个数据包所用的时间, Avg 表示评价时间, Best 和 Wrst 表示最小和最大时间。在大多数状况下,平均时间( Avg)列须要咱们特别注意。
最后一列 StDev 提供了数据包在每一个主机的标准误差。若是标准误差越高,说明数据包在这个节点的延时越不相同。标准误差会让您了解到平均延时是不是真的延时时间的中心点,或者测量数据受到某些问题的干扰。
例如,若是标准误差很大,说明数据包的延迟是不肯定的。一些数据包延迟很小(例如:25ms),另外一些数据包延迟很大(例如:350ms)。当10个数据包所有发出后,获得的平均延迟多是正常的,可是平均延迟是不能很好的反应实际状况的。若是标准误差很高,使用最好和最坏的延迟来肯定平均延迟是一个较好的方案。
在大多数状况下,您能够把 MTR 的输出分红三大块。根据配置,第二或第三跳通常都是您的本地 ISP,倒数第二或第三跳通常为您目的主机的ISP。中间的节点是数据包通过的路由器。
当分析 MTR 的输出时,您须要注意两点:loss 和 latency。
若是在任何一跳上看到 loss 的百分比,这就说明这一跳上可能有问题了。固然,不少服务提供商人为限制 ICMP 发送的速率,这也会致使此问题。那么如何才能指定是人为的限制 ICMP 传输 仍是肯定有丢包的现象?此时须要查看下一跳。若是下一跳没有丢包现象,说明上一条是人为限制的。以下示例:
人为限制MTR丢包
在此例中,第4跳发生了丢包现象,可是接下来几条都没任何丢包现象,说明第二跳的丢包是人为限制的。若是在接下来的几条中都有丢包,那就多是第二跳有问题了。请记住,ICMP 包的速率限制和丢失可能会同时发生。
MTR丢包截图
从上面的图中,您能够看从第13跳和第17跳都有 10% 的丢包率,从接下来的几跳都有丢包现象,可是最后15,16跳都是100%的丢包率,咱们能够猜想到100%的丢包率除了网络糟糕的缘由以前还有人为限制 ICMP。因此,当咱们看到不一样的丢包率时,一般要以最后几跳为准。
还有不少时候问题是在数据包返回途中发生的。数据包能够成功的到达目的主机,可是返回过程当中遇到“困难”了。因此,当问题发生后,咱们一般须要收集反方向的 MTR 报告。
此外,互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率,当出现短暂的10%丢包率时候,没必要担忧,应用层的程序会弥补这点损失。
除了能够经过MTR报告查看丢包率,咱们也还能够看到本地到目的之间的时延。由于是不通的位置,延迟一般会随着条数的增长而增长。因此,延迟一般取决于节点之间的物理距离和线路质量。
MTR查看网络延迟
从上面的MTR报告截图中,咱们能够看到从第11跳到12跳的延迟猛增,直接致使了后面的延迟也很大,通常有多是11跳到12跳属于不通地域,物理距离致使时延猛增,也有多是第12条的路由器配置不当,或者是线路拥塞。须要具体问题进行具体的分析。
然而,高延迟并不必定意味着当前路由器有问题。延迟很大的缘由也有多是在返回过程当中引起的。从这份报告的截图看不到返回的路径,返回的路径多是彻底不一样的线路,因此通常须要进行双向MTR测试。
注:ICMP 速率限制也可能会增长延迟,可是通常能够查看最后一条的时间延迟来判断是不是上述状况。
根据MTR结果解决网络问题
MTR 报告显示的路由问题大都是暂时性的。不少问题在24小时内都被解决了。大多数状况下,若是您发现了路由问题,ISP 提供商已经监视到而且正在解决中了。当您经历网络问题后,能够选择提醒您的 ISP 提供商。当联系您的提供商时,须要发送一下 MTR 报告和相关的数据。没有有用的数据,提供商是没有办法去解决问题的。
然而大多数状况下,路由问题是比较少见的。比较常见的是由于物理距离太长,或者上网高峰,致使网络变的很慢。尤为是跨越大西洋和太平洋的时候,网络有时候会变的很慢。这种状况下,建议就近接入客户的节点。