QUIC, HTTP/3の標準化状況を確認したい (2019年11月版)

HTTP QUIC internet-draft 雑

2020/06/01追記
まるっと解説記事を書き直しました
asnokaze.hatenablog.com

目次

QUICは現在IETFで標準化が進められているトランスポートプロトコルであり、HTTP/3はそのQUICの上で効率よくHTTPのメッセージをやりとりするプロトコルです。

ChromeやFirefox, Nginxなどがすでに実装を行っており、「相互接続テスト」を定期的に実施している。その他多くの実装があり、「Implementations」から確認ができる。

その標準化状況について、QUIC WGとHTTP WG両方のチェアを務めるMark Nottinghamが先週行われたIETFで発表した「Quick QUIC Update」の資料が良かったので、大変おこがましいが自分なりに補足しながら紹介したい。

技術的な詳細は過去に紹介しているので、"QUICカテゴリ"をご覧いただければと思います (関連記事をブログ最後に羅列しておきます)。

Status

QUIC WGでは、下記の4つをコアドキュメントとして扱っている。現在 draft-24であり、各ドキュメントとも歩調を合わせて改定されている。(その他にもQPACKやオペレーションに関するドキュメントも扱っている)

QUIC WGでは標準化にあたってEarly-Stage ProcessとLate-Stage Processという2段階のステージにのっとって議論を進めている。Early-Stage Processではドキュメントの著者の裁量が強く早く柔軟性が強いです。Late-Stage Processでは、WG内でのコンセンサスが得られたものが仕様に反映されます。（プロセスの詳細はURLを参照）

現在はTransport, TLS, Invariants(説明は割愛)がLate-Stage Processです。HTTP/3, QPACK, RecoveryはEarly-Stage Processですが、Late-Stage Processへの移行も近そうです。

また、先述の通り実装をもちよっての相互接続テストを実施し仕様の確度を高めています。

＊2019/11/27追記
HTTP/3, QPACK, RecoveryはLate-Stage Processになりました
https://mailarchive.ietf.org/arch/msg/quic/hxadXDI53V83dCiNe-bKGaws8-A

The Plan

2019年末頃にWorking Group Last Callが予定されています。実装及びデプロイ結果からのフィードバックを受け付けるため、長い停止時間が設けられます。

2020年中頃に、IETFの技術的責任を持つIESG(Internet Engineering Steering Group)に送られレビューされます。

その後RFCとしての体裁が整えられ、RFCとして出版されることになります。

Versions

QUICではたくさんの仕組みや機能が導入されていますが、闇雲になんでも機能追加するわけではなくQUICv1として世の中に出す機能は絞られてきました。そのため、FECやマルチパスといったいくつかの機能はQUICv2へと見送りになってきました。

QUICv2が問題なく使えるように、バージョンのネゴシエーション・管理の仕組みや、ossification(硬直化)を避ける仕組みが議論され導入されています。

しかし、現時点でQUICv2がどの様になるかは、パケットファーマット（invariants以外の部分）や機能含め具体的な議論は始まっていません。

Extensions

QUICは拡張できるようになっています。

現在検討されているもの

  • QUIC Load Balancers (duke-quic-load-balancers)
  • QUIC Version Negotiation (schinazi-quic-version-negotiation)
  • QUIC Datagrams (pauly-quic-datagram)

QUICのロードバランサとバックエンドが連携するための仕様、バージョンをより柔軟にネゴシエーションする仕様、再送を必要としないアプリケーションデータの送信などが拡張として議論されています。

その他に、下記の仕様が検討されています。

  • Loss Bits (ferrieuxhamchaoui-tsvwg-lossbits)
  • 0RTT-BDP (kuhn-quic-0rtt-bdp)
  • Multipath (deconinck-quic-multipath)

経路上からQUICコネクションでパケロス発生したことを観測できるようにする仕様、経路特性を学習し接続を再開したときによりスループットを良くする仕様、Wi-Fiとキャリア回線など複数経路を用いて通信を行うマルチパスの仕様などが議論されています。

Applications

QUICはトランスポートプロトコルですので、アプリケーションプロトコルはHTTP/3に限りません。

多くのアプリケーションプロトコルがQUICの利用を検討しています

  • WebTransport (vvv-webtransport-quic)
  • Media
  • Proxy/tunnelling (e.g., draft-schinazi-masque)
  • Others (e.g., DNS, NETCONF)

WebSocketのようなWebで双方向通信を行うWebTransport（この上でメディアも流すユースケースもあります）や、RTP over QUIC、VPNのようにつかうmasqueプロトコル。DNS over QUICなど様々です。

Other Things

その他にも、シミュレータツール、デバック用ログフォーマット、衛星通信での利用などのトピックがあります

  • QUIC Network Simulator
  • QLog logging format (marx-qlog-main-schema)
  • Pluginised QUIC
  • QUIC for SATCOM (kuhn-quic-4-sat)

More Information

その他の関連事項については、下記を参照
https://github.com/quicwg/base-drafts/wiki/Related-Activities

  • 拡張仕様は、ドラフトを書いてQUIC WGへ
  • アプリケーションは、ドラフトを書いてArea Directorへ

関連記事

手前味噌だが、今回取り上げたトピックの多くを本ブログで紹介済みである

仕様関連 (日付降順)

実装関連 (日付降順)

Qiita