MTR（My Traceroute）是一个网络诊断工具，它结合了ping和traceroute的功能。通过发送一系列的网络数据包并显示每个跳点的延迟、丢包情况等信息，帮助用户分析网络连接的质量。
以下是MTR工具的使用示例：
假设你想测试到目标服务器的网络连接状况。
-
打开终端窗口或命令提示符窗口。
-
输入以下命令，并在后面加上目标服务器的IP地址或域名：
mtr <目标服务器IP地址或域名>
-
按下回车键开始运行MTR。
-
MTR会不断发送网络数据包并显示每个跳点的延迟、丢包率等信息。通常情况下，MTR会持续运行，直到你手动停止它。
-
查看MTR的输出结果。你将看到每个跳点的IP地址、主机名、平均延迟、丢包率等信息。你可以根据这些信息判断网络连接是否稳定，找出可能存在的问题。
-
如果需要保存MTR的输出结果，可以将结果导出为文本文件。在Windows命令提示符窗口中，你可以使用以下命令将MTR的结果保存到文件中：
mtr <目标服务器IP地址或域名> > mtr_output.txt
这将把MTR的结果保存到名为mtr_output.txt的文件中。
通过使用MTR工具，你可以快速定位网络连接问题，并与网络管理员或服务提供商共享有关网络延迟、丢包率等方面的信息，以便进行故障排除和改善网络连接质量。
命令参数
用法：
mtr [选项] 主机名
-F, --filename 文件 从文件中读取主机名
-4 仅使用IPv4
-6 仅使用IPv6
-u, --udp 使用UDP而不是ICMP回显
-T, --tcp 使用TCP而不是ICMP回显
-I, --interface 名称 使用指定的网络接口
-a, --address 地址 将出站套接字绑定到地址
-f, --first-ttl 数字 设置起始TTL值
-m, --max-ttl 数字 最大跳数
-U, --max-unknown 数字 最大未知主机数
-P, --port 端口号 TCP、SCTP或UDP的目标端口号
-L, --localport 本地端口号 UDP的源端口号
-s, --psize 包大小 设置用于探测的数据包大小
-B, --bitpattern 数字 设置用于负载的位模式
-i, --interval 秒数 ICMP回显请求间隔
-G, --gracetime 秒数 等待响应的秒数
-Q, --tos 数字 IP头部的服务类型字段
-e, --mpls 显示来自ICMP扩展的信息
-Z, --timeout 秒数 保持探测套接字打开的秒数
-r, --report 使用报告模式输出
-w, --report-wide 使用宽格式报告输出
-c, --report-cycles 数字 设置发送的ping次数
-j, --json 输出JSON格式
-x, --xml 输出XML格式
-C, --csv 输出逗号分隔值格式
-l, --raw 输出原始格式
-p, --split 分割输出
-t, --curses 使用curses终端界面
--displaymode 模式 选择初始显示模式
-n, --no-dns 不解析主机名
-b, --show-ips 显示IP地址和主机名
-o, --order 字段 选择输出字段
-y, --ipinfo 数字 在输出中选择IP信息
-z, --aslookup 显示AS号码
-h, --help 显示此帮助并退出
-v, --version 输出版本信息并退出
使用示例
mtr -6 2409:8a00:164:17f0:a00:27ff:fe4b:890f -c 10 -r
发送10个数据包到指定的IPv6地址，使用报告模式输出。
Start: 2023-10-07T11:32:22+0800
HOST: MacBook-Pro-2.local Loss% Snt Last Avg Best Wrst StDev
1.|-- 2400:da00:c001:ff11::1 0.0% 10 4.9 34.6 4.8 208.7 62.8
2.|-- 2400:da00:c001:d1d2::1 0.0% 10 16.9 20.3 5.2 106.1 30.8
3.|-- 2400:da00:c0bc:efd1::701 0.0% 10 5.9 7.2 4.1 20.4 4.9
4.|-- 2400:da00:c0bc:c0ef::701 0.0% 10 144.3 84.2 6.4 169.9 73.9
5.|-- 2400:da00:c0bc:1ec0::1 0.0% 10 74.3 92.3 5.0 257.5 70.4
6.|-- 2400:da00:c0bc:1e1e::11:1 0.0% 10 5.8 41.4 3.8 194.4 57.1
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- 2409:8a00:164:17f0:a00:27 0.0% 10 33.8 57.1 12.4 277.2 88.2
- Loss%到达此节点的数据包丢包率，显示的每个对应IP的丢包率。
- Snt显示设置发送数据包的数量，默认值是10 通过参数 -c来自定义数量。
- Last显示的最近一次的返回时延。
- Avg平均值这个应该是发送ping包的平均时延。
- Best最好或者说时延最低的。
- Wrst最差或者说时延最大的。
- StDev是标准偏差，该值越大说明相应节点越不稳定。
链路测试结果说明
Avg（平均值）和 StDev（标准偏差）
由于链路抖动或其他因素的影响，节点的Best和Wrst值可能相差很大。而Avg（平均值）统计了自链路测试以来所有探测的平均值，所以能更好的反应出相应节点的网络质量。而StDev（标准偏差值）越高，则说明数据包在相应节点的延时值越不相同（越离散）。所以标准偏差值可用于协助判断Avg是否真实反应了相应节点的网络质量。例如，如果标准偏差很大，说明数据包的延迟是不确定的。可能某些数据包延迟很小（例如25 ms），而另一些延迟却很大（例如350 ms），但最终得到的平均延迟反而可能是正常的。所以此时Avg并不能很好的反应出实际的网络质量情况。
分析标准如下：
如果StDev值很高，则同步观察相应节点的Best和Wrst，来判断相应节点是否存在异常。
如果StDev值不高，则通过Avg来判断相应节点是否存在异常。
Loss%（丢包率）
任一节点的Loss%（丢包率）如果不为零，则说明这一跳网络可能存在问题。导致相应节点丢包的原因通常有如下两种：
-
运营商基于安全或性能需求，人为限制了节点的ICMP发送速率，导致丢包。
-
节点确实存在异常，导致丢包。
可以结合异常节点及其后续节点的丢包情况，来判定丢包原因：
-
如果随后节点均没有丢包，则通常说明异常节点丢包是由于运营商策略限制所致。可以忽略相关丢包。
-
如果随后节点也出现丢包，则通常说明异常节点确实存在网络异常，导致丢包。
-
如果随后节点出现没有丢包的节点和丢包的节点，即相应节点既存在策略限速，又存在网络异常。对于这种情况，如果异常节点及其后续节点连续出现丢包，而且各节点的丢包率不同，则通常以最后几跳的丢包率为准。
延迟
- 延迟跳变
如果在某一跳之后延迟陡增，则通常判断该节点存在网络异常。不过，高延迟并不一定完全意味着相应节点存在异常，延迟大也有可能是在数据回包链路中引发的。所以，建议结合反向链路测试一并分析。
- ICMP限速导致延迟增加
ICMP策略限速也可能会导致相应节点的延迟陡增，但后续节点通常会恢复正常，可以判断该节点的延迟陡增及丢包是由于策略限速所致。