これは第9回HTTP/2勉強会の資料です。
スウェーデンの首都、ストックホルムで開催された第二回HTTP Workshopへの出張報告である。
- このイベントはワークショップ形式であり、HTTPについての議論をする場
- 非常にラフなアジェンダのみ用意されており、スケジュールは頻繁に変更される
- Twitter公式アカウントでも情報が発信されている
- レポートがすでに公開されており、参加者も記載されている
場所、日時
- 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主催の 
を飲む会。
1日目
1日目レポート: https://daniel.haxx.se/blog/2016/07/25/a-workshop-monday/
The state of HTTP by Mark Nottingham, Akamai
これはキーノート的なもので、現在のHTTPコミュニティで議論している事柄の総まとめ。
h2 checkpoint by Patrick, Mozilla
発表資料: https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/http2-review-data.pdf
MozillaがFirefox Telemetryで集めた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の話。
Cache Digestとは、クライアントがキャッシュしているリソースをサーバーに知らせる仕組みで、サーバーをその情報をもとにプッシュするかしないかを判断できる。
Cache Digestを送るために接続毎にブラウザがキャッシュをオリジン毎に全部確かめるコストは?
Cache DigestはGolumb-Rice符号を使っている。これはブルームフィルターに比べてサイズを小さくできるが、計算コストが高い。
Mozilla主催の夕食会
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のチューニング方法をまとめた仕様の話。
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も代替候補だよ、という意見があった。
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において、リクエストを送信したが、何らかの理由で、レスポンスが得られなかった場合に、クライアントがリクエストを再送するかどうかは、リクエストメソッドの冪等性に依っている。
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を使えるようにするための仕様の話。すでに Clear-Site-Data ヘッダーの値として使おうと、関連仕様での動きも出つつある。
JSONについては、数値の精度の問題やそもそも遅すぎて使えないという強い反対意見があった。会場の雰囲気は悲観的。
現行のヘッダーは区切りが色々ありすぎてコンパイルコードを書くのが難しいという話や、そもそも既存のヘッダーを書き換えるのか、CBORのようなバイナリー形式の値にするのはどうか、といった議論が出ていた。
Secondary certificate, and h2 regrets by Mike Bishop, Microsoft
資料: https://github.com/HTTPWorkshop/workshop2016/raw/master/talks/HTTP2%20Regrets.pdf
現在進めている HTTP/2 と証明書に関する仕様の話。
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サーバーのデバッグ出力に関する話。
TLS Adoption, TLS 1.3 Implementations
資料: https://drive.google.com/file/d/0B8m2iMhiJHBdQlpIOFJNNHhUTlk/view
その他
街の様子
ストックホルムの旧市街地はいわゆるヨーロッパの街並みが残されていた。
食べ物
最終日に食べた鹿肉。
