TCP/IP詳解,卷1:協議--第8章 Traceroute程序

引言

由Van Jacobson編寫的Tr a c e r o u t e程序是一個能更深刻探索T C P / I P協議的方即可用的工具。
儘管不能保證從源端發往目的端的兩份連續的 I P數據報具備相同的路由,可是大多數狀況下
是這樣的。Tr a c e r o u t e程序可讓咱們看到I P數據報從一臺主機傳到另外一臺主機所通過的路由。
Tr a c e r o u t e程序還可讓咱們使用I P源路由選項。
使用手冊上說:「程序由Steve Deering提議,由Van Jacobson實現,並由許多其餘人
根據C. Philip Wood, Tim Seaver 及Ken Adelman等人提出的使人信服的建議或補充意見
進行調試。服務器

Traceroute程序的操做

在7 . 3節中,咱們描述了 I P記錄路由選項(R R)。爲何不使用這個選項而另外開發一個
新的應用程序?有三個方面的緣由。首先,原先並非全部的路由器都支持記錄路由選項,
所以該選項在某些路徑上不能使用( Tr a c e r o u t e程序不須要中間路由器具有任何特殊的或可選
的功能)。
其次,記錄路由通常是單向的選項。發送端設置了該選項,那麼接收端不得不從收到的 I P
首部中提取出全部的信息,而後所有返回給發送端。在 7 . 3節中,咱們看到大多數P i n g服務器的
實現(內核中的I C M P回顯應答功能)把接收到的R R清單返回,可是這樣使得記錄下來的 I P地
址翻了一番(一來一回)。這樣作會受到一些限制,這一點咱們在下一段討論( Tr a c e r o u t e程序
只須要目的端運行一個U D P模塊 — 其餘不須要任何特殊的服務器應用程序)。
最後一個緣由也是最主要的緣由是, I P首部中留給選項的空間有限,不能存放當前大多
數的路徑。在I P首部選項字段中最多隻能存放 9個I P地址。在原先的A R PA N E T中這是足夠的,
可是對如今來講是遠遠不夠的。網絡

Tr a c e r o u t e程序使用I C M P報文和I P首部中的T T L字段(生存週期)。T T L字段是由發送端
初始設置一個8 bit字段。推薦的初始值由分配數字 R F C指定,當前值爲6 4。較老版本的系統
常常初始化爲1 5或3 2。咱們從第7章中的一些p i n g程序例子中能夠看出,發送 I C M P回顯應答
時常常把T T L設爲最大值2 5 5併發

發送一份 T T L字段爲1的I P數據報給
目的主機。處理這份數據報的第一個路由器將 T T L值減1,丟棄該數據報,併發回一份超時
I C M P報文。這樣就獲得了該路徑中的第一個路由器的地址。而後 Tr a c e r o u t e程序發送一份
T T L值爲2的數據報,這樣咱們就能夠獲得第二個路由器的地址。繼續這個過程直至該數據報
到達目的主機。可是目的主機哪怕接收到 T T L值爲1的I P數據報,也不會丟棄該數據報併產生
一份超時I C M P報文,這是由於數據報已經到達其最終目的地。那麼咱們該如何判斷是否已經
到達目的主機了呢?
Tr a c e r o u t e程序發送一份U D P數據報給目的主機,但它選擇一個不可能的值做爲 U D P端口
號(大於30 000),使目的主機的任何一個應用程序都不可能使用該端口。由於,當該數據報
到達時,將使目的主機的 U D P模塊產生一份「端口不可達」錯誤(見 6 . 5節)的I C M P報文。
這樣,Tr a c e r o u t e程序所要作的就是區分接收到的 I C M P報文是超時仍是端口不可達,以判斷
何時結束。
Tr a c e r o u t e程序必須能夠爲發送的數據報設置T T L字段。並不是全部與T C P / I P接口的
程序都支持這項功能,同時並不是全部的實現都支持這項能力,但目前大部分系統都支
持這項功能,並能夠運行Tr a c e r o u t e程序。這個程序界面一般要求用戶具備超級用戶權
限,這意味着它可能須要特殊的權限以在你的主機上運行該程序。工具

局域網輸出

往返時間是由發送主機的 t r a c e r o u t e程序計算的。它是指從 t r a c e r o u t e程序到該路
由器的總往返時間。若是咱們對每段路徑的時間感興趣,能夠用 T T L字段爲N + 1所打印出來的
時間減去T T L字段爲N的時間ui

有兩種不一樣的I C M P「超時」報文(見6 . 2節的圖6 - 3),它們的I C M P報文中c o d e字段不一樣。
圖8 - 2給出了這種I C M P差錯報文的格式

咱們所討論的I C M P報文是在T T L值等於0時產生的,其c o d e字段爲0。
主機在組裝分片時可能發生超時,這時,它將發送一份「組裝報文超時」的 I C M P報文
(咱們將在11 . 5節討論分片和組裝)。這種差錯報文將c o d e字段置1指針

計算出S L I P鏈路的往返時間是頗有意義的,就象咱們在 7 . 2節中所舉的P i n g例子,將鏈路
值設置爲1 2 0 0 b / s同樣。發送出的U D P數據報共4 2個字節,包括1 2字節的數據、8字節U D P首
部、2 0字節的I P首部以及(至少)2字節的S L I P幀(2 . 4節)。可是與P i n g不同的是,返回的
數據報大小是變化的。從圖 6 - 9能夠看出,返回的 I C M P報文包含發生差錯的數據報的 I P首部
以及緊隨該I P首部的8字節數據(在t r a c e r o u t e程序中,即U D P首部)。這樣,總共就是2 0調試

  • 8 + 20 + 8 + 2,即5 8字節。在數據速率爲960 b/s的狀況下,預計的RT T就是(42 + 58/960),
    即104 ms。這個值與s v r 4上所估算出來的110 ms是吻合的

關於t r a c e r o u t e程序,還有一些必須指出的事項。首先,並不能保證如今的路由也是
未來所要採用的路由,甚至兩份連續的 I P數據報均可能採用不一樣的路由。若是在運行程序時,
路由發生改變,就會觀察到這種變化,這是由於對於一個給定的 T T L,若是其路由發生變化,
t r a c e r o u t e程序將打印出新的I P地址。
第二,不能保證I C M P報文的路由與t r a c e r o u t e程序發送的U D P數據報採用同一路由。
這代表所打印出來的往返時間可能並不能真正體現數據報發出和返回的時間差(若是 U D P數
據報從信源到路由器的時間是 1秒,而I C M P報文用另外一條路由返回信源用了 3秒時間,則打印
出來的往返時間是4秒)
第三,返回的I C M P報文中的信源I P地址是U D P數據報到達的路由器接口的 I P地址。這與
I P記錄路由選項(7 . 3節)不一樣,記錄的 I P地址指的是發送接口地址。因爲每一個定義的路由器
都有2個或更多的接口,所以,從 A主機到B主機上運行t r a c e r o u t e程序和從B主機到A主機
上運行t r a c e r o u t e程序所獲得的結果多是不一樣的blog

最後,在廣域網狀況下,若是 t r a c e r o u t e程序的輸出是可讀的域名形式,而不是 I P地
址形式,那麼會更好理解一些。可是因爲 t r a c e r o u t e程序接收到I C M P報文時,它所得到的
惟一信息就是I P地址,所以,在給定 I P地址的狀況下,它作一個「反向域名查看」工做來獲
得域名。這就須要路由器或主機的管理員正確配置其反向域名查看功能(並不是全部的狀況下
都是如此)接口

IP源站選路選項

一般I P路由是動態的,即每一個路由器都要判斷數據報下面該轉發到哪一個路由器。應用程
序對此不進行控制,並且一般也並不關心路由。它採用相似 Tr a c e r o u t e程序的工具來發現
實際的路由。
源站選路(source routing)的思想是由發送者指定路由。它能夠採用如下兩種形式:
• 嚴格的源路由選擇。發送端指明 I P數據報所必須採用的確切路由。若是一個路由器發現
源路由所指定的下一個路由器不在其直接鏈接的網絡上,那麼它就返回一個「源站路
由失敗」的I C M P差錯報文。
• 寬鬆的源站選路。發送端指明瞭一個數據報通過的 I P地址清單,可是數據報在清單上指
明的任意兩個地址之間能夠經過其餘路由器ip

圖8 - 6給出了源站路由選項的格式。

這個格式與咱們在圖 7 - 3中所示的記錄路由選項格式基本一致。不一樣之處是,對於源站選
路,咱們必須在發送I P數據報前填充I P地址清單;而對於記錄路由選項,咱們須要爲 I P地址清
單分配並清空一些空間,並讓路由器填充該清單中的各項。同時,對於源站選路,只要爲所
須要的I P地址數分配空間並進行初始化,一般其數量小於 9。而對於記錄路由選項來講,必須
儘量地分配空間,以達到9個地址。
對於寬鬆的源站選路來講, c o d e字段的值是0 x 8 3;而對於嚴格的源站選路,其值爲 0 x 8 9。
l e n和p t r字段與7 . 3節中所描述的同樣。
源站路由選項的實際稱呼爲「源站及記錄路由」(對於寬鬆的源站選路和嚴格的源站選路,
分別用L S R R和S S R R表示),這是由於在數據報沿路由發送過程當中,對I P地址清單進行了更新。
下面是其運行過程:
• 發送主機從應用程序接收源站路由清單,將第 1個表項去掉(它是數據報的最終目的地
址),將剩餘的項移到1個項中(如圖8 - 6所示),並將原來的目的地址做爲清單的最後一
項。指針仍然指向清單的第1項(即,指針的值爲4)。
• 每一個處理數據報的路由器檢查其是否爲數據報的最終地址。若是不是,則正常轉發數
據報(在這種狀況下,必須指明寬鬆源站選路,不然就不能接收到該數據報)。
• 若是該路由器是最終目的,且指針不大於路徑的長度,那麼( 1)由p t r所指定的清單中的
下一個地址就是數據報的最終目的地址;(2)由外出接口(outgoing interface)相對應的I P
地址取代剛纔使用的源地址;(3)指針加4
以用下面這個例子很好地解釋上述過程。在圖 8 - 7中,咱們假設主機 S上的發送應用程
序發送一份數據報給D,指定源路由爲R1,R2和R3

在上圖中,#表示指針字段,其值分別是 四、八、1 2和1 6。長度字段恆爲1 5(三個I P地址加
上三個字節首部)。能夠看出,每一跳I P數據報中的目的地址都發生改變。
當一個應用程序接收到由信源指定路由的數據時,在發送應答時,應該讀出接收到的路
由值,並提供反向路由

Host Requirements RFC指明,T C P客戶必須能指明源站選路,同時,T C P服務器
必須可以接收源站選路,而且對於該 T C P鏈接的全部報文段都能採用反向路由。若是
T C P服務器下面接收到一個不一樣的源站選路,那麼新的源站路由將取代舊的源站路
由。

小結

在一個T C P / I P網絡中,t r a c e r o u t e程序是不可缺乏的工具。其操做很簡單:開始時發 送一個T T L字段爲1的U D P數據報,而後將 T T L字段每次加 1,以肯定路徑中的每一個路由器。 每一個路由器在丟棄 U D P數據報時都返回一個 I C M P超時報文 2,而最終目的主機則產生一個 I C M P端口不可達的報文

相關文章
相關標籤/搜索