次世代プロトコルはどう作られる？HTTP/2.0相互接続試験参加レポート（標準化作業編）

大津繁樹

7年前

先日私はドイツで行われた第1回目のHTTP/2.0接続試験に参加してきました。今回、この接続試験を通じて次世代プロトコルがどのように作られていくのか、HTTP/2.0の仕様策定作業の最前線の様子を少しご紹介したいと思います。

はじめに

先日公開された小松健作さんの記事「変わる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回中間会議が、ドイツ・ハンブルグで開催されました。

ハンブルグの風景

HTTP/2.0の仕様案を執筆するコアメンバーとChromeやFirefoxといったブラウザーのSPDYスタックを実際に開発しているソフトウェアエンジニアなど、20数名がAdobe社の会議室に集まりました。私は5月より仕様検討やドラフトの修正作業に参加していますが、実際の会議は初参加です。今回、Node.jsで新たに開発したHTTP/2.0モジュールiij-http2を持参して相互接続試験に臨みました。

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

1日目: 終日実装者からのフィードバック、issueの議論・整理
2日目: 終日相互接続試験
3日目: 午前 issueの議論・整理、今後のロードマップ策定

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

HTTP/2.0の初期接続が問題なく完了し、HTTP/2.0の処理が開始できること。
新しいヘッダ圧縮仕様を使って問題なく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仕様ドラフトに基づくものです。今後仕様が変更され記述内容と異なる可能性がありますので、ご注意ください。)