パスワードを忘れた? アカウント作成
11806544 story
インターネット

多くのサイトではHTTPよりもHTTPSのほうが速くアクセスできる? 42

ストーリー by hylom
これが新プロトコルのパワーか 部門より
insiderman 曰く、

Kazuho's Weblogによると、最近ではWebサイトへのアクセス時、HTTPSのほうがHTTPよりもアクセス速度が高速になるケースが多いらしい。これはHTTP vs HTTPS Testという、アクセス速度比較サイトで実際に体感できるとのことで、HTTPSではSPDYで通信行われるケースが多いためにより高速になる、という話だそうだ。

SPDYは複数のファイルを並行してダウンロードできるため、多くのWebサイトのような小さいファイルを多数ダウンロードするサイトではより高速にサイトを読み込めるという。

また、現在標準化作業中のHTTP/2プロトコルでは、多くのWebブラウザがHTTPSでの通信時のみこれを利用するようになる見込みだそうで、そのためHTTPSのほうがHTTPより高速になる、という状況は今後も続くと考えられるそうだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by takehora (12309) on 2014年12月09日 13時39分 (#2724856) 日記

    まず、参照されている元のコンテンツ「HTTP vs HTTPS Test」のテスト内容が錯誤に陥らせる内容なので、それはどうなの?と思います。

    (誤) HTTPとHTTPSの比較
    (正) HTTPとHTTPS+SPDYの比較

    さて、タイトルが齎す錯誤より大きな、このテストの問題は、読み込まれる画像にExpiresヘッダーが入っており、二回目以降の読み込みは、IMS(If-Modified-Since)リクエスト、つまりダウンロードせず、変更確認だけで済む点です。

    Firebugを開いた状態で、
    https://www.httpvshttps.com/ [httpvshttps.com]
    を開いてみてください。

    もし、既にブラウジングしたことがあるのであれば、Ctrl+F5で、スーパーリロードをさせて、再度コンテンツをダウンロードさせます。
    その秒数を確認して下さい。

    では、次に、http://www.httpvshttps.comにアクセスします。これもスーパーリロードでブラウジングします。
    その秒数を確認して下さい。

    これで、速いわけではないことがわかります。

    "Each test loads 360 unique, non-cached images"と書いてあるのと、"For fastest results, run each test 2-3 times in a private/incognito browsing session."と書いてあるのが、嫌らしいですね。

    さて、HTTPS+SPDY自体が速さを齎すかという話ですが、SPDYは少数のドメインを参照している場合は速いですが、昨今のWebページは、20~60ものドメインからファイルを読み込んでいるため、実際には遅くなります。Facebook、Twitter、Google+、はてなと、この4つのSNSのボタンを付けただけで、参照するドメイン数は20を超えます。

    私は仕事柄、日本のWebサイト60ぐらいを定常的に24時間365日、IE(SPDY Off)、Firefox(SPDY On)、Chrome(SPDY On)で計測していますが、IEが最速という結果になっています。

    • 質問です。「HTTP vs HTTPS Test」で読み込む画像のURL には,キャッシュ対策のパラメータがランダム(規則あり?)についています。
      これでもキャッシュされるのでしょうか?

      あと,私の環境ではイメージの応答ヘッダをみるとEtag はついていますが Expires は含まれていません。
      MacOSX 10.9 の Firefox 34.0 です。
      相手に合わせて、応答をかえているのでしょうか。

      他の皆さんどうですか?

      親コメント
      • FirefoxのExpires Headerについて、調べました。
        他の方が書いているとおり、ChromeやIEにはExpires Headerはなく、このサーバから配信されている素のレスポンスヘッダーには、Expires Headerが無いことをcurlでも確認しました。この点は、私の早とちりだったようです。失礼しました。

        Firefoxは、Last-Modified Headerがついているものについては、自動でExpires Headerを付与するそうです。

        "On pages that return a Last-Modified header but no Expires header, Mozilla will automatically generate its own Expires date."

        https://bugzilla.mozilla.org/show_bug.cgi?id=277813 [mozilla.org]

        Query String付きのURLの画像をキャッシュするかどうかについては、FirefoxはEtagが付与されているものについてはキャッシュするそうです。

        "So you should assume that query string should not cache dynamic content which includes html. This however is not the case for IE and Chrome which pay attention to the Cache-Control and Expires headers for as given requested URI.

        With that said it really depends on the implementation of the client and server.

        In firefox when reloading using F5 key and examining the Developer Tools you should see 403 Not Modified for Cache Hits when using e-tag header."

        http://webmasters.stackexchange.com/questions/63119/why-doesnt-firefox... [stackexchange.com]

        では、仕様としてはどうか?という話としては、2005年にリリースされたRFC3986では、「その URI のスキームと (存在する場合は) 命名オーソリティの範囲内のリソースを識別するために利用される。」とあり、キャッシュされるべきであろうという意見が出ています。
        http://bizcoder.com/caching-resources-with-query-strings [bizcoder.com]

        尚、キャッシュされないIEやChromeであっても、やはり、HTTPSの方が遅いことには変わりはないです。

        親コメント
        • by Anonymous Coward

          > Query String付きのURLの画像をキャッシュするかどうかについては、FirefoxはEtagが付与されているものについてはキャッシュするそうです。

          下記
          > 「その URI のスキームと (存在する場合は) 命名オーソリティの範囲内のリソースを識別するために利用される。」
          にあるとおり、各画像には読み込みごとに異なるクエリストリングが付与されるため、
          それぞれ異なるリソースとして扱われるので、キャッシュはヒットしません。
          そもそもIf-None-Match等のヘッダも送信されていません。

          > では、仕様としてはどうか?という話としては、2005年にリリースされたRFC3986では、「その URI のスキームと (存在する場合は) 命名オーソリティの範

    • by Anonymous Coward

      このPCだと、Ctrl+F5でよませるとHTTPS+SPDYの方が遅かった。

  • by Anonymous Coward on 2014年12月09日 14時04分 (#2724879)

    元記事の図を一見するだけだと「HTTP では1つのソケット経由で逐次的に3往復の通信が必要なところ、
    SPDY を使用すると並行化できるよ」みたいな印象を受けますが、正確には、HTTP でも通信は並行化されます。
    最近のブラウザは1つのホストに対して6つ程度のコネクションを張って通信しますからね。
    (HTTP/1.1 の RFC には、2つまでにしといてね、って書いてあった気がしますが、まぁ気にしないでおきましょう)

    とはいえ、それでも1つ1つのコネクションには TCP 接続を確立するためのパケットの往復が必要ですし、
    確立した後も TCP のスロースタートにより、最初はゆっくりとしか通信になってしまいます。

    これに対し、SPDY だと1つのコネクションだけを張って、その上にセッションみたいな層を用意し、
    その上で並行して複数の HTTP/1.1 相当の通信をします。だから TCP のコネクションは1つですみますし、
    全部の通信が1つのコネクション内で行われるので TCP スロースタートもはやく暖まって高速になります。

    でも、SPDY は TLS の上にあるのだから、HTTP と違って SSL のネゴシエーションが必要になるではないか、
    という指摘は当然あると思います。これは、その通りですが、CA の証明書を添付する OCSP stapling などに
    より、オーバーヘッドを削減する努力がなされているので、ネゴシエーションのオーバーヘッドはあるものの、
    以前よりはよくなっているように思います。

    私も SPDY を愛用しているクチですが、私の感覚では、ちゃんと運用されているサイトであればそれほど
    大きな差はないように思います。CSS や JS を結合しておらずアイコンや小さい画像をスプライト化していない
    サイトだと小さいファイルを多数ダウンロードすることになりますが、それらの数が多いと SPDY の方が
    速くなるように感じています。そのようなサイトだと、前述のように HTTP だと最大6コネクションの制限があり、
    SPDY だとそれ以上の並行化が可能だからではないかと思います。SPDY が有利になるようなベンチマークも、
    作ろうと思えば作れるんじゃないでしょうかね。

  • by Anonymous Coward on 2014年12月09日 12時53分 (#2724824)
    なのかな?
    • by Anonymous Coward

      そんなことはないでしょう。
      SPDY on HTTPみたいな実装が出てくれば逆転するんじゃないですかね。

    • by Anonymous Coward

      全てのアクセスをSPDYにしたほうがいい
      ってことでしょ

    • by Anonymous Coward

      httpプロトコルは単純なかわりに無駄が多いのでより高度なhttpsプロトコルの方が高速になります。

      • by Anonymous Coward

        へぇ。じゃあ、なんで今までhttpsの方が遅かったの?

        # とマジレスしてみたり。

  • by Anonymous Coward on 2014年12月09日 13時46分 (#2724865)

    サーバ側の対応は充分なの?
    https://srad.jp/ [srad.jp] とか、そもそもhttpsでアクセスすることすらできないんだけど。

    • by Anonymous Coward

      ほんとだ、今更気付いた。
      /.-JってHTTPでログインさせるんだね。
      (ちなみに本家/.はさすがにログインだけはHTTPSだった)

      • by Anonymous Coward

        スラド程度なら漏れてもいいかなと思ってる自分がいる。
        もちろん、IDPASSの使い回しはしない。

  • by Anonymous Coward on 2014年12月09日 14時04分 (#2724880)

    まずそもそもHTTPSはキャッシュできない。
    キャッシュできるように設定することもできるが、常識的にそんなことをしてる奴は居ないだろうし、例えProxyを強制してるようなところでもHTTPSだけはalways_directかつno_cacheとか当たり前。
    ディスクにもメモリにもProxyにすら存在しないので、例え同じデータでも毎回毎回取りに行かなきゃならん。

    無駄に何度も転送することになるので、個人サイト等ではサーバ自体が転送量制限に達っして終了する場合も多いし、転送量制限どころか負荷制限に引っかかって終了する可能性すらある。

    次に、TCPが通信を開始する前に3ウェイハンドシェイクを必須とするのはご存知の通りだが、HTTPSは更に3往復必要になる。
    言わば9ウェイハンドシェイク。

    また9ウェイハンドシェクの後に、実際に通信を初める前にその証明書が失効していなかを調べるOCSPの遅さも無視できない。

    実際に通信が開始するまでの遅延は絶対に短くならないし、転送量や負荷も間違いなく増大する。
    つまり、いくらSPDYが効率的に転送可能だろうと無意味。

    こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
    我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
    妄言も大概にしろ。と言いたい。

    • 一点だけ。httpsでも、キャッシュされます。

      http://news.mynavi.jp/articles/2011/02/02/https-stories/ [mynavi.jp]

      親コメント
      • by Anonymous Coward

        この手の人にそういうの書いても無駄だよ。
        どうせ「ボクの周りではみたことないもん!例外だもん!」とか返ってくるだけ。

        • by Anonymous Coward

          周りの罪もない人が一見もっともらしい自信たっぷりなコメントに騙されるのを防ぐ意味がある。一対一でメッセージ送り合ってるんじゃないんだから。

    • by Anonymous Coward

      >こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。

      わはは。あったあった。

      by 古参C++プログラマ

    • by Anonymous Coward

      >こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
      やれやれ。いかにもな老害のご意見。

      >内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
      たとえばボトルネックを解析して最適化されたインライン展開の機能は無視ですか。
      「局所部分限定ならC++/CでもJavaと変わりません」とやられてるようなもん。

      >我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、
      ダウト。
      特にサーバーサイドでは起動終了のコストなんて無視できるようになる。

      PC上で言えば、IEみたいに常駐するという禁じ手があるんだよな。
      #まあ立ち上がりが遅いという問題については言語に関係無くダウンロードする
      #コードサイズの問題があるので、MS-Officeみたいにでかいとどうしても遅くなる。

      • by Anonymous Coward

        そういう話を考慮しても、C/C++のほうが速いんだよ。
        http://benchmarksgame.alioth.debian.org/u64q/java.php [debian.org]

        けど、Javaの黎明期に、意図的に有利なコードで比較してJavaのほうが速いと主張する、いんちきベンチマークがよくあったんだよ。

        • by Anonymous Coward

          いんちきベンチマーク := Javaに有利なコード
          公正なベンチマーク := C/C++に有利なコード

          という用語の定義を最初に書かないと。

      • by Anonymous Coward

        「全体的な評価」のくだりはJavaとCを比べるときはそうすべき、という話。
        今回のHTTP v HTTPS+SPDYで言うと、読み込み速度だけでなく、通信を始める前のハンドシェイクやその他もろもろの時間も計算に入れるべき、と#2724880は言っています。
        よってあなたの反論は的外れかと。

        #わたしもJavaは嫌いですが、そこはオフトピですから、あまり触れないようにしましょう。

      • by Anonymous Coward
        起動終了に関しては、ウィルススキャンソフトがjreのjar解凍しにいくからしょうがない。javaも被害者な気がする。

        # ハッシュ値でなんとかならんのかと思うよ。
    • by Anonymous Coward

      >こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
      >我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
      >妄言も大概にしろ。と言いたい。

      その御蔭で我々は、試行の条件と適用場面をちゃんと確認する癖が付いたのではないかね?
      感謝して頂きたい。 by Java厨

      # まぁ、冗談はさておきJavaを使ってる人間ほど、シビアに使い所を見てると思うよ。
      # 開始終了が遅いのだから、開始終了関係ない状況で使おうぜ、とサーバ用途が伸びたりとかね。
      # 早くないからこそどう使うのかとかアルゴリズムを気にしたりもするし。
      # このベンチマークは、少し胡散臭い所があるのには賛成だよ。
      # 本当は素のHTTPSとも比べてやったり別のテストケースも見て考えさせるべきだわな。

      • by Anonymous Coward

        ># 早くないからこそどう使うのかとかアルゴリズムを気にしたりもするし。

        ちまちま手動で最適化してた時代に逆戻りしてるような気が…

        • by Anonymous Coward

          いくら富豪プログラミングが当たり前な世の中になっても
          アルゴリズムの選定が重要になる局面は残るよ。

          暗号化が一般になりかつ計算機の性能が上がるにしたがって
          いかに遅いアルゴリズムを開発するかが勝負だったりすることもありますしね。
          気にする局面は減るとは思いますが、それでもクリティカルな部分では残ります。

  • by Anonymous Coward on 2014年12月09日 15時20分 (#2724930)

    SSLの暗号化に専用ハードウェアをつかっているならいいんですが、
    HTTP/HTTPS併用サーバにしている場合は、暗号化の計算処理が重いのです。

    ですので、通常は、HTTPSの接続数をHTTPより少なくしてあるかと。

  • by Anonymous Coward on 2014年12月09日 15時25分 (#2724934)

    暗号化・復号化は時間的コストが高いって言われてましたけど、SPDYで送受信まとめればコスト以上のベネフィットがあるんですね。

    趣味のサーバは Apache HTTP Server 2.2 で mod_Spdy を使っていましたが、問題ないと思って 2.4 にアップデートしたら、 mod_Spdy が対応していない。結局,素の https で通信しているから、遅くなっているんだろうな。

    • by Anonymous Coward

      復号化ってどんなことをするのですか?

  • by Anonymous Coward on 2014年12月09日 15時37分 (#2724946)

    Chrome39 (x64), Ctrl+F5 で
    http : 9.844秒
    https : 2.586秒

    Firefox 34, Ctrl+F5にて
    http : 18.544秒
    https : 27.803秒

    Firefox 34, F5にて
    http : 9.336秒
    https : 3.217秒

    という結果でした。

    ちなみに画像にはExpiresヘッダはなく、
    URLパラメーターによってキャッシュは無効化されているため、
    Ctrl+F5とF5で通信内容に差はありません。
    (200にて画像をダウンロード)

    サーバーまでのRTTが148ms, httpが6並列接続なので、
    http結果 = RTTに由来する通信遅延(148ms * 360 / 6)
     + 帯域幅に由来する通信遅延 + 処理遅延
    https結果 = RTTに由来する通信遅延(148ms)
     + 帯域幅に由来する通信遅延 + 処理遅延
    ということで、FirefoxのCtrl+F5以外はだいたい納得のいく結果でした。

    FirefoxのCtrl+F5の結果は、挙動を観察するにクライアントのCPUに律速されているようですので、
    Firefoxの実装の問題ではないかと思います。

    • by takehora (12309) on 2014年12月10日 0時11分 (#2725272) 日記

      http://it.srad.jp/comments.pl?sid=647117&cid=2725256 [srad.jp]
      に書きましたが、確かに、Expires Headerは無かったです。これは、Firefoxで自動で付けるそうです。
      失礼しました。

      Chromeのディベロッパーツールを開いて、「Disable cache」にチェックを入れて、HTTP、HTTPSをクリックして読み込ませれば、スーパーリロードの処理に依らず、秒数をご確認頂けます。

      私の環境においては、HTTPSの方が遅いです。
      後日、一次ISPで定常計測してみて、それなりのデータ量を取って比較して、レポートをブログに書いてみます。

      親コメント
    • by Anonymous Coward

      Firefoxには4タイプのリロードがある、って話を思い出しました。

    • by Anonymous Coward

      ChromeはCtrlじゃなくてShiftですよ。

  • by Anonymous Coward on 2014年12月09日 16時14分 (#2724972)

    全てのHTTP通信がHTTPSになり、暗号化必須になったら、その暗号化と復号に費やされるエネルギーはどのくらいになるのだろう?

    • by deleted user (13014) on 2014年12月09日 18時12分 (#2725056)

      Got SSL? [youtube.com], TLS All the Things! - Security with Performance [youtube.com], HTTPS Everywhere [youtube.com]. Google の人に言わせれば「言い訳無用とにかく使え」ということですね。今のモバイル機器を含めたコンピューター環境を見れば、オーバーヘッドはない。

      たしかに、重たいDOM/CSSの仕様に厳格に則ることや、画像、動画をデコードすることに比べれば、どうということはないんでしょう。

      親コメント
    • by Anonymous Coward

      環境のためを思うなら、SPDYをHTTPにも対応したほうがよさそうだよね・・・
      ウェブの中で本当に暗号化すべきページってそんなに多くないよ・・・たぶん10%未満。

    • by Anonymous Coward

      エロサイトの暗号化と複合化に費やされるエネルギーが一人エッチするエネルギーより大きいのでオナ禁させられる未来

      • by Anonymous Coward

        複合化したら発電量は増える気がします。
        一つの要素を突き詰めた作品もいいですが、複数の要素を合わせた作品もいいものです。

        ところで、暗号化とはモザイクのことでしょうか?

typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...