Tracert出现了timeout为什么还能正常通信?

前言

学计算机网络的时候,有一个tracert命令,进行跟踪路由的时候出现了大量timeout!这个时候就有个问题,如果通路不可达的话,那么正常通信按道理来说会无响应的啊?可事实确实相反的,因此引发了我的思考。

测试过程

tracert www.baidu.com后,经历了17跳,但是却出现了8个timeout。如果中间的timeout是断掉的,那应该不会有下一跳了啊?可是通信却能照常进行……

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
C:\Users\Feng>tracert www.baidu.com

通过最多 30 个跃点跟踪
www.a.shifen.com [39.156.66.14] 的路由:

1 3 ms 2 ms 2 ms 192.168.43.1
2 * * * 请求超时。
3 45 ms 19 ms 37 ms 172.21.0.97
4 * * * 请求超时。
5 * * * 请求超时。
6 76 ms 40 ms 37 ms 223.87.28.5
7 * * 93 ms 221.183.47.105
8 95 ms 72 ms 48 ms 221.183.37.153
9 * * * 请求超时。
10 84 ms 83 ms 55 ms 111.13.0.174
11 53 ms 73 ms 60 ms 39.156.27.5
12 52 ms 58 ms 86 ms 39.156.67.49
13 * * * 请求超时。
14 * * * 请求超时。
15 * * * 请求超时。
16 * * * 请求超时。
17 74 ms 59 ms 68 ms 39.156.66.14

跟踪完成。

tracert原理

Tracert从源主机向目的主机发送一连串的IP数据报,数据报中封装的是无法交付的UDP用户数据报。第一个数据报P1的生存时间TTL设置为1.当P1到达路径上的第一个路由器R1,路由器R1先收下它,接着把TTL值减1.由于TTL等于零了,R1就把P1丢弃了,并向源主机发送一个ICMP时间超过差错报告。

源主机接着发送第二个数据报P2,并把 TTL 设置为2。P2先到达路由器R1R1收下后把TTL减1再转发给路由器R2R2收到P2时TTL为1,但减1后TTL变为零了。R2就丢弃P2,并向源主机发送一个ICMP 时间超过差错报告报文。这样一直继续下去。当最后一个数据报刚刚到达目的主机时,数据报的TTL是1。主机不转发数据报,也不把 TTL值减1。但因IP数据报中封装的是无法交付的运输层的UDP用户数据报,因此目的主机要向源主机发送ICMP终点不可达差错报告报文。

这样,源主机达到了自己的目的,因为这些路由器和最后目的主机发来的ICMP报文正好给出了源主机想知道的路由信息——到达目的主机所经过的路由器的IP地址,以及到达其中的每一个路由器的往返时间。

这也解释了为什么tracert要比正常访问时间还要长,因为要反复发送请求和等待超时后ICMP时间超过的差错报文报告,卡的是最长时间。

Time Out原因

部分交换机等机器不支持发送ICMP差错报告,不具备回复能力,所以会造成链路不通的假象。

网络核心部分架设的路由器有的设置了不允许回复,因此不会发送ICMP时间超过差错报告,这样就会显示Time Out,但实际上链路是通的,只是人家根本不理你而已。