Minimum = 13ms， Maximum = 28ms， Average = 19ms  
第一臺(tái)TTL為118，則基本可以判斷這是一臺(tái)Windows機(jī)器，從我的機(jī)器到這臺(tái)機(jī)器經(jīng)過了10個(gè)節(jié)點(diǎn)，因?yàn)?28-118=10。而第二臺(tái)應(yīng)該是臺(tái)Linux，理由一樣64-54=10。  
了解了上面的東西，可能有人會(huì)有一些疑問，例如以下：  

1，不是說包可能走很多路徑嗎，為什么我看到的4個(gè)包TTL都是一樣的，沒有出現(xiàn)不同？  

這是由于包經(jīng)過的路徑是經(jīng)過了一些最優(yōu)選擇算法來定下來的，在網(wǎng)絡(luò)拓?fù)浞€(wěn)定一段時(shí)間后，包的路由路徑也會(huì)相對(duì)穩(wěn)定在一個(gè)最短路徑上。具體怎么算出來的要去研究路由算法了，不在討論之列。  

2，對(duì)于上面例子第二臺(tái)機(jī)器，為什么不認(rèn)為它是經(jīng)過了74個(gè)節(jié)點(diǎn)的Windows機(jī)器？因?yàn)?28-74=54。  

對(duì)于這個(gè)問題，我們要引入另外一個(gè)很好的ICMP協(xié)議工具。不過首先要聲明的是，一個(gè)包經(jīng)過74個(gè)節(jié)點(diǎn)這個(gè)有些恐怖，這樣的路徑還是不用為好。  

要介紹的這個(gè)工具是tracert（*nix下為traceroute），讓我們來看對(duì)上面的第二臺(tái)機(jī)器用這個(gè)命令的結(jié)果  
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.  

從這個(gè)命令的結(jié)果能夠看到從我的機(jī)器到服務(wù)器所走的路由，確實(shí)是11個(gè)節(jié)點(diǎn)（上面說10個(gè)好像是我犯了忘了算0的錯(cuò)誤了，應(yīng)該是64-54+1，嘿嘿），而不是128的TTL經(jīng)過了70多個(gè)節(jié)點(diǎn)。  
既然已經(jīng)說到這里了，不妨順便說說關(guān)于這兩個(gè)ICMP命令的高級(jí)一點(diǎn)的東西。  
首先是ping命令，其實(shí)ping有這樣一個(gè)參數(shù)，可以無視操作系統(tǒng)默認(rèn)TTL值而使用自己定義的值來發(fā)送ICMP Request包。  
例如還是用那臺(tái)Linux機(jī)器，用以下命令：  
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  

D:Documents and Settingshx>  
這個(gè)命令我們定義了發(fā)包的TTL為11，而前面我們知道，我到這臺(tái)服務(wù)器是要經(jīng)過11個(gè)節(jié)點(diǎn)的，所以這個(gè)輸出和以前沒什么不同。現(xiàn)在再用這個(gè)試試看：  
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  

D:Documents and Settingshx>  

可以看到，結(jié)果不一樣了，我定義了TTL為10來發(fā)包，結(jié)果是TTL expired in transit.就是說在到達(dá)服務(wù)器之前這個(gè)包的生命周期就結(jié)束了。注意看這句話前面的ip，這個(gè)ip恰好是我們前面tracert結(jié)果到服務(wù)器之前的最后1個(gè)ip，包的TTL就是在這里減少到0了，根據(jù)我們前面的討論，當(dāng)TTL減為0時(shí)設(shè)備會(huì)丟棄包并發(fā)送一個(gè)TTL過期的ICMP反饋給源地址，這里的結(jié)果就是最好的證明。  
通過這里再次又證明了從我機(jī)器到服務(wù)器是經(jīng)過了11個(gè)節(jié)點(diǎn)而不是70多個(gè)，呵呵。  
最后再鞏固一下知識(shí)，有人可能覺得tracer這個(gè)命令很神奇，可以發(fā)現(xiàn)一個(gè)包所經(jīng)過的路由路徑。其實(shí)這個(gè)命令的原理就在我們上面的討論中。  

想象一下，如果我給目的服務(wù)器發(fā)送一個(gè)TTL為1的包，結(jié)果會(huì)怎樣？  
根據(jù)前面的討論，在包港出發(fā)的第一個(gè)節(jié)點(diǎn)，TTL就會(huì)減少為0，這時(shí)這個(gè)節(jié)點(diǎn)就會(huì)回應(yīng)TTL失效的反饋，這個(gè)回應(yīng)包含了設(shè)備本身的ip地址，這樣我們就得到了路由路徑的第一個(gè)節(jié)點(diǎn)的地址。  
因此，我們繼續(xù)發(fā)送TTL=2的包，也就受到第二個(gè)節(jié)點(diǎn)的TTL失效回應(yīng)  

依次類推，我們一個(gè)一個(gè)的發(fā)現(xiàn)，當(dāng)最終返回的結(jié)果不是TTL失效而是ICMP Response的時(shí)候，我們的tracert也就結(jié)束了，就是這么簡(jiǎn)單。  

順便補(bǔ)一句ping命令還有個(gè)-n的參數(shù)指定要發(fā)包的數(shù)量，指定了這個(gè)數(shù)字就會(huì)按照你的要求來發(fā)包了而不是默認(rèn)的4個(gè)包。如果使用-t參數(shù)的話，命令會(huì)一直發(fā)包直到你強(qiáng)行中止它。

最新評(píng)論