SPDYの話 ありえるえりあ（情報元のブックマーク数）
一段と解析がしにくい世の中に。
SPDY開発チームがapacheモジュールでmod_spdyを作っているようです。
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はレスポンスの順序が直列化される制約を外すことで問題を解決しようとします。問題の根源を断つ解法です。これで解決できれば、上記のような「ハイパフォーマンスなんとか」はバッドノウハウになります。
