Winsock UDP數據包被丟棄了嗎？

Question

我們在Windows中通過UDP設置建立了客戶端/服務器通信系統。 我們面臨的問題是，當吞吐量增長時，數據包會被丟棄。 我們懷疑這是由於UDP接收緩沖區不斷被輪詢導致緩沖區被阻塞並丟棄任何傳入的數據包。 是否有可能讀取此緩沖區將導致傳入的數據包被丟棄？ 如果是這樣，有什么選擇來糾正這個？ 該系統是用C語言編寫的。請告訴我這是否過於模糊，我可以嘗試提供更多信息。 謝謝！

Answer 1

Windows套接字中的默認套接字緩沖區大小為8k或8192字節。 使用setsockopt Windows函數增加緩沖區的大小（請參閱SO_RCVBUF選項）。

但除此之外，如果您沒有足夠快地讀取數據包，增加接收緩沖區的大小只會延遲數據包再次丟棄的時間。

通常，您需要兩種線程來處理這種情況。

第一個線程僅用於服務套接字。 換句話說，線程的唯一目的是從套接字讀取數據包，將其添加到某種正確同步的共享數據結構，發出已收到數據包的信號，然后讀取下一個數據包。

存在第二個線程來處理接收的數據包。 它處於空閑狀態，直到第一個線程發出信號通知已收到數據包。 然后，它從正確同步的共享數據結構中提取數據包並對其進行處理。 然后等待再次發出信號。

作為測試，嘗試短路數據包的完整處理，並在每次收到數據包時向控制台（或文件）寫入消息。 如果您可以在不丟棄數據包的情況下成功完成此操作，那么將您的功能分解為“接收”線程和“處理”線程將有所幫助。

Answer 2

是的，當緩沖區太滿時，允許堆棧 - 靜默地，甚至 - 丟棄數據包。 這是UDP性質的一部分，這是您從TCP切換時放棄的可靠性之一。 您可以通過添加重試邏輯，ACK數據包等來重新發明TCP - 或者您可以切換到SCTP之間的內容。

有一些方法可以增加堆棧的緩沖區大小，但這在很大程度上忽略了這一點。 如果你沒有足夠快地讀取以保持緩沖區空間可用，那么使緩沖區變大只會延長緩沖區空間耗盡的時間。 正確的解決方案是在您自己的代碼中創建更大的緩沖區，並將數據從堆棧的緩沖區移動到程序的緩沖區ASAP中，它可以等待任意長時間處理。

Answer 3

是否有可能讀取此緩沖區將導致傳入的數據包被丟棄？

如果數據包到達的速度比您讀取的速度快，則可以刪除數據包。

如果是這樣，有什么選擇來糾正這個？

一種選擇是更改網絡協議：使用TCP，或使用UDP實現一些確認+'流量控制'。

否則你需要明白為什么你不能快速/經常閱讀。

如果CPU 100％使用，那么您需要為每個數據包執行更少的工作或獲得更快的CPU（或者如果您還沒有使用多線程和更多CPU）。

如果CPU不是100％，那么可能正在發生的事情是：

• 你讀了一個包
• 你做了一些工作，需要x毫秒的實時，其中一些在其他I / O上被阻塞（所以CPU不忙，但它沒有被用來讀取另一個數據包）
• 在那些x毫秒期間，大量數據包到達，一些數據包被丟棄

解決這個問題的方法是改變螺紋。

另一種可能性是從套接字執行幾個同時讀取（每個讀取提供一個可以接收UDP數據包的緩沖區）。

另一種可能性是查看是否存在（O / S特定的）配置選項來增加網絡堆棧願意緩沖的接收UDP數據包的數量，直到您嘗試讀取它們為止。

Answer 4

第一步，增加接收器緩沖區大小，Windows幾乎授予所有合理大小的請求。

如果這沒有幫助，您的消費代碼似乎有一些相當慢的區域。 我會使用線程，例如使用pthreads並利用生產者消費者模式將傳入的數據報放在另一個線程的隊列中然后從那里消耗，因此你的接收調用不會阻塞，緩沖區也不會運行

第3步，修改您的應用程序級協議，允許發送方處的批處理數據包和批處理數據包，以減少發送大量小數據包的UDP報頭開銷。

第4步檢查您的網絡設備，交換機等，可以為您提供有關其流量統計，緩沖區溢出等的詳細輸出 - 如果有問題，可以獲得更快的交換機或可能切換出錯誤的交換機

...只是fyi，我正在我們的后端連續運行UDP多播流量。 ~30Mbit / sec，峰值為70Mbit / s，我的丟棄率為零

Answer 5

不確定這一點，但在Windows上，它不可能輪詢套接字並導致數據包丟失。 Windows從輪詢中單獨收集數據包，不應導致任何丟棄。

我假設您使用select（）輪詢套接字？ 據我所知，不能導致跌落。

Answer 6

由於路徑上任何地方不相關的網絡流量增加，或者完全接收緩沖區，數據包可能會丟失。 為了緩解這種情況，您可以在Winsock中增加接收緩沖區大小。

從本質上講，UDP是一種不可靠的協議，因為無法保證數據包傳輸，並且在傳遞失敗時不會向發送方返回任何錯誤。 如果您擔心數據包丟失，最好將確認數據包實施到您的通信協議中，或將其移植到更可靠的協議（如TCP）。 確實沒有任何其他真正可靠的方法來防止UDP數據包丟失。