每個udp數據包有多個或單個請求？

Question

我正在開發自己的UDP協議（在Linux下），用於緩存應用（類似於memcached），它只對對象執行INSERT/READ/UPDATE/DELETE操作，我不確定哪種設計最好：

1. 每包發送一個請求。 （客戶端準備請求並立即將其發送到服務器）
2. 每個數據包發送多個請求。 （客戶端將包中的請求排入隊列中，並且當它滿了時（接近MTU大小）將它發送到服務器）

請求的大小（即記錄數據）可以從32字節到1400字節，我不知道它會是平均值，它完全取決於用戶的應用程序。

1. 如果選擇每個數據包的單個請求，我將不得不管理很多小包，並且內核會被中斷很多次。這會降低操作速度，因爲從用戶空間切換到系統時，內核必須保存寄存器。此外，如果用戶的應用程序發送32字節的許多請求（udp的數據包開銷約爲28字節），網絡流量將增加一倍，並且我將對傳輸速度產生很大影響，所以數據傳輸將會有開銷。然而，高網絡流量不一定意味着低性能，因爲NIC具有其自己的處理器並且不會使CPU停滯。如果出現網絡瓶頸，可以安裝額外的網卡。 使用單個數據包的一大優點是服務器和客戶端將如此簡單，以便我能夠節省指令並提高速度，同時我的bug也會減少，並且項目將盡早完成。

2. 如果我使用每個數據包多個請求，我將有更少但更大的數據包，因此可以通過網絡傳輸更多的數據。我將減少系統調用的數量，但服務器的複雜性需要更多的內存和更多的指令來執行，所以我們不知道如果以這種方式更快地執行它。可能會發生CPU將成爲瓶頸，但添加CPU或網卡的更便宜嗎？

應用程序應該有很重的數據加載，比如最新的CPU每秒100,000個請求。我不知道該怎麼做。我正在考慮尋求「每個數據包的單個請求」，但是在我重寫所有我已經爲多個請求處理編寫的代碼之前，我想問一些建議。

在此先感謝。

Answer 1

你更關心什麼：延遲或帶寬？

• 如果是延遲，儘快發送請求，即使這意味着數據包末端和整個數據包更多的「鬆弛」。
• 如果帶寬捆綁多個請求，以消除「鬆弛」併發送更少的數據包整體。

注：網絡，而不是CPU，可能會在兩種情況下你的主要瓶頸，除非你正在運行在一個非常快速的網絡。即使你這樣做，數據庫中的INSERT/READ/UPDATE/DELETE可能花費的CPU和I/O也比數據包所需的CPU工作更多。

Answer 2

另一種折衷的每個數據包發送多個請求是

• ，一方面，UDP的不可靠的性質可能導致您的時間下降的多個請求，從而使重傳更加昂貴。
• 在另一方面，內核將使用更少的緩衝區來實現你的數據，減少數據的可能性降到

然而，分析是不完整的部署體系結構的理解，如緩衝區NIC，交換機和路由器的大小以及其他網絡硬件。

但建議是用相對簡單的實現（每包單個請求）啓動，但以這樣的方式編寫的代碼，這樣就不會太困難，如果需要增加更多的複雜性。