Web表示の高速化を実現するSPDYとHTTP/2.0の標準化

はじめに

SPDY(スピーディと読みます)は、GoogleがWebの表示を高速化するために開発した、新しいプロトコルです。新しいと言っても、今後普及が見込まれるような新技術ではなく、既に実用化され多くの方が日常的に利用しています。
現在ChromeやFirefox、Operaのブラウザを使われている方は、Googleのサービスやtwitterにアクセスしていると、実は全く気付かないうちに、このプロトコルを利用しています。
SPDYは2010年6月にリリースされたChromeのバージョン6安定版からデフォルトで有効になっており、Chrome利用者はこの新技術を3年以上も利用していることになります。

一般のユーザはSPDYを使っているかどうか、どうしたらわかるのでしょうか？ Chromeでは、"SPDY Indicator"という便利な拡張機能を提供しています。また同種のツールは、FirefoxやOperaでも同じ名前で提供されています。この"SPDY Indicator"をインストールして、GoogleのサービスサイトやTwitter、Facebook、WordpressといったSPDY対応のWebサイトにアクセスすると、アドレスバーに緑の稲妻アイコンが表示され、ブラウザがSPDYを使っているかどうか一目でわかります。
最近では、ブラウザ側のSPDY対応に合わせて、apache、nginx、JettyといったWebサーバ側でもSPDYがサポートされるようになりました。現在これらのWebサーバをSSLで使っているサイトであれば、誰でも独自にSPDYを利用することが可能です。

これまでSPDYはGoogle独自の仕様でしたが、最近ではIETFで標準化を進める動きが始まりました。2014年春に仕様化を目指すHTTP/2.0では、現在SPDYの仕様をベースとして議論が進んでいます。
本記事では、このSPDYがどういう目的で開発され、どのような仕組みで、どんな効果をもたらしているのか、そして次世代のHTTP/2.0ではどうなるのかを解説します。

SPDYが開発された目的

現在インターネットで広く利用されているプロトコルは、Webで使われているHTTPです。2013年6月時点で利用されているHTTPのバージョンは1.1であり、これは1999年に仕様化されたものです。
しかし、この10年余でWebの利用状況は劇的に変わりました。Webコンテンツの容量が劇的に増加し、多くのサイトで単に静的にページを表示するだけでなく様々なアニメーションを駆使した動的効果が施されるようになりました。
インフラ的にもCDN(Contents Delivery Network)が普及し、人気サイトでは世界各地のユーザが地理的に最適なサイトにアクセスするよう誘導されていることも珍しくありません。

httparchive.orgの統計によると、2012年10月時点のコンテンツの平均容量は1999年と比べ15倍以上に増加し、1.2MByteを超えています。１ページのWebアクセスでは、平均14のドメイン宛に85のHTTPリクエストが必要になっています。
今後モバイル環境からスマートフォンによるインターネットアクセスが普及すると、このようなリッチコンテンツが更に増えていくものと思われます。

一般的にWeb表示の高速化を目指すアプローチはいくつかあります。GoogleはWebを高速化する効果的な要素を探すため、サーバとクライアント間の回線帯域とRTT(Round Trip Time)を変え、HTTPでWebページを読み込む時間を測定しました。
その結果、ネットワークの回線帯域を増加させても一定の速度を超えると、それ以上ページの読み込み時間が短くならないことがわかりました。一方RTTに関しては、値が小さくなればなるほどページのダウンロード時間が短縮されました。

この比較結果から、Web表示を高速化するには、ネットワーク回線速度を上げるより、RTTを短くする方が効果的であることが見て取れます。これはブラウザによるWebページの読み込み処理が、「DNSによるアドレス解決」、「TCP接続のハンドシェイク」、「HTTPのリクエストとレスポンス」といった３つのステップから構成されており、それぞれの処理時間が回線速度よりもRTTに大きく依存していることに起因しています。
そこでSPDYは、この部分を改善する効果を狙っており、その目的は「Web表示のレイテンシー(待ち時間）を短縮すること」であると定義されています。

SPDYの歩み

SPDYは、Googleが2009年11月にドラフト仕様を公開して、初めて世に知られることになりました。その後SPDYの仕様は、メーリングリストを中心にオープンの場で議論が進められ、現在ではバージョン3がリリースされています。当初SPDYの開発はChromeだけで進められ、SPDYに対応したサーバやサービスは公表されていませんでした。しかし、2011年1月に突然「90%のGoogleサービスでSPDYの対応が完了した」と発表があり、既にSPDYが大規模なサービスで利用されていることが広く知られるようになりました。2011年末にはFirefoxでSPDY対応が開始され、2012年からはChrome以外のクライアントやオープンソースのWebサーバでSPDY対応が急速に進みました。2013年6月時点では、Googleのサービス以外にTwitterやWordPress、Facebookにおいて大規模なSPDY対応が始まっています。

2013年6月時点でChrome、Firefox、Operaの3種類のブラウザにおいて、デスクトップ・モバイル版のSPDY対応が完了しています。特にスマートフォンで用いられるモバイル版のブラウザでは利用できる回線帯域が限られているため、SPDYによる性能向上効果が高く見込まれるものと期待されています。

SPDYの特徴

SPDYは、技術的に「HTTP接続を操作するセッション層の置き換えを行ったもの」と定義できます。これまでHTTP/1.1で利用されてきたメソッドやヘッダといったHTTPのセマンティクスを変更するものではありません。SPDYは、Webコンテンツを取得するセッションの手順を新しく定義し直したものです。その目的は、ハードウェア性能・ソフトウェア技術・ネットワーク環境の進歩に合わせてWeb表示の高速化を図ることです。その上、現実的な普及ができるよう既存環境との共存も十分考慮されています。

Webサイト管理者の視点から、SPDYの利用には以下3つの利点があります。

利点1：ブラウザへのWebサイトのページ読み込み時間を短縮する

従来のHTTP接続の無駄や非効率な部分を改善し、Webページの読み込み時間を短縮します。これがSPDYの第一の目的です。ただし、ページ読み込み時間がどの程度改善されるかは、サイトの構成や環境に大きく依存します。場合によっては表示時間がほとんど変わらない、もしくは悪化するという場合もあります。

利点2：Webコンテンツの変更を必要としない

SPDYの利用によって、これまで利用していたHTML/CSS/JavaScriptなどのWebコンテンツを書き替える必要はありません。ただしSPDYによる性能向上を最大化するためには、コンテンツサイトの構成変更や従来のチューニング手法（ドメイン分割やインライン化など）の利用を止めることが求められます。

利点3：既存のHTTPサーバと互換性を保ちつつ簡単に順次デプロイ(Drop-in replacement)が可能である

SPDYはTLSと組み合わせると、HTTP・SPDYのどちらを利用するかサーバ・ブラウザ間で自動的に決めることが可能になります（詳細は後述します)。そのため通常ではSPDY専用にサーバを用意する必要はありません。現状ほとんどのSPDY対応サーバは、SPDY非対応ブラウザに対して従来通りHTTPを提供します。同様にSPDY対応ブラウザも従来のWebサーバに対してはHTTPで接続します。おかげでサーバやアプリの入れ替えに応じて、順次SPDY対応のサイトを展開していくことが可能になりました。
ただしこの互換性を保つ方法は、TLSの仕組みを利用することで実現しているためTLSの利用が必須です。そのため、これまで非SSLで提供していたサーバは、SSLに置き換えなければなりません。その結果、サーバ証明書を取得するなどコストが増加し、さらに暗号処理によるサーバ負荷上昇対策やシステム構成の見直しといった新たな負担が発生する場合もあります。SPDYの導入にはコストメリットを十分検討することが必要です。

SPDYに向かないサイト構成

SPDYを導入しても、必ずしも全てのサイトが無条件に高速化されるわけではありません。SPDYの技術的な特徴を活かせる構成では性能向上を期待することができますが、既存の環境をそのままでSPDYを適応すると、逆効果になるケースも考えられます。そのような構成を3つほど例示します。

例1：多数のドメインに分割してコンテンツを配置しているサイト

SPDYは1つのTCP接続を最大限に効率化することで高速化を図るプロトコルです。しかしWebコンテンツ内のリソースを多数のドメインに分割配置している場合、ブラウザはそれぞれのドメインのホストに対してTCP接続を生成することが必要となります。そのため、このようなサイトでは、TCP接続のオーバヘッドを小さくするメリットを生かすことができません。CDN等を利用して、地域的に多数のホスト・ドメインにコンテンツリソースを分割配置しているケースが当てはまります。（先述したワイルドカード証明書とDNS情報を共有してChromeで接続する場合は事情が異なります。）

例2：一度にダウンロードするコンテンツの量があまり多くないサイト

SPDYの多重化接続は、一度に多数のリソースをダウンロードする時にその効果を発揮します。しかし、そもそもダウンロードするリソースの絶対量が少ないサイトの場合は、この性能向上効果は見込めません。

例3：クライアントからの通信経路の品質があまりにも悪いサイト

SPDYは1つのTCP接続に通信を依存しているため、その1つのTCP接続の通信品質がページ全体の表示に影響を与えます。パケットロス等が頻繁に発生するような通信品質の悪い環境では、複数接続した場合に比べて単一のTCP接続の品質悪化による影響度が大きくなります。

SPDYの性能

ではWeb表示の高速化を目指すSPDYは、いったいどの程度、表示を高速化できるのでしょうか？これまでGoogleを始めとする、いくつかのベンチマーク結果が公表されています。当初実験環境では、ページ表示速度が2倍に向上するといった結果が公表されていましたが、その後実サイトを模擬した疑似的なモバイル環境では、2～3割の向上に留まるといったレポートが公開されています。一方、CDN環境では数パーセント程度の改善しか見られないとの報告もあります。また非SSLのサイトとの比較では、SPDY化による恩恵よりもSSL化の遅延の方が大きいといったことも言われています。

筆者がベンチマークを行ったところ、SPDYによって平均で12%～15%程度、読み込み時間が改善されました。ただし、ベンチマークを繰り返すと劇的に読み込みが早くなる場合もあれば、SSLより遅くなる場合もあります。これらの結果を見ると、単純にSPDYを導入すればWebサイトの読み込み速度が劇的に変化する、というわけではないのは確かです。そのため日頃からサイトのパフォーマンス測定を継続して行い、SPDY導入後もその効果が何に依存するのかといった運用ノウハウを蓄積することが求められます。