HTTPSとHTTPの速度の比較
2013年4月25日更新：
これはおそらく必要以上に注目を集めている人気の質問です。誤報の拡散を防ぐために、まず次の段落と付随する記事をお読みください：
速度は、HTTPSとHTTPのどちらを使用するかを決定する際の要因にはなりません。 need HTTPS for anyサイトの一部（ログイン、登録、クレジットカードなど）の場合HTTPSは絶対に必要ですそれのすべて、いつも。
理由については SSLは暗号化に関するものではありませんTroy Hunt をご覧ください。
私のeコマースWebサイト全体をhttpsで実行することを検討しています。 httpsには暗号化プロセスによる追加のオーバーヘッドがかかることを読んだため、httpsとhttpを介して156KBの画像のダウンロード時間を測定するために、大まかなベンチマークを実行することにしました。
ベンチマークは、FirefoxのFirebugを使用して、空のキャッシュから画像をダウンロードするときに、「待機」および「受信」時間（他の時間はすべて0）をネットパネルからExcelに転記することによって実行されました。
私の結果は予想外でした：
http: 11.233 seconds
Waiting Receiving Total
1.56 0.88 2.44
1.55 0.101 1.651
1.53 0.9 2.43
1.71 0.172 1.882
1.9 0.93 2.83
https: 9.936 seconds
Waiting Receiving Total
0.867 1.59 2.457
0.4 1.67 2.07
0.277 1.5 1.777
0.536 1.29 1.826
0.256 1.55 1.806
[明白]ベンチマークからの観察：
- サーバーの応答は高速ですが、ダウンロード時間はhttpよりもhttpsの方が遅くなります。
- httpsは全体的にかなり高速です（約10％）。
これが起こる理由を誰かが説明できますか？
ドキュメント（html、css、javascript）は異なる結果をもたらすと思いますか？
ダウンロードのベンチマークを行うより良い方法はありますか？
[テスト画像は削除されました]
追加情報：
- ウェブサイトはGodaddy.comを通じて共有ホスティングアカウントにあります。
- 独自のベンチマークを実行するほど親切にする場合は、「www」サブドメインを追加しないでください。静的コンテンツのルートはとにかく使用します。
- 統合パイプラインモードでIIS7を使用します。
編集：以下の1px GIF（35バイト）のベンチマーク：
http: 2.666 seconds
Waiting Receiving Total
0.122 0.31 0.432
0.184 0.34 0.524
0.122 0.36 0.482
0.122 0.34 0.462
0.126 0.64 0.766
https: 2.604 seconds
Waiting Receiving Total
0.25 0.34 0.59
0.118 0.34 0.458
0.12 0.34 0.46
0.182 0.31 0.492
0.134 0.47 0.604
結果：httpsはさらに高速です。この場合は些細なことですが。
誰かが私のベンチマークに欠陥を見つけた場合は、私に知らせて、より良い結果を投稿できるようにしてください。
したがって、Godaddyでは、httpsを介して提供される私の特定のサーバーコンテンツの午後6時頃の共有ホスティングは、httpよりも高速です。
あなたの時間を見ると、httpの待機時間は長く、受信時間は短くなっています。一方、httpsでは待機時間が短く、受信時間が長くなります。これは、共有ホスティングサーバーのhttpポートがビジーであり、要求がサーバーに受け入れられるまでキューに長く留まると解釈します。いったん受け入れられると、リクエストはhttpsよりも速く転送されます。 httpsポートではサーバー上のトラフィックが少ないため、リクエストの処理は速くなりますが、転送に時間がかかります。
Httpsとhttpの比較では、httpと比較してhttpsの各リクエストをハンドシェイクするために、より長い時間を考慮する必要があります。多くの小さなリクエストを行うと、状況が悪化するはずです。
また、HTTPSドキュメントはユーザーのブラウザ以外の場所にはほとんどキャッシュされないことを考慮に入れる必要がある場合があるため、個々のユーザーにはほとんど違いがありませんが、HTTPドキュメントは、キャッシュ。 （一部の場所では、ISPが顧客に共有プロキシキャッシュを経由させることは依然として一般的です）
もちろん、ユーザーが共有しても構わない場合は。
HTTPSを介して見られるより高速なパフォーマンスはまぐれではないと思います。
結果について2つの点に注意してください。
- HTTPは、最初の「合計」結果では常に高速ですが、後続の合計では遅くなります。
- HTTPSの結果はより一貫しています。
最新のロードバランサーは通常、SSLの使用中に圧縮を有効にしてパフォーマンスを向上させます。最初のSSLハンドシェイクでかなりのレイテンシが発生することは事実ですが、セッションの維持に使用されるメカニズム（非対称暗号化の代わりに「再開されたハンドシェイク」と対称暗号化）は、ごくわずかなレイテンシしか追加しません。その結果、セッションが短い場合を除き、セッションのメンテナンスで失うよりも、圧縮の方がパフォーマンス上のメリットが得られます。
SSLでかなりの遅延が発生するという従来の知識は古くなっています（セッションが非常に短い場合を除きます）。一部のGoogleエンジニア 記事を書いた SSLに関する以前の前提の一部が真実ではなくなっていることを説明しています。
httpsは次のように機能します。最初に4ウェイハンドシェイクが実行され（少なくとも4ウェイであったことを正しく覚えている場合）、ここでクライアントとサーバーが後で使用する対称暗号化アルゴリズムに同意し、証明書（公開鍵を含む）を交換します。
それらは、公開鍵暗号を使用してセッション（後で対称encの鍵）を交換します。
これで、セッションキーといくつかの暗号化アルゴリズム（3des、aes、rc4、rc5など）で暗号化されたメッセージが送信されます。対称暗号化はそれほど高価な操作ではないため、ダウンロード時間の違いはそれほど大きくありません。
less待機時間があるという事実は、httpリクエストと比較して、HTTPポートでのトラフィックが少ないか、httpsリクエストを実行したときのトラフィックが少ないためです。
したがって、ハンドシェイクは比較的コストのかかる手順であるため、パフォーマンスを最適化するには、できるだけ少ないhttps接続を使用する必要があります。
プロキシ経由でサイトにアクセスしていますか？その場合、プロキシがバイパスされるか、最初のCONNECTリクエストの処理のみを使用するように削減されるため、パフォーマンスが向上する可能性があります。
HTTPを使用すると、プロキシがコンテンツをチェックしてキャッシュする可能性があり、パフォーマンスが低下します。