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，有一个名为“WinMTR”的MTR端口。您可以从WinMTR上游下载此应用程序 。
苹果系统使用Homebrew 或 MacPorts在macOS上安装MTR 。要使用Homebrew安装MTR，请运行：
brew install mtr
要使用MacPorts安装MTR，请运行：
port install mtr
因为MTR提供了从一个主机到另一个主机的路由流量的图像，所以它本质上是一个定向工具。互联网上两点之间的路由可能因位置和位于上游的路由器而有很大差异。因此，对于遇到连接问题的所有主机，最好双向收集MTR报告。
Brixly客户支持往往会要求中期审查报告都 以 和 从 如果遇到网络问题您的托管帐户。这是因为，当来自相反方向的数据包丢失时，MTR报告有时不会从一个方向检测到错误。
在引用MTR报告时，此文档指的是mtr 作为源主机运行 的 主机和作为目标主机的查询所针对的 主机。
使用以下语法生成MTR报告：
mtr -rw [destination_host]
例如，要测试到目标主机的流量的路由和连接质量 example.com：
mtr -rw example.com
您的主机帐户的MTR报告可以从您的本地计算机运行。替换 192.0.2.0 为服务器的IP地址：
mtr -rw 192.0.2.0
SSH进入您的服务器并从您的服务器收集到您的家庭网络的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
在Windows系统上使用MTR注意
该
r选项标志生成报告（简称--report）。该
w选项标志使用主机名，以便我们的技术人员的长版本，你可以看到每一跳（简称的全名--report-wide）。该
c选项标志设置多少数据包被发送并记录在报告中。不使用时，默认值通常为10，但是对于更快的间隔，您可能需要将其设置为50或100.执行此 *** 作时，报告可能需要更长时间才能完成。该
i选项标志运行以更快的速度，报告揭示，只能在网络拥塞发生丢包。该标志指示MTR每n 秒发送一个数据包 。默认值为1秒，因此将其设置为十分之几秒（0.1,0.2等）通常很有帮助。
在Windows上运行MTR使用GUI。打开WinMTR，根据提示在框中键入目标主机，然后选择开始选项以开始生成报告数据。如上所示，您需要使用Linux版本的MTR从服务器生成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节点。主机的名称（例如，示例中的“内蛋糕”和“外蛋糕”）由反向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运行到您的服务器，则前2或3个跃点属于您的ISP。最后3个跃点属于服务器所在的数据中心。中间的任何啤酒花都是中间啤酒花。在本地运行MTR时，如果您在源附近的前几个跃点中看到异常，请联系您当地的服务提供商或调查您的本地网络配置。相反，如果您在目的地附近看到异常，则可能需要联系目标服务器的 *** 作员或该计算机的网络支持。不幸的是，在中间跃点存在问题的情况下，两个服务提供商解决问题的能力都有限。
分析MTR报告 验证数据包丢失在分析MTR输出时，您正在寻找两件事：损失和延迟。如果您在任何特定跳跃中看到丢失百分比，则可能表示该特定路由器存在问题。但是，某些服务提供商通常会对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协议旨在对某些网络性能降级具有d性，并且数据在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报告可以描述常见的网络问题。如果您遇到某种网络问题并想要诊断问题，请考虑以下示例。
目标主机网络配置不正确在下一个示例中，由于路由器配置不正确，似乎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能够在指定的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报告显示的大多数路由问题都是暂时的。大多数问题将在24小时内自行解决。在大多数情况下，当您能够发现路由问题时，Internet服务提供商的监控已经报告了问题，管理员正在努力解决问题。如果您在较长时间内遇到服务质量下降，您可以选择向提供商提醒您遇到的问题。联系服务提供商时，请发送MTR报告以及您可能拥有的任何其他相关数据。没有可用的数据，提供商无法验证或修复问题。
虽然路由错误和问题占网络相关速度的一定百分比，但它们绝不是降低性能的唯一原因。网络拥塞，特别是在高峰时段的长距离，可能会变得严重。跨大西洋和跨太平洋的交通可能变化很大，并且受到一般网络拥塞的影响。在这些情况下，建议您将主机和资源定位在尽可能靠近目标受众的地理位置。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）