BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース HTTP の改善を図る Google と Microsoft

HTTP の改善を図る Google と Microsoft

ブックマーク

原文(投稿日:2012/05/24)へのリンク

Google と Microsoft は,SPDY と Speed+Mobility で HTTP を改善したいと考えている。今回の記事では,幅広く利用されているインターネットプロトコルである HTTP に対して,それぞれの提案がもたらすメリットがどのようなものであるかをレビューする。

Internet Engineering Task Force (IETF) は W3C と共同で,ネットワークのルーティング,転送,セキュリティに関連する活動の取りまとめを行う機関である。1999 年にその詳細が決定し,Roy Fielding,T.Bemers-Lee 両氏が署名した RFC2616 HTTP 1.1 仕様提案は,そのような活動成果のひとつだ。その HTTP の最終バージョンが採択されてから,すでに 12 年以上が経過している。非常によく使われるインターネットプロトコルである HTTP には,現在のニーズに対応するための拡張が必要だとする声もあがっていて,HTTP 2.0 に対する多数の提案が IETF に提出されている。Google の SPDYMicrosoft の HTTP Speed+Mobility はそのような提案のひとつであり,どちらも現行バージョンとの後方互換性を保持しつつ,既存のインフラストラクチャ上への構築を試みている。

Google は HTTP 1.1 における速度の問題に対処しようとしている。

HTTP 実装でのボトルネックのひとつに,並行性の実現に複数のコネクションを使用している点があります。これによってコネクション確立時のラウンドトリップの増加,スロースタート遅延,さらには単一サーバに対する過度の接続を回避するためのクライアント側のコネクション配分など,さまざまな問題が発生しているのです。

そこで SPDY では,

フレーミング層を追加して,複数の並列ストリームを単一の TCP コネクション (あるいは任意の高信頼性トランスポートストリーム) 上に多重化します。フレーミング層は HTTP のような要求 – 応答ストリームに最適化されています。そのため Web アプリケーションの開発者は,現在 HTTP 上で動作しているアプリケーションをほとんど,あるいはまったく変更することなく,SPDY 上で動作させることができるのです。

実際に SPDY が HTTP 1.1 に提供するのは,多重要求,優先度付き要求,ヘッダ圧縮,サーバプッシュ形式のストリーム,という4つの改善点である。プロトコルとしてはまだ提案レベルだが,すでに実装され,運用も行われている。Google は多数のサービスと Chrome に SPDY を使用しているが,それ以外の実装 としては Apache SPDY モジュールや node.js 用の SPDY サーバ,Firefox,Amazon Silk などがある。Ngnix も近く採用する予定だ。

Microsoft は HTTP 2.0 用に,SPDY と WebSocket をベースとした,速度問題に加えてモバイル性にも対処する 仕様 を提案中だ。提案の署名者である Microsoft Open Technologies シニアプログラムマネージャの Adalberto Foresti 氏は,InfoQ とのメールのやり取りの中で,"SPDY は Web のパフォーマンスに対する意識を高めた点,Web をより高速にする HTTP 改善に "クリーンスレート" アプローチを採用した点,この2つにおいて大きな役割を果たしました" と書いている。Microsoft の提案では "WebSocket の制御フレームと冗長性を持つ項目の削除,既存の HTTP セマンティクスとの互換性の破棄,あるいはトランスポート層での実行に最良なコンセプトを実装するようにセッション制御メッセージを" を簡略化することで SPDY を修正している。

Microsoft の HTTP Speed+Mobiloty ではさらに CPU の使用率,デバイスのバッテリやリソース,セキュリティなどを考慮して,"モノのインターネット (IoT / Internet of Things)" における HTTP 利用を向上させるための2章を追加している。1.1.4 章 "クライアントによるコンテント管理 (Client is in control of content)" に次のような記述がある。

インターネット上のクライアントと,そこで用いられる接続シナリオにはさまざまなものがあります。したがってダウンロードされるコンテントを定義するには,クライアントは最良のポジションなのです。ブラウザやアプリなどのクライアントは,ユーザが現在何をしているか,すでにローカルに存在しているデータは何か,といった情報を直接的に保持しています。例えば今日のブラウザの多くは高機能なキャッシュを備えて,頻繁に変更されるウェブ要素を保存するために利用しています。…

HTTP 2.0 の案がブラウザあるいはアプリに要求されていないコンテントや,すでにキャッシュされているコンテントのダウンロードを強要するようなものであることは許されません。さらにクライアントには,希望していない,あるいは必要のないコンテントを拒否できるような選択権が必要です。そのためにはクライアント側に,キャッシュされていてダウンロード不要な要素をサーバに通知する機能が必要になります。このようなクライアントからサーバへのフィードバックによって,コンテントのインクリメンタルな承認を行うことで,適切なコンテントを適切なセキュリティとフォーマットのもとで配信するような,効率のよい "プッシュ" 拡張が実現できれば理想的です。

1.1.5 章 "ネットワークのコストと消費電力 (Network Cost and Power)" では,電力と帯域幅の消費に関わる問題を取り上げている。

速度,コスト,消費電力のどれを選択するかというのは,単純な問題ではありません。ある場合には速度が最重要な考慮事項であるかも知れませんし,帯域幅のコストやバッテリ寿命が決定要因になることもあります。HTTP 2.0 では,一般的な問題に対してモノシリックなソリューションを提供することよりも,開発者自身の問題空間に特有な制約 (それは時間とともに変わる可能性もあります) への最適化が可能であることが必要です。

高速度,低コスト,低消費電力といった目標は,多くの場合において並立が可能です。例えば送信データ量を少なくすればページロードが高速になり,電波出力を早く低減することができる上に,帯域幅の消費も低く抑えられます。しかし HTTP 2.0 が適用されるであろうさまざまなシナリオを考えるならば,常にこのようになるということはあり得ません。例えばバッテリをほとんど使い果たした,あるいはキャッシュの使用容量が限界に近いデバイスでは,サーバのプッシュ更新を無効にしてその他の HTTP 2.0 の最適化を維持するようにした方が,よりよいユーザエクスペリエンスを提供できると考えられます。ですからワーキンググループでは,速度と同様に消費電力やコストについての考慮が必要なのです。

このような問題に対処するため,Microsoft は WebSocket を用いてセッションのハンドシェイク,メンテナンス,フレーミングを向上させることを提案している。仕様にはユーザがこの種の資料に期待するような,低レベルな詳細事項についても記載されている。

Microsoft はこの提案を,3月に行われた ETF 83 会議中に提出した。同社はさらに,コンセプトを実証するために プロトタイプ をオープンソースで実装している。開発者はこれを使って HTTP Speef+Mobility 提案を評価することができる。ソースコードは GitHub で公開されている。

業界の選択がどちらになるかを知るには,今後を待たなければならない。IETF 標準化プロセス では "仕様は開発期間とインターネットコミュニティによる何回かのレビューの繰り返し,その経験に基づくリビジョンを経て,適切な機関によって標準として採択され,... 公開される" とされている。

この記事に星をつける

おすすめ度
スタイル

BT