HTTP Workshop 2016参加報告

これは[第9回HTTP/2勉強会](http://http2study.connpass.com/event/39210/)の資料です。

スウェーデンの首都、ストックホルムで開催された第二回[HTTP Workshop](https://httpworkshop.github.io/)への出張報告である。

- このイベントはワークショップ形式であり、HTTPについての議論をする場
- 非常にラフなアジェンダのみ用意されており、スケジュールは頻繁に変更される
- [Twitter公式アカウント](https://twitter.com/http_workshop)でも情報が発信されている 
- [レポート](https://github.com/HTTPWorkshop/workshop2016/wiki/Report)がすでに公開されており、参加者も記載されている

# 場所、日時

- 2016/7/25から7/27の3日間
- スウェーデンのストックホルム
- シェラトンホテル会議室

# 日程、議題

## Welcome Drink

0日目レポート: https://daniel.haxx.se/blog/2016/07/24/http-workshop-2016-day-1/

Gamla StanのThe Bishop's ArmsでCloudFlare主催の :beers: を飲む会。

## 1日目

1日目レポート: https://daniel.haxx.se/blog/2016/07/25/a-workshop-monday/

### The state of HTTP by Mark Nottingham, Akamai

https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/state.pdf

これはキーノート的なもので、現在のHTTPコミュニティで議論している事柄の総まとめ。

### h2 checkpoint by Patrick, Mozilla

発表資料: https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/http2-review-data.pdf

Mozillaが[Firefox Telemetry](https://telemetry.mozilla.org/)で集めたHTTP/2に関するメトリクスの紹介。

h2は全トランザクションのうち、31%を占める。HTTPSの中では、44%。
HTTPS自体は、55%から72%へ増加した。

去年の夏は HTTP/2:SPDY は 1:1 だったが今年はもう 20:1 になっている。

NPNは昨年20%、今年はまだ10%。

RTTについて、今までは中央値を低くしようと色々と対策をしてきて効果はあるが、ロングテールの部分を削減することが困難である。このような対策をする場合は、効果が何%の人々に影響を与えているのかを常に考えるべきである。

h2では、6以上の並行ストリームを使っているのは20%であった。

HPACKでリクエストヘッダーは中央値で90%削減。80パーセンタイル(th)で75%、90thで10%。リクエストサイズの中央値は85バイト。レスポンスヘッダーサイズは、リクエストのそれよりも42%少ない。

Firefoxではサーバープッシュの利用はほとんど観測されておらず、全体の0%。

ALT-SVCはほとんどデプロイされていない。ALT-SVCの5%はOE (opportunistic encryption)。

h2 priorityの話では、webパフォーマンス(e.g., page load time)に影響するからとても重要だが、現在のクライアント、サーバーの実装状況は良くない。

### Server Push by Vlad Krasnov, Cloudflare 

発表資料: https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/server-push.pdf

CloudFlareのサーバープッシュ機能は、Linkヘッダーを使用したものでページあたり最大50プッシュまで可能。プッシュにはデバッグ用のHTTPヘッダー cf-h2-pushed が付与されるので、それで識別できる。

47%のプッシュアセットはブラウザからのRST_STREAMによりキャンセルされている。プッシュされたものの、使われていないケースもあるかもしれないとのこと。

CloudFlare全体で25%以上がTLS。TLSのうちの24%がHTTP/2、9%がSPDY、残りはHTTP/1.1。

PUSH_PROMISEに入れるべきヘッダーは何か(RFCには最低限必要なもの以外は特に指定なし)。

### Cache Digest by Kazuho Oku, DeNA

発表資料: https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/cache-digests.pdf

Kazuhoさんの[Cache Digest](https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-00)の話。

Cache Digestとは、クライアントがキャッシュしているリソースをサーバーに知らせる仕組みで、サーバーをその情報をもとにプッシュするかしないかを判断できる。

Cache Digestを送るために接続毎にブラウザがキャッシュをオリジン毎に全部確かめるコストは?

Cache DigestはGolumb-Rice符号を使っている。これはブルームフィルターに比べてサイズを小さくできるが、計算コストが高い。

### Mozilla主催の夕食会

:wine_glass: 

## 2日目

2日目レポート: https://daniel.haxx.se/blog/2016/07/27/workshop-day-two/

### About h2 performance by Moritz Steiner, Akamai

AkamaiでのHTTP/2でのパフォーマンス検証の話。

### TCP tuning for HTTP by Daniel Stenberg, Mozilla

資料: https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/TCP.pdf

HTTPを使うにあたり推奨されるTCPのチューニング方法をまとめた[仕様](https://tools.ietf.org/html/draft-stenberg-httpbis-tcp-02)の話。

### QUIC by Jana Iyengar, Google

資料: https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/quic.pdf

"Call it TCP/2, One more time." とのことで、TCP/2 と呼ぶのはやめましょう。

低遅延でのコネクション確立や複数ストリーム、効率のよい再送アルゴリズムなどがQUICの目指すところ。

Googleではすでに、Chrome、Google モバイルアプリ、Google+が対応済みで、Youtubeも対応作業中。

GoogleとChrome間のリクエストの85%がQUICに移行済み。移行していないリクエストは、PCIコンプライアンスに対応する都合でドメイン単位でオプトアウトされていたりするケース。

UDPがブロックされていたり、MTUが小さすぎるとHTTP/2にフォールバックする。管理者設定で明示的に無効化することもできる。

quicをHTTP/3にするかどうかの議論では、HTTPのセマンティクスとトランスポートへのマッピングを分けて考えるべきだという意見があった。現在のh2はHTTPをTCPへのマッピング、quicはHTTPをUDPへのマッピング。未だ世界はh2へ移行できていない中、我々だけがどんどん先に進みすぎるのは良くない、程よいペースが望ましい。

### LT

#### Programming TCP to avoid head-of-line blocking

資料: https://github.com/HTTPWorkshop/workshop2016/blob/master/talks/tcpprog.pdf

kazuho さんの TCP 送信バッファを意識した実装に関する話。

#### Head-of-line blocking in QUIC

HTTP/2でHoLが起きないようにがんばったがQUICでもHoLが起きる部分がある。HPACK、SETTINGS ネゴシエーションなど、同期が必要なポイントがいくつかあるという話。

#### WebSockets -- What's up with that? 

HTTP/2でWebSocketどうしようか、といった話。

ブラウザの Fetch API が Stream をサポートするので、WebSocket の代替として使えるかもしれない、という話が出ていた。

[Streams](https://streams.spec.whatwg.org/)も代替候補だよ、という意見があった。

#### Open multiple connections for each ip in a DNS reply

DNS への問い合わせで複数のエントリーがあったら全てに接続して一番レイテンシが速いやつを使おう、という話。

Happy Eyeball に対して Happiest Eyeball という言葉も出ていた。

### HTTP Ideas

資料: https://github.com/HTTPWorkshop/workshop2016/wiki/Future-of-HTTP

去年のHTTP Workshopで出ていたHTTPの将来で何やりたい？という話をみんなで再構築。

H2Q (HTTP/2 over QUIC)、HTTP/3、SciFi、HTTP/2 拡張、HTTP/*.* 拡張の5つの項目に分割。

### Fetch

資料: https://annevankesteren.nl/presentations/fetch/#fetch

ブラウザに実装されているFetch APIの話。ブラウザにおける非同期リクエストのプリミティブな仕様。

FetchでTrailersは扱えるのか、という質問が出ていた。Fetch APIとしてTrailersを扱うためのPromiseを返すかどうかといった議論。gRPCはTrailersを使用しており、そういったプロトコルを扱うには必要になる。

## 3日目

3日目レポート: https://daniel.haxx.se/blog/2016/07/27/a-third-day-of-deep-http-inspection/

### Retry safety extension by Subodh Iyengar, Facebook

HTTP のリトライは難しく、リトライ用の拡張は必要かという話が出ていた。

MLでのこのトピックの初出は https://www.ietf.org/mail-archive/web/httpbisa/current/msg26861.html だと記憶している。

現在のところ、HTTPにおいて、リクエストを送信したが、何らかの理由で、レスポンスが得られなかった場合に、クライアントがリクエストを再送するかどうかは、リクエストメソッドの[冪等](https://ja.wikipedia.org/wiki/%E5%86%AA%E7%AD%89)性に依っている。

GET、PUT、DELETEなどは冪等だが、POSTは冪等ではない。

しかしながら、本当にリトライが可能かどうかはリクエストメソッドではなくてアプリケーション依存である。JavascriptでPOSTをリトライしたいユースケースがある。

若干話がずれるが、TLS 1.3 0-RTTでは、アプリケーションデータを最初のパケットに入れることができるが、攻撃者がこれをキャプチャーして、サーバーに送りつけることが可能である。有効な攻撃としては、キャプチャーした1パケットを1000回サーバーに送りつけるなどである。これに関しては、パケットが有効な期間を設けるためにタイムスタンプをつける、といった議論があった。MLでもその話題が出ている。

HTTPではクライアントとオリジンサーバーの間にプロキシーがある場合があり、その場合、どこでリトライするのかという議論があった。end-to-endでリトライすればいいのでは、という意見もあった。中間装置でリトライすると、時間がかかる可能性がある。

mnotのリトライに関する調査のようなもの: https://mnot.github.io/I-D/httpbis-retry/
実装毎にリトライの基準が異なるところが興味深い。Chromiumが一番アグレッシブ。

### JSON header field value by Julian Reschke, Greenbytes

HTTPヘッダーの値にJSONを使えるようにするための[仕様](https://tools.ietf.org/html/draft-ietf-httpbis-jfv-01)の話。すでに `Clear-Site-Data` ヘッダーの値として使おうと、[関連仕様](https://w3c.github.io/webappsec-clear-site-data/#header)での動きも出つつある。

JSONについては、数値の精度の問題やそもそも遅すぎて使えないという強い反対意見があった。会場の雰囲気は悲観的。

現行のヘッダーは区切りが色々ありすぎてコンパイルコードを書くのが難しいという話や、そもそも既存のヘッダーを書き換えるのか、[CBOR](http://cbor.io/)のようなバイナリー形式の値にするのはどうか、といった議論が出ていた。

### Secondary certificate, and h2 regrets by Mike Bishop, Microsoft

資料: https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/HTTP2%20Regrets.pdf

現在進めている HTTP/2 と証明書に関する[仕様](https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01)の話。

TLSではサーバーの証明書は1接続に一つである。クライアントはSNIによってサーバーから送られる証明書を選ぶことはできても一つであることは変わらない。Secondary certificateではサーバーが追加の証明書をクライアントへh2レイヤーで送信することを可能にする。

h1ではクライアントがクライアント認証が必要なリソースにアクセスすると、サーバーはTLSでリネゴシエーションしてクライアントに証明書を要求していたが、h2ではアプリケーションデータ送信後のリネゴシエーションは禁止になっている。Secondary certificateはサーバーがクライアントに証明書を要求することをh2レイヤーで可能にする。

h2での後悔については、上記のようなクライアント証明書要求ができなくなったということ、プッシュは拡張にしてコアスペックから外すべきだった、h2プライオリティは難しいといったトピックであった。

### LT

#### H2 push from origin

#### a library for QUIC to relive h2 success

h2では早期にライブラリが出ていて有用だったので、QUICのライブラリを誰か早く作れ、という話。

#### stale-if-error stale-while-revalidate

ブラウザキャッシュを制御する stale-if-error と stale-while-revalidate の話。

ブラウザはChromeがstale-while-revalidateに対応しているのみで、他のブラウザは未サポートという状況。使うのは厳しい。

#### Implementation debug output

HTTP/2サーバーのデバッグ出力に関する話。

[Pythonでのテスト実装](https://shootout.lukasa.co.uk/.well-known/h2interop/state)と[Goのテスト実装](https://http2.golang.org/.well-known/h2interop/state)がある。

### TLS Adoption, TLS 1.3 Implementations

資料: https://drive.google.com/file/d/0B8m2iMhiJHBdQlpIOFJNNHhUTlk/view

# その他

## 街の様子

ストックホルムの旧市街地はいわゆるヨーロッパの街並みが残されていた。

![http2-1.jpg](https://qiita-image-store.s3.amazonaws.com/0/42268/e2b18c22-857f-4638-b78d-06abdad175a8.jpeg)


## 食べ物

最終日に食べた鹿肉。

![http2-2.jpg](https://qiita-image-store.s3.amazonaws.com/0/42268/47e54a5a-9526-4daa-03f1-d31c9b9fd54f.jpeg)


## 関連記事

- https://icing.github.io/mod_h2/httpws-2016.html
- https://lukasa.co.uk/2016/07/HTTP_Workshop_and_Python/
- https://blog.yoav.ws/being_pushy/