MTR 软件使用简介(请主要学习参考链接，文章为参考链接内容摘要)参考链接：
https://en.wikipedia.org/wiki/MTR_(software) ////MTR维基百科解释
https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr/
////MTR 优秀介绍-用MTR诊断网络问题(原载)
http://www.bitwizard.nl/mtr/ ////MTR软件作者介绍MTR功能
https://www.azure.cn/documentation/articles/aog-virtual-network-troubleshoot-mtr/
////Azure 中使用 MTR 进行网络故障排查中文
http://www.tuicool.com/articles/emINv2v ////"用MTR诊断网络问题"中文翻译一
http://itindex.net/blog/2015/09/01/1441103160000.html ////"用MTR诊断网络问题"中文翻译二
http://winmtr.net/download-winmtr/ ////WinMTR下载地址
https://ss64.com/bash/mtr.html ////MTR Linux环境命令注释
https://docs.oracle.com/cd/E62103_01/html/E62877/mtr-1m.html ////Linux系统 MTR关联命令介绍
https://github.com/traviscross/mtr ////GITHub --MTR(原载-项目地址)
https://github.com/traviscross/mtr/issues ////MTR 问答示例
https://github.com/traviscross/mtr/issues/145 ////解释了
"
一些路由器被配置为每秒产生最多一（*）个这样的错误消息。
如果两个或更多的人正在通过主机运行mtr，你会看到很多丢失的数据包。
一些路由器配置为生成错误消息，但不响应ping。
在过去，我们曾经抱怨有些主机会“显示”，但是报告0％的响应100％包丢失
”
https://github.com/traviscross/mtr/issues/92 ////解释了 "部分发送探测包数量可能不同" 离散发送
MTR 介绍
相信很多人都使用过 ping 、 traceroute（ Windows 中为 tracert ）来诊断网络故障。使用 ping 时，只能测试两个节点之间的连通性，以及响应延迟。使用 traceroute 时，能获得测试所途径的节点信息，但是测试结果不能持续显示每个节点的连接状态，也不能显示每个节点的丢包率。 MTR 弥补了 ping 和 traceroute 功能上的不足，集二者的优点于一身，并且将二者的测试结果整合在一起，让大家能够更直观的查看到网络状态。 MTR 和 ping 、 traceroute 一样，都是通过发送 ICMP 包来测试网络上两个节点之间的网路连接状态。
｛ ICMP Time Exceeded (type 11, code 0) packets coming back from routers, or ICMP Echo Reply (type 0, code 0) packets when the packets have hit their destination host.｝
因为 MTR 报告包括了丰富的信息，新手第一次阅读有点困难。
下面是本地到 google.com 的测试报告：
$ mtr --report google.comHOST: 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 的输出结果表述每个主机的往返时间。
如果您想忽略 rDNS 查找，您可以使用 –no-dns 参数，使用 –no-dns 参数后，
报告结果如下：
% mtr --no-dns --report google.comHOST: 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.5Loss% 列展示了数据包在每一跳的丢失率。
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 报告 数据包的丢失
当分析 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 报告看到丢包率，我们还可以看到本地到目的主机之间的延时。因为不同的物理位置，延迟通常随着跳数的增加而增加。所以，延迟通常取决于节点之间的物理距离和线路质量。
高延迟并不一定意味着当前路由器有问题。延迟很大的原因也有可能是在返回过程中引发的。MTR报告中我们看不到返回的路径，返回的路径可能是完全不同的线路，所以我们一般要进行双向测试了。
ICMP 速率限制也可能会增加延迟，如下：
root@meiriyitie.com:~# mtr --report www.google.comHOST: 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 报告类型
很多网络问题十分麻烦，并且需要上级网络提供商来帮助。然而，这里有很多常见的 MTR 报告所描述的网络问题。如果您正在经历一些网络问题，并且想诊断出原因，可以参考如下示例：
目的主机网络配置不当在下面这个例子中，数据包在目的地出现了 100% 的丢包。乍一看是数据包没有到达，其实未必，很有可能是路由器或主机配置不当。
root@meiriyitie.com:~# mtr --report www.google.comHOST: 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.0MTR 报告数据包没有到达目的主机是因为目的主机没有发送任何应答。这可能是目的主机防火墙的原因，例如： iptables 配置丢掉 ICMP 包所致。
家庭或办公室路由器的原因有时候家庭路由器的原因导致 MTR 报告看起来有点误导。
% mtr --no-dns --report google.comHOST: 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 包永远不能到达目的地，例如：
当没有额外的路由信息时，将会显示问号（???），下面例子也一样：
有时候，一个错误配置的路由器，将会在一个环路中不断发送数据包，如下：
通过报告可以看打第4跳的路由器没有正确配置。如果这种状况发生了，您可以连接当地的网络管理员或ISP解决问题。
ICMP 速率限制ICMP 速率限制可引起数据包的丢失。如果数据包在这一跳有丢失，但是下面几条都正常，我们可以判断是 ICMP 速率限制的原因。如下：
root@meiriyitie.com:~# mtr --report www.google.comHOST: 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.comHOST: 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 设置引起的原因，这个是没关系的。
