多くのサイトでは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より高速になる、という状況は今後も続くと考えられるそうだ。
錯誤に陥らせる内容 (スコア:5, 参考になる)
まず、参照されている元のコンテンツ「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が最速という結果になっています。
Re:錯誤に陥らせる内容 (スコア:1)
質問です。「HTTP vs HTTPS Test」で読み込む画像のURL には，キャッシュ対策のパラメータがランダム（規則あり？）についています。
これでもキャッシュされるのでしょうか？
あと，私の環境ではイメージの応答ヘッダをみるとEtag はついていますが Expires は含まれていません。
MacOSX 10.9 の Firefox 34.0 です。
相手に合わせて、応答をかえているのでしょうか。
他の皆さんどうですか？
Re:錯誤に陥らせる内容 (スコア:2)
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の方が遅いことには変わりはないです。
Re: (スコア:0)
> Query String付きのURLの画像をキャッシュするかどうかについては、FirefoxはEtagが付与されているものについてはキャッシュするそうです。
下記
> 「その URI のスキームと (存在する場合は) 命名オーソリティの範囲内のリソースを識別するために利用される。」
にあるとおり、各画像には読み込みごとに異なるクエリストリングが付与されるため、
それぞれ異なるリソースとして扱われるので、キャッシュはヒットしません。
そもそもIf-None-Match等のヘッダも送信されていません。
> では、仕様としてはどうか?という話としては、2005年にリリースされたRFC3986では、「その URI のスキームと (存在する場合は) 命名オーソリティの範
Re: (スコア:0)
このＰＣだと、Ctrl+F5でよませるとHTTPS+SPDYの方が遅かった。
通信の並行化やら何やら (スコア:1)
元記事の図を一見するだけだと「HTTP では１つのソケット経由で逐次的に３往復の通信が必要なところ、
SPDY を使用すると並行化できるよ」みたいな印象を受けますが、正確には、HTTP でも通信は並行化されます。
最近のブラウザは１つのホストに対して６つ程度のコネクションを張って通信しますからね。
（HTTP/1.1 の RFC には、２つまでにしといてね、って書いてあった気がしますが、まぁ気にしないでおきましょう）
とはいえ、それでも１つ１つのコネクションには TCP 接続を確立するためのパケットの往復が必要ですし、
確立した後も TCP のスロースタートにより、最初はゆっくりとしか通信になってしまいます。
これに対し、SPDY だと１つのコネクションだけを張って、その上にセッションみたいな層を用意し、
その上で並行して複数の HTTP/1.1 相当の通信をします。だから TCP のコネクションは１つですみますし、
全部の通信が１つのコネクション内で行われるので TCP スロースタートもはやく暖まって高速になります。
でも、SPDY は TLS の上にあるのだから、HTTP と違って SSL のネゴシエーションが必要になるではないか、
という指摘は当然あると思います。これは、その通りですが、CA の証明書を添付する OCSP stapling などに
より、オーバーヘッドを削減する努力がなされているので、ネゴシエーションのオーバーヘッドはあるものの、
以前よりはよくなっているように思います。
私も SPDY を愛用しているクチですが、私の感覚では、ちゃんと運用されているサイトであればそれほど
大きな差はないように思います。CSS や JS を結合しておらずアイコンや小さい画像をスプライト化していない
サイトだと小さいファイルを多数ダウンロードすることになりますが、それらの数が多いと SPDY の方が
速くなるように感じています。そのようなサイトだと、前述のように HTTP だと最大６コネクションの制限があり、
SPDY だとそれ以上の並行化が可能だからではないかと思います。SPDY が有利になるようなベンチマークも、
作ろうと思えば作れるんじゃないでしょうかね。
Re: (スコア:0)
この https://www.httpvshttps.com/ [httpvshttps.com] がまさにそのような SPDY 有利なベンチマークサイトですね。
Re: (スコア:0)
（HTTP/1.1 の RFC には、２つまでにしといてね、って書いてあった気がしますが、まぁ気にしないでおきましょう）
HTTP/1.1、公開から15年の時を経て改訂
http://it.srad.jp/story/14/06/11/0520230 [srad.jp]
http://it.srad.jp/comments.pl?sid=633471&cid=2619341 [srad.jp]
全てのアクセスをHTTPSにしたほうがいいてこと？ (スコア:0)
Re: (スコア:0)
そんなことはないでしょう。
SPDY on HTTPみたいな実装が出てくれば逆転するんじゃないですかね。
Re: (スコア:0)
全てのアクセスをSPDYにしたほうがいい
ってことでしょ
Re: (スコア:0)
httpプロトコルは単純なかわりに無駄が多いのでより高度なhttpsプロトコルの方が高速になります。
Re: (スコア:0)
へぇ。じゃあ、なんで今までhttpsの方が遅かったの？
# とマジレスしてみたり。
ブラウザよりも (スコア:0)
サーバ側の対応は充分なの？
https://srad.jp/ [srad.jp] とか、そもそもhttpsでアクセスすることすらできないんだけど。
Re: (スコア:0)
ほんとだ、今更気付いた。
/.-JってHTTPでログインさせるんだね。
(ちなみに本家/.はさすがにログインだけはHTTPSだった)
Re: (スコア:0)
スラド程度なら漏れてもいいかなと思ってる自分がいる。
もちろん、IDPASSの使い回しはしない。
NE-YO (スコア:0)
まずそもそもHTTPSはキャッシュできない。
キャッシュできるように設定することもできるが、常識的にそんなことをしてる奴は居ないだろうし、例えProxyを強制してるようなところでもHTTPSだけはalways_directかつno_cacheとか当たり前。
ディスクにもメモリにもProxyにすら存在しないので、例え同じデータでも毎回毎回取りに行かなきゃならん。
無駄に何度も転送することになるので、個人サイト等ではサーバ自体が転送量制限に達っして終了する場合も多いし、転送量制限どころか負荷制限に引っかかって終了する可能性すらある。
次に、TCPが通信を開始する前に3ウェイハンドシェイクを必須とするのはご存知の通りだが、HTTPSは更に3往復必要になる。
言わば9ウェイハンドシェイク。
また9ウェイハンドシェクの後に、実際に通信を初める前にその証明書が失効していなかを調べるOCSPの遅さも無視できない。
実際に通信が開始するまでの遅延は絶対に短くならないし、転送量や負荷も間違いなく増大する。
つまり、いくらSPDYが効率的に転送可能だろうと無意味。
こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
妄言も大概にしろ。と言いたい。
httpsでもキャッシュされます (スコア:2)
一点だけ。httpsでも、キャッシュされます。
http://news.mynavi.jp/articles/2011/02/02/https-stories/ [mynavi.jp]
Re: (スコア:0)
この手の人にそういうの書いても無駄だよ。
どうせ「ボクの周りではみたことないもん！例外だもん！」とか返ってくるだけ。
Re: (スコア:0)
周りの罪もない人が一見もっともらしい自信たっぷりなコメントに騙されるのを防ぐ意味がある。一対一でメッセージ送り合ってるんじゃないんだから。
Re: (スコア:0)
>こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
わはは。あったあった。
by 古参C++プログラマ
Re: (スコア:0)
＞こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
やれやれ。いかにもな老害のご意見。
＞内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
たとえばボトルネックを解析して最適化されたインライン展開の機能は無視ですか。
「局所部分限定ならC++／CでもJavaと変わりません」とやられてるようなもん。
＞我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、
ダウト。
特にサーバーサイドでは起動終了のコストなんて無視できるようになる。
PC上で言えば、IEみたいに常駐するという禁じ手があるんだよな。
＃まあ立ち上がりが遅いという問題については言語に関係無くダウンロードする
＃コードサイズの問題があるので、MS-Officeみたいにでかいとどうしても遅くなる。
Re: (スコア:0)
そういう話を考慮しても、C/C++のほうが速いんだよ。
http://benchmarksgame.alioth.debian.org/u64q/java.php [debian.org]
けど、Javaの黎明期に、意図的に有利なコードで比較してJavaのほうが速いと主張する、いんちきベンチマークがよくあったんだよ。
Re: (スコア:0)
いんちきベンチマーク := Javaに有利なコード
公正なベンチマーク := C/C++に有利なコード
という用語の定義を最初に書かないと。
Re: (スコア:0)
「全体的な評価」のくだりはJavaとCを比べるときはそうすべき、という話。
今回のHTTP v HTTPS+SPDYで言うと、読み込み速度だけでなく、通信を始める前のハンドシェイクやその他もろもろの時間も計算に入れるべき、と#2724880は言っています。
よってあなたの反論は的外れかと。
#わたしもJavaは嫌いですが、そこはオフトピですから、あまり触れないようにしましょう。
Re: (スコア:0)
# ハッシュ値でなんとかならんのかと思うよ。
Re: (スコア:0)
>こんなのは、Java厨が良くやる「実はJavaってこんなにも速いんですよ」アピールと同じようなもん。
>我々はそのプログラムが実際に開始し、処理し、終了するまでの全体的な評価を求めているのに、内部処理の値だけ取ってきて「Cでするのと殆ど変わりません。」とかやられてるようなもん。
>妄言も大概にしろ。と言いたい。
その御蔭で我々は、試行の条件と適用場面をちゃんと確認する癖が付いたのではないかね？
感謝して頂きたい。 by Java厨
# まぁ、冗談はさておきJavaを使ってる人間ほど、シビアに使い所を見てると思うよ。
# 開始終了が遅いのだから、開始終了関係ない状況で使おうぜ、とサーバ用途が伸びたりとかね。
# 早くないからこそどう使うのかとかアルゴリズムを気にしたりもするし。
# このベンチマークは、少し胡散臭い所があるのには賛成だよ。
# 本当は素のHTTPSとも比べてやったり別のテストケースも見て考えさせるべきだわな。
Re: (スコア:0)
＞# 早くないからこそどう使うのかとかアルゴリズムを気にしたりもするし。
ちまちま手動で最適化してた時代に逆戻りしてるような気が…
Re: (スコア:0)
いくら富豪プログラミングが当たり前な世の中になっても
アルゴリズムの選定が重要になる局面は残るよ。
暗号化が一般になりかつ計算機の性能が上がるにしたがって
いかに遅いアルゴリズムを開発するかが勝負だったりすることもありますしね。
気にする局面は減るとは思いますが、それでもクリティカルな部分では残ります。
サーバー側からすると (スコア:0)
SSLの暗号化に専用ハードウェアをつかっているならいいんですが、
HTTP/HTTPS併用サーバにしている場合は、暗号化の計算処理が重いのです。
ですので、通常は、HTTPSの接続数をHTTPより少なくしてあるかと。
SPDY の利得は大きいのか (スコア:0)
暗号化・復号化は時間的コストが高いって言われてましたけど、SPDYで送受信まとめればコスト以上のベネフィットがあるんですね。
趣味のサーバは Apache HTTP Server 2.2 で mod_Spdy を使っていましたが、問題ないと思って 2.4 にアップデートしたら、 mod_Spdy が対応していない。結局，素の https で通信しているから、遅くなっているんだろうな。
Re: (スコア:0)
復号化ってどんなことをするのですか？
ご参考までに (スコア:0)
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の実装の問題ではないかと思います。
Re:ご参考までに (スコア:2)
http://it.srad.jp/comments.pl?sid=647117&cid=2725256 [srad.jp]
に書きましたが、確かに、Expires Headerは無かったです。これは、Firefoxで自動で付けるそうです。
失礼しました。
Chromeのディベロッパーツールを開いて、「Disable cache」にチェックを入れて、HTTP、HTTPSをクリックして読み込ませれば、スーパーリロードの処理に依らず、秒数をご確認頂けます。
私の環境においては、HTTPSの方が遅いです。
後日、一次ISPで定常計測してみて、それなりのデータ量を取って比較して、レポートをブログに書いてみます。
Re: (スコア:0)
Firefoxには4タイプのリロードがある、って話を思い出しました。
Re: (スコア:0)
ChromeはCtrlじゃなくてShiftですよ。
環境に優しくね！ (スコア:0)
全てのHTTP通信がHTTPSになり、暗号化必須になったら、その暗号化と復号に費やされるエネルギーはどのくらいになるのだろう？
Re:環境に優しくね！ (スコア:2)
Got SSL? [youtube.com], TLS All the Things! - Security with Performance [youtube.com], HTTPS Everywhere [youtube.com]. Google の人に言わせれば「言い訳無用とにかく使え」ということですね。今のモバイル機器を含めたコンピューター環境を見れば、オーバーヘッドはない。
たしかに、重たいDOM/CSSの仕様に厳格に則ることや、画像、動画をデコードすることに比べれば、どうということはないんでしょう。
Re: (スコア:0)
環境のためを思うなら、SPDYをHTTPにも対応したほうがよさそうだよね・・・
ウェブの中で本当に暗号化すべきページってそんなに多くないよ・・・たぶん10%未満。
Re: (スコア:0)
規格としては存在しているみたいだけど，有力なブラウザは実装しない方向になりそうですね。
https://www.mnot.net/blog/2014/01/04/strengthening_http_a_personal_view [mnot.net]
Re: (スコア:0)
エロサイトの暗号化と複合化に費やされるエネルギーが一人エッチするエネルギーより大きいのでオナ禁させられる未来
Re: (スコア:0)
複合化したら発電量は増える気がします。
一つの要素を突き詰めた作品もいいですが、複数の要素を合わせた作品もいいものです。
ところで、暗号化とはモザイクのことでしょうか？