Block Rockin’ Codes

back with another one of those block rockin' codes

これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2014)

Update

2014-01-19 振り返り

CROSS2014 が無事終了しました。

以下ログです。ビデオは前のセッションとかぶっているので 35 分くらいからが本セッションです。


去年に引き続き、今年もなかなか密度の高い内容になったんじゃないかと思います。

プロトコル編では、普段なかなか表に出てこない方を中心にお呼びして、2013 年から今日までの流れを踏まえつつ、今起こっているプロトコル的な変化を浮き彫りにし、今後の HTTP2.0 の展望や QUIC の持つ意義などを話し合いました。
象徴的なのは「TCP/IP の破壊」などという想定外に振り切った本音に見て取れるかと思います。こうした発言が出たあたり、非常にやった甲斐を感じました。


アーキテクチャ編は、去年より幅広いポジションの方々に出て頂き、それぞれの視点から現実的な話をして頂きました。去年の CROSS で「リアルタイム」として語っていた内容が、「ゲーム」というより具体的なものに繋がり、新しい技術の適応先の一例として興味深い話も出ました。確かに今回は出て頂いた方の携わる分野的な偏りもあったと思いますが、それでも現在の Web について語る上で、ゲームを「完全には無視できない」というのが自分としては盲点だったところかと思います。


全体を通しては、「TLS 前提の Web」という風潮の是非に対する、プロトコル編 / アーキテクチャ編双方のスタンスに割と明確な差異が見いだせました。プロトコルを考えるロール、それを用いてサービスを運用するロール、双方の意見が聞けたのがこのセッション構成をとった 1 つのメリットとして見いだせたのかなと思っています。


反省点は色々ありますが、少なくとも [twitter:muddydixon] さんに「もうやるな」と言われない限りは続けていきたいなと思っています。
(あと、 1 年に 1 回だと少し間が長いし、もっと色々な方とも議論もしてみたいので、 CROSS 以外にも場を作ったり、場が無ければ Podcast にしてみても面白いかなぁ、などと思っています。)


あまり俺が色々書くより、セッションの最後でも話した、参加者による「自分の考える次世代 Web」ブログにそこは譲って(出てくるといいなぁw)、自分のまとめとしてはここまでで。

最後に、出て頂いた登壇者の皆さん。参加して下さったみなさん。そして CROSS スタッフのみなさん。本当にありがとうございました & お疲れ様でした!

Jxck



Intro

2014/1/17(Fri) に開催される CROSS2014 にて、
CROSS2013 に引き続き「次世代 Web セッション」というセッションを担当させていただくことになりました。

今日はこのセッションの意図と概要について書こうと思います。
セッションで扱わない内容などについても言及するので、参加される方はこのエントリを README(趣意書) だと思って参加前に目を通して頂ければと思います。


去年のログ: これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013)

テーマ

このセッションのメインテーマは去年と同じです。

「次世代 Web セッション」ではいま起こっている Web の変化について、

  • 「何が起こっているのか」
  • 「どこに向かっているのか」

を議論することを目的としています。


また、その議論の主軸を絞るために 2h の枠を

の 2 つのセッションに分けて議論します。

登壇者

今年も豪華な登壇者の方々に集まって頂くことができました。
(公式サイト用プロフィールを引用)

プロトコル編」

@さん
Aria2/Spdylay/nghttp2/Wslay の作者 https://github.com/tatsuhiro-t
@ さん
Chromium Project にて、主に WebSocket, XHR の実装及び関連仕様の標準化を担当。それ以前は、現職にて Load balancer の開発、大学にて FPGA を用いた TCP/IPv6/10GbE の高速化研究など。
@ さん
2009年頃から主にIETFを中心とした標準化活動に参加。現在、通信プロトコル、認証・認可等のセキュリティ領域、プログラミング言語処理系等を主な活動対象としている。


アーキテクチャ編」

@ さん
2011年よりカヤックに入社。自社サービス、ソーシャルゲームのサーバインフラ、運用、監視を担当。
@ さん
2006年はてな入社、2010年より2代目CTO。技術的なことであれば、なんでも好物。はてなのサービスと技術の進化を加速させていきます。著書に「サーバ・インフラを支える技術」「大規模サービス技術入門」など
@ さん
ネットウォッチが高じてプログラマに。とにかくJavaScriptを高速化したい。ネイティブに負けたくない。CoffeeScript等のAltjsが好きで、最近だとLLVMEmscriptenに興味がある。

モチベーション

Web は絶えず変化しています。前回の CROSS2013 からも 1 年経って変わったところがいくつもあります。
この変化をキチンと把握し続けるのはなかなか難しいことです。

例えば「SPDY とは?」といった部分的話は割りとしやすいので、初心者向けの話は多くのイベントでされています。
(自分もよくお話させて頂いています。)

一方で、そうした初心者向けの話は、もう聞き飽きている人も多くいます。
しかし、初心者向けセッションの「その先」を扱うのは実は難しいのが現実です。


次世代 Web セッションは「その先」に挑戦したいと思っています。


「どこに向かっているのか」に答えを持っている人はいません。しかし、僕ら技術者はそこにコミットすることはできると思います。

「どこに向かっているのか」を考えるには、まず今「なにが起こっているか」をきちんと把握する事も必要です。


そこで自分は

  • 「何が起こっているのか」
  • 「どこに向かっているのか」

について、きちんと議論する場を作りたいと思い、その議論ができるであろう方々に声をかけさせて頂きました。

お断り

このセッションは、答えを出すセッションではありません。
答えが出せる、出ているような話は、わざわざここで議論する気はありません。


自分たちが「次世代の Web」を考える上で必要な知見を、常にそれを考えて戦っている方々との議論の中から見出そうというのがこのセッションの目的です。


参加するだけで答えが教えてもらえるという期待を持つ方は、このセッションには参加しないことをおすすめします。

扱わない内容

1 時間は、ちょっと真面目に議論すればあっという間に過ぎてしまう時間です。
その限られた時間の中で本来のテーマに集中するために、切り捨てる内容について書きます。

これは、自分が今回「あまり積極的に扱う必要がない」だろうと考えているものです。 といってもさじ加減なので、実際は登壇者の方々に委ねます。
しかし、参加者の方には「前提」として考えていただきたいと思っています。

初心者向け内容

例えば「SPDY とは何か?」「REST とは何か?」「IETF とは何か?」etc といった話には時間を割きません。
ある程度の知識は前提として、それを踏まえて先について話すことを重視します。
知識を得て Catch Up するためではなく、議論を通して Move Up するセッションにしたいという思いがあります。

過去の事

今回、テーマにはあえて「過去」を入れていません。 懐古するためのセッションとは考えていません。

  • 「何が起こっているのか」(現在)
  • 「どこに向かっているのか」(未来)

もちろん、古きを知ることは重要です。
過去の事例が引き合いに出ることもあると思いますが、過去を改めてから未来を語るには時間がたりません。
過去は基本的には共有された前提として考えて、「その先」にフォーカスして議論したいと考えています。

登壇者紹介

こうしたセッションで、自己紹介で大きく時間を浪費するセッションをよく見ます。
今回の登壇者のみなさんは著名な方が多く、このセッションを聞きに来る方は知っている人が多いと思います。
彼らの自己紹介に時間を割く気はありません、みなさん自己紹介を聞きに来るわけでもないでしょう。
なので、冒頭に自分がみなさんの名前を紹介する程度とさせて頂きます。


各登壇者の紹介は、このエントリや公式サイトのセッション概要から見ることもできますので。予め見ておいて頂けると良いと思います。

進め方

流れを決めすぎると予定調和になってしまうので、打ち合わせの段階でおおまかな方向性とキーワードのみを決めておき、
当日はそれについて基本的にはフリースタイルで議論を進めていきたいと思っています。


あまりズレて行くなら、途中で切るなどはしすまが、その場で起こる議論をなによりも大事にしたいです。

雰囲気については、去年の映像をご参照下さい。

まとめ

最後にもう一度。
このセッションは、 Web について

  • 「何が起こっているのか」
  • 「どこに向かっているのか」

に 1 時間フォーカスし続け、「その話はもう知ってるよ」とか、「何度も聞いたよ」みたいな話を無くして、少しでも議論の密度を高めたいです。
そのために参加者には「前提」を求める部分が多くなる点はありますが、限りある時間を有効に使うためにご理解ください。
これだけの方が揃ったセッションなので、変わりゆく Web の今後を考える上で、少しでも熱く有益な議論ができる場を作れればと考えています。


今年も去年同様、「最後は自分の頭で考えろ」(by @) で行きたいと思います。
このセッションで得たものをベースに、あなたが考える「次世代 Web」についてのエントリが読めることを、楽しみにしています。

Jxck

HPACK の Integer Representation の仕組み

intro

この内容は、 HPACK draft-03 を元に書かれています。
http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-03

将来のドラフトでは変わる可能性があるためバージョンにはご注意下さい。

(以下の内容は、自分がアルゴリズムから読み解いたものなので、間違ってたら教えて下さい。)

HPACK

HPACK のフレーム表現の中に、以下のような表記が出てくる。

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1 |        Index (7+)         |
+---+---------------------------+

この Index(7+) は、ここに数値が 7 bit もしくは、それに続く数 byte を用いて、
表現されていることを示している。

この表現は、 7 bit で収まる数値は 7bit で表現し
収まらない大きな数値は、後続の byte を必要なだけ用いて表現することで
任意の大きさの数値を表現できる仕組みになっている。

この Index(N+) の部分の表現を Integer Representation という。

Encode アルゴリズム

ドラフトを見ると、 Encode 方法として以下のアルゴリズムが示されている。

If I < 2^N - 1, encode I on N bits
Else
    encode 2^N - 1 on N bits
    I = I - (2^N - 1)
    While I >= 128
         Encode (I % 128 + 128) on 8 bits
         I = I / 128
    encode (I) on 8 bits

この通りやればエンコードできるのだが、最初は意図がよくわからなかった。
また、デコードの方法は記されてないので、 Decode するためには逆算するのだが、
その導出過程で仕組みを解いてみたら面白かったので紹介する。

以下 I が表現したい値、 N が Prefix (+N の部分) とする。

仕組み

ここでは、簡素化のために N=5 で固定する。

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| x   x   x |   Index (5+)      |
+-----------+-------------------+
I=10

まず、小さい数値 I=10 で導出過程を見てみる。
10 を表現するには 5 bit あれば十分である。
なぜなら N<2^5-1(31) よりも小さいから。

xxx0 1010

つまり 2^N - 1 より小さい値については、普通に 2 進数にすれば良いことがわかる。
(If I < 2^N - 1, encode I on N bits の部分)

I=3,000,000

I を大きめにしてみる。
(ドラフトのサンプルでは 1337 があるが、ターン数が少ないので、より大きな数字を選んだ)

まず、 N bit は使えるので、そこで表せる最も大きい値をそこで表すことにする。
2^N-1 = 2^5-1 = 31
つまり、 以下のようにすればとりあえず 31 は表せる。
(encode 2^N - 1 on N bits の部分)

xxx1 1111 (31)

そこで、元の I から表せた分だけ引いたものを算出すると。

3,000,000 - 31 = 2,999,969

この値は、後続の byte を用いて表す必要がある。
(I = I - (2^N - 1) の部分)

そこで、現在の値を 2 進数で表してみると。

0010 1101  1100 0110  1010 0001 (2,999,969)

全てが 8 bit には収まらないので、後続のバイト列で表現せざるをえない。
それをどう表現するか。

表現不足な例

下位から 8 bit ごとに区切っていけばいいと考えると。。

xxx1 1111
1010 0001
1100 0110
0010 1101

こうなる。
これで表現できた気もするが、問題がある。
それは、この後も別のバイト列が続いた場合に、
どこまでが I を表しているのかがわからないからだ。

終端を自己表現するために

I を表すのに何byte 使ったのかを別途持つ方法もあるが、
Integer Representation は、表現自身からどこまでが
I を表しているかわかるようにしている。

8bit ではなく、 7bit ごとに区切って、後続がある場合は
必ず先頭 bit を 1 にし、最後のバイトの場合は先頭 bit が
0 になるようにしているのである。

もう一度もとのバイト列

0010 1101  1100 0110  1010 0001 (2,999,969)
xxxx xxxx  xxxx xxxx  xooo oooo

下位 7bit を切り出して、8bit 目を 1 にして後続の 1byte とする。
現在の表現に加える。(o の部分)

xxx1 1111
1010 0001

I からはその分削る。
次は、以下になる。

0101 1011  1000 1101 (23,437)
xxxx xxxx  xooo oooo
xxx1 1111
1010 0001
1000 1101

同様に。

1011 0111 (183)
xooo oooo
xxx1 1111
1010 0001
1000 1101
1011 0111

で、最後は 1 になるが、これは そのまま 1 としてエンコードすれば良い。
結果は以下になる。

xxx1 1111
1010 0001
1000 1101
1011 0111
0000 0001

つまり、先頭ビットを 0 にしたまま表現できるサイズまで縮めば、
それを最後の byte とすることができる。
その値は最大で 127 である。

0111 1111 (127)

アルゴリズムで言うと

While I >= 128

この部分は、先頭ビットを 0 にしたまま表現できない値を意味している。
その間は、

Encode (I % 128 + 128) on 8 bits

128 は 2^7 であるので、 128 で割るのは、 7 bit 右シフトすることと等価である。
つまり、 128 で割ったあまりは、 7bit 右シフトしたら消えてしまう部分にあたるので、
(I % 128) は下位 7 bit をさす。
128 加えるのは、 1000 0000 を加えることなので 7bit の値に対して先頭 bit に 1 を加えることを意味する。

I = I / 128

これは、単純に今処理した 7bit を消すために 7bit 右シフトしていることと等化である。

これを繰り返し、 I < 127 (7bit で表現できる値) になったら

encode (I) on 8 bits

8 bit で表現するということは先頭がかならず 0 になるので、これを終端とみなせる。

デコード

結果をもう一度見てみよう。

xxx1 1111
1010 0001
1000 1101
1011 0111
0000 0001

この値を上から見た場合。

1, I=5 で、 5bit 読んだら全て 1 なので 5bit では表せず後続 byte を使っていることがわかる。

                        0001 1111

2, 次の byte を見ると、先頭が 1 なので、それを除いた 7 bit が最下位になり、まだ続くことがわかる
3, 最後の 0 で始まる byte が最後になり、そこまでをシフトしながら繋いで行けば良い。

これを図持すると以下のイメージに成る。

                        0010 0001
                0000 1101
        0011 0111
0000 0001
------------------------------------
        1011 0111000 1101010 0001 (2,999,969)

1 と 2-3 の結果を加える。

                  0001 1111        (31)
10 1101 1100 0110 1010 0001 (2,999,969)
---------------------------------------
10 1101 1100 0110 1100 0000 (3,000,000)

よって、デコードは上記を行うアルゴリズムを構築すれば良い。

#BPStudy72 で SPDY / HTTP2.0 / QUIC のお話をさせて頂きました。

intro

ちょっと遅くなってしまいましたが、 BPStudy#72 にて、 SPDY / HTTP2.0 / QUIC についてのお話をさせて頂きました。

BPStudy#72 - connpass

資料

発表資料です。


資料は以下です。今回は、とりあえず上記 3 つを全部突っ込もうということで盛りだくさんな感じになってしまいましたが、現時点での話は割りと網羅できた気がします。


盛り込んだバージョンは、 2013/8/28 時点のものなので、バージョンでは以下のような感じです。

  • HTTP/2.0 draft-06
  • HPAC draft-03
  • SPDY/3
  • QUIC (現状)


当日の朝に HPAC の仕様が新しくなったり、 devops-ML ができたりと動きがあり、行ってから直したりしました。
週末に作った資料が水曜には古くなっているという程度の動きの速さなので、今回の資料も賞味期限は早めだと思いますが、ご注意下さい。


BPStudy

BPStudy は今回でちょうど 6 年目だそうです。もうそんなにやっているんですね。
いわゆる勉強会ブームの初期か、その前くらいから開催されていて、自分も気になるトピックを見つけては、ちょくちょく参加して勉強させていただいていました。それが今回初めて登壇者として声をかけていただいたので、とても光栄です。


技術系の会社が、自分たちの技術をキチンとアップデートするために、こうした取り組みをするだけでも凄いのに、
それを定期的に続けてここまで来たというのは素晴らしいことだと思います。
それも、代表の佐藤さんが技術について真剣に向き合ってきたからなのでしょう。


今後も興味のあるテーマは是非参加させて頂きたいと思います。
これからも有益な勉強会を期待しております。
ありがとうございました。

HTTP2.0 勉強会を開催しました

Intro

HTTP2.0 は Draft-04 が出て、その実装を持ち寄っての相互接続試験を実施し、フィードバックを踏まえて Draft-05 が出るなど、割とチェックポイントな感じがあったので、一旦色々まとめたいなと思い勉強会を実施しました。

http2.0 勉強会 - connpass

発表資料

自分の発表資料はこちら。

前座的なポジションになったので HTTP2.0 のここまでと、現時点の実装を簡単に紹介して来ました。
あと、最近作ってた HTTP2Cat も紹介してきました。

他の方の資料も順次 connpass に上がる予定です。

HTTP2Cat

http://jxck.io/labs/http2cat

HTTP2.0 や SPDY の開発をすると tatsuhiro_t 先生のモジュール軍には必ずお世話になります。
で、その中に HTTP2.0 や SPDY の接続確認に使える nghttp, spdycat という CLI ツール(wget 的な) があります。

超絶便利なのですが、ビルドがちょっと面倒なところもあるので、 Web のフロントを作って見ました。(かなり突貫ですが。。)



結果を WebSocket で返すのに、 Nginx を使いたかったので SPDY/2 でホストしてます(nginx は spdy/3 が無い)。

使い方は nghttp, spdycat のドキュメントを見てもらえれば多分わかります(雑)

HTTP2.0 の薄い本

今回発表していただいた、 @flano_yuki さんが、コミケで HTTP2.0 の薄い本を出されました。

「learning HTTP 2.0」

かわいらしい表紙とあいまって、内容は凄く良くまとまっており、初心者向きな一冊です。
500 円でこれが読めるなら安いものでね。まだ在庫があるらしいので、欲しい方は @flano_yuki さんに言えばまだ手に入るかも。

今後

HTTP2.0 今が一番面白い時期ですね。今後もチェックポイントがあるごとに、こうして情報や成果を共有する場は作りたいと思っています。
ハッカソンとかもやりたいですね。

宣伝

8/27 の BPStudy でも SPDY/HTTP2/QUIC あたりでお話しさせていただきます。

BPStudy#72 - connpass

もう埋まっているようですが、よろしくお願いいたします。

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

intro

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


draft-ietf-httpbis-http2-00

が、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 などを用いた接続をすることができます。
この観点から、 DNSsrv レコードなどを用い、名前解決時に解決先のサーバの情報(対応するプロトコルなど)を送るという方法も提案されています。

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 自体がここまで大きく変わるのは、それらと比較してもやはりインパクトのある変化といえるでしょう。
この影響範囲の大きさは、このブログを読みに来た方ならお分かりかと思いますが、
特に技術者サイドから見ると、大きな影響のある変化になりえます。


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

注意

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


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