検索
連載

次世代HTTP 2.0はSPDYの取り組みがベースにOSS界のちょっと気になる話(7)

Web通信の高速化を目的にGoogleが策定を進めている通信プロトコル「SPDY」が盛り上がりを見せている。十数年ぶりのHTTPのメジャーバージョンアップの土台にもなりそうだ。(編集部)

PC用表示 関連情報
Share
Tweet
LINE
Hatena

最近静かに熱いSPDY

 2012年に入ってから、Googleが策定を進めている通信プロトコル「SPDY」の周りで、静かに熱い状況が続いている。

 当初Googleは、高速なWeb通信を実現するためにSPDYというプロトコルを発表。自社ブラウザであるChromeにSPDYの実装を追加するとともに、順次Googleが提供しているサービスをSPDY対応にしていった。

 このため、Googleの提供するサービスはChromeからアクセスした時の方が高速になるという状況が現れた。これに対応する形でFirefox 11が実験的にSPDYの実装を追加。Firefox 13からはデフォルトの機能としてSPDYが有効化されている。Opera SoftwareはSPDYを実験的にサポートしたOpera Labs SPDYの提供を開始するなど、ブラウザ側の対応も進んでいる。

 GoogleのWebサービスのみならず、ほかの主要なWebサービスもSPDYへの対応を進めている。TwitterはすでにSPDYに対応しているし、ほかのWebサービスも対応を発表している。Webサーバ側ではApache HTTPd Server向けにmod_spdyが提供されているし、Nginxは開発版となる1.3系でSPDYへの対応を計画している。Webサーバ側の対応も順調だ。

 Webサービスは日々の生活や業務においてますます重要なインフラになりつつあり、通信の高速化は快適なサービスの利用に欠かせないものになっている。SPDYに関係した動きは速く、今後もさまざまな局面でSPDYへの対応が進むものとみられる。

SPDYからHTTP 2.0へ

 SPDYの登場に対して、HTTPを根本的に改訂しようという取り組みが起こっている。この取り組みはIETFのHypertext Transfer Protocol Bis (httpbis)ワーキンググループが進めている。

 内容はこれから随時変更されることになると見られるが、Proposal for a Network-Friendly HTTP Upgrade draft-tarreau-httpbis-network-friendly-00あたりを読むと、現時点でどういった改訂が予定されているのかが分かりやすい。特に、ドラフトの「Improvements」という節を読めば、改訂の要約を知ることができる。

 挙げられている主な改善点は次のとおりだ。

  • リクエスト/レスポンスの多重化
  • ヘッダフィールドの圧縮
  • ヘッダフィールドのグループ化
  • レイヤモデルの導入

 現行のHTTP 1.1とは後方互換性を持たせると説明がある。また、ここで提案されている改善はすでにSPDYで実施されているものだ。SPDYにおける改善をHTTP 2.0のベースとしていく方針であることが分かる。

HTTP 1.1の何が問題なのか

 後方互換が実現されるのであれば、運用側としてはWebサーバ、ブラウザ、関連するWebサービスなどがHTTP 2.0に対応するのを待ってさえいれば、次の企業インフラアップデート時に自動的にHTTP 2.0へ切り替わるかもしれない。

 しかし、いったい何がWebのパフォーマンスのボトルネックになっており、どう改善しようとしているのか、その概要は把握しておいた方がよいだろう。

 HTTP 1.1ではリクエストとレスポンスは1対1で対応しており、最初のレスポンスを得てからでないと、次のリクエストは送信できない仕組みになっている。例えば、あるHTMLページの中にたくさんの画像やスクリプトへのリンクがあって、100のリクエストが必要だったとする。この場合、HTTP 1.1ではその分だけ、リクエストとレスポンスの受取を繰り返すことになる。

 この処理は遅い。このため現行のブラウザは複数のコネクションを張って複数のコンテンツを同時にダウンロードする仕組みを採用している。しかし、この方法はWebサーバに対する負荷が高くなるため、紳士協定的にそれほど多くのコネクションは張らないようにブラウザ側のデフォルトの設定が設けてある。しかしながら、本質的にあまり優れた解決方法とはいい難い。

 SPDYではこの問題を解決するために、1つのコネクションの中でまとめてリクエストを送る方法を規定している。この方法を活用すれば複数のコネクションを張る場合よりも低い負荷で高速にコンテンツをダウンロードできるようになる。


図1 SPDYではリクエストとレスポンスを集約して高速化を図っている

 ほかにも毎回ヘッダを送るという効率の悪さを改善する方法などが盛り込まれている。

SPDYは実は速くならない? いや、状況は変わっていく

 SPDYに関して最近最も衝撃的だったのはGuy Podjarny氏が発表した「Not as SPDY as You Thought」だ。


画面1 Guy Podjarny氏が発表した「Not as SPDY as You Thought」のブログ投稿

 内容を要約すると、実際のトップ500サイトでHTTP、HTTPS、SPDYを比較してみた結果、「SPDYはHTTPSよりは高速だが、HTTPよりは遅いという結果」が得られた、というものだ。説明されている実験方法を読む限りでは、これはそれなりに説得力がある。

 しかしこの実験内容は、そもそもSPDYの最適化が効きにくい状況を想定したものだった。もしSPDYの効果が得られやすい状況で実験するならばさらに性能は向上するという意見が出ており、それほど問題ではないというコンセンサスが生まれているように思う。

10年以上の月日を超えてHTTPメジャーバージョンアップへ

 Hypertext Transfer Protocol -- HTTP/1.1が策定されたのが1999年であることを考えると、HTTP 2.0は、何と10年以上の月日を経てのメジャーバージョンアップということになる。

 すでにSPDYに対応したWebサーバの実装もブラウザの実装もあり、Webサービス側でもSPDY対応が増えていることを考えると、現在の提案がそのままHTTP 2.0になるというのも、それなりに現実的な話であるように思える。

 Googleが自社の提供しているWebサービスをより快適に利用できるようにとの思いから取り組み始めたSPDYが、最終的にHTTP 2.0へつながっていくことになる。もちろんまだ議論は始まったばかりだが、かなり実現性の高い話だ。今後の進展に注目しておきたい。

著者プロフィール

後藤大地

BSDコンサルティング株式会社取締役、オングス代表取締役。@ITへの寄稿、MYCOMジャーナルにおけるニュース執筆のほか、アプリケーション開発やシステム構築、『改訂第二版 FreeBSDビギナーズバイブル』『D言語パーフェクトガイド』『UNIX本格マスター 基礎編〜Linux&FreeBSDを使いこなすための第一歩〜』など著書多数。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る