httpとhttpsのパフォーマンスに大きな違いはありますか？HTTPSはHTTPの5分の1の速度になる可能性があることを読んだことを思い出すようです。これは、現在の世代のWebサーバー/ブラウザで有効ですか？もしそうなら、それをサポートするホワイトペーパーはありますか？

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

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

他の人が言ったように、暗号化のためにある程度のオーバーヘッドが発生しますが、それは次のものに大きく依存しています。

• ハードウェア
• サーバーソフトウェア
• 動的コンテンツと静的コンテンツの比率
• サーバーまでのクライアント距離
• 一般的なセッションの長さ
• その他（私の個人的なお気に入り）
• クライアントのキャッシング動作

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

メモリに簡単にキャッシュできるかなり小さい静的ページのセットを提供することに負荷がかかるサーバーは、はるかに高いオーバーヘッドに悩まされます（1つのケースでは、スループットが「イントラネット」で処理されました）。

編集：SSLハンドシェイクがHTTPSの主要なコストであることは、他のいくつかによって提起された1つの点です。それが正しいので、「典型的なセッションの長さ」と「クライアントのキャッシング動作」が重要です。

多くの非常に短いセッションは、ハンドシェイク時間が他のパフォーマンス要因を圧倒することを意味します。セッションが長くなると、セッションの開始時にハンドシェイクのコストが発生しますが、後続のリクエストのオーバーヘッドは比較的低くなります。

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

HTTPSは初期ハンドシェイクを必要とするため、非常に遅くなる可能性があります。ハンドシェイクの一部として転送される実際のデータ量はそれほど大きくありませんが（通常5 kB未満）、非常に小さなリクエストの場合、これはかなりのオーバーヘッドになる可能性があります。ただし、ハンドシェイクが完了すると、対称暗号化の非常に高速な形式が使用されるため、オーバーヘッドが最小限になります。結論：HTTPSを介して大量の短いリクエストを行うと、HTTPよりもかなり遅くなりますが、単一のリクエストで大量のデータを転送する場合、違いはわずかです。

ただし、キープアライブはHTTP / 1.1のデフォルトの動作なので、1つのハンドシェイクを実行してから、同じ接続を介して多数のリクエストを実行します。これは、HTTPSに大きな違いをもたらします。（他の人が提案したように）サイトをプロファイリングして確認する必要がありますが、パフォーマンスの違いは目立ちません。

HTTPSによって遅延がどのように増加するかを本当に理解するには、HTTPS接続が確立される方法を理解する必要があります。ここに素敵な図があります。重要なのは、クライアントが2つの「レッグ」（1回の往復でリクエストを送信し、サーバーが応答を送信する）の後にデータを取得する代わりに、少なくとも4つのレッグ（2回の往復）までデータを取得しないことです。 。したがって、パケットがクライアントとサーバーの間を移動するのに100ミリ秒かかる場合、最初のHTTPSリクエストには少なくとも500ミリ秒かかります。

もちろん、これはHTTPS接続を再利用することで軽減できます（ブラウザーで行う必要があります）が、HTTPS Webサイトをロードするときの最初のストールの一部については説明しています。

オーバーヘッドは暗号化によるものではありません。最近のCPUでは、SSLに必要な暗号化は簡単です。

オーバーヘッドは、SSLハンドシェイクが原因で発生します。SSLハンドシェイクは長く、HTTPセッションでのHTTPSセッションに必要なラウンドトリップの数が大幅に増加します。

サーバーがシミュレートされた高遅延リンクの端にある間のページ読み込み時間を（Firebugなどのツールを使用して）測定します。高遅延リンクをシミュレートするツールが存在します-Linuxには「netem」があります。同じセットアップでHTTPとHTTPSを比較します。

待ち時間は、次の方法である程度軽減できます。

• サーバーがHTTPキープアライブを使用していることを確認する-これにより、クライアントはSSLセッションを再利用できるため、別のハンドシェイクが不要になります。
• 可能な限り少ない数にリクエストの数を減らす-可能な場合はリソース（.jsインクルードファイル、CSSなど）を組み合わせ、クライアント側のキャッシュを奨励する
• ページにロードする必要のないデータを（おそらく非表示のHTML要素で）ロードし、クライアントスクリプトを使用して表示するなどして、ページのロード数を減らします。

2014年12月の更新

AnthumChrisのHTTP vs HTTPS Test Webサイトを使用して、ご使用のブラウザーでHTTPとHTTPSのパフォーマンスの違いを簡単にテストできます。「このページは、安全でないHTTP接続と暗号化されたHTTPS接続での読み込み時間を測定します。どちらのページも、キャッシュされていない360個の一意の画像を読み込みます（合計2.04 MB）。」

結果はあなたを驚かせるかもしれません。

Let's Encrypt Certificate Authorityは、Mozilla、Akamai、Cisco、Electronic Frontier Foundation、およびIdenTrustのおかげで、2015年の夏に無料の自動化されたオープンSSL証明書の発行を開始するため、HTTPSのパフォーマンスに関する最新の知識を持つことが重要です。

2015年6月の更新

Let's Encryptの更新-2015年9月に到着：

• 起動スケジュールを暗号化しましょう（2015年6月16日）
• ルート証明書と中間証明書を暗号化しましょう（2015年6月4日）
• 契約者ドラフトを暗号化しましょう（2015年5月21日）

Twitterの詳細：@letsencrypt

HTTPSおよびSSL / TLSのパフォーマンスの詳細については、以下を参照してください。

• TLSはまだ高速ですか？
• 高性能ブラウザネットワーク、第4章：トランスポート層セキュリティ
• SSLのオーバークロック
• SSL処理の構造とパフォーマンス

HTTPSを使用することの重要性の詳細については、以下を参照してください。

• すべてにHTTPSを使用する理由 （HTTPSのみの標準）
• Let's Encrypt（インターネットセキュリティ研究グループ）
• HTTPS Everywhere（Electronic Frontier Foundation）

まとめると、Ilya Grigorik氏は次のように述べています。

以下のコメントを提供してくれたChris - HTTP vs HTTPSテストベンチマークの作者に感謝します。

現在のトップの答えは完全に正しくはありません。

他の人がここで指摘したように、httpsはハンドシェイクを必要とするため、より多くのTCP / IPラウンドトリップを実行します。

WAN環境では、通常、遅延が制限要因となり、サーバーでのCPU使用率の増加ではありません。

ヨーロッパから米国への待ち時間は約200ミリ秒（トルントトリップ時間）になる可能性があることに注意してください。

HTTPWatchでこれを簡単に測定できます（単一ユーザーの場合）。

これまでに述べたすべてに加えて、一部の（すべて？）Webブラウザーは、セキュリティ上の理由から、ローカルのハードドライブにHTTPS経由で取得したキャッシュコンテンツを保存しないことに注意してください。つまり、ユーザーの視点から見ると、静的コンテンツがたくさんあるページは、ブラウザの再起動後に読み込みが遅く見えるようになり、サーバーの視点から見ると、HTTPSを介した静的コンテンツのリクエストの量は、HTTPを介する場合よりも多くなります。

これに対する単一の答えはありません。

暗号化は常により多くのCPUを消費します。これは多くの場合、専用ハードウェアにオフロードでき、コストは選択したアルゴリズムによって異なります。たとえば、3desはAESよりも高価です。一部のアルゴリズムは、暗号化解除機能よりも暗号化解除機能の方が高価です。一部は反対のコストを持っています。

バルク暗号よりも高価なのはハンドシェイクのコストです。新しい接続はより多くのCPUを消費します。古いセッションシークレットが期限切れになるまで保持することを犠牲にして、セッション再開によりこれを減らすことができます。これは、それ以上返ってこないクライアントからの小さなリクエストが最も高価であることを意味します。

クロスインターネットトラフィックの場合、使用可能な帯域幅が低すぎるため、データレートのこのコストに気付かない場合があります。しかし、ビジー状態のサーバーでのCPU使用率には確かに気づくでしょう。

（ダイヤルアップユーザーとして）SSLを使用した同じページは通常のHTTPを使用した場合よりも数倍遅いと言えます...

多くの場合、SSLハンドシェイクのパフォーマンスへの影響は、SSLセッションを両端（デスクトップとサーバー）にキャッシュできるため、軽減されます。たとえば、Windowsマシンでは、SSLセッションは最大10時間キャッシュできます。http://support.microsoft.com/kb/247658/EN-USを参照して ください。一部のSSLアクセラレータには、セッションがキャッシュされる時間を調整できるパラメーターもあります。

考慮すべきもう1つの影響は、HTTPSを介して提供される静的コンテンツはプロキシによってキャッシュされないため、同じプロキシを介してサイトにアクセスする複数のユーザーのパフォーマンスが低下する可能性があることです。これは、静的コンテンツがデスクトップでもキャッシュされるという事実によって軽減できます。InternetExplorerバージョン6および7は、特に指示がない限り、キャッシュ可能なHTTPS静的コンテンツをキャッシュします（[ツール]メニュー/ [インターネットオプション] / [詳細設定] / [セキュリティ] / [暗号化されたページを保存しない]ディスクへ）。

小さな実験を行って、flickrからの同じ画像（233 kb）に対して16％の時間差を得ました。

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

もちろん、これらの数値は、コンピューターのパフォーマンス、接続速度、サーバーの負荷、パス上のQoS（ブラウザーからサーバーへの特定のネットワークパス）などの多くの要因に依存しますが、一般的な考え方を示しています。完了するにはさらに多くの操作が必要です（SSLハンドシェイクとデータのエンコード/デコード）。

SSLハンドシェイクのレイテンシに関する優れた記事（少し古いですが、それでも素晴らしい）を次に示します。遅いインターネット接続でアプリを使用していたクライアントの速度低下の主な原因としてSSLを特定するのに役立ちました。

http://www.semicomplete.com/blog/geekery/ssl-latency.html

私のプロジェクトでも同じ問題を調査しているので、これらのスライドを見つけました。古いが興味深い：

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

ここには厄介なエッジケースがあるようです：混雑したwifi上のAjax。

Ajaxは通常、キープアライブが20秒後にタイムアウトになったことを意味します。ただし、wifiは、（理想的には高速の）ajax接続が複数のラウンドトリップを行う必要があることを意味します。さらに悪いことに、wifiはしばしばパケットを失い、TCPの再送信があります。この場合、HTTPSのパフォーマンスは非常に悪くなります。

TLSはまだ高速ですか？はい。

• 見る：https : //www.youtube.com/watch?v=0EB7zh_7UE4
• 読む：https : //istlsfastyet.com/

線をぼかし、HTTPSを同じくらい高速にすることを目的としたプロジェクトが世の中にたくさんあります。同様SPDYとMOD-SPDY。

HTTPとHTTPSのパフォーマンス比較

いつものHTTPと比べて、HTTPSを常に遅いページ読み込み時間に関連付けています。Web開発者として、Webページのパフォーマンスは私にとって重要であり、私のWebページのパフォーマンスを低下させるものはすべてノーです。

関連するパフォーマンスへの影響を理解するために、下の図は、HTTPSを使用してリソースをリクエストしたときに内部で何が起こるかについての基本的な考え方を示しています。

上の図からわかるように、プレーンなHTTPを使用する場合と比較して、HTTPSを使用する場合に必要な追加の手順がいくつかあります。HTTPSを使用してリクエストを行う場合、リクエストの信頼性を確認するためにハンドシェイクを行う必要があります。このハンドシェイクは、HTTPリクエストと比較すると追加の手順であり、残念ながらオーバーヘッドが発生します。

パフォーマンスへの影響を理解し、パフォーマンスへの影響が大きいかどうかを自分で確認するために、このサイトをテストプラットフォームとして使用しました。私はwebpagetest.orgに行き、視覚的な比較ツールを使用して、HTTPSとHTTPを使用したこのサイトの読み込みを比較しました。

こちらからご覧いただけるように、テスト動画の結果は HTTPSを使用した場合にページの読み込み時間に影響を与えましたが、その違いはごくわずかであり、300ミリ秒の違いに気づきました。これらの時間は、コンピューターのパフォーマンス、接続速度、サーバーの負荷、サーバーからの距離など、多くの要因に依存することに注意することが重要です。

サイトは異なる場合があります。サイトを徹底的にテストし、HTTPSへの切り替えに伴うパフォーマンスへの影響を確認することが重要です。

これを測定する方法があります。jmeterと呼ばれるApacheのツールは、スループットを測定します。SSLの有無にかかわらず、制御された環境でjmeterを使用してサービスの大規模なサンプリングを設定する場合、相対コストの正確な比較を取得する必要があります。あなたの結果に興味があります。

HTTPSには暗号化/復号化のオーバーヘッドがあるため、常に少し遅くなります。SSL終了はCPUを非常に集中的に使用します。SSLをオフロードするデバイスがある場合、サーバーの負荷によっては、レイテンシの違いがほとんど目立たなくなる場合があります。

より重要なパフォーマンスの違いは、ユーザーが接続している間、HTTPSセッションが開いていることです。HTTPの「セッション」は、単一のアイテムリクエストに対してのみ持続します。

多数の同時ユーザーがいるサイトを実行している場合、大量のメモリを購入すると予想されます。

SSLが非SLL HTTPでは必要とされない追加の暗号化ステップを必要とすることを考えると、これはほぼ確実に当てはまります。

HTTPSは確かにページ速度に影響します...

上記の引用は、サイトのセキュリティと速度に関する多くの人々の愚かさを明らかにしています。HTTPS / SSLサーバーハンドシェイクは、インターネット接続を確立するときに最初のストールを作成します。訪問者のブラウザ画面に何かがレンダリングを開始する前に遅い遅延があります。この遅延は、Time-to-First-Byte情報で測定されます。

HTTPSハンドシェイクのオーバーヘッドは、Time-to-First-Byte情報（TTFB）に表示されます。一般的なTTFBの範囲は、100ミリ秒未満（最良の場合）から1.5秒超（最悪の場合）です。しかし、もちろん、HTTPSを使用すると500ミリ秒悪くなります。

往復の無線3G接続は500ミリ秒以上になることがあります。追加のトリップにより、遅延が2倍になり1秒以上になります。これは、モバイルのパフォーマンスに大きな悪影響を及ぼします。非常に悪いニュースです。

機密データを交換しない場合は、SSLはまったく必要ありませんが、eコマースWebサイトが好きな場合は、ログインやチェックアウトなどの機密データが交換される特定のページでHTTPSを有効にすることができます。

ソース：Pagepipe

ブラウザーはHTTPまたはHTTPSのいずれかでHTTP / 1.1プロトコルを受け入れることができますが、ブラウザーはHTTPSでHTTP / 2.0プロトコルしか処理できません。HTTP / 1.1からHTTP / 2.0へのプロトコルの違いにより、HTTP / 2.0は平均でHTTP / 1.1の4〜5倍高速になります。また、HTTPSを実装するサイトのほとんどは、HTTP / 2.0プロトコルを介して実装します。したがって、HTTPSは一般的に使用するプロトコルが異なるため、ほとんど常にHTTPよりも高速になります。ただし、HTTP over HTTP / 1.1とHTTPS over HTTP / 1.1を比較すると、HTTPは平均してHTTPSよりもわずかに高速です。

以下は、Chrome（Ver。64）を使用して実行した比較です。

HTTPS over HTTP / 1.1：

• 0.47秒の平均ページ読み込み時間
• HTTP over HTTP / 1.1より0.05秒遅い
• HTTPS over HTTP / 2.0より0.37秒遅い

HTTP over HTTP / 1.1

• 0.42秒の平均ページ読み込み時間
• HTTPS over HTTP / 1.1より0.05秒速い
• HTTPS over HTTP / 2.0より0.32秒遅い

HTTPS over HTTP / 2.0

• 0.10秒の平均読み込み時間
• HTTP over HTTP / 1.1より0.32秒速い
• HTTPS over HTTPS / 1.1より0.37秒速い