2015-12-01

HTTP/2 Push を Service Worker + Cache Aware Server Push で効率化したい話

intro

このエントリは、　http2 advent calendar の 1 日目です。

http2study の分かってる人にとっては、「casper の JS 版を作ってる」だけで伝わるかもしれませんが、そうでない場合非常に話すべきことがたくさん有る気がするので、順を追って説明します。

今回理解すべき内容は以下

http2 push の問題点
cache aware server push
bloom filter と golomb coded set
cache fingerprinting
dispenser.js

(最初は casper.js と言ってたけど、よく考えると被ってるのがあるので dispenser.js に変えました)

そして結論からいうと、まだまだ想定していた挙動まではいけませんでした。。

http2 push の問題点

http2 で push することで、リソースをブラウザにキャッシュしてキャッシュヒットさせる、というユースケースについてはもう散々語られたと思うので、それは前提とします。

問題は、例えば index.html へのリクエストで script.js を push する設定をした場合に、サーバは毎回 script.js を push しては無駄なわけです。もしすでに push 済みであれば、 push しないで index.html に対するレスポンスを返し、 script.js を速やかにリクエストさせてキャッシュヒットさせたい。

問題はつまりこういうことです。

ブラウザが何をキャッシュとして持っているか、サーバが知る方法が無い

ブラウザのキャッシュを取得できると、閲覧履歴などがわかってしまい問題となる可能性もあるため、基本的にこういうことをする API はありません。

cache aware server push

そこで kazuho さんは、 push 済みのリソースの情報を Cookie に付与しておくことで、次のリクエストで「index.html が欲しいけど scirpt.js はもうキャッシュに有るから push しないでいいよ」という情報をクライアントから取得するという方法を考えました。

これが Cache Aware Server Push という方式です。

では、実際 cookie には何の情報を入れればいいでしょうか？

例えば、 script.js を Push したら Cookie にも "script.js" って書けばいいかもしれません。しかし、それだとキャッシュされた script.js よりも、サーバが持っている script.js が新しく更新された場合に、「新しくなったから更新」ということができません。

それは、ファイルのバージョンを示すのに使われる Etag の値を一緒に載せればわかるでしょう。

/assets/scripts/script.js:zidr965q3jalsfda4

でもこれでは、ファイルパスや Etag が長くて、さらにファイルが何個もあったら、すぐに膨らんでしまいます。 Cookie は他にも多くの情報を入れるために使われるので、サブリソースが多くなりがちな昨今ではちょっと辛いです。

そこで、この情報をうまく圧縮する必要があります。

false positive

ファイルパスと Etag があれば十分ではありますが、本当に全部入れる必要はあるでしょうか？そもそも、ブラウザのキャッシュなんていつ消えるかわかりません。 Cookie がそれと完全に同期するのがそもそも無理です。

したがって 100% は無理なので、そこを狙う必要は無く、もし当てが外れても以下の二通りになります。

「キャッシュされてると思って Push しなかったら、されてなかった」=> ブラウザが普通に GET するだけ
「キャッシュされてないと思って Push したら、されてた」 => キャッシュが上書きされるだけ

つまり Push は読みが外れても動かなくなるものではありません。

しかし、かといって毎回 Push しまくってはせっかくのキャッシュで 0 RTT hit させられるのに無駄です。狙いは、「なるべく無駄な Push を減らす」ことです、すると本質的に必要な情報は以下になります。

「今から Push しようとしているファイルは、すでにキャッシュに 有りそうかどうか？ (あるとはいってない)」

100% でなくてもよい(あると思ったら無かった=false positive が許される)、となると実は情報を圧縮する方法がいくつかあります。その代表例が確率的データ構造である bloom fileter です。

bloom filter

bloom filter についてはこちら説明あたりがわかりやすいと思います。

簡単に言えば、その構造体の中に特定のデータが含まれているかどうかを検査を、元のデータセットより小さいサイズで実現できます。

具体的には k 個のハッシュ関数を用意し、要素をそのハッシュにかけます。そこ結果を、求めるデータサイズ m ビットで丸めると、 0~m の範囲の値が一要素につき k 個得られます。ゼロクリアした m bit の値に対し、それぞれの値の場所(3 なら 3bit 目)を 1 にします。全ての要素でこれを繰り返せば完成です。

ある要素がそこに入ってるかを検証するには、同じくハッシュを通してビットが立ってるかを調べます。

この場合、全部のビットが立ってなければ確実に無いことがわかります。しかし、全部のビットが立っていても、それが他の要素の計算による可能性があるわけです。これが "False Positive" = 「Positive(ある) と思ったら False(嘘) だった」です。

Bloom Filter は

要素数(ファイルの数) = n
ハッシュ関数の数(要素ごとに立つビットの数) = k
結果のビット数 = m

とすると

誤検出の確率 = (1 - e*p(-float(k * n) / m)) ** k
m = -n*ln(p) / (ln(2)^2)
k = m/n * ln(2)

の関係がわかっています。 HTTP のペイロードに載せることを考えれば、計算量よりもデータサイズが小さいことが望ましいため、許容できる誤検出を元に、これを最適化することができます。

ただし、計算量を追加することで、より論理的な限界までこれを圧縮するというのが Golomb Coded Set(GCS) です。

Golomb Coded Set(GCS)

Golomb-coded set は、ほぼここに書かれた通りなのでそれを元に紹介。

まずターゲットが以下の値(N=26)だとします。

['alpha', 'bravo', 'charlie', 'delta', 'echo', 'foxtrot',
 'golf', 'hotel', 'india', 'juliet', 'kilo', 'lima', 'mike',
 'november', 'oscar', 'papa', 'quebec', 'romeo', 'sierra',
 'tango', 'uniform', 'victor', 'whiskey', 'xray', 'yankee',
 'zulu']

これを P=64 (誤検出が64回に1回) になるようにします。

ハッシュ関数は、セキュリティ面で言われる危殆化が関係ないため、 MD5 や SHA1 などで構いません。求めた値が [0, N*P) = [0, 1664) に収まるように mod で丸め込むと、

[('alpha', 1017), ('bravo', 591), ('charlie', 1207)...]

このハッシュ部分だけをソートして

[151, 192, 208, ..., 1630]

このとき、ハッシュの質が良ければ、結果は [0, 1664) に一様分布するはずです。

そして、それぞれの値の間の距離をとると以下になります。

[151, 41, 16, 61, ...]

26 個の値を 26*64 の間に分布させたので、距離の平均は 64 になるはずです。つまり、この距離の配列の中には、 多くの 64 近い値 と、少しの 64 と遠い値 があるはずです。 (実際、 64 との差の絶対値をプロットするとわかる)

Golomb Coded Set は、この性質を利用して、配列を圧縮します。

まず、この配列の各値を 64 で割ると、多くの商は 0, 1, 2 あたりになります。(最悪 25 だがそれはハッシュ関数を見直した方が良い)

で、その商を Unary Encoding(商の数だけ 0 の前に 1 をつける) します。具体的には、こうです。

商   Unary encoding
 0   0
 1   10
 2   110
 3   1110
 4   11110
 5   111110
 6   1111110

これに余り(0~63) をそのまま 6bit バイナリとして加えると、

距離  商  余   Golomb encoding
151    2  23      110 010111
 41    0  41        0 101001
 16    0  16        0 010000
 61    0  61        0 111101
192    3   0     1110 000000
 51    0  51        0 110011
.
.

結果の長さは、

0~63 は 0+6bit で 7bit
64~127 は 10+6bit で 8bit
128~191 は 110+6bit で 9bit

なので、 64 に近い値が多いという前提であれば、これで多くの値が小さくエンコードできることがわかります。

結果を全部つなげると完成です。

11001011 10101001 00100000 11110111 10000000 0110011...

元に戻すには 0 がくるまで 1 を並べ、その後固定長(ここでは 6bit) とって逆算すれば、順番にハッシュが取得できます。

これが基本的なアイデア。

cache aware server push と casper cookie

で、 kazuho さんはこれを使って push 済みのファイル(Path+Etag)情報を圧縮し、 Cookie につけてクライアントに送る。クライアントから来る Cookie の情報から Push するかしないかを判断するという方法を、 h2o に実装しました。

その Cookie を casper cookie と言います。

現在 h2o のデモページではその Cookie が付与されています。

で、 kazuho さんがこの方法を 10月の #http2study httpbis ガチ勢の前でデモした結果大好評となり、「これは Cookie より別途ヘッダがあった方がいい」「ドラフト書け」みたいな話になって kazuho さんが書いたドラフトが以下です。

Cache fingerprinting for HTTP

cache fingerprinting

Cache Fingerprinting では、以下の二つのヘッダが定義されています。

Cache-Fingerprint-Key
Cache-FIngerprint

Cache-Fingerprint-Key

この値が、各ファイルごとのハッシュ値になります。 casper cookie の頃は、 Path+Etag の sha1 hash でしたが、この値を別のロジックで出すことで最適化できる可能性もあるため、仕様上この値の導出は明記されていません。実装依存です。

値が uint32 (0~2³²) までとだけ定義されています。

Cache-Fingerprint Header Field

クライアントはキャッシュしたレスポンスの fingerprint key を集め、 Golombset でエンコードした結果を Cache-Fingerprint ヘッダで送ることで、サーバにキャッシュしているファイルを伝えることができます。

リクエストヘッダなので、通常はブラウザが実装することが想定されます。

(注意: このブログを書いてる最中に、フレームが良いということになって、ドラフトは http2 に拡張フレームを定義しています)

dispenser.js

やっと本題です。

ブラウザが実装するまでは、このヘッダは使えないので、 h2o は Cookie にも fingerprint を吐いていますが、 Cookie はブラウザキャッシュとは同期させられません。

そこで、 Service Worker がブラウザキャッシュの代わりに Cache API でキャッシュを管理し Fingerprint を計算、リクエストを Proxy しヘッダに追加して行けば、より正確にキャッシュの管理ができ、無駄な Push を減らせるということで作ったのが dispenser.js です。

動作

基本の流れはこうです。

最初のリクエストでサーバは全てのサブリソースを Push する
Service Worker を登録する
次のリクエストは SW で interapt する
SW は fetch を発行し、それがブラウザキャッシュヒットする
取得したレスポンスを Cache API で保存し、返す
それ以降のリクエストは、 Cache に無いものだけ、キャッシュしたレスポンスのヘッダから fingerprint を計算してヘッダに足す

これにより、 SW で発行した fetch がブラウザキャッシュにヒットしたときに Cache API に移され、ブラウザキャッシュを JS で管理している状態に近づけます。また、サーバにキャッシュの情報を正確に伝えることで、無駄な Push を減らすことができます。

実装

ここです。(あとで色々整理します。。)

https://github.com/Jxck/dispenser.js

知見

ということで作って検証していたのですが、色々と課題が出てしまいました。。

SW 内の fetch はブラウザキャッシュヒットしない

これ、すると思ってたのですが、現状していません。これでは Push したリソースを fetch でキャッシュヒットさせて SW 内の Cache に引き込むことができません。大前提が。。

今後 Push API が http2 push を受けられるようになったりすればまた少し変わりますが、もしかしたらフロントの fetch でキャッシュヒットさせて SW に送り込むとかしないといけないかもしれません。

それもまだ未検証です。

Chrome Canary だと onfetch でフックした Request を引数に new Request すると怒られる

Stable ではできているのですが、 Canary だと怒られます。つまりそのうち使えなくなる可能性が。ブラウザからのリクエストを雑に複製するのは簡単なのですが、このスクリプトが casper 対応サーバで無条件にホストして良いレベルの汎用スクリプトにするためには、複製した Request はオリジナルと限りなく近い必要があります。

そもそもなんで動かなくなったのか？(仕様変更か実装の話か) などもう少し調べる必要があります。

https://localhost 開発問題

http2 なので開発も https でやっています。オレオレ証明書で https://localhost を許可するわけですが、この場合 invalid cert なので、 SW の register がエラーになります。

現状これを回避する方法は、全ての証明書エラーを無視するという、ちょっとデンジャラスな起動オプションを使う必要があります。有効にした場合、開発中に同じブラウザでググるみたいなのが総じて危険になるため、本当はより正しいやり方があるのですが、その正しいやり方の方が Chrome のバグで動きません。

デンジャラスな方が広まると良く無いのでここには書きません。

バグは issue を上げてあるので、直ったら追記したり呟いたりします。

Chrome ではリロードとナビゲートでキャッシュの扱いが違う

@kinu さんに教えてもらったのですが

リロード(CTL+R) では、ブラウザキャッシュは無視して必ずサーバにリクエスト
ナビゲート(CTL+L Enter) は、ブラウザキャッシュがあればキャッシュヒット

なので、この開発中は CTL+R で更新してたので、非常にハマりました。

https://twitter.com/kinu/status/669432544178380806

Push されたことを確実に知る方法

cache hit すると DevTools の NetWork タブで from cache みたいな感じで出ますが、より正確に知るためには chrome://net-internal で http2 のセッションを見るしか無いようです。

例えば index.html が 1.css, 2.css を含み、 CSS は PUSH している場合以下のようになります(抜粋) 1.css, 2.css は PUSH_PROMISE で送られていて、二つに対する SEND_HEADERS が書かれてなければ、キャッシュヒットしています。

t=1386045 [st=    0]    HTTP2_SESSION_SEND_HEADERS
                        --> fin = true
                        --> :authority: 127.0.0.1:3000
                            :method: GET
                            :path: /main.html
                            :scheme: https
                        --> priority = 0
                        --> stream_id = 1
                        --> unidirectional = false
t=1386045 [st=    0]    HTTP2_SESSION_RECV_PUSH_PROMISE
                        --> :authority: 127.0.0.1:3000
                            :method: GET
                            :path: /1.css
                            :scheme: https
                        --> id = 1
                        --> promised_stream_id = 2
t=1386045 [st=    0]    HTTP2_SESSION_RECV_HEADERS
                        --> fin = false
                        --> :status: 200
                            accept-ranges: bytes
                            cache-fingerprint-key: 7351
                            content-length: 23
                            content-type: text/css
                            etag: "5643ea29-17"
                            last-modified: Thu, 12 Nov 2015 01:23:53 GMT
                            server: h2o/1.6.0-beta1
                            x-http2-push: pushed
                        --> stream_id = 2
t=1386045 [st=    0]    HTTP2_SESSION_RECV_PUSH_PROMISE
                        --> :authority: 127.0.0.1:3000
                            :method: GET
                            :path: /2.css
                            :scheme: https
                        --> id = 1
                        --> promised_stream_id = 4
t=1386045 [st=    0]    HTTP2_SESSION_RECV_HEADERS
                        --> fin = false
                        --> :status: 200
                            accept-ranges: bytes
                            cache-fingerprint-key: 4710
                            content-length: 27
                            content-type: text/css
                            etag: "5654b166-1b"
                            last-modified: Tue, 24 Nov 2015 18:50:14 GMT
                            server: h2o/1.6.0-beta1
                            x-http2-push: pushed
                        --> stream_id = 4
t=1386046 [st=    1]    HTTP2_SESSION_RECV_HEADERS
                        --> fin = false
                        --> :status: 200
                            accept-ranges: bytes
                            content-length: 7774
                            content-type: text/html
                            etag: "565e3110-1e5e"
                            last-modified: Tue, 01 Dec 2015 23:45:20 GMT
                            link: </1.css>; rel=preload</2.css>; rel=preload
                            server: h2o/1.6.0-beta1
                            set-cookie: [64 bytes were stripped]
                        --> stream_id = 1
t=1396049 [st=10004]    HTTP2_SESSION_GOAWAY
                        --> active_streams = 1
                        --> last_accepted_stream_id = 1
                        --> status = 0
                        --> unclaimed_streams = 1

これを見やすくするツールが一応あるようです。

https://github.com/rmurphey/chrome-http2-log-parser

Chrome には表示を追加する issue があるようです。

https://code.google.com/p/chromium/issues/detail?id=464501

まとめ

本当は「作りました！」で効果測定の結果などを書きたかったですが、そこまで行けませんでした。

HTTP2 Push も Service Worker もまだまだ研究の余地が一杯あるなということで、地道に頑張ります。

Jxck

2015-05-15

HTTP2 の RFC7540 が公開されました

http2 RFC7540

Intro

今朝、ついにずっと策定作業が行われていた HTTP/1.1 の後継仕様である HTTP2 と、関連仕様である HPACK が、 RFC として公開されました。

ついに HTTP2 RFC 7540 出た！！ #http2study / “rfc7540.txt” http://t.co/CuaVul98l3
— Jxck (@Jxck_) 2015, 5月 14

それぞれ番号は 7540 と 7541 になります。

ちなみに HTTP/2.0 ではなく HTTP/2 が正式名称です。(マイナーバージョンアップでの HTTP/2.1 などはありません)

二年半

HTTP2 の前進である SPDY のコピーとして始まったのが 2012年11月28日。このブログで最初のドラフトを紹介したのは 2012年12月でした。

次世代規格 HTTP2.0 のファーストドラフト公開 - Block Rockin’ Codes

もうそれから二年半くらい経つのですね。。あっと言う間でした。そっから #http2Study という勉強会を主催したり、ブログも結構書きましたね。

自分で実装してみたりもしました、仕様を網羅するには全然足りてませんが。これが Go を始めるきっかけでしたね。

けっこう色々やったなぁ。

HTTP2 本当に RFC になったんだなぁ。始まった頃は本当に RFC になるかなんて半信半疑だった、正直言うと。
— Jxck (@Jxck_) 2015, 5月 14

http2study

日本にはかなりのガチ勢が集まっており、結果として日本のコミュニティの貢献は RFC の最後に以下の一文を載せていただくまでになりました。

The Japanese HTTP/2 community provided invaluable contributions,
including a number of implementations as well as numerous technical
and editorial contributions.

本当に嬉しいですね。

これから

HTTP2 の RFC 化は終わった訳ですが、これは HTTP2 にとってはむしろ「やっと始まった」ということです。これから、実際に HTTP2 を使う上でまだまだ足りてないものは沢山有ります。

HTTP/1.1 からの移行
パフォーマンスチューニング
セキュリティ
負荷分散構成
実運用ノウハウ
gRPC のような使い方
etc

(先日あった Push に関する議論も、実際にデプロイして検証していく必要がありますし。)

http2study も、 HTTP2 の「仕様を議論する」という最初のフェーズを終えて、第二フェーズとしてこれから「どうやって使っていくか」という話や、デプロイ・運用ノウハウの共有などに移っていければと思っています。

このへんは実に一ヶ月早く世界に先駆けて勝手に実施した RFC 発行祝賀会でも話しました。

HTTP2 RFC 発行記念祝賀会 from Jxck :)

www.slideshare.net

もちろん、 WebSocket over HTTP2 や HTTP/3 の議論が始まれば、それも追って行きたいと思います。

Outro

HTTP2 各位、本当にお疲れさまでした。ここまでの 2 年半本当に楽しかったし、勉強になりました。

これからもコレを使いこなす/使い切るために、色々議論していきましょう！

2015-05-11

HTTP2 時代のサーバサイドアーキテクチャ考察

http2

update

色々と twitter で議論が起こったのでまとめて貼っておきます。

<a href="http://togetter.com/li/820433">HTTP2 時代のサーバサイドアーキテクチャフィードバック</a>togetter.com

みなさんありがとうございました。

intro

HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。

そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。

前提

今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。

また、本エントリ内では独自に以下の表記を採用します。

HTTP/1.1 = HTTP/1.1 (平文)
HTTP/2 = HTTP/2 (平文)
HTTPS/1.1 = HTTP/1.1 over TLS
HTTPS/2 = HTTP/2 over TLS

HTTPS/1.1 での構成

まず、ベースとして HTTPS/1.1 でコンテンツ配信をしていた場合のサーバ構成を復習します。小さななサービスであれば別ですが、ある程度のサービスであれば前段に Nginx などのサーバを Reverse Proxy として立て、その後ろにアプリケーションサーバの層がある構成が標準的でしょう。なお、 Proxy よりも後ろはデータセンタ内の高速なネットワークを想定します。

この場合 Proxy の層は以下のような責務を担います。

TLS の終端
IP ベースのフィルタリング
コンテンツの gzip 圧縮
ヘッダの追加/削除
静的ファイルの配信(ELB のようにしない場合もある)
etc

重要なのは、 URL が https: なリクエストが来た場合、クライアントから Proxy までは HTTPS/1.1 ですが、 Proxy とアプリケーションサーバは HTTP/1.1 で通信する点です。

C --- https/1.1 ---> P --- http/1.1 ---> S

HTTPS/2 での構成

最近では Proxy のポジションは Nginx が多いと思いますが、まだ HTTP/2 には対応していません。 HTTP2 に対応するには H2O や nghttp2 などがありますが、やはり Nginx と比べると実装の枯れ具合の部分もあるし、すでに Nginx 使ってればそのまま行きたいという気持ちも有ります。

Nginx は 2015 年中には HTTP2 を実装するというロードマップがあり、そこでは、 Nginx が nghttp2 の proxy 実装である nghttpx 相当の機能を実装するであろうと予想されるので、今回は、先取りして Nginx にその辺の機能が実装された前提で考えます。

また HTTP2 の場合は、現在のブラウザの実装状況がこのまま続くと考えると、おのずとクライアントとの間は HTTPS/2 が前提になっていくでしょう。したがって、サービスは全体的に HTTPS/2 になっていくと予想されます。

その場合も、これまで同様 TLS の終端は Nginx で行うことになるでしょう。

C --- https/2 ---> N --- ??? ---> S

では、そこからアプリケーションサーバの間をどうするのか。

大まかに二つが考えられます。

HTTP/1.1 で中継

Nginx で TLS と HTTP/2 を両方解き、 HTTP/1.1 にしてしまうという考え方です。

C --- https/2 ---> N --- http/1.1 ---> S

この方式は、既存のアプリケーションに手を入れる必要が無く、新規に作るとしても言語自体が HTTP2 の実装を持っている必要がありません。 HTTP2 の持つネットワーク上の最適化は Nginx の層で実施することでインターネット側で発揮され、高速なデータセンタ内では、従来と互換という移行しやすい方式かと思います。

HTTP/1.1 にしてしまうと、例えばサーバプッシュといった新しい機能が使えないように思えるかもしれませんが、 resouce hints という仕様を使うと、 Link ヘッダというヘッダを追加することでプッシュしたいリソースを Proxy に知らせることができます。

例えばアプリが index.html のレスポンスの前に style.css を Push して欲しい場合は index.html のレスポンスヘッダに以下のヘッダを入れます。

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Link: /style.css; rel=preload
...

すると Proxy は style.css を探して Push してくれるというものです。

この機能はすでに nghttpx や h2o には実装されているため、 Nginx にも実装されることが期待できます。

HTTP/2 で中継

Nginx では TLS だけ解き、 HTTP/2 で中継するという考え方です。

C --- https/2 ---> N --- http/2 ---> S

この方式は、アプリケーションの層が HTTP/2 の平文実装に対応する必要があります。データセンタ内であるため HTTP/2 のメリットはネットワーク最適化というよりは、サーバプッシュなどをよりアグレッシブにアプリケーションサーバから使いたい場合に取る戦略かと思います。

前述の HTTP/1.1 に解いた場合は、 Nginx に Push を伝える方法が Link ヘッダに限られてしまいます。この場合、例えば時間のかかるリクエストの処理をしているが、結果がどうなろうと(status code が決まる前に)先に Push しておきたいコンテンツがあると言った場合に対応できません。 (Nginx にはレスポンスヘッダで伝えないといけないが、 status code が決まらないとそもそもレスポンスを作れないから)

アプリが直接 HTTP/2 を話せると、アプリから直接コンテンツを Push できるインタフェースを叩ける可能性があるので、よりアグレッシブなプッシュができるでしょう。

また、 gRPC など HTTP/2 の機能をよりふんだんに使った構成を考える場合も、こちらを選ぶことになると思います。

HTTPS/2 で中継？

ところが、 HTTP/2 はもともとおまけのような扱いで始まってしまったきらいがあり、若干軽視されている感があります。特に言語での実装はどのくらいこなれて行くのか若干不安があります。

すると素直に HTTPS/2 のまま通せば良いのでは？という発想もあるかもしれませんが、あまり現実的とは思えません。

TLS の終端をしないと、アプリごとの証明書管理が必要になったり、アプリ側で OpenSSL のバージョンがバラけていたりした場合は、バグが出た時に対応が難しくなるなどの運用面での懸念があります。

なによりデータセンタ内ではセキュリティは IPSec や MACSec などによる対応が考えられるため、 TLS が必須ではないでしょう。

まとめ

結論として以下のようになるのかなと考えます。

互換性を重視し Resouce Hints レベルで Push する: http/1.1 Forward
積極的に Push する: http/2 Forward

こう考えると、当初「HTTP/2 を HTTPS だけにしない」という理由から付け加えられたような HTTP/2 の平文仕様でしたが、実は結構大事だったことに今更ながら気がついたということです。

特にブラウザはほとんど HTTPS/2 しか実装してないし、する気もなさそうですが、サーバサイドや Proxy を作るような場合は、これの変更考慮して HTTP2 の平文実装もぜひ無視しないであげてください。

また、特に今回書いたような中~大(not 超大)規模くらいのサービスを運用されている方々からのコメントをお待ちしています。

2014-12-24

#HTTP2Study の軌跡

http2study http2 http2conf

Intro

この記事は HTTP2 アドベントカレンダー 24 日目の記事です。

HTTP2Study

HTTP2 Study は、2013年8月くらいから小さく小さく活動しているコミュニティです。

HTTP2 もまだ HTTP2.0 と呼ばれていた頃で、 Draft でいうと 04 くらいですね(今は 16)。

(ちなみに、現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です。)

仕様を策定してる HTTPbis としての議論は概ね片付いて、 HTTP2 の仕様は RFC にするための次のステップに移り、もし仕様を覆すような大きな指摘が無ければ、来年の頭にはこのまま RFC として公開されるかもしれないというところまで来ました。

そして今日はこの仕様策定をずっと追いかけてきた HTTP2Study がやってきたことを、簡単にまとめてみます。

きっかけ

この業界であれば HTTP/1.1 を普通にみんな使ってるわけですね。そして keep-alive や pipelining といった仕様に対して、意見というか文句がある人は結構いて、思うに任せて呟いたりしていた人もよく見ていました。

まあ、 RFC 2000 番台で公開された仕様で、リアルワールドでがっつりデプロイされている仕様なので、そう簡単には変えられません。仕方ないのはわかります。

そして最近になって、その隣で WebSocket のような仕様が策定される様を自分は見ていました。仕様は結構ドラスティックに変わって、結果 RFC として公開されました。でもやっぱり、仕様に文句言う人が結構沢山いるんですよね。まあわかります。フレームが複雑な気は確かにします。でもそれは意味があって議論した結果できたことで。。

というか、ついこの間まで仕様策定してたんだから、意見があるなら策定中に言えば反映されたかもなぁ、と薄々思っていました。

SPDY が出た時も文句がある人が結構いました。 HTTPS 前提とかバイナリフレームとか色々気に食わなかったんでしょう。でもこれは一企業の独自プロトコルなのでまあしょうがない。

でも、これが HTTP の次の仕様として策定されるドラフトの土台になって、標準化が始まりました。

この大きな変化の中で、仕様の策定段階から仕様を読んだり、実装を進めたり、集まって自分たちなりに議論したりすれば、この仕様策定に少しは「関与」することがもっとできるのではないか？

RFC 出てから文句を言うのではなく、議論の段階でそこに参加することで、今まで結果に対して受け身でしか無かった「標準仕様」というものに対して、もう少し積極的に関われるんじゃないかと思い、そういう場所を作ってみようという思いがありました。

単に参加者の前でスライドを読んで終わる発表会や、 LT 大会よりも、実装とか議論を意識的に重視してきたのはその意味もあります。

嘘です、 Web が変わって行く様が見たかっただけです。

実装

HTTP2 を実装するのが一つの目的なので、主要な人はだいたい実装を持っています。

主な実装は以下の Wiki にまとめられているんですが、この中で 5 つ、ここに載ってないものでも 2,3 個が日本から出ています。

http2 implementation

言語で言うと、 C, Go, Node.js, Ruby, Haskell etc と言う感じで多岐に渡っています。

中でも @tatsuhiro_t さんが実装する nghttp2 は、世界で最も素早く仕様に追随し、ほぼ全ての機能を実装して、あらゆるところで使われている神実装です。功績は書ききれない。

httpbis のチェアである Mark Nottingham にも「nghttp2 は参照実装(reference implementation) だ」とお墨付きをもらっています。

こんな凄い開発者が日本人だったから HTTP2Study はできたという面は、正直かなりでかいです。

勉強会

小さく小さくやってきました。ただかなり濃かったと思います。

日々仕様は変わって行くので、まずは仕様策定が進む大事な会議である IETF の会議に参加したメンバーに、その参加報告をしてもらっています。主に @mad_p さんや @jovi0608 さんにやって頂きました。

海外渡航とか長期滞在はそう簡単にはできませんので、この報告は非常に助かってます。 (今年は、自分も IETF89 に参加する機会があったのでやらせていただきました。)

各自が実装してみた知見の共有も結構やりました、ただ発表会じゃなくてそこから議論が始まるくらいには近い距離感を意識したので、時間内に終わったことはあまりないし、それができるように発表は少なくしてきたのも良かったと思います。

他にも、 HTTP2 の性質上色々なレイヤに話が及ぶので、そうした話に詳しい方もお呼びして話して頂きました。

たとえば Canon の藤沢さんに HPACK の原型になった EXI圧縮の話をお願いしたり、 @hirano_y_aa さんに、議論中の WebSocket over HTTP2 の話をお願いしたり、 @kaname さんに、ネットワークインフラ(プロバイダ寄り)からみた HTTP2 のお話をお願いしたり。

ここでしか聞けな話は多かったと思います。

hack-a-thon

実装者も多いのでハッカソンも何回かやりました。

このタイミングで、後述するテストケースが生まれたりもしましたね。これらは、 HTTP2 を実装する上であるとうれしいものだし、 HTTPbis の ML では同じようなものをやるやる詐欺してる人も多かったけど、実際にちゃんと作りました。後者は @kazu_yamamoto さんが作ってくれたものをもとに今作業中です。

成果物も多くなったので、 http://http2.info/ を作ってまとめる作業もやりました。(ロゴも含めて @summerwind さんがデザインしてくれました)

また、初心者も実装に参加できるように、膨らんだ HTTP2 の仕様を削りに削って最小の Hello World を実装できるようにするハンズオン。「HTTP2 最速実装」シリーズも作りました。これはやるたびに仕様が変わるので、持ち回りで最新の仕様にアップデートしたもんをやっています。 (v0 は wiki に俺が書いたのがはじまりなんだけど、さすがに古いのでこれはアップデートしないとだ。。)

そして、毎回会場を貸していただいてる @y_iwanaga_ さんには本当に感謝です。いつも色々手配して頂いて本当にありがとうございます！

issue-thon

HTTP2 の仕様は github で管理されているので、そこにあがっている issue を読んできて、みんなで議論するという回をためしにやってみました。

目標としては、 issue を眺めるだけじゃなくて、それを理解して議論してコメントを書くことで、議論に参加しようというもの。

といっても理解するだけでも結構大変なので、俺はコメントするようなところまで行けませんでしたが、かなり高度な議論になり、会自体はすごく勉強になりました。

これも少人数だったのがよかったのかも。

またやりたいと思うのですが、 HTTP2 の issue は基本片付いた(だから RFC に向けて進んでる)ので、まあ直近は無いかもれませんが、似たような構成を別の形でやりたいですね。

(ちなみに、 @mad_p さんが今年の IETF でコミュニティの話を発表したときは、海外勢には issue-thon が一番食いつきよかったようです。)

HTTP2 Conference

色々なタイミングが重なったので、今年は HTTP2 のカンファレンスを開催しました。まあ世界初のカンファレンスというと聞こえがいいですが、単純に RFC も出てない仕様のカンファレンスという意味では気が早かっただけですかねw

ゲストとして、 High Performance Browser Networking の著者でもある Ilya Grigorik に来日してもらって、キーノートをお願いしました。

そして、この少し前に h2o を実装した @kazuho さんも交えて、トークセッションをやらせてもらいました。

全体的に濃くて良いカンファレンスになったと思います。

ドラフトに ACK が載った

そんなこんなで色々やっている間に、ドラフトにこのコミュニティがやってきた活動に対して謝辞が載りました。

http://tools.ietf.org/html/draft-ietf-httpbis-http2-16

The Japanese HTTP/2 community provided an invaluable contribution,
including a number of implementations, plus numerous technical and
editorial contributions.

日本の HTTTP/2 コミュニティは、多くの実装に加え、
様々な技術的および編集上の修正など、多大な貢献をしてくれました

http://http2.github.io/ のページのトップにも、 HTTP/2 JP のページへのリンクがいつの間にか載っていました。

多分世界的に見ても、ここまで盛り上がっている地域コミュニティは多分まだないので、「どこぞの島国にクレイジーな奴らがいる」くらいの印象なんだろうとは思いますが、まあこうして認知してもらえる程度には貢献できたのかなと思います。

今後

直近では、ハッカソンを年明けにやります。これは Interop といって、それぞれが実装を持ち寄って相互接続試験をやるという内容です。

今回は最速実装のような初心者向けコンテンツも用意しない(interop に集中するため)ので、初心者向けではありません。

あとは、とりあえず RFC が出るのを楽しみにするフェーズですね。出たらちょっとしたお祝いでもやれたらなと思っています。 HTTP2 も RFC になる前に大どんでん返しがあって、振り出しに戻る可能性だってありますが。

他は、正直まだ考えていません。来年の今頃は #quicstudy になってるかもw

ふりかえって

コミュニティとしての成果だけでなく、そこにいる人々の個別の成果も含めれば、ここに書いたのはほんの一部です。そして実際、自分個人としてはまあ大したことはしてません。日程を決めて場所を取ってコンパスに登録したくらいです。

ただ、幸運にも凄い人たちが集まって、そこから得られるものは凄く多かったし、なによりもこうやって、議論や実装を重視する場ができたのが自分としては良かったなと思います。

そうした人たちに色々教えてもらったおかげで、自分の実装もかろうじて動くくらいまではきました。

本当にこのコミュニティは勉強になります。凄い場所だなといつも思います。

今後どうなるかはわかりませんが、とりあえず次の interop に向けて各自冬休みがんばりましょう！！

2014-10-14

HTTP2 のカンファレンスを開催します。 #http2conf

http2 http2study http2conf

11/3 に HTTP2 のカンファレンスを開催します。

HTTP2Conference

2012年8月に、 SPDY/3 の仕様をベースとしてスタートした HTTP2.0 は、その正式名称を HTTP2 と変えながら議論を重ね、執筆時点で Draft-14 まで仕様の策定が進みました。

現在は、この Draft をベースに Chrome, FireFox, IE といった主要ブラウザベンダや、 Google, Facebook, Twitter といったパイパージャイアントと呼ばれる大規模サービス、そして、その他仕様に関心のある世界中のエンジニア達によって実装され、検証され、フィードバックされています。

HTTP2 を策定するワーキンググループである IETF の HTTPbis では、 ML を介して今も活発な議論が行われ、その議論の結果は RFC に向けた次なるステップである WGLC(ワーキンググループ・ラストコール) という形にまとめようというフェーズにあります。

要するに HTTP2 の仕様の大枠は見えており、世界中の Web で実用可能な仕様まで詳細を詰めながら形にしていくという、最も重要な時期であるといえます。

このタイミングで、ここまでの http2 を振り返り今後を考える一つの機会として、把握している限りでは世界初の HTTP2 をテーマとしたカンファレンスを開催することになりました。

HTTP2Conference

スケジュールは以下です。

11:00-12:00	受付(受付票を提示下さい)
12:00-12:25	オープニング by @jxck
12:30-13:30	基調講演 by @igrigorik (英語/通訳無し)
13:30-13:45	休憩
13:45-14:45	HTTP2 最速実装*1 by @summerwind
14:45-15:00	休憩
15:00-15:30	h2o by @kazuho
15:30-16:00	nghttp2 by @tatsuhiro_t
16:00-16:30	QUIC by @jovi0608
16:30-16:45	休憩
16:45-17:45	トークセッション*2(英語/通訳無し) by @igrigorik, @kazuho, @tatsuhiro_t, @jovi0608
17:45-18:00	クロージング*3

セッションのキーノートでは、 Google の Web Performance エンジニアかつ Developer Advocate であり、High Performance Browser Networking の著者でもある Ilya Grigorik を招待してトークをお願いします。

次に「HTTP2 最速実装」ですが、これは新しく HTTP2 に興味をもった人が、手を動かすとっかかりとなる題材として http2study のメンバーで持ち回りで行っているハンズオンです。一言で言えば以下のような内容です。

複雑な HTTP2 の仕様の中で、
一番簡単に Hello World レベルまでを実装するための、
最小限の仕様とそれを用いた実装方法の解説

もともと wiki から始まったものですが、これまで 3 回(v1, v2, v3) 実施してきました。

今回は、 HTTP2 仕様の日本語訳を行っている @summerwind さんが担当として、最新のドラフトでの最速実装をライブコーディングを混ぜながらやっていただく予定です。 HTTP2 をこれから始める方も、仕様の理解を深めるとっかかりとなるコンテンツです。

他には、 - ISUCON 周辺でも話題になった @kazuho さんによる h2o のトーク - 世界を代表する HTTP2 の実装である @tatsuhiro_t さんによる nghttp2 のトーク - そしてどこよりも早い @jovi0608 さんによる QUIC のトークなどをお願いしています。

また、トークセッションでは、 Ilya 含めた登壇者達による HTTP2 の現在と今後についてのトークを実施予定です。かなりガチな内容となるでしょう。

HTTP2 (ないしは SPDY や QUIC) に興味がある方々、これから始める方も、すでに HPBN などで知識を得ている方、または実装に着手している方、様々な方々が得るもののあるカンファレンスとなると思うので、是非参加してみてください。

また、これを期に開催の母体となっている #http2study のこれまでの活動を簡単にまとめてみたいと思います。

http2study の活動

日本では元々 SPDY に関心があったメンバーを中心として、2013年8月に最初の勉強会 #http2study を開催しました。

HTTP2 の実装は、ブラウザベンダ以外にも多くの開発者によって行われており、自己申告ではありますが以下の Wiki にまとめられています。 (開発途中も含みますが)

http2 implementation

現時点で 26 の実装が掲載されていますが、この中には世界的に有名な、事実上のリファレンス実装となっている nghttp2 を含め 5 つの実装が日本から出ています。(ここにないものも 2,3 は確認しています)

そのほとんどの日本人開発者が参加する #http2study では以下のような活動をしてきました。

IETF 報告会
HTTP2 最速実装ハンズオン
hpack-test-case
仕様翻訳(ほぼ @summerwind さんによるもの)
仕様に関する議論/実装で得られた知見の共有

IETF 報告会

IETF で定期的に行われる会議は HTTP2 の仕様がまさしく改訂されて行く現場ですが、海外で実施されるため簡単には行けません。そこで、参加者に結果を報告会として共有してもらって、みんなで進捗を把握します。

実際には IETF とは別途行われる httpbis の interim というミーティングの内容や、 interop という相互接続テストの結果なども参加者に共有してもらってきました。

(ちなみに、次回 11/9~14 で行われる IETF の報告会は、 11/27 に予定しています。)

HTTP2 最速実装

高度な議論になりがちな勉強会ですが、新しく HTTP2 に興味をもった人たちにとっては敷居が高すぎるため、 http2study では「HTTP2 最速実装」というハンズオンを定期的に行っています。

最速実装とは簡単にいうとこうです。

「複雑な HTTP2 の仕様の中で、一番簡単に Hello World レベルまでを実装するための、最小限の仕様とそれを用いた実装方法の解説」

最初は自分が書いた wiki で始まったのですが、そこから担当を替え、 @mad_p さん、 @y_iwanaga_ さん、 @syu_cream さんが、その時の最新実装でアップデートしながら続けてきました。

これを見ると、ドラフトのどことどこを見れば、一番簡単な実装が完成するのかを把握し、手を動かすための第一歩となるでしょう。

hpack-test-case

HPACK という仕様の実装のために、テストケースがあったらはかどるだろうと始まったのが、 hpack-test-case です。

hpack-test-case

ここでは、各自の実装でエンコードしたデータを登録し、それを他の実装がデコードすることで、 interop (相互接続テスト) を行うためのテストケース群です。仕様書にあるサンプルだけではカバーしきれないケースもあぶり出し、なにより自分の実装が一定水準を満たしていることが確認できるため非常に有用です。

現在、 HTTP2 のフレームを対象にしたテスケースも同様に作成するために、メンバーで作業中です。また、相互テストの自動化を検討しているメンバーもいます。

仕様翻訳

HTTP2 のドラフトと HTTP2 のリポジトリにある FAQ については @summerwind さんによる日本語訳が公開されています。

素晴らしいことに Draft については Draft-04 から改訂ごとにアップデートされており、最新のものに追従されています。

また、初見で理解するのはなかなか難しい仕様の理解を深めるために、議論も活発に行われています。実装するなかで得られた知見は、そのまま HTTP2 の仕様に反映されたものもあります。

仕様に関する議論/実装で得られた知見の共有

仕様について深く理解するためのディスカッションもよくおこります。HTTP2 の Github リポジトリにある issue や ML であがっているトピックを議論するための issue-thon を開催したこともありました。

特に仕様に熟知した @tatsuhiro_t さんや、標準化に深く関わる @jovi0608 さんがいるため、仕様についての質問をすることができるのも非常に恵まれた環境です。 @kazu_yamamoto さんが共有してくれた、実装を用いたベンチマークは、実際に仕様の変更につながる結果となりました。

前に立つ人だけが発信する一方向なイベントスタイルにとどまらず、個々がどんどん発言する結果、結構ガチな議論が行われる、そんなスタイルで #http2study は活動してきました。拙作ですが、 @tatsuhiro_t さんと @jovi0608 さんには、 #mozaicfm の http2 の回にも出ていただきました。

ここまでを振り返って

なかなかガチというか、実際自分でも着いて行けてないことが多い、ハイレベルはコミュニティだと思います。 (一方でこの密度の勉強会を維持できたのは結構凄いと思ってます)

このコミュニティの活動はそれなりの結果が出ていると思うし、自分はその一部を今年の 3月に IETF89 で発表させてもらったりもしました。

その http2study の活動と HTTP2 という仕様自体の、一つのチェックポイントとして、このカンファレンスを通じて HTTP2 への関心と正しい理解が広がればと思います。

Jxck

2014-03-09

IETF89 で #http2study の話をしてきました。

ietf http2 http2study

Intro

2014/3/2 ~ 3/7 にイギリスのロンドンで実施された IETF89 に参加し、HTTP2 について議論している httpbis というワーキンググループで、日本での HTTP2.0 に関する Local Activity (コミュニティ活動とその成果)について発表してきました。

IETF

IETF は、ネットに関わる「Wire より上、Application より下」のレイヤの標準仕様などを決める標準化団体です。 IETF には、さらに目的に特化した WG(Working Group) に分かれており、最近自分が取り組んでいる HTTP2 はこの IETF の中の httpbis という WG で議論されています。

今回色々な方の助けもあり、幸運が重なって、初めて IETF に参加することができました。

とりあえず旅行記的に書いてみます。

-2日目(出発)

日本での土曜の早朝の便なので自宅からは始発でもキツイ、ということで前日終電で羽田に入り、空港で一晩明かすことにしました。結構人がいる静かな空港のカフェで、ひたすらスライドとコードを書きます。

編集後記 pic.twitter.com/ZbMJ0fUQea
— Jxck (@Jxck_) 2014, 3月 9

飛行機に乗ったら離陸と同時に爆睡。 12 時間のうち 10 時間は寝て、 2 時間は "Kick Ass 2" を見てるうちに到着。起きた時はイギリスの 8:00 くらいだったので、時差ボケ一切なく英国入りするという狙いは完全に成功しました。

-1日目(入国)

FB には書きましたが、「個人が趣味で IETF に参加する」というシチュエーション自体が怪しまれたのか、税関を通るのに苦労するという罠を何とか突破しホテルへ。

飛行場から Heathrow Connect (8.5ポンド)で行くつもりが、間違えて Express (21ボンド) を買ってしまい宿へ。快適でした(泣。

ヒースローからロンドン中心までの電車からの風景、完全に Star Guitar の PV である。 pic.twitter.com/4TnofbmxkV
— Jxck (@Jxck_) 2014, 3月 1

宿は会場から 2 駅離れた Baker Street 付近。普通のホテル。

checked in pic.twitter.com/EEa5biaxmU
— Jxck (@Jxck_) 2014, 3月 1

近くにはでかい公園とかシャーロック・ホームズミュージアムとかあったけど、ほとんど観光せず。先に現地入りした方と合流。 IETF 大先輩な方々と、トルコ料理を頂きました。

0日目(New Commers Session)

IETF 開始の前日にあたるこの日は、参加受け付けをし、初心者向けのセッションへ。

New Commer は、受付で赤いリボンをもらうことができ、このリボンをつけている限りはみんなが優しく接してくれるそうです。

このリボンが身を守ってくれるらしい。 pic.twitter.com/VP5bAjo7sr
— Jxck (@Jxck_) 2014, 3月 2

そして、 New Commers Session に参加。 IETF がどういう団体で、どういうプロセスで標準仕様を決めているのか、などなど細かいところまで教えてもらえます。(資料はまだ上がってないみたい) これ、凄い勉強になったし、噂の hum デビューしました。

(IETF では Rough Consensus を取るときに、挙手させるのではなく hum (ハミング) で大体の賛否を取ります。要するに「hu~~~~」って感じでハミングして、だれが何に賛同しているかを見た目ではわかりにくくしている。)

IETF での Rough Consensus の説明で初 hum (ハミング) を決めた。
— Jxck (@Jxck_) 2014, 3月 2

その後 Orientation で IETF な方々や他の参加者と交流。意外と日本人が多い、特に大学生が多い。

ここで、今回参加しないと聞いていた WebSocket over HTTP2 の仕様作者さんが急遽参加していたことを知り、一緒に御飯を食べることに。

1日目(httpbis#1)

httpbis の一回目のミーティング。このミーティングの最初の方が、自分達が話すターン。

今回の httpbis は、 Google の Hasan というピンクを着こなすオシャレガイにより、「スーツに Bowtie」というドレスコードが発行されていました。実際、全員ではないけど Chair の Mark や Google の Martine, Will Chan などなど数人がスーツで出席。

俺は、 @nunnun と一緒にスーツで登壇。

httpbisで @Jxck_ と @nunnun が発表してたの図！ Good! #ietf89j #http2study pic.twitter.com/oy0ih5DLpM
— lef/HAYASHI, Tatsuya (@lef) 2014, 3月 3

まず自分が #http2study などで行っている日本の Local Activity や、その成果としての hpack-test-case について話し、最後に @nunnun が 4 月に書く予定の I-D (Infomational Draft) について話しました。

今日 IETF で話してきたスライドです。 #http2study / “slides-89-httpbis-2.pdf” http://t.co/Hcnt6Wxebl
— Jxck (@Jxck_) 2014, 3月 3

その後は、 Github の issue を Open Mic で話しながらみんなで閉じるという、 IETF の歴史からいうと結構先進的なワークフローで議論が進みました。

注目していた WebSocket over HTTP2 の話はあまり出ず。 hum をする機会はありませんでした。

ひと通り WG が終わったら、最後に全体向けのプレナリセッションがあり、今話題の Bitcoin の話とかあったのですが、その寸前に httpbis 議長の Mark が、地元の勉強会に出るらしいことを聞きつけ、自分だけそっちに行きました。

I'm attending London Web Standards - How does HTTP/2 sound? (#lwshttp), 3rd March 2014 in London http://t.co/9WL1sbBuiL
— Jxck (@Jxck_) 2014, 3月 3

Mark のセッションは俺にとってはそんなに新しいことはなかったけど、会場からはかなり質の良い質問が沢山でていて、勉強会としては非常に良かったと思います。(電源が無いことは別として)

会場はキレイな大学のような場所？ pic.twitter.com/8UmqkhrjgV
— Jxck (@Jxck_) 2014, 3月 3

向こうのミートアップのオーガナイザと、勉強会運営的な話したけど、結論から言うと「ピザ+ビールはグローバル」。
— Jxck (@Jxck_) 2014, 3月 3

日本(の Otaku 文化)大好きなナターシャと、カウボーイ・ビバップや図書館戦争の話をしたりしながら、ひと通り飲んで帰宅。

ロンドンのパブでイギリス人と「カウボーイ・ビバップ」や「図書館戦争」の話ししながら飲んできた。
— Jxck (@Jxck_) 2014, 3月 3

2日目(social)

イギリスに来たら必ずやる「イングリッシュ・ブレックファースト」で朝食。

@bad_at_math どや！！ pic.twitter.com/Ilsuewt4CZ
— Jxck (@Jxck_) 2014, 3月 4

好きである。ちなみに紅茶派。

この日は特にミッションも無かったので、 WebRTC とか見ていたけど、席も後ろで殆ど見えず、ついていけなかったのでこのブログをひたすら書く内職。

夜は Social Event ということで会場から 30 分の博物館を貸しきってイベント。

もともとは、造船所だったっぽい。イギリスの歴史についての展示がメインでした。

編集後記2(ソーシャルイベントでの博物館) pic.twitter.com/a0PCuNQS7G
— Jxck (@Jxck_) 2014, 3月 9

楽しかったけど、腹ペコなのにフードが圧倒的に不足していて、割りと空腹なまま宿に帰って寝る。

3日目(httpbis#2)

httpbis の二日目。

初日同様に github の issue を片付けていく感じ。メインだったのは Priority Leveling と、 TLS のネゴシエーション周り。

終わり際に少し Mark に話をしたけど、「続きは土曜に」ということで断念。 (土曜は London の Mozilla で非公式の httpbis meeting がある。俺は出れない)

その後何人かで、 1日目に日本のアニメ話をした Natasha にパイの美味しいお店に連れてってもらい、たらふく食べる。

編集後記3(ナターシャ達と行ったパイの店) pic.twitter.com/bhWucxWg4j
— Jxck (@Jxck_) 2014, 3月 9

夜のロンドンをちょっと観光案内してもらいつつ解散して宿に帰り、この記事を書く。また、徹夜で電車に乗り空港へ。

4日目(帰国)

朝の 5 時にチェックアウト。

100ポンド持って行った残りが、空港についてスタバで一杯飲んだ時点で 3 ポンド強の使い道を探るなどする。(空港でお土産を買えば、小銭全部＋残りはカードみたいなのが出来たらしい。)

安眠確保のために、奮発してプレミアム・エコノミーに上げたけど、「あれだけ追加払ってもこんなものか。。」という程度だった印象。そうこうするうちに着陸。

そのまま空港で IETF での発表時に着た、およそ社員が会社に着ていくとは思えないドレス・スーツに着替えて出社。何事もなかったように日常にジョインしてターンエンド。

感想

やっぱりまだまだ英語力、特にリスニング力が足りないなぁと。

議論の内容が聞き取れないと自分がどんなにその技術や議題を理解していても、参加できないという現実。

以前 US で NodeConf に参加した時も同じことを思って、自分なりに色々訓練したつもりだったけど、まだまだダメでした。

この状況はもっと何とかする必要がありますね。

あと、標準化の世界は自分にとってはかなり未知で、その世界の仕組みについては標準化 Guy である @lef さんとか @nunnun さんに色々教えてもらえたのが幸運だった。

みんなミッションを持って来るので、俺のような趣味の延長で来たような人間がウロウロするのはあまり良いことでは無いのかもしれないけど、 @nunnun さんの計らいで、たった 5 分でも日本のアクティビティーを世界に発信するという能動的な参加ができたのは、幸運だったし自分にとってはいい経験だったと思う。

この世界の人々は、「3月で予算が余ったから来たんですよテヘペロ」と口では言っておきながら、「コードを書く」という俺らが得意とする分野のもう一層隣にある、「標準化する」というレイヤから世界を良くしようという、熱意と正義感で貢献している人が集まっていて、とても良い刺激が得られました。

2015年11月には、 IETF が日本の横浜で開催されることが決定しているので、興味のある方は是非参加してみるといいと思います。

終わりに

肝心の HTTP2 の議論と動向については、次回の #http2study で報告します。

今回の旅で知り合うことができた、 WebSocket over HTTP2 のドラフト筆者である @hirano_y_aa さんと、ネットワーク・インフラのエキスパートである @kaname さんにも登壇をお願いしたので、かなり熱い話が聞けると思います。

ちなみに次の #http2study は IETF のまとめ、ドラフト作者による WebSocket over HTTP2、インフラ屋さん視点で HTTP2 はどうなのかといった内容です。結構濃いですよ。 http://t.co/jE9TScNcyf
— Jxck (@Jxck_) 2014, 3月 8

最後に、ずっとお世話になりっぱなしだった @lef さん、 @nunnun さん、 @mad_p さん。本当にありがとうございました。

Jxck

2012-12-30

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

cross http2 spdy websocket

update

2013/1/13: 終了したので録画やログを追加

intro

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

次世代 Web セッション

今日はこのセッションの内容と、このセッションで自分がやりたいと思っていることについて書こうと思います。

Theme

このセッションは「次世代 Web セッション」というタイトルとし、主にいま起こっている Web の変化(リアルタイム Web, HTTP2.0 の登場など)について、

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

を、

「プロトコル編」(1h)
「アーキテクチャ編」(1h)

の 2 つのセッションに分けて議論したいと思っています。
(枠自体は「次世代 Web セッション」の 1 つですが、内容的には 2 つのセッションからなります)

Motivation

HTTP, CGI, Ajax, HTML5 etc と、 Web には今までもいろいろな変化がありました。そして今また、 Web が大きく変わりつつあると感じています。

この変化をキチンと把握するのはなかなか難しいです。

例えば「WebSocket とは？」といった部分的話は割りとしやすいので、初心者向けの話は多くのイベントでされています。一方で、そうした初心者向けの話は、もう聞き飽きている人も多くいます。しかし、初心者向けセッションの「その先」を扱うのは実は結構難しいのが現実です。

今回の CROSS では各 1 時間という時間をつかって、初心者向けセッションで語られない「その先」に挑戦したいと思っています。

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

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

そこで自分は

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

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

「プロトコル編」(14:00-15:00)

今起こっている変化の主流には、プロトコルレベルで Web を見直すという取り組みが大きく関わっていると考えます。

そこでは様々なステークホルダが参加しているので、議論される問題は Web の現状を浮き彫りにし、非常に興味深いものがあります。

プロトコル編では、主に Web のプロトコル自体の変化(WebSocket, SPDY, WebRTC, HTTP2.0 etc)について、低レイヤで何が起こり、どこに向かっているかを議論したいと考えています。

登壇者

小松さん(@komasshu)
大津さん(@jovi0608)
清水さん(@kazubu)

「アーキテクチャ編」(15:15-16:15)

プロトコルが変わると、アーキテクチャが前提としていた制約が変わります。すると、自ずとアーキテクチャも見直す必要が出てきます。

また、プロトコル以外にも、サービスに求められる要件の変化によっても、アーキテクチャは変化しています。

「アーキテクチャ編」では、そうしたプロトコルの変化、時代の要求の変化により、Web のアーキテクチャがどうなっていくだろうかという点について、議論したいと考えています。
キーワードとしては REST や MVC、リアルタイム、リアクティブ、バイナリベース/テキストベースなどを考えています。ただ、キーワードはあくまで議論の呼び水であり、議論の主軸は「何が起こり、どこに向かっているのか」です。

登壇者

山本さん (@yohei)
江島さん (@kenn)
佐々木さん (@yssk22)

扱わない内容

今回は、各セッションが 1 時間しかありません。これは、ちょっと真面目に議論すればあっという間に過ぎてしまうと思います。
その限られた時間の中でとにかくテーマに集中するために、いくつか切り捨てる内容について書きたいと思います。

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

初心者向け内容

難しいところですが、例えば「WebSocket とは何か？」「REST とは何か？」「IETF とは何か？」etc といった話は要らないと思っています。
知識を得て Catch Up するためではなく、議論を通して Keep Up するセッションにしたいという思いがあります。

過去の事

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

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

もちろん、古きを知ることは重要です。 Web の歴史、HTTP の歴史 etc 引き合いに出るでしょう。
しかし、過去を改めてから未来を語るには時間がたりません。過去は基本的には共有された前提として考えて、それらを踏まえた「その先」を中心に議論したいと考えています。

登壇者紹介

特に自己紹介で大きく時間を使ってしまうセッションが多いです。
今回の登壇者のみなさんは著名な方が多く、このセッションを聞きに来る方は知っている人が多いと思うので、冒頭に自分がみなさんの名前を紹介する程度とさせて頂きます。

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

進め方

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

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

最後に

今のWeb について

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

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

CROSS には、このセッション以外にも興味深いセッションが多数あります。
現在エンジニアや、それに関わることを何かしらをしていれば、気になるセッションがきっと一つはあると思います。
なにとぞよろしくお願い致します。

本番終了後ログ

無事本番を終えました。
自分としては、上記に望んでいたセッションができたので満足しています。

以下が録画です。

(前半) プロトコル編

(後半) アーキテクチャ編

スライド

Next generation web talk @cross2013 from Jxck :)

最後の yohei さんの一言「あとは自分の頭で考えろ」が何よりのまとめです。
そして、それを考えるに足るだけのエッセンスはほぼ出てきました、
来ていただいたみなさんにとっても、これからの Web を考えるきっかけになったなら、よかったと思います。

今回のセッションを作るにあたっては、(最終的には登壇もして頂いたんですがw) t_wada さんに色々な面でアドバイスを頂きました。
こうしたセッションを作るには自分はまだまだ力不足だったので、非常に心強かったです。

そして、このセッションのために非常に豪華な登壇者の方に集まって頂きました。
みなさん忙しい中自分のわがままに付き合って頂いて、本当に感謝しております。

最後に muddy さんを始め運営のみなさん、このような機会を頂き本当にありがとうございました。

Jxck