Google、HTTPを置き換えるプロトコルに取り組む

作者 Abel Avram , 翻訳者 笹井 崇司 投稿日 2009年11月17日

セクション

運用/インフラ,

設計/アーキテクチャ,

デベロップメント

トピック

HTTP ,

Google ,

W3C ,

Architecture ,

パフォーマンス&スケーラビリティ ,

仕様 ,

Web Server

共有 |

原文(投稿日：2009/11/13)へのリンク

GoogleがSPDYを提案した。これはSSLの上で動く新しいアプリケーションプロトコルであり、レイテンシが大きいとされるHTTPを置き換えるものだ。彼らはすでに、SPDYに対応したWebサーバとChromeブラウザによるプロトタイプを開発しており、Webページを2倍高速にロードできるという。

少し前、Googleはインターネットを高速にすることを目的として、「Webを高速化しよう」というイニシアチブを立ち上げた。このイニシアチブのスコープは、高速なWebサーバの開発から高速なブラウザの開発まで、広範囲に及んでいる。例えば、Page Speedは、Webページを改善して高速なダウンロードを実現するためのツールだ。世界中の開発者がWebサイトを高速化できるよう、Googleは様々なツールをオープンソースにして、チュートリアルを公開した。

しかし、Googleはここで立ち止まることはなかった。彼らはSPDY（「スピーディ」と発音する）と名付けた新しいアプリケーションプロトコルをいじっていたのだ。もし、これがうまくいって広まると、HTTPを置き換えてインターネットの屋台骨をオーバーホールすることになるだろう。SPDYのホワイトペーパーでは、スタックの下位にあるトランスポートプロトコル（TCP）をもっと優れたものに置き換えるというアイデアについても言及している。しかし、これを実際に広めるのは極めて困難であると考えて、代わりにアプリケーションプロトコルであるHTTPを改善しようとしている。

SPDYのホワイトペーパーでは、ページ配信の遅延につながるHTTPプロトコルの制約について、いくつか列挙している。

• 1コネクションにつき1リクエスト。 HTTPでは一度に1つのリソースしか取得できません（HTTPパイプラインは有用ですが、それでも1つのFIFOキューだけという制限があります）。サーバ遅延が500ミリ秒あると、次のリクエストのためにTCPチャネルを再利用できなくなります。ブラウザは複数のコネクションを利用することで、この問題を回避してきました。2008年以降、ほとんどのブラウザは、1ドメインにつき2コネクションだったのを6コネクションに変更しています。
• リクエストを開始できるのはクライアントだけ。HTTPでは、クライアントからしかリクエストを開始できません。たとえ、クライアントにリソースが必要であることをサーバが知っていても、それをクライアントに知らせる仕組みはありません。クライアントがそのリソースに対してリクエストするまで、サーバは待たなくてはなりません。
• 非圧縮のリクエスト/レスポンスヘッダ。今やリクエストヘッダのサイズは、200バイトから2キロバイト超までさまざまです。アプリケーションが機能拡張のためにクッキーやユーザエージェントを利用すると、ヘッダサイズは700-800バイトほどになるでしょう。モデムやADSLでは上りの帯域が非常に狭いため、このヘッダサイズはレイテンシに大きな影響を与えます。ヘッダサイズを削減できれば、リクエスト送信時のシリアライゼーション遅延を改善できるでしょう。
• 冗長なヘッダ。これに加えて、同一チャネルのリクエストにおいて、何度も繰り返し送信されるヘッダがいくつかあります。User-Agent、Host、Accept* といったヘッダは通常変わることはないので、再送する必要はありません。
• データ圧縮の使用はオプション。HTTPでは、データのための圧縮エンコーディングの使用はオプションになっています。しかし、コンテンツは常に圧縮形式で送信されるべきです。

SPDYの目標の1つは、ページロード時間を50％まで削減して、ブラウズを2倍高速にすることだ。数百ミリ秒というのはユーザにとって大した意味がないように思えるが、近い将来、Webアプリケーションが密に相互接続するようになると、ミリ秒にも大きな意味がある。また、この新しいプロトコロルを導入しても、現在のWebコンテンツが影響を受けることはない。SPDYが利用できるよう、Webサーバとクライアントを改良するだけでよいのだ。

GoogleはSPDYを使って、一体何がしたいのだろうか？

• 単一のTCPセッションで複数のHTTPリクエストを同時実行できるようにすること。

• ヘッダを圧縮して不要なヘッダを削除することで、HTTPが使用する帯域を削減すること。

• 実装しやすく、サーバ効率の優れたプロトコルを定義すること。エッジケースを減らして簡単にパースできるメッセージフォーマットを定義することで、HTTPの複雑さを軽減したい。

• セキュリティと既存のネットワークインフラとの互換性を考慮して、SSLを基本トランスポートプロトコルとすること。SSLの使用はレイテンシの面では不利ですが、私たちは、Webの長期的な未来はセキュアなネットワークコネクション次第だと信じています。さらに、既存のプロキシを介した通信を壊さないようにするためにも、SSLを利用する必要があります。
• サーバからクライアントへの通信を開始して、いつでもクライアントにデータをプッシュできるようにすること。

これらの目標を実現するため、SPDYはSSLの上にセッション層を追加することで作られている。これにより、単一のTCPコネクション上に複数のストリームを並行にインターリーブすることができる。HTTPのGETとPOSTのメッセージフォーマットはそのまま変わらないが、SPDYでは「ネットワーク上にデータをエンコードして伝送するための新しいフレーミングフォーマット」を提案している。このストリームは双方向であり、クライアントとサーバのどちら側からでもリクエストを開始することができる。

今のところ、GoogleはHTTPとSPDYの両方のプロトコルを処理できるオンメモリサーバを開発しており、このコードは間もなくオープンソースになる予定だ。また、SPDYに対応したChromeブラウザも開発しており、内部では暫定的にflipと呼ばれている(ソースコードが利用可能)。このブラウザはHTTPとSPDYのどちらでも動作する。彼らはテスティングツール一式も開発しており、これを使うと、SPDYを使って正しくページがダウンロードできているかを確認することができる。こうしたツールも間もなくリリースされる予定だ。

プロトタイプによる結果を見ると、今のところは期待できそうだ。

私たちは、1%のパケットロスのある家庭用ネットワーク接続をシミュレーションして、「トップ100」Webサイトのうち25サイトをダウンロードしました。各サイトをそれぞれ10回ダウンロードして、平均ページロード時間を計算したのです。その結果、ページロード時間はTCP上で27%・0%、SSL上で39%・5%となり、高速になっていることが確認できました。

邨

Googleが最高のプロトコルを作ったとしても、彼らだけでは目標を達成できないのは明らかだ。コミュニティに受け入れられ、新しいアプリケーションプロトコル作りに参加してもらう必要がある。他の主要なプレイヤがどんな反応をするのか、興味深いところだ。

参考リソース: SPDYプロトコル仕様のドラフト, SPDY対応のChromeブラウザ。