WebファームはTLSハンドシェイクのオーバーヘッドを懸念する必要があります
私は、Webサーバーが安全な接続のネゴシエーションを担当するWebファームを持っています。 Webファームを持っている他の誰かが、 TLS再開ハンドシェイク がサポートされていることを確認することによってTLSハンドシェイクのオーバーヘッドを減らすために邪魔をしませんか？もしそうなら、なぜですか？
スティッキーセッションから、よりバランスの取れた負荷分散アルゴリズムに切り替えています。 TLS再開機能のメリットが失われることを懸念しています。クライアントからのすべての接続が別のWebサーバーに接続されると仮定すると、完全なTLSハンドシェイクが必要になると想定しています。オーバーヘッドはわかりませんが、往復20ミリ秒を見ると、完全なハンドシェイクが完了するまでに3倍ほどかかるように見えます。
OP Webサーバーファームの大きさはわかりませんが、ほとんどの中小規模のインストールでは、ロードバランサーですべてのTLS/SSLを処理するのが最もクリーンで簡単だと思います。だからあなたは持っています：
Internet (HTTPS req) -> L7 HTTPS proxy LB -> plain HTTP on LAN -> webserver
o3 Magazineは良い nginxでこれがどれほど簡単かについての記事 、そしてあなたが期待できるパフォーマンスの数値。 f5は、DIYソリューションの代わりに SSLアクセラレーションに商用アプライアンスを使用する利点についての解説 を投稿しました（IMHOはやや偏っています）。
X-Forwarded-ForおよびX-FORWARDED_PROTOヘッダーを検査し、接続を正しく処理するには、Webサーバーが必要であることに注意してください。 。
ほとんどのインストールは、単一のHTTPおよびHTTPSロードバランサー、またはHAのアクティブ/パッシブ構成のロードバランサーのペアでうまくいくはずです。このセットアップでは、SSL/TLSエンドポイントが1つしかないため（通常はハンドシェイク再開を自動的にサポートします）、ハンドシェイク再開は問題になりません。
ロードバランサーが配置されていても、接続が確立された場合、そのセッションの将来の接続はすべて同じサーバーで発生するという印象を受けました。
おそらくそれは、私が使用したサイトと構成したサービスの動作方法にすぎません。
Apacheを使用していると仮定して、 distcache を見てください。マニュアルページから、「distcacheアーキテクチャは、アプリケーション、そして実際にはマシンがネットワークサービスを介してそれらの間でセッション状態を共有できるようにするためのプロトコルと付随するツールのセットを提供します。」
「現在、distcacheの主な用途はSSL/TLSセッションキャッシングです。これにより、SSL/TLSサーバー（HTTPSサポートを提供する安全なApache Webサーバーなど）が集中セッションキャッシュを使用できるようになります。つまり、どのサーバーでもネゴシエートされたSSL/TLSセッションを再開できます。このアプローチの利点には、負荷分散のためのメカニズムの自由度が高まることが含まれます。」