MTR（My Traceroute）是一个网络诊断工具，它结合了ping和traceroute的功能。通过发送一系列的网络数据包并显示每个跳点的延迟、丢包情况等信息，帮助用户分析网络连接的质量。

以下是MTR工具的使用示例：

假设你想测试到目标服务器的网络连接状况。

  1. 打开终端窗口或命令提示符窗口。

  2. 输入以下命令，并在后面加上目标服务器的IP地址或域名：

mtr <目标服务器IP地址或域名>

  1. 按下回车键开始运行MTR。

  2. MTR会不断发送网络数据包并显示每个跳点的延迟、丢包率等信息。通常情况下，MTR会持续运行，直到你手动停止它。

  3. 查看MTR的输出结果。你将看到每个跳点的IP地址、主机名、平均延迟、丢包率等信息。你可以根据这些信息判断网络连接是否稳定，找出可能存在的问题。

  4. 如果需要保存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策略限速也可能会导致相应节点的延迟陡增，但后续节点通常会恢复正常，可以判断该节点的延迟陡增及丢包是由于策略限速所致。