假設有一個網絡在通過它傳輸數據包時會出現大量超時錯誤。現在，超時可以發生是因爲網絡本身固有損耗（比如，硬件差），也可能是網絡是高度擁擠，由於其網絡設備丟失數據包之間，導致超時。現在，還需要哪些有關正在傳輸的流量的其他統計信息（例如丟失數據包錯誤等），這可能有助於我們確定是否由於硬件不佳或網絡負載太多而導致超時。 請注意，我們只能訪問網絡中的（從我們所傳送的數據包）一個節點，因此，我們無法瞭解負載通過網絡上的其他節點被投入。同樣，我們並沒有任何有關網絡中使用的硬件的任何信息。統計是我們所有的。有損網絡與擁塞網絡
網絡節點只有關於其本地衝突域的硬件信息，在標準網絡上它是將主機鏈接到交換機的電纜。
所有TCP堆棧將知道丟失的數據包是它沒有收到確認，因此它需要重新發送，在源和目標之間沒有設備機制（例如，交換機&）告訴源存在一個問題。
如果沒有訪問任何其他節點，確定問題是否基於負載的唯一方法是運行一個測試，在網絡上長時間發送一致的流量，如果數據包每秒鐘/分鐘/小時重試計數保持不變，那麼它會表明存在硬件問題，如果損失僅發生在高峯時段，那麼問題可能與負載有關。當然也有可能是一種情況，錯誤的硬件問題將只在高話務時段明顯，這需要東西還給這是，你需要從超越你的單節點接入網絡統計數據的主要問題。
實際上，地面網絡路徑上的幾乎所有損失都是由於擁塞或防火牆造成的。由於誤碼造成的損失極爲罕見。即使在無線網絡中，前向糾錯也能處理大多數位/媒體/傳輸錯誤。擁塞可以通過很多不同的因素造成：任何給定的網絡路徑將涉及幾十個設備的，如果他們中的任何一個變成即使是瞬間過載，數據包將被丟棄。
區分擁塞引起的數據包丟失和媒體錯誤的唯一方法是媒體錯誤將獨立於負載發生。換句話說，無論您是發送大量數據還是僅發送少量數據，丟失率都是一樣的。
爲了測試，您需要對路徑上的負載進行一些控制，或至少需要知道。既然你不用管，你有唯一的知識是從源節點的觀察，你能做的最好是採取測試樣品（使用ping最容易）全天候和整個星期，記錄丟失率和延遲。這些應該讓你知道路徑何時相對閒置。如果即使路徑（可能）空閒時丟失率仍然很高，那麼可能會出現媒體丟失問題。但是，這又是非常罕見的。
有關背景，我已經寫了關於這個問題的幾篇文章：