「世間ではGoogle Buzzが話題ですが」と書き始めようと思っていたら、もう誰もGoogle Buzzを話題にしていないような気がします。世の中の流れは速いのですが、世間をまったく気にせずSPDY(スピーディ)の話をします。

• http://dev.chromium.org/spdy/spdy-whitepaper

SPDY開発チームがapacheモジュールでmod_spdyを作っているようです。

• http://code.google.com/p/mod-spdy/

Apacheの実装(少なくともv2.2では、ひとつのスレッドはひとつのリクエスト処理を前提)とSPDYのモデルの差を埋めるのが大変なようです。

少しSPDYを見てみました。

以下、keep-aliveを前提にします。

HTTPの基本動作は、ひとつのリクエストを投げると対応するレスポンスが返るまで次のリクエストを投げません。HTTP1.1のパイプライン機能を使うと、レスポンスが返る前にリクエストを投げられます。とは言え、たとえば、リクエストA、B、Cの3つのリクエストを投げた場合に対応するレスポンスの順序が入れ替わることはありません。先頭のレスポンスサイズが大きくて遅いと、残りのレスポンスのサイズが小さくても先に戻ってくることはありません。

HTTPは、並列化と正反対の直列化の世界です。並列化する方法のひとつは、複数のTCP接続を確立することです。ただし、あまりに多数のTCP接続を確立するとサーバが悲鳴をあげるので、紳士協定により少数に抑えることになっています。

リクエストとレスポンスのやりとりが直列化されている問題に対して、「ハイパフォーマンスなんとか」と称するノウハウがあります。遅いレスポンスのせいで後続のレスポンスが詰まるのが問題の根源なので、ブラウザ側が欲しいレスポンスを先に受け取れるように、リクエストの順序を制御するノウハウです。

SPDYはレスポンスの順序が直列化される制約を外すことで問題を解決しようとします。問題の根源を断つ解法です。これで解決できれば、上記のような「ハイパフォーマンスなんとか」はバッドノウハウになります。

SPDYのサイトから特徴を引用しておきます。

• Multiplexed requests
• Prioritized requests
• Compressed headers
• Server pushed streams

最初の「Multiplexed requests」がリクエスト/レスポンスの直列化問題の制約を外す話です。2番目の「Prioritized requests」は近い話ですが、速く返ってきてほしいレスポンスを優先度として指定できる機能です。並列化して全部平等に遅くなることへの対策です。3番目の「Compressed headers」は完全に別次元の話です。新しいプロトコルなのでついでに入れたようにも見えます。4番目の「Server pushed streams」はリクエスト/レスポンスが並列化されれば、リクエストなしでレスポンスだけ(事実上、サーバ側からのプッシュ)があっても全体の複雑度はさして変わらない、といったところでしょうか。

FirewallがあるのでSPDYの普及は厳しいと思っていましたが、SSLだったら世の中のほとんどのFirewallをすり抜けます。いつになるか分かりませんが、未来のいつかはHTTP3.0だろうと思います。多くの人が似たような問題意識を持っているので、HTTP3.0はSPDY的なものかもしれません。もっとも、実はあまり想像できていません。たぶん10年先を見ようという志が足りないせいです。

ちなみに、mod_spdyの実装はC++です。Cで書かないとApache本家に取り込めない、と指摘があったら以下のような回答でした。

「C++でプロトタイピングして、後でCで書き直します」