MTR 是一款强大的网络诊断工具，网络管理员使用 MTR 能够诊断和隔离网络问题，而且为上游 ISP 提供有用的网络状态报告。node
MTR 是传统 traceroute 命令的进化版，而且能够提供强大的数据样本，由于他集合了 traceroute 和 ping 这两个命令的精华。本文带您深刻了解 MTR ，从数据如何生成，到若是正确理解报告样本并得出相应的结论。linux
关于网络诊断技术的基本理论请参考 network diagnostics .若是您怀疑您的 Linux 系统有其余问题，请参考system diagnostics 。最后，咱们假定您已经掌握了 getting started guide (入门指南) 。ios
网络诊断工具 例如 ping traceroute mtr 都使用的 “ICMP” 包来测试 Internet 两点之间的网络链接情况。当用户使用 ping 命令 ping 网络上的主机后， ICMP 包将会发送到目的主机，而后在目的主机返回响应。这样，就能够得知本机到目的主机 ICMP 包传输所使用的往返时间。数组
相对于其余命令仅仅收集传输路径或响应时间，MTR 工具会收集更多的信息，好比 链接状态，链接可用性，以及传输路径中主机的响应性。因为这些额外的信息，咱们建议您尽量完整的展示 Internet 两个主机之间的网络链接信息。接下来咱们讲述如何安装 MTR 软件，以及如何看懂这款软件的输出结果。安全
在 Debian 和 Ubuntu 系统中，使用以下命令更新系统，而后安装 MTR：服务器
apt-get update apt-get upgrade apt-get install mtr-tiny
在 CentOS 和 Fedora 系统中，使用以下命令更新系统，并安装 MTR：网络
yum update yum install mtr
在 Arch Linux 系统中，按照以下命令更新系统并安装 MTR：ide
pacman -Sy pacman -S mtr
若是您的本机使用的是 Linux 系统，而且想用 MTR 测试网络情况，请按照如上教程安装。工具
若是您的本机使用的 Mac OS X 系统，可使用 Homebre 或 MacPorts 来安装 MTR。使用 Homebrew 安装 MTR：
brew install mtr
使用 MacPorts 安装 MTR：
port install mtr
若是您的本机使用的是 Windows 系统，您可使用 “WinMTR”。能够从这里下载：WinMTR .
由于 MTR 提供两个主机之间的网络路径图，您能够把它想象成一款定向工具。另外，由于地址位置或上游ISP路由器的缘由，路径有时候可能会有很大的不一样。因此咱们建议您尽量多的收集 MTR 的报告信息。
若是您遇到网络方面的问题， Linode 的技术支持常常建议您收集双向的 MTR 报告（从 Linode 出发和到 Linode 的往返路径）。这是由于有时候网络情况从一个方向不会出现错误，可是从另外一个方向会出现丢包现象。当出现网络问题时候，双向 MTR 报告是十分有用的。
在本文中，运行 mtr 命令的主机称为 源主机，被查询的主机称为 目的主机。
当在Linux 或 Mac OS X 系统中安装 MTR 后，您可使用以下命令来产生 MTR 报告：
mtr -rw [destination_host]
例如，咱们须要测试到 example.com 的路由信息和网络链接质量，在源主机上运行以下命令：
mtr -rw example.com
若是咱们遇到网络问题，须要联系 Linode 的技术支持，Linode 须要咱们提供双向的 MTR 报告。第一份是从您的本机到 Linode VPS 的 MTR 报告，命令以下：
mtr -rw 87.65.43.21
使用您的Linode VPS 的IP地址替换 87.65.43.21 。
而后咱们须要搜集从您的Linode VPS 返回到您的本机的 MTR 报告，命令以下：
mtr -rw 12.34.56.78
请使用您的本地公网IP地址替换 12.34.56.78 。若是您不肯定您的本地公网IP地址，您可使用相关的第三方服务，若是 WhatIsMyIP.com。（译者著：国内可使用 ip.c、ip138.com 、ipip.net 等第三方服务）
注
咱们使用 rw 参数是为了方便让 Linode 的技术支持看到更多的网络信息。
r 产生报告信息（–report 的缩写）
w 报告中带有 hostname 信息，Linode 技术支持能够看到每一跳的完整 hostname （–report-wide 的缩写）
首先，Windows 下的 MTR 有 GUI 的，运行 WinMTR，输入目的地址，而后选择开始便可，您就会看到输出内容。
另外，您还须要使用 Linux 版本的 MTR 来产生从 Linode 到您本地的返回线路网络情况。（由于目前 Linode 仅有Linux 的VPS，哈哈）
由于 MTR 报告包括了丰富的信息，新手第一次阅读有点困难。下面是我本地到 google.com 的测试报告：
$ mtr --report google.com HOST: example Loss% Snt Last Avg Best Wrst StDev 1. inner-cake 0.0% 10 2.8 2.1 1.9 2.8 0.3 2. outer-cake 0.0% 10 3.2 2.6 2.4 3.2 0.3 3. 68.85.118.13 0.0% 10 9.8 12.2 8.7 18.2 3.0 4. po-20-ar01.absecon.nj.panjde 0.0% 10 10.2 10.4 8.9 14.2 1.6 5. be-30-crs01.audubon.nj.panjd 0.0% 10 10.8 12.2 10.1 16.6 1.7 6. pos-0-12-0-0-ar01.plainfield 0.0% 10 13.4 14.6 12.6 21.6 2.6 7. pos-0-6-0-0-cr01.newyork.ny. 0.0% 10 15.2 15.3 13.9 18.2 1.3 8. pos-0-4-0-0-pe01.111eighthav 0.0% 10 16.5 16.2 14.5 19.3 1.3 9. as15169-3.111eighthave.ny.ib 0.0% 10 16.0 17.1 14.2 27.7 3.9 10. 72.14.238.232 0.0% 10 19.1 22.0 13.9 43.3 11.1 11. 209.85.241.148 0.0% 10 15.1 16.2 14.8 20.2 1.6 12. lga15s02-in-f104.1e100.net 0.0% 10 15.6 16.9 15.2 20.6 1.7
使用 mtr –report google.com 命令来输出这篇报告。使用 report 选项能够给 google.com 主机发送10个 ICMP 包，而后输出报告。若是咱们不使用 –report 参数， mtr 会不断的动态运行。在动态模式下， mtr 的输出结果表述每一个主机的往返时间。大多数状况下，使用 –report 参数就能够提供足够的数据了。
在命令下面，就是 MTR 产生的输出报告 。在一般状况下， MTR须要几秒钟的时间来输出报告，可是偶尔可能须要更长的时间。MTR 报告是由一系列跳数组成的（在上述例子中是12跳）。“跳”意味着节点，或路由器，数据包经过它们才能到达目的主机。在上面例子中，数据包通过本地网络的“内层”和“外层”，而后到达 “68.85.118.13”，而后再到一系列的域名主机。主机的域名是经过反向 DNS 查找肯定的。若是您想忽略 rDNS 查找，您可使用 –no-dns 参数，使用 –no-dns 参数后，报告结果以下：
% mtr --no-dns --report google.com HOST: deleuze Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2 2. 68.85.118.13 0.0% 10 8.6 11.0 8.4 17.8 3.0 3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2 4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4 5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3 6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9 7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9 8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6 9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9 10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2 11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5
当咱们研究 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，目的地是您的 Linode VPS，通常前三跳属于您的本地 ISP，后三跳属于 Linode 数据中心这边的。中间的条数是属于中间节点的。当您在本地运行 MTR，若是您在前几跳发现异常，请联系您本地的 ISP 服务提供商。相反，若是您在接近目的地的几跳发现问题，请联系您目的地的服务器提供商（例如：Linode）。若是您的问题出如今中间几跳，很不幸，两边的服务提供商的能力有限，可能不能彻底为您解决问题喽。
当分析 MTR 的输出时，您须要注意两点： loss 和 latency。首先，让咱们讨论一下 loss。若是您在任何一跳上看到 loss 的百分比，这就说明这一跳上可能有问题了。固然，不少服务提供商人为限制 ICMP 发送的速率，这也会致使此问题。那么如何才能指定是人为的限制 ICMP 传输 仍是肯定有丢包的现象？咱们须要查看下一跳。若是下一跳没有丢包现象，说明上一条是人为限制的。以下示例：
root@meiriyitie.com:~# mtr –report www.google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 50.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
在此例中，第二跳发生了丢包现象，可是接下来几条都没任何丢包现象，说明第二跳的丢包是人为限制的。若是在接下来的几条中都有丢包，那就多是第二跳有问题了。请记住，ICMP 包的速率限制和丢失可能会同时发生。若是发生包的丢失状况，咱们要用最低百分比来衡量时间状况。为何这么说呢？请看以下示例：
root@meiriyitie.com:~# mtr –report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2
在这个例子中，您能够看打 第3跳和第4跳都有 60% 的丢包率，从接下来的几跳都有丢包现象，因此不像是人为限制 ICMP 速率的缘由。可是最后几跳都是40%的丢包率，咱们能够猜想到60%的丢包率除了网络糟糕的缘由以前还有人为限制 ICMP。因此，当咱们看到不一样的丢包率时，一般要以最后几跳为准。
还有不少时候问题是在数据包返回途中发生的。数据包能够成功的到达目的主机，可是返回过程当中遇到“困难”了。因此，当问题发生后，咱们一般须要收集反方向的 MTR 报告。
此外，互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率，当出现短暂的10%丢包率时候，没必要担忧，应用层的程序会弥补这点损失。
除了能够经过 MTR 报告看到丢包率，咱们还能够看到本地到目的主机之间的延时。由于不一样的物理位置，延迟一般随着跳数的增长而增长。因此，延迟一般取决于节点之间的物理距离和线路质量。
例如，在一样的传输距离下，dial-up链接比cable modem链接有更大的延迟。以下示例中显示 MTR 报告：
root@meiriyitie.com:~# mtr –report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 388.0 360.4 342.1 396.7 0.2
5. 72.14.233.56 0.0% 10 390.6 360.4 342.1 396.7 0.2
6. 209.85.254.247 0.0% 10 391.6 360.4 342.1 396.7 0.4
7. 64.233.174.46 0.0% 10 391.8 360.4 342.1 396.7 2.1
8. gw-in-f147.1e100.net 0.0% 10 392.0 360.4 342.1 396.7 1.2
在这份报告中，从第三跳到第四跳的延迟猛增，直接致使了后面的延迟也很大。这多是由于第四跳的路由器配置不当，或者线路很拥堵的缘由。
然而，高延迟并不必定意味着当前路由器有问题。这份报告虽然看到第四跳有点问题，可是数据仍然能够正常达到目的主机而且返回给主机。延迟很大的缘由也有多是在返回过程当中引起的。我这份报告咱们看不到返回的路径，返回的路径多是彻底不一样的线路，因此咱们通常要进行双向测试了。
ICMP 速率限制也可能会增长延迟，以下：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 0.0% 10 254.2 250.3 230.1 263.4 2.9 6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
乍一看，第4跳和第5跳直接的延迟很大。可是第5跳以后，延迟又恢复正常了。最后的延迟差很少为 40ms。像这种状况，是不影响实际状况的。由于可能仅仅是第5跳设备限制了 ICMP 传输速率的缘由。因此咱们通常要用最后一跳的实际延迟为准。
不少网络问题十分麻烦，而且须要上级网络提供商来帮助。然而，这里有不少常见的 MTR 报告所描述的网络问题。若是您正在经历一些网络问题，而且想诊断出缘由，能够参考以下示例：
在下面这个例子中，数据包在目的地出现了 100% 的丢包。乍一看是数据包没有到达，其实未必，颇有多是路由器或主机配置不当。
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9 6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 100.0 10 0.0 0.0 0.0 0.0 0.0
MTR 报告数据包没有到达目的主机是由于目的主机没有发送任何应答。这多是目的主机防火墙的缘由，例如： iptables 配置丢掉 ICMP 包所致。
有时候家庭路由器的缘由致使 MTR 报告看起来有点误导。
% mtr --no-dns --report google.com HOST: deleuze Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2 2. ??? 100.0 10 8.6 11.0 8.4 17.8 3.0 3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2 4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4 5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3 6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9 7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9 8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6 9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9 10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2 11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5
不要为 100% 的丢包率所吓到，这并不代表这里有问题。你能够看打在接下来几跳是没有任何丢包的。
有时候您的运营商的路由器配置缘由，致使 ICMP 包永远不能到达目的地，例如：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 10. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
当没有额外的路由信息时，将会显示问号（???），下面例子也同样：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 172.16.29.45 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 10. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
有时候，一个错误配置的路由器，将会在一个环路中不断发送数据包，以下：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 9. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 10. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 11. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 12. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 13. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 14. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
经过报告能够看打第4跳的路由器没有正确配置。若是这种情况发生了，您能够链接当地的网络管理员或ISP解决问题。
ICMP 速率限制可引发数据包的丢失。若是数据包在这一跳有丢失，可是下面几条都正常，咱们能够判断是 ICMP 速率限制的缘由。以下：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.9 6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
这种情况是不要紧的。ICMP 速率限制是一种常见的手段，这样能够减小网络数据的负载，让更重要的流量先经过。
在不少种状况下会发生超时现象。例如：不少路由器可能会直接丢弃 ICMP 包，这时就会致使超时（???）。
另外，也有可能在数据返回的路上出现了问题。
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. ??? 0.0% 10 7.2 8.3 7.1 16.4 2.9 6. ??? 0.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
超时不必定是数据包被丢失。如上例，数据包仍是安全的到达目的地而且返回。中间节点的超时多是路由器配置丢弃 ICMP 包，或者 QoS 设置引发的缘由，这个是不要紧的。
MTR 报告显示的路由问题大都是暂时性的。不少问题在24小时内都被解决了。大多数状况下，若是您发现了路由问题，ISP 提供商已经监视到而且正在解决中了。当您经历网络问题后，能够选择提醒您的 ISP 提供商。当联系您的提供商时，须要发送一下 MTR 报告和相关的数据。没有有用的数据，提供商是没有办法去解决问题的。
然而大多数状况下，路由问题是比较少见的。比较常见的是由于物理距离太长，或者上网高峰，致使网络变的很慢。尤为是跨越大西洋和太平洋的时候，网络有时候会变的很慢。这种状况下，建议您选择 VPS 的物理距离尽可能接近您的目标客户。
若是您遇到网络链接问题，而且不能解读 MTR 报告，您能够打开一个支持工单提交问题，Linode 工做人员会帮您分析报告。
您能够参考以下链接了解更多与 MTR 有关的知识。
Understanding the Traceroute Command – Cisco Systems
Wikipedia article on traceroute
译者注：这篇文章实在是太长了，敲的我手都麻了。