Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
QUIC標準化動向 〜2017/7
QUIC標準化動向 〜2017/7
Kazuho Oku
Fastly
QUIC標準化動向 〜2017/7
• 大手CDN「Fastly」勤務
• HTTP/2サーバ「H2O」開発者
– TLS 1.3実装済 (known as picotls)
– QUIC実装中 (known as quicly)
• HTTP...
QUIC標準化動向 〜2017/7
• QUICとは
• 標準化動向
• 標準化の論点
• まとめ
• TLS 1.3動向
目次
QUIC標準化動向 〜2017/7
QUICとは
QUIC標準化動向 〜2017/7
QUIC標準化動向 〜2017/7
• TCP/IPとTLSとHTTP/2の一体化
QUICとは
HTTP/2
TLS
TCP
IP
QUIC
QUIC-HTTP
UDP
TLS
暗号化
多重化
トランスポート
QUIC標準化動向 〜2017/7
• 接続確立の高速化
• ヘッドオブラインブロッキングの回避
• ローミング
• プライバシー保護と進化可能性
一体化の理由
QUIC標準化動向 〜2017/7
• 従来: 2RTT
– TCPハンドシェイク: 1RTT
– TLSハンドシェイク: 1RTT
• QUIC: 1RTT
– SYNとTLSハンドシェイクを一体化
接続確立の高速化
QUIC標準化動向 〜2017/7
• HTTP/2では、先行するレスポンスのパケット
が欠落すると、後続するレスポンスのパケット
が届いていてもデコードできない
– TCP(TLS)はデータを順に処理するモデルだから
• QUICでは、パケッ...
QUIC標準化動向 〜2017/7
• QUICでは、IPアドレス/ポートではなく64bitの
Connection IDを用いて接続を判別すること
が可能
– クライアントのアドレスがかわっても通信を継続
ローミング
QUIC標準化動向 〜2017/7
• QUICでは、Connection IDとパケット番号以
外の全てのデータを暗号化
– 通信の中継者に漏れる情報が少ない
– ルータ等のバグにより、プロトコルの進化が阻害
されない
• カーネルではなくユ...
QUIC標準化動向 〜2017/7
• GQUIC
– GoogleがChromeと自社サーバ間で利用してい
るプロトコル
– 定期的にバージョンアップ
• いずれはIQUICになる
• IQUIC
– GQUICをもとにIETFで標準化中のプ...
QUIC標準化動向 〜2017/7
• モバイル・新興国など回線状態の悪い環境に
おけるユーザ体験の改善
• 検索のレイテンシ:
– 90パーセンタイル: 10.3%減少
– 99パーセンタイル: 16.7%減少
• 動画再生時のリバッファ発生...
QUIC標準化動向 〜2017/7
• パケット構成:
– ヘッダ:
• Type, Connection ID, Packet Numberは平文
• 残りはAEAD暗号化
– 平文部分はAEADの認証データ
– フレーム群:
• STREA...
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
+-+-+-+-+-+-+-+-+
|...
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
+-+-+-+-+-+-+-+-+-+-+...
QUIC標準化動向 〜2017/7
標準化動向
QUIC標準化動向 〜2017/7
• 2016/11 ワーキンググループ設立
• 2017/7 初回相互接続テスト
• 2018/3 コアドキュメント群のラストコール完了
• 2018/11 HTTPマッピングのラストコール完了
予定ロードマ...
QUIC標準化動向 〜2017/7
• 2016/11 ワーキンググループ設立
• 2017/7 初回相互接続テスト
• 2018/3 コアドキュメント群のラストコール完了
• 2018/11 HTTPマッピングのラストコール完了
実際
QUIC標準化動向 〜2017/7
初回相互接続テスト
参照: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit
•...
QUIC標準化動向 〜2017/7
• Rough Consensus and Running Code
• 基本はMLとGitHub Issuesで議論
• 年6回のミーティング
– 年3回のIETF
– 年3回のInterim Meetin...
QUIC標準化動向 〜2017/7
QUIC標準化動向 〜2017/7
標準化の論点
QUIC標準化動向 〜2017/7
• トランスポート
– Server-chosen Connection ID
– Stateless Reset
– Closing Connections
– Unidirectional Streams...
QUIC標準化動向 〜2017/7
• GQUICの仕様: IDはクライアントが決定
• やりたいこと: IDにPOP識別子を埋込みたい
– 理由: クライアントのアドレスがローミングすると、
AnycastベースのCDNでは異なるPOPにパケ...
QUIC標準化動向 〜2017/7
• QUICではRSTも暗号化される
• 課題: エンドポイントがリセットされて暗号鍵
が失われたら、接続をリセットできない???
• 結論: 以下の手順でやる
– 1. RSTを表すバイト列を接続確立時に発...
QUIC標準化動向 〜2017/7
• 接続レベルでの切断用パケットは不要?
– 注: ストリーム単位でのFINはある
– タイムアウト時に切断パケットを流すのは電力と
ネットワークの無駄
• 結論:
– 切断用パケットはQUICでは標準化しな...
QUIC標準化動向 〜2017/7
• ストリームを片方向として定義したい
– 各バインディングで両方向のストリームを束ねれ
ば、双方向ストリームを実現可能
• メリット:
– QUICレイヤのステートマシン単純化
• デメリット:
– バイン...
QUIC標準化動向 〜2017/7
• QUICでは、ルータはACKに含まれるpacket
numberを観測できない(暗号化されるから)
• 課題: ルータが接続のRTTを測定し、それに
基づいた最適化を施せない
• 解決案:
– パケットヘ...
QUIC標準化動向 〜2017/7
• ECN対応
– ルータが輻輳をエンドポイントに通知
– エンドポイントはピアにECN情報を通知※
– ※をQUICで行うべきか、どうやるか
• Encrypting Metadata
– packet n...
QUIC標準化動向 〜2017/7
• 問題: ヘッダとボディを別々のストリームで送
るか否か
– 注: ヘッダを送るストリームはリセットできない(圧
縮情報として後続のリクエストから参照されるた
め)。ボディはリセット必須
• 結論:
– 圧...
QUIC標準化動向 〜2017/7
• ヘッダ圧縮
– HPACKは配送順に依存するので改良が必要
– ふたつの提案: QPACK, QCRAM
– 両者の主要な差異:
• header indexを絶対値で送るか、絶対値を復元可能
な相対値で...
QUIC標準化動向 〜2017/7
• 優先度制御
– HTTP/2では、Idle Streamを使って、複数のスト
リームをまとめて優先度制御していた
– QUICにはIdle Streamが存在しない
• すべてのStreamでHTTPリク...
QUIC標準化動向 〜2017/7
まとめ
QUIC標準化動向 〜2017/7
• 議論錯綜中
– 特にunidirectional streamはコアの設計に影響
• interopはちょい遅れくらいでがんばり
まとめ
QUIC標準化動向 〜2017/7
TLS 1.3動向
QUIC標準化動向 〜2017/7
• draft-21のWGLCなう
• 一部のファイアウォールを通過できない問題
– Facebookがcleartext handshake messageの
IDを変えることで、疎通率が改善したと報告
•...
Prochain SlideShare
Chargement dans…5
×

QUIC標準化動向 〜2017/7

7 818 vues

Publié le

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

Publié dans : Technologie
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

QUIC標準化動向 〜2017/7

  1. 1. QUIC標準化動向 〜2017/7 QUIC標準化動向 〜2017/7 Kazuho Oku Fastly
  2. 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. 3. QUIC標準化動向 〜2017/7 • QUICとは • 標準化動向 • 標準化の論点 • まとめ • TLS 1.3動向 目次
  4. 4. QUIC標準化動向 〜2017/7 QUICとは
  5. 5. QUIC標準化動向 〜2017/7
  6. 6. QUIC標準化動向 〜2017/7 • TCP/IPとTLSとHTTP/2の一体化 QUICとは HTTP/2 TLS TCP IP QUIC QUIC-HTTP UDP TLS 暗号化 多重化 トランスポート
  7. 7. QUIC標準化動向 〜2017/7 • 接続確立の高速化 • ヘッドオブラインブロッキングの回避 • ローミング • プライバシー保護と進化可能性 一体化の理由
  8. 8. QUIC標準化動向 〜2017/7 • 従来: 2RTT – TCPハンドシェイク: 1RTT – TLSハンドシェイク: 1RTT • QUIC: 1RTT – SYNとTLSハンドシェイクを一体化 接続確立の高速化
  9. 9. QUIC標準化動向 〜2017/7 • HTTP/2では、先行するレスポンスのパケット が欠落すると、後続するレスポンスのパケット が届いていてもデコードできない – TCP(TLS)はデータを順に処理するモデルだから • QUICでは、パケット単位でデコード可能 – TLSを用いてハンドシェイク後、パケット単位の暗 号鍵をTLSスタックからexport – AEAD nonce=packet number ヘッドオブラインブロッキング
  10. 10. QUIC標準化動向 〜2017/7 • QUICでは、IPアドレス/ポートではなく64bitの Connection IDを用いて接続を判別すること が可能 – クライアントのアドレスがかわっても通信を継続 ローミング
  11. 11. QUIC標準化動向 〜2017/7 • QUICでは、Connection IDとパケット番号以 外の全てのデータを暗号化 – 通信の中継者に漏れる情報が少ない – ルータ等のバグにより、プロトコルの進化が阻害 されない • カーネルではなくユーザランドで実装可能 • 接続確立時にプロトコルバージョンのネゴシ エーション プライバシー保護と進化可能性
  12. 12. QUIC標準化動向 〜2017/7 • GQUIC – GoogleがChromeと自社サーバ間で利用してい るプロトコル – 定期的にバージョンアップ • いずれはIQUICになる • IQUIC – GQUICをもとにIETFで標準化中のプロトコル 2つのQUIC
  13. 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. 14. QUIC標準化動向 〜2017/7 • パケット構成: – ヘッダ: • Type, Connection ID, Packet Numberは平文 • 残りはAEAD暗号化 – 平文部分はAEADの認証データ – フレーム群: • STREAM, ACK, MAX_DATA, … • HTTPのフレーム != QUICフレーム – HTTPのフレーム(例: PRIORITY)はSTREAM内のデータ IQUICのパケットフォーマット
  15. 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. 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. 17. QUIC標準化動向 〜2017/7 標準化動向
  18. 18. QUIC標準化動向 〜2017/7 • 2016/11 ワーキンググループ設立 • 2017/7 初回相互接続テスト • 2018/3 コアドキュメント群のラストコール完了 • 2018/11 HTTPマッピングのラストコール完了 予定ロードマップ(2016/11)
  19. 19. QUIC標準化動向 〜2017/7 • 2016/11 ワーキンググループ設立 • 2017/7 初回相互接続テスト • 2018/3 コアドキュメント群のラストコール完了 • 2018/11 HTTPマッピングのラストコール完了 実際
  20. 20. QUIC標準化動向 〜2017/7 初回相互接続テスト 参照: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit • 当初はハンドシェイクのみにする予定だった • 次回はHTTP/0.9での相互接続が目標
  21. 21. QUIC標準化動向 〜2017/7 • Rough Consensus and Running Code • 基本はMLとGitHub Issuesで議論 • 年6回のミーティング – 年3回のIETF – 年3回のInterim Meeting – ハッカソンで相互接続を確認、問題の洗い出し 標準化の進め方
  22. 22. QUIC標準化動向 〜2017/7
  23. 23. QUIC標準化動向 〜2017/7 標準化の論点
  24. 24. QUIC標準化動向 〜2017/7 • トランスポート – Server-chosen Connection ID – Stateless Reset – Closing Connections – Unidirectional Streams – On-path RTT measurement – … • HTTPバインディング 標準化の論点
  25. 25. QUIC標準化動向 〜2017/7 • GQUICの仕様: IDはクライアントが決定 • やりたいこと: IDにPOP識別子を埋込みたい – 理由: クライアントのアドレスがローミングすると、 AnycastベースのCDNでは異なるPOPにパケット が届き始める – 元のPOPがどこかをどうやって判別するのか • 結論: ハンドシェイク終了時にサーバで Connection IDを発番 Server-chosen Connection ID
  26. 26. QUIC標準化動向 〜2017/7 • QUICではRSTも暗号化される • 課題: エンドポイントがリセットされて暗号鍵 が失われたら、接続をリセットできない??? • 結論: 以下の手順でやる – 1. RSTを表すバイト列を接続確立時に発行 • このバイト列はstatic keyとconnection IDから導出 • 一見暗号化されたデータのように見える – 2. サーバはリセット時に、このバイト列を送信 – 3. クライアントはパケットの復号に失敗したら、こ のリセットでないか確認 Stateless Reset
  27. 27. QUIC標準化動向 〜2017/7 • 接続レベルでの切断用パケットは不要? – 注: ストリーム単位でのFINはある – タイムアウト時に切断パケットを流すのは電力と ネットワークの無駄 • 結論: – 切断用パケットはQUICでは標準化しない – 必要なら各プロトコルバインディングで対応 • 例: DNS over QUICなら切断用パケット不要 • 例: HTTP over QUICなら、切断時に、サーバが最後 に処理したリクエストのstream IDを送信 Closing Connections
  28. 28. QUIC標準化動向 〜2017/7 • ストリームを片方向として定義したい – 各バインディングで両方向のストリームを束ねれ ば、双方向ストリームを実現可能 • メリット: – QUICレイヤのステートマシン単純化 • デメリット: – バインディングの複雑化 • 結論: 提案の再検討 – コアで双方向ストリームをサポートする点は合意 Unidirectional Streams
  29. 29. QUIC標準化動向 〜2017/7 • QUICでは、ルータはACKに含まれるpacket numberを観測できない(暗号化されるから) • 課題: ルータが接続のRTTを測定し、それに 基づいた最適化を施せない • 解決案: – パケットヘッダ内に、ルータが自由に書き換え可 能な1bitを用意する – エンドポイントはこの1bitをそのままエコー • 問題: プライバシーリスク On-path RTT measurement
  30. 30. QUIC標準化動向 〜2017/7 • ECN対応 – ルータが輻輳をエンドポイントに通知 – エンドポイントはピアにECN情報を通知※ – ※をQUICで行うべきか、どうやるか • Encrypting Metadata – packet numberも暗号化したい その他のコアのissue
  31. 31. QUIC標準化動向 〜2017/7 • 問題: ヘッダとボディを別々のストリームで送 るか否か – 注: ヘッダを送るストリームはリセットできない(圧 縮情報として後続のリクエストから参照されるた め)。ボディはリセット必須 • 結論: – 圧縮情報はcontrol streamで送信 – ヘッダとボディはリセット可能な単一ストリーム • ヘッダはcontrol streamの圧縮情報を参照 HTTPバインディング
  32. 32. QUIC標準化動向 〜2017/7 • ヘッダ圧縮 – HPACKは配送順に依存するので改良が必要 – ふたつの提案: QPACK, QCRAM – 両者の主要な差異: • header indexを絶対値で送るか、絶対値を復元可能 な相対値で送るか • トランスポートが受信したACKの情報を使ってヘッダ 圧縮器のステートを更新するか、HTTPバインディング レベルでACKを送るか HTTPバインディング
  33. 33. QUIC標準化動向 〜2017/7 • 優先度制御 – HTTP/2では、Idle Streamを使って、複数のスト リームをまとめて優先度制御していた – QUICにはIdle Streamが存在しない • すべてのStreamでHTTPリクエストを流さないと色々 面倒なことになるので… – 解決策: ストリームをまとめるグループ専用のID 空間を用意しよう HTTPバインディング
  34. 34. QUIC標準化動向 〜2017/7 まとめ
  35. 35. QUIC標準化動向 〜2017/7 • 議論錯綜中 – 特にunidirectional streamはコアの設計に影響 • interopはちょい遅れくらいでがんばり まとめ
  36. 36. QUIC標準化動向 〜2017/7 TLS 1.3動向
  37. 37. QUIC標準化動向 〜2017/7 • draft-21のWGLCなう • 一部のファイアウォールを通過できない問題 – Facebookがcleartext handshake messageの IDを変えることで、疎通率が改善したと報告 • Googleが追試中 • Using Early Data in HTTP TLS 1.3動向

×