射撃しつつ前転 RSSフィード

2013-01-08

なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか

 完全に釣りタイトルですけど中身は真面目に書くよ。

 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスTwitterFacebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。

 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。

なぜ遅くなるのか

 HTTPで通信する場合、クライアントサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを1往復させないといけないのである。パケットの往復にどれぐらい時間がかかるかはpingコマンドで簡単に確認できる。たとえば、ping www.kyoto-u.ac.jpとかコマンドを打つと、おそらくは京都にサーバがあるであろう京都大学のサイトにパケットが行って戻ってくる時間が計測できる。1往復で約30msぐらいだった。東京-京都間(500kmぐらい?)で30msということを覚えておきたい。

 30ms、つまり0.03秒であればそんなに大したことのない数字である。

 実は、HTTPSでは通信をはじめる前に必要なパケットのやり取りが3往復になる。3往復するとなると0.09秒、もうほとんど0.1秒待たされることになる。ちょっとそろそろ人間が知覚できるぐらいの時間になってきた。

 他にも悪いニュースがある。SSLの証明書にはOCSP(Online Certificate Status Protocol)という証明書を失効させるための仕組みがあるのだがこれが遅いのである。この仕組みを要約すると、証明書を受け取ったら実際に通信を始める前にOCSPレスポンダと呼ばれる失効情報管理するサーバに対して、証明書が失効していないかどうかを確認する、というものである。別のサーバに問い合わせが発生するため、DNS名前を解決したり、サーバにリクエストを飛ばしたり、といった手順が必要になり、通信の開始が遅れるわけである。安いSSL証明書を使うとOCSPレスポンダが海外にしかなかったりして悪影響が大きい。OCSPは最近ブラウザであればほぼ確実に対応している。

 なんでOCSPのような仕組みが必要なのか。証明書というのは技術的には公開鍵暗号公開鍵側なので、対応する秘密鍵漏れた場合には悪用を防ぐために失効させる仕組みがほしい、ということでこんな状況になっている。以前は失効した鍵のデータベース(Certification Revocation List)をダウンロードするという方式だったようだが、最近のブラウザは全部OCSPに移行したみたいだ。

 ここまでの説明を繰り返すと、HTTPSで通信を行うことになると、TCP/IPの分で1往復、SSLの分で2往復の遅れが発生し、OCSPチェックで2往復から4往復程度はパケットの往復が発生する。4往復、というのは、安い証明書だと中間証明書というものが入っており、中間証明書にもOCSPチェックが必要だからである。OCSPチェックで海外にリクエストが行く場合はこの往復は30msとかそんなかわいい数字ではなく、1往復で200msぐらいかかったりする。実際にはOCSPには300ms程度はかかるのがふつうみたいだ。

 という訳で、SSLを使うと通信が始まるまで、HTTPの場合と比べ、最低でも120ms程度の遅延が発生することを覚悟しないといけないのである。

 Googleでは0.4秒レスポンスが遅くなるとクエリ件数が0.6%程度減少するそうなので、うん、120ms程度だとそんなに気にするほどじゃないかな……。ただ、OCSPチェックで0.5秒とかかかると、ちょっと無視できない感じになってくる。

速くする方法はあるのか

 というわけで、SSLを使うと、レイテンシがある程度増えることは仕方がない。しかし、多少の対策は取り様がある。以下ではいくつかを解説する。

 1つめはSSL False Startと呼ばれるSSLの通信開始方式である。これはSSLで必要なパケットの往復回数を2回から1回に減らしてくれる。ただ、ブラウザ側がサポートしていないと使えない。Google Chromeではデフォルト有効化されている。Firefoxでは実装されているがデフォルト設定では無効になっている。ユーザがGoogle Chromeを使っていることを祈るだけなので、対策とは呼べないが、有効ではある。

 2つめは、OCSPステープリングと呼ばれるTLS拡張である。これは、OCSPレスポンダの返答をあらかじめサーバ側がキャッシュし、通信時に証明書と一緒にクライアントに送りつけることで、クライアントではOCSPのチェックを省略できる、というものである。証明書と一緒にホチキス留めしてしまうイメージなのでステープリングと言うのだろう。自分で自分の使ってる証明書が正しいと言ってるだけで安心できないのでは、と一瞬思ってしまうのだが、OCSPレスポンダの返答は改竄できないようになっているので、これでも大丈夫である。これを使うとOCSPチェックが省略できる。Apacheであれば2.4系列であれば対応している。Nginxはまだ安定版ではサポートしてないようだ。開発版ではサポートしている。OCSPステープリングは強力だが、1つの証明書に対してしかステープリングできない。このため、中間証明書が使われている場合、OSCPチェックを完全に省略できるわけではない。

 この他に有効な対策としてはKeepAliveの秒数や同時接続数の設定を見直すことが挙げられる。HTTPセッションを使いまわすことができたら、上記のぐちゃぐちゃとしたパケットの往復は全部すっ飛ばすことができるからである。ただし、初回接続時には効かない。

蛇足

 OCSP staplingについて調べると、たぶん上の方にCloudflareとGlobalSignの提携でSSLが速くなるよ〜、みたいな話がtechcrunchに載っていたがのが出てくるのだが、あの記事には間違いがいくつかある。というか、2つの話をごっちゃにしてしまって、結果として間違いが生じている。1つめはCloudflareがSSL経由でファイルをデリバリーする際にOCSP staplingを行うようにして高速に配信できるようになったよという話で、これにはGlobalSign側のシステムには何ら変更は生じていない。2つめはGlobalSignがCloudFlareを使ってOCSPサーバを世界中に配備したよという話で、こちらはOCSP staplingとは関係がない。(OCSP staplingを使うならばOCSPサーバは多少遅くても問題はない。いや、実際には中間証明書の問題があるから遅いと問題なんだけど。メジャーな中間証明書ってあんまり多くないはずなので比較的問題は少ない……はず……。)時系列が非常に近く、話も複雑なので仕方がないと思う。CloudFlareのブログ記事の冒頭にOCSP staplingの話が載っていたので誰かが勘違いしたのだろう。

 調べていて最初理屈が通らずに混乱したので、同じ道を通る人が減るようにここに書いておく。

参考URL

まとめ

  • サイトをSSL化すると初回の接続時に0.x秒程度の遅延が発生することになる。
  • Global SignのSSL証明書を使うとOCSPサーバがCDNで世界中に配備されてるのでOCSPチェックがだいぶ速い。
    • でも個人で買うにはちょっと高いんだよね、GlobalSign……。
  • 初回接続時のことはあきらめて、Keep Aliveの設定とかを見直すのがいいかなと思う。
  • とりあえず、SSL使う場合はどんだけ遅くなるのかはあらかじめテストして確認したほうがよい。

"高速文字列解析の世界"を読んだ

 高速文字列解析の世界というタイトルからは、どんな中身なのかあまり伝わってこないので、どんなことが書いてある本なのか、中身をちょっと紹介してみる。

 1章、2章は概観や準備であり、3章からが本番なのだが、Burrows Wheeler Transform、簡潔データ構造、ウェーブレットツリー、データ圧縮、全文検索テキストマイニングのためのデータ構造、という章題になっている。

 何に使うのかという目的ベースで考えると、この本に載っているのは、データ圧縮、情報検索とテキストマイニングの基盤技術である(データ圧縮については基盤と言うよりはそのものだが)。ただ、この本には本当に基盤技術の話しか載っていないので、「この本で情報検索はバッチリだぜ!!」というような訳にはいかない。テキストマイニングに関しても同様である。別途入門書を読むなりしないと、より高次元(ここでの高低は技術の積み重ねの高低であり、難しさの高低ではない)の知識を手に入れることはできない。

 というわけで、全くの初心者にこの本をおすすめするというわけには行かない(基盤側の技術についてから上側の機能を推測できるようなレベルの人ならば話は別で、そういう人もいっぱいいるとは思うけれど)のだが、初心者向けの本、例えば 情報検索の基礎とか検索エンジンはなぜ見つけるのか ―知っておきたいウェブ情報検索の基礎知識のような本を読んだけど、次に何を読めばいいのだろう、というような人に、これまではThe Burrows-wheeler Transform: Data Compression, Suffix Arrays, and Pattern Matching のような洋書を薦めるしかなかった(もしくは「SIGIRの論文とか読むといいよ?」と言うぐらいか)のだが、これからは多少ハードルを下げ、日本語の本を薦めることができるというわけだ。あと、The Burrows-wheeler Transformの方は読んでないけど、たぶんこっちの方が新しいことが書いてある。Wavelet Matrixとか。

 というのが一般的な話だと思うのだが、個人的には前から読みたかった話が色々と書いてある。以下にまとまりのない感じで感想を述べる。

 XBWはとりあえず理解した。XBWのアイデアは賢い。BWT拡張になっていてLF-mappingが成り立つのである。賢い。賢いがLOUDSと比べてどれぐらい速いんだろうか。ちょっと気になる。あと、marisa-trieで使ってる再帰的Trie分解と組み合わせることができるし、パトリシア化もできそうなのだが、実装するとものすごく辛いだろうなぁ……。

 透過的符号の話とかも面白い。透過的符号というのは、ランダムな位置から効率よく復元できる符号化方法で、書籍のほうで紹介されている手法では、ほとんどの値が小さくてたまにおっきな数字が混ざってる、みたいな配列をこれで符号化するとサイズが小さくなって速度もあんまり落ちない。実装も簡単そう。

 ウェーブレットツリーはどういうデータ構造なのかはだいたい知ってるのだが、いろいろな操作ができるという事はよく知らないのでこれから勉強したい。

 接尾辞配列をInduced Sortingで作る話は難しい。寝る前にちょろちょろ読んでるのでは理解できなさそうだ。紙と鉛筆自分で配列書いてみないとしんどい

 まとめると、情報検索やテキストマイニングなどの新しい基盤技術に興味のある人、データ圧縮に興味のある人におすすめの本であると言える。

2005 | 04 | 05 | 06 |
2006 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 02 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 03 | 05 | 06 | 11 |
2013 | 01 | 05 |