這是我第一次進入UDP套接字編程。在不瞭解程序的細節的情況下，服務器基本上向客戶端發送n組設置大小的消息。我編寫並運行了代碼，看起來好像我的所有消息都按照服務器發送的順序到達客戶端。這有意義嗎？這是我的理解，使用UDP，發送的數據包並不總是交付，並不總是以相同的順序交付。如果是這樣，那麼客戶端程序爲什麼會以相同的順序接收所有服務器消息，並且從不丟失任何消息？我嘗試了不同的消息編號（例如發送200或500條消息）和不同的消息大小。我沒有使用線程或類似的東西。只需要爲服務器設置一個循環，逐個發送數據包，客戶端只需等待一個無限循環即可接收數據包。來自更有經驗的人的洞察將非常有幫助！Java UDP編程
UDP不是保證要交付或按順序。這並不意味着它不會，尤其是在您假設您的客戶端和服務器位於同一臺計算機上（或同一本地網絡上）的情況下。
這主要取決於您的操作系統緩衝區，並且UDP不保證按順序發送/接收，因此我認爲您的順序發送數據是主要原因。
UDP對可靠傳遞不作任何保證。
這與保證交付不可靠是不一樣的。
嘗試在不同大洲的同行，看看丟包/重排/重複是什麼樣的。 （我很好奇）
那麼UDP的事情是它通常工作得很好，並且與TCP相比，它具有真正的低延遲。這可能是在幾乎每一個網絡遊戲爲什麼它在幾乎所有的VoIP應用使用，實時視頻等原因（見RTP，RFC 3550）等
然而，有一個陷阱:-)
UDP不保證任何內容。因此，這意味着，UDP客戶端應用程序需要進行很多可怕的事情，包括
要準備對於實時通信應用程序，RTP是爲了解決這些問題而開發的（請參閱RTP）。除此之外 - 爲了獲得對通信線路的更多控制，還開發了RTCP（RFC 3605）。
但是，沒有人會阻止你滾動自己的協議，以確保使用UDP作爲傳輸層時的行爲。
底線是，當使用UDP時，你將不得不付出更多的努力到客戶端智能，以獲得正確的事情，而不是使用有狀態的傳輸協議。
它在VoIP中使用的原因是在該域（和其他域）中的及時性要比在TCP中保證每個數據包的順序傳遞要重要得多。 – EJP
僅僅因爲你*可以*丟失數據包並不意味着你這樣做。嘗試儘可能快地發送幾百萬個數據包，然後測量是否丟失任何數據包。重新排序通常發生在路由器上，特別是如果它確實對數據包進行負載平衡的話。 – nos