17. パケットフォーマット

すべての数値はネットワークバイトオーダー（つまり、ビッグエンディアン）でエンコードされ、すべてのフィールドサイズはビット単位です。フィールドの値を記述するために16進表記が使用されます。

17.1 パケット番号のエンコードとデコード

パケット番号は、0から2^62-1の範囲の整数です (セクション 12.3)。パケット内に存在する場合、1〜4バイトでエンコードされます。パケット番号を表すために必要なビット数は、パケット番号の最下位ビットのみを含めることで削減されます。

エンコードされたパケット番号は、[QUIC-TLS] のセクション 5.4 で説明されているように保護されます。

送信者は、最大の確認応答されたパケット番号と送信されるパケット番号との差の2倍以上の範囲を表現できるパケット番号サイズを使用しなければなりません (MUST)。パケットを受信するピアは、パケットが転送中に遅延して、より高い番号の多くのパケットが受信された後に到着しない限り、パケット番号を正しくデコードします。

その結果、パケット番号エンコーディングのサイズは、新しいパケットを含む連続した未確認応答パケット番号の数の底2の対数より少なくとも1つ多くなります。

17.2 ロングヘッダーパケット

ロングヘッダーは、1-RTTキーの確立前に送信されるパケットに使用されます。1-RTTキーが利用可能になると、送信者はショートヘッダーを使用するパケットの送信に切り替えます (セクション 17.3)。ロング形式により、バージョンネゴシエーションパケットなどの特殊なパケットを、この統一された固定長パケットフォーマットで表現できます。

ロングヘッダーを持つパケットは、ヘッダーフォームビットが1に設定されていることで識別されます。

17.2.1 バージョンネゴシエーションパケット

バージョンネゴシエーションパケットは本質的にバージョン固有ではありません。クライアントによる受信時に、Versionフィールドの値が0であることに基づいてバージョンネゴシエーションパケットとして識別されます。

17.2.2 Initialパケット

Initialパケットは、タイプ値0x00のロングヘッダーを使用します。鍵交換を実行するためにクライアントとサーバーによって送信される最初のCRYPTOフレームを運び、両方向のACKフレームを運びます。

17.2.3 0-RTT

0-RTTパケットは、タイプ値0x01のロングヘッダーを使用します。0-RTTパケットは、ApplicationDataのパケット番号スペース (セクション 12.3) を持ちます。

17.2.4 Handshakeパケット

Handshakeパケットは、タイプ値0x02のロングヘッダーを使用します。サーバーとクライアントからの暗号化ハンドシェイクメッセージと確認応答を運ぶために使用されます。

17.2.5 Retryパケット

Retryパケットは、タイプ値0x03のロングパケットヘッダーを使用します。サーバーによって作成されたアドレス検証トークンを運びます。リトライを実行したいサーバーによって使用されます (セクション 8.1 を参照)。

17.3 ショートヘッダーパケット

このバージョンのQUICは、ショートパケットヘッダーを使用する単一のパケットタイプを定義します。

17.3.1 1-RTTパケット

1-RTTパケットは、ショートパケットヘッダーを使用します。バージョンと1-RTTキーがネゴシエートされた後に使用されます。

17.4 レイテンシースピンビット

ショートヘッダーのビット0x20に位置するレイテンシースピンビットは、ネットワークパス上の観測ポイントからのパッシブなレイテンシー監視を可能にします。スピンビットはショートパケットヘッダーにのみ存在します。これは、ハンドシェイクを観測することで接続の初期RTTを測定できるためです。したがって、スピンビットは、バージョンネゴシエーションと接続確立が完了した後に利用可能になります。