QUICの話 (QUICプロトコルの簡単なまとめ)

[追記] QUIC, HTTP/3 関連記事
まるっと解説記事を書き直しました
asnokaze.hatenablog.com

その他もどうぞ

QUICの話

QUICのプロトコルについて、自分の理解を整理するためにその中身について簡単にまとめていきたい。

本当は体系的にちゃんとまとめていきたい。。。

(なお、draft16を元に書いている)

QUICの話
QUICの概要
プロトコルの話
次書きたい話題

QUICの概要

QUICと今

プロトコルの中身に入る前に、簡単にQUICについて紹介をする。

QUICはもともとGoogleによって考案実装されたUDP上で動作するプロトコルであり、TCPのような信頼性を持ちTLSのような暗号化された通信路で効率的なHTTPのメッセージをやりとりする。すでにChromeやGoogleのサービスで実装されている。そのデプロイについては以前このブログで触れた、GoogleのQUIC関係者によって書かれた論文が詳しい(こちらを参照)。

Googleでの実験をへて、2016年11月より正式にIETFでQUIC WGが結成され、QUICの標準化が進められている。

ここで注意すべきは、Googleが現在使っているQUICとIETFで標準化を行っているQUICはとこどころ異なっており互換性はない。区別して前者をgQUIC、後者をiQUICと呼び分ける。(参照: gQUICのiQUICへの移行について)

iQUICは実装はすでにいくつかあり、定期的に実装をもちよって相互接続性試験を行っており、その結果を仕様側にフィードバックし仕様の確度をあげている。今は「9th Implementation Draft」となっており、その相互接続性試験の結果はスプレッドシートにまとめられている(URL)。

なお、iQUICはトランスポートプロトコルであり、上位のプロトコルとしてまずHTTPを想定しているがHTTPのみには限定されない。
以後、特に断りがない場合、QUICと行った場合 iQUIC を指す。

背景とQUICの目的

Webの配信高速化のために、HTTP/1.1からHTTP/2への改定された。より高速化のために、トランスポートレイヤでの問題に焦点が当てられるようになりました。

例えば下記の点があげられる

TCPでは、パケットロスがあるとパケットロスが回復されるのをまってアプリケーションにデータが渡される。
- HTTP/2では複数のリクエスト・レスポンスが一つのTCPコネクションに多重化されている。
- HTTPレスポンスAとHTTPレスポンスBがあったとする、片方のデータのパケットロスが、もう片方の通信もブロックさせてしまう。
ハンドシェイクのラウンドトリップ回数 (TCP + TLS)
- 通信を開始するにあたって、TCPとTLSのコネクション確立にラウンドトリップタイムがかかる
クライアントのIP / ポート変更に伴うコネクションの切断
- Wi-Fiからキャリア回線などにハンドオーバーした際、TCPコネクションが切れてしまう

そのような問題を解決するために、QUICでは下記の項目にフォーカスして標準化が進められました

コネクション確立と全体的な転送待ち時間を最小限に抑え、アプリケーションデータをより早いタイミングで転送可能とする
ヘッドラインブロッキング(HoLB)なしで多重化を提供する。パケットロスの影響を最小化する
エンドポイントのみが対応すればQUICが疎通するようにする（スイッチや中間装置の対応が不要）
マルチパスとFEC拡張の対応
デフォルトでTLS 1.3を使用して、常に安全なトランスポートを提供する。

フォーカス項目としては以上のとおりだが、QUICの機能は多く、上記にあがってないが、例えばECN(Explicit Congestion Notification)がサポートされていたりとたくさんの機能が組み込まれている。

ちなみに、現在はQUIC v1と呼ばれる機能の標準化を行っており、マルチパスやFECといった機能は先送りとなっている。しかし、そういった機能が将来的には対応できるよう拡張性をもっている。

QUICのオーバービュー

QUICのプロトコルスタックは以下の通りである
f:id:ASnoKaze:20181031000151p:plain
(引用: QUIC Tutorial)

左側のスタックが一般的に使用されているHTTP/2で、右側がQUICのスタックです。

QUICの構成としては

QUICで提供されるトランスポート上でHTTPのメッセージをやりとりする。
コネクション確立時にTLS1.3のメッセージをやり取りし、以後のメッセージを暗号化する鍵を取得する(0-RTT鍵, 1-RTT鍵)。
- メッセージのAckやコネクションの切断メッセージといった制御メッセージも暗号化される。
UDP上で、TCPのような信頼性(パケロスの回復・パケットの順番の入れ替わりの補正)や輻輳制御フロー制御を提供するレイヤ。
- パスの到達性や、アドレスの所持確認の機能や、反射攻撃を防ぐ工夫など
- ストリームと呼ばれる仮想的な通信単位を持つ
- 輻輳制御やパケロス検出アルゴリズムはTCPなどで使用されているものをそのまま使用する

HTTP部分については、通常のHTTP/2のメッセージ形式を使うのではなくQUICで扱うための変更が入っている

通所のHTTP/2に似ており、HTTPメッセージをやりとりする
後述のストリームの管理がQUICレイヤに移り、それにあわせフレームの変更やQUICストリームの利用方法の定義
ヘッドオブラインブロッキング避けるために、HPACKをQUIC用に改良したQPACKを用いる
サーバプッシュやプライオリティの扱いが少し変更された
QUICにあわせてエラーメッセージの追加など

提案仕様はレイヤごとに別れており、スタックと合わせてみるとわかりやすい

プロトコルの話

ここからQUICのプロトコルの中の話に入っていく

QUICの用語

QUICで用いる用語について簡単に紹介する。

エンドポイント

クライアント: QUICコネクションを開始する側
サーバ: QUICコネクションを受け付ける側
エンドポイント: クライアントもしくはサーバ
ピア: 反対のエンドポイント

コネクションとパケット

QUICコネクション: UDP上のQUICレイヤのいわゆるコネクション。可変長整数のコネクションIDによって識別される
- Source Connection ID: 送信元のコネクションID (一度、コネクションが確立すると省略される)
- Destination Connection ID: 送信先のコネクションD
QUICパケット
- ClientとServerによってやりとりされるデータの単位
- UDPパケットの中にQUICパケットが結合されて格納される場合がある(ただし個別のQUICパケットとして処理される)
- QUICパケットにタイプが有り、それぞれロングヘッダもしくはショートヘッダを持つ
- ロングヘッダはコネクション確立時に利用され、ショートヘッダはそれ以降利用される
- パケットタイプ毎にパケット番号を持ち、パケットを送るごとにインクリメントされる

f:id:ASnoKaze:20181031010348p:plain

ストリームとフレーム

フレーム
- QUICパケットの中に含まれるメッセージ単位
- 現在のQUICの仕様では21のフレームタイプが定義されており、フレームによって様々なメッセージを格納する。例えば次の通り
- 暗号ハンドシェイクのデータ、アプリケーションプロトコルのデータ、Ackやクローズといった制御情報、フロー制御情報
- パケットがロスした場合は、再送する必要のあるフレームのみ、新しいパケット番号を持つパケットで再送される
ストリーム
- QUICはHTTP/2のように、コネクションの中にストリームと呼ばれる仮想的な通信単位を持つ
- いくつかのフレームは、ストリームIDを持ちストリームと紐付けられる
- 各ストリームはストリームIDを持つ
- ストリームにはタイプが有り、そのストリームIDの下位2bitによって次の通り分かれる
  - 0x0:クライアントが作成した双方向ストリーム、0x1:サーバが作成した双方向ストリーム
  - 0x2:クライアントが作成した単方向ストリーム、0x3:サーバが作成した単方向ストリーム
- 同じストリームに属するデータ内でのみ、パケットロスや並び替わりでブロックが発生する。他のストリームのデータはブロックしない。
- (UDPなので、来たデータからユーザ空間で処理可能)

f:id:ASnoKaze:20181031005926p:plain
(STREAMフレームはHTTPなどのアプリケーションデータを運ぶ)

QUICのコネクション確立/切断

コネクションの確立

QUICのコネクションの確立は下記のとおり行われます。
f:id:ASnoKaze:20181031012530p:plain

このときにトランスポート用パラメータと、TLSハンドシェイクをあわせて行うため、RTTが小さくなっています

TLS1.3の鍵交換のメッセージはCRYPTOフレームに格納されますが、コネクションを確立するための最初のCRYPTOフレームはInitialパケットで送信されます。各パケットタイプ毎にAckを返し、続いてHandshakeパケットでCRYPTOフレームを送信しTLS1.3のハンドシェイクを完了します。こうして1-RTT鍵が取得できたら、1-RTT鍵で保護されたパケットでアプリケーションデータを送受信できるようになります。

明示的にクライアントのIPアドレス所持を確認する方法もありますが、このハンドシェイクを通してクライアントのIPアドレス所持を確認できます

初期ウィンドウサイズや、ストリームの上限といったトランスポートパラメータはQUIC TLSで定義されるquic_transport_parameters拡張に格納され、ハンドシェイク後にきちんと認証されます。

コネクションの切断

QUICのコネクションの切断は3種類ある

アイドルタイムアウト
即時切断
ステートレスリセット

アイドルタイムアウトはその名の通り、トランスポートパラメータでアドバタイズされたアイドルタイムアウト値を超えた場合はクローズされる。なお、タイムアウト直前に送られたパケットが届く可能性があるため、draining状態になってから規定時間待ってコネクションの状態を破棄する。

即時切断は、CONNECTION_CLOSEフレームもしくはAPPLICATION_CLOSEフレームを送信することでコネクションを即時にクローズすることができます。なお、アイドルタイムアウトと同様、パケットの順番などが入れ替わる可能性があるのでdraining状態をヘてコネクションの状態が破棄されます。

ステートレスリセットは、コネクションを切断するための最後の手段です。仮にサーバ側の再起動などにより鍵情報が失われ、サーバが届いたパケットを正しく解読できなくなった場合、CONNECTION_CLOSEといった切断用のメッセージも解釈できなくなってしまいます。そうするとクライアントはアイドルタイムアウトまで待たないとコネクションが切断できなくなってしまいます。

上記の問題を防ぐために、サーバ側から事前にトークンを暗号路で発行しておき、そのトークンをステートレスリセットパケットでサーバに送ることでトークンと紐づくコネクションを切断できるようにします。

一度使ったトークンは二度としようできません。