http2.0勉強会に行ってきた
http2.0勉強会に行ってきた。面白かった。なんだかね、勉強会の雰囲気がよかった。人数が少なくて、ゆるくて、濃い。いいね。
tweetまとめた。
内容はこんな感じ。
- HTTP2.0 の基本的とこれまで @jxckさん
- ヘッダ圧縮とネゴシエーションの話 @flano_yukiさん
- httpbisってWGはこんな風にCrazyな場所なんですよ? @lefさん
- httpbis interim と相互接続試験の話 @jovi0608さん
予習資料。もともとはdraft04だったけど、下のリンクはdraft05にしちゃった。
- draft-ietf-httpbis-http2-05 - Hypertext Transfer Protocol version 2.0
- wg_materials/interim-13-08 at master · http2/wg_materials
いろんな方が blog 書いてる。勉強会エントリ、最近減ってる気がするので、なかなかすごいと思う。
- HTTP2.0 勉強会を開催しました - Block Rockin’ Codes
- HTTP2.0勉強会( #http2study )が超おもしろかった話 - After Coding
- http2.0 勉強会感想文 - ぽにくすじゃないブログ
HTTP2.0 の基本的とこれまで @jxck
@jxckさんが執筆された、WEB+DB Press Vol.75のSPDY & HTTP2.0特集を読んでいたので、ちょっとは話についていけたと思う。
SPDY特集はとてもわかりやすくて、日本語で解説を読めてうれしかった。このときのWEB+DB Pressはほんとうに自分にぴったりで、継続的Webサービス改善ガイドに共感し、SPDYに憧れた。
技術評論社
売り上げランキング: 5,932
WEB+DB PRESSのときは、たぶん draft03 なのかな。binary framesの内容が、draft-03からけっこう変わってるとのこと。
Server Pushのの説明がわかりやすくてよかった。ちゃんと理解できてなかったなーと思った。
nghttp2 と spdylay は準備するのが面倒で、試していなかった。@Jxckさんがこんな素敵なツールを作ってくださった。
nghttp や spdycat の結果がWebで見れる。こういうのが、Webから確認できる。オプションも選べる、Know Hostに有名所のURLが用意されてる。うれしい。
$ nghttp http://http2.iijplus.jp:8443/ -v -n
[ 0.237] NPN select next protocol: the remote server offers:
* HTTP-draft-04/2.0
NPN selected the protocol: HTTP-draft-04/2.0
[ 0.281] send SETTINGS frame <length=16, flags=0x00, stream_id=0>
(niv=2)
[4:100]
[7:65535]
[ 0.281] send HEADERS frame <length=65, flags=0x05, stream_id=1>
; END_STREAM | END_HEADERS
; Open new stream
:host: http2.iijplus.jp:8443
:method: GET
:path: /
:scheme: http
accept: */*
accept-encoding: gzip, deflate
user-agent: nghttp2/0.1.0-DEV
[ 0.323] recv SETTINGS frame <length=16, flags=0x00, stream_id=0>
(niv=2)
[4:100]
[7:65536]
[ 0.389] recv HEADERS frame <length=48, flags=0x04, stream_id=1>
; END_HEADERS
; First response header
:status: 200
content-length: 12
content-type: text/plain
date: Fri, 16 Aug 2013 00:11:05 GMT
[ 0.389] recv DATA frame (length=12, flags=1, stream_id=1)
; END_STREAM
[ 0.389] send GOAWAY frame <length=8, flags=0x00, stream_id=0>
(last_stream_id=0, error_code=NO_ERROR(0), opaque_data=)
このマニアックそうな本が、いまはEarly Releaseで Onlineで 無料で読めるとのこと。
ちらっと見てみたけど、楽しそうだけど難しそうな感じが…。これがHTTP2.0の章。
ヘッダ圧縮とネゴシエーションの話 @flano_yuki
プロトコルネゴシエーション。http や https でアクセスして、どうやって HTTP 2.0 や SPDY に切り替えるか、その方法についての内容だった。
@flano_yukiさんが以前書かれた、こちらのエントリが参考になる。
HTTPからの切り替えは、Upgradeヘッダを使って行われる。WebSocketも同じ。
HTTPSからの切り替えは TLS-NPN(Next Protocol Negotiation) と TLS-ALPN(Application Layer Protocol Negotiation) が議論されているそう。SPDYは NPN を使っている。
httpbisってWGはこんな風にCrazyな場所なんですよ? @lef
IETFの仕様策定の現場の話。全然知らないことばかりだったので、面白かった。
こちらの記事を書いている方が、@lefさんと同じ会社の方だった。
IETFの仕様策定の話からちょっと外れて、ヘッダ圧縮の話題に関連して CRIME Attack についてのことがでてきた。
CRIME Attack のことは聞いたことある程度で、ちゃんと調べたことがなかった。で、話を聞きながら調べてみると、これもまた面白い。
- CRIME - Google ドライブ
- Mike Belshe「SPDYの圧縮方式と攻撃ツールCRIMEの件」 - 以下斜め読んだ内容
- Adam Langley「CRIME attackの件」 - 以下斜め読んだ内容
- SSL/SPDYを攻撃するCRIMEはBEASTの正統な後継者だ - WAF Tech Blog | Scutum
- App Engine セキュリティー情報 - BREACH attack について - Google グループ
- BREACH ATTACK
この説明が端的でわかりやすかった。
SSLにおいて、圧縮機能は暗号化前のデータ中の文字列に重複部分があればそれを効率的に圧縮するように動作します。そのため、イヴが予測し、リクエストに埋め込んだ偽のCookieの値が、HTTPヘッダに含まれる本物のCookieの値と一致した場合にのみ、データの圧縮後のサイズが小さくなるわけです。イヴは様々な文字列を埋め込み、送信されるデータのサイズを確認します。サイズに変化があれば、「ビンゴ!」というわけです。
この攻撃手法は、とてもシンプルなアイディアに基づいている。いくつかの資料を読めば、僕でも理解できる。その盲点に気付き、実証するとこまで落としこむのがすごい。
ヘッダー圧縮ではハフマン符号を利用している。ハフマン符号はサイモン・シンの暗号解読に出てきた気がする。たしか。
全体を1つの符号木で変換していたから、CRIME Attackでは値を1つずつ変えることで圧縮率の変化を見て、値を特定していった。すごいね。
httpbis interim と相互接続試験の話 @jovi0608
相互接続試験の話、面白かった。プロトコルの実装をするってすごいな。protocol loversでは普通なんだろうけど。
そのほかいろいろ楽しい内容があったけど、うまく文章にできない。内容が濃かったので、それをうまく文章に落とし込めない。
ヘッダー圧縮の新しい方式のHPACについての内容も面白かったけど、こちらは文章にできるほど理解できてない。HPACについての資料もあがるとうれしいな。
まとめ
セッションの流れがよかった。@Jxckさんのセッションでは全体的な内容があって、@flano_yukiさんのセッションでヘッダ圧縮の話題があり、そこから@lefさんのセッションでヘッダ圧縮に関連して CRIME Attack の話があり、最後の@jovi0608さんのセッションでヘッダ圧縮について詳しい解説があった。合間に httpbis や相互接続試験の、実際の現場の話があって楽しかった。
こういうの、事前に打ち合わせしてそういう流れにしているんじゃなくて、勉強会のなかで楽しそうなトピックを掘り下げていったんだと思う。そういうライブ感、いいよね。
僕はフロントエンド、バックエンドに限らず、Webアプリケーションを作るのが好きで、そのために必要になる技術も好き。自分が使うかどうかは置いといて、どんな技術があるのか、必要なのか、使えるのか、そういうことを知りたい。
Webの高速化って、いまはフロントエンドによるところが大きい。基本的にはとにかくサイズを小さくする、リクエスト数を減らす。いまの高速化については、ここでけっこう書いた。もう一年前の記事だけど、まだまだ役に立つと思う。宣伝。
高速化の手法は、もうちょっとしたら、HTTP 2.0やSPDYによって大きく変わる。すでに変わり始めているし。そこでちゃんと対応できるようになっていたい。
高速化がプロトコルレベルでの対応になれば、パケット読むことになる。httpの実装は書いたことないけど、httpのリクエストとレスポンスは読む。同じように、プロトコルの実装を書いたりすることはないけど、そのプロトコルのパケットは読むことになる。だからある程度の知識は持っておきたい。
I want to Make the My Service Faster.