My Traceroute (MTR) 结合了 traceroute 和 ping 来测量网络路径的健康状况。
阅读本文后,您将能够:
复制文章链接
Traceroute 是一种用于诊断网络路径问题的工具。Traceroute 用于了解 IP 数据包从一台计算机(源 IP 地址)到另一台计算机(目标 IP 地址)的路径。命令 traceroute(在 Linux 或 macOS 上)或 tracert(在 Windows 上)可以使其了解:
*往返时间 (RTT) 是指数据在网络上往返于某一点所需的时间量。
下面是一个到 1.1.1.1 的 Traceroute 示例。带星号的行 (* * *) 代表没有返回数据包的跃点数;当路由器被配置为忽略 Traceroute 数据包时可能发生这种情况。每一行中的毫秒时间是每个数据包从来源到该跃点的往返时间(Traceroute 每次发送三个数据包以验证结果)。
Traceroute 示例 |
---|
Traceroute 到 1.1.1.1(1.1.1.1),最大 64 个跃点,52 字节数据包 |
1 myrouter (192.168.47.1) 2.755 毫秒 1.452 毫秒 1.325 毫秒 |
2 * * * |
3 69.168.32.65 (69.168.32.65) 18.159 毫秒 18.658 毫秒 15.091 毫秒 |
4 * * * |
5 206.126.237.30 (206.126.237.30) 30.453 毫秒 50.242 毫秒 24.342 毫秒 |
6 one.one.one.one (1.1.1.1) 29.000 毫秒 26.784 毫秒 26.017 毫秒 |
网络路径是指一个数据包为到达目的地而经过的网络序列。
互联网是通过路由相互连接的大规模网络集合。大多数互联网端点(例如,试图访问网站的 Web 浏览器和托管该网站的服务器)不是同一个网络的一部分。这意味着,如果所述 Web 浏览器向网站的服务器发送请求,则该请求可能必须沿途在多个中间网络之间跳跃。
Traceroute 工具将数据包发送到目标 IP,并将生存时间 (TTL) 设置为 1,因此数据包到达的第一个路由器将发回错误(“超时”)。当错误返回时,Traceroute 工具记录第一个路由器的身份和往返时间,增加 TTL,并发送新数据包,重复此过程直到:1)后一个数据包到达目标 IP,或 2)两组数据包被丢弃。
通过这样做,该工具让您能够了解数据包所采用的路径以及到每个跃点的往返时间,因此您可以对数据包丢失和延迟进行故障排除。
Traceroute 依赖于 ICMP(互联网控制消息协议)协议。ICMP 是一个用于错误测试的网络层协议。它没有相关的传输协议,直接在互联网协议 (IP) 上运行。当 Traceroute 工具发送的数据包的 TTL 被超过时,路由器会发回一个 ICMP Type 11(超时错误)数据包。
传出数据包(从起始路由器发送)可以使用 ICMP(MacOS 和 Linux 操作系统上的默认值)或 UDP(Windows 上的默认值)。如果将网络路径上的路由器配置为过滤掉特定协议的数据包,则为传出的 Traceroute 数据包选择不同的协议能够获得更完整结果。
My Traceroute (MTR) 是一个结合了 traceroute 和 ping 的工具,这是测试网络连接和速度的另一个常用方法。除了网络路径上的跃点外,MTR 还显示到目的地的路线中不断更新的延迟和丢包信息。这可让您实时看到路径上发生的情况,协助排除网络问题。
MTR 以与 traceroute 类似的方式发现网络路径,然后定期发送数据包以继续收集信息,以提供有关网络运行状况和速度的更新视图。
与 traceroute 一样,MTR 可以将 ICMP 或 UDP 用于传出数据包,但依赖 ICMP 返回 (Type 11: Time Exceeded) 数据包。
以下是如何阅读 MTR 输出并从中得出结论的三个示例。
正常的 MTR | |||||||
---|---|---|---|---|---|---|---|
开始:2020-04-08T13:28:52+0100 | |||||||
主机:myrouter | 丢包率 | 发送包数 | 最后 | 平均 | 最佳 | 最差 | 标准偏差 |
1.|-- 10.10.1.1 | 0.0% | 10 | 0.3 | 0.4 | 0.3 | 0.4 | 0.0 |
2.|-- 141.0.147.177.bcube.co.uk | 0.0% | 10 | 2.7 | 2.7 | 2.5 | 3.1 | 0.2 |
3.|-- 172.16.28.38 | 0.0% | 10 | 2.8 | 6.4 | 2.8 | 22.2 | 6.1 |
4.|-- 172.17.13.76 | 0.0% | 10 | 1.1 | 2.8 | 1.1 | 14.6 | 4.2 |
5.|-- 172.17.13.49 | 0.0% | 10 | 1.4 | 4.0 | 1.3 | 25.0 | 7.4 |
6.|-- 172.17.13.24 | 0.0% | 10 | 2.5 | 2.7 | 2.0 | 5.1 | 1.1 |
7.|-- one.one.one.one | 0.0% | 10 | 1.3 | 1.2 | 1.2 | 1.3 | 0.0 |
此示例遵循起始路由器和 Cloudflare 的 1.1.1.1 DNS 服务器之间的网络路径。MTR 输出没有表明任何问题—— 需要 7 次跳跃才能到达 1.1.1.1,并且没有任何一项表示发生任何丢包。
路径上的丢包 | |||||||
---|---|---|---|---|---|---|---|
开始:2020-04-08T12:48:28+0000 | |||||||
主机:myrouter | 丢包率 | 发送包数 | 最后 | 平均 | 最佳 | 最差 | 标准偏差 |
1.|-- 2400:cb00:207:1000::1 | 0.0% | 10 | 1.1 | 6.0 | 0.6 | 15.7 | 5.9 |
2.|-- 2404:d400:4000:27::1 | 0.0% | 10 | 0.4 | 0.6 | 0.2 | 2.9 | 0.8 |
3.|-- 2404:d400:0:8:: | 0.0% | 10 | 125.7 | 125.7 | 125.7 | 126.2 | 0.2 |
4.|-- 2001:978:2:42::e:1 | 50.0% | 10 | 129.2 | 129.6 | 129.2 | 130.5 | 0.6 |
5.|-- be2846.ccr42.fra03.atlas.cogentco.com | 80.0% | 10 | 151.9 | 139.5 | 127.1 | 151.9 | 17.6 |
6.|-- be2814.ccr42.ams03.atlas.cogentco.com | 80.0% | 10 | 136.2 | 137.0 | 136.2 | 137.8 | 1.1 |
7.|-- be2183.ccr22.lpl01.atlas.cogentco.com | 50.0% | 10 | 146.3 | 146.2 | 145.9 | 146.3 | 0.1 |
8.|-- be3043.ccr22.ymq01.atlas.cogentco.com | 30.0% | 10 | 215.3 | 215.2 | 215.0 | 215.4 | 0.2 |
9.|-- be3260.ccr32.yyz02.atlas.cogentco.com | 90.0% | 10 | 227.8 | 227.8 | 227.8 | 227.8 | 0.0 |
10.|-- be2994.ccr22.cle04.atlas.cogentco.com | 30.0% | 10 | 234.9 | 234.9 | 234.5 | 235.1 | 0.2 |
11.|-- be2718.ccr42.ord01.atlas.cogentco.com | 70.0% | 10 | 233.7 | 233.8 | 233.7 | 233.9 | 0.1 |
12.|-- be2832.ccr22.mci01.atlas.cogentco.com | 50.0% | 10 | 244.8 | 245.1 | 244.8 | 245.5 | 0.3 |
13.|-- be3036.ccr22.den01.atlas.cogentco.com | 30.0% | 10 | 259.6 | 259.6 | 259.3 | 259.8 | 0.2 |
14.|-- be3038.ccr32.slc01.atlas.cogentco.com | 90.0% | 10 | 267.2 | 267.2 | 267.2 | 267.2 | 0.0 |
15.|-- be3110.ccr22.sfo01.atlas.cogentco.com | 10.0% | 10 | 291.0 | 291.1 | 291.0 | 291.4 | 0.1 |
16.|-- be3670.ccr41.sjc03.atlas.cogentco.com | 30.0% | 10 | 292.6 | 292.7 | 292.6 | 292.8 | 0.1 |
17.|-- 2001:550:2:1f::29:2 | 0.0% | 10 | 312.3 | 291.5 | 287.0 | 312.3 | 8.6 |
8.6 | 0.0% | 10 | 298.7 | 299.5 | 298.7 | 306.1 | 2.3 |
19.|-- ??? | 100.0 | 10 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
20.|-- ??? | 100.0 | 9 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
21.|-- 2400:cb00:36:1008::a29e:40e2 | 0.0% | 9 | 302.9 | 302.9 | 302.8 | 303.2 | 0.1 |
这个例子显示了起始路由器和 2400:cb00:36:1008::a29e:40e2 之间的网络路径,这是一个 IPv6 地址。输出显示所有 Cogent 跃点上的大量数据包丢失。但是,在最后一个跃点 (21) 上没有丢包。这表明网络路径实际上没有问题。正在发生的事情通常被称为“控制平面监管”。
如前所述,MTR 通过发送(默认情况下)ICMP Echo 数据包来工作,每个数据包具有递增的 TTL(生存时间)。当 TTL 过期时,路由器会发回一个 ICMP Type 11 (Time Exceeded),表示从 A 点到 B 点有多少个跃点。
许多网络运营商(包括 Cloudflare)对允许到达路由器控制平面的 ICMP 数据包数量设置了任意限制。(控制平面是路由器的大脑。)超过路由器 TTL 的数据包必须由控制平面处理。为了防止控制平面被过多的此类数据包淹没,设置了速率限制(或监管器),这就是为什么我们看到所有丢包都发生在中间跃点上,而不是在最后一个跃点上:中间跃点上的路由器的控制平面速率限制被超过,因此对于超过这些限制的 traceroute 数据包不会发回 Type 11 数据包,但数据包能够安全地到达目的地。
返回路径上的丢包 | |||||||
---|---|---|---|---|---|---|---|
开始:2020-04-08T13:32:30+0000 | |||||||
主机:myrouter | 丢包率 | 发送包数 | 最后 | 平均 | 最佳 | 最差 | 标准偏差 |
1.|-- 162.158.216.129 | 0.0% | 10 | 0.7 | 6.9 | 0.7 | 62.6 | 19.6 |
2.|-- 118.69.221.209 | 0.0% | 10 | 0.2 | 0.3 | 0.2 | 1.3 | 0.3 |
3.|-- 118.69.252.172 | 0.0% | 10 | 0.7 | 1.0 | 0.6 | 2.9 | 0.7 |
4.|-- 118.69.132.169 | 0.0% | 10 | 11.4 | 11.3 | 11.2 | 11.5 | 0.1 |
5.|-- 118.69.247.64 | 0.0% | 10 | 34.2 | 34.4 | 33.9 | 37.2 | 1.0 |
6.|-- 13335.sgw.equinix.com | 50.0% | 10 | 27.5 | 27.9 | 27.1 | 29.1 | 0.8 |
7.|-- 162.158.161.251 | 30.0% | 10 | 26.8 | 26.8 | 26.8 | 26.8 | 0.0 |
此示例显示起始路由器和 162.158.161.251 之间的网络路径。输出显示最后 2 个跃点上的数据包丢失。
MTR 有许多选项。您可以通过 MTR 帮助页面找到更多:mtr --help
一些经常使用的选项包括: