Answers:
TLDR：在TCP上多路复用多个通道时（如果操作正确），您可能会注意到的主要缺点是由于通道之间的行头阻塞而导致延迟增加。
结论：如果您不关心延迟，那应该没问题。
另一方面，使用单个TCP连接“意味着与其他流的竞争更少，连接寿命更长，从而可以更好地利用可用网络容量”。
如果您在同一TCP流的顶部多路复用多个通道，则这些通道可能会遭受行头阻塞：
当传输协议提供有序或部分有序服务时，可能会发生行头阻塞（HOL）：如果段丢失，则后续消息必须等待接收器队列中的成功重传，从而被延迟。
在TCP上多路复用多个流时，会在通道之间出现 HOL 。
如果通道A已填满TCP发送缓冲区，则必须等待接收到所有这些数据，然后才能将通道B的任何新数据有效地传输到远程应用程序层。
请参阅“ TCP上的多路复用”以获取有关TCP上的多路复用通道和hackernews讨论的更多详细信息。
SSH就是一个典型的例子。SSH可以复用多个信道（见ControlMaster，ControlPath和ControlPersistOpenSSH中）。使用此功能可减少初始化新SSH会话的成本（初始延迟），但在一个通道上进行大量传输通常会增加其他通道的延迟/交互（如果您使用多个TCP流，则不会发生）：会话并开始尝试通过同一频道进行繁重的文件传输，您的会话将开始变得缺乏互动性。
HTTP / 2使用TCP上的请求/响应的多路复用以修复HOL阻塞。在许多有关HTTP / 2的文章和论文中都宣传了此功能。的HTTP / 2 RFC权利要求：
HTTP / 1.1添加了请求流水线处理，但这仅部分解决了请求并发问题，并且仍然受到行头阻塞的困扰。
[...]
生成的协议对网络更友好，因为与HTTP / 1.x相比，可以使用更少的TCP连接。这意味着与其他流量的竞争减少，连接寿命更长，进而可以更好地利用可用网络容量。
但是，没有讨论的是HOL阻塞没有完全解决。HTTP / 2通过TCP仍然遭受从）TCP级HOL阻塞。
在有关QUIC的LWN文章中对此进行了讨论 ：
HTTP / 2旨在使用单个连接中内置的多个“流”来解决此问题。它带来了一个新问题：单个数据包的丢失将立即停止所有流的传输，从而产生新的延迟问题。此行头阻塞问题的变体内置于TCP本身，无法通过在HTTP级别进行更多调整来解决。
这是SCTP（多数据流）的独特功能之一，您可以在同一个SCTP关联中拥有多个独立的数据流，并且每个数据流都不会阻塞其他数据流。
有关使用SCTP以避免SSH中跨通道HOL阻塞的效果，请参阅SSH over SCTP －通过使其适应SCTP来优化多通道协议：
SCTP仅保留单个流中消息的顺序，以减轻称为行首阻塞的影响。如果丢失了一条消息，则必须延迟随后的消息，直到重新发送丢失的消息以保留顺序为止。由于仅必须延迟同一流的消息，因此减少了丢失后受影响消息的数量。
[...]
通过将SSH的通道映射到SCTP的流上，可以使SSH获得多流传输的好处，这可以减轻行首阻塞的影响。
SCTP不一定易于部署（由于OS可用性，中间盒交互等）。一种可能性是在用户空间中通过UDP 实现它。
另一个示例是用于在UDP上多路复用HTTP 的实验性QUIC协议（因为HTTP / 2确实遭受HOL阻塞，因此在TCP之上多路复用多个流）：
QUIC是一种新的传输方式，与TCP相比，它可以减少延迟。从表面上看，QUIC与在UDP上实现的TCP + TLS + HTTP / 2非常相似。
[...]
多路复用，无线路阻塞
Google的QUIC协议：在TCP上多路复用通道时，将网络从TCP迁移到UDP可以很好地概述QUIC和HOL阻止。
最近的一份演讲声称，HTTP over QUIC可以改善延迟，但是HOL阻止的改进是“较小的好处”：
0-RTT，超过50％的延迟改善
[…]
更少的基于超时的重传改善了尾部等待时间[…]
其他较小的好处，例如生产线阻塞
请注意，虽然QUIC被描述为“非常类似于在UDP上实现的TCP + TLS + HTTP / 2”，但它实际上是一种通用传输方式，可以独立于HTTP / 2使用，并且可能满足您的需求。
注意：HTTP / QUIC将被标准化为HTTP / 3。