引言
由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的時間
有兩種不同的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程式所得到的結果可能是不同的
最后，在廣域網情況下，如果 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地址清單，但是資料報在清單上指
明的任意兩個地址之間可以通過其他路由器
圖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
在上圖中，#表示指標欄位，其值分別是 4、8、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埠不可達的報文
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/91895.html
標籤：其他
上一篇：adb server version (xx) doesn't match this client (xx); killing...