在工作生活中，如果幹點跟網絡沾邊的活，可能都會用到tracert，tracert是windows操作系統上用於追蹤到達目標地址路由的一個小工具，同樣的軟件在linux上也有，只不過是traceroute，原理相似，可能tracert就是根據traceroute開發的，細節上有些不同而已。
Tracert屬於icmp協議，通過使用它可以輕而易舉的找出ip地址在網路上的路徑，判斷IP地址經過了哪些設備，找出哪些設備延遲過高，從而發現網絡中存在的問題。比如，我們經常接到反饋說，訪問某個網站特別慢，那到底是什麼慢呢，其實就是我們到達服務器的延時較高，從而導致數據傳輸過慢，網頁加載也就更慢了。
一、Tracert原理
要弄清tracert的原理什麼，就得首先簡單瞭解下ICMP和IP包頭字段中的TTL。
ICMP全稱Internet控制報文協議，作爲TCP/IP的一個子協議，常用來在IP傳輸中用來指出網絡不通、主機是否可達、路由是否可用等。例如常見的ping應用，當主機A測試能否到達主機B時，由主機A發送imcp request（type:8,code0），當主機B收到這個數據包時，主機B發送給主機A一個icmp replay（type:0,code0）。這時，主機A將收到的信息回顯傳輸給上層應用。
TTL是IP包頭的一個字段，用於表示該數據包在網絡裏存活了多久，一般根據系統不同，初始的TTL值也不盡相同。例如在windows 10裏，TTL一般設置爲64。IP採用這個機制主要是爲了防環，數據包每經過一個設備，TTL都會減一，也就是說，該數據包在網絡裏最多能有64跳，當然已經這足夠用了。當TTL被最終減到1或0時，接收設備就不會再次轉發該數據包，而是丟棄，然後給發送該數據包的源主機發送一個icmp Time-to-live exceeded（type:11,code:0）報文，也就是告訴源主機:“你的數據包死掉啦，重傳還是改變ttl你自己看着辦吧!”
Tracert就巧妙的運用了以上兩種技術，實現了對路徑的識別。Tracert選取icmp協議（linux下traceroute使用udp協議，高端口號），當我的PC Tracert一個IP地址時，pc向目的ip發送一份icmp request（type:8,code0）報文，但是tracert程序會把該數據報的ttl設置1。什麼，那不就發送不出去了嗎？是的，tracert本來也沒想直接就能送達到目的主機，他要的是什麼？他要的是差錯報文消息！
這樣一來，第一跳設備就會給源主機回覆一個icmp Time-to-liveexceeded（type:11,code:0）告訴源主機，你的ttl超時啦！tracert記錄下時間，再重複兩次該過程，如此以來，tracert就完成了第一跳信息的收集。接下來，tracert會把第二個數據報ttl設置爲2，第三個數據報ttl設置爲3，依次類推，直到某個數據報收到icmp replay（type:0,code0）,連續收到3次後，最終認爲tracert已經完成。
二、tracert抓包分析
接下來我們看看數據包收發過程是否像我說的那樣。
ttl=1,ttl=2,ttl=3……我們可以看到每個數據包都發送了3次，而每次都收到了icmp Time-to-live exceeded 消息。
但是也有沒有收到icmp Time-to-liveexceeded 消息的，這將被tracert認爲是未收到迴應，將顯示*號，請求超時。
當成功收到來自119.75.217.109的icmp replay時，則認爲追蹤完成。
三、Tracert排障應用
原理我們懂了，如何排除故障就簡單了。根據案例分析，我們到達目的地址119.75.217.109總共經歷了8跳，但是有人要問了，爲什麼8跳延遲沒什麼規律呢？其實，延遲除了由線路轉發設備決定，也受回包設備的性能影響。現在的網絡設備都是控制層面和轉發層面分離，控制層面可以理解爲一個小電腦，轉發層面由控制層面進行控制，但是控制層面出問題短時間不一定會影響轉發層面轉發。有點繞對不？
一般設備上的cpu主頻比較低，再加上還要處理一些路由協議之類的信息，所以有可能回覆的就慢一些，因爲icmp協議處理的優先級比較低。所以一般而已，負載高的設備回覆ping延遲高一些，負載低的設備回覆ping延遲低一些。
所以，但只是根據延遲判斷網絡問題是不靠譜的。
如圖所示，延遲到了16跳的時候，直接增加了200ms左右，而且後面的設備迴應都大於200ms了，也就是說這一跳的設備要不是帶寬負載過高，要不就是有限制。當然根據ip地址分析了下，15-16跳估計到國際出口了，帶寬不足正常現象。但是如果假設這些延遲增高現象是發生在你自己的網絡裏的話，那你可就得小心了。