HTTP/2.0相互接続試験で重要な技術要素の概要

SPDYを技術ベースにして検討されているHTTP/2.0仕様は、現在60ページ弱の分量です。従来のHTTP/1.1と異なりバイナリー通信を基本とするため、その多くはフレームフォーマットの説明に割かれています。HTTP/2.0で新しく導入されたヘッダ圧縮の仕様(HPACK)は、現在HTTP/2.0の仕様と分離されていますが、将来的には統合することも検討されています。
HTTP/2.0は、既存のHTTP/1.1のセマンティクスを保持したままフレームやストリームといった単位でバイナリー通信を行うので、この点過去のSPDYの開発経験や運用実績を活かすことができます。他方、既存のSPDYでは使われていないようなHTTP/2.0で新しく議論された技術仕様については、まだ未知数な部分が多く残っています。ここでは後者に該当する項目、先に述べた相互接続試験のポイントとなった2つの技術要素について、簡単に解説します。

初期接続：HTTP/2.0の接続方法は3種類で2段階

相互接続試験における一番最初の技術的なハードルは、初期接続の確立です。将来HTTP/2.0の仕様化が完了すると、ある日突然今利用している全てのウェブサーバやブラウザーを一斉にHTTP/2.0対応に変えなければならなくなる、というわけではありません。HTTP/1.1とHTTP/2.0はインターネット上で共存できるよう設計されており、皆さんはHTTP/1.1をこれからもずっと使い続けることができるでしょう。その共存を可能にする技術が、HTTP/2.0の初期接続仕様です。ブラウザやサーバは、この初期接続を通じて相手がHTTP/2.0を使うことができるのかどうかを知り、従来のHTTP/1.1を使うのか、それとも新しいHTTP/2.0で接続するのかを正確に判断することができるのです。

初期接続の第1段階

HTTP/2.0の初期接続は、2段階のステップに分かれています。 第１段階は、次の3種類の接続方法を規定しています(図1)。

1. TLS+ALPN

ALPN(Alternate Protocol Negotiation)は、TLSのハンドシェイク時に拡張フィールドにクライアントから利用可能なプロトコルリスト送信し、そのリストを受け取ったサーバが利用プロトコルを決定する方法です。 SPDYでは、クライアント側が利用プロトコルを決定するNPN(Next Protocol Negotiation)仕様を利用していました。IETFのtlsワーキンググループの議論の過程で、TLSハンドシェイク後のプロトコル選択方法としてNPNではなく、ALPNを採用することが決定されました。ALPN仕様の採用には様々な理由がありますが、セキュリティ通信の多くは基本的にサーバ側が決定権を持つというのが理由の一つです。 クライアント・サーバ間でTLSのネゴシエーションが終り、ALPNでその後続けてHTTP/2.0通信を行うことが決まると、次に2段階目の初期接続に移ります。
今回8月の接続試験時は、opensslのALPN対応パッチの導入がまだ公表されていなかったため、iij-http2 を含めたいくつかの実装は、ALPNの代替としてNPNを利用して試験しました。

2. HTTP Upgrade

従来のHTTP/1.1リクエストを行うと同時にクライアントから Upgrade ヘッダを送信して HTTP/2.0 接続に切り替える方法です。これは、WebSocketで行われている方法と同じ切り替え方式になります。サーバが、HTTP/2.0に対応していれば、ステータスコード 101 (Switching Protocols)をクライアントに返し、第2段階目の初期接続に移ります。Upgrade時にクライアントからHTTP/1.1で送信されたHTTPリクエストは、サーバ内部で最初のHTTP/2.0のリクエストとして扱われます。サーバ側では、Upgradeの有無によってHTTP/1.1とHTTP/2.0の両方を処理可能にする必要があるため、 iij-http2ではクライアントのみこの接続方式を実装しました。

3. Direct接続

あらかじめクライアントの接続先がHTTP/2.0に対応していることを知っていれば、(1)や(2)の初期接続を行わずいきなり第2段階目の初期接続から開始することも可能です。どのようにして事前にHTTP/2.0対応であることを知ることができるのかは、HTTP/2.0仕様とは別に決めることになっています。現在のところ、DNSレコードを見て判断する方法やAlternate-Protocolヘッダを見てリダイレクションを行う方法などが候補とされていますが、具体的な仕様の検討はまだ始まっていません。

初期接続の第2段階

第2段階目の初期接続は、HTTP/2.0通信を開始する最終確認です。このステップでは、24バイトのコネクションヘッダというバイト列(505249202a20485454502f322e300d0a0d0a534d0d0a0d0a) をクライアントからサーバに送信します(図2) 。

これは、 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n という文字列を表したものです(注1)。もし第１段階を経由して間違ってHTTP/1.1のサーバにアクセスしてしまっても、HTTP/1.1のサーバは PRIというメソッドとHTTP/2.0というサポートされていないバージョンを持ったHTTPリクエストを受け取ったと解釈し、400 (Bad Request) のエラーを返して直ちにコネクションを切断するでしょう。一方、 HTTP/2.0のサーバは、このバイト列を受け取れば確かにHTTP/2.0のクライアントからの接続であることの確証が取れますので、安心してHTTP/2.0の処理を継続することができます。

このバイト列を受け取ったことを確認したら、クライアント・サーバ双方で設定情報を通知するSETTINGSフレームを送信し、HTTP/2.0の初期情報を交換します。これをSETTINGSフレームによって、通常データのフロー制御を行う初期ウィンドウサイズや同時オープンできるストリーム数の最大数などの設定情報が定まります。

以上、第2段階までのHTTP/2.0初期接続のステップを完了して初めて通常のHTTPリクエスト・レスポンスといった処理を開始することができます。今回の相互接続試験では、試験対象の実装がサポートしている初期接続に対してちゃんと仕様が想定している通りに動作し、お互いに第二段階まで問題なく完了できるのかといったところが一つの技術的なマイルストーンでした。

実装者からのフィードバック議論において、既に大規模にSPDY向けにTLS+NPNを実サービスに展開しているGoogleなどから、HTTP/2.0でTLS+ALPNが採用されたため、今後どう両者を共存させながら大規模試験をしていくのか、そして最終的にどのようにしてSPDYからHTTP/2.0に移行していくか、という運用上の問題が懸念として示されました。これに伴いHTTP/2.0に関する dev ops の議論を行う場を新たに作る提案がなされています。

ヘッダ圧縮(HPACK)：脆弱性を克服、これまでのWebにはない新しい試み

現状HTTP/1.1で利用されているヘッダ情報は、毎回同じデータを送るように冗長になっている場合が多く、その容量も次第に増加しています。特にネットワーク帯域が制限されているモバイル環境では、冗長なHTTPヘッダ情報のやり取りは帯域を圧迫し、その影響は無視できないものになっています。この状況を解決するためSPDYでは、deflateという汎用的な圧縮アルゴリズムを利用してヘッダ情報の通信容量を圧縮しました。

しかし2012年9月に、deflateを用いた場合にヘッダ情報が暗号化された通信上でも漏えいできることをセキュリティ研究者により明らかにされました。彼らはCRIMEというツールを利用することにより、特定の環境下で短時間にクッキーなどの重要なヘッダ情報を取得することを示しました。現在SPDYを利用しているブラウザーでは、この脆弱性に対応するために暫定的にヘッダ圧縮をしない対策がとられています。しかしモバイル環境などでヘッダ情報の送受信を削減することは急務の課題です。
皮肉なことにこの脆弱性は、データ圧縮アルゴリズムによって送信データが最適化されてしまったことを手掛かりにヘッダ情報を取得する手法を使っています。このため一般的な情報圧縮手法では脆弱性を回避できない可能性もあり、HTTP/2.0ではHTTPのリクエスト・レスポンスに特化した目的でヘッダ情報のデータ量を削減する新たな仕様を導入する必要に迫られました。

当初新たなヘッダ圧縮手法として、 Delta2 と Header-Diff という2つの仕様が候補として検討が進められていました。調整の結果、第2回の中間会議の直前にこの2つを合わせた Header-Compression 仕様(現HPACK仕様)が両仕様の共著として提出されました。最終的にこれを実装仕様として採用することが決定し、相互接続試験では一部を改良した仕様(Header-Compression-01)を使ってテストが行われました。
HTTPリクエストとレスポンスは、HTTPヘッダのやり取りをせずに実現できるものではありません。相互試験の参加者は、Header-Compressionのリリース後初めてこのヘッダ圧縮仕様を実装します。今回の相互接続試験のもう一つの技術トピックは、この新しいヘッダ圧縮の仕様を使って本当にHTTPリクエスト・レスポンスのやり取りが実現可能か実証する所にありました。

HPACKの仕様は、これまでHTTPで用いられてきた通信手順と全く異なり、新しいコンセプトに基づくものです。その手順は細かく規定されていますが、全てを説明するとわかりにくくなるため、若干正確性を犠牲にしますが一部簡略化してその仕組みの概要を解説します。

この仕様の基本は、サーバ・クライアントがヘッダ情報を記載したヘッダテーブルとreference set という２つのデータ集合を状態として保持することにあります。このヘッダテーブルとreference setは、HTTPリクエスト・レスポンスそれぞれに用意されるものです。ヘッダテーブルは、初期状態としてあらかじめ数十種類のヘッダ情報が番号付きで登録されています。 reference set は、1つ前のHTTPリクエスト・レスポンスの送受信によって有効になったヘッダ情報を保持しています(図3）。reference set の初期状態は空です。 クライアントとサーバは、HTTPリクエスト・レスポンスが行われる度に reference set やヘッダテーブルに対してどういうヘッダ情報を追加・削除・変更するのかといった差分操作をやり取りします。この差分操作を表すやり方は、その種類や操作によって4種類のエンコーディング方式が定義されています(注2)。受信側は、エンコードされた差分操作のデータを解析し、記載された操作に従ってヘッダテーブルやreference set を更新します。その結果、サーバとクライアントは同じヘッダテーブルと reference set を持ち、ブラウザやWebアプリケーションはこの新しい reference set を有効になヘッダ情報として利用することになります。

具体的な例を見たほうがよりわかりやすいでしょう。一例としてまずクライアントが一番最初に :scheme http :host serverA :path / xmyhoge hoge のヘッダ(空白を除いて39バイト）情報をサーバにHTTPリクエストとして送信する場合を考えます。この場合、次の5つのステップでヘッダ情報の差分操作として表します。

1. 0番のヘッダテーブルをそのまま使う
2. 2番のヘッダテーブルを serverAに書き換える
3. 3番のヘッダテーブルをそのまま使う
4. 4番のヘッダテーブルをそのまま使う
5. xmyhogeは新しくヘッダテーブルに採番して値にhogeを入れ込む

この差分操作を規定されたエンコード書式で表すと、 0x80 0x03 0x02 0x07 serverA 0x83 0x84 0x40 0x07 xmyhoge 0x04 hoge のような形式になります。これは全27バイトのデータ容量で、HTTP/2.0のフレームに付与してクライアントからサーバへ送信されます。従来のヘッダ情報の送信(39バイト）よりもデータ容量が減っていることがわかります。このヘッダ操作データを受け取ったサーバは、エンコード情報を解析し、初期状態が空のreference setとヘッダテーブルに対して1から5の差分操作を行います。結果、クライアントと同じ有効なヘッダ情報を持つreference setを作成し、Webアプリケーションに渡します（図4）。

次にクライアントが2回目のリクエストする際には、この新しいreference setに対して、ヘッダの追加、削除、変更という差分操作情報をサーバに送信します。もしクライアントが、 :scheme http :host serverA :path /foo.html xmyhoge hoge のヘッダ情報（47バイト）を2回目に送信する場合は、今保持するreference setに対して:pathのヘッダ情報だけ更新を指示する操作情報のみサーバに送ることになります（3番のヘッダテーブルを/foo.htmlに書き換える操作）。 このエンコード方式は、 0x04 0x03 0x09 /foo.html と表すことができます。これは、わずか12バイトです。このデータをクライアントからサーバに送信し、サーバは、reference set とヘッダテーブル:pathの値を更新します。HPACKを使わなければ47バイトのヘッダ情報を送付しなければならないことが、HPACKの利用で12バイトを送付するだけに縮小できるのです(図5)。

もし3回目のリクエストが2回目と同じヘッダ情報を持つリクエストなら、更新操作は必要なくなり、送付する差分操作情報は0バイトになります。クライアントは、ペイロードを空にしてフレームヘッダだけを送信すればよいのです（図6）。 このように冗長で繰り返し同じヘッダ情報を送付する場合に、HPACKはその効果が最大限に発揮される仕様であると言えます。

この方式は、SPDYで利用されていたdeflateの圧縮アルゴリズムと全く異なるものであるため先ほどのCRIME攻撃の脆弱性は存在しないものと考えられています。当初この仕様を見て実装を始めた時には、その変わり様に非常に驚きました。しかし、実際に相互接続試験では初めての実装試験であるにもかかわらず、各実装に対して問題なくHTTPリクエスト・レスポンスのやり取りができることを確認できました。
しかし様々な課題がまだ残っています。例えばメモリの対策のためヘッダテーブルは容量を制限しなければなりません。その容量を超えた場合の更新処理はどうなるのか。また実利用のヘッダ情報を使っても長時間継続してヘッダ情報の更新を行った場合でも、クライアント・サーバ間でヘッダ情報の整合性を保てるのか、といったような課題が議論され今後更なる仕様の見直しと試験を続けていく必要がある、ということが合意されました。

このように従来とは全く異なった手法でヘッダ情報がやり取りされるということは、HTTP/2.0の大きな特徴です。今後HTTP/2.0の導入や運用を行う際には、これまでの古い知識にとらわれず新しく頭を切り替えてHTTP/2.0に取り組んでいく必要がありそうです。

まだまだある、技術的なチャレンジ

上記2つの技術トピックスは、初回の相互接続試験で特に問題になりそうなものだけを解説しました。これ以外にも、

• クライアント・サーバ間でフレームの送受信の競合状態が発生しても問題は発生しないか
• リクエストの予約という形の新しいサーバプッシュ機能はクライアントへキャッシュを正常に送り込めるのか
• フロー制御や優先度設定はいろんな環境でも有効に機能するのか

などなど、他にも解決しなければならない技術的課題がまだ数多く残っています。

とはいえ、近い将来インターネットで主流となる新しいプロトコルを世界中の優秀な技術者と一緒に作り上げていく過程は、エンジニアとして非常に貴重な機会であり、とてもワクワクする瞬間です。このレポートを読んでいただいている方に、このワクワク感が少しでも伝わればうれしいことだと思っています。

(注： 本記事は、2013年8月時点でのHTTP/2.0仕様ドラフトに基づくものです。今後仕様が変更され記述内容と異なる可能性がありますので、ご注意ください。)

(注1) これ(PRI SM)は、あのスノーデン事件が起きた時にエディターがシャレで付けた文字列です。現時点でこの文字列を正式に決めるようとすると議論がまとまらない可能性があるので仮の値になってます。このようにどうでもいいことで議論が発散することをbikeshed（自転車置き場）と呼んでワーキンググループ内で議論する時に注意しています。

(注2) この4種類のエンコーディング方式は、

Indexed Header Representation

ヘッダテーブルの数字指定だけで有効・無効をトグルさせる操作方式

Literal Header without Indexing

ヘッダを文字列指定してヘッダテーブルの更新しない操作方式

Literal Header with Incremental Indexing

ヘッダを文字列指定してヘッダテーブルの最後に追加する操作方式

Literal Header with Substitution Indexing

ヘッダを文字列指定して既存のヘッダテーブルの値を更新する操作方式

はじめに

先日公開された小松健作さんの記事「変わるWebプロトコルの常識（SPDY, HTTP2.0編）」で解説されている通り、Webを支えるプロトコルHTTPをバージョン1.1から2.0に大幅に改訂する作業が、現在急ピッチで進められています。10数年ぶりに改訂されるHTTPの仕様は、現状のインターネット環境に適応できるよう、これまで以上にWeb表示の高速化・効率化が実現できることを目的としています。

HTTP/2.0標準化作業の進め方

HTTP/2.0のプロトコル仕様の策定は、インターネット技術の標準化を推進する団体IETFのhttpbisワーキンググループで行われています。httpbisでは、SPDYを開発したGoogleをはじめ、Microsoft、Mozilla, Twitter, Akamaiなどのエンジニアが中心となり、メーリングリスト上で活発に議論を進めています。特にHTTP/2.0の仕様策定は他のワーキングループと違い、通常年3回ほど開催されるIETF総会とは別にinterimと呼ばれる中間会議を頻繁に開催して集中討議を行っているのが特徴です。 HTTP/2.0の仕様自体は、GitHub上で管理されています。ここのhttp2-specレポジトリでは、議論の合意を受けてエディタがドラフトを更新する様子をリアルタイムで見ることができます。

仕様更新の手順は通常のオープンソースプログラムと同様に、issueやPull Requestを使って行われています。仕様策定に関する議論はメーリングリスト上で行うことと決められているのですが、たまにメーリングリストに構わずGitHubのコメント上でやり取りが続いたりします。チャット感覚で議論が進むので白熱することも多いのですが、そんな時はチェアから注意を受けたりします。一方、設計を変更しない程度の修正であればPull Requestを送って、直接取り込んでもらうことも可能です。まだまだいろいろ試行錯誤の段階ですが、こういった今風なソーシャルコーディングのインフラを活用しながら標準化作業を進めていく手法は、IETFでも新しい試みではないかと思われます。

HTTP/2.0の仕様は、今どこまで進んでいるのか？

これまでのHTTP/2.0仕様策定作業の歩みを表1にまとめます。 今年になり、8月までに3回httpbisの中間会議が開催されました。HTTP/2.0の仕様ドラフトも6回改訂されています。当初HTTPの仕様改訂を開始するにあたり、SPDYを含む複数の候補案で検討が始まりました。途中大きな議論を経て、最終的にSPDYをHTTP/2.0の仕様ベースとして採用することが決定しました。ベースといっても、SPDYで実現できている機能や利点といった特徴を、HTTP/2.0の仕様に大部分引き継いでいますが、その仕組みに関しては大きく見直しが入っています。 HTTP/2.0の変更点の概要としては、

• フレームやストリームという多重化構造のSPDYプロトコルアーキテクチャをそのまま利用する。
• 無駄なヘッダフィールドやフレームタイプを統廃合し、簡略化を図る。
• SPDYの実運用で明らかとなったフロー制御・優先度制御といった課題に対応する。
• TLS利用を前提とするSPDYに対し、HTTP/2.0はTLS以外の接続も利用可能にする。
• 情報漏えいを起こす脆弱性対策として新たにHTTPヘッダ圧縮の送受信仕様を策定する。

といったことが挙げられます。 標準化作業の大きなマイルストーンとして、第2回目のhttpbis中間会議の結果を受けて最初のHTTP/2.0の実装仕様がdraft-04として7月上旬にリリースされました。それまで2つの案を候補にして検討されてきたヘッダ圧縮仕様も、両者をジョイントした新しい仕様Header-Compression-01がリリースされました。この2つのドラフト仕様がそろったところで、初めてHTTP/2.0を実装できる環境が整いました。実際に動くものを作って議論を進める段階に来たのです。

世界初、HTTP/2.0相互接続試験の実施

8月上旬、初めてのHTTP/2.0相互接続試験を実施すべく第3回中間会議が、ドイツ・ハンブルグで開催されました。

ハンブルグの風景

第3回の中間会議は二日半の日程で、下記のアジェンダで進められました。

1日目

終日 実装者からのフィードバック、issueの議論・整理

2日目

終日 相互接続試験

3日目

午前 issueの議論・整理、今後のロードマップ策定

ハンブルグでの初のHTTP/2.0相互接続試験向けに提出された実装のリストは、 http2-spec レポジトリのWikiページにまとめられています。現在ここに10の実装が登録されていますが、このうち実際に会議中に相互接続試験を行うことができたのは8つでした。実装の種類は、クライアント・サーバ・プロキシの3つの用途に大きく分類されます。今回の相互接続試験は初回ということもあり、基礎的な部分の動作確認が中心となりました。技術的には以下の2点が大きな検証ポイントです。

1. HTTP/2.0の初期接続が問題なく完了し、HTTP/2.0の処理が開始できること。
2. 新しいヘッダ圧縮仕様を使って問題なくHTTPのリクエスト・レスポンスの処理が行えること。

上記2つの技術ポイントについての詳細は、本レポートの後半(技術解説編）で解説します。

相互接続試験の結果と今後のロードマップ

私が持ち込んだ iij-http2 モジュールと他の実装との相互接続試験は、中間会議の2日目に集中的に行いました。ただ実際には、担当者同士でメールのやり取りをして、前日から既に試験を開始しています。

HTTP/2.0相互接続試験の様子

実は今回作成したiij-http2は、会議前にソースが公開されていた実装 (nghttpd や node-http等）に対してドイツ出発の2日前になってやっと初めて簡単な接続テストができたレベルなので、実際の接続試験ではどうなるかドキドキでした。当日は会議参加者間だけでなく、オフラインで参加した実装者も含めて各自がテストを進めています。相互接続試験といってもきっちりしたテストシナリオやチェック項目が用意されているわけではありません。開発者が気になる部分を中心に、用意されたサーバ・クライアントを自由にテストするといったやり方でした。

iij-http2は、テストのためにインターネット上に単純にHello Worldを返すサーバの2種類準備しました。ブラウザの替りに手元のクライアント実装を使って他のサーバやプロキシ実装に対してアクセスを行い、手元で表示されるデバッグ情報などと照らし合わせてHTTP/2.0プロトコルのやり取りを確認しました。最終的なiij-http2の接続試験結果を表2に示します。

試験を通じていくつの問題が発見されましたが、最終的にiij-http2は接続テストを行った全ての実装と接続確認が取れました。初回ということであまり複雑なアクセスパターンやエラー時の挙動などの試験を行っていませんが、先に解説した技術ポイントに対する相互接続は成功したことになります。一例としてHTTP/2.0対応Chromeとiij-http2との接続成功時のスクリーンショットを載せます。

会議の最終日は、今後のロードマップをどうするかという議論に移りました。クローズしたissueの方針や接続試験で議論された内容を最新のドラフトに反映し、第2回目の接続試験を行うための新しい実装仕様draft-06を2週間後にリリースすることが決まりました。またヘッダ圧縮仕様については一部仕様の見直しが必要なことが判明し、さらに詳細な試験が必要との声から、9月中旬に開発者が中心になってヘッダ圧縮に特化した試験を集中的に行うことも決めました。ちなみにヘッダ圧縮仕様の「圧縮」という名称は、機能的に正確な表現でないため、その名称をHPACKに変更するということが了承されました。

次の相互接続試験を行う中間会議は10月初旬シアトルで行われることを合意し、その先の2014年1月に開催する第5回中間会議までの予定を決めて会議は終了しました。HTTP/2.0の標準化作業は、2014年春の仕様化完了に向けてまだまだ続きます。後半では技術的な内容に興味を持つ人のために、HTTP/2.0相互接続試験の検証ポイントとなった技術トピックスについて解説します。

(注： 本記事は、2013年8月時点でのHTTP/2.0仕様ドラフトに基づくものです。今後仕様が変更され記述内容と異なる可能性がありますので、ご注意ください。)

HTML5の登場により、Webで使われるプロトコルは、 HTTP1.1 から大きく変わろうとしています。具体的には、SPDY, HTTP2.0, WebSocket, WebRTC といったプロトコルがそれにあたります。これらは、現状のHTTPが抱える各種問題点を解決するものです。

しかしながら、これらのプロトコルについて、

• いったい何であるのか
• 今のWebの何を解決してくれるのか

は、あまり知られていません。そこで数回に分けて、これらのプロトコルがいったい何であるのか、今のWebの何を解決してくれるのかを解説したいと思います。_[1]

今回は、SPDY, HTTP2.0について取り上げます。

そもそも HTTP とは？

まず、従来のWebプロトコル HTTP についておさえておきましょう。HTTPは Hypertext Transfer Protocol の頭文字をとったもの。その名の通り HTML (Hypertext Markup Language) 文書をサーバーからブラウザにダウンロードするために開発されました。ちなみに現在もっとも使われているバージョンは1.1です。

このHTTPの特徴は、動作が非常に単純であることにつきます。その動作パターンは以下のようになります。

1. ブラウザから、サーバーに HTML 文書を要求(request)する
2. サーバーは、ブラウザに要求された HTML文書を返す（response）

このため、HTTPは request & response型のプロトコルと呼ばれます。

Webの進化に伴い、スピードの問題が!!

Webが登場してしばらくの間は、このHTTPで全く問題がありませんでした。Webの初期は文書を表示することしかできなかったため、一つのHTML文書をダウンロードすれば良かったからです。

しかしWebの進化に伴い、特にスピード面で問題が出るようになりました。多くのリソースをダウンロードすることによる、パフォーマンス上のボトルネックが生じるようになったのです。

今皆さんが利用しているWebページは、多くのリソース（JavaScriptやスタイルシート, 画像など）から構成されています。例えば、HTML5 Experts.jpのトップページでは 80個のリソース から構成されています。これらのリソースを、HTTPを用いて 素直に 取得しようとすると、以下の様なパターンとなります。

1. ブラウザから、サーバーに HTML 文書を要求する
2. HTML 文書を取得したら、次のリソース（スタイルシート）を要求する …
3. 最後の画像リソースをダウンロードしたら、それを表示してWebページが完成する

つまり、request & responseの繰り返しが 80 回起きるわけです。もし、仮にサーバーからリソースをダウンロードするのに 1 回あたり、0.2秒かかったとすると 16 秒かかる計算になります。こんなに時間がかかっては、正直サービスになりません。

このため、現在Webで使われている HTTP1.1 では、同時に送信するリクエストの数を増やすことで、ダウンロード時間の短縮を図っています_[2]。運送業者にたとえるなら、80個の荷物を1台のトラックで1個づつピストン輸送するよりも、同時に複数台のトラックでピストン輸送したほうが早く終わる…という感じです。

この解決策により、スピードの問題は著しく改善しました。現在のWebでは様々なテクニックを駆使し、10本以上の同時リクエストを送信することで、スピードの高速化を図っています。

同時リクエストの乱用による新たな問題

しかし、このようなHTTPの同時リクエストの乱用は、新たな問題を生むことになりました。サーバーやネットワーク機器の負荷を上昇することとなってしまったのです。

先の運送業者の例で、伝え忘れていたことがありました。このトラックは、一本の車線を占有しないと走れないという困った特徴があります。これは、同時に10台でピストン輸送しようとすると、10本の車線が必要となることを意味しています。

これは、あまりにも大変で、無駄が多いことは直感的にわかると思います。トラックに積荷を載せる倉庫は、多くの車線をカバーする大きなものが必要になりますし、途中の道路についても同様です。

ここで、倉庫をサーバーとし、道路をネットワーク、車線をTCPコネクションとしたのが今のWebです。HTTPはTCPコネクションという車線の上を走るトラックに相当しますので、同時に送信するリクエスト数が増えれば増えるほど、TCPコネクション数が上昇し、サーバーやネットワークに過剰な負荷を引き起こします_[3]。

SPDY, HTTP2.0の登場

このようなTCPコネクション数の乱用による問題を解決するために登場したのが SPDY, HTTP2.0です。これらの最新Webプロトコルを用いることで、スピードを高めつつ、サーバーやネットワークの負荷を下げることが可能となりました。

そのアイディアは非常に単純・明快です。トラックでたとえれば、一台あたり一本の車線を専有してしまうのが諸悪の根源です。もし筆者が運送業者の社長であれば、運転手を説得し、全てのトラックを一本の車線で走らせることでしょう。冒頭の図面のように。SPDYやHTTP2.0についても、全く同様のアイディアです。複数のHTTPを一本のTCPコネクションで運べるようにしたのです_[4]。

最初に登場したのは、SPDYです。Googleが提唱した独自プロトコルで、ドラフト仕様が最初に公開されたのは 2009 年のことです。HTTPの多重化以外にも、HTTPヘッダーの圧縮やサーバープッシュ、フロー制御など高速化のためのさまざまな機能が盛り込まれています。

既に、Googleの各種サービスや Twitter, Facebookなどの大規模サイトで実際に利用されており、運用実績があるのも大きな魅力です。ブラウザとしてはすでにChromeやFirefoxが対応しており、Internet Explorerの次期バージョン IE11 でもサポートされることから、今後更に普及することが予想されます。

HTTP2.0の検討は、SPDYをきっかけとして 2012年に始まりました。SPDYのエッセンスを新しい HTTP のバージョンに盛り込み、HTTP1.1の様々な問題を解決した標準仕様を策定しようとする取り組みです。最初のドラフトは SPDY そのものでしたが、徐々にその形を変えてきています。今年度内には、テスト実装も予定されており、これをベースとして検討がより具体化されると予想されます。

SPDY と HTTP2.0の関係・これから

SPDYとHTTP2.0の関係ですが、SPDY/4では、HTTP2.0仕様の一部を取り込み始めています。短絡的に考えるのは早計ですが、SPDYとHTTP2.0は互いに影響を与えながら、あるべき次世代 HTTP の結論を導くことでしょう。

ただし、SPDYがカバーしようとする領域は HTTP だけではありません。Webに関わるその他のプロトコル〜DNSやWebSocketなど〜もSPDYの中に取り込んでいこうとするアイディアもあります。こういった様々な興味深いトピックも、HTML5 Experts.jpでは今後紹介していければと思っています。

[1] このシリーズは、最新Webプロトコルの入門編的な記事です。その後、より詳しいシリーズを執筆する予定です。

[2] 正確にはHTTP1.1というより、現在のブラウザのHTTP実装がそうなっているというほうが正しいのですが、話が複雑になるので割愛します。

[3] 例えばIPv4枯渇に伴い、特にモバイルキャリアのネットワークに CGN（Carrier Grade NAT）の導入が進んでいますが、このような振る舞いがCGNに大きなインパクトを与えています。

[4] 多重化のアイディアは、HTTP1.1でもpipeline仕様として存在しているのですが、相互接続性の問題から実際には殆ど使われていません。