5. HTTP データグラムペイロード形式

HTTP データグラムペイロード形式

HTTP データグラム（[HTTP-DGRAM] のセクション 2 を参照）が UDP プロキシリクエストストリームに関連付けられている場合、HTTP データグラムペイロードフィールドは、[QUIC] のセクション 1.3 の表記法を使用して、図 7 で定義された形式を持つ。HTTP データグラムが QUIC DATAGRAM フレーム [QUIC-DGRAM] を使用してエンコードされる場合、以下で定義される Context ID フィールドは、QUIC DATAGRAM フレームペイロードの開始にある Quarter Stream ID フィールドの直後に続くことに注意すること；[HTTP-DGRAM] のセクション 2.1 を参照。

UDP Proxying HTTP Datagram Payload { Context ID (i), UDP Proxying Payload (..), }

            図 7: UDP プロキシ HTTP データグラム形式

Context ID: Context ID の値を含む可変長整数（[QUIC] のセクション 16 を参照）。不明な Context ID を運ぶ HTTP/3 データグラムが受信された場合、受信者はそのデータグラムを黙ってドロップするか、対応する Context ID の登録を待つ間、一時的に（往復時間のオーダーで）バッファリングしなければならない (SHALL)。 UDP Proxying Payload: データグラムのペイロード。そのセマンティクスは前のフィールドの値に依存する。このフィールドは空でもよいことに注意すること。

UDP パケットは、Context ID フィールドがゼロに設定された HTTP データグラムを使用してエンコードされる。Context ID フィールドがゼロに設定されている場合、UDP プロキシペイロードフィールドには、UDP パケットの変更されていないペイロード（[UDP] ではデータオクテットと呼ばれる）が含まれる。

UDP ヘッダー [UDP] の定義により、65527 バイトを超える UDP ペイロードをエンコードすることはできない。したがって、エンドポイントは、Context ID ゼロを使用して、65527 を超える UDP プロキシペイロードフィールドを持つ HTTP データグラムを送信してはならない (MUST NOT)。UDP プロキシペイロードフィールドが 65527 を超える Context ID ゼロを使用する HTTP データグラムを受信したエンドポイントは、対応するストリームを中止しなければならない (MUST)。UDP プロキシが、基盤となるリンク MTU のために特定の長さの UDP パケットしか送信できないことを知っている場合、UDP プロキシペイロードフィールドがその制限を超える Context ID ゼロを使用する着信 HTTP データグラムを破棄するしかない。破棄された HTTP データグラムが DATAGRAM カプセルによって転送された場合、受信者はカプセルの内容をバッファリングせずにそのカプセルを破棄すべきである (SHOULD)。

UDP プロキシが対応するリクエストを受信する前に HTTP データグラムを受信した場合、その HTTP データグラムを黙ってドロップするか、対応するリクエストを待つ間、一時的に（往復時間のオーダーで）バッファリングしなければならない (SHALL)。

データグラムのバッファリング（リクエストがまだ受信されていないか、Context ID がまだ不明であるため）はリソースを消費することに注意すること。データグラムをバッファリングする受信者は、リソース枯渇のリスクを軽減するために、バッファリング制限を適用すべきである (SHOULD)。たとえば、受信者は、ストリームごと、コンテキストごと、または接続ごとに、バッファリングされたデータグラムの総数またはバッファリングされたデータグラムの累積サイズを制限できる。

クライアントは、UDP プロキシリクエストへのレスポンスを受信する前に、HTTP データグラムでの UDP パケットの送信を楽観的に開始してもよい (MAY)。ただし、実装者は、UDP プロキシがリクエストに失敗で応答した場合、またはプロキシされたパケットがリクエストの前に UDP プロキシによって受信され、UDP プロキシがそれらをバッファリングしないことを選択した場合、そのようなプロキシされたパケットが UDP プロキシによって処理されない可能性があることに注意すべきである。