メインコンテンツまでスキップ

2. HTTP データグラム (HTTP Datagrams)

HTTP データグラム (HTTP Datagrams) は、可能な場合は多重化 (multiplexing) を伴い、HTTP 接続内で双方向かつ潜在的に信頼性のないデータグラムを伝送するための規約です。すべての HTTP データグラムは HTTP リクエストに関連付けられています。

HTTP データグラムが HTTP/3 接続で伝送される場合、QUIC DATAGRAM フレームを使用して、逆多重化 (demultiplexing) と信頼性のない配信を提供できます (セクション 2.1 を参照)。HTTP データグラムに対する QUIC DATAGRAM フレームの使用のネゴシエーションは、HTTP/3 設定の交換を介して実現されます (セクション 2.1.1 を参照)。

HTTP/2 上で実行される場合、逆多重化は HTTP/2 フレーミング層によって提供されますが、信頼性のない配信は利用できません。HTTP データグラムは、カプセルプロトコル (Capsule Protocol) を使用してネゴシエートおよび伝送されます (セクション 3.5 を参照)。

HTTP/1.x 上で実行される場合、リクエストは接続内で厳密にシリアル化されます。したがって、逆多重化は利用できません。信頼性のない配信も同様に利用できません。HTTP データグラムは、カプセルプロトコルを使用してネゴシエートおよび伝送されます (セクション 3.5 を参照)。

HTTP データグラムは、それらを明示的にサポートする HTTP リクエストとの関連付けでのみ送信しなければなりません (MUST)。例えば、既存の HTTP メソッド GET および POST は、関連付けられた HTTP データグラムのセマンティクスを定義していません。したがって、GET または POST リクエストストリームに関連付けられた HTTP データグラムは送信できません。

HTTP データグラムが受信され、それが HTTP データグラムの既知のセマンティクスを持たないリクエストに関連付けられている場合、受信者はリクエストを終了しなければなりません (MUST)。HTTP/3 が使用されている場合、リクエストストリームは H3_DATAGRAM_ERROR (0x33) で中止されなければなりません (MUST)。HTTP 拡張機能は、ネゴシエーションメカニズムと HTTP データグラムのセマンティクスを定義することにより、これらの要件を上書きしてもよい (MAY) です。

2.1. HTTP/3 データグラム (HTTP/3 Datagrams)​

HTTP/3 で使用される場合、QUIC DATAGRAM フレームのデータグラムデータ (Datagram Data) フィールドは次の形式を使用します:

HTTP/3 Datagram {
  Quarter Stream ID (i),
  HTTP Datagram Payload (..),
}

図 1: HTTP/3 データグラム形式

Quarter Stream ID (クォーターストリーム ID): このデータグラムが関連付けられているクライアント開始双方向ストリームの値を 4 で割った値を含む可変長整数 (variable-length integer) です (4 で割る理由は、HTTP リクエストがクライアント開始双方向ストリーム上で送信され、これらのストリーム ID が 4 で割り切れるためです)。最大の有効な QUIC ストリーム ID 値は 2^62-1 であるため、Quarter Stream ID フィールドの最大の有効な値は 2^60-1 です。より大きな値を含む HTTP/3 データグラムを受信した場合、H3_DATAGRAM_ERROR (0x33) タイプの HTTP/3 接続エラーとして扱わなければなりません (MUST)。

HTTP Datagram Payload (HTTP データグラムペイロード): データグラムのペイロードであり、そのセマンティクスは HTTP データグラムを使用している拡張機能によって定義されます。このフィールドは空でもよい (MAY) ことに注意してください。

Quarter Stream ID フィールドの解析を許可するにはペイロードが短すぎる QUIC DATAGRAM フレームを受信した場合、H3_DATAGRAM_ERROR (0x33) タイプの HTTP/3 接続エラーとして扱わなければなりません (MUST)。

対応するストリームの送信側が開いていない限り、HTTP/3 データグラムを送信してはなりません (MUST NOT)。対応するストリームの受信側が閉じられた後にデータグラムが受信された場合、受信されたデータグラムは黙って破棄されなければなりません (MUST)。

HTTP/3 データグラムが受信され、その Quarter Stream ID フィールドがまだ作成されていないストリームにマップされる場合、受信者は、そのデータグラムを黙って破棄するか (SHALL)、対応するストリームの作成を待つ間、一時的に (ラウンドトリップのオーダーで) バッファリングするものとします (SHALL)。

HTTP/3 データグラムが受信され、その Quarter Stream ID フィールドが、クライアント開始双方向ストリーム制限により作成できないストリームにマップされる場合、H3_ID_ERROR タイプの HTTP/3 接続エラーとして扱うべきです (SHOULD)。QUIC ストリーム制限が HTTP/3 層に不明である可能性があるため、エラーの生成は必須ではありません。

HTTP/3 データグラムの優先順位付けは、本文書では定義されていません。将来の拡張機能は、データグラムの優先順位付け方法を定義してもよく (MAY)、優先順位付けの設定を通信できるようにするシグナリングを定義してもよい (MAY) です。

2.1.1. SETTINGS_H3_DATAGRAM HTTP/3 設定​

エンドポイントは、SETTINGS_H3_DATAGRAM (0x33) 設定を値 1 で送信することにより、HTTP/3 データグラムを受信する意思があることをピアに示すことができます。

SETTINGS_H3_DATAGRAM 設定の値は 0 または 1 でなければなりません (MUST)。値 0 は、実装が HTTP データグラムを受信する意思がないことを示します。SETTINGS_H3_DATAGRAM 設定が 0 でも 1 でもない値で受信された場合、受信者は H3_SETTINGS_ERROR エラーで接続を終了しなければなりません (MUST)。

SETTINGS_H3_DATAGRAM 設定が値 1 で送信および受信されるまで、QUIC DATAGRAM フレームを送信してはなりません (MUST NOT)。

クライアントが 0-RTT を使用する場合、サーバーの SETTINGS_H3_DATAGRAM 設定の値を保存してもよい (MAY) です。これにより、クライアントは 0-RTT パケットで QUIC DATAGRAM フレームを送信できます。サーバーが 0-RTT データを受け入れることを決定した場合、NewSessionTicket メッセージを送信した接続でクライアントに送信した値以上の SETTINGS_H3_DATAGRAM 設定を送信しなければなりません (MUST)。クライアントが 0-RTT 状態で SETTINGS_H3_DATAGRAM 設定の値を保存する場合、ハンドシェイク中にサーバーから送信された SETTINGS_H3_DATAGRAM 設定の新しい値が保存された値以上であることを検証しなければなりません (MUST)。そうでない場合、クライアントは H3_SETTINGS_ERROR エラーで接続を終了しなければなりません (MUST)。すべての場合において、SETTINGS_H3_DATAGRAM 設定パラメータの最大許容値は 1 です。

HTTP/3 データグラムの受信をサポートする実装は、アプリケーションが HTTP/3 データグラムを使用する意図がない場合でも、常に SETTINGS_H3_DATAGRAM 設定を値 1 で送信することが推奨されます (RECOMMENDED)。これは「目立つこと」を避けるのに役立ちます (セクション 4 を参照)。

2.2. カプセルを使用した HTTP データグラム (HTTP Datagrams Using Capsules)​

HTTP/3 データグラムが利用できない、または望ましくない場合、HTTP データグラムはカプセルプロトコル (Capsule Protocol) を使用して送信できます (セクション 3.5 を参照)。

に最終更新