「HTTP/2」制定の背景や「HTTP/1」との違い、Akamaiのマーク・ノッティンガム 氏が説明

ニュース

（2015/7/7 06:00）

　HTTPの最新バージョンである「HTTP/2」は、IETFのhttpbisワーキンググループで制定され、2015年2月に正式な仕様として承認された。このhttpbisワーキンググループのチェアマンであるAkamai Tehcnologiesのマーク・ノッティンガム氏が来日し、報道関係者向けに説明会を開いた。

マーク・ノッティンガム氏（Akamai主席アーキテクト兼IETF httpbis Working Groupチェアマン）

　まずHTTP/2が必要とされた背景として、ノッティンガム氏は、インターネット上のトラフィックの増加や、遅延が損失に直結するようになったこと、今では大きな割合を占めるモバイル通信では遅延が大きくなることを挙げた。

　一方、ウェブで1つのページを読み込むには、画像やCSS、JavaScriptなど複数のファイルを読み込む必要がある。そのため、現在ではウェブ製作者は、リクエスト数を減らそうと努力。複数の画像を1枚にまとめて必要な部分だけ表示するCSSスプライトや、画像データを符号化してCSS内に記述するインラインイメージ、JavaScriptやCSSの複数のファイルを1つにまとめる結合などの工夫（ハック）がなされているという。

モバイル回線の遅延とページのロード時間

　「HTTPリクエストはなぜそんなにコストが高いのか」としてノッティンガム氏は、「HTTP/1のTCPの使い方がよくない」と「HTTPヘッダーが饒舌」という2つの理由を挙げた。

　TCPの問題というのは、HTTPのリクエストとレスポンスごとに1つのTCPコネクションを使うことを指す。これにより、1つずつしかリクエストを処理できず、レスポンスの待ちが発生するという。HTTPパイプラインを使っても順次処理されるため、大きな画像などがあるとそれ以降は待たされる。

　また、HTTPヘッダーの問題としては、複数のリクエストを連続して送る時に、リクエストヘッダーの多くの部分が共通していることがある。ノッティンガム氏はetsy.comへのリクエストを例に、1つのページで4つのリクエストが発生し、合計2,596バイトのうち1,797バイトが冗長なものだったと説明した。特にTCPのウィンドウサイズが小さい時などは、データが大きいとTCPレベルの往復が複数回になり、遅延の大きい回線ではより時間がかかる。

1つずつしかリクエストが処理されないため待ちが発生する問題

リクエストヘッダーに共通部分が多く冗長という問題。このヘッダーの場合、反転した箇所以外は前のリクエストと同じ

　こうした問題を解決するために、HTTP/2が作られた。ベースとなったのはGoogleのSPDYで、現在は35以上の企業や実装が対応しているという。

　目標は「1つのTCPコネクションで」やりとりすること。そのための技術要素として、「フレームからHTTPセマンティクスを分離」「ヘッダーの圧縮」「サーバープッシュ」の3つをノッティンガム氏は挙げた。

　HTTP/2では、「フレーム」という単位が使われ、1つのセッションの中で接続設定やHTTPヘッダー、データ本体、接続終了など、複数のフレームがやりとりされる。各フレームにはIDが付けられ、これによってリクエストとレスポンスが対応付けられるため、リクエストとレスポンスを多重化できるという。

　また、HTTP/2では、HPACKによりヘッダーサイズを圧縮する。HPACKは、前に送ったヘッダーを後のリクエストから参照することで、ほとんど差分だけ送ればいいようにする。

　サーバープッシュは、リクエストなしにサーバーからクライアントにデータを送るものだ。これにより、例えばHTMLファイルのリクエストが来た時に、次はそこから読み込まれるCSSファイルのリクエストがあるものと想定して、CSSファイルも送ってしまって全体の応答時間を短縮するといった使い方ができるという。

HTTP/2のフレームの種類

IDでフレームを識別してリクエストとレスポンスを多重化する

ヘッダーのHPACK圧縮

サーバープッシュで全体の応答時間を短縮する

　HTTP/2の影響は、まず高速化できることだ。ノッティンガム氏は、「速くなるのを保証するものではない。レアケースではパフォーマンスが落ちることもある」と前置きしながら、GoogleやTwitterで高速化したデータを紹介。さらに、Wikipediaのページをロードした時の処理の様子をHTTP/1とHTTP/2で比較し、HTTP/1で発生していた待ちがHTTP/2では解消されることを示した。

　また、HTTP/2ではTLS（HTTPS）が事実上必須となる。仕様ではTLSを使わない場合のことも記述されているが、ブラウザーの実装ではいずれもHTTP/2にTLSを必要としているという。「仕様を決めたのはスノーデン事件より前だったが、最近は常時HTTPSの動きもあり、いま仕様を決めると違う結論になるかもしれない」とノッティンガム氏は説明した。

　ウェブ開発者にとっては、やりとりがテキストからバイナリーに変わることで、デバッグ方法が変わるという変化もある。これについては、いくつかのツールが出てきていることをノッティンガム氏は紹介した。

GoogleのHTTP/2による高速化実験（ただしSPDYでのもの）

TwitterのHTTP/2による高速化実験（ただしSPDYでのもの）

HTTP/1とHTTP/2でWikipediaのページを読み込む処理の比較。HTTP/1（上）で発生していた待ち（茶色の部分）がHTTP/2（下）では解消されている

　IETFでのこれからの取り組みとしては、現在策定中という「Alternative Services」が紹介された。HTTP/2ではコネクションの寿命が長くなることから、ロードバランスやフェイルオーバーの考え方が変わるとノッティンガム氏は語る。Alternative Servicesは、サーバーからクライアントに代替のアクセス先を通知し、クライアントが望めば新しいアクセス先に移る仕様。これによって、ロードバランスやフェイルオーバーがシームレスに行なえるとノッティンガム氏は説明した。

　また、現在のTCPの制限を超えるため、Googleの「QUIC」をはじめとする新しいトランスポート層のプロトコルが議論されているという。「数週間後にプラハでIETFの会議があり、そこでも議論されるだろう」とノッティンガム氏は説明した。

　なお、HTTP/2が実際に使われる時期についてノッティンガム氏は、ウェブサーバー側がまだ実装中のものが多いとし、OSのディストリビューションに入るのはさらに先になるだろうとしながら、クライアント側はすでに対応しているためトラフィックのある程度の割合はHTTP/2が使われていると語った。