专栏首页运维杂家技术分享MTR工具使用说明文档
原创

MTR工具使用说明文档

MTR工具使用说明文档

版本说明:

版本

修订日期

修订内容

修订人

联系方式

1.0

20191225

完成

Hunter

hunter_xiao@126.com

目 录

第1章 MTR是什么

第2章 MTR如何获取

2.1 Mtr for linux

2.2 Mtr for windows

第3章 MTR如何使用

3.1 Mtr for Linux

3.2 Mtr for Windows

第4章 测试结果分析

4.1 链路测试步骤

4.1.1 获取客户端和服务器端公网IP

4.1.2 正向链路测试(PING和MTR)

4.1.3 反向链路测试(PING和MTR)

4.1.4 测试结果分析

第1章 MTR是什么

Mtr是一个将“traceroute”和“ping”程序功能结合在一起的一个网络诊断工具。

运行Mtr指定一个IP地址,Mtr会查看运行Mtr的主机和指定目标主机之间的网络节点。在确定目标主机和本地主机间每个网络节点的IP地址后,它向每个网络节点发送一个ICMP ECHO请求,以确定到每个节点的链路的质量。就像这样它会打印到每个节点的运行统计信息。

如下图所示:Windows Mtr 工具示例图

第2章 MTR如何获取

2.1 Mtr for linux

Linux 使用命令安装,例如CentOS使用yum命令安装

yum install -y mtr

安装完毕后即可使用

2.2 Mtr for windows

Windows 在这里下载 https://mtr-1251908826.cos.ap-beijing.myqcloud.com/WinMTR.7z

根据您windows操作系统的版本选择mtr的版本。

第3章 MTR如何使用

3.1 Mtr for Linux

使用说明:

[root@VM_65_87_centos ~]# mtr --help

usage: mtr [-hvrwctglspniu46] [--help] [--version] [--report]

[--report-wide] [--report-cycles=COUNT] [--curses] [--gtk]

[--raw] [--split] [--no-dns] [--address interface]

[--psize=bytes/-s bytes]

[--interval=SECONDS] HOSTNAME [PACKETSIZE]

常用参数:

mtr -s 用来指定ping数据包的大小

mtr -n no-dns不对IP地址做域名反解析

mtr -a 来设置发送数据包的IP地址,这个用于主机有多个IP时。

mtr -i 使用这个参数来设置ICMP返回之间的要求默认是1秒

mtr -c 指定发送多少个数据包

mtr -4 IPv4

mtr -6 IPv6

在MTR运行过程中,可以输入快捷字母切换模式例如:

?或 h:显示帮助菜单。

d:切换显示模式。

n:切换启用或禁用 DNS 域名解析。

u:切换使用 ICMP或 UDP 数据包进行探测。

示例输出:

[root@VM_65_87_centos ~]# mtr -c 100 -i0.1 -r 114.114.114.114

HOST: VM_65_87_centos Loss% Snt Last Avg Best Wrst StDev

1. ??? 100.0 100 0.0 0.0 0.0 0.0 0.0

2. 10.243.119.41 40.0% 100 3935. 5162. 3935. 5841. 561.4

3. 10.200.174.217 0.0% 100 1.3 0.9 0.8 2.8 0.2

4. 210.48.136.205 0.0% 100 0.9 1.1 0.9 9.4 1.0

5. 59.43.247.229 0.0% 100 11.9 5.3 1.5 61.4 9.9

6. 59.43.250.77 0.0% 100 5.3 11.9 5.3 89.0 15.9

7. 59.43.187.141 61.0% 100 7.3 9.3 7.2 40.6 6.9

8. 59.43.130.113 0.0% 100 7.9 8.0 7.8 11.7 0.6

9. 59.43.80.22 0.0% 100 10.8 10.1 8.2 15.8 1.3

10. 202.97.64.126 0.0% 100 12.3 15.2 11.1 19.3 2.4

11. 202.97.47.229 1.0% 100 36.9 36.4 33.5 60.4 3.1

12. 218.2.182.30 1.0% 100 29.9 31.5 29.2 33.9 1.2

13. 58.213.224.170 70.0% 100 33.8 34.5 33.7 41.1 1.5

14. public1.114dns.com 1.0% 100 29.0 29.1 28.9 32.1 0.3

返回结果各列数据说明:

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

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

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

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

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

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

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

第八列:StDev是标准偏差

3.2 Mtr for Windows

根据上文2.2章节下载安装MTR。

WinMTR 工具是Windows 环境图形化实现,WinMTR进行了功能简化,只支持 mtr部分参数调整设置。WinMTR 默认发送ICMP 数据包进行探测,无法切换。

使用说明:

1 如下图所示,打开程序在Host后面的方框内输入目标域名或IP地址。

注意: Host后面的方框内IP地址前后不要加空格,如有空格报错如下。

2 点击 Start 开始测试(开始测试后,相应按钮变成了 Stop)。

3 运行一段时间后,点击 Stop 停止测试。

4 其它选项说明:

Copy Text to clipboard:将测试结果以文本格式复制到粘贴板。

Export TEXT:将测试结果以文本格式导出到指定文件。

示例如下:

Copy HTML to clipboard:将测试结果以 HTML 格式复制到粘贴板。

Export HTML:将测试结果以 HTML 格式导出到指定文件。

示例如下:

Options:可选参数:

Interval(sec):每次探测的间隔(过期)时间。默认为 1 秒。

Ping size(bytes): ping 探测所使用的数据包大小,默认为 64 字节。、

Max hosts in LRU list: LRU 列表支持的最大主机数,默认值为 128。

Resolve names:通过反查 IP 以域名显示相关节点。

默认配置,返回结果各列数据说明:

第一列(Hostname):节点 IP 或域名。

第二列(Nr):节点编号。

第三列(Loss%):节点丢包率。

第四列(Sent):已发送的数据包数量。

第五列(Recv):已成功接收的数据包数量。

第六、七、八、九列(Best 、Avg、Worst、Last):分别是到相应节点延迟的最小值、平均值、最大值和最后一次值。

第八列(StDev):标准偏差。越大说明相应节点越不稳定。

第4章 测试结果分析

4.1 链路测试步骤

4.1.1 获取客户端和服务器端公网IP

在客户端和服务器端浏览器里面输入https://ping.huatuo.qq.com/www.ipip.net等网站,就可以获得本地或者服务器对应的公网IP。

4.1.2 正向链路测试(mtr)

从客户端向目标服务器做MTR链路测试。从客户端向目标服务器域名或IP做持续的MTR测试,测试100个数据包,记录测试结果。根据客户端操作系统环境的不同,使用WinMTR或mtr命令,设置测试目的地址为目标服务器域名或IP,然后进行链路测试,记录测试结果。

4.1.3 反向链路测试(mtr)

进入目标服务器系统内部,做反向MTR链路测试。从目标服务器向客户端IP做持续的MTR测试,建议至少测试100个数据包,记录测试结果。根据目标服务器操作系统环境的不同,使用WinMTR或mtr命令,设置测试目的地址为客户端 IP,然后进行链路测试,记录测试结果。

4.1.4 测试结果分析

参阅前述说明,对测试结果进行分析。确认异常节点后,访问 https://ping.huatuo.qq.com/ 等网站查询、获取相应节点归属运营商及网络。如果是客户端本地网络相关节点出现异常,则需要对本地网络进行相应排查分析。如果是运营商相关节点出现异常,则需要直接联系运营商,或联系腾讯云售后技术支持向相应运营商反馈问题。

4.1.4.1 验证数据包丢失

在分析 MTR 输出时,需要寻找两件事情:丢包和延迟。首先让我们来谈谈丢包。如果您在任何特定跳点看到一定百分比的丢失,这可能表明该特定路由器存在问题。然而,一些服务提供商通常的做法是限制 MTR 使用的ICMP流量。这实际上没有真正的丢包,但是给出丢包的错觉。要确定您看到的丢包是真实的还是由于速率限制的,可查看随后的一跳,如果该跳丢包率是0.0%,那么您可以确定您看到的是 ICMP 速率限制导致,而不是实际丢包。参见下面的例子:

对链路测试结果进行分析时,需要关注如下要点。

网络区域

链路负载均衡

结合Avg(平均值)和 StDev(标准偏差)综合判断

Loss%(丢包率)的判断

延迟

在这种情况下,第1跳和第4跳之间报告的丢包可能是由于第2和3跳速率限制。虽然剩下的跳数的流量都触及第2和3跳,但是第4跳没有丢包。如果丢失持续多于一个跳,则可能存在一些丢包或路由问题。请记住,速率限制和实际丢失可能同时发生。在这种情况下,将序列中的最低损失百分比作为实际损失。例如,考虑以下输出:

mtr -r www.goole.com

HOST:PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

1.10.1.1.254

0.0%

10

1.6

0.8

0.7

1.6

0.3

2.10.1.253.22

0.0%

10

0.5

0.6

0.3

1.4

0.3

3.210.74.5.2

0.0%

10

1.0

1.1

0.9

1.3

0.2

4.10.244.246.9

0.0%

10

2.0

2.5

1.6

5.2

1.2

5.10.244.200.1

0.0%

10

1.8

2.3

1.6

3.8

0.7

6.172.18.0.149

0.0%

10

4.2

9.9

4.2

35.1

11.0

7.222.35.253.153

0.0%

10

2.2

2.2

2.1

2.6

0.2

8.61.233.9.209

0.0%

10

3.4

5.2

3.1

7.0

1.5

9.61.237.123.134

0.0%

10

32.9

34.4

32.7

36.7

1.4

10.61.237.123.214

0.0%

10

33.5

33.5

33.1

34.1

0.3

11.prs-b4-link.telia.net

10.0%

10

217.3

217.5

217.2

217.9

0.2

12.prs-bb2-link.telia.net

0.0%

10

222.8

234.4

222.7

291.5

24.8

13.ffm-bb4-link.telia.net

0.0%

10

218.0

220.1

218.0

223.5

2.3

14.ffm-b1-link.telia.net

0.0%

10

217.9

223.8

217.9

233.9

6.2

15.1o1internet-ic-309319-ffm-b1

0.0%

10

234.4

227.2

223.1

234.4

3.2

16.ae-11.bb-c.bs.kae.de.oneando

0.0%

10

228.2

231.2

225.1

238.0

5.0

17.ae-3.bb-c.bap.rhr.de.oneando

10.0%

10

226.1

231.4

226.1

238.1

4.6

18.ae-11.gw-distp-a.bap.rhr.de.

10.0%

10

226.3

227.3

226.0

235.7

3.2

19.ae-1.gw-prtr-r231-a.bap.rhr.

20.0%

10

221.3

221.4

221.2

221.7

0.2

20.???

100.0%

10

0.0

0.0

0.0

0.0

0.0

21.s325913783.websitehome.co.uk

10.0%

10

223.3

223.6

222.1

225.1

1.1

在这种情况下,您会看到跳数17和18之间的损失为10%,18和19跳之间的损失为20%。您可以假设第18跳和第19跳可能会丢失一定数量的流量,因为后续的主机报告10%损失。然而,一些损失是由于速率限制,因为最终的跳数只有10%的损失。报告不同数量的损失时,请始终信任来自后期的报告。

一些损失也可以通过返回路线中的问题来解释。数据包将无错误地到达目的地,但很难做出回程。这在报告中很明显,但可能难以从 MTR 的输出中推断出来。因此,当您遇到问题时,通常最好双向收集 MTR 报告。

另外,抵制调查或报告您的连接中所有丢包发生的诱惑。互联网协议被设计为对一些网络退化具有弹性,并且数据跨 Internet 的路由可以响应于负载,简短的维护事件和其他路由问题而波动。如果您的 MTR 报告显示10%附近的少量损失,则没有任何理由引起真正的关注,因为应用层将补偿可能短暂的丢包。

4.1.4.2 了解网络延迟

MTR除了可以帮助您评估数据包丢失之外,MTR 还能帮助您评估主机与目标主机之间的连接延迟。由于物理限制,延迟总是随着路由中的跳数增加而增加。但是,增幅应该是一致和线性的。不幸的是,延迟通常是相对的,并且非常依赖于主机连接的质量和它们的物理距离。在评估可能存在问题的连接报告时,除了在给定区域内的其他主机之间的已知连接速度之外,还可以将早期的报告视为上下文。

连接质量也可能会影响特定路由的延迟时间。可以预见的是,拨号连接将比同一目的地的电缆调制解调器连接具有更高的延迟。考虑以下MTR报告显示高延迟:

mtr -r www.goole.com

HOST:PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

1.10.1.1.254

0.0%

10

0.7

1.2

0.7

5.8

1.6

2.10.1.253.22

0.0%

10

0.6

0.7

0.3

1.6

0.4

3.210.74.5.2

0.0%

10

1.6

1.1

0.8

1.6

0.2

4.10.244.246.9

0.0%

10

2.1

2.0

1.6

2.8

0.3

5.10.244.200.1

0.0%

10

1.7

2.0

1.7

2.7

0.3

6.172.18.0.149

0.0%

10

4.2

11.8

4.2

34.5

12.2

7.222.35.253.153

0.0%

10

2.1

2.5

2.0

3.2

0.4

8.61.233.9.209

0.0%

10

4.6

5.3

4.3

6.4

0.6

9.61.237.123.134

0.0%

10

37.2

35.5

33.4

37.2

1.1

10. 61.237.123.214

0.0%

10

33.6

33.5

33.1

33.7

0.2

11. prs-b4-link.telia.net

0.0%

10

218.6

217.6

217.2

218.6

0.4

12.prs-bb2-link.telia.net

0.0%

10

222.9

224.8

222.7

240.5

5.5

13.ffm-bb4-link.telia.net

0.0%

10

219.2

221.4

218.4

226.5

2.7

14.ffm-b1-link.telia.net

0.0%

10

225.6

222.3

218.1

229.8

4.5

15.1o1internet-ic-309319-ffm-b1

0.0%

10

229.2

227.5

223.5

232.9

3.1

16.ae-11.bb-c.bs.kae.de.oneando

0.0%

10

225.7

228.7

225.2

238.0

4.2

17.ae-3.bb-c.bap.rhr.de.oneando

0.0%

10

226.0

228.2

225.9

236.7

4.3

18.ae-11.gw-distp-a.bap.rhr.de.

10.0%

10

230.3

227.3

225.9

231.9

2.2

19.ae-1.gw-prtr-r231-a.bap.rhr.

10.0%

10

221.3

222.1

221.3

226.7

1.7

20. ???

100.0

10

0.0

0.0

0.0

0.0

0.0

21.s325913783.websitehome.co.uk

10.0%

10

224.9

224.8

223.2

226.5

0.9

在跳数10和11之间显示高延迟。这可能指向网络延迟有问题,因为在第11跳之后的往返时间保持较高。

从这个报告来看,不能确定延迟增加的原因,延迟增加可能是,路由器配置不对、链路拥塞或物理链路过长导致。

高延迟并不总是意味着当前路由有问题。像上面这样的报告显示,第11跳有某种问题,但流量仍然到达了目的地主机,并返回到源主机。延迟可能是由于返回路线问题引起的。

单方向MTR 报告中不会显示返回路由,且正向和反向的MTR路由有可能完全不同。

ICMP 速率限制还可以产生类似延迟的现象,类似于它可以产生类似丢包的现象。

请考虑以下示例:

mtr -r www.baidu.com

HOST: PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

1. 10.1.1.254

0.0%

10

0.7

1.3

0.7

3.7

1.0

2. 10.1.253.22

0.0%

10

0.6

0.9

0.5

2.5

0.6

3. 210.74.5.2

0.0%

10

1.1

1.0

0.8

1.5

0.2

4. 10.244.246.9

0.0%

10

1.9

2.0

1.7

2.8

0.4

5. 10.244.244.10

0.0%

10

2.9

2.8

2.4

3.5

0.4

6. 14.197.149.173

0.0%

10

2.4

2.6

2.2

3.2

0.3

7. 14.197.253.49

0.0%

10

68.7

71.8

2.9

104.7

28.4

8. 14.197.178.94

0.0%

10

3.6

3.4

3.1

4.3

0.4

9. ???

100.0

10

0.0

0.0

0.0

0.0

0.0

10. ???

100.0

10

0.0

0.0

0.0

0.0

0.0

11. ???

100.0

10

0.0

0.0

0.0

0.0

0.0

12. 220.181.112.244

0.0%

10

3.1

3.3

3.0

3.7

0.2

1. 10.1.1.254

0.0%

10

0.7

1.3

0.7

3.7

1.0

跳数6和7之间的延迟会引起关注。然而,在第7跳之后,延迟急剧下降。这里测量的实际延迟约为3.6ms。在这种情况下第7跳延迟不影响正常服务。在评估 MTR 报告时,需要考虑到最后一跳的延迟。

4.1.4.3 MTR目的主机网络配置不正确

在下一个示例中,由于配置不正确的路由器,目标主机似乎有100%的损失。乍看之下,数据包似乎没有到达主机,但情况并非如此。

mtr -r www.baidu.com

HOST: PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

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 报告显示丢失,因为目的地主机没有发送回复。

没有回复的原因可能是目标主机丢弃了ICMP数据包,丢弃ICMP数据可能的原因是不正确配置了网络或防火墙(iptables)规则的结果。

这个丢包是由于一个配置错误的主机造成的,100%丢失的跳数。从前面的报告可以看出,只有最后一跳丢包,这样的错误是很常见的。

4.1.4.4 住宅或商业路由器

通常,住宅网关使mtr报告看起来有点误导。

mtr --no-dns - google.com

HOST: PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

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%丢失而感到震惊。这并不表示有问题。你可以看到后续的跳数没有损失。

4.1.4.5 ISP路由器配置不正确

有时,您的路由器上的路由器配置错误,您的数据包可能永远不会到达目的地。请考虑以下示例:

mtr -r www.google.com

HOST: PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

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

当没有其他路线信息时会出现问号。以下报告显示相同的问题:

mtr -r www.google.com

HOST: PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

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

有时路由会以循环的形式出现,如下数据5跳6跳7跳8跳路由是一样的 。您可以在以下示例中看到:

mtr -r www.google.com

HOST: PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

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跳的路由器可能配置有误。当这种情况发生时,解决问题的唯一方法是联系网络运营商团队。

4.1.4.6 ICMP速率限制

ICMP速率限制会导致明显的丢包,如下所述,当第5跳的下一跳不持续丢包,到第5跳以后都没有丢包时,丢包可能是由ICMP限制引起的。请参阅以下示例:

mtr -r www.google.com

HOST: PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

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

在这样的情况下,可以不用担心。速率限制是一种常见的做法,它可以减少拥塞以优先考虑更重要的流量。

4.1.4.7 超时

超时可能由于各种原因而发生。一些路由器将丢弃ICMP,并且输出中没有回应将作为超时显示(???)。或者,返回路线可能有问题:

mtr -r www.google.com

HOST: PBSVVTRADER01

Loss%

Snt

Last

Avg

Best

Wrst

StDe

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(服务质量)的分组,或者可能存在导致超时的返回路由的某些问题。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • HTTPS基础知识介绍

    一 介绍 HTTPS 之前,我们先回顾一下 HTTP 协议。HTTP 超文本传输协议,它是无状态的、简单快速、基于 TCP 的可靠传输协议。既然 HTTP 协议...

    Hunter
  • 使用Flex Gateway V**将数据迁移到腾讯云

    Hunter
  • COS助力HADOOP轻松实现数据存储

    1.2 如何在hadoop集群上实现简单的数据处理,通过 wordcount 实现测试。

    Hunter
  • GitHub 上 10 款免费开源 Windows 工具

    GitHub 是如今所有开源事物的中央仓库, 这个网站最近发布了一个叫做《2016 Octoverse 状态报告》,详细列出了从去年起其一系列亮点, 包括总的...

    顶级程序员
  • 机器学习(七) ——logistic回归

    机器学习(七)——logistic回归 (原创内容,转载请注明来源,谢谢) 一、概述 1、基本概念 logistic回归(logisticre...

    用户1327360
  • WIN7中安装的VMware WS+Ubuntu10.04上网配置

    本文就不写VMware Workstation 和Ubuntu10.04的安装了。只讲解上网配置,包括使用代理上网。下面来一一说明Ubuntu10.04的上网配...

    Enjoy233
  • 科学家研究分析表明:到火星地下找生命更靠谱|黑科技

    镁客网
  • 科学家研究分析表明:到火星地下找生命更靠谱 | 黑科技

    镁客网
  • C#开发BIMFACE系列8 服务端API之获取文件上传状态信息

    在BIMFACE控制台上传文件,上传过程及结束后它会自动告诉你文件的上传状态,目前有三种状态:uploading,success,failure。即上传中、上传...

    张传宁老师
  • CodeForces 832B Petya and Exam

    B. Petya and Exam time limit per test 2 seconds memory limit per test 256 ...

    ShenduCC

扫码关注云+社区

领取腾讯云代金券