6. Frame Definitions (フレーム定義)

本仕様は、それぞれ一意の8ビットタイプコードで識別される多数のフレームタイプを定義します。各フレームタイプは、接続全体または個々のストリームの確立と管理において、明確な目的を果たします。

特定のフレームタイプの送信は、接続の状態を変更する可能性があります。エンドポイントが接続状態の同期されたビューを維持できない場合、接続内での成功した通信はもはや不可能になります。したがって、エンドポイントが任意のフレームの使用によって状態がどのように影響を受けるかについて共通の理解を持つことが重要です。

6.1. DATA

DATAフレーム（type=0x00）は、ストリームに関連付けられた任意の可変長オクテットシーケンスを伝達します。たとえば、1つ以上のDATAフレームがHTTPリクエストまたはレスポンスメッセージの内容を運ぶために使用されます。

DATAフレームにはパディング (padding) を含めることもできます (MAY)。パディングは、メッセージのサイズを不明瞭にするためにDATAフレームに追加できます。パディングはセキュリティ機能です。セクション10.7を参照してください。

DATA Frame {
  Length (24),
  Type (8) = 0x00,

  Unused Flags (4),
  PADDED Flag (1),
  Unused Flags (2),
  END_STREAM Flag (1),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  Data (..),
  Padding (..2040),
}

図3: DATAフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。DATAフレームには、以下の追加フィールドが含まれます:

Pad Length (パディング長): フレームパディングの長さをオクテット単位で含む8ビットフィールド。このフィールドは条件付きであり、PADDEDフラグが設定されている場合にのみ存在します。

Data (データ): アプリケーションデータ。データの量は、存在する他のフィールドの長さを差し引いた後のフレームペイロードの残りです。

Padding (パディング): アプリケーションセマンティック値を含まないパディングオクテット。送信時にパディングオクテットはゼロに設定しなければなりません (MUST)。受信者はパディングを検証する義務はありませんが、ゼロ以外のパディングをタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱うことができます (MAY)。

DATAフレームは以下のフラグを定義します:

PADDED (0x08): 設定されている場合、PADDEDフラグは、Pad Lengthフィールドとそれが記述するパディングが存在することを示します。

END_STREAM (0x01): 設定されている場合、END_STREAMフラグは、このフレームがエンドポイントが識別されたストリームに対して送信する最後のフレームであることを示します。このフラグを設定すると、ストリームは「half-closed」状態の1つまたは「closed」状態 (セクション5.1) に入ります。

| 注意: すべてのデータを送信した後にストリームの閉鎖を知ったエンドポイントは、 | 長さゼロのDataフィールドとEND_STREAMフラグが設定されたSTREAMフレームを送信 | することでストリームを閉じることができます。これは、エンドポイントがトレーラー | を送信しない場合にのみ可能です。その場合、END_STREAMフラグはHEADERSフレーム | に表示されます。セクション8.1を参照してください。

DATAフレームはストリームに関連付けられていなければなりません (MUST)。Stream Identifierフィールドが0x00のDATAフレームを受信した場合、受信者はタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) で応答しなければなりません (MUST)。

DATAフレームはフロー制御の対象であり、ストリームが「open」または「half-closed (remote)」状態にある場合にのみ送信できます。Pad LengthおよびPaddingフィールド (存在する場合) を含む、DATAフレームペイロード全体がフロー制御に含まれます。ストリームが「open」または「half-closed (local)」状態にないDATAフレームを受信した場合、受信者はタイプSTREAM_CLOSEDのストリームエラー (セクション5.4.2) で応答しなければなりません (MUST)。

パディングオクテットの総数は、Pad Lengthフィールドの値によって決定されます。パディングの長さがフレームペイロードの長さ以上である場合、受信者はこれをタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

| 注意: 値がゼロのPad Lengthフィールドを含めることにより、フレームのサイズを | 1オクテット増やすことができます。

6.2. HEADERS

HEADERSフレーム (type=0x01) は、ストリームを開く (セクション5.1) ために使用され、さらにフィールドブロックフラグメントを運びます。名前にもかかわらず、HEADERSフレームはヘッダーセクションまたはトレーラーセクションを運ぶことができます。HEADERSフレームは、「idle」、「reserved (local)」、「open」、または「half-closed (remote)」状態のストリーム上で送信できます。

HEADERS Frame {
  Length (24),
  Type (8) = 0x01,

  Unused Flags (2),
  PRIORITY Flag (1),
  Unused Flag (1),
  PADDED Flag (1),
  END_HEADERS Flag (1),
  Unused Flag (1),
  END_STREAM Flag (1),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  [Exclusive (1)],
  [Stream Dependency (31)],
  [Weight (8)],
  Field Block Fragment (..),
  Padding (..2040),
}

図4: HEADERSフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。HEADERSフレームペイロードには、以下の追加フィールドがあります:

Pad Length (パディング長): フレームパディングの長さをオクテット単位で含む8ビットフィールド。このフィールドは、PADDEDフラグが設定されている場合にのみ存在します。

Exclusive (排他): 単一ビットフラグ。このフィールドは、PRIORITYフラグが設定されている場合にのみ存在します。HEADERSフレームの優先度シグナルは非推奨です。セクション5.3.2を参照してください。

Stream Dependency (ストリーム依存): 31ビットストリーム識別子。このフィールドは、PRIORITYフラグが設定されている場合にのみ存在します。

Weight (重み): 符号なし8ビット整数。このフィールドは、PRIORITYフラグが設定されている場合にのみ存在します。

Field Block Fragment (フィールドブロックフラグメント): フィールドブロックフラグメント (セクション4.3)。

Padding (パディング): アプリケーションセマンティック値を含まないパディングオクテット。送信時にパディングオクテットはゼロに設定しなければなりません (MUST)。受信者はパディングを検証する義務はありませんが、ゼロ以外のパディングをタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱うことができます (MAY)。

HEADERSフレームは以下のフラグを定義します:

PRIORITY (0x20): 設定されている場合、PRIORITYフラグは、Exclusive、Stream Dependency、およびWeightフィールドが存在することを示します。

PADDED (0x08): 設定されている場合、PADDEDフラグは、Pad Lengthフィールドとそれが記述するパディングが存在することを示します。

END_HEADERS (0x04): 設定されている場合、END_HEADERSフラグは、このフレームが完全なフィールドブロック (セクション4.3) を含み、CONTINUATIONフレームが続かないことを示します。

END_HEADERSフラグが設定されていないHEADERSフレームは、同じストリームの CONTINUATIONフレームが続かなければなりません (MUST)。受信者は、他のタイプの フレームまたは異なるストリーム上のフレームの受信を、タイプPROTOCOL_ERRORの 接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

END_STREAM (0x01): 設定されている場合、END_STREAMフラグは、フィールドブロック (セクション4.3) がエンドポイントが識別されたストリームに対して送信する最後のものであることを示します。

END_STREAMフラグが設定されたHEADERSフレームは、ストリームの終了を示します。 ただし、END_STREAMフラグが設定されたHEADERSフレームの後に、同じストリーム上で CONTINUATIONフレームが続くことができます。論理的には、CONTINUATIONフレームは HEADERSフレームの一部です。

HEADERSフレームのフレームペイロードには、フィールドブロックフラグメント (セクション4.3) が含まれます。HEADERSフレームに収まらないフィールドブロックは、CONTINUATIONフレーム (セクション6.10) で継続されます。

HEADERSフレームはストリームに関連付けられていなければなりません (MUST)。Stream Identifierフィールドが0x00のHEADERSフレームを受信した場合、受信者はタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) で応答しなければなりません (MUST)。

HEADERSフレームは、セクション4.3で説明されているように接続状態を変更します。

パディングオクテットの総数は、Pad Lengthフィールドの値によって決定されます。パディングの長さがフレームペイロードの長さ以上である場合、受信者はこれをタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

| 注意: 値がゼロのPad Lengthフィールドを含めることにより、フレームのサイズを | 1オクテット増やすことができます。

6.3. PRIORITY

PRIORITYフレーム (type=0x02) は非推奨です。セクション5.3.2を参照してください。PRIORITYフレームは、idleまたはclosedストリームを含む任意のストリーム状態で送信できます。

PRIORITY Frame {
  Length (24) = 0x05,
  Type (8) = 0x02,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Exclusive (1),
  Stream Dependency (31),
  Weight (8),
}

図5: PRIORITYフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。PRIORITYフレームのフレームペイロードには、以下の追加フィールドが含まれます:

Exclusive (排他): 単一ビットフラグ。

Stream Dependency (ストリーム依存): 31ビットストリーム識別子。

Weight (重み): 符号なし8ビット整数。

PRIORITYフレームはフラグを定義しません。

PRIORITYフレームは常にストリームを識別します。ストリーム識別子が0x00のPRIORITYフレームを受信した場合、受信者はタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) で応答しなければなりません (MUST)。

PRIORITYフレームの送信または受信は、任意のストリームの状態 (セクション5.1) に影響を与えません。PRIORITYフレームは、「idle」または「closed」を含む任意の状態のストリーム上で送信できます。PRIORITYフレームは、単一のフィールドブロック (セクション4.3) を構成する連続したフレーム間で送信できません。

長さが5オクテット以外のPRIORITYフレームは、タイプFRAME_SIZE_ERRORのストリームエラー (セクション5.4.2) として扱わなければなりません (MUST)。

6.4. RST_STREAM

RST_STREAMフレーム (type=0x03) は、ストリームの即時終了を可能にします。RST_STREAMは、ストリームのキャンセルを要求するため、またはエラー条件が発生したことを示すために送信されます。

RST_STREAM Frame {
  Length (24) = 0x04,
  Type (8) = 0x03,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Error Code (32),
}

図6: RST_STREAMフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。さらに、RST_STREAMフレームには、エラーコード (セクション7) を識別する単一の符号なし32ビット整数が含まれます。エラーコードは、ストリームが終了される理由を示します。

RST_STREAMフレームはフラグを定義しません。

RST_STREAMフレームは、参照されたストリームを完全に終了し、「closed」状態に入るようにします。ストリーム上でRST_STREAMを受信した後、受信者はPRIORITYを除いて、そのストリームに対して追加のフレームを送信してはなりません (MUST NOT)。ただし、RST_STREAMを送信した後、送信エンドポイントは、RST_STREAMの到着前にピアによって送信された可能性のある、ストリーム上で送信された追加のフレームを受信して処理する準備をしなければなりません (MUST)。

RST_STREAMフレームはストリームに関連付けられていなければなりません (MUST)。ストリーム識別子が0x00のRST_STREAMフレームを受信した場合、受信者はこれをタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

「idle」状態のストリームに対してRST_STREAMフレームを送信してはなりません (MUST NOT)。アイドルストリームを識別するRST_STREAMフレームを受信した場合、受信者はこれをタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

長さが4オクテット以外のRST_STREAMフレームは、タイプFRAME_SIZE_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

6.5. SETTINGS

SETTINGSフレーム (type=0x04) は、エンドポイントが通信する方法に影響を与える構成パラメータ、たとえばピアの動作に関する設定や制約を伝達します。SETTINGSフレームは、これらの設定の受信を確認するためにも使用されます。個別に、SETTINGSフレームからの構成パラメータは「設定 (setting)」と呼ばれます。

設定は交渉されません。それらは、受信ピアによって使用される送信ピアの特性を記述します。各ピアは、同じ設定に対して異なる値を通知できます。たとえば、クライアントは高い初期フロー制御ウィンドウを設定する可能性がありますが、サーバーはリソースを節約するために低い値を設定する可能性があります。

SETTINGSフレームは、接続の開始時に両方のエンドポイントによって送信されなければならず (MUST)、接続の存続期間中にいずれかのエンドポイントによっていつでも送信できます (MAY)。実装は、この仕様で定義されているすべての設定をサポートしなければなりません (MUST)。

SETTINGSフレームの各パラメータは、そのパラメータの既存の値を置き換えます。設定は、表示される順序で処理され、SETTINGSフレームの受信者は、各設定の現在の値以外の状態を維持する必要はありません。したがって、SETTINGSパラメータの値は、受信者が見る最後の値です。

SETTINGSフレームは、受信ピアによって確認されます。これを可能にするために、SETTINGSフレームはACKフラグを定義します:

ACK (0x01): 設定されている場合、ACKフラグは、このフレームがピアのSETTINGSフレームの受信と適用を確認することを示します。このビットが設定されている場合、SETTINGSフレームのフレームペイロードは空でなければなりません (MUST)。ACKフラグが設定され、長さフィールド値が0以外のSETTINGSフレームを受信することは、タイプFRAME_SIZE_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。詳細については、セクション6.5.3 (「設定同期」) を参照してください。

SETTINGSフレームは常に接続に適用され、単一のストリームには適用されません。SETTINGSフレームのストリーム識別子はゼロ (0x00) でなければなりません (MUST)。エンドポイントがStream Identifierフィールドが0x00以外のSETTINGSフレームを受信した場合、エンドポイントはタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) で応答しなければなりません (MUST)。

SETTINGSフレームは接続状態に影響を与えます。形式が正しくないまたは不完全なSETTINGSフレームは、タイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

長さが6オクテットの倍数でないSETTINGSフレームは、タイプFRAME_SIZE_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

6.5.1. SETTINGS Format (SETTINGS形式)

SETTINGSフレームのフレームペイロードは、それぞれ符号なし16ビット設定識別子と符号なし32ビット値で構成される、ゼロ個以上の設定で構成されます。

SETTINGS Frame {
  Length (24),
  Type (8) = 0x04,

  Unused Flags (7),
  ACK Flag (1),

  Reserved (1),
  Stream Identifier (31) = 0,

  Setting (48) ...,
}

Setting {
  Identifier (16),
  Value (32),
}

図7: SETTINGSフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。SETTINGSフレームのフレームペイロードには、任意の数のSettingフィールドが含まれ、それぞれが以下で構成されます:

Identifier (識別子): 16ビット設定識別子。セクション6.5.2を参照してください。

Value (値): 設定の32ビット値。

6.5.2. Defined Settings (定義された設定)

以下の設定が定義されています:

SETTINGS_HEADER_TABLE_SIZE (0x01): この設定により、送信者は、フィールドブロックをデコードするために使用される圧縮テーブルの最大サイズをオクテット単位でリモートエンドポイントに通知できます。エンコーダは、フィールドブロック内の圧縮形式に固有のシグナリングを使用して ([COMPRESSION]を参照)、この値以下の任意のサイズを選択できます。初期値は4,096オクテットです。

SETTINGS_ENABLE_PUSH (0x02): この設定は、サーバープッシュを有効または無効にするために使用できます。サーバーは、このパラメータが0の値に設定されている場合、PUSH_PROMISEフレームを送信してはなりません (MUST NOT)。セクション8.4を参照してください。このパラメータを0に設定し、確認を受けたクライアントは、PUSH_PROMISEフレームの受信をタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

SETTINGS_ENABLE_PUSHの初期値は1です。クライアントの場合、この値は、 PUSH_PROMISEフレームを受信する意思があることを示します。サーバーの場合、 この初期値は効果がなく、値0と同等です。0または1以外の値は、タイプ PROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

サーバーは、この値を明示的に1に設定してはなりません (MUST NOT)。サーバーは、 SETTINGSフレームを送信するときにこの設定を省略することを選択できます (MAY) が、 サーバーが値を含める場合、それは0でなければなりません (MUST)。クライアントは、 SETTINGS_ENABLE_PUSHが1に設定されたSETTINGSフレームの受信を、タイプ PROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

SETTINGS_MAX_CONCURRENT_STREAMS (0x03): この設定は、送信者が許可する最大同時ストリーム数を示します。この制限は方向性があります。送信者が受信者に作成を許可するストリームの数に適用されます。最初は、この値に制限はありません。並列性を不必要に制限しないように、この値は100以上であることが推奨されます。

SETTINGS_MAX_CONCURRENT_STREAMSの値0は、エンドポイントによって特別に扱われる べきではありません (SHOULD NOT)。ゼロ値は新しいストリームの作成を防ぎますが、 これはアクティブなストリームで使い果たされた任意の制限でも発生する可能性が あります。サーバーは、短期間のみゼロ値を設定すべきです (SHOULD)。サーバーが リクエストを受け入れたくない場合、接続を閉じる方がより適切です。

SETTINGS_INITIAL_WINDOW_SIZE (0x04): この設定は、ストリームレベルのフロー制御のための送信者の初期ウィンドウサイズ (オクテット単位) を示します。初期値は2^16-1 (65,535) オクテットです。

この設定は、すべてのストリームのウィンドウサイズに影響します (セクション6.9.2を参照)。

最大フロー制御ウィンドウサイズ2^31-1を超える値は、タイプFLOW_CONTROL_ERRORの 接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

SETTINGS_MAX_FRAME_SIZE (0x05): この設定は、送信者が受信する意思のある最大フレームペイロードのサイズをオクテット単位で示します。

初期値は2^14 (16,384) オクテットです。エンドポイントによって通知される値は、 この初期値と最大許容フレームサイズ (2^24-1または16,777,215オクテット) の間 (両端を含む) でなければなりません (MUST)。この範囲外の値は、タイプ PROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

SETTINGS_MAX_HEADER_LIST_SIZE (0x06): この助言的設定は、送信者が受け入れる準備ができている最大フィールドセクションサイズをオクテット単位でピアに通知します。値は、名前と値の長さ (オクテット単位) に各フィールド行に対して32オクテットのオーバーヘッドを加えた、フィールド行の非圧縮サイズに基づいています。

任意の特定のリクエストに対して、通知された値よりも低い制限が適用される場合が あります (MAY)。この設定の初期値は無制限です。

未知またはサポートされていない識別子を含むSETTINGSフレームを受信したエンドポイントは、その設定を無視しなければなりません (MUST)。

6.5.3. Settings Synchronization (設定同期)

SETTINGSのほとんどの値は、ピアが変更されたパラメータ値を受信して適用したタイミングの理解から恩恵を受けるか、それを必要とします。このような同期時点を提供するために、ACKフラグが設定されていないSETTINGSフレームの受信者は、受信後できるだけ早く更新された設定を適用しなければなりません (MUST)。SETTINGSフレームは、受信された順序で確認されます。

SETTINGSフレームの値は、表示される順序で処理されなければならず (MUST)、値間で他のフレーム処理は行われません。サポートされていない設定は無視されなければなりません (MUST)。すべての値が処理されたら、受信者は直ちにACKフラグが設定されたSETTINGSフレームを発行しなければなりません (MUST)。ACKフラグが設定されたSETTINGSフレームを受信すると、変更された設定の送信者は、最も古い未確認のSETTINGSフレームからの値が適用されたことを信頼できます。

SETTINGSフレームの送信者が妥当な時間内に確認を受信しない場合、タイプSETTINGS_TIMEOUTの接続エラー (セクション5.4.1) を発行できます (MAY)。タイムアウトを設定する際には、ピアでの処理遅延に対してある程度の余裕を持たせる必要があります。エンドポイント間のラウンドトリップ時間のみに基づくタイムアウトは、誤ったエラーを引き起こす可能性があります。

6.6. PUSH_PROMISE

PUSH_PROMISEフレーム (type=0x05) は、送信者が開始する予定のストリームをピアエンドポイントに事前に通知するために使用されます。PUSH_PROMISEフレームには、エンドポイントが作成する予定のストリームの符号なし31ビット識別子と、ストリームの追加コンテキストを提供するフィールドセクションが含まれます。セクション8.4には、PUSH_PROMISEフレームの使用に関する詳細な説明が含まれています。

PUSH_PROMISE Frame {
  Length (24),
  Type (8) = 0x05,

  Unused Flags (4),
  PADDED Flag (1),
  END_HEADERS Flag (1),
  Unused Flags (2),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  Reserved (1),
  Promised Stream ID (31),
  Field Block Fragment (..),
  Padding (..2040),
}

図8: PUSH_PROMISEフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。PUSH_PROMISEフレームペイロードには、以下の追加フィールドがあります:

Pad Length (パディング長): フレームパディングの長さをオクテット単位で含む8ビットフィールド。このフィールドは、PADDEDフラグが設定されている場合にのみ存在します。

Promised Stream ID (約束されたストリームID): PUSH_PROMISEによって予約されるストリームを識別する符号なし31ビット整数。約束されたストリーム識別子は、送信者によって送信される次のストリームの有効な選択でなければなりません (MUST) (セクション5.1.1の「新しいストリーム識別子」を参照)。

Field Block Fragment (フィールドブロックフラグメント): リクエスト制御データとヘッダーセクションを含むフィールドブロックフラグメント (セクション4.3)。

Padding (パディング): アプリケーションセマンティック値を含まないパディングオクテット。送信時にパディングオクテットはゼロに設定しなければなりません (MUST)。受信者はパディングを検証する義務はありませんが、ゼロ以外のパディングをタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱うことができます (MAY)。

PUSH_PROMISEフレームは以下のフラグを定義します:

PADDED (0x08): 設定されている場合、PADDEDフラグは、Pad Lengthフィールドとそれが記述するパディングが存在することを示します。

END_HEADERS (0x04): 設定されている場合、END_HEADERSフラグは、このフレームが完全なフィールドブロック (セクション4.3) を含み、CONTINUATIONフレームが続かないことを示します。

END_HEADERSフラグが設定されていないPUSH_PROMISEフレームは、同じストリームの CONTINUATIONフレームが続かなければなりません (MUST)。受信者は、他のタイプの フレームまたは異なるストリーム上のフレームの受信を、タイプPROTOCOL_ERRORの 接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

PUSH_PROMISEフレームは、「open」または「half-closed (remote)」状態にあるピアが開始したストリーム上でのみ送信しなければなりません (MUST)。PUSH_PROMISEフレームのストリーム識別子は、それが関連付けられているストリームを示します。Stream Identifierフィールドが値0x00を指定する場合、受信者はタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) で応答しなければなりません (MUST)。

約束されたストリームは、約束された順序で使用される必要はありません。PUSH_PROMISEは、後で使用するためにストリーム識別子を予約するだけです。

ピアエンドポイントのSETTINGS_ENABLE_PUSH設定が0に設定されている場合、PUSH_PROMISEを送信してはなりません (MUST NOT)。この設定を設定し、確認を受信したエンドポイントは、PUSH_PROMISEフレームの受信をタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

PUSH_PROMISEフレームの受信者は、PUSH_PROMISEの送信者に約束されたストリーム識別子を参照するRST_STREAMを返すことにより、約束されたストリームを拒否することを選択できます。

PUSH_PROMISEフレームは、2つの方法で接続状態を変更します。まず、フィールドブロック (セクション4.3) の包含により、フィールドセクション圧縮のために維持される状態が変更される可能性があります。次に、PUSH_PROMISEは後で使用するためにストリームも予約し、約束されたストリームが「reserved (local)」または「reserved (remote)」状態に入るようにします。送信者は、そのストリームが「open」または「half-closed (remote)」でない限り、ストリーム上でPUSH_PROMISEを送信してはなりません (MUST NOT)。送信者は、約束されたストリームが新しいストリーム識別子の有効な選択である (セクション5.1.1) ことを確認しなければなりません (MUST) (つまり、約束されたストリームは「idle」状態でなければなりません (MUST))。

PUSH_PROMISEはストリームを予約するため、PUSH_PROMISEフレームを無視すると、ストリーム状態が不確定になります。受信者は、「open」でも「half-closed (local)」でもないストリーム上でPUSH_PROMISEを受信することを、タイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。ただし、関連するストリーム上でRST_STREAMを送信したエンドポイントは、RST_STREAMフレームが受信されて処理される前に作成された可能性のあるPUSH_PROMISEフレームを処理しなければなりません (MUST)。

受信者は、不正なストリーム識別子 (セクション5.1.1) を約束するPUSH_PROMISEの受信を、タイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。不正なストリーム識別子は、現在「idle」状態にないストリームの識別子であることに注意してください。

パディングオクテットの総数は、Pad Lengthフィールドの値によって決定されます。パディングの長さがフレームペイロードの長さ以上である場合、受信者はこれをタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

| 注意: 値がゼロのPad Lengthフィールドを含めることにより、フレームのサイズを | 1オクテット増やすことができます。

6.7. PING

PINGフレーム (type=0x06) は、送信者からの最小ラウンドトリップ時間を測定し、アイドル接続がまだ機能しているかどうかを判断するためのメカニズムです。PINGフレームは、任意のエンドポイントから送信できます。

PING Frame {
  Length (24) = 0x08,
  Type (8) = 0x06,

  Unused Flags (7),
  ACK Flag (1),

  Reserved (1),
  Stream Identifier (31) = 0,

  Opaque Data (64),
}

図9: PINGフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。

フレームヘッダーに加えて、PINGフレームには、フレームペイロードに8オクテットの不透明データが含まれていなければなりません (MUST)。送信者は、選択した任意の値を含めることができ、それらのオクテットを任意の方法で使用できます。

ACKフラグを含まないPINGフレームの受信者は、同一のフレームペイロードで、ACKフラグが設定されたPINGフレームを応答として送信しなければなりません (MUST)。PING応答は、他の任意のフレームよりも高い優先度を与えられるべきです (SHOULD)。

PINGフレームは以下のフラグを定義します:

ACK (0x01): 設定されている場合、ACKフラグは、このPINGフレームがPING応答であることを示します。エンドポイントは、PING応答でこのフラグを設定しなければなりません (MUST)。エンドポイントは、このフラグを含むPINGフレームに応答してはなりません (MUST NOT)。

PINGフレームは、個々のストリームに関連付けられていません。Stream Identifierフィールド値が0x00以外のPINGフレームを受信した場合、受信者はタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) で応答しなければなりません (MUST)。

長さフィールド値が8以外のPINGフレームを受信することは、タイプFRAME_SIZE_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

6.8. GOAWAY

GOAWAYフレーム (type=0x07) は、接続のシャットダウンを開始するため、または深刻なエラー条件を通知するために使用されます。GOAWAYにより、エンドポイントは、以前に確立されたストリームの処理を完了しながら、新しいストリームの受け入れを優雅に停止できます。これにより、サーバーメンテナンスなどの管理操作が可能になります。

エンドポイントが新しいストリームを開始することとリモートピアがGOAWAYフレームを送信することの間には、固有の競合状態があります。このケースに対処するために、GOAWAYには、この接続で送信エンドポイントで処理された、または処理される可能性のある最後のピアが開始したストリームのストリーム識別子が含まれます。たとえば、サーバーがGOAWAYフレームを送信する場合、識別されたストリームは、クライアントによって開始された最も高い番号のストリームです。

GOAWAYが送信されると、ストリームに含まれる最後のストリーム識別子よりも高い識別子を持つ場合、送信者は、受信者によって開始されたストリーム上で送信されたフレームを無視します。GOAWAYフレームの受信者は、接続上で追加のストリームを開いてはなりませんが (MUST NOT)、新しいストリームのために新しい接続を確立できます。

GOAWAYの受信者が、GOAWAYフレームに示されているものよりも高いストリーム識別子を持つストリーム上でデータを送信した場合、それらのストリームは処理されない、または処理されません。GOAWAYフレームの受信者は、ストリームがまったく作成されなかったかのようにストリームを扱うことができ、それによりそれらのストリームが新しい接続で後で再試行されることを可能にします。

エンドポイントは、接続を閉じる前に常にGOAWAYフレームを送信すべきであり (SHOULD)、リモートピアがストリームが部分的に処理されたかどうかを知ることができるようにします。たとえば、HTTPクライアントがサーバーが接続を閉じるのと同時にPOSTを送信する場合、サーバーがどのストリームに対してアクションを実行した可能性があるかを示すGOAWAYフレームを送信しない場合、クライアントはサーバーがそのPOSTリクエストの処理を開始したかどうかを知ることができません。

エンドポイントは、行儀の悪いピアに対してGOAWAYを送信せずに接続を閉じることを選択する場合があります。

GOAWAYフレームは、接続の閉鎖の直前に来ない場合があります。接続の使用がなくなったGOAWAYの受信者は、接続を終了する前にGOAWAYフレームを送信すべきです (SHOULD)。

GOAWAY Frame {
  Length (24),
  Type (8) = 0x07,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31) = 0,

  Reserved (1),
  Last-Stream-ID (31),
  Error Code (32),
  Additional Debug Data (..),
}

図10: GOAWAYフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。

GOAWAYフレームはフラグを定義しません。

GOAWAYフレームは、特定のストリームではなく、接続に適用されます。エンドポイントは、ストリーム識別子が0x00以外のGOAWAYフレームを、タイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

GOAWAYフレームの最後のストリーム識別子には、GOAWAYフレームの送信者が何らかのアクションを実行した、または実行する可能性がある最も高い番号のストリーム識別子が含まれます。識別されたストリームまでのすべてのストリームは、何らかの方法で処理された可能性があります。ストリームが処理されなかった場合、最後のストリーム識別子は0に設定できます。

| 注意: このコンテキストでは、「処理された」とは、ストリームからの一部のデータが、 | その結果として何らかのアクションを実行した可能性のあるより高い層のソフトウェアに | 渡されたことを意味します。

接続がGOAWAYフレームなしで終了した場合、最後のストリーム識別子は事実上、可能な最高のストリーム識別子です。

接続が閉じられる前に完全に閉じられなかった、より低いまたは等しい番号の識別子を持つストリーム上では、HTTP GET、PUT、またはDELETEのような冪等アクションを除いて、リクエスト、トランザクション、または任意のプロトコルアクティビティを再試行することはできません。より高い番号のストリームを使用する任意のプロトコルアクティビティは、新しい接続を使用して安全に再試行できます。

最後のストリーム識別子以下の番号のストリーム上のアクティビティは、まだ正常に完了する可能性があります。GOAWAYフレームの送信者は、GOAWAYフレームを送信することにより接続を優雅にシャットダウンし、進行中のすべてのストリームが完了するまで接続を「open」状態に維持する場合があります。

状況が変化した場合、エンドポイントは複数のGOAWAYフレームを送信できます (MAY)。たとえば、優雅なシャットダウン中にNO_ERRORでGOAWAYを送信するエンドポイントは、その後、接続の即時終了を必要とする条件に遭遇する可能性があります。最後に受信したGOAWAYフレームからの最後のストリーム識別子は、どのストリームに対してアクションが実行された可能性があるかを示します。エンドポイントは、最後のストリーム識別子で送信する値を増やしてはなりません (MUST NOT)。ピアがすでに別の接続で未処理のリクエストを再試行している可能性があるためです。

リクエストを再試行できないクライアントは、サーバーが接続を閉じたときに転送中のすべてのリクエストを失います。これは、HTTP/2を使用してクライアントにサービスを提供していない可能性のある仲介者にとって特に当てはまります。接続を優雅にシャットダウンしようとしているサーバーは、最後のストリーム識別子を2^31-1に設定し、NO_ERRORコードを使用して初期GOAWAYフレームを送信すべきです (SHOULD)。これは、シャットダウンが差し迫っており、さらなるリクエストの開始が禁止されていることをクライアントに通知します。転送中のストリーム作成の時間 (少なくとも1ラウンドトリップ時間) を許可した後、サーバーは、更新された最後のストリーム識別子を使用して別のGOAWAYフレームを送信できます (MAY)。これにより、リクエストを失うことなく接続をクリーンにシャットダウンできることが保証されます。

GOAWAYフレームを送信した後、送信者は、識別された最後のストリームよりも高い識別子を持つ受信者によって開始されたストリームのフレームを破棄できます。ただし、接続状態を変更する任意のフレームを完全に無視することはできません。たとえば、HEADERS、PUSH_PROMISE、およびCONTINUATIONフレームは、フィールドセクション圧縮のために維持される状態が一貫していることを保証するために最小限処理されなければなりません (MUST) (セクション4.3を参照)。同様に、DATAフレームは接続フロー制御ウィンドウに対してカウントされなければなりません (MUST)。これらのフレームの処理に失敗すると、フロー制御またはフィールドセクション圧縮状態が非同期になる可能性があります。

GOAWAYフレームには、接続を閉じる理由を含む32ビットエラーコード (セクション7) も含まれます。

エンドポイントは、任意のGOAWAYフレームのフレームペイロードに不透明データを追加できます (MAY)。追加のデバッグデータは診断目的のみを目的としており、セマンティック値を持ちません。デバッグ情報には、セキュリティまたはプライバシーに敏感なデータが含まれる可能性があります。ログに記録された、またはその他の方法で永続的に保存されたデバッグデータは、不正アクセスを防ぐための適切な保護措置を講じなければなりません (MUST)。

6.9. WINDOW_UPDATE

WINDOW_UPDATEフレーム (type=0x08) は、フロー制御を実装するために使用されます。概要については、セクション5.2を参照してください。

フロー制御は2つのレベルで動作します: 各個別のストリーム上と、接続全体上です。

両方のタイプのフロー制御はホップバイホップ、つまり2つのエンドポイント間のみです。仲介者は、依存接続間でWINDOW_UPDATEフレームを転送しません。ただし、任意の受信者によるデータ転送のスロットリングは、元の送信者に向かってフロー制御情報の伝播を間接的に引き起こす可能性があります。

フロー制御は、フロー制御の対象として識別されるフレームにのみ適用されます。このドキュメントで定義されているフレームタイプのうち、これにはDATAフレームのみが含まれます。フロー制御から免除されているフレームは、受信者がフレームを処理するためのリソースを割り当てることができない場合を除き、受け入れられて処理されなければなりません (MUST)。受信者は、フレームを受け入れることができない場合、タイプFLOW_CONTROL_ERRORのストリームエラー (セクション5.4.2) または接続エラー (セクション5.4.1) で応答できます (MAY)。

WINDOW_UPDATE Frame {
  Length (24) = 0x04,
  Type (8) = 0x08,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Reserved (1),
  Window Size Increment (31),
}

図11: WINDOW_UPDATEフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。WINDOW_UPDATEフレームのフレームペイロードは、1つの予約ビットと、送信者が既存のフロー制御ウィンドウに加えて送信できるオクテット数を示す符号なし31ビット整数です。フロー制御ウィンドウへの増分の法的範囲は、1から2^31-1 (2,147,483,647) オクテットです。

WINDOW_UPDATEフレームはフラグを定義しません。

WINDOW_UPDATEフレームは、ストリームまたは接続全体に固有である場合があります。前者の場合、フレームのストリーム識別子は影響を受けるストリームを示します。後者の場合、値「0」は、接続全体がフレームの対象であることを示します。

受信者は、フロー制御ウィンドウ増分が0のWINDOW_UPDATEフレームの受信を、タイプPROTOCOL_ERRORのストリームエラー (セクション5.4.2) として扱わなければなりません (MUST)。接続フロー制御ウィンドウでのエラーは、接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

WINDOW_UPDATEは、END_STREAMフラグが設定されたフレームを送信したピアによって送信できます。これは、受信者が「half-closed (remote)」または「closed」状態のストリーム上でWINDOW_UPDATEフレームを受信する可能性があることを意味します。受信者は、これをエラーとして扱ってはなりません (MUST NOT) (セクション5.1を参照)。

フロー制御されたフレームを受信する受信者は、受信者がこれを接続エラー (セクション5.4.1) として扱わない限り、接続フロー制御ウィンドウに対するその寄与を常に説明しなければなりません (MUST)。これは、フレームがエラーの場合でも必要です。送信者はフレームをフロー制御ウィンドウに対してカウントしますが、受信者がそうしない場合、送信者と受信者のフロー制御ウィンドウが異なる可能性があります。

長さが4オクテット以外のWINDOW_UPDATEフレームは、タイプFRAME_SIZE_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

6.9.1. The Flow-Control Window (フロー制御ウィンドウ)

HTTP/2のフロー制御は、各送信者がすべてのストリーム上で保持するウィンドウを使用して実装されます。フロー制御ウィンドウは、送信者が送信を許可されているデータのオクテット数を示す単純な整数値です。したがって、そのサイズは受信者のバッファリング容量の尺度です。

2つのフロー制御ウィンドウが適用されます: ストリームフロー制御ウィンドウと接続フロー制御ウィンドウ。送信者は、受信者によって通知されたいずれかのフロー制御ウィンドウで使用可能なスペースを超える長さのフロー制御されたフレームを送信してはなりません (MUST NOT)。END_STREAMフラグが設定された長さゼロのフレーム (つまり、空のDATAフレーム) は、いずれかのフロー制御ウィンドウで使用可能なスペースがない場合に送信できます (MAY)。

フロー制御計算では、9オクテットのフレームヘッダーはカウントされません。

フロー制御されたフレームを送信した後、送信者は、送信されたフレームの長さだけ両方のウィンドウで使用可能なスペースを減らします。

フレームの受信者は、データを消費してフロー制御ウィンドウのスペースを解放するときにWINDOW_UPDATEフレームを送信します。ストリームレベルおよび接続レベルのフロー制御ウィンドウに対して、個別のWINDOW_UPDATEフレームが送信されます。受信者は、非常に小さな増分でWINDOW_UPDATEフレームを送信しないようにメカニズムを配置することをお勧めします。[RFC1122]のセクション4.2.3.3を参照してください。

WINDOW_UPDATEフレームを受信した送信者は、フレームで指定された量だけ対応するウィンドウを更新します。

送信者は、フロー制御ウィンドウが2^31-1オクテットを超えることを許可してはなりません (MUST NOT)。送信者が、フロー制御ウィンドウをこの最大値を超えさせるWINDOW_UPDATEを受信した場合、適切にストリームまたは接続を終了しなければなりません (MUST)。ストリームの場合、送信者はエラーコードFLOW_CONTROL_ERRORを使用してRST_STREAMを送信します。接続の場合、エラーコードFLOW_CONTROL_ERRORを使用してGOAWAYフレームが送信されます。

送信者からのフロー制御されたフレームと受信者からのWINDOW_UPDATEフレームは、互いに完全に非同期です。このプロパティにより、受信者は、ストリームが停止するのを防ぐために、送信者によって保持されるウィンドウサイズを積極的に更新できます。

6.9.2. Initial Flow-Control Window Size (初期フロー制御ウィンドウサイズ)

HTTP/2接続が最初に確立されたとき、新しいストリームは初期フロー制御ウィンドウサイズ65,535オクテットで作成されます。接続フロー制御ウィンドウも65,535オクテットです。両方のエンドポイントは、SETTINGSフレームにSETTINGS_INITIAL_WINDOW_SIZEの値を含めることにより、新しいストリームの初期ウィンドウサイズを調整できます。接続フロー制御ウィンドウは、WINDOW_UPDATEフレームを使用してのみ変更できます。

SETTINGS_INITIAL_WINDOW_SIZEの値を設定するSETTINGSフレームを受信する前に、エンドポイントは、フロー制御されたフレームを送信するときにデフォルトの初期ウィンドウサイズのみを使用できます。同様に、WINDOW_UPDATEフレームを受信するまで、接続フロー制御ウィンドウはデフォルトの初期ウィンドウサイズに基づいて設定されます。

まだアクティブでないストリームのフロー制御ウィンドウを変更することに加えて、SETTINGSフレームは、アクティブなフロー制御ウィンドウを持つストリーム (つまり、「open」または「half-closed (remote)」状態のストリーム) の初期フロー制御ウィンドウサイズを変更できます。SETTINGS_INITIAL_WINDOW_SIZEの値が変化すると、受信者は、維持しているすべてのストリームフロー制御ウィンドウのサイズを、新しい値と古い値の差によって調整しなければなりません (MUST)。

SETTINGS_INITIAL_WINDOW_SIZEの変更により、フロー制御ウィンドウで使用可能なスペースが負になる可能性があります。送信者は、負のフロー制御ウィンドウを追跡しなければならず (MUST)、フロー制御ウィンドウを正にするWINDOW_UPDATEフレームを受信するまで、新しいフロー制御されたフレームを送信してはなりません (MUST NOT)。

たとえば、クライアントが接続確立時に直ちに60 KBを送信し、サーバーが初期ウィンドウサイズを16 KBに設定した場合、クライアントはSETTINGSフレームの受信時に使用可能なフロー制御ウィンドウを-44 KBに再計算します。クライアントは、WINDOW_UPDATEフレームがウィンドウを正に戻すまで、負のフロー制御ウィンドウを保持し、その後クライアントは送信を再開できます。

SETTINGSフレームは、接続フロー制御ウィンドウを変更できません。

エンドポイントは、任意のフロー制御ウィンドウを最大サイズを超えさせるSETTINGS_INITIAL_WINDOW_SIZEの変更を、タイプFLOW_CONTROL_ERRORの接続エラー (セクション5.4.1) として扱わなければなりません (MUST)。

6.9.3. Reducing the Stream Window Size (ストリームウィンドウサイズの縮小)

現在のサイズよりも小さいフロー制御ウィンドウを使用したい受信者は、新しいSETTINGSフレームを送信できます。ただし、受信者は、送信者がSETTINGSフレームを処理する前に下限を超えるデータを送信する可能性があるため、このウィンドウサイズを超えるデータを受信する準備をしなければなりません (MUST)。

初期フロー制御ウィンドウサイズを減らすSETTINGSフレームを送信した後、受信者は、フロー制御制限を超えるストリームの処理を継続できます (MAY)。ストリームの継続を許可しても、受信者はフロー制御ウィンドウのために予約するスペースを直ちに減らすことはできません。これらのストリームの進行も停止する可能性があります。送信者が送信を再開できるようにするには、WINDOW_UPDATEフレームが必要だからです。受信者は、影響を受けるストリームに対して、エラーコードFLOW_CONTROL_ERRORを使用してRST_STREAMを送信することもできます (MAY)。

6.10. CONTINUATION

CONTINUATIONフレーム (type=0x09) は、フィールドブロックフラグメントのシーケンス (セクション4.3) を継続するために使用されます。先行するフレームが同じストリーム上にあり、END_HEADERSフラグが設定されていないHEADERS、PUSH_PROMISE、またはCONTINUATIONフレームである限り、任意の数のCONTINUATIONフレームを送信できます。

CONTINUATION Frame {
  Length (24),
  Type (8) = 0x09,

  Unused Flags (5),
  END_HEADERS Flag (1),
  Unused Flags (2),

  Reserved (1),
  Stream Identifier (31),

  Field Block Fragment (..),
}

図12: CONTINUATIONフレーム形式

Length、Type、Unused Flag(s)、Reserved、およびStream Identifierフィールドはセクション4で説明されています。CONTINUATIONフレームペイロードには、フィールドブロックフラグメント (セクション4.3) が含まれます。

CONTINUATIONフレームは以下のフラグを定義します:

END_HEADERS (0x04): 設定されている場合、END_HEADERSフラグは、このフレームがフィールドブロック (セクション4.3) を終了することを示します。

END_HEADERSフラグが設定されていない場合、このフレームは別のCONTINUATIONフレームが 続かなければなりません (MUST)。受信者は、他のタイプのフレームまたは異なるストリーム 上のフレームの受信を、タイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) として 扱わなければなりません (MUST)。

CONTINUATIONフレームは、セクション4.3で定義されているように接続状態を変更します。

CONTINUATIONフレームはストリームに関連付けられていなければなりません (MUST)。Stream Identifierフィールドが0x00のCONTINUATIONフレームを受信した場合、受信者はタイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) で応答しなければなりません (MUST)。

CONTINUATIONフレームは、END_HEADERSフラグが設定されていないHEADERS、PUSH_PROMISE、またはCONTINUATIONフレームの前になければなりません (MUST)。このルールの違反を観察する受信者は、タイプPROTOCOL_ERRORの接続エラー (セクション5.4.1) で応答しなければなりません (MUST)。

---

第6章完了!