間歇性高 ping/延遲問題
我一直在與我的 ISP（它是一個 WISP，實際上是固定寬頻無線）合作，試圖找出為什麼我會間歇性地獲得高延遲。在線上遊戲和其他流媒體應用程序中可以檢測到延遲。如果我進行跟踪路由，您可以通過回程網路看到路徑：
Tracing route to google.com [74.125.67.105] over a maximum of 30 hops: 1 1 ms 4 ms <1 ms 192.168.23.1 2 1 ms 8 ms 9 ms 10.100.100.1 3 9 ms 9 ms 3 ms 10.7.37.1 4 15 ms 24 ms 19 ms 10.7.36.1 5 10 ms 79 ms 9 ms 10.7.31.3 6 10 ms 39 ms 39 ms 10.10.5.9 7 19 ms 19 ms 19 ms 10.10.5.5 8 9 ms 19 ms 19 ms 10.10.5.1 9 341 ms 237 ms 226 ms 10.250.200.1 10 249 ms 280 ms 991 ms <ISP WAN IP> 11 703 ms 681 ms 401 ms <ISP WAN IP> 12 819 ms 628 ms 484 ms <AT&T IP> <- Traffic enters AT&T backbone 13 699 ms 528 ms 290 ms <AT&T IP> 14 201 ms 106 ms 52 ms <AT&T IP> 15 624 ms 392 ms 436 ms <AT&T IP> 16 666 ms * 252 ms <AT&T IP> 17 456 ms 403 ms 581 ms 209.85.254.120 18 430 ms 339 ms * 209.85.242.215 19 1061 ms 56 ms 53 ms 72.14.239.131 20 3514 ms 734 ms 219 ms 209.85.255.190 21 49 ms 59 ms 56 ms 74.125.67.105這似乎表明問題出在 10.250.200.1 的主機上。但是，如果我直接 ping 主機，一切似乎都很好（往返約 10 毫秒）。在可疑節點之後 ping 後續跳也可以提供合理的往返時間。高延遲一次只能持續幾秒鐘到幾分鐘。
編輯是的，這是一個顯示明確問題的跟踪的壞例子，但經過反複測試，在第 9 跳之前從來沒有延遲 > 100 毫秒，這就是我認為這可能是一個問題的原因。
事件期間的尋路會產生以下結果：
Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 192.168.23.129 0/ 100 = 0% | 1 2ms 0/ 100 = 0% 0/ 100 = 0% 192.168.23.1 0/ 100 = 0% | 2 3ms 0/ 100 = 0% 0/ 100 = 0% 10.100.100.1 0/ 100 = 0% | 3 14ms 0/ 100 = 0% 0/ 100 = 0% 10.7.37.1 0/ 100 = 0% | 4 15ms 0/ 100 = 0% 0/ 100 = 0% 10.7.36.1 0/ 100 = 0% | 5 19ms 0/ 100 = 0% 0/ 100 = 0% 10.7.31.3 0/ 100 = 0% | 6 27ms 0/ 100 = 0% 0/ 100 = 0% 10.10.5.9 0/ 100 = 0% | 7 28ms 0/ 100 = 0% 0/ 100 = 0% 10.10.5.5 0/ 100 = 0% | 8 --- 100/ 100 =100% 100/ 100 =100% 10.10.5.1 0/ 100 = 0% | 9 25ms 0/ 100 = 0% 0/ 100 = 0% 10.250.200.1 0/ 100 = 0% | 10 24ms 1/ 100 = 1% 1/ 100 = 1% <ISP WAN IP> 0/ 100 = 0% | 11 25ms 4/ 100 = 4% 4/ 100 = 4% <ISP WAN IP> 0/ 100 = 0% | 12 35ms 0/ 100 = 0% 0/ 100 = 0% <AT&T IP> 0/ 100 = 0% | 13 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP> 0/ 100 = 0% | 14 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP> 0/ 100 = 0% | 15 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP> 0/ 100 = 0% | 16 58ms 0/ 100 = 0% 0/ 100 = 0% <AT&T IP> 1/ 100 = 1% | 17 59ms 1/ 100 = 1% 0/ 100 = 0% 209.85.254.120 0/ 100 = 0% | 18 59ms 1/ 100 = 1% 0/ 100 = 0% 209.85.242.215 0/ 100 = 0% | 19 56ms 1/ 100 = 1% 0/ 100 = 0% 72.14.239.127 0/ 100 = 0% | 20 60ms 1/ 100 = 1% 0/ 100 = 0% 209.85.255.194 0/ 100 = 0% | 21 59ms 1/ 100 = 1% 0/ 100 = 0% 74.125.67.105為什麼這種延遲只在跟踪路由期間出現，而不是在正常 ping 時出現？我在我的應用程序中看到的性能不足與此不謀而合。
換句話說，當我的應用程序出現問題時，如果我同時執行跟踪，我會得到上述結果*，同時*ping 可疑主機會顯示正常 ping。
鬼魂？意思是無線ISP？如果是這樣，這就是你可能的答案。無線是不可靠的，你會看到證明。
您無法真正修復它，因為您的介質（大氣）對於傳輸數據非常糟糕。首先，因為空氣是集線器而不是交換機，因此您與周圍的任何人共享它並碰撞數據包，其次因為CSMA/CA比 CSMA/CD 慢，第三因為無線通常是半雙工而不是全雙工，並且第四，因為與銅相比，通過空氣的干擾要高幾個數量級。
$$ Microwaves, for example, operate at the same wavelength as 802.11b/g… but the microwave operates at about 500-1000 Watts vs your wireless antenna’s 100 milliwatts. Microwaves are shielded, but shielding isn’t perfect and microwaves aren’t regulated by the FCC so it’s not illegal if they cause interference. $$ 再加上您要經過 10 多個躍點才能訪問 Internet。這無濟於事，尤其是在進行任何 NAT 或防火牆的情況下。 正如@dbasnett 所說，到給定主機的traceroute ping 延遲僅指示在該時間點作為一個整體的介面之間的整個網路的狀態。這就是為什麼響應時間有時會下降的原因。它們很尖，因為網路不可靠。您
pathping看起來不錯，因為它正在執行大量查詢，而不是僅tracert執行 3 個。Sopathping向您展示網路在 325 秒（預設情況下）內正在做什麼，並向tracert您展示網路上每跳 3 個數據包正在做什麼。
10 次跟踪路由結果中有 9 次不是網路問題的指示。Traceroute 將 ICMP 回應要求數據包發送到源和目標之間的每個連續躍點，每個連續躍點將 TTL 遞增 1。每個躍點的結果是該躍點如何響應 ICMP 流量的指示，而不是通過和超出該躍點的路徑質量的指示。路由器的工作是轉發流量，因此，許多路由器都被程式為忽略、丟棄或給予低優先級的 ICMP 流量指向它們自己。躍點 14、19 和 21 具有非常好的響應時間這一事實表明該路徑沒有任何問題。如果在第 12 跳（如您所強調的）或影響路徑的任何其他跳出現問題，那麼您會在每個後續跳看到問題，並且您會看到每個跳都比以前更糟。只有當您在 traceroute 中看到這些類型的結果時，您才應該懷疑存在路徑問題。第 21 跳是目的地，響應時間為 59 毫秒，它告訴您源和目的地之間的路徑很好。分析路徑問題的關鍵是分析其在實際數據傳輸時的性能，除非您在每個躍點上都有數據包嗅探器/網路監視器並且可以訪問每個躍點上的記憶體、CPU 和吞吐量計數器，否則無法做到這一點從源到目的地的路徑中的網路節點（路由器和交換機）。只有當您在 traceroute 中看到這些類型的結果時，您才應該懷疑存在路徑問題。第 21 跳是目的地，響應時間為 59 毫秒，它告訴您源和目的地之間的路徑很好。分析路徑問題的關鍵是分析其在實際數據傳輸時的性能，除非您在每個躍點上都有數據包嗅探器/網路監視器並且可以訪問每個躍點上的記憶體、CPU 和吞吐量計數器，否則無法做到這一點從源到目的地的路徑中的網路節點（路由器和交換機）。只有當您在 traceroute 中看到這些類型的結果時，您才應該懷疑存在路徑問題。第 21 跳是目的地，響應時間為 59 毫秒，它告訴您源和目的地之間的路徑很好。分析路徑問題的關鍵是分析其在實際數據傳輸時的性能，除非您在每個躍點上都有數據包嗅探器/網路監視器並且可以訪問每個躍點上的記憶體、CPU 和吞吐量計數器，否則無法做到這一點從源到目的地的路徑中的網路節點（路由器和交換機）。
與其試圖根據路徑的跟踪來找出性能問題的原因，不如專注於源和目標之間的實際 TCP 會話，並查看響應時間（延遲）和這兩個端點之間的任何封包遺失。
Trace route，顧名思義，是一種發現兩個端點之間路徑的工具，而不是分析該路徑質量的工具。