好吧，所以我正在爲我的網絡課程進行編程，並且必須使用UDP實現一個使用Java的Java項目。我們正在實現一個HTTP服務器和客戶端以及一個'gremlin'函數，該函數以指定的概率破壞數據包。 HTTP服務器必須在應用層將大文件分成多個段，並通過UDP發送到客戶端。客戶端必須在應用層重組收到的段。但是我想知道的是，如果UDP在定義上不可靠，爲什麼我不得不在這裏模擬不可靠性？丟失UDP數據包的機會是多少？
我的第一個想法是，也許這只是因爲我的老師認爲在我們的情況下，客戶端和服務器都將在同一臺機器上運行，並且文件將從一個進程轉移到另一個100％通過UDP，因爲它位於同一臺計算機上的兩個進程之間。
這讓我不禁要問，如果服務器和客戶端是同一臺機器上的兩個進程，並且不需要出去，UDP是否會丟失數據包，是否會損壞數據包或將數據包亂序發送實際的網絡。
我也想知道實際上丟失數據包的機會是什麼，如果數據包損壞，或者讓它們在現實中亂序發生，通常會通過互聯網在兩個地理上遙遠的主機之間。
非常感謝任何能夠幫助我解決這些問題的人。
如果UDP定義不可靠，爲什麼我不得不在這裏模擬不可靠性？
有一個受控的機制來模擬最壞的情況以及您的客戶端和服務器如何響應它們是非常有用的。教練可能會希望您證明系統的可靠性。
您也在討論有效負載有效性，而不僅僅是丟包。
這使我懷疑是否UDP，失去一個包，損壞的數據包，或提供其無序如果服務器和客戶端是在同一臺機器上的兩個進程，它是不用去超出實際網絡。
它明顯不太可能通過回送適配器，但這不是不可能的。
我也想知道，實際上失去了一個包，讓它損壞，或讓他們在現實中按順序發送的機會通常會是在互聯網上兩個地理上遙遠的主機之間。
這個問題可能需要縮小一點。應用程序級別（數據包大小和頻率）以及沿路徑上的路由器和交換機的限制/流量有幾個因素。
我找不到任何硬數字，但它似乎相當低...像5％以下。
您可能會感興趣The Internet Traffic Report以及可能的頁面，如this。
丟包發生的原因有很多。主要是由於個別鏈路和網絡擁塞的錯誤。
當鏈路正常工作時，由於鏈路上的錯誤導致的數據包丟失非常低。少於0.01％並不罕見。
擁塞造成的包丟失顯然取決於鏈路的繁忙程度。如果整個路徑上有剩餘容量，則該數字將爲0％。但是隨着網絡繁忙，這個數字會增加。當流量控制正確完成時，這個數字不會很高。一些丟失的數據包通常足以讓某些人降低傳輸速度，足以阻止因擁塞而丟失數據包。
如果數據包丟失達到1％，則出現問題。這可能是您的擁塞控制算法如何響應數據包丟失的一個錯誤。如果以相同速率發送數據包，當網絡擁塞並丟失數據包時，數據包丟失可能會更高，如果軟件行爲異常，則可能會有99％的數據包丟失。但這取決於所涉及的鏈接類型。千兆以太網使用背壓來控制流量，因此如果從源到目的地的路徑是單個千兆位以太網段，則發送應用程序可能會變慢，從不會看到實際的數據包丟失。
對於包丟失情況下的軟件測試行爲，我會建議兩種不同的模擬。
這裏的數字來源會很有用。 – 2016-10-29 15:43:43
猜測你從來沒有遇到過糟糕的互聯網連接; p UDP主要用於場景中接收者不可能響應的場景。通過衛星，無線電波傳輸數據的示例 – leppie 2013-02-25 04:45:14
而不是「接收機無法響應的地方」我會說它用於丟失數據包並不重要的場景，比如音頻/視頻流媒體，視頻會議等 – Trap 2016-07-04 13:24:19
從這裏的經驗講，我有一個項目，其中兩個程序通過UDP進行通信，並不時發生丟包，我無法想象爲什麼，他們運行在同一臺計算機上並通過迴環接口。所以是的，你必須實現你的gremlin函數是一件好事，因爲儘管可靠性很高（我沒有任何統計信息，但是我在迴環上高於99.9％甚至更高），數據包丟失仍然會發生。 – soger 2016-12-31 14:52:30