HTTP2.0勉強会( #http2study )が超おもしろかった話

SPDY Seriousが開催できなかったという経緯で開催された(?)HTTP/2.0勉強会

予習資料もdraftもほとんど見ないで参加したけど、おもしろかった。
最近参加した勉強会の中でも突出して、おもしろかった。本当に、おもしろかった。
ので、この気持ちを伝えるべくブログを書く。

Ustがなかったのでツイート頑張ろうと思ったけど、話に聴き入ってしまってそれどころでは無かった。
@sada_hさんが纏めてくれてるけどそもそも全体のツイート数が少ない。

1: HTTP/2.0 Guide (@Jxckさん)


講師は少し前のweb+dbでSPDYとHTTP/2.0の記事を書いた人だった。
WEB+DB PRESS Vol.75

WEB+DB PRESS Vol.75


執筆が終わった直後に次のdraftが出たらしく、仕様策定の激しさが伺える。
「そういえばSPDYもあるけどHTTP/2.0とかちあうんじゃね?」と思っていたんだけど、SPDYでのフィードバックをHTTP/2.0にフィードバックし、収束させていくというGoogleの意向ということで納得がいった。
というか、HTTP/2.0の始まりがSPDYのコピーだったらしい。びっくり!
SPDYは独自の進化を遂げる一方、標準としてのHTTP/2.0の策定が進んでおり、2014-15年位でHTTP/2.0へ収束させる予定らしい。
あと、GitHubで議論していて、プルリクを集めているというのも興味深かった。

現在HTTP/2.0はdraft 5。
バイナリフレームの名称・役割がSPDYとは異なっているらしい。
特徴は以下のとおり

  1. Streamベースの多重化: 例えばGETに対して、コンテンツを複数並行で返せる。コンテンツが多いなら効果的。
  2. HEADERS、DATAフレーム: フレーム単位で通信する。中身は圧縮される。フレームにはstream_idが付与されるが、0はTCPコネクションで予約されており、クライアントからは1以上の奇数がつくことになる。
  3. Server Push: PUSH_PROMISEフレームを用いる。コンテンツをブラウザにキャッシュしておき、ヒットしなかった時だけサーバに取りに行く。RTT減少が期待される。

nghttpというツールでHTTPのやりとりを見れるが、automakeとかの都合で見れない人向けにJxckさんがHTTP2CATというツールを作ってくれてた。親切!
High Performance Browser Networkingという書籍が詳しく解説しているようなので、読もう(執筆中で今は無料)

2: ヘッダ圧縮とネゴシエーションの話 (@flano_yukiさん)


先日のコミケでHTTP/2.0の薄い本を出された@flano_yukiさん。
新卒インフラエンジニアらしい。僕と歳近いのかな!すげー!!
件の薄い本がとてもわかりやすいので、入手をおすすめする。

HTTP1と2は互換性が無く、クライアント-サーバが同じバージョンを話す必要がある。
そのために用意されている機構がアップグレード。
最初にHTTP1で通信を開始し、使用可能ならUPGRADEヘッダを用いて2.0に変更する。
ただ、このあたりの仕組みでももめているらしい...

あとHTTPSだけど、TLSハンドシェイク中にネゴシエーション(NPN)したりして高速化が図られているみたい。
しかし後述するALPNともめており...

ヘッダ圧縮といったけど、zip的な圧縮ではなくハフマン符号化を指すらしい。
詳しいことはjoviさんが発表していた。

また、ヘッダをUTF8にするかでも揉めてるみたい。もめすぎだろ...
エンコーディングをどのように指定してどのように共有するのかで揉めてるようで、まぁ確かに悩むところかも。

3: httpbisってWGはこんな風にCrazyな場所なんですよ?(@lefさん)

HTTPbisという標準化団体の空気感の話。
技術的な話ではないが、一番おもしろかったかもしれない。

webを支える技術はwebで公開されている、ということは知っていたが、やはり会議に参加しなければ意思決定に関与できないみたい。
なので、HTTP/2.0に関わる人は世界各地で開催される会議に出張しまくっているらしい。大変だなぁ。

パソコンの話とはいえ決めているのは人なので、ドラマがたくさんあっておもしろい。"倍返しだ!"のドラマよりおもしろい。
例えばRC4(ストリーム暗号)が弱いのでもうやめようって話をしていた時。
代替案が採択される会議の直前で、その暗号化を破る報告をみんな絶望的な気持ちで聞いて、「どうするよ...」と大変だったらしい。
あと、各企業や個人の思惑があったりして会議が進まなかったり。

9/7にバーチャルintropあるのでもしかしたら日本でも何かやるかもらしい。

4: httpbis interim と相互接続試験の話(@jovi0608さん)


HTTP相互接続試験に行かれたjoviさん。
相互接続試験の話と、ヘッダ圧縮についての詳細な話がメインだった。

HTTP/2.0はバイナリプロトコルなわけだけど、これには賛否両論らしい。
確かにwiresharkとかで見難いし、否定の理由も分からなくはない。

策定に関わる企業の思惑の話もあって、そもそもヘッダ圧縮ってエンドユーザにはメリット無いけど巨人には死活問題だよねーとか、議長(Chair)所属企業の商売的に議論が偏っているかもとか、そんな感じ。
仕様策定に積極的なのは、「クライアントとサーバどちらも持っている企業」。納得がいく。オレオレプロトコルで直接的な利益あるっぽいし。
逆に言うと、「サーバだけ」「クライアントだけ」な企業は、策定には消極的らしい。どことは言わないがFとかAとか。
個人の開発者でも、先行者利益あるかもだし単純に面白いので興味あるならコミットしたい。
あとgithubでの仕様策定が盛り上がるらしいけど、本当はMLでやるべきみたい。

ヘッダ圧縮と呼んでいるが、その実態は差分のやりとりなので、ヘッダをパックするのでHPACと名前が変わった

  • ヘッダテーブル: 料理屋のメニュー。全部書いてる
  • リファレンスセット: アクティブなやつ。メニュー
  • ワーキングセット: 作業場。テンポラリ領域みたいな。クラサバそれぞれがヘッダ情報として扱う

という例えがとても分かりやすかった。

元々の仕様では、でかいヘッダが送られきてもアトミックに処理できず、逐次処理でデコードしなければならないので辛い、DOS的な攻撃が怖いという課題がある。
あとヘッダは4k超えた時に頭からシフトしていくとかまじかよ...ってなっているので解決に向かわせている。

ということでこれらの課題を解決してHPAC誕生!
ワーキングセット作らないし逐次処理対応 メモリ制限あり。
しかしクライアント-サーバどちらもが同じテーブルを持つことが前提。やりとりが回数多くなるとずれてしまうかも。
その時何がおこるかわからない→Interimでやってみよう!
ってことで先日の接続試験らしい。

バイナリのパースさえできればHello, World位はつくれるって言ってたので、

しかしそのバイナリのパースがわけわかめなんだな...

感想
超おもしろかったよ。
席ガラガラだったしもったいない。
DEFCON MTGといいHTTP/2.0といい、IIJで行われる勉強会はいつも最高だな!!

あとこれ。


今まではプロトコルとかは雲の上の存在で、プロトコルスタックマイコンのデータシートか、それに関連してI2Cくらいが関の山だったんだけど、一気に身近に感じられた。
やはり、第一人者が目の前で楽しそうに話していたからなんだと思う。

とはいえ自分で実装しないと多分理解できないと思うので、仕事が落ち着いたらErlangPerlか何かで実装してみたいものだ。

今後勉強会やハッカソンがあったらぜひ参加したいし、ドラフトを積極的に追えるかもしれないと思えた、最高の夜だった。

他参加者のブログ