在7.3節中，我們描述了IP記錄路由選項（RR）。為什么不使用這個選項而另外開發一個新的應用程序？有三個方面的原因。首先，原先并不是所有的路由器都支持記錄路由選項，因此該選項在某些路徑上不能使用（Traceroute程序不需要中間路由器具備任何特殊的或可選的功能）。 其次，記錄路由一般是單向的選項。發送端設置了該選項，那么接收端不得不從收到的IP首部中提取出所有的信息，然后全部返回給發送端。在7.3節中，我們看到大多數Ping服務器的實現（內核中的ICMP回顯應答功能）把接收到的RR清單返回，但是這樣使得記錄下來的IP地址翻了一番（一來一回）。這樣做會受到一些限制，這一點我們在下一段討論（Traceroute程序只需要目的端運行一個UDP模塊—其他不需要任何特殊的服務器應用程序）。 最后一個原因也是最主要的原因是，IP首部中留給選項的空間有限，不能存放當前大多數的路徑。在IP首部選項字段中最多只能存放9個IP地址。在原先的ARPANET中這是足夠的，但是對現在來說是遠遠不夠的。 Traceroute程序使用ICMP報文和IP首部中的TTL字段（生存周期）。TTL字段是由發送端初始設置一個8 bit字段。推薦的初始值由分配數字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字段的目的是防止數據報在選路時無休止地在網絡中流動。例如，當路由器癱瘓或者兩個路由器之間的連接丟失時，選路協議有時會去檢測丟失的路由并一直進行下去。在這段時間內，數據報可能在循環回路被終止。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端口號（大于30000），使目的主機的任何一個應用程序都不可能使用該端口。因為，當該數據報到達時，將使目的主機的UDP模塊產生一份“端口不可達”錯誤（見6.5節）的ICMP報文。 這樣，Traceroute程序所要做的就是區分接收到的ICMP報文是超時還是端口不可達，以判斷什么時候結束。 Traceroute程序必須可以為發送的數據報設置TTL字段。并非所有與TCP/IP接口的程序都支持這項功能，同時并非所有的實現都支持這項能力，但目前大部分系統都支持這項功能，并可以運行Traceroute程序。這個程序界面通常要求用戶具有超級用戶權限，這意味著它可能需要特殊的權限以在你的主機上運行該程序。