TCPパススルーモードは、HTTPリスナーよりも優れたレイテンシパフォーマンスを提供しますか？
アプリケーションがある場合、次のようになります。
クライアント<-> ELB <-> EC2
ELBをTCPパススルーモードとして設定した場合、HTTPリスナーとして設定するよりも、E2Eレイテンシが低くなる可能性がありますか？
TCPパススルーモードが私のE2Eレイテンシを向上させる可能性があると推測する理由）このシナリオのELBは、次のシナリオよりも余分なホップコストをほとんど引き起こさないためです。
クライアント<-> EC2
私の理解は正しいですか？そうでない場合は、私に説明してください。
TCPパススルーは実際にはペイロードパススルーであるため、理解は完全ではありません。バランサーは接続を受け入れてから、インスタンスへの新しい接続を作成します、次にペイロードを接続上で前後に渡します。トラフィックは引き続き追加のデバイス（バランサー）を通過します。
リクエストがHTTPモードでカットスルーされると、動作は似ており、バイトが1つの接続から別の接続にコピーされるため、レイテンシに大きな違いはない可能性があります。
短所 of TCP=モードは、HTTPモードのクラシックELBが実行できる何かを失うことです：複数の順次要求を処理するためにインスタンスへの同じ接続を再利用しますクライアント-アイドル状態の接続をインスタンスに対して開いたままにし、より多くのクライアントリクエストが到着するのを待ちます。つまり、インスタンスに対して開始される接続が少なくなり、多くのリクエストがすでに確立されている接続を使用する可能性があります。
アプリケーションによっては、ALB（アプリケーションロードバランサー）は、インスタンス接続を再利用するだけでなく、ブラウザー側でHTTP/2をサポートし、ブラウザーがインスタンスにファンアウトされる同時リクエストを送信できるようにするという、さらなる利点を提供します。パラレルHTTP/1.1リクエストとして。
または、TCPパススルーシナリオが本当に必要な場合は、NLB-ネットワークロードバランサーが必要になる可能性があります。他の2つのバランサータイプとは異なり、NLBは実際にネットワークの動作を変更して動的なNATインスタンスへの変換-NLBは仮想エンティティであるため、トラフィックを処理する個別のシステムはありません。クラシックバランサーとアプリケーションバランサーは、実際には（誰もが知る限り）「非表示」のEC2インスタンス。