ロード バランサが SSL/TLS で暗号化されたデータをサーバーに渡すようにします。クライアントへの新しい HTTPS 接続が確立された場合、ハンドシェイクはどのように処理されるのでしょうか。ハンドシェイクはステートフル通信です。たとえば、クライアントの完了メッセージを検証するには、サーバー (ファーム) とクライアントの間でこれまでに交換されたすべてのハンドシェイク メッセージをサーバーが認識している必要があります。したがって、私が知る限り、次の 3 つの可能性があります。
SSL/TLSデータはすべてのサーバーで共有されるキャッシュに保持されます
ハンドシェイク メッセージの内容はすべてのサーバーに複製されます。
ロード バランサは、クライアントからのすべてのハンドシェイク メッセージを同じサーバーに送信します。
質問: このような環境では、通常どのシナリオが使用されますか? ハンドシェイクの処理に関して、私が見逃したその他のポリシーはありますか?
追加した：私の質問は重複しているという主張に直面しており、なぜ違うのかを説明するために質問を編集するように言われています。負荷分散とHTTPS戦略それで、私の質問と他の質問を比較すると次のようになります。
a) 負荷分散環境で https 状態を処理するための 3 つのオプションを考え出し、これらのうちどれ (または他のオプション) が実際に使用されているかを尋ねました。
b) 他の質問では、OP はオプション 3 (「同じサーバー」) を使用しています。つまり、同じ IP を持つすべてのリクエストが同じサーバーにルーティングされます。ただし、ほとんどのクライアントが同じ IP を使用しているため、lb はうまく機能せず、OP は解決策を求めています。5 つの回答のうち 4 つ半は、実質的に上記のオプション 3 を維持する提案を示しています。その回答の一部 (「ターゲット サーバーの DNS」) は理解できませんでした。
問題は、オプション 1 (「SSL キャッシュ」) と 2 (「SSL ハンシェイク データのレプリケーション」) が実際に使用されているかどうかです。記事http://wtarreau.blogspot.de/2006/11/making-applications-scalable-with-load.htmlオプション 1 が好まれるようです (「4. 専用 SSL キャッシュ ファーム」を参照)。
答え1
セットアップのすべての部分で HTTPS を使用する必要があるときは、クライアントと lb の間でハンドシェイクを実行し、lb とサーバーの間で別の証明書セットを用意する方が簡単かつ実現可能です。
SSL パススルーは可能であり、一部の CDN では提供されています。私の理解では、すべてのトラフィックはそのまま転送されますが、これでは負荷分散はできません。
これを機能させるには、LB レベルでのセッションのスティッキー性が必要です。
答え2
NginxのTCPストリームプロキシ経由でSSLパススルーを行うことができます
https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/