学部在学中に、Linux 用の POSIX ソケットを使用するネットワーク プログラミング コースを受講することにしました。参考資料として、TCP/IP を使用した Internetworking (comer と stevens) という本を使用しました。2008年はかなり時代遅れで、まだ適用可能なテキストであり、いくつかのサーバー設計を経ています.
この本であまり取り上げられていない設計の 1 つは、クライアントがバックエンド アプリケーション サーバーに接続し、単一の TCP 接続を介して複数の要求をサーバーに送信する場合です。複数のリクエストがスレーブソケットを介してサーバーに送信され、応答が同じスレーブソケットを介して送信されるためです。スレーブ ソケットは、応答と要求が同じソケットを介して受信されると輻輳します。全二重通信速度を可能にするために、エンドポイントとエンドポイント間の 2 番目の TCP 接続を許可する方が良いオプションでしょうか? サーバーのパフォーマンスを向上させるために使用できる他のアーキテクチャは何ですか?
ソケットは単にパケットに付けられた番号 (ルーティング番号またはアドレスと呼びます) であるため、ソケット自体が混雑することは想像できません。
ソケットを処理するコードは可能ですが、パケットが到着したときに配布することで非常に簡単に修正できるはずです。
着信パケットと発信パケットの処理を異なるスレッドで実行するようにコーディングしたり、多数のスレッドに分散するためにパケットをキューに入れることもできます。
しかし、元の仮定が完全に正確であるとは思えません。私は間違っているかもしれません...
TCP 接続はすでに全二重です。(単純化すると) TCP 接続は単方向接続のペア (1 つの送信と 1 つの受信) と考えることができます。
単一の接続を介して複数のリクエストを送信することは、実際にはいくつかのプロトコルでパフォーマンスを向上させるために使用されます (接続を再利用すると、ハンドシェイクとスロースタートのオーバーヘッドが回避されるため)。一例として、HTTP キープアライブ接続があります。パフォーマンスを向上させるもう 1 つの方法は、パイプライン処理 (応答を待たずに複数の要求を送信すること) を使用することです。これは明らかに、複数の要求に対して TCP 接続を再利用している場合にのみ実行できます。