HTTP 2.0の最新動向

　東日本大震災直後の例を紐解くまでもなく、インターネットはすでに社会的なインフラとして認識されていると言ってよい。その上に構築されているウェブの世界は、ビジネスをはじめとする近代社会の基盤としてなくてはならない、新しい大きな世界となりつつある。

　ウェブ技術の革新が日々進む中、いわばウェブの下位レイヤーであるHTTPやその周辺技術も、大きな進化を遂げようとしている。 しかしながら、日本語では断片的な情報ばかりでまとまった情報はあまり見受けられず、その真価が日本国内では広く認知されていないように思う。

　そこで本連載では、IETF（Internet Engineering Task Force：インターネットで利用される技術を標準化し、規格として策定することを目的とする組織）に参加し、アプリケーションエリア（IETFにおいて、ウェブや電子メールに関連する技術の標準化を担当するエリア）をはじめとした領域でHTTP認証プロトコルの標準化を推し進めている立場から、HTTP/2.0の策定・標準化を中心に、WebSocketやWebRTC等も含め、IETF周辺におけるWeb関連技術の標準化の最新動向を、基本的に月1回のペースでご紹介していく予定だ。

●HTTP/2.0の策定、ついに始まる

　すでにご存知の方も多いかと思うが、2012年初めごろから少しずつ、HTTP/2.0の策定が進んでいる。

　HTTP/2.0の策定を行うHTTPbisワーキンググループは、そもそもHTTP/1.1の純粋な改良を目的としたワーキンググループだった。2007年頃から行ってきたHTTP/1.1の改良の作業に一段落が付きそうになったことで、2012年1月頃から少しずつHTTP/2.0の策定についての話題が出始めていた。その後、2012年3月に開催されたIETF83の会合においていくつかの提案がなされたことで、だんだんと実際の策定への気運が高まった。

　「HTTP/2.0」という言葉だけを見ると、「Web2.0」や「HTML5」の時のように、何やら革新的な新機能が導入されるような印象を覚えるのではないだろうか。しかし、現在HTTP/2.0の策定において目標とされているのは、従来のHTTPのありかたを継承しつつ、現状困っている点を改善することだ。主にHTTP/2.0には、以下のような改善が求められている。

• 特定の環境に限定しないパフォーマンス改善(例: デスクトップブラウザとモバイルブラウザ、回線の速度やレイテンシの違い等)
• ネットワーク資源のより効率的な使用（特に、TCPセッション数の削減）
• 現代的なセキュリティ要件および慣習の反映

　実際に標準化作業が開始してからまだ半年程度しか経っていないこともあり、現段階ではHTTP/2.0としてはほとんど形になってはいない。しかし、IETFのメーリングリストや、定期的に開催されるミーティングの会場では活発に議論が行われている。2012年6月にHTTP2.0策定のスタートポイントとなるいくつかの草案が提出された後は、様々な立場からのレビューや議論が交わされるようになった。

　6月に実際に提出された提案は、以下の3つだ。

• Mike Belshe氏ら（Google）の「SPDY」
• Gabriel Montenegro氏ら（Microsoft）の「HTTP Speed+Mobility(S+M)」
• Willy Tarreau氏（HAProxy Project）やAmos Jeffries氏(Squid Project)らの「Network-Friendly HTTP Upgrade」

　これらの提案それぞれの目的や特徴についてご紹介しておこう。

●SPDY

　SPDYは、2009年頃からGoogleが開発しているHTTP通信を高速・効率化することを目的としたプロトコルで、主に以下のような特徴を持つ。

• 通信の多重化(Multiplexing)によるTCPセッション数の効率化や応答速度の向上
• 優先度の制御による体感速度の向上
• ヘッダ及びコンテンツの圧縮による使用する帯域幅の削減
• サーバーからのコンテンツプッシュ配信による必要な要素の事前キャッシュ

SPDYの概念図

　SPDYは、プロトコルとしてTLS（Transport Layer Security）による暗号化がほぼ必須といっていい。そのため、コンテンツ事業者に対する負荷が増大すると考えられるのだが、提案者は「RC4（Rivest’s Cipher 4）を用いた暗号化やハンドシェイクに必要なCPUリソースは低く、証明書も無料で取得でき、実際にTLSを使用するSPDYのほうが従来のHTTPより高速である」という調査結果を提示している。

　しかし、この調査結果についてはAkamaiの設計者をはじめ、いくつか異論の声も上がっている。どうやら、ウェブサイトの条件によって結果にぶれがでるようで、ただ単純に導入すればウェブサイトを高速化することができる夢のような技術というわけではなさそうだ。

　また、TLSが必須になると、今までリバースプロキシーやロードバランサー、SSLアクセラレーターなどを用いて、負荷分散等のバックエンドに平文通信を利用していたコンテンツ事業者にとっては、規模の大小はあるものの、設備の増強を余儀なくされることは容易に想像できる。もっとも、現段階で世に出ている製品は基本的にHTTP/1.1にしか対応していないため、今後何らかの対応が必要になるという点は、SPDYに限った話ではない。

　その他、今回の提案の中で唯一、HTTP/1.1から通信を開始することができない点が気になるところだ。

●HTTP Speed+Mobility(S+M)

　HTTP Speed+Mobility（S+Mと省略されることが多い）は、WebSocketでセッションを確立し、その中でSPDYの提案を利用する提案だ。また、不要とも考えられるSPDYの細かないくつかの機能を削除している。この提案では、そもそも暗号化が要求されない、または不可能な通信も多く存在する中、現状のHTTPを置き換えるプロトコルであるHTTP/2.0において暗号化を必須にしてはならないという主張のもと、TLSによる通信をオプションとしている。

　そのためTLSを前提とするSPDYと異なり、最初はTLSではないHTTPから通信を開始することができ、既存のHTTP実装や現状のユーザーの利用法との親和性が高いと考えられる。

HTTP Speed+Mobility(S+M)

●Network-Friendly HTTP Upgrade

　Network-Friendly HTTP Upgradeは、プロキシーやロードバランサーなど、クライアントとサーバーの間でHTTPを処理する機器やソフトウェアからみた課題やプロトコルに対する要求などをまとめ、以下のような改良を加える提案だ。

• 通信の多重化によるによるTCPセッション使用数の効率化や応答速度の向上
• アウトオブオーダー処理による体感速度の向上
• ヘッダー等各要素の長さの埋め込みによるパースにかかる資源の削減
• バイナリーエンコードの利用などによるパースにかかる資源の削減
• 頻繁に用いられるヘッダ名やメソッド名の短縮による使用する帯域幅の削減
• 通信セッション内で共通な情報、連続したリクエストで共通な情報やメッセージを分類して、共通な情報は再送しないことによる使用する帯域幅の削減

　この提案についても、WebSocketと同様に既にHTTPに用意されているUpgradeヘッダーを用いてプロトコルの切り替えを行うため、HTTP/1.1から通信を開始することが可能である。

Network-Friendly HTTP Upgrade

●SPDY or Not SPDY？

　HTTP/2.0に関する話題として、「SPDYがベースになる」という記述を目にする機会が何度かあった。

　SPDYは現時点でGoogleやTwitter等のウェブサービスで実際に利用されており、ブラウザー実装にChrome、Firefox、Opera（開発版０、サーバー実装にApache、Jetty、nginx（開発版）などが存在する。これをもって、GoogleはすでにSPDYの事実上のデプロイは完了していると公言している。確かにすでにデプロイが進んでおり、HTTP/2.0と目的が重なるところの多いSPDYが、HTTP/2.0の策定においてスタートポイントとなることに間違いはない。しかし、SPDYがそのままHTTP/2.0になるかと言われると、答えはノーである。

　IETF84の議論中の質問において、SPDYの仕様そのものについて合意が取れているとはしないことが明確となり、 このことはワーキンググループのチャーター（目標を記述した文章：httpbis WG Charter／URL　http://datatracker.ietf.org/wg/httpbis/charter/）にも記述された。すなわち、SPDYはあくまで土台としての採用にすぎず、全体の再検討を行うことを前提としている。

　また、SPDYは通信開始時にTLSのNPN（Next Protocol Negotiation：TLSセッションを確立するための最初の通信時に、その通信の中で利用するプロトコルを明示することにより、1つの受け口で複数のプロトコルによる通信の待ち受けを可能とする技術）拡張を使用して、TLSセッションの確立時に、従来のHTTPを使用するかSPDYを使用するかを決定する。そのため、現状のSPDYはTLSを使用することが事実上前提となっており、HTTPS以外で利用することができない。

　議長のMark Nottingham氏はこの点について、HTTPSのみでしかHTTP/2.0が利用できないような状況にするつもりはないと公言しており、TLSを用いない通信時の仕様は、新たに策定することになるだろう。 この点についても、HTTP URL時のネゴシエーション方法等に対する検討の必要性がチャーターに記載されている。 メーリングリストにおいては、DNSのSRVレコードを用いる方法等が挙げられているほか、既存のHTTP/1.1に用意されているUpgradeヘッダーを用いた方法が提案されている。(HTTP 2.0 Negotiation／URL　http://tools.ietf.org/html/draft-montenegro-httpbis-http2-negotiation-00)

　以上のようなことから、SPDYがそのままHTTP/2.0として標準化されることはまずなさそうだ。

●難航する先行技術との連携

　HTTP/2.0の策定は突発的に始まったこともあり、関連する他の活動との連携の薄さが目立つところが大きい。たとえば、SPDY等の提案に含まれるもののうち、通信の多重化（Multiplexing）やフレーミングの機能については、現在までWebSocket（ウェブブラウザーとサーバーの間で双方向リアルタイム通信を実現する技術）の標準化において議論してきた内容と重複している。

　同じような機能を上下レイヤでそれぞれ持つ意味はほとんどなく、たとえばTCP over TCPにおける性能劣化のように、通信の効率を落とす可能性すらある。 実際、WebSocketのプロトコル部分を策定しているhybiワーキンググループのセッションでは、HTTP/2.0との兼ね合いについて言及されていた。

　また、前述したTLSのNPN拡張は現状、インターネットドラフトとして提出はされているものの、標準化の目処は立っていない。そのほかにも、HTTP/2.0の策定によって影響が出る範囲は予想以上に大きいと考えられ、周辺との綿密な調整が必要となるだろう。

　前述したとおり、SPDYがスタートポイントとは言われているものの、全体を見直す必要があり、少なからず修正が入ることは明らかだ。このことからも、HTTP/2.0標準化は、策定までもう少し相当な時間がかかると予想される。

　以上が、2012年10月現在のHTTP/2.0の主な状況だ。しかし、モバイルデバイス等の普及による爆発的なトラフィックの増加や、IPアドレス等の資源枯渇の深刻化、より安全な通信に対する需要の高まりは日々進行する一方である。これらに対応するためには、HTTP/2.0の策定を急ぐ必要があると言えるだろう。もうすぐIETF 85ミーティングが開催される。まだまだ慣れない身ではあるものの、今後の動向をしっかり追いかけたい。

●用語解説

IETF
Internet Engineering Task Forceの略称で、インターネットにおいて利用される技術を標準化し、規格として策定することを目的とする組織。

アプリケーションエリア
IETF内の用語。IETFにおいて、ウェブや電子メールに関連する技術の標準化を担当するエリア。現在標準化が行われている代表的なものに、HTTP、WebSocketなどがある。

ワーキンググループ
IETFなど標準化委員会内で用いられる用語。1つあるいは複数の技術についての標準化を、実際に行う部会。たとえば、HTTP/1.1の改良及びHTTP/2.0の策定はhttpbisワーキンググループが作業を行っている。

インターネットドラフト
標準規格として発行される前の草案のこと。インターネットドラフト自体は誰でも自由に投稿することができ、必要性が認められたものについてはRFC等として発行される。

WebSocket
ウェブブラウザーとサーバーの間で、双方向リアルタイム通信を実現する技術。リアルタイムに情報を更新するWebサイトやチャットなどへの利用が想定されている。

WebRTC
異なるユーザーのウェブブラウザ同士で、双方向リアルタイム通信を実現する技術。ビデオ通話などへの利用が想定されている。

Apache
Apache Foundationが開発しているHTTPサーバーソフトウェア。

Jetty
Javaで記述されているHTTPサーバー/Java Servletコンテナ。

Nginx
高速な動作を特徴とする、HTTPサーバー/リバースプロキシー。

TLS Next Protocol Negotiation(NPN)
TLSセッションを確立するための最初の通信時に、その通信の中で利用するプロトコルを明示することにより、1つの受け口で複数のプロトコルによる通信の待ち受けを可能とする技術。現時点で標準化は行われていないものの、利用例がいくつか存在する。

Multiplexing
1つの通信セッション中に、異なるコンテキストの通信を同時に含めて通信する技術。送信側でデータに対してコンテキスト毎に異なる識別子を付与し、受信側でそれをもとにコンテ キストを識別する等の手法が存在する。

TCP over TCPにおける性能劣化
TCPセッション上でTCPパケットをカプセル化することによって生じる性能劣化。TCPがもつ、信頼性向上を実現するための仕組みに起因する。