常用的ping、tracert、nslookup一般用于判断主机的网络连通性。其实linux下有更好的网络连通性判断工具。可以结合pingnslookuptracert来判断网络的相关特征。这个命令就是mtr。mtr的全称是mytraceroute，是一款将ping和traceroute合二为一的网络诊断工具。traceroute默认使用UDP包检测，而mtr默认使用ICMP包检测。ICMP在某些路由节点中的优先级低于其他数据包，因此测试得到的数据可能低于实际情况。安装方法1.Windows系统可以直接在https://cdn.ipip.net/17mon/besttrace.exe下载安装BestTrace工具。也可以在https://github.com/oott123/WinMTR/releasesGitHub上下载MTR专用工具。本工具免安装，下载后可直接使用。2、linux可以直接运行命令安装。#Debian/Ubuntu系统aptinstallmtr#RedHat/CentOS系统yuminstallmtr3.苹果客户端可以在Appstore搜索BestNetTools下载安装4.安卓客户端：可以在GooglePlay上下载TracePing，但是因为国内的GooglePlay无法访问，我自己下载好了之后，可以直接访问https://dwz.cn/KCdNPH4c下载TracePing。使用MTR非常简单。查看本机到qq.com的路由和连接状态，直接运行如下命令：mtrqq.com图片MTRqq.com测试接口具体输出参数含义为：第一列为IP地址包lossrate:Loss发送包数:Snt最后一个包的延迟:Last平均延迟:Avg最小延迟:Best最坏延迟:Wrst方差(稳定性):StDev参数说明-ror--report使用mtr-rqq.com打印报告，如果不使用-r或--report参数，mtr将继续动态运行。使用report选项，mtr会向qq.com主机发送10个ICMP包，然后直接输出结果。通常mtr需要几秒钟来输出报告。mtr报告由一系列的跳数组成，每一跳意味着数据包经过节点或路由器到达目的主机。一般情况下，mtr的前几跳是本地ISP，后几跳是腾讯数据中心等服务商，中间几跳是中间节点。如果发现前几跳异常，需要联系当地的ISP服务商。如果跳转有问题，需要联系服务商。如果中跳出现问题，需要联系运营商处理。默认使用-r参数生成报告，只会发送10个数据包。如果要自定义数据包的个数，可以使用-c参数-s或者--packetsize使用-s来指定ping包的大小mtr-s100qq.com100字节的包会被用来发送，测试，如果设置为负数，每次发送的数据包大小将是一个随机数。-c指定发送数量mtr-c100qq.com-n不解释主机使用-n选项让mtr只输出IP而不解释主机名mtr-nqq.comMTR结果分析当我们分析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。网络数据包丢失如果您在任何一跳上看到丢失百分比，则表示此一跳可能存在问题。当然，很多服务商人为限制ICMP发送的速率，也会造成这个问题。那么如何指定是人为限制ICMP传输还是判断是否有丢包呢？此时，您需要检查下一跳。如果下一跳没有丢包，说明前面的表项被人为限制了。下例：人为限制MTR丢包本例中第四跳出现丢包，但后面几行没有丢包，说明人为限制了第二跳的丢包。如果后面几行有丢包，那可能是第二跳的问题。请记住，ICMP数据包的速率限制和丢弃可能同时发生。MTR丢包截图从上图可以看到第13、17跳有10%的丢包率，后面几跳也有丢包，但是最后15、16跳都是100%丢包率，我们可以猜测100%的丢包率除了网络不好的原因外，还有ICMP人为限制。所以，当我们看到不同的丢包率时，通常取决于最后几跳。也有很多时候问题出现在回包的路上。数据包可以顺利到达目的主机，但在返回过程中遇到“困难”。所以，当出现问题时，我们通常需要反方向收集MTR报告。此外，互联网设施的维护或网络的短期拥堵也可能导致短期的丢包率。当出现短期10%的丢包率时，不用担心，应用层程序会弥补这个损失。网络延迟除了通过MTR报告查看丢包率外，我们还可以看到本地和目的地之间的延迟。由于无法到达位置，延迟通常会随着柱数的增加而增加。因此，延迟通常取决于节点之间的物理距离和线路质量。MTR查看网络延迟从上面MTR报告的截图我们可以看到，从第11跳到第12跳的延迟急剧增加，这直接导致了后面的大延迟。一般情况下，第11～12跳有可能属于不可达区域，物理距离导致延迟急剧增加，也有可能是第12条路由器配置不当，或者线路拥堵。需要具体问题具体分析。但是，高延迟并不一定意味着您当前的路由器有问题。延迟较大的原因也可能是在退货过程中造成的。从这个报告的截图看不到返回路径，返回路径可能是完全不同的线路，所以一般需要双向MTR测试。注意：ICMPratelimiting也可能会增加延迟，但是一般可以查看最后一项的时间延迟来判断是否是这种情况。根据MTR结果排除网络问题MTR报告显示的路由问题大多是暂时的。许多问题在24小时内得到解决。在大多数情况下，如果您发现路由问题，您的ISP供应商已经监控并正在处理它。当您遇到网络问题时，您可以选择提醒您的ISP提供商。联系您的提供商时，需要发送MTR报告和相关数据。没有有用的数据，提供者就没有办法解决问题。然而，在大多数情况下，路由问题相对较少。更常见的是网络变得很慢，因为物理距离太远，或者上网高峰期。特别是在穿越大西洋和太平洋时，网络有时会变得非常慢。在这种情况下，建议就近连接到客户的节点。
