38

2013 年 4 月 25 日更新:

これは、おそらく必要以上に注目を集めている人気のある質問です。誤った情報の拡散を防ぐために、まず次の段落とそれに付随する記事をお読みください。

HTTPS と HTTP のどちらを使用するかを決定する際に、速度を考慮すべきではありません。サイトのいずれかの部分 (ログイン、登録、クレジット カードなど) でHTTPSが必要な場合は、すべての部分で常に HTTPS が絶対に必要です。

理由については、SSL はTroy Huntによる暗号化に関するものではないことをお読みください。

私は、https の下で e コマース Web サイト全体を運営していると考えられています。https と http を介して 156KB の画像のダウンロード時間を測定するために大雑把なベンチマークを実行することにしました。

ベンチマークは、Firefox の Firebug を使用して、空のキャッシュから画像をダウンロードするときに、Net パネルから Excel に「待機」時間と「受信」時間 (それ以外の時間はすべて 0) を転記するだけで実行されました。

私の結果は予想外でした：

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) によって異なる結果が得られると思いますか?
ダウンロードをベンチマークするためのより良い方法はありますか?



テスト画像は次のとおりです。

[テスト画像削除]

追加情報：

  • この Web サイトは、Goaddy.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 はまだ高速です。この場合は些細なことですが。

誰かが私のベンチマークに欠陥を見つけたら、私に知らせて、より良い結果を投稿できるようにします.

そのため、私の特定のサーバーで午後 6 時頃に共有された Godaddy 共有ホスティングでは、https 経由で提供されるコンテンツは、http 経由よりも高速です。

4

6 に答える 6

19

時間を見ると、http の方が待ち時間が長く、受信時間が短いです。一方、https は待ち時間が短く、受信時間が長くなります。これは、共有ホスティング サーバーの http ポートがよりビジーであるためと解釈できます。そのため、サーバーに受け入れられるまで、リクエストはキューに長く留まります。受け入れられると、リクエストは https よりも高速に転送されます。https ポートでは、サーバー上のトラフィックが少ないため、リクエストは高速に処理されますが、転送に時間がかかります。

https と http の比較では、http と比較して https の各リクエストのハンドシェイクにかかる時間が長いことを考慮する必要があります。小さなリクエストを多数実行すると、悪化が見られるはずです。

于 2009-09-23T21:50:20.753 に答える
11

また、HTTPS ドキュメントがユーザーのブラウザー以外の場所にキャッシュされることはほとんどないことを考慮する必要があるかもしれません。キャッシュ。(一部の場所では、ISP が共有プロキシ キャッシュを介して顧客を配置することは依然として一般的です)

もちろん、ユーザーが共有しても構わないものであれば.

于 2009-09-24T01:37:53.280 に答える
5

HTTPS で見られるパフォーマンスの高速化はまぐれではないと思います。

結果について次の 2 つの点に注意してください。

  1. HTTP は、最初の「合計」結果では常に高速ですが、その後の合計では遅くなります。
  2. HTTPS の結果はより一貫しています。

最新のロード バランサーは通常、パフォーマンスを向上させるために SSL を使用している間は圧縮を有効にします。最初の SSL ハンドシェイクでかなりのレイテンシが発生することは事実ですが、セッションを維持するために使用されるメカニズム (「再開されたハンドシェイク」と、非対称暗号化ではなく対称暗号化) によって追加されるレイテンシはごくわずかです。その結果、セッションが短い場合を除き、セッションの維持によって失われるよりも、圧縮によってより多くのパフォーマンス上の利点が得られます。

SSL がかなりの遅延を招くという従来の通念は時代遅れです (セッションが非常に短い場合を除きます)。一部の Google エンジニアは、 SSL に関するこれまでのいくつかの仮定がもはや正しくないことを説明する 記事を書きました。

于 2010-11-16T21:24:15.660 に答える
2

https は次のように機能します: 最初に 4 ウェイ ハンドシェイクが実行されます (少なくとも私の記憶が正しければ 4 ウェイでした)。ここで、クライアントとサーバーは後で使用される対称暗号化アルゴリズムに同意し、証明書 (公開鍵を含む) を交換します。

publickey crypto を使用して、セッション (後で対称暗号化のキー) を交換します。

現在、彼らはセッションキーといくつかの暗号化アルゴリズム (3des、aes、rc4、rc5 など) で暗号化されたメッセージを送信しています。対称暗号化はそれほど高価な操作ではないため、ダウンロード時間の差はそれほど大きくありません。

待ち時間が短いという事実は、おそらく http ポートのトラフィックが少ないか、http 要求と比較して https 要求を実行したときのトラフィックが少ないためです。

したがって、パフォーマンスを最適化するには、ハンドシェイクは比較的高価な手順であるため、使用する https 接続をできるだけ少なくする必要があります。

于 2009-09-23T21:59:45.180 に答える
1

プロキシ経由でサイトにアクセスしていますか? その場合、プロキシがバイパスされているか、最初の CONNECT 要求の処理のみを使用するように削減されているため、パフォーマンスが向上している可能性があります。

HTTP を使用すると、プロキシがコンテンツをチェックしてキャッシュする可能性があり、パフォーマンスが低下する可能性があります。

于 2009-09-24T17:12:28.997 に答える