ロードバランサーは何を返しますか？
ユーザーがロードバランサーをヒットし、ロードバランサーが転送先のWebサーバーを決定すると、次に何が起こりますか？ロードバランサーはリクエストとそのすべてのデータをウェブサーバーに転送し、ウェブサーバーの応答を受信してユーザーに返しますか？
それとも、ロードバランサが選択したサーバーのIPアドレスをブラウザに返すだけで、ブラウザが特定のサーバーとの新しい接続を開かなければならないリダイレクトのようなものですか？
私の直感では、後者ではないだろうと言っています。これは、すべてのWebサーバーのIPアドレスが公開されることを意味し、セキュリティ上の理由から、ロードバランサーアドレスのみを公開するのが最善だと考えました。ただし、ロードバランサでSSL terminationを有効にすると、リダイレクトされたサーバーでSSLを再確立する必要がないので、私は正確にはわかりません。
エンドIPは公開されません。このプロセスは、実際に、クライアント（バランサーにアクセスするユーザー）が、実際のノードと通信しながらバランサーと通信していると信じる方法で機能します。
非常に簡単な説明では、ほとんどのトランザクションは次のように機能します：
- ユーザーがロードバランサーにリクエストを行います。
- バランサーは、どのノードが最適であるか（バランシングに使用している戦略に基づいて）を決定し、宛先IPを選択（変更）します。
- （ここで魔法が起こります。）ノードはリクエストを受信し、接続を受け入れ、バランサに応答します。
- バランサーは、応答IPを仮想バランサーの1つに戻し、応答をユーザーに転送します。
- ちなみに、ユーザーは実際には別の場所で処理されていたとしても、最初のリクエストのIPを含む応答を受け取ります。
パケットの書き換え（手順4でのIPアドレスの変更）は非常に重要です。これがないと、クライアントは、信頼できないIPからパケットを受信しても、応答を単に破棄します。
ラッドバランサーは、レイヤー4 OSIで動作します。ポート番号までパケットをカプセル化解除し、3つのモードのいずれかでパケットを送信します。
ロードバランサーは3つのモードで機能します。1。直接ルーティングこのモードでは、実サーバーはIPパブリックを使用します。バランサーはパケットを受信し、レイヤー4までカプセル化を解除します。ロードバランスルールが一致する場合、実サーバーの1つにパケットを（変更せずに）リダイレクトします。実サーバーにはロードバランスアドレスと同じエイリアスアドレスがあるため、実サーバーがxxx.xxx.xxx.xxxの宛先を持つパケットを受信すると、そのパケットの権利を自分のアドレス（エイリアス）に定義します。次に、クライアントへの実サーバー応答要求を直接送信します（ロードバランスを介さない）。
2。NATこのモードでは、パケットは宛先アドレスを変更して実サーバーにリダイレクトされます。宛先アドレスは実サーバーアドレス（NAT）に置き換えられます。このモードでは、実サーバーはIPパブリックを必要とせず、ローカルネットワークを使用できます。そして、パケットは新しい宛先アドレスなしで配信されます。実サーバーがパケットを受信すると、ゲートウェイ（ロードバランス）を介してクライアント要求アドレスに応答します。このモードでは、ロードバランスは実サーバーのルーターおよびゲートウェイとして使用されます。
。トンネルこのモードでは、パケットは新しいsrc-dstアドレス（vpnなど）でトンネリングされ、実サーバーにパケットを配信します。パケットが実サーバーで受信されると、実サーバーはトンネルパイプ経由でロードバランスに応答します。そして、実際のリクエストの送信元アドレスに配信応答をロードバランスします。
HTTPS/SSLの場合、ロードバランスはそれを処理せず、レイヤー4 OSIまでロードバランス処理します。上記のレイヤー5は実サーバーで処理されます。つまり、TCP 3ウェイハンシェイク、SSL/HTTPSは実サーバーで処理されます。パケットのディレクタのみをロードバランスします。
私の小さな説明が何かに役立つことを願っています。