爲什麼跟蹤路由時間有時會在跳數之間下降？

我在traceroute聯機幫助頁上看到類似的輸出，但我一直很好奇爲什麼Ping時間在跳數之間下降？也就是說，我總是期待值從跳遞增跳躍，如：爲什麼跟蹤路由時間有時會在跳數之間下降？

[yak 71]% traceroute nis.nsf.net. 
traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet 
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms 
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 
6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 
8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms 
9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms 
10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 
11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms

但是，什麼是推理：

[yak 72]% traceroute allspice.lcs.mit.edu. 
traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max 
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms 
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms 
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms 
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms 
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms 
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms 
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms 
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms 
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms 
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms 
12 * * * 
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms 
14 * * * 
15 * * * 
16 * * * 
17 * * * 
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms

爲什麼從啤酒花3時至4去從39MS到19ms？

來源

2014-10-05 Colby Blair

它們不僅僅是不同的「啤酒花」，而是完全不同的事件，在不同的時間，可能在不同的條件下。

traceroute的工作方式是，它發送TTL爲1的數據包，看看答案到達需要多長時間。該程序重複三次以解釋可能的和正常的變化（注意即使是「同一躍點」中的三個數字有時也是非常不同的，因爲它們也是完全獨立的東西）。

然後，traceroute發送一個TTL爲2（然後3和4等）的數據包，並看到一個答案到達需要多長時間。同時，第一臺路由器的負載可能會降低，因此您的數據包實際上會更快地轉發。或者，您的數據包出去的物理電纜可能並不繁忙，因爲您的室友剛剛完成了下載他的色情內容（而在您的網卡需要等待電纜閒置之前）。這是一直髮生的事情，你無法知道或控制。
有沒有辦法回到過去，所以你不能改變一個事實，就是第二個事實，你的數據包需要花費更長的時間才能完成。你在兩個不同的時間探索，所以你能得到的是一個合理的猜測。是的，一般來說，從一跳到一跳的時間應逐漸增加，但不一定。

這並不意味着往返時間是真的要跳3和4之間上下它只意味着在此期間去了，而你，你單獨試圖讓多久3周跳的估計和4跳可能需要。

來源

2014-10-06 15:33:03 Damon

真棒詳細的解釋，這就是我一直在尋找的！我通常懷疑是這樣的，但細節很好。謝謝！我希望traceroute能夠將數據包發送到第一個測試/列的每一跳，然後將數據包發送到第二列第二測試的每一跳等，這樣跳數之間的時間減少會更加明顯。這並不是說這個常用工具會改變。 – 2014-10-08 21:09:09

線之間最有可能的隨機延遲。請注意，在第二個和第三個數據包發送的跳數3-4從19ms到39ms。無論如何他們都在同一個網絡中，所以大部分延遲都是由於處理/擁塞。

雖然偶爾會看到另一種情況，即某些服務器爲ICMP消息提供更高的QoS，但表面上看起來性能更好。

來源

2014-10-06 15:18:27 fruglemonkey

奇怪 - 在我的（廣泛的）體驗中，大多數服務器/路由器給IMCP消息帶來的優先級更高。 – Alnitak 2014-10-06 15:23:42

我聽說過一個狡猾的ISP /服務器主機給予ICMP消息更高的優先級以使他們的服務更好看的情況 – fruglemonkey 2014-10-07 01:16:59

在分組交換網絡上，分組延遲不是確定性的，特別是在網絡擁塞的情況下。 traceroute測試的每一跳都是一個單獨的測試，因此變化的網絡條件很容易導致後面的測試比較近的跳躍具有更好的延遲。

也就是說，traceroute不只是發出三個數據包，然後以某種方式找出每跳的時間。它發送數據包特意設計爲n躍點後超時，並測量時間爲n增加。

來源

2014-10-06 15:27:09 Alnitak

爲什麼跟蹤路由時間有時會在跳數之間下降？

回答

相關問題