Tracert 工作原理[通俗易懂]

Tracert 工作原理
通過向目標發送不同 IP 生存時間 (TTL) 值的“Internet 控制消息協議 (ICMP)”回
應數據包，Tracert 診斷程序確定到目標所采取的路由。要求路徑上的每個路由器在
轉發數據包之前至少將數據包上的 TTL 遞減 1。數據包上的 TTL 減為 0 時，路由器
應該將“ICMP 已超時”的消息發回源系統。

Tracert 先發送 TTL 為 1 的回應數據包，并在隨后的每次發送過程將 TTL 遞增 1，
直到目標響應或 TTL 達到最大值，從而確定路由。通過檢查中間路由器發回的“ICM
P 已超時”的消息確定路由。某些路由器不經詢問直接丟棄 TTL 過期的數據包，這在
Tracert 實用程序中看不到。

Tracert 命令按順序打印出返回“ICMP 已超時”消息的路徑中的近端路由器接口列表
。如果使用 -d 選項，則 Tracert 實用程序不在每個 IP 地址上查詢 DNS。

在下例中，數據包必須通過兩個路由器（10.0.0.1 和 192.168.0.1）才能到達主機
172.16.0.99。主機的默認網關是 10.0.0.1，192.168.0.0 網絡上的路由器的 IP 地
址是 192.168.0.1。

C:\\>tracert 172.16.0.99 -d
Tracing route to 172.16.0.99 over a maximum of 30 hops
1 2s 3s 2s 10,0.0,1
2 75 ms 83 ms 88 ms 192.168.0.1
3 73 ms 79 ms 93 ms 172.16.0.99
Trace complete.
用 tracert 解決問題
可以使用 tracert 命令確定數據包在網絡上的停止位置。下例中，默認網關確定 19
2.168.10.99 主機沒有有效路徑。這可能是路由器配置的問題，或者是 192.168.10.
0 網絡不存在（錯誤的 IP 地址）。

C:\\>tracert 192.168.10.99

Tracing route to 192.168.10.99 over a maximum of 30 hops

1 10.0.0.1 reports:Destination net unreachable.

Trace complete.

Tracert 實用程序對于解決大網絡問題非常有用，此時可以采取幾條路徑到達同一個
點。

Tracert 命令行選項
Tracert 命令支持多種選項，如下表所示。

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

選項 描述
-d 指定不將 IP 地址解析到主機名稱。
-h maximum_hops 指定躍點數以跟蹤到稱為 target_name 的主機的路由。
-j host-list 指定 Tracert 實用程序數據包所采用路徑中的路由器接口列表。
-w timeout 等待 timeout 為每次回復所指定的毫秒數。
target_name 目標主機的名稱或 IP 地址。

詳細信息，請參閱使用 tracert 命令跟蹤路徑。

使用 pathping 測試路由器
pathping 命令是一個路由跟蹤工具，它將 ping 和 tracert 命令的功能和這兩個工
具所不提供的其他信息結合起來。pathping 命令在一段時間內將數據包發送到到達最
終目標的路徑上的每個路由器，然后基于數據包的計算機結果從每個躍點返回。由于
命令顯示數據包在任何給定路由器或鏈接上丟失的程度，因此可以很容易地確定可能
導致網絡問題的路由器或鏈接。某些選項是可用的，如下表所示。

選項 名稱 功能
-n Hostnames 不將地址解析成主機名。
-h Maximum hops 搜索目標的最大躍點數。
-g Host-list 沿著路由列表釋放源路由。
-p Period 在 ping 之間等待的毫秒數。
-q Num_queries 每個躍點的查詢數。
-w Time-out 為每次回復所等待的毫秒數。
-T Layer 2 tag 將第 2 層優先級標記（例如，對于 IEEE 802.1p）連接到數據包并
將它發送到路徑中的每個網絡設備。這有助于標識沒有正確配置第 2 層優先級的網絡
設備。-T 開關用于測試服務質量 (QoS) 連通性。
-R RSVP test Che檢查以確定路徑中的每個路由器是否支持“資源保留協議 (RSVP)”
，此協議允許主機為數據流保留一定量的帶寬。 -R 開關用于測試服務質量 (QoS) 連
通性。

默認的躍點數是 30，并且超時前的默認等待時間是 3 秒。默認時間是 250 毫秒，并
且沿著路徑對每個路由器進行查詢的次數是 100。

以下是典型的 pathping 報告。躍點列表后所編輯的統計信息表明在每個獨立路由器
上數據包丟失的情況。

D:\\>pathping -n msw

Tracing route to msw [7.54.1.196]
over a maximum of 30 hops:
0 172.16.87.35
1 172.16.87.218
2 192.68.52.1
3 192.68.80.1
4 7.54.247.14
5 7.54.1.196

Computing statistics for 125 seconds…
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 172.16.87.35
0/ 100 = 0% │
1 41ms 0/ 100 = 0% 0/ 100 = 0% 172.16.87.218
13/ 100 = 13% │
2 22ms 16/ 100 = 16% 3/ 100 = 3% 192.68.52.1
0/ 100 = 0% │
3 24ms 13/ 100 = 13% 0/ 100 = 0% 192.68.80.1
0/ 100 = 0% │
4 21ms 14/ 100 = 14% 1/ 100 = 1% 10.54.247.14
0/ 100 = 0% │
5 24ms 13/ 100 = 13% 0/ 100 = 0% 10.54.1.196

Trace complete.

當運行 pathping 時，在測試問題時首先查看路由的結果。此路徑與 tracert 命令所
顯示的路徑相同。然后 pathping 命令對下一個 125 毫秒顯示忙消息（此時間根據躍
點計數變化）。在此期間，pathping 從以前列出的所有路由器和它們之間的鏈接之間
收集信息。在此期間結束時，它顯示測試結果。

最右邊的兩欄 This Node/Link Lost/Sent=Pct 和 Address 包含的信息最有用。172
.16.87.218（躍點 1）和 192.68.52.1（躍點 2）丟失 13% 的數據包。 所有其他鏈
接工作正常。在躍點 2 和 4 中的路由器也丟失尋址到它們的數據包（如 This Node
/Link 欄中所示），但是該丟失不會影響轉發的路徑。

對鏈接顯示的丟失率（在最右邊的欄中標記為 │）表明沿路徑轉發丟失的數據包。該
丟失表明鏈接阻塞。對路由器顯示的丟失率（通過最右邊欄中的 IP 地址顯示）表明
這些路由器的 CPU 可能超負荷運行。這些阻塞的路由器可能也是端對端問題的一個因
素，尤其是在軟件路由器轉發數據包時。

轉載于:https://blog.51cto.com/nianyi/1303721