twitterが spdy/3.1 の試験を始めてます

はじめに、

先日 @tatsuhiro_t さんのつぶやきで見つけたのですが、twitter が spdy/3.1 の試験をしているようです。

ChromiumのコミットログからGoogleがspdy/3.1を実装したのは気づいていましたが、www.google.comを調べても spdy/3 までしか提供されていないので内部で試験中なんだろうなと思ってました。
Googleではなく twitter がインターネット向けに spdy/3.1 のフィールド試験を最初に始めたというのは驚きです。

さっそく twitter からの NPNリストを確認しましたが、その時は自前の環境では twitter から spdy/3 しか確認できませんでした。最近はほぼ毎回 spdy/3.1 が来ているようなので大規模な試験が始まったんではないかと思います。

そして、ちょうど先週末 Chromium で Flow Control の状況が chrome://net-internals/#spdy で確認できるようになりました。
"Add session flow control data to SPDY info in net-internals (Closed) "
なので、ちょうどタイミング的に spdy/3.1 について触れてもいいかなと思い、手元で確認したことを書いてみたいと思います。

実は明日の SPDY&WS 勉強会（仮）で、本当は Node.jsで作った spdy のベンチマークサイトと、Server push の話をする予定でしたが、まだスライド書いていません。前日まで当初の予定にない flow control ネタを書いてしまい、どうしようかと途方に暮れてます。まぁなんとか時間にあうよう合わせ技にするかもしれません。

なお spdy/3.1 は、ちゃんとした仕様書に基づくバージョンではなく、spdy/4 の一部機能の先行試験用のプライベートバージョンだと思われます。このブログを見て、もしご自身で試される場合は、twitter社への迷惑やシステムリスク等を考慮の上、自己責任でお願いします。

SPDY/3.1 とは、

SPDY/3.1 については、既にid:ASnoKaze さんが chromeに実装されたSPDY/3.1についてでspdy/3.1 の使い方・実装内容が書かれていますので、詳しくはそちらを参考にして下さい。

spdy/3 で導入された per-stream flow control に加えて、spdy/4 では per-session flow control の導入が議論されています。spdy/3.1 はこの per-session flow control の機能を先行的に試験するためだけのバージョンの様です。使い方は、 --enable-spdy31 のオプション付けて起動するだけです。

今回 Chrome Canary を使って見てみます。

twitter 向けの spdy 接続が spdy/3.1 になっているのがわかります。後半の3つのフィールド、Send window, Receive window, Unacked received data が per-session flow control 向けに追加された統計情報です。

次に実際の per-session flow control の様子を見てみましょう。

赤下線の SPDY_SESSION_SENT_WINDOW_UPDATE_FRAME が per-session flow control のウィンドウサイズ値を決めたところです。今回 per-stream と同じく 10Mbyte の値になっています。

この per-session のウィンドウサイズがどう変化していくでしょうか？追ってみます。

赤線内を見てわかるようデータが来るとそのデータサイズ分だけウィンドウサイズが減っていきます。per-session のウィンドウサイズは複数のストリームで共有されているので、これが０になったら WINDOW_UPDATE が来るまで送信ストップになります。

私のタイムラインをずっと掘り下げていったのですが10メガに達する前にセッションが終わってしまいました。うーん、やっぱりもっと多数のフォロー数がないとウィンドウサイズを使い切れないうちに終わっちゃいますね。

なぜ Per-session Flow Control が必要なのか？

そもそも flow control とは、spdy/3 から導入された新機能です。それは以下の図にあるよう Buffer Bloat と HOL(Head of Line) Blocking 問題を解決するために採用されました。

spdy/3 では下図のように per-stream (ストリーム毎に） flow control の仕組みを設けました。

Google の環境である環境では性能が向上したという結果が報告されました。ただ、Googleは初期において Chrome の初期ウィンドウサイズを数十キロバイト程度の小さなものにして細かく制御できるようにしてました。

しかし、Firefox は 256MByte の大きな初期ウィンドウサイズを実装したところ、性能が倍近くFirefoxの方が高いという結果が出てしまいました。
"SPDY/3 Flow Control Comparisons"

その後の試験や議論から per-stream flow control は、以下の課題を持っているということがわかりました。

結局 Google は Chrome の初期ウィンドウサイズを 10Mbyte に増加させることになりました。
" Increase Chrome SPDY/3 stream receive window to 10MB. (Closed) "
今度は、大きなウィンドウサイズを持つ複数のストリームが、全体の帯域を食いつぶす恐れがあります。

そこで spdy/4 では、 per-session flow control の導入の検討が始まりました。

per-session flow control を導入すると複数ストリームが含まれるSPDYセッション全体全体のウィンドウサイズを制限できます。per-stream も廃止の提案がありましたが、各ストリームに関しては利用目的に合わせて利用するということで残っています。（先の Buffer Bloat や HOL Blocking 問題のために必要であるとの判断から）

結局、 per-session と per-stream の2段階のフロー制御を導入することで、より効率的にフロー制御ができるということです。

いよいよ明日は SPDY&WS勉強会（仮）

いよいよ明日 3月28日（木）19時より神保町のIIJ本社大会議室で SPDY & WS 勉強会 (仮)が開催されます。会場準備の都合上、当初の開始時間より30分遅れての19時から始まりますのでご注意ください。
尚、250名近くの方に参加申し込みをしていただき、多数の補欠の方がお待ちです。ご都合の悪い方は早めのキャンセルをお願いいたします。また、Ust中継も用意する予定です。（一部資料＋音声のみの中継）
Ust中継URL http://www.ustream.tv/channel/spdy-ws
残念ながら補欠で繰り上がらなかった方はこちらの方をご利用ください。

100名近い勉強会の会場準備をするのは初めての経験ですが、社内で快く協力を申し出てくれた8名のボランティアと供にこの勉強会をホストさせて頂きます。明日は皆さんのお越しをお待ちしています。