Ping命令之TTL(转)

来源:互联网 发布:虎门巨新网络老板 编辑:程序博客网 时间:2024/06/06 06:52

转自:http://blog.sina.com.cn/s/blog_50cefbdf0100aplg.html

ping命令使用的是网络层协议ICMP,所以TTL指的是一个网络层数据包(package)的生存周期(Time to Live)

显然,一个package从一台机器到另一台机器中间需要经过很长的路径,而且这个路径不是单一的,是很复杂的,并且很可能存在环路。如果一个数据包在传输过程中进入了环路,而不终止它的话,它会一直循环下去,如果很多数据包都这样循环的话,那对于网络来说这就是灾难了,所以需要在包中设置这样一个值,包在每经过一个节点,将这个值减1,反复这样操作,最终可能造成两种结果:包在这个值还为正数的时候到达了目的地,或者是在经过一定数量的节点后,这个值减为了0。前者代表完成了一次正常的传输,后者代表包可能选择了一条非常长的路径甚至是进入了环路,这显然不是我们期望的,所以在这个值为0的时候,网络设备将不会再传递这个包而是直接将他抛弃,并发送一个通知给包的源地址,说这个包已死。

其实TTL值这个东西本身并代表不了什么,对于使用者来说,关心的问题应该是包是否到达了目的地而不是经过了几个节点后到达。

每个操作系统对TTL值得定义都不同,这个值甚至可以通过修改某些系统的网络参数来修改,例如Win2000默认为128,通过注册表也可以修改。而Linux大多定义为64。不过一般来说,很少有人会去修改自己机器的这个值的,这就给了我们机会可以通过ping的回显TTL来大体判断一台机器是什么操作系统。

以我公司2台机器为例,看如下命令

D:>Documents and Settingshx>ping 61.152.93.131

Pinging 61.152.93.131 with 32 bytes of data:

Reply from 61.152.93.131: bytes=32 time=21ms TTL=118

Reply from 61.152.93.131: bytes=32 time=19ms TTL=118

Reply from 61.152.93.131: bytes=32 time=18ms TTL=118

Reply from 61.152.93.131: bytes=32 time=22ms TTL=118

Ping statistics for 61.152.93.131:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Approximate round trip times in milli-seconds:

Minimum = 18ms, Maximum = 22ms, Average = 20ms

 

D:>Documents and Settingshx>ping 61.152.104.40

Pinging 61.152.104.40 with 32 bytes of data:

Reply from 61.152.104.40: bytes=32 time=28ms TTL=54

Reply from 61.152.104.40: bytes=32 time=18ms TTL=54

Reply from 61.152.104.40: bytes=32 time=18ms TTL=54

Reply from 61.152.104.40: bytes=32 time=13ms TTL=54

Ping statistics for 61.152.104.40:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Approximate round trip times in milli-seconds:

Minimum = 13ms, Maximum = 28ms, Average = 19ms

 

第一台TTL为118,则基本可以判断这是一台Windows机器,从我的机器到这台机器经过了11个节点,因为128-118+1=11。而第二台应该是台Linux,理由一样64-54+1=11。

了解了上面的东西,可能有人会有一些疑问,例如以下:

1,不是说包可能走很多路径吗,为什么我看到的4个包TTL都是一样的,没有出现不同?

这是由于包经过的路径是经过了一些最优选择算法来定下来的,在网络拓扑稳定一段时间后,包的路由路径也会相对稳定在一个最短路径上。具体怎么算出来的要去研究路由算法了。

2,对于上面例子第二台机器,为什么不认为它是经过了74个节点的Windows机器?因为128-74=54。

对于这个问题,我们要引入另外一个ICMP协议工具tracert。不过首先要声明的是,一个包经过74个节点这个有些恐怖Ping命令之TTL

要介绍的这个工具是tracert(Unix下为traceroute),让我们来看对上面的第二台机器用这个命令的结果

D:Documents and Settingshx>tracert 61.152.104.40

Tracing route to 61.152.104.40 over a maximum of 30 hops

1 13 ms 16 ms 9 ms 10.120.32.1

2 9 ms 9 ms 11 ms 219.233.244.105

3 12 ms 10 ms 10 ms 219.233.238.173

4 15 ms 15 ms 17 ms 219.233.238.13

5 14 ms 19 ms 19 ms 202.96.222.73

6 14 ms 17 ms 13 ms 202.96.222.121

7 14 ms 15 ms 14 ms 61.152.81.86

8 15 ms 14 ms 13 ms 61.152.87.162

9 16 ms 16 ms 28 ms 61.152.99.26

10 12 ms 13 ms 18 ms 61.152.99.94

11 14 ms 18 ms 16 ms 61.152.104.40

Trace complete.

从这个命令的结果能够看到从我的机器到服务器所走的路由,确实是11个节点,而不是128的TTL经过了70多个节点。

 

其实ping还有这样一个参数,可以无视操作系统默认TTL值而使用自己定义的值来发送ICMP Request包。

例如还是用那台Linux机器,用以下命令:

D:Documents and Settingshx>ping 61.152.104.40 -i 11

Pinging 61.152.104.40 with 32 bytes of data:

Reply from 61.152.104.40: bytes=32 time=10ms TTL=54

Reply from 61.152.104.40: bytes=32 time=13ms TTL=54

Reply from 61.152.104.40: bytes=32 time=10ms TTL=54

Reply from 61.152.104.40: bytes=32 time=13ms TTL=54

Ping statistics for 61.152.104.40:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 10ms, Maximum = 13ms, Average = 11ms

这个命令我们定义了发包的TTL为11,而前面我们知道,我到这台服务器是要经过11个节点的,所以这个输出和以前没什么不同。现在再用这个试试看:

D:Documents and Settingshx>ping 61.152.104.40 -i 10

Pinging 61.152.104.40 with 32 bytes of data:

Reply from 61.152.99.94: TTL expired in transit.

Reply from 61.152.99.94: TTL expired in transit.

Reply from 61.152.99.94: TTL expired in transit.

Reply from 61.152.99.94: TTL expired in transit.

Ping statistics for 61.152.104.40:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

可以看到,结果不一样了,我定义了TTL为10来发包,结果是TTL expired in transit.就是说在到达服务器之前这个包的生命周期就结束了。注意看这句话前面的ip,这个ip恰好是我们前面tracert结果到服务器之前的最后1个ip,包的TTL就是在这里减少到0了,根据我们前面的讨论,当TTL减为0时设备会丢弃包并发送一个TTL过期的ICMP反馈给源地址,这里的结果就是最好的证明。


0 0
原创粉丝点击