從圖中還可以看出，數據包目標端口號從33435開始并且每次加1，traceroute能夠通過UDP數據包遞增的目標端口號來唯一識別返回的包。
如圖，第11跳的61.51.113.202路由只返回了一個ICMP超時通知，與終端顯示的信息相符。
如圖，TTL=34時，ICMP數據包中Type=3(Destination unreachable)，Code=3(Port unreachable)，說明目的地址向源地址發(fā)送了端口不可達通知(ICMP Port Unreachable)，表示數據包到達目的地址。
(2)Linux
traceroute www.baidu.com 。
Linux系統(tǒng)下的抓包解析與Mac OS類似。
2. Windows——tracert
tracert www.baidu.com 。
如圖，第一跳為10.8.160.1，第二跳為10.0.14.1，第三跳為10.0.4.41;每條記錄輸出3個延時結果，說明源地址每次默認發(fā)送三個數據包;在第6條記錄只有2個延時結果，說明源地址只收到了2個ICMP超時通知消息;數據包從源地址經過15跳之后到達目的地址。
如圖，源地址10.8.169.32向目的地址220.181.111.188發(fā)送ICMP請求回顯(ICMP Echo Request)數據包，每跳默認發(fā)送3個，TTL設置為1;數據包遇到路由器之后，被丟棄，返回Time tolive exceeded超時通知，解析出路由器IP地址10.8.160.1。源地址再發(fā)數據包，設置TTL=2，從而解析出第二跳路由10.0.14.1和10.0.14.5。同理，解析出第三跳路由10.0.4.41。與終端顯示的信息相符。
從圖中還可以看出，數據包從seq=142開始每次加1，tracert能夠通過seq來唯一識別返回的包。
如圖，seq=157的數據包沒有得到路由器172.16.7.1的超時通知消息，因此第6跳只有兩個延時結果，與終端顯示的信息相符。
如圖，TTL=15時，源地址收到了目的地址的ICMP回應答復(ICMP Echo Reply)，說明源地址經過了15跳到達目的地址，與終端顯示信息相符。
五、The Great Cannon案例
2015年3月26日開始，因某些眾所周知的原因，GitHub遭到其網站歷史上最大規(guī)模DDoS攻擊。 瑞典網絡安全公司 Netresec 通過查看數據包中的 TTL 值斷定這是一起中間人攻擊事件。在此過程中，他們借助了路由追蹤程序 traceroute/tracert 的實現(xiàn)原理。首先 建立一個正常的連接，確保數據包能夠到達目標機器。然后依次發(fā)送TTL值為1,2,3…的HTTP請求。若數據包沒有到達中間人設備，則不會出現(xiàn)HTTP響應;若數據包到達中間人設備，則會出現(xiàn)HTTP響應，然后只需在出現(xiàn)HTTP響應時，查看請求數據包設置初始TTL值即可。
安全人員根據下圖發(fā)現(xiàn)中間人設備潛伏在11和12跳之間。Web請求中 TTL 值為11的時候數據包沒有響應，而TTL值為12的時候，返回了正常響應。
六、小結
Traceroute/tracert路由追蹤程序是用來追蹤數據包到達網絡主機所經過的路由信息的重要工具，雖然路由追蹤效果一致，但實現(xiàn)原理略有不同：前者借助 UDP 協(xié)議，后者借助 ICMP 協(xié)議。此外，利用 TTL 追蹤攻擊主機的位置，也為我們提供了新的思路。