次世代規格 HTTP2.0 のファーストドラフト公開

intro

少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、

が、IETF の httpbis ワーキンググループで公開されました。

このドラフトは Google から提案された仕様である SPDY が採用されています。

HTTP1.1 からのアップデート

HTTP1.1 の RFC が提出されたのは 1999 年で、
13 年経った今年 2012年8月に、 HTTP の仕様を議論する httpbis というワーキンググループが、
HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。

これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、
そしてなによりも、 Web の使われ方が大きく変わり、
求められている要求を満たすためには、見なおすべき点が現行の HTTP には多い、
という点からの策定着手と見ることができます。

複数の Proposal Draft

HTTP2.0 のドラフトに対する提案は、いくつかあげられていました。
主な個人ドラフトは以下の 3 つです。

(今回公開された draft-ietf-httpbis-http2-00 のように ietf という文字が入っているものは WG(ワーキンググループ) ドラフトと言い、
httpbis WG の中で採用されたものということを意味します。それに対して、ここに個人の名前(ないし愛称)が入っているものは、
個人ドラフトであり、ようするに WG ドラフトの元になる提案です。)

SPDY

http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy

今回採用されたドラフトであり、Google の Mike Belshe 氏の名義で出ています。
2009 年ごろから Google 内で開発され、現在では Google のほとんどのサービスで採用されているプロトコルです。
実装があり実績も十分にあるというのが、このドラフトの強みと言えます。
(最初に知った頃はこんなことになるとは思わなかった。。)

multiplexing や compression などの基本的な効率化仕様はもちろん、 Server-Push や優先度付きストリームなどの仕様も含んでいます。
TLS に依存しないと言いながらも、ブラウザの場合は NPN(Next Protocol Negotiation) を用いて接続するため TLS が事実上前提となります。

現在 SPDY には仕様が 4 バージョンまでありますが、実質中身があるのは 3 つです。 SPDY Protocol - The Chromium Projects
今回 IETF にあがったのも、この SPDY Draft-3 でした。

HTTP Speed+Mobility

http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility

Microsoft の Gabriel Montenegro 氏名義で出ています。
モバイルを重視し、スピードとセキュリティを強調した仕様として出ています。
ベースは SPDY であり、幾つかの仕様を外したりオプション扱いにしているものです。

大きな特徴として Session Layer に WebSocket を採用し、その上で通信を行うこと、
暗号化を必須にすべきではないとして、 TLS を必須にはしてないことが挙げられます。
(SPDY も使用上は必須ではないんですが、 NPN を使うのでブラウザからだと事実上必須な実装になります)

Network Friendly

http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly

HAProxy の作者 Willy Tarreau 氏名義で出ています。共同で Squid の作者 Amos Jeffries 氏も関っているよう。

正直自分はこの仕様についてはよく知らないです。

他のも含めて、こちらに概要がまとまっているので説明は譲らせて頂きます。
【HTTP 2.0の最新動向】第1回：HTTP/2.0の策定、ついに始まる -INTERNET Watch

HTTP/2.0 Deliverables

こうした複数のドラフトの中から、 SPDY が HTTP2.0 のドラフトとして採用したのには、
やはり既存の実装があり、それが Google で全面的に採用されているという実績があるようです。

とはいえ、実は SPDY が HTTP2.0 のたたき台になることは、策定に着手した段階からある程度決まっていたことなので、
驚くほどではないといえば、そうなるかもしれません。

HTTP2.0 策定開始時には、以下のように宣言されています。

http://trac.tools.ietf.org/wg/httpbis/trac/wiki#HTTP2.0Deliverables

We're also chartered to work on a replacement for how HTTP is expressed "on the wire."
This effort is known as "HTTP/2.0", although it is not a ground-up rewrite of the protocol.

The basis of the work is [http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00:title=SPDY].
However, we will be collecting issues against this document, as well as confirming consensus over individual portions.

See also [http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00:title=Tickets] related to HTTP/2.0.

また、 HTTP2-00 が公開された日にも ML で以下のように強調されています。

http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0447.html

This draft is (obviously, I'd hope) NOT for implementation.
When we get to a point where we've addressed some issues and evolved the protocol sufficiently,
we'll mark a draft for test implementation;
I'm hoping this will happen very early next year, and we'll iterate as necessary after that.

So, please have a look and start thinking about what needs to change.

要するに、 SPDY はあくまでも議論のたたき台(呼び水) であり、ゼロから議論を開始するより既存の仕様をもとにしたほうが良いだろうという目的です。

ここから、様々な議論をもとに diff を積んでいくことになりますが、それでも多重化や圧縮などの仕様は入るだろうし、
バイナリフレームなのも避けられないだろうから、そこをベースにできるものがある方が議論が捗るだろうというのが採用の大きな理由と言えます。
また、既存の実装があると試せる(ベンチがとれる)というのも大きいでしょう(S+M はそこが弱かった)。

大きめな問題

こうして、SPDY が土台となったわけですが、もうすでに issue となっている点がいくつかあります。
現在 HTTP2.0 を策定するにあたって、議論の対象となっている幾つかの問題について紹介します。

Upgrade

HTTP2.0 のプロトコルをどうやって使うのか、といった問題です。
この議論の前提には「HTTP2.0 も 80/443 ポートで使いたいよね」という要望が透けて見えており、
実際 80/443 を基本(capability but not the requirement) として話が進んでいます。

SPDY では、 TLS が事実上の前提となっているため、 NPN(Next Protocol Negotiation) を使って SPDY に移行し、
もし SPDY がアクセプトされたなかった場合は、 HTTPS で接続するという方法が取られています。

これでは HTTP2.0 を事実上 TLS 前提のプロトコルとしなくてはなりません。
しかし、 HTTPbis では「HTTP2.0 が TLS でしか動かないという仕様は避けるべき」という流れもあり、
TLS でない場合は HTTP1.1 の 101 Switching Protocols を用いて upgrade する方法が提案されています。

draft-lear-httpbis-svcinfo-rr-00 - A DNS Resource Record for Service Descriptions

この方法は WebSocket でも採用されており、互換性の観点から移行しやすいのが特徴です。

upgrade などを用いる方法は、要するに一度サーバに問い合わせてから、その後の通信方法を決めるわけですが、
もし、クライアントがサーバの対応するプロトコルを「事前に」知ることができれば、
最初から HTTP2.0 などを用いた接続をすることができます。
この観点から、 DNS の srv レコードなどを用い、名前解決時に解決先のサーバの情報(対応するプロトコルなど)を送るという方法も提案されています。

draft-lear-httpbis-svcinfo-rr-00 - A DNS Resource Record for Service Descriptions

新しいプロトコルを策定する際に、一番大きな問題になるところなので、先の IETF 85 のミーティングでも議論が盛り上がったようです。
minutes を見ると、 DNS から着手する感じなんでしょうか？ DNS 詳しくないので、勉強が必要です。。

http://www.ietf.org/proceedings/85/minutes/minutes-85-httpbis:minutes-85-httpbis

TLS

TLS の扱い(必須とするかどうかなど)という点も、重要な論点となっています。
これは、前節でも触れたように NPN を使ってプロトコルを変更する場合は TLS が必至となりますが、
それ以外にも「TLS を必須にしたほうがいい」と「そもそも TLS を必須にするのはいかがなものか」という
二つの議論があるようです。

もちろんセキュリティ面から TLS を必須にするというのもありますが、
暗号化してしまえば、パケットの中身は基本的にエンド同士しか見れなくなるわけなので、
intermediaries (中間サーバ e.g. proxy) などを通しやすくなるというメリットもあります。
一方で、 Web において TLS を必須にするということ自体が、
様々な点で自由度を下げるという意見もあります。

また、 NPN もまだドラフトの段階であるため TLS の WG とも調整が必要といった、
影響範囲の問題なども出てきているようです。

Compression

CRIME の登場で一時荒れた圧縮関連ですが、概ねヘッダ圧縮は必要という論調です。
SPDY のドラフトを書いた Mike Belshe は、 S+M のドラフトがヘッダ圧縮をオプションにしたことに対して以下のように言っています。

http://www.belshe.com/2012/03/29/comments-on-microsofts-spdy-proposal/

Lastly, I’m puzzled as to why anyone would propose removing the header compression.
We could argue about which compression algorithm is best,
but it has been pretty non-controversial that we need to start compressing headers with HTTP.
(See also: SPDY spec, Mozilla example, UofDelaware research)

要するに、「ヘッダ圧縮を仕様から外したがる理由がわからない。そこの議論より、早くどの圧縮アルゴリズムがベストかを議論したい。」という感じ。

コメント欄では、デバッグ目的で圧縮をオプションにするのは良いかもといいつつも、基本は前提で考えているようです。

そもそもの目的に HTTP の高速化がある以上、バイナリベースのプロトコルで圧縮を必須にするといった仕様は、入ってくるんじゃないかと思います。

WebSocket は、圧縮の仕様を WebScoket Extension (拡張) の仕様として策定中で、 Deflate を基本としています。
HTTP2.0 においても、圧縮を前提にする合意が取れると、 CRIME の件も含めてどの圧縮アルゴリズムを使うのかの議論が始まるのではないかと思います。

その他

issue で上がってるものとしては、

Server Push
Flow Controll
prioritisation

など、 SPDY が定義していた機能が上がっています。
特にこの辺は割りとエッジが効いた機能なので、色々な意見があがりそうです。

情報

issue

HTTP2 Tickets – httpbis

チケットはこちらで管理されています。
もし、「HTTP について一言ある」といった方は、こちらから登録されると良いかと思います。

HTTP2.0 twitter acount

https://twitter.com/http_2

まだ少ないですが、最新情報を呟いてくれるそうです。

HTTP2 Github Account

https://github.com/http2

検証コードやサンプル実装が上がるようです。

ミーティング

http://trac.tools.ietf.org/wg/httpbis/trac/wiki/F2F/Jan13

なんと、この HTTP2.0 の issue を徹底的に話し合う場として、
HTTPbis のミーティングが開催されることになりました。

期間は、 2013/1/30 から 2/1 まで。
場所はなんと日本！！、東京六本木の Google 本社で行われるようです。

参加に特に条件は書かれてないけど、 IETF の ML くらいは参加してれば、
基本は誰でもいけるのかな。。
しかし、行きたい人は直接 Chair にメールをするというハードルの高さ。。
そして「ど平日」。

うーん行ってみたい。。

まとめ

まだまだ、本当に始まったばかりの仕様ですが、これは「次期標準仕様」のためのドラフトです。
つまり、我々が普段当たり前のように使っている Web を、根っこで支えている HTTP に
まさしくメスが入ろうとしています。

Web に対する大きな変化はこれまでにも色々あったと思います (CGi, Ajax, HTML5 etc)。
しかし、HTTP 自体がここまで大きく変わるのは、それらと比較してもやはりインパクトのある変化といえるでしょう。
この影響範囲の大きさは、このブログを読みに来た方ならお分かりかと思いますが、
特に技術者サイドから見ると、大きな影響のある変化になりえます。

今回提出されたドラフトが、来年どうなっていくのか、注目してみたいと思います。

注意

なるべく出展を明示していますが、それ以外は自分自身の意見や、自分自身が感じてる議論の雰囲気をもとに書いています。
また、ここに書かれていることの賞味期限はとても短いと思います。ご注意下さい。

また、例によってもし間違っている点などあったら教えて頂けると幸いです。

Block Rockin’ Codes

back with another one of those block rockin' codes