用MTR诊断网络问题

魔法少女伊莉雅

发布于 2018-09-10 11:01:11

13.7K0

发布于 2018-09-10 11:01:11

MTR是一个功能强大的工具，使管理员能够诊断和隔离网络错误，并向上游提供商提供网络状态报告。MTR表示的演进traceroute通过提供更大的数据样本，好像增强命令traceroute与ping输出。本文深入介绍了MTR，它产生的数据，以及如何根据它提供的数据得出结论。

有关网络诊断技术的基本概述，请参阅我们的网络诊断简介。如果您的系统存在其他问题，请阅读我们的常规系统诊断概述。

网络诊断背景

网络诊断工具包括ping，traceroute和mtr，它们使用Internet控制消息协议（ICMP）数据包来测试Internet上两点之间的连接和传输。当用户在Internet上ping主机时，会向主机发送一系列ICMP数据包，主机通过发送数据包作为响应。然后，用户的客户端能够计算因特网上两点之间的往返时间。

相反，诸如traceroute和MTR之类的工具发送ICMP数据包的TTL递增，可以查看数据包在源和目的地之间产生的一系列跳。TTL即生存时间，控制着数据包在“死亡”并返回主机之前将进行多少跳。通过发送一系列数据包并使它们在一跳、两跳、三跳之后返回，MTR能够分析英特网上不同主机之间流量的通路。

MTR不是只提供Internet的路由间的简单概述，而是收集有关中间主机的状态，连接和响应性的其他信息。由于这些附加信息，MTR可以提供Internet上两台主机之间连接的完整描述。以下部分概述了如何安装MTR软件以及如何解释此工具提供的结果。

安装MTR

Linux

Debian / Ubuntu

apt update && apt upgrade
apt install mtr-tiny

CentOS/ RHEL / Fedora

yum update
yum install mtr

Windows

对于Windows，有一个名为“WinMTR”的MTR端口。您可以从WinMTR上游下载此应用程序。

苹果系统

使用Homebrew或MacPorts在macOS上安装MTR 。要使用Homebrew安装MTR，请运行：

brew install mtr

要使用MacPorts安装MTR，请运行：

port install mtr

生成MTR报告

因为MTR提供了从一个主机到另一个主机的路由流量的图像，所以它本质上是一个定向工具。互联网上两点之间的路由可能因位置和位于上游的路由器而有很大差异。因此，对于遇到连接问题的所有主机，最好双向收集MTR报告。

Linode客户支持往往会要求中期审查报告都要以你的Linode为起点或终点如果你遇到网络问题。这是因为，当来自相反方向的数据包丢失时，MTR报告有时从一个方向检测不到错误。

在引用MTR报告时，此文档指的是源主机运行mtr查询队列作为目标主机。

在基于Unix的系统上使用MTR

使用以下语法生成MTR报告：

mtr -rw [destination_host]

例如，要测试到目标主机example.com的流量的路由和连接质量：

mtr -rw example.com

可以从本地计算机运行到您的Linode的MTR报告。替换192.0.2.0为您的Linode的IP地址：

mtr -rw 192.0.2.0

SSH进入您的Linode并从您的Linode收集MTR到您的家庭网络的报告。替换198.51.100.0为家庭网络的IP地址。

mtr -rw 198.51.100.0

如果您不知道您的家庭IP地址，请使用WhatIsMyIP.com。

如果未检测到数据包丢失，则技术支持人员可能会要求您以更短的时间间隔运行：

mtr -rwc 50 -i 0.2 -rw 198.51.100.0

在某些系统上，使用此标志可能需要管理权限：

sudo mtr -rwc 50 -i 0.2 -rw 198.51.100.0

注意r选项标志生成报告（简称--report）。 w选项标志使用主机名，以便我们的技术人员和你可以看到每一跳（简称的全名--report-wide）。 c选项标志设置多少数据包被发送并记录在报告中。不使用时，默认值通常为10，但是对于更快的间隔，您可能需要将其设置为50或100.执行此操作时，报告可能需要更长时间才能完成。 i选项标志以更快的速度运行监测是否只在网络拥塞发生丢包。该标志指示MTR每n秒发送一个数据包。默认值为1秒，因此将其设置为十分之几秒（0.1,0.2等）通常很有帮助。

在Windows系统上使用MTR

在Windows上使用GUI运行MTR。打开WinMTR，根据提示在框中键入目标主机，然后选择开始选项以开始生成报告数据。如上所示，您需要使用Linux版本的MTR从您的Linode生成MTR报告。

阅读MTR报告

由于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选项，该选项将10个数据包发送到主机google.com并生成报告。如果没有--report选项，mtr将在交互式环境中持续运行。交互模式反映了每个主机的当前往返时间。在大多数情况下，--report模式以有用的格式提供足够的数据。

报告中的每个编号行代表一个跃点。跃点是数据包通过并到达目的地的Internet节点。主机的名称（例如，示例中的“inner-cake”和“outer-cake”）由反向DNS查找确定。如果要省略rDNS查找，可以使用--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还在后面的七列中提供有关该连接的持久性的有价值的统计信息。Loss%列显示每跳的丢包百分比。Snt列计算发送的数据包数。--report除非指定--report-cycles=[number-of-packets]，否则该选项将发送10个数据包，其中[number-of-packets]表示要发送到远程主机的数据包总数。

接下来的四列Last，Avg，Best和Wrst以毫秒为单位测量所有延迟（ms）。Last是最后发送的数据包的延迟，Avg是所有数据包的平均延迟，而Best并Wrst显示最佳（最短）和最差（最长）往返时间的到该主机的包的时间。在大多数情况下，average（Avg）列应该是您关注的焦点。

最后一列StDev提供了每个主机的延迟标准偏差。标准差越大，延迟测量之间的差异越大。标准偏差允许您评估所提供的平均值（平均值）是否代表数据集的真实中心，或者是否因某种现象或测量误差而偏斜。如果标准偏差很高，则延迟测量值不一致。在对发送的10个数据包的延迟进行平均后，平均值看起来正常但实际上可能不能很好地表示数据。如果标准偏差很高，请查看最佳和最差延迟测量，以确保平均值是实际延迟的良好表示，而不是太大波动的结果。

在大多数情况下，您可能会想到三个主要部分的MTR输出。根据配置，前2或3跳通常代表源主机的ISP，而最后2或3跳代表目标主机的ISP。中间的跳数是数据包遍历到达目的地的路由器。

例如，如果MTR从您的家用PC运行到您的Linode，则前2或3个跃点属于您的ISP。最后3个跃点属于您的Linode所在的数据中心。中间的任何跳都是处于中间媒介的跳。在本地运行MTR时，如果您在源附近的前几个跃点中看到异常，请联系您当地的ISP或调查您的本地网络配置。相反，如果您在目的地附近看到异常，则可能需要联系目标服务器的操作员或该计算机的网络支持。不幸的是，在中间跃点存在问题的情况下，两个服务提供商解决问题的能力都有限。

分析MTR报告

验证数据包丢失

在分析MTR输出时，您要寻找两件事：丢包和延迟。如果您在任何特定跳中看到丢失百分比，则可能表示该特定路由器存在问题。但是，某些ISP通常会对MTR使用的ICMP流量进行速率限制。这可能给出丢包的错觉然而实际上并没有丢包。要确定您所看到的丢包是真实的还是由于速率限制，请查看后续跳。如果后续跳显示0.0％的丢包，那么您可能是看到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

在这种情况下，跳1和2之间报告的丢包可能是由于第二跳的速率限制。剩余8个跃点的流量都到第二跳，但没有数据包丢失。如果丢失持续超过一跳，则可能存在丢包或路由问题。请记住，速率限制和丢包可以同时发生。在这种情况下，将序列中最低的丢包百分比作为实际丢包：

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

在这种情况下，跳2和3之间以及跳3和4之间有60％的丢包。您可以假设第三跳和第四跳可能会丢失一些流量，因为没有后续主机报告零丢失。然而，一些丢包是由于速率限制，因为几个最终的跳仅经历了40％的丢包。报告不同数量的丢包时，请始终信任后续跃点中的报告。

一些丢包也可以通过返回路线中的问题来解释。数据包将毫无错误地到达目的地，但很难进行返回。因此，当您遇到问题时，通常最好在两个方向收集MTR报告。

不要调查或报告连接中所有的丢包事件。Internet协议对某些网络性能下降具有弹性，并且在Internet上传输数据的路由可能会因负载、简短维护事件和其他路由问题而发生波动。如果您的MTR报告显示10％左右的少量丢包，则没有理由去关注，因为应用层将补偿这些丢包。

网络延迟

除了帮助您评估数据包丢失外，MTR还将帮助评估主机与目标主机之间连接的延迟。由于物理约束，延迟总是随着路由中的跳数而增加。但是，增加应该是线性的。不幸的是，延迟通常是相对的，并且非常依赖于主机连接的质量和它们的物理距离。在评估可能存在问题的连接的MTR报告时，除了已知给定区域中其他主机之间的连接速度之外，还要关注早期的所有的功能报告。

连接质量还可能影响您到特定路由器遇到的延迟量。可以知道，拨号连接比连接到同一目的地的电缆调制解调器连接具有更高的延迟。以下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

延迟量在跳3和4之间显著增高。这可能是网络延迟问题，因为在第四跳之后往返时间仍然很高。从该报告中可以知道，配置不良的路由器或拥塞的链路是可能原因，但无法确定原因。

不幸的是，高延迟并不总是意味着当前路线的问题。像上面那样的报告意味着尽管第4跳出现了某种问题，但流量仍然到达目标主机并返回到源主机。延迟也可能是由返回路线问题引起的。您的MTR报告中将不会显示返回路由，并且数据包可以采用与特定目的地完全不同的路由。

在上面的示例中，虽然主机3和4之间的延迟有很大的跳跃，但延迟在任何后续跳跃中都不会异常增加。由此可以合理地假设第4个路由器存在一些问题。

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之间的延迟引起了人们的注意。然而，在第五跳之后，延迟急剧下降。这里测量的实际延迟大约是40ms。在这种情况下，MTR的报告的延迟并没有什么影响。在评估MTR报告时，请考虑最后一跳的延迟。

通用MTR报告

一些网络问题是新颖的并且需要升级到上游网络的运营商。但是，有一些常见的MTR报告可以描述常见的网络问题。如果您遇到某种网络问题并想要诊断问题，请考虑以下示例。

目标主机网络配置不正确

在下一个示例中，由于路由器配置不正确，似乎100％丢失了目标主机。乍一看，似乎数据包没有到达主机，但事实并非如此。

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    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数据包的结果。

您可以判断丢失是由于配置错误的主机造成的，就是查看显示100％丢失的跳数。从以前的报告中，您可以看到这是最后一跳，并且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％损失并不表示存在问题。您可以看到后续跃点没有丢失。

未正确配置ISP路由器

有时，您的数据包所使用的路由上的路由器配置错误，您的数据包可能永远无法到达目的地：

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. ???                           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@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. 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跳路由器未正确配置。发生这些情况时，解决问题的唯一方法是联系源主机上的网络管理员的操作员团队。

ICMP速率限制

ICMP速率限制可能导致明显的数据包丢失。如果丢包到一个跳不会持续到后续跳，则丢失是由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                 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，缺少的回复将在输出中显示为超时（???）。或者，返回路线可能存在问题：

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. ???                           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

超时不一定表示数据包丢失。数据包仍然可以到达目的地，而不会出现明显的丢包或延迟超时可能归因于路由器为了QoS（服务质量）目的而丢弃数据包，或者导致超时的返回路由可能存在一些问题。这是另一个误报。

先进的MTR技术

较新版本的MTR能够在指定的TCP端口上以TCP模式运行，而不是ICMP（ping）协议。在某些情况下，网络性能下降可能只限于特定端口，它们可能是由于配置不正当的防火墙规则或者特定路由器禁用特定端口所导致的。在某个端口上运行MTR可能会显示丢包，而默认的ICMP报告可能没有。

在TCP模式下运行MTR在大多数机器上需要具有sudo权限：

sudo mtr -P 80 -i 0.5 -rwc 50 example.com
sudo mtr -P 22 -i 0.5 -rwc 50 example.com

解决您的MTR报告中确定的路由和网络问题

MTR报告显示的大多数路由问题都是暂时的。大多数问题将在24小时内自行解决。在大多数情况下，当您能够发现路由问题时，Internet服务提供商的监控已经报告了问题，管理员正在努力解决问题。如果您在较长时间内遇到服务质量下降，您可以选择向提供商提醒您遇到的问题。联系服务提供商时，请发送MTR报告以及您可能拥有的任何其他相关数据。没有可用的数据，提供商无法验证或修复问题。

虽然路由错误和问题占网络速度问题的一定的百分比，但它们绝不是降低性能的唯一原因。网络拥塞，特别是在高峰时段的长距离传输，可能会变得严重。跨大西洋和跨太平洋的网络波动可能变化很大，并且受到一般网络拥塞的影响。在这些情况下，建议您将主机和资源定位在尽可能靠近目标受众的地理位置。

如果您遇到连接问题且无法解释您的MTR报告，请打开支持服务单。在Linode Manager的“支持”选项卡中提交报告的输出，我们的技术人员可以帮助您分析问题。