8.1 引言
由Van Jacobson編寫的Traceroute程序是一個能更深入探索TCP/IP協議的方便可用的工具。儘管不能保證從源端發往目的端的兩份連續的IP數據報具有相同的路由，但是大多數情況下是這樣的。Traceroute程序可以讓我們看到IP數據報從一臺主機傳到另一臺主機所經過的路由。Traceroute程序還可以讓我們使用IP源路由選項。
traceroute功能：記錄ip數據報在傳輸過程中經過的路由
8.2 Traceroute程序的操作
在7.3節中，我們描述了IP記錄路由選項（RR）。爲什麼不使用這個選項而另外開發一個新的應用程序？有三個方面的原因。首先，原先並不是所有的路由器都支持記錄路由選項，因此該選項在某些路徑上不能使用（Traceroute程序不需要中間路由器具備任何特殊的或可選的功能）。
其次，記錄路由一般是單向的選項。發送端設置了該選項，那麼接收端不得不從收到的IP首部中提取出所有的信息，然後全部返回給發送端。在7.3節中，我們看到大多數Ping服務器的實現（內核中的ICMP回顯應答功能）把接收到的RR清單返回，但是這樣使得記錄下來的IP地址翻了一番（一來一回）。這樣做會受到一些限制，這一點我們在下一段討論（Traceroute程序只需要目的端運行一個UDP模塊—其他不需要任何特殊的服務器應用程序）。
最後一個原因也是最主要的原因是，IP首部中留給選項的空間有限，不能存放當前大多數的路徑。在IP首部選項字段中最多隻能存放9個IP地址。在原先的ARPANET中這是足夠的，但是對現在來說是遠遠不夠的。
Traceroute程序使用ICMP報文和IP首部中的TTL字段（生存週期）。TTL字段是由發送端初始設置一個8bit字段。推薦的初始值由分配數字RFC指定，當前值爲64。較老版本的系統經常初始化爲15或32。我們從第7章中的一些ping程序例子中可以看出，發送ICMP回顯應答時經常把TTL設爲最大值255。
每個處理數據報的路由器都需要把TTL的值減1或減去數據報在路由器中停留的秒數。由於大多數的路由器轉發數據報的時延都小於1秒鐘，因此TTL最終成爲一個跳站的計數器，所經過的每個路由器都將其值減1。
RFC 1009[Braden and Postel 1987]指出，如果路由器轉發數據報的時延超過1秒，那麼它將把TTL值減去所消耗的時間（秒數）。但很少有路由器這麼實現。新的路由器需求文檔RFC[Almquist 1993]爲此指定它爲可選擇功能，允許把TTL看成一個跳站計數器。
TTL是 Time To Live的縮寫，該字段指定IP包被路由器丟棄之前允許通過的最大網段數量。
TTL字段的目的是防止數據報在選路時無休止地在網絡中流動。例如，當路由器癱瘓或者兩個路由器之間的連接丟失時，選路協議有時會去檢測丟失的路由並一直進行下去。在這段時間內，數據報可能在循環迴路被終止。TTL字段就是在這些循環傳遞的數據報上加上一個生存上限。
當路由器收到一份IP數據報，如果其TTL字段是0或1，則路由器不轉發該數據報（接收到這種數據報的目的主機可以將它交給應用程序，這是因爲不需要轉發該數據報。但是在通常情況下，系統不應該接收TTL字段爲0的數據報）。相反，路由器將該數據報丟棄，並給信源機發一份ICMP“超時”信息。Traceroute程序的關鍵在於包含這份ICMP信息的IP報文的信源地址是該路由器的IP地址。
我們現在可以猜想一下Traceroute程序的操作過程。它發送一份TTL字段爲1的IP數據報給目的主機。處理這份數據報的第一個路由器將TTL值減1，丟棄該數據報，併發回一份超時ICMP報文。這樣就得到了該路徑中的第一個路由器的地址。然後Traceroute程序發送一份TTL值爲2的數據報，這樣我們就可以得到第二個路由器的地址。繼續這個過程直至該數據報到達目的主機。但是目的主機哪怕接收到TTL值爲1的IP數據報，也不會丟棄該數據報併產生一份超時ICMP報文，這是因爲數據報已經到達其最終目的地。那麼我們該如何判斷是否已經到達目的主機了呢？
Traceroute程序發送一份UDP數據報給目的主機，但它選擇一個不可能的值作爲UDP端口號（大於30 000），使目的主機的任何一個應用程序都不可能使用該端口。因爲，當該數據報到達時，將使目的主機的UDP模塊產生一份“端口不可達”錯誤（見6.5節）的ICMP報文。這樣，Traceroute程序所要做的就是區分接收到的ICMP報文是超時還是端口不可達，以判斷什麼時候結束。
Traceroute程序必須可以爲發送的數據報設置TTL字段。並非所有與TCP/IP接口的程序都支持這項功能，同時並非所有的實現都支持這項能力，但目前大部分系統都支持這項功能，並可以運行Traceroute程序。這個程序界面通常要求用戶具有超級用戶權限，這意味着它可能需要特殊的權限以在你的主機上運行該程序。
traceroute原理：設置特定的TTL和不可能的udp端口號，依據TTL跳站計數器以及爲0時應該丟棄並給信源機發imcp超時報文的機制獲取路由地址
8.3 局域網輸出
現在已經做好運行Traceroute程序並觀察其輸出的準備了。我們將使用從svr4到slip，經路由器bsdi的簡單互聯網（見內封面）。bsdi和slip之間是9600 b/s的SLIP鏈路。
輸出的第1個無標號行給出了目的主機名和其IP地址，指出traceroute程序最大的TTL字段值爲30。40字節的數據報包含20字節IP首部、8字節的UDP首部和12字節的用戶數據（12字節的用戶數據包含每發一個數據報就加1的序列號，送出TTL的副本以及發送數據報的時間）。
輸出的後面兩行以TTL開始，接下來是主機或路由器名以及其IP地址。對於每個TTL值，發送3份數據報。每接收到一份ICMP報文，就計算並打印出往返時間。如果在5秒種內仍未收到3份數據報的任意一份的響應，則打印一個星號，併發送下一份數據報。在上述輸出結果中，TTL字段爲1的前3份數據報的ICMP報文分別在20 ms、10 ms和10 ms收到。TTL字段爲2的3份數據報的ICMP報文則在120 ms後收到。由於TTL字段爲2到達最終目的主機，因此程序就此停止。
往返時間是由發送主機的traceroute程序計算的。它是指從traceroute程序到該路由器的總往返時間。如果我們對每段路徑的時間感興趣，可以用TTL字段爲N+1所打印出來的時間減去TTL字段爲N的時間。
圖8-1給出了tcpdump的運行輸出結果。正如我們所預想的那樣，第1個發往bsdi的探測數據報的往返時間是20 ms、而後面兩個數據報往返時間是10 ms的原因是發生了一次ARP交換。tcpdump結果證實了確實是這種情況。
圖8-1 從svr4到slip的traceroute程序示例的tcpdump輸出結果
目的主機UDP端口號最開始設置爲33435，且每發送一個數據報加1。可以通過命令行選項來改變開始的端口號。UDP數據報包含12個字節的用戶數據，我們在前面traceroute程序輸出的40字節數據報中已經對其進行了描述。
後面tcpdump打印出了TTL字段爲1的IP數據報的註釋[ttl 1]。當TTL值爲0或1時，tcpdump打印出這條信息，以提示我們數據報中有些不太尋常之處。在這裏可以預見到TTL值爲1；而在其他一些應用程序中，它可以警告我們數據報可能無法到達其最終目的主機。我們不可能看到路由器傳送一個TTL值爲0的數據報，除非發出該數據報的該路由器已經崩潰。
因爲bsdi路由器將TTL值減到0，因此我們預計它將發回“傳送超時”的ICMP報文。即使這份被丟棄的IP報文發送往slip，路由器也會發回ICMP報文。
有兩種不同的ICMP“超時”報文（見6.2節的圖6-3），它們的ICMP報文中code字段不同。圖8-2給出了這種ICMP差錯報文的格式。
圖8-2 ICMP超時報文
我們所討論的ICMP報文是在TTL值等於0時產生的，其code字段爲0。
主機在組裝分片時可能發生超時，這時，它將發送一份“組裝報文超時”的ICMP報文（我們將在11.5節討論分片和組裝）。這種差錯報文將code字段置1。
圖8-1的第9~14行對應於TTL爲2的3份數據報。這3份報文到達最終目的主機，併產生一份ICMP端口不可達報文。
計算出SLIP鏈路的往返時間是很有意義的，就象我們在7.2節中所舉的Ping例子，將鏈路值設置爲1200b/s一樣。發送出的UDP數據報共42個字節，包括12字節的數據、8字節UDP首部、20字節的IP首部以及（至少）2字節的SLIP幀（2.4節）。但是與Ping不一樣的是，返回的數據報大小是變化的。從圖6-9可以看出，返回的ICMP報文包含發生差錯的數據報的IP首部以及緊隨該IP首部的8字節數據（在traceroute程序中，即UDP首部）。這樣，總共就是20+8+20+8+2，即58字節。在數據速率爲960 b/s的情況下，預計的RT T就是（42+58/960），即104 ms。這個值與svr4上所估算出來的110 ms是吻合的。
圖8-1中的源端口號（42804）看起來有些大。traceroute程序將其發送的UDP數據報的源端口號設置爲Unix進程號與32768之間的邏輯或值。對於在同一臺主機上多次運行traceroute程序的情況，每個進程都查看ICMP返回的UDP首部的源端口號，並且只處理那些對自己發送應答的報文。
我們所討論的ICMP報文是在TTL值等於0時產生的，其code字段爲0。
主機在組裝分片時可能發生超時，這時，它將發送一份“組裝報文超時”的ICMP報文（我們將在11.5節討論分片和組裝）。這種差錯報文將code字段置1。
圖8-1的第9~14行對應於TTL爲2的3份數據報。這3份報文到達最終目的主機，併產生一份ICMP端口不可達報文。
計算出SLIP鏈路的往返時間是很有意義的，就象我們在7.2節中所舉的Ping例子，將鏈路值設置爲1200b/s一樣。發送出的UDP數據報共42個字節，包括12字節的數據、8字節UDP首部、20字節的IP首部以及（至少）2字節的SLIP幀（2.4節）。但是與Ping不一樣的是，返回的數據報大小是變化的。從圖6-9可以看出，返回的ICMP報文包含發生差錯的數據報的IP首部以及緊隨該IP首部的8字節數據（在traceroute程序中，即UDP首部）。這樣，總共就是20+8+20+8+2，即58字節。在數據速率爲960 b/s的情況下，預計的RT T就是（42+58/960），即104 ms。這個值與svr4上所估算出來的110 ms是吻合的。
圖8-1中的源端口號（42804）看起來有些大。traceroute程序將其發送的UDP數據報的源端口號設置爲Unix進程號與32768之間的邏輯或值。對於在同一臺主機上多次運行traceroute程序的情況，每個進程都查看ICMP返回的UDP首部的源端口號，並且只處理那些對自己發送應答的報文。
關於traceroute程序，還有一些必須指出的事項。首先，並不能保證現在的路由也是將來所要採用的路由，甚至兩份連續的IP數據報都可能採用不同的路由。如果在運行程序時，路由發生改變，就會觀察到這種變化，這是因爲對於一個給定的TTL，如果其路由發生變化，traceroute程序將打印出新的IP地址。
第二，不能保證ICMP報文的路由與traceroute程序發送的UDP數據報採用同一路由。這表明所打印出來的往返時間可能並不能真正體現數據報發出和返回的時間差（如果UDP數據報從信源到路由器的時間是1秒，而ICMP報文用另一條路由返回信源用了3秒時間，則打印出來的往返時間是4秒）。
第三，返回的ICMP報文中的信源IP地址是UDP數據報到達的路由器接口的IP地址。這與IP記錄路由選項（7.3節）不同，記錄的IP地址指的是發送接口地址。由於每個定義的路由器都有2個或更多的接口，因此，從A主機到B主機上運行traceroute程序和從B主機到A主機上運行traceroute程序所得到的結果可能是不同的。事實上，如果我們從slip主機到svr4上運行traceroute程序，其輸出結果變成了：
這次打印出來的bsdi主機的IP地址是140.252.13.66，對應於SLIP接口；而上次的地址是140.252.13.35，是以太網接口地址。由於traceroute程序同時也打印出與IP地址相關的主機名，因而主機名也可能變化（在我們的例子中，bsdi上的兩個接口都採用相同的名字）。
考慮圖8-3的情況。它給出了兩個局域網通過一個路由器相連的情況。兩個路由器通過一個點對點的鏈路相連。如果我們在左邊LAN的一個主機上運行traceroute程序，那麼它將發現路由器的IP地址爲if1和if3。但在另一種情況下，就會發現打印出來的IP地址爲if4和if2。if2和if3有着同樣的網絡號，而另兩個接口則有着不同的網絡號。
圖8-3 traceroute程序打印出的接口標識
最後，在廣域網情況下，如果traceroute程序的輸出是可讀的域名形式，而不是IP地址形式，那麼會更好理解一些。但是由於traceroute程序接收到ICMP報文時，它所獲得的唯一信息就是IP地址，因此，在給定IP地址的情況下，它做一個“反向域名查看”工作來獲得域名。這就需要路由器或主機的管理員正確配置其反向域名查看功能（並非所有的情況下都是如此）。我們將在14.5節描述如何使用DNS將一個IP地址轉換成域名。
總結：其實就是traceroute在局域網中的現實應用以及詳細解釋，並對其缺陷進行了補充說明
8.4 廣域網輸出
前面所給出的小互聯網的輸出例子對於查看協議運行過程來說是足夠了，但對於像全球互聯網這樣的大互聯網來說，應用traceroute程序就需要一些更爲實際的東西。圖8-4是從sun主機到NIC(Network Information Center)的情況。
圖8-4 從sun主機到nic.ddn.mil的traceroute程序
由於運行的這個例子包含文本，非DDN站點（如，非軍方站點）的NIC已經從nic.ddn.mil轉移到rs.internic.net，即新的“InterNIC”。
一旦數據報離開tuc.noao.edu網，它們就進入了telcom.arizona.edu網絡。然後這些數據報進入NASA Science Internet，nsn.nasa.gov。TTL字段爲6和7的路由器位於JPL(Jet Propulsion Laboratory)上。TTL字段爲11所輸出的sura.net網絡位於Southeastern Universities Research Association Network上。TTL字段爲12的域名GSI是Government Systems,Inc.,NIC的運營者。
TTL字段爲6的第2個RTT（590）幾乎是其他兩個RT T值（234和262）的兩倍。它表明IP路由的動態變化。在發送主機和這個路由器之間發生了使該數據報速度變慢的事件。同樣，我們不能區分是發出的數據報還是返回的ICMP差錯報文被攔截。
TTL字段爲3的第1個RT T探測值（204）比TTL字段爲2的第1個探測值（233）值還小。由於每個打印出來的RT T值是從發送主機到路由器的總時間，因此這種情況是可能發生的。
圖8-5的例子是從sun主機到作者出版商之間的運行例子。
圖8-5 從sun.tuc.noao.edu主機到aw.com的traceroute程序
在這個例子中，數據報離開telcom.arizona.edu網絡後就進行了地區性的網絡westnet.net(TTL字段值爲6和7)。然後進行了由Advanced Network & Services運營的NSFNET主幹網，t3.ans.net，（T3是對於主幹網採用的45 Mb/s電話線的一般縮寫。）最後的網絡是alter.net，即aw.com與互聯網的連接點。
總結：traceroute廣域網的例子。。。
8.5 IP源站選路選項
通常IP路由是動態的，即每個路由器都要判斷數據報下面該轉發到哪個路由器。應用程序對此不進行控制，而且通常也並不關心路由。它採用類似Traceroute程序的工具來發現實際的路由。
源站選路(source routing)的思想是由發送者指定路由。它可以採用以下兩種形式：
- 嚴格的源路由選擇。發送端指明IP數據報所必須採用的確切路由。如果一個路由器發現源路由所指定的下一個路由器不在其直接連接的網絡上，那麼它就返回一個“源站路由失敗”的ICMP差錯報文。
- 寬鬆的源站選路。發送端指明瞭一個數據報經過的IP地址清單，但是數據報在清單上指明的任意兩個地址之間可以通過其他路由器。
Traceroute程序提供了一個查看源站選路的方法，我們可以在選項中指明源站路由，然後檢查其運行情況。
一些公開的Traceroute程序源代碼包中包含指明寬鬆的源站選路的補丁。但是在標準版中通常並不包含此項。這些補丁的解釋是“Van Jacobson的原始Traceroute程序（1988年春）支持該特性，但後來因爲有人提出會使網關崩潰而將此功能去除。”對於本章中所給出的例子，作者將這些補丁安裝上去，並將它們設置成允許寬鬆的源站選路和嚴格的源站選路。
圖8-6給出了源站路由選項的格式。
圖8-6 IP首部源站路由選項的通用格式
這個格式與我們在圖7-3中所示的記錄路由選項格式基本一致。不同之處是，對於源站選路，我們必須在發送IP數據報前填充IP地址清單；而對於記錄路由選項，我們需要爲IP地址清單分配並清空一些空間，並讓路由器填充該清單中的各項。同時，對於源站選路，只要爲所需要的IP地址數分配空間並進行初始化，通常其數量小於9。而對於記錄路由選項來說，必須儘可能地分配空間，以達到9個地址。
對於寬鬆的源站選路來說，code字段的值是0x83；而對於嚴格的源站選路，其值爲0x89。len和ptr字段與7.3節中所描述的一樣。
源站路由選項的實際稱呼爲“源站及記錄路由”（對於寬鬆的源站選路和嚴格的源站選路，分別用LSRR和SSRR表示），這是因爲在數據報沿路由發送過程中，對IP地址清單進行了更新。下面是其運行過程：
- 發送主機從應用程序接收源站路由清單，將第1個表項去掉（它是數據報的最終目的地址），將剩餘的項移到1個項中（如圖8-6所示），並將原來的目的地址作爲清單的最後一項。指針仍然指向清單的第1項（即，指針的值爲4）。
- 每個處理數據報的路由器檢查其是否爲數據報的最終地址。如果不是，則正常轉發數據報（在這種情況下，必須指明寬鬆源站選路，否則就不能接收到該數據報）。
- 如果該路由器是最終目的，且指針不大於路徑的長度，那麼(1)由ptr所指定的清單中的下一個地址就是數據報的最終目的地址；(2)由外出接口(outgoing interface)相對應的IP地址取代剛纔使用的源地址；(3)指針加4。
可以用下面這個例子很好地解釋上述過程。在圖8-7中，我們假設主機S上的發送應用程序發送一份數據報給D，指定源路由爲R1，R2和R3。
圖8-7 IP源路由示例
在上圖中，#表示指針字段，其值分別是4、8、12和16。長度字段恆爲15（三個IP地址加上三個字節首部）。可以看出，每一跳IP數據報中的目的地址都發生改變。
當一個應用程序接收到由信源指定路由的數據時，在發送應答時，應該讀出接收到的路由值，並提供反向路由。
Host Requirements RFC指明，TCP客戶必須能指明源站選路，同時，TCP服務器必須能夠接收源站選路，並且對於該TCP連接的所有報文段都能採用反向路由。如果TCP服務器下面接收到一個不同的源站選路，那麼新的源站路由將取代舊的源站路由。
8.5.1 寬鬆的源站選路的 traceroute 程序示例
使用traceroute程序的-g選項，可以爲寬鬆的源站選路指明一些中間路由器。採用該選項可以最多指定8箇中間路由器（其個數是8而不是9的原因是，所使用的編程接口要求最後的表目是目的主機）。
在圖8-4中，去往NIC，即nic.ddn.mil的路由經過NASA Science Internet。在圖8-8中，我們通過指定路由器enss142.UT.westnet.net(192.31.39.21)作爲中間路由器來強制數據報通過NSFNET：
圖8-8 採用寬鬆源站選路通過NSFNET到達nic.ddn.mil的traceroute程序
在這種情況下，看起來路徑中共有16跳，其平均RT T大約是350 ms。而圖8-4的通常選路則只有13跳，其平均RTT約爲322 ms。默認路徑看起來更好一些（在建立路徑時，還需要考慮其他的一些因素。其中一些必須考慮的因素是所包含網絡的組織及政治因素）。
前面我們說看起來有16跳，這是因爲將其輸出結果與前面的通過NSFNET（圖8-5）的示例比較，發現在本例採用寬鬆源路由，選擇了3個路由器（這可能是因爲路由器對源站選路數據報產生ICMP超時差錯報文上存在一些差錯）。在netb和butch路由器之間的gateway.tuc.noao.edu路由器丟失了，同時，位於Gabby和enss142.UT.west.net之間的Westgate.Telcom.Arizona.edu和uu-ua.AZ.westnet.net兩個路由器也丟失了。在這些丟失的路由器上可能發生了與接收到寬鬆的源站選路選項數據報有關的程序問題。實際上，當採用NSFNET時，信源和NIC之間的路徑有19跳。本章習題8.5繼續對這些丟失路由器進行討論。
同時本例也指出了另一個問題。在命令行，我們必須指定路由器enss142.UT.westnet.net的點分十進制IP地址，而不能以其域名代替。這是因爲，反向域名解析（14.5節中描述的通過IP地址返回域名）將域名與IP地址相關聯，但是前向解析（即給出域名返回IP地址）則無法做到。在DNS中，前向映射和反向映射是兩個獨立的文件，而並非所有的管理者都同時擁有這兩個文件。因此，在一個方向是工作正常而另一個方向卻失敗的情況並不少見。
還有一種以前沒有碰到過的情況是在TTL字段爲8的情況下，對於第一個RT T，打印一個星號。這表明，發生超時，在5秒內未收到本次探查的應答信號。
將本圖與圖8-4相比較，還可以得出一個結論，即路由器nsn-FIX-pe.sura.net同時與NSFNET和NASA Science Internet相連。
8.5.2 嚴格的源站選路的 traceroute 程序示例
在作者的traceroute程序版本中，-G選項與前面所描述的-g選項是完全一樣的，不過此時是嚴格的源站選路而不是寬鬆的源站選路。我們可以採用這個選項來觀察在指明無效的嚴格的源站選路時其結果會是什麼樣的。從圖8-5可以看出來，從作者的子網發往NSFNET的數據報的正常路由器順序是netb，gateway，butch和gabby（爲了便於查看，後面所有的輸出結果中，均省略了域名後綴.tuc.noao.edu和.telcom.arizona.edu）。我們指定了一個嚴格源路由，使其試圖將數據報從gateway直接發送到gabby，而省略了butch。我們可以猜測到其結果會是失敗的，正如圖8-9所給出的結果。
圖8-9 採用嚴格源站路由失敗的traceroute程序
這裏的關鍵是在於TTL字段爲3的輸出行中，RT T後面的!S。這表明traceroute程序接收到ICMP“源站路由失敗”的差錯報文：即圖6-3中type字段爲3，而code字段爲5。TTL字段爲3的第二個RT T位置的星號表示未收到這次探查的應答信號。這與我們所猜想的一樣，gateway不可能直接發送數據報給gabby，這是因爲它們之間沒有直接的連接。
TTL字段爲2和3的結果都來自於gateway，對於TTL字段爲2的應答來自gateway，是因爲gateway接收到TTL字段爲1的數據報。在它查看到（無效的）嚴格的源站選路之前，就發現TTL已過期，因此發送回ICMP超時報文。TTL字段等於3的行，在進入gateway時其TTL字段爲2，因此，它查看嚴格的源站選路，發現它是無效的，因此發送回ICMP源站選路失敗的差錯報文。
圖8-10給出了與本例相對應的tcpdump輸出結果。該輸出結果是在sun和netb之間的SLIP鏈路上遇到的。我們必須在tcpdump中指定-v選項以顯示出源站路由信息。這樣，會輸出一些像數據報ID這樣我們並不需要的結果，我們在給出結果中將這些不需要的結果刪除掉。同樣，用SSRR表示“嚴格的源站及記錄路由”。
首先注意到，sun所發送的每個UDP數據報的目的地址都是netb，而不是目的主機(westgate)。這一點可以用圖8-7的例子來解釋。類似地，-G選項所指定的另外兩個路由器（gateway和gabby）以及最終目(westgate)成爲第一跳的SSRR選項。
從這個輸出結果中，還可以看出，traceroute程序所採用的定時時間（第15行和16行之間的時間差）是5秒。
圖8-10 失敗的嚴格源站選路traceroute程序的tcpdump輸出結果
8.5.3 寬鬆的源站選路traceroute程序的往返路由
我們在前面已經說過，從A到B的路徑並不一定與從B到A的路徑完全一樣。除非同時在兩個系統中登錄並在每個終端上運行traceroute程序，否則很難發現兩條路徑是否不同。但是，採用寬鬆的源站選路，就可以決定兩個方向上的路徑。
這裏的竅門就在於指定一個寬鬆的源站路由，該路由的目的端和寬鬆路徑一樣，但發送端爲目的主機。例如，在sun主機上，我們可以查看到發往以及來自bruno.cs.colorado.edu的結果如圖8-11所示。
發出路徑（TTL字段爲1~11）的結果與返回路徑（TTL字段爲11~21）不同，這很好地說明了在Internet上，選路可能是不對稱的。
該輸出同時還說明了我們在圖8-3中所討論的問題。比較TTL字段爲2和19的輸出結果：它們都是路由器gateway.tuc.noao.edu，但兩個IP地址卻是不同的。由於traceroute程序以進入接口作爲其標識，而我們從兩條不同的方向經過該路由器，一條是發出路徑（TTL字段爲2），另一條是返回路徑（TTL字段爲19），因此可以猜想到這個結果。通過比較TTL字段爲3和18、4和17的結果，可以看到同樣的結果。
圖8-11 顯示非對稱路徑的traceroute程序
總結：大體介紹了寬鬆路由選擇和嚴格路由選擇的概念，並作了相關演示。
8.6 小結
在一個TCP/IP網絡中，traceroute程序是不可缺少的工具。其操作很簡單：開始時發送一個TTL字段爲1的UDP數據報，然後將TTL字段每次加1，以確定路徑中的每個路由器。每個路由器在丟棄UDP數據報時都返回一個ICMP超時報文2，而最終目的主機則產生一個ICMP端口不可達的報文。
我們給出了在LAN和WA N上運行traceroute程序的例子，並用它來考察IP源站選路。我們用寬鬆的源站選路來檢測發往目的主機的路由是否與從目的主機返回的路由一樣。