ソフトウェアまたはハードウェアのロード バランサーがどのように機能するかについては、まったくわかりません。ハードウェア ロード バランサーは基本的にスイッチであり、何らかのアルゴリズムに基づいて、着信要求に対してどのノードに切り替えるかを決定すると思います。ソフトウェア ロード バランサーのフロントでは、ソフトウェアがノードを選択し、リバース プロキシ接続を使用していると思います。このようなシナリオでは、ロード バランサーがクライアントの秘密鍵を持つことができないため、双方向 SSL は機能しません。
繰り返しますが、ソフトウェア ロード バランサーがどのように機能するかはわかりませんが、私のアプリケーションにはロード バランサーが必要であり、アプリケーションは双方向 SSL 接続を使用するため、ソフトウェア ロード バランサーが双方向 SSL をどのように処理するのか知りたいと思いました。繋がり。
いいえ、SSL はロード バランサーで動作します。それらは通常 TCP レベルで動作するため、クライアントは LB IP アドレスに接続しますが、実サーバーへの接続は NAT します。接続はその存続期間中同じ実サーバーに持続しますが、同じクライアントが別のサーバーを作成した場合、別のサーバーに接続できます (通常は接続します)。
HTTPS の場合、これは正常に機能しますが、SSL セッション キャッシングをサポートする Web サーバーがある場合、クライアントが別のサーバーに戻ると SSL セッション キャッシュが失われます。実際には、これは大きな問題ではありません。もちろん、HTTP キープアライブ セッションは単一の TCP 接続であるため影響を受けず、同じ実サーバーにとどまります。
一般的に言えば、ソフトウェア ロード バランサーは、新しい着信接続要求があることを認識し、使用可能なマシンのワークロードを評価して、新しい要求を最も適切なマシンに割り当てます。セッションベースのサービスがある場合、その接続はセッションの間持続します。リバランスはサーバーがダウンした場合にのみ発生し、おそらく新しくバランスのとれた構成で新しい接続を確立します。
したがって、Jon が示唆したように、SSL セッションはサーバーで確立され、セッションが終了するまでそのサーバーで続行されます。
接続をより動的にルーティングする場合は、別のサーバーに要求を動的に送信するソフトウェアの前で SSL セッションを終了 (復号化) する必要がある場合があります。
これらはすべて可能ですが、必ずしも効率的または実装されているわけではありません。
ソフトウェア ロード バランサーは、セッションを複数のサーバーに均等に分散します。
そのため、ユーザーがロード バランサーにヒットすると、ユーザーは特定のサーバーに送信され、そのサーバーは SSL をネゴシエートします。ユーザーは、セッションが期限切れになるまで、このサーバーと継続的に通信します。その時点で、彼は再びロード バランサーにアクセスします。