[解決済み】HTTPとHTTPSのパフォーマンス比較

質問

http と https でパフォーマンスに大きな違いはありますか？ HTTPSはHTTPの5分の1の速度になると読んだように記憶しています。 これは、現世代のウェブサーバ/ブラウザで有効なのでしょうか？ もしそうなら、それを裏付けるようなホワイトペーパーはあるのでしょうか？

どのように解決するのですか？

これには、とてもシンプルな答えがあります。 Webサーバーのパフォーマンスをプロファイリングして、特定の状況におけるパフォーマンス・ペナルティを確認します。 HTTPサーバーとHTTPSサーバーのパフォーマンスを比較するツールがいくつかあり（JMeterとVisual Studioが思い浮かびます）、非常に使いやすいものです。

がなければ、誰も意味のある答えを出すことはできません。 いくつか お客様のウェブサイトの性質、ハードウェア、ソフトウェア、およびネットワーク構成に関する情報。

他の方もおっしゃっているように、暗号化によるオーバーヘッドがある程度発生しますが、それは大きく左右されるものです。

• ハードウェア
• サーバーソフトウェア
• 動的コンテンツと静的コンテンツの比率
• クライアントからサーバーまでの距離
• 標準的なセッションの長さ
• など（個人的に好きです）
• クライアントのキャッシュ動作

私の経験では、動的コンテンツを多用するサーバーは、HTTPSによる影響が少ない傾向にあります。なぜなら、暗号化（SSLオーバーヘッド）にかかる時間は、コンテンツ生成時間に比べて重要でないからです。

メモリに簡単にキャッシュできる、かなり小さな静的ページのセットを提供することに重点を置いているサーバーは、はるかに高いオーバーヘッドに悩まされます（あるケースでは、イントラネットでスループットが大混乱に陥ったことがあります）。

編集部：他の方からも指摘があったのですが、SSLハンドシェイクがHTTPSの大きなコストになっているということです。その通りです。だからこそ、典型的なセッションの長さとクライアントのキャッシュ動作が重要なのです。

非常に短いセッションが多いということは、ハンドシェイク時間が他の性能要因を圧倒してしまうということです。長いセッションは、ハンドシェイクのコストがセッションの開始時に発生しますが、その後のリクエストは比較的低いオーバーヘッドになります。

クライアントキャッシュは、大規模なプロキシサーバーから個々のブラウザのキャッシュまで、いくつかのステップで行うことができます。一般的に、HTTPSコンテンツは共有キャッシュにキャッシュされません（ただし、少数のプロキシサーバーは中間者型の動作を悪用してこれを実現することができます）。多くのブラウザは HTTPS コンテンツを現在のセッションのためにキャッシュし、多くの場合、セッションをまたいでキャッ シュします。キャッシュしない、あるいはキャッシュが少ないということは、クライアントが同じコンテンツをより頻繁に取得することを意味します。この結果、同じ数のユーザーにサービスを提供するために、より多くのリクエストと帯域幅が必要になります。