Google の SPDY ベンチマークに関する一考察

Google さんからのブログ記事 モバイルネットワークにおける SPDY のパフォーマンス は４月末に元記事が出ていたのに、すっかり見逃していて日本語訳が出るまで気づきませんでした。元記事を読むと、ベンチを取る環境の構築が徹底していてさすが Google と感心させられます。特にHTTPサーバをSPDYサーバに変換している Google FrontEnd (GFE) server は一般に公開してもらえないのかなと願ってたりします。

このベンチマーク自体は、箱庭環境を作って 77URL サイトに対して Chrome for Android のページ読み込み速度を SPDY/HTTP で比較をしています。結果、全体統計で1.3倍の速度向上が見られたという結論になっています。

この1.3倍という数字が大きいか小さいかは人によって判断が分かれるかと思いますが、元記事 SPDY Performance on Mobile Networks で一つのサイト(Harvard大学のwikipedia ページ）の読み込み時間のウォーターフォール図(figure3,4)が示されています。

この図が SPDY の特徴をよく表しているので、今回少し考察してみたいと思います。

SPDY による読み込み速度の向上効果が一番よく表れるサイトの一例は、 多数の画像が張られているサイトです。mod_spdy のサイトでは、 国旗の画像を多数貼り付けた World Flags mod_spdy Demo のデモサイトとビデオを用意しています。

今回の Google さんのブログで示された「Harvard大学のwikipedia ページ」の読み込みで SPDY の効果が最もあらわれているところは、 upload.wikipedia.org から画像を26ファイル GET しているところになります。その部分だけ拡大比較した図を下記に示します。

推測ですが、おそらく図の紫色の部分はロード時間・グレーは画像のレンダリングプロセス時間、緑はTCPのハンドシェイク時間、オレンジはロードするまでの待ち時間を表しているのだと思われます。（SPDYに緑色のTCPハンドシェイク時間がみられませんが、ダウンロード時間に含まれているか既にSSL接続が確立しているかどちらかだと思われます。）

上図にコメントを書いていますが、HTTP接続の場合ブラウザが最大同時に6本サーバにTCP接続して画像をロードします。（緑色が5つしかないのは、1本は先に別画像の読み込みで接続されているため）26個の画像を6本のチャネルを使って順次ロードしているので、どうしてもロード待ちしているリクエストが存在します。下のリクエストほどオレンジの待ち時間が長くなっているのはその理由です。

他方、 SPDY ではSSLのTCP接続は1本しかありませんが、コントロールストリームを使いロードする複数のURLのGETリクエストを多重化してサーバに送ります。サーバ側は他の画像のロード状況を気にせず、データストリームとしてクライアント側に画像データを一気に送ることができます。左側のSPDYのウォーターフォールでは26個の画像ファイルが同時にダウンロードしている様子がわかると思います。

この図を比較してみると、SPDY を使って26個の画像をロードが完了するのはだいたい500[msec]程度、 HTTP ではロードの待ち時間込みで1.8[sec] 程度に見えます。この観点でいえば 「SPDYを使うとHTTPの約3倍の画像読み込み速度の向上が達成できた」ということになります。

さらに SPDY では、クライアントからのHTTPリクエストを待たずにあらかじめサーバからクライアントに対してURLとデータを送りつける「Server Push」というテクニックが使えます。（あらかじめサーバから送られたデータはキャッシュとしてクライアントに残ります。）
もし Server Push を行って SPDY によるページ読み込みの最適化を行ったら、読み込み時間のウォーターフォール図はおそらくこんな感じになるんじゃないかと想像します。（注： 画像は合成です。）

もし本当にこんな感じになるならページ読み込みの体感速度はめちゃくちゃ上がっているでしょうね。今後の SPDY の普及が楽しみです。