搜索多路複用的C/C++網絡庫

我正在編寫一個應用程序，它具有在兩個實例之間並行運行的數百個並行網絡操作。由於連接的平均壽命非常短（至多秒），我認爲每次使用多個TCP連接並握手（特別是對於TLS握手）的開銷會過大。搜索多路複用的C/C++網絡庫

我開始看一對夫婦協議和庫實現複用（主要是AMQP實現比如Apache Qupid，RabbitMQ，在答案中提到，以this question）的。然而，它們都似乎運行在TCP上，這引入了一些開銷並且沒有多大意義（this post很好地解釋了這個問題，並得出了TCP多路複用是愚蠢的結論）。他們都覺得很胖，我更喜歡小而輕（ZeroMQ不幸的是不實現複用afaik）。這讓我想到了使用UDP是否是一種選擇。當然，人們必須正確地實施恢復和確認等內容，但是通過連接的多個流的知識應該比簡單地使用TCP更有效。

你認爲我上面的推理是正確的，還是我錯過了重要的事情？有沒有實現通過UDP多路複用的好的C/C++庫？

來源

2012-11-06 lucas clemente

對於高性能網絡事件處理（複用），您可以查看[libevent]（http://libevent.org/）或[libev]（http： //software.schmorp.de/pkg/libev.html）。 –

從它的外觀來看，你會用UDP的方式重新實現TCP，而我不知道如何讓它更有效率。您鏈接到的帖子並沒有真正說'TCP多路複用是愚蠢的'，更多的是存在複雜的風險（例如本地緩衝區溢出），並且這些也傾向於應用於模擬TCP。 – Kylotan

@Kylotan沒錯，但我的「重新實現」會知道多路複用流。鏈接中突出顯示的問題是多路複用流所需的ACK會觸發另一個TCP ACK（因此會增加往返）。這是不需要的開銷，不會發生在UDP上。 –

做能夠工作的最簡單的事情，使之更加複雜的僅在必要時：

使用一個TCP連接，並在其上
- 複用的邏輯會話，如果這些邏輯實體只是異步請求/響應對，例如，您可以完全免除顯式邏輯會話
，如果你在每個實例中的多個併發的組件，其真的需要自己的隊列，反推到油門過於急切的發件人：
- 首先考慮的只是加蓋在發送側突出的請求/活動會話的數量，而不是僅在需要動態改變隊列長度時才需要特定的確認
- （例如，因爲你真的試圖限制工作記憶，它通過會話而異）使用一個明確的邏輯ACK此
只有當你擊出了一些情況下你的邏輯會話真正與TCP交互嚴重，再考慮實現您擁有可靠流量控制的數據報協議

來源

2012-11-06 14:03:01 Useless

搜索多路複用的C/C++網絡庫

回答

相關問題