用MTR诊断网络问题

时间  2019-11-12
标签 mtr 诊断 网络 问题 栏目 系统网络 繁體版
原文   原文链接

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

有关网络诊断技术的基本概述，请参阅咱们的网络诊断简介。若是您的系统存在其余问题，请阅读咱们的常规系统诊断概述。node

网络诊断背景

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

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

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

安装MTR

Linux

Debian / Ubuntu网络

apt update && apt upgrade
apt install mtr-tiny

CentOS/ RHEL / Fedoraide

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的“支持”选项卡中提交报告的输出，咱们的技术人员能够帮助您分析问题。

更多信息

有关此主题的其余信息，您可能须要参考如下资源。虽然提供这些是但愿它们有用，但请注意，咱们没法保证外部托管材料的准确性或时效性。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程