通過丟失保護來加速基於UDP的文件傳輸？

Question

我正在嘗試學習UDP，並制作一個簡單的文件傳輸服務器和客戶端。 我知道TCP可能會更好，因為它內置了一些可靠性。但是我想自己實現一些基本的可靠性代碼。

我決定嘗試確定何時丟失數據包，然后重新發送。

我實現的是一個系統，其中服務器將以10字節塊的形式向客戶端發送特定文件。 發送每個塊后，它等待確認。 如果在幾秒鍾內沒有收到一個，它將再次發送該塊。

我的問題是如何快速完成這樣的文件傳輸？ 如果您發送文件，並且假設他們有25％的機會丟失數據包，那么將有大量時間等待ACK。

有辦法解決嗎？ 還是接受丟包率高的狀態需要很長時間？ 確認的可接受超時值是多少？

謝謝！

Answer 1

您的帖子中有很多問題，我會嘗試解決。 最主要的是進行基准測試並找到瓶頸。 什么是最慢的操作？

現在，我可以告訴您，您的方法中的瓶頸在於等待每個塊之后的ACK。 您要確認序列而不是確認塊。 第二大問題是可笑的小塊。 在這種大小下，開銷要比實際數據多（查找IP和UDP的標頭大小）。

結論：

我實現的是一個系統，其中服務器將以10字節塊的形式向客戶端發送特定文件。

您可能想嘗試幾百個字節的塊。

發送每個塊后，它等待確認。

在需要確認之前發送更多的塊，並標記它們。 有多種方法：

• 而不是確認塊，而是確認數據：“我已經收到5000字節”（TCP，傳統）
• 在一條消息中確認多個塊。 “我收到了塊1、5、7、9”（帶有SACK的TCP）

Answer 2

您已實現的是Stop-and-wait ARQ 。 在高延遲網絡中，它不可避免地會比其他一些更復雜的選項慢，因為它會在每次傳輸時等待一個完整的周期。

有關其他可能性，請參見“ 滑動窗口”，然后單擊其他變量的鏈接。 您得到的基本上是窗口大小為1的退化形式的滑動窗口。

正如其他答案所指出的，這將涉及在您的數據包中添加序列號，在等待確認時發送其他數據包以及以更復雜的模式進行重傳。

如果這樣做，實際上是在重新發明TCP，TCP使用這些策略來提供可靠的連接。

Answer 3

您需要某種類型的數據包編號，以便客戶端可以通過接收到的數據包序列中的丟失編號來檢測丟失的數據包。 然后，客戶端可以請求重新發送它知道丟失的數據包。

例：

服務器將數據包1,2,3,4,5發送到客戶端。 客戶收到1,4,5，因此知道丟失了2和3。 因此，客戶端確認1,4和5，並重新發送2和3的請求。

然后，您仍然需要弄清楚如何處理ack /重發請求等。在任何情況下，為數據包分配一個連續的數字序列，以便序列中的“空白”可以檢測到數據包丟失，這是一種不錯的解決方法這個問題。

Answer 4

您的問題恰好描述了TCP試圖解決的問題之一。 TCP的答案特別優雅，簡潔，imo，因此閱讀TCP的英語描述可能會有所幫助。

只是為了讓您對現實世界中的UDP有個大致了解：SNMP是一種網絡管理協議，旨在通過UDP運行。 從未明確確認管理器發送到受管節點的SNMP請求（大約1500個有效負載字節），並且運行良好。 25％的數據包丟失是一個巨大的數字-現實生活中的數據包丟失在最壞的情況下要差一個數量級-而且，在這種損壞的環境中，SNMP幾乎無法工作。 當然，操作網絡管理系統（NMS）的人會很快通過電話獲得網絡硬件支持。

當我們使用SNMP時，我們通常會理解超時值是三到四秒，這意味着受管網絡節點中的SNMP代理可能會在該時間內完成其工作。

高溫超導

Answer 5

看一下TFTP協議 。 它是基於UDP的文件傳輸協議，具有內置的確認/重新發送規定。