Personal tools
You are here: Home ブログ 井上 SPDYの話
« December 2010 »
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Recent entries
Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23
Herokuの発音 inoue 2010-12-20
雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18
IPA未踏のニュース inoue 2010-12-15
労基法とチキンゲーム inoue 2010-12-06
フロントエンドエンジニア inoue 2010-12-03
ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25
技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24
雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22
RESTの当惑 inoue 2010-11-22
「プログラマのためのUXチートシート」を作りました inoue 2010-11-19
「ビューティフルコード」を読みました inoue 2010-11-16
Categories
カテゴリなし
 
Document Actions

SPDYの話

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

SPDY開発チームがapacheモジュールで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で書き直します」
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/spdy/tbping

Re:SPDYの話

Posted by inoue at 2010-02-26 02:20
仕様書(ドラフト2版: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2)を読んでみました。

率直な感想を言うと、魅力を感じません。AJPもそうですが、基本的にバイナリプロトコルが好きではないせいかもしれません。

「If the server is initiating the stream, the Stream-ID must be even. If the client is initiating the stream, the Stream-ID must be odd.」は、変わっていて面白いと思ったのですが、何の意味があるのか分かりませんでした。
Add comment

You can add a comment by filling out the form below. Plain text formatting.

(Required)
(Required)
(Required)
This helps us prevent automated spamming.
Captcha Image


Copyright(C) 2001 - 2006 Ariel Networks, Inc. All rights reserved.