2

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

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

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

4

1 回答 1

5

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

  1. 使用单个 TCP 连接并在其上多路复用逻辑会话

    • 例如，如果这些逻辑实体只是异步请求/响应对，您可以完全省去显式逻辑会话

  2. 如果您在每个实例中都有多个并发组件，这些组件确实需要它们自己的队列并通过回推来限制过度急切的发送者：

    • 首先考虑限制发送端的未完成请求/活动会话的数量，而不是要求特定的 ack
    • 仅当您需要动态改变队列长度时（例如，因为您确实试图限制工作内存，这因会话而异）为此使用显式逻辑确认

  3. 仅当您遇到逻辑会话与 TCP 交互不佳的情况时，才考虑实现自己的可靠流控制数据报协议

于 2012-11-06T14:03:01.533 回答