2

2つのインスタンス間で並行して実行される多数（数百）の同時ネットワーク操作を持つアプリケーションを作成しています。接続の平均存続期間は非常に短いため（多くても数秒）、多くのTCP接続を使用して毎回ハンドシェイクを実行する（特にTLSハンドシェイクの場合）オーバーヘッドが大きすぎると思いました。

私は、多重化を実装するいくつかのプロトコルとライブラリを調べ始めました（この質問への回答で述べたように、主にApache Qupid、RabbitMQなどのAMQP実装）。ただし、それらはすべてTCP上で実行されているように見えるため、オーバーヘッドが発生し、あまり意味がありません（この投稿では、問題を十分に説明し、TCP多重化は愚かであるという結論に達しました）。また、それらはすべてかなり太っていると感じます、私は小さくて軽いものが好きです（ZeroMQ残念ながら、多重化afaikは実装されていません）。それで、UDPを使用することが選択肢になるかどうかを考えました。もちろん、リカバリやACKなどを適切に実装する必要がありますが、接続を介した複数のストリームに関する知識があれば、単にTCPを使用するよりもはるかに効率的です。

上記の私の推論は正しいと思いますか、それとも私は何か重要なことを見逃しましたか？UDPを介した多重化を実装する優れたC/C ++ライブラリはありますか？

4

1 に答える 1

5

おそらく機能する可能性のある最も単純なことを行い、必要な場合にのみそれをより複雑にします。

  1. 単一のTCP接続を使用し、その上で論理セッションを多重化します

    • たとえば、これらの論理エンティティが単なる非同期の要求/応答ペアである場合、明示的な論理セッションを完全に省くことができる場合があります

  2. 各インスタンスに複数の同時コンポーネントがあり、熱心な送信者を抑制するためにプッシュバックを備えた独自のキューが本当に必要な場合：

    • 最初に、特定のackを要求するのではなく、送信側で未処理のリクエスト/アクティブセッションの数を制限することを検討してください
    • キューの長さを動的に変更する必要がある場合にのみ（たとえば、セッションによって異なる作業メモリーを実際に制限しようとしているため）、これに明示的な論理ACKを使用します。

  3. 論理セッションが実際にTCPとうまく相互作用しない場合にのみ、独自の信頼できるフロー制御データグラムプロトコルの実装を検討してください。

于 2012-11-06T14:03:01.533 に答える