performance - HTTP と HTTPS のパフォーマンス

Question

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

score 237 · Accepted Answer

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

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

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

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

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

メモリに簡単にキャッシュできるかなり小さな静的ページのセットを処理することに重きを置くサーバーは、はるかに高いオーバーヘッドに悩まされます (あるケースでは、「イントラネット」でスループットが低下しました)。

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

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

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

score 229 · Accepted Answer

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

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

score 102 · Accepted Answer

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

もちろん、これは HTTPS 接続を再利用することで軽減できますが (ブラウザはそうすべきです)、HTTPS Web サイトをロードするときの初期ストールの一部を説明しています。

score 79 · Accepted Answer

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

オーバーヘッドは SSL ハンドシェークによるもので、これは時間がかかり、HTTP セッションを介した HTTPS セッションに必要なラウンドトリップの数を大幅に増加させます。

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

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

サーバーが HTTP キープアライブを使用していることを確認します。これにより、クライアントは SSL セッションを再利用できるようになり、別のハンドシェイクが不要になります。
可能な限りリソースを組み合わせ (例: .js インクルードファイル、CSS)、クライアント側のキャッシュを促進することにより、リクエストの数をできるだけ少なくします。
ページの読み込み回数を減らします。たとえば、不要なデータをページ (おそらく非表示の HTML 要素) に読み込み、クライアントスクリプトを使用して表示します。

score 24 · Accepted Answer

現在のトップアンサーは完全には正しくありません。

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

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

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

これは、 HTTPWatchを使用して（シングルユーザーの場合）簡単に測定できます。

score 12 · Accepted Answer

これまでに述べたことすべてに加えて、一部の (すべて?) Web ブラウザーは、セキュリティ上の理由から、HTTPS 経由で取得したキャッシュされたコンテンツをローカルのハードドライブに保存しないことに注意してください。これは、ユーザーの観点からは、ブラウザの再起動後に大量の静的コンテンツを含むページの読み込みが遅く見えることを意味し、サーバーの観点からは、HTTPS を介した静的コンテンツに対する要求の量が HTTP を介した場合よりも多くなります。

score 6 · Accepted Answer

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

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

score 6 · Accepted Answer

これに対する答えは 1 つではありません。

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

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

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

score 6 · Accepted Answer

(ダイアルアップユーザーとして) SSL 経由の同じページは、通常の HTTP 経由よりも数倍遅いと言えます...

score 3 · Accepted Answer

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

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

score 2 · Accepted Answer

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

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

score 2 · Accepted Answer

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

視聴: https://www.youtube.com/watch?v=0EB7zh_7UE4
読む: https://istlsfastyet.com/

境界線を曖昧にし、HTTPS を同じくらい高速にすることを目的としたプロジェクトが数多くあります。SPDYとmod-spdy のように。

score 2 · Accepted Answer

ここには厄介なエッジケースがあるようです: 混雑した Wi-Fi を介した Ajax。

Ajax は通常、KeepAlive が 20 秒後にタイムアウトしたことを意味します。ただし、wifi は、(理想的には高速な) ajax 接続が複数回の往復を行う必要があることを意味します。さらに悪いことに、Wi-Fi はしばしばパケットを失い、TCP の再送信が発生します。この場合、HTTPS のパフォーマンスは非常に悪いです。

score 0 · Accepted Answer

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

score 0 · Accepted Answer

HTTPS には暗号化/復号化のオーバーヘッドがあるため、常に少し遅くなります。SSL ターミネーションは、CPU を非常に集中的に使用します。SSL をオフロードするデバイスがある場合、サーバーの負荷によっては、待ち時間の違いはほとんどわからない場合があります。

score 0 · Accepted Answer

これを測る方法があります。jmeter と呼ばれる apache のツールは、スループットを測定します。制御された環境で jmeter を使用してサービスの大規模なサンプルをセットアップする場合、SSL を使用する場合と使用しない場合で、相対的なコストを正確に比較する必要があります。私はあなたの結果に興味があります。

score -1 · Accepted Answer

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

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

performance - HTTP と HTTPS のパフォーマンス

22 に答える 22

Related

Reference