如何使用MTR诊断网络问题

前言

MTR 是一款强大的网络诊断工具，网络管理员使用 MTR 可以诊断和隔离网络问题，并且为上游 ISP 提供有用的网络状态报告。MTR 是传统 traceroute 命令的进化版，并且可以提供强大的数据样本，因为他集合了 traceroute 和 ping 这两个命令的精华。本文带您深入了解 MTR ，从数据如何生成，到如果正确理解报告样本并得出相应的结论。

使用 MTR 诊断网络问题

更新历史

2019年01月22日 - 初稿

阅读原文 - https://wsgzao.github.io/post...

扩展阅读

MTR - http://www.bitwizard.nl/mtr/
Diagnosing Network Issues with MTR - https://www.linode.com/docs/n...

网络诊断相关的背景知识

Networking diagnostic tools including ping, traceroute, and mtr use Internet Control Message Protocol (ICMP) packets to test contention and traffic between two points on the Internet. When a user pings a host on the Internet, a series of ICMP packets are sent to the host, which responds by sending packets in return. The user’s client is then able to compute the round trip time between two points on the Internet.

In contrast, tools such as traceroute and MTR send ICMP packets with incrementally increasing TTLs in order to view the route or series of hops that the packet makes between the origin and its destination. The TTL, or time to live, controls how many hops a packet will make before “dying” and returning to the host. By sending a series of packets and causing them to return after one hop, then two, then three, MTR is able to assemble the route that traffic takes between hosts on the Internet.

Rather than provide a simple outline of the route that traffic takes across the Internet, MTR collects additional information regarding the state, connection, and responsiveness of the intermediate hosts. Because of this additional information, MTR can provide a complete overview of the connection between two hosts on the Internet. The following sections outline how to install the MTR software and how to interpret the results provided by this tool.

网络诊断工具例如 ping traceroute mtr 都使用的 “ICMP” 包来测试 Internet 两点之间的网络连接状况。当用户使用 ping 命令 ping 网络上的主机后， ICMP 包将会发送到目的主机，然后在目的主机返回响应。这样，就可以得知本机到目的主机 ICMP 包传输所使用的往返时间。

相对于其他命令仅仅收集传输路径或响应时间，MTR 工具会收集更多的信息，比如连接状态，连接可用性，以及传输路径中主机的响应性。由于这些额外的信息，我们建议您尽可能完整的展现 Internet 两个主机之间的网络连接信息。接下来我们讲述如何安装 MTR 软件，以及如何看懂这款软件的输出结果。

Diagnostics and Testing - https://www.linode.com/docs/n...

名词解释

ICMP(Internet Control Message Protocol)
IP 协议族的一员，主要用于网络设备间发送错误指示信息, 一般不用于传输数据，常见部署在用户端网络程序中，诸如 traceroute 或 ping 等程序

TTL(Time To Live)
此处的 Time 表示的是次数，而不是时间，表达的是一个包在结束之前还能经过的跳数

Hop
跳数: 网络中两个端路径上的节点，路由器的数目

ISP(Internet Service Provider)
互联网服务提供商

ping

ping send ICMP ECHO_REQUEST to network hosts

ICMP 是（Internet Control Message Protocol）Internet 控制报文协议。它是 TCP/IP 协议族的一个子协议，用于在 IP 主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。

使用 ping 检查连通性有六个步骤：

使用 ifconfig 观察本地网络设置是否正确；
ping 127.0.0.1，127.0.0.1 回送地址 Ping 回送地址是为了检查本地的 TCP/IP 协议有没有设置好；
ping 本机 IP 地址，这样是为了检查本机的 IP 地址是否设置有误；
ping 本网网关或本网 IP 地址，这样的是为了检查硬件设备是否有问题，也可以检查本机与本地网络连接是否正常；(在非局域网中这一步骤可以忽略)
ping 本地 DNS 地址，这样做是为了检查 DNS 是否能够将 IP 正确解析。注: /etc/resolv.conf文件，"nameserver 8.8.8.8" 指定了 dns 服务器的地址，如果启用了NetworkManager要注意网卡重启或服务器重启配置被覆盖的问题；
ping 远程 IP 地址，这主要是检查本网或本机与外部的连接是否正常。

安装 MTR

# CentOS
yum install mtr
# Ubuntu
apt-get install mtr
# macOS
brew install mtr
# Windows
BestTrace - https://www.ipip.net/product/client.html


Usage:
 mtr [options] hostname

 -F, --filename FILE        read hostname(s) from a file
 -4                         use IPv4 only
 -6                         use IPv6 only
 -u, --udp                  use UDP instead of ICMP echo
 -T, --tcp                  use TCP instead of ICMP echo
 -a, --address ADDRESS      bind the outgoing socket to ADDRESS
 -f, --first-ttl NUMBER     set what TTL to start
 -m, --max-ttl NUMBER       maximum number of hops
 -U, --max-unknown NUMBER   maximum unknown host
 -P, --port PORT            target port number for TCP, SCTP, or UDP
 -L, --localport LOCALPORT  source port number for UDP
 -s, --psize PACKETSIZE     set the packet size used for probing
 -B, --bitpattern NUMBER    set bit pattern to use in payload
 -i, --interval SECONDS     ICMP echo request interval
 -G, --gracetime SECONDS    number of seconds to wait for responses
 -Q, --tos NUMBER           type of service field in IP header
 -e, --mpls                 display information from ICMP extensions
 -Z, --timeout SECONDS      seconds to keep probe sockets open
 -r, --report               output using report mode
 -w, --report-wide          output wide report
 -c, --report-cycles COUNT  set the number of pings sent
 -j, --json                 output json
 -x, --xml                  output xml
 -C, --csv                  output comma separated values
 -l, --raw                  output raw format
 -p, --split                split output
 -t, --curses               use curses terminal interface
     --displaymode MODE     select initial display mode
 -n, --no-dns               do not resove host names
 -b, --show-ips             show IP numbers and host names
 -o, --order FIELDS         select output fields
 -y, --ipinfo NUMBER        select IP information in output
 -z, --aslookup             display AS number
 -h, --help                 display this help and exit
 -v, --version              output version information and exit

如何读懂 MTR 报告

因为 MTR 报告包括了丰富的信息，新手第一次阅读有点困难。下面是我本地到 google.com 的测试报告

[root@sg-gop-10-65-200-186 wangao]# mtr -r google.com
Start: Wed Jan 23 16:00:30 2019
HOST: sg-gop-10-65-200-186        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.65.200.20               0.0%    10    0.3   0.3   0.3   0.5   0.0
  2.|-- ns9.webhostsg.com          0.0%    10    1.0   0.9   0.9   1.0   0.0
  3.|-- 192.168.3.33               0.0%    10    0.9   0.9   0.8   0.9   0.0
  4.|-- vlan242-s4rsm.starhub.net  0.0%    10    1.6   1.8   1.6   1.9   0.0
  5.|-- ancoretl02.starhub.net.sg  0.0%    10    2.0   2.0   1.9   2.1   0.0
  6.|-- anutli12.starhub.net.sg    0.0%    10    1.9   2.1   1.9   3.1   0.3
  7.|-- 72.14.194.0                0.0%    10    2.5   2.7   2.4   4.3   0.5
  8.|-- 74.125.242.35              0.0%    10    2.5   2.5   2.4   2.7   0.0
  9.|-- 216.239.49.74              0.0%    10    3.4   4.4   3.3  12.0   2.6
 10.|-- 74.125.252.254             0.0%    10    3.7   3.7   3.5   3.9   0.0
 11.|-- 108.170.233.49             0.0%    10    4.4   4.2   4.0   4.7   0.0
 12.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

返回结果各列数据说明：

第一列: 显示的是 IP 地址或本机域名，这点和 traceroute 很像

第二列: Loss% 到达此节点的数据包丢包率，显示的每个对应 IP 的丢包率。

第三列: Snt:100 设置发送数据包的数量，默认值是 10 通过参数 -c 来自定义数量。

第四列: Last 显示的最近一次的返回时延

第五列: Avg 平均值这个应该是发送 ping 包的平均时延

第六列: Best 最好或者说时延最低的

第七列: Wrst 最差或者说时延最大的

第八列: StDev 是标准偏差

使用 mtr –report google.com 命令来输出这篇报告。使用 report 选项可以给 google.com 主机发送 10 个 ICMP 包，然后输出报告。如果我们不使用 –report 参数， mtr 会不断的动态运行。在动态模式下， mtr 的输出结果表述每个主机的往返时间。大多数情况下，使用 –report 参数就可以提供足够的数据了。

在命令下面，就是 MTR 产生的输出报告。在通常情况下， MTR 需要几秒钟的时间来输出报告，但是偶尔可能需要更长的时间。MTR 报告是由一系列跳数组成的（在上述例子中是 12 跳）。“跳”意味着节点，或路由器，数据包通过它们才能到达目的主机。在上面例子中，数据包经过本地网络的 “内层” 和“外层”，然后再到一系列的域名主机。主机的域名是通过反向 DNS 查找确定的。如果您想忽略 DNS 查找，您可以使用 –no-dns 参数，使用 –no-dns 参数后，报告结果如下：

[root@sg-gop-10-65-200-186 wangao]# mtr -rn google.com
Start: Wed Jan 23 16:01:02 2019
HOST: sg-gop-10-65-200-186        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.65.200.20               0.0%    10    0.2   0.3   0.2   0.3   0.0
  2.|-- 203.117.178.28             0.0%    10    0.8   0.9   0.8   1.1   0.0
  3.|-- 192.168.3.33               0.0%    10    0.8   0.8   0.7   0.9   0.0
  4.|-- 203.117.6.21               0.0%    10    1.8   1.8   1.6   1.9   0.0
  5.|-- 203.118.15.177             0.0%    10    1.8   1.9   1.8   2.1   0.0
  6.|-- 203.118.12.10              0.0%    10    1.9   1.9   1.8   2.1   0.0
  7.|-- 72.14.194.0                0.0%    10    2.4   2.5   2.4   2.7   0.0
  8.|-- 74.125.242.35              0.0%    10    2.6   4.7   2.5  12.6   3.8
  9.|-- 216.239.49.74              0.0%    10    3.5   3.5   3.3   4.0   0.0
 10.|-- 74.125.252.254             0.0%    10    3.7   4.1   3.7   6.6   0.8
 11.|-- 108.170.233.49             0.0%    10    4.3   4.4   4.2   4.7   0.0
 12.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

当我们研究 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 延迟

确定丢包率

当分析 MTR 的输出时，您需要注意两点： loss 和 latency。首先，让我们讨论一下 loss。如果您在任何一跳上看到 loss 的百分比，这就说明这一跳上可能有问题了。当然，很多服务提供商人为限制 ICMP 发送的速率，这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输还是确定有丢包的现象？我们需要查看下一跳。如果下一跳没有丢包现象，说明上一条是人为限制的。如下示例：

root@localhost:~# 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@localhost:~# 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@localhost:~# 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@localhost:~# 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 报告类型

很多网络问题十分麻烦，并且需要上级网络提供商来帮助。然而，这里有很多常见的 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 速率限制可引起数据包的丢失。如果数据包在这一跳有丢失，但是下面几条都正常，我们可以判断是 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 使用小结

mtr 的功能是检查在目的地址有丢包的情况下，查出具体在哪一跳丢包，然后反馈给机房，机房再反馈给运营商；
看 mtr 的截图，先看最后的目的地址是否有丢包，若最后一跳没有丢包，说明线路 ok，若最后一跳有丢包，往下看；
再看在路由情况，第一次丢包发生在哪一跳，对应的查这一跳的丢包情况即可；
如果有条件建议双向测试抓取 mtr 返回结果，对比路由是否对等；
整理邮件发送机房联系本地网络服务商ISP或者云主机服务商请求技术支持。

如何使用MTR诊断网络问题

前言

更新历史

网络诊断相关的背景知识

名词解释

ping

安装 MTR

如何读懂 MTR 报告

分析 MTR 报告

确定丢包率

读懂网络延迟

常见的 MTR 报告类型

目的主机网络配置不当

家庭或办公室路由器的原因

运营商的路由器没有正确配置

ICMP 速率限制

超时

MTR 使用小结

王奥OX

引用和评论

字节跳动和TikTok内推

自制工具 | 局域网文本、文件传输与共享，跨设备剪切板（预览版）

【JavaEE】http/https 超级详解

Docker Swarm 核心概念及详细使用

ping请求超时是为什么？怎么解决

ITIL 4给ITSM建设带来哪些指导性意义

国企事业单位网站SSL证书怎么选？