使用多路复用搜索 C/C++ 网络库答案

【问题标题】：Searching for C/C++ network library with multiplexing使用多路复用搜索 C/C++ 网络库
【发布时间】：2012-10-26 11:00:25
【问题描述】：

我正在编写一个应用程序，该应用程序具有在两个实例之间并行运行的多个（数百个）并发网络操作。由于连接的平均生命周期很短（最多几秒），我认为使用多个 TCP 连接和每次握手（尤其是 TLS 握手）的开销会太大。

我开始研究一些实现多路复用的协议和库（主要是AMQP 实现，如Apache Qupid、RabbitMQ，如this question 的答案中所述）。然而，它们似乎都在 TCP 上运行，这引入了一些开销并且没有多大意义（this post 很好地解释了这个问题，并得出结论 TCP 多路复用是愚蠢的）。而且他们都觉得很胖，我更喜欢小而轻的东西（ZeroMQ 不幸的是没有实现多路复用 afaik）。这让我开始思考是否可以选择使用 UDP。当然，必须正确实现恢复和 ACK 之类的东西，但要了解连接上的多个流，这应该比简单地使用 TCP 更有效。

你认为我上面的推理是正确的，还是我错过了一些重要的事情？有没有好的 C/C++ 库可以通过 UDP 实现多路复用？

【问题讨论】：

对于高性能网络事件处理（多路复用），您可以查看libevent 或libev。
从外观上看，您将根据 UDP 重新实现 TCP，我不知道您将如何提高效率。您链接到的帖子并没有真正说“TCP 多路复用是愚蠢的”，更多的是存在复杂的风险（例如本地缓冲区溢出），这些往往也适用于模拟 TCP。
@Kylotan 是的，但我的“重新实现”会知道多路复用流。链接中突出显示的一个问题是多路复用流所需的 ACK 会触发另一个 TCP ACK（因此增加了往返）。这是在 UDP 上不会发生的不必要的开销。
我要补充一点，您可以在 UDP 中根据应用程序的需要调整 ack/retry 算法，而在 TCP 中则不能（在相同程度上）。
等等，多路复用的流如何需要一个 ack 来触发另一个 ack？

标签： c++ c networking multiplexing

【解决方案1】：

做可能可行的最简单的事情，并仅在必要时使其变得更复杂：

使用单个 TCP 连接并在其上多路复用逻辑会话
- 如果这些逻辑实体只是异步请求/响应对，例如，您可以完全省去显式逻辑会话
如果您在每个实例中有多个并发组件，确实需要它们自己的队列并通过回推来限制过度急切的发送者：
- 首先考虑在发送端限制未完成请求/活动会话的数量，而不是要求特定的确认
- 仅当您需要动态改变队列长度时（例如，因为您确实试图限制工作内存，这会因会话而异）对此使用显式逻辑确认
只有在遇到逻辑会话与 TCP 交互不佳的情况时，才考虑实现自己的可靠流控制数据报协议

【讨论】：