私たちの多くは、プレーンTCPを使用するWebサーバーとアプリケーションサーバーを持っています。
私たちの中には、SSLなどの安全なレイヤーを使用するWebサーバーやその他のサーバーを持っている人もいます。
SSLについての私の理解は、ハンドシェイクは非常に計算集約的であり、進行中の接続の暗号化は（比較的）安価であるということです。
あなたが訂正するための私の仮定：平均的なホスティングボックス（およびクラウドホスティングでの平均的な情報もクールです）は、AES暗号化パケットでネットワーク接続を飽和させることができると簡単に期待できますが、1000を実行するのは困難です1秒あたりのRSAハンドシェイク。証明書を使用したクライアント認証は、匿名クライアントよりもサーバーにとってかなりコストがかかります。
SSLの1秒あたりのセッションセットアップ数にはどのような経験則がありますか？
なぜ測定するだけではないのですか？使用しているソフトウェアとハードウェアの正確な数値が得られます。また、サーバー インフラストラクチャの変更 (ボックスの追加、SSL アクセラレータ、パラメーターの調整など) の影響を測定することもできます。
1 つのボックスで 1 秒あたり 1,000 回の SSL ハンドシェイクに到達するのは難しいということは正しいです。というか、多分無理だと思います。毎秒数十回、問題ありません。たくさんの $$$ がないわけではありません。
また、1 秒あたり 1000 回のハンドシェイクが実際には必要ない可能性もあります。それは非常に多く、そのようなものを必要とするためにはすでにかなりのトラフィックが必要です: これを参照してください: SSL TPS パフォーマンスに何が必要ですか?
通常、常に新しい SSL ハンドシェイクを行うわけではないことに注意してください。ブラウザーはハンドシェイクを 1 回行い、多数のリクエストやページ ビューで接続を開いたままにするため、1 秒あたりのハンドシェイクの必要性は、思ったよりもはるかに低くなる可能性があります。
Ville が言ったように、実際のオプションはありませんので、構成で試してみてください。ただし、リンクを確立した後のデータの対称暗号化を過小評価しないでください。コストは低くなるかもしれませんが、暗号化されたチャネルを介して大量のデータをダウンロードする場合は、最初のネゴシエーションよりもはるかに多くのコストがかかる可能性があります.
したがって、このためには、サイトを使用するための一般的なシナリオを構築してから、ストレス テストを行う必要があります。