回答:
TLDR： TCPの上で複数のチャネルを多重化する際に気付くかもしれない主な欠点は（もし正しい場合）、チャネル間の行頭ブロッキングのために遅延が増加することです。
結果：待ち時間を気にしないのであれば大丈夫です。
一方、単一のTCP接続を使用することは、「他のフローと長寿命の接続との競合が少なくなり、利用可能なネットワーク容量の利用率が向上する」ことを意味します。
同じTCPストリームの上に複数のチャネルを多重化すると、チャネルでヘッドオブラインブロッキングが発生する可能性があります。
トランスポートプロトコルが順序付けされたサービスまたは半順序付けされたサービスを提供する場合、Head-of-Line Blocking（HOL）が発生する可能性があります：セグメントが失われた場合、後続のメッセージは受信キューでの再送信の成功を待たなければならず、遅延します。
TCP上で複数のストリームを多重化すると、チャネル間で HOL が発生します。
チャネルAがTCP送信バッファをいっぱいにした場合、チャネルBの新しいデータをリモートアプリケーション層に効率的に送信するには、このデータがすべて受信されるまで待機する必要があります。
参照してください「TCPの上に多重化」 TCPの上部と上のチャネルを多重化の詳細についてはhackernewsについての議論。
この典型的な例はSSHです。SSHは、（参照複数のチャネルを多重化することができるControlMaster、ControlPathとControlPersistOpenSSHの中）。これを使用すると、新しいSSHセッションを初期化するコスト（初期レイテンシ）が削減されますが、通常、1つのチャネルでの重い転送により、他のチャネルのレイテンシ/インタラクティブ性が増加します（複数のTCPストリームを使用する場合は発生しません）：インタラクティブを使用している場合セッションを開始し、同じチャネルを介して大量のファイル転送を開始すると、セッションの対話性が大幅に低下します。
HTTP / 2は、HOLブロッキングを修正するために、TCPを介した要求/応答の多重化を使用します。この機能は、HTTP / 2に関する多くの記事や論文で宣伝されています。HTTP / 2 RFCの主張：
HTTP / 1.1はリクエストのパイプライン化を追加しましたが、これはリクエストの並行性に部分的にしか対処しておらず、依然として行頭ブロッキングの影響を受けています。
[...]
結果のプロトコルは、HTTP / 1.xと比較して使用できるTCP接続が少ないため、ネットワークにより適しています。これは、他のフローとの競合が少なくなり、接続の寿命が長くなることを意味します。これにより、利用可能なネットワーク容量の利用率が向上します。
ただし、議論されていないのは、HOLブロッキングが完全に解決されないことです。HTTP / 2 over TCP は、TCPレベルのHOLブロッキングの影響を受けます）。
これは、QUICに関するこのLWNの記事で説明されています 。
HTTP / 2は、単一の接続に組み込まれた複数の「ストリーム」を使用してこの問題に対処するように設計されました。[...]新しい問題が発生します。1つのパケットが失われると、すべてのストリームの送信が一度に停止し、新しい遅延の問題が発生します。行頭ブロッキング問題のこのバリアントはTCP自体に組み込まれており、HTTPレベルでさらに調整しても修正できません。
これは、SCTP（マルチストリーミング）の際立った機能の1つです。同じSCTPアソシエーションに複数の独立したストリームを含めることができ、各ストリームは他のストリームをブロックしません。
SSHでのクロスチャネルHOLブロッキングを回避するためにSCTPを使用する効果については、SCTP経由のSSH — SCTPに適応させることによるマルチチャネルプロトコルの最適化を参照してください。
SCTPは、単一のストリーム内のメッセージの順序のみを保持して、行頭ブロッキングと呼ばれる効果を軽減します。メッセージが失われた場合、順序を維持するために、失われたメッセージが再送信されるまで、後続のメッセージを遅延させる必要があります。同じストリームのメッセージのみを遅延させる必要があるため、損失後の影響を受けるメッセージの数は減少します。
[...]
SSHのチャネルをSCTPのストリームにマッピングすることにより、マルチストリーミングの利点がSSHで利用可能になります。これは、行頭ブロッキングの緩和です。
SCTPの展開は必ずしも簡単ではありません（OSの可用性、ミドルボックスの相互作用などのため）。可能性は、ユーザー空間でUDP上 に実装することです。
別の例は、HTTP over UDPの多重化に使用される実験的なQUICプロトコルです（HTTP / 2にはHOLブロッキングが発生するため、TCPの上に複数のストリームを多重化するため）：
QUICは、TCPに比べて待ち時間を短縮する新しいトランスポートです。表面的には、QUICはUDPに実装されたTCP + TLS + HTTP / 2に非常に似ています。
[...]
行頭ブロッキングなしの多重化
GoogleのQUICプロトコル：WebをTCPからUDPに移行すると、TCP上でチャネルを多重化する際のQUICおよびHOLブロッキングの概要がわかりやすくなります。
最近のプレゼンテーションでは、HTTP over QUICはレイテンシーを改善しますが、HOLブロッキングの改善は「小さな利点」であると主張しています。
0-RTT、レイテンシー改善の50％以上
[…]
タイムアウトベースの再送信が少ないため、テールレイテンシが改善されます[…]
その他のより小さな利点、たとえば行頭ブロッキング
QUICは「UDPに実装されたTCP + TLS + HTTP / 2に非常に似ている」と説明されていますが、実際にはHTTP / 2とは独立して使用できる汎用トランスポートであり、ニーズに合う場合があります。
ZeroMQ Guideを読む必要があると思いますが、それが与える理由と欠点を備えたパターンは不可欠な読み物です。
ただし、それ以外の場合は、アプリケーションデータ配信からネットワークチャネルを切断しても問題はありません。送信されたデータパケットの多重化と分離（連続フローでのデータのストリーミングではなく、ここではパケットベースのアーキテクチャをお勧めします）と、それらの両端でのバッファリングを行う必要があります。
それ以外の場合はほとんど影響はありません。データをバッファするためにより多くのメモリが必要になる場合がありますが、パケットをロックおよび解析するためのコードを処理するためにCPUが少し必要になります。（大きなスループットとパフォーマンスを必要とする専門家を書いている場合を除きます）。
はい、私は正確にこの原則を使用してクライアントサーバーデータベースシステムを構築しました。
1つのTCP接続に多重化されたチャネルは、それぞれデータのパケットを送信し、データのパケットはもう一方の端の各受信者に分割されます。
1つの不正なチャネルによる接続の占有は、TCP接続送信者が、データを送信する準備ができているチャネルから送信するパケットをラウンドロビン選択することによって行われます。
1GBのパケットを送信することを決定し、他の全員をロックアウトする1つのチャネルのケースを処理するために、送信者はパケットをチャンクに分割し、別のチャネルに順番を与える前に1つのチャンクのみを送信することを選択できます。受信側では、受信者がパケットを見る前に、チャンクのパケットへの再組み立てが行われます。