QUICの標準化動向を日本語で解説。HTTP/2勉強会発表資料(2017/08/23) https://http2study.connpass.com/event/63998/

1. QUIC標準化動向 〜2017/7
QUIC標準化動向 〜2017/7
Kazuho Oku
Fastly

2. QUIC標準化動向 〜2017/7
• 大手CDN「Fastly」勤務
• HTTP/2サーバ「H2O」開発者
– TLS 1.3実装済 (known as picotls)
– QUIC実装中 (known as quicly)
• HTTP関連のインターネットドラフト著者
– 103 Early Hints
– Cache Digest for HTTP/2
自己紹介

3. QUIC標準化動向 〜2017/7
• QUICとは
• 標準化動向
• 標準化の論点
• まとめ
• TLS 1.3動向
目次

4. QUIC標準化動向 〜2017/7
QUICとは

5. QUIC標準化動向 〜2017/7

6. QUIC標準化動向 〜2017/7
• TCP/IPとTLSとHTTP/2の一体化
QUICとは
HTTP/2
TLS
TCP
IP
QUIC
QUIC-HTTP
UDP
TLS
暗号化
多重化
トランスポート

7. QUIC標準化動向 〜2017/7
• 接続確立の高速化
• ヘッドオブラインブロッキングの回避
• ローミング
• プライバシー保護と進化可能性
一体化の理由

8. QUIC標準化動向 〜2017/7
• 従来: 2RTT
– TCPハンドシェイク: 1RTT
– TLSハンドシェイク: 1RTT
• QUIC: 1RTT
– SYNとTLSハンドシェイクを一体化
接続確立の高速化

9. QUIC標準化動向 〜2017/7
• HTTP/2では、先行するレスポンスのパケット
が欠落すると、後続するレスポンスのパケット
が届いていてもデコードできない
– TCP(TLS)はデータを順に処理するモデルだから
• QUICでは、パケット単位でデコード可能
– TLSを用いてハンドシェイク後、パケット単位の暗
号鍵をTLSスタックからexport
– AEAD nonce=packet number
ヘッドオブラインブロッキング

10. QUIC標準化動向 〜2017/7
• QUICでは、IPアドレス/ポートではなく64bitの
Connection IDを用いて接続を判別すること
が可能
– クライアントのアドレスがかわっても通信を継続
ローミング

11. QUIC標準化動向 〜2017/7
• QUICでは、Connection IDとパケット番号以
外の全てのデータを暗号化
– 通信の中継者に漏れる情報が少ない
– ルータ等のバグにより、プロトコルの進化が阻害
されない
• カーネルではなくユーザランドで実装可能
• 接続確立時にプロトコルバージョンのネゴシ
エーション
プライバシー保護と進化可能性

12. QUIC標準化動向 〜2017/7
• GQUIC
– GoogleがChromeと自社サーバ間で利用してい
るプロトコル
– 定期的にバージョンアップ
• いずれはIQUICになる
• IQUIC
– GQUICをもとにIETFで標準化中のプロトコル
２つのQUIC

13. QUIC標準化動向 〜2017/7
• モバイル・新興国など回線状態の悪い環境に
おけるユーザ体験の改善
• 検索のレイテンシ:
– 90パーセンタイル: 10.3%減少
– 99パーセンタイル: 16.7%減少
• 動画再生時のリバッファ発生率
– 90パーセンタイル: 70.4%減少
– 99パーセンタイル: 18.5%減少
参考文献: The QUIC Transport Protocol: Design and Internet-Scale Deployment
GQUICの効果測定

14. QUIC標準化動向 〜2017/7
• パケット構成:
– ヘッダ:
• Type, Connection ID, Packet Numberは平文
• 残りはAEAD暗号化
– 平文部分はAEADの認証データ
– フレーム群:
• STREAM, ACK, MAX_DATA, …
• HTTPのフレーム != QUICフレーム
– HTTPのフレーム（例: PRIORITY）はSTREAM内のデータ
IQUICのパケットフォーマット

15. QUIC標準化動向 〜2017/7
Long Packet:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|1| Type (7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Connection ID (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frames (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STREAM Frame:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|1 1 F S S O O D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (0/16/32/64) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Data Length (16)] | Stream Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

16. QUIC標準化動向 〜2017/7
ACK Frame:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 1 N L L M M|[Num Blocks(8)]| NumTS (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Acknowledged (8/16/32/64) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Delay (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Block Section (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Section (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACK Block Section:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First ACK Block Length (8/16/32/64) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap 1 (8)] | [ACK Block 1 Length (8/16/32/64)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap 2 (8)] | [ACK Block 2 Length (8/16/32/64)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap N (8)] | [ACK Block N Length (8/16/32/64)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

17. QUIC標準化動向 〜2017/7
標準化動向

18. QUIC標準化動向 〜2017/7
• 2016/11 ワーキンググループ設立
• 2017/7 初回相互接続テスト
• 2018/3 コアドキュメント群のラストコール完了
• 2018/11 HTTPマッピングのラストコール完了
予定ロードマップ(2016/11)

19. QUIC標準化動向 〜2017/7
• 2016/11 ワーキンググループ設立
• 2017/7 初回相互接続テスト
• 2018/3 コアドキュメント群のラストコール完了
• 2018/11 HTTPマッピングのラストコール完了
実際

20. QUIC標準化動向 〜2017/7
初回相互接続テスト
参照: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit
• 当初はハンドシェイクのみにする予定だった
• 次回はHTTP/0.9での相互接続が目標

21. QUIC標準化動向 〜2017/7
• Rough Consensus and Running Code
• 基本はMLとGitHub Issuesで議論
• 年6回のミーティング
– 年3回のIETF
– 年3回のInterim Meeting
– ハッカソンで相互接続を確認、問題の洗い出し
標準化の進め方

22. QUIC標準化動向 〜2017/7

23. QUIC標準化動向 〜2017/7
標準化の論点

24. QUIC標準化動向 〜2017/7
• トランスポート
– Server-chosen Connection ID
– Stateless Reset
– Closing Connections
– Unidirectional Streams
– On-path RTT measurement
– …
• HTTPバインディング
標準化の論点

25. QUIC標準化動向 〜2017/7
• GQUICの仕様: IDはクライアントが決定
• やりたいこと: IDにPOP識別子を埋込みたい
– 理由: クライアントのアドレスがローミングすると、
AnycastベースのCDNでは異なるPOPにパケット
が届き始める
– 元のPOPがどこかをどうやって判別するのか
• 結論: ハンドシェイク終了時にサーバで
Connection IDを発番
Server-chosen Connection ID

26. QUIC標準化動向 〜2017/7
• QUICではRSTも暗号化される
• 課題: エンドポイントがリセットされて暗号鍵
が失われたら、接続をリセットできない???
• 結論: 以下の手順でやる
– 1. RSTを表すバイト列を接続確立時に発行
• このバイト列はstatic keyとconnection IDから導出
• 一見暗号化されたデータのように見える
– 2. サーバはリセット時に、このバイト列を送信
– 3. クライアントはパケットの復号に失敗したら、こ
のリセットでないか確認
Stateless Reset

27. QUIC標準化動向 〜2017/7
• 接続レベルでの切断用パケットは不要?
– 注: ストリーム単位でのFINはある
– タイムアウト時に切断パケットを流すのは電力と
ネットワークの無駄
• 結論:
– 切断用パケットはQUICでは標準化しない
– 必要なら各プロトコルバインディングで対応
• 例: DNS over QUICなら切断用パケット不要
• 例: HTTP over QUICなら、切断時に、サーバが最後
に処理したリクエストのstream IDを送信
Closing Connections

28. QUIC標準化動向 〜2017/7
• ストリームを片方向として定義したい
– 各バインディングで両方向のストリームを束ねれ
ば、双方向ストリームを実現可能
• メリット:
– QUICレイヤのステートマシン単純化
• デメリット:
– バインディングの複雑化
• 結論: 提案の再検討
– コアで双方向ストリームをサポートする点は合意
Unidirectional Streams

29. QUIC標準化動向 〜2017/7
• QUICでは、ルータはACKに含まれるpacket
numberを観測できない（暗号化されるから）
• 課題: ルータが接続のRTTを測定し、それに
基づいた最適化を施せない
• 解決案:
– パケットヘッダ内に、ルータが自由に書き換え可
能な1bitを用意する
– エンドポイントはこの1bitをそのままエコー
• 問題: プライバシーリスク
On-path RTT measurement

30. QUIC標準化動向 〜2017/7
• ECN対応
– ルータが輻輳をエンドポイントに通知
– エンドポイントはピアにECN情報を通知※
– ※をQUICで行うべきか、どうやるか
• Encrypting Metadata
– packet numberも暗号化したい
その他のコアのissue

31. QUIC標準化動向 〜2017/7
• 問題: ヘッダとボディを別々のストリームで送
るか否か
– 注: ヘッダを送るストリームはリセットできない（圧
縮情報として後続のリクエストから参照されるた
め）。ボディはリセット必須
• 結論:
– 圧縮情報はcontrol streamで送信
– ヘッダとボディはリセット可能な単一ストリーム
• ヘッダはcontrol streamの圧縮情報を参照
HTTPバインディング

32. QUIC標準化動向 〜2017/7
• ヘッダ圧縮
– HPACKは配送順に依存するので改良が必要
– ふたつの提案: QPACK, QCRAM
– 両者の主要な差異:
• header indexを絶対値で送るか、絶対値を復元可能
な相対値で送るか
• トランスポートが受信したACKの情報を使ってヘッダ
圧縮器のステートを更新するか、HTTPバインディング
レベルでACKを送るか
HTTPバインディング

33. QUIC標準化動向 〜2017/7
• 優先度制御
– HTTP/2では、Idle Streamを使って、複数のスト
リームをまとめて優先度制御していた
– QUICにはIdle Streamが存在しない
• すべてのStreamでHTTPリクエストを流さないと色々
面倒なことになるので…
– 解決策: ストリームをまとめるグループ専用のID
空間を用意しよう
HTTPバインディング

34. QUIC標準化動向 〜2017/7
まとめ

35. QUIC標準化動向 〜2017/7
• 議論錯綜中
– 特にunidirectional streamはコアの設計に影響
• interopはちょい遅れくらいでがんばり
まとめ

36. QUIC標準化動向 〜2017/7
TLS 1.3動向

37. QUIC標準化動向 〜2017/7
• draft-21のWGLCなう
• 一部のファイアウォールを通過できない問題
– Facebookがcleartext handshake messageの
IDを変えることで、疎通率が改善したと報告
• Googleが追試中
• Using Early Data in HTTP
TLS 1.3動向