[2] ストリームstreamは、HTTP/2接続中の独立したフレームの双方向の流れbidirectional flow (列) です >>1, >>3。 一組の要求と応答を送受信するために使います。 ストリームは HTTP/2 で新たに導入された概念です。

[136] 一つの接続内で複数のストリームを使うことにより、 複数の要求を並行して処理できます。

仕様書

プロトコル

[4] HTTP/2接続は、並行して複数のフレームを開くことができます。 つまり複数のストリームのフレームを混在させて送受信できます。 >>3

[5] ストリームは、サーバーとクライアントのどちらからも確立したり閉じたりできますし、 一方だけで使ったり、両方で使ったりできます。 >>3

[7] HTTP/2接続の開始の時点では、ストリームはありません。

[86] ただし理論上は HTTP/1.1 から Upgrade: h2c で HTTP/2 で切り替えた場合は、ストリーム識別子 0x1 が使われた状態となります。

HTTP/2接続参照。

[65] エンドポイントは、各ストリームの次の情報を保持します。

ストリーム識別子 >>3
符号無し31ビット整数。
開始した peer
ストリーム識別子が奇数ならクライアント、 偶数ならサーバーです >>3。
状態
状態遷移図上の状態のいずれかです (>>8)。 closed 状態には付随していくつかのフラグがあります。
親ストリーム
依存性木上の親です。必ず1つ存在します。 依存ストリームの逆方向の関係です。
依存ストリーム群
依存性木上の子の集合です。 0個以上のストリームが含まれます。
重み
親ストリームから本ストリームへの依存性木上の枝に割り当てられた、 優先度を表す値です。
処理開始済み
データをアプリケーション層に伝えたかどうかを表すフラグです。 GOAWAY フレーム送信時に使います。
RST_STREAM タイムスタンプ
RST_STREAM フレーム再送判定に使います。
ストリームフロー制御窓

[6] ストリームにおけるフレームの順序には意味があり、 受信者は受信した順序で処理する必要があります。 >>3

状態

[8] エンドポイントは、ストリームの状態stateを保持します。 >>3

[9] ストリームの状態は、エンドポイントがそれぞれ保持しているもので、 フレームの転送中は peer と異なることがあります。 >>3 また (local) と (remote) のような対となる状態になっていることもあります。

[50] 状態は、フレームの送受信で遷移します。単一のフレームで複数の状態遷移が発生することもあります。

[63] 未知のフレーム型のフレームは無視して捨てなければなりません >>3, >>75。しかし後述の通り、 指定されたフレームの種類以外はエラーとなるとの規定もあります。 どちらの規定が優先されるのかは不明ですが、この両文が RFC では隣に並んでいるので、無視が優先されるとエスパーできます。

[76] 捨てられるフレームも、他の要件には影響することがあります。 ヘッダーリストやフレームを参照。

[144] GOAWAY フレームを受信したら、 その最終ストリーム識別子よりも大きなストリームについて RST_STREAM フレームを受信したものとして処理するべきと思われます。

[66] 次の状態があります。

idle
idle
v
>>
1
->
reserved.local
->
reserved.remote
->
open
->
closed
reserved.local
reserved (local)
->
half.remote
->
closed
reserved.remote
reserved (remote)
>>
4
->
half.local
->
closed
open
open
v
>>
1
->
half.local
->
half.remote
->
closed
half.remote
half-closed (remote)
v
->
closed
half.local
half-closed (local)
>>
4
->
closed
closed
closed
v
>>
2

[89] 状態毎に、送信できるフレーム型の制約があります。

状態DATAHEADERSPRIORITYRST_STREAMSETTINGSPUSH_PROMISEPINGGOAWAYWINDOW_UPDATECONTINUATIONその他
idle×○○××××××××
reserved (local)×○○○×××××××
reserved (remote)××○○××××○××
open○○○○×○××○○×
half-closed (local)××○○××××○△×
half-closed (remote)○○○○×○××○○×
closed××○××××××△×
接続××××○×○○○××

各状態においても更に細かい制約があるかもしれません。

idle

[10] ストリームは、作成されると idle 状態となります >>3。

[11] エンドポイントは、peer と協調せずとも自身でストリームを作成できます >>3。相手に伝わるまでは、一方のみにストリームが存在する状態となります。

[22] 送信できるフレームの種類の制約は明記されていませんが、 HEADERS と PRIORITY しか送信できないと見られます。

[12] 送受信するフレームの種類により、次のような状態遷移があります >>3。

  • [13] HEADERS フレームを送信または受信すると、 open に遷移します。
  • [14] 他のストリームで PUSH_PROMISE フレームを送信し、 その Promised Stream ID で本ストリームが示されていれば、 reserved (local) に遷移します。
  • [15] 他のストリームで PUSH_PROMISE フレームを受信し、 その Promised Stream ID で本ストリームが示されていれば、 reserved (remote) に遷移します。
  • [64] 本ストリームを開始した peer がより大きなストリーム識別子のストリームを使用 (フレームを送受信) したら、 closed に遷移します。

[16] HEADERS と PRIORITY 以外のフレームを受信したら、 接続エラー PROTOCOL_ERROR としなければなりません >>3。

[137] RST_STREAM や WINDOW_UPDATE も接続エラーとなるようです。

[139] 実際には WINDOW_UPDATE を受信したら Firefox はストリームエラー PROTOCOL_ERROR とし、 Chrome は無視するようです。

[142] Firefox も Chrome も RST_STREAM を受信してもエラーとはしないようです。 (closed に遷移しているものと思われます。)

reserved (local)

[17] PUSH_PROMISE フレームで約束すると、 ストリームは reserved (local) 状態となります >>3。

[23] HEADERS, RST_STREAM, PRIORITY 以外を送信してはなりません >>3。

[19] 送受信するフレームの種類により、次のような状態遷移があります >>3。

  • [20] HEADERS フレームを送信すると、 half-closed (remote) に遷移します。
  • [21] RST_STREAM フレームを送信または受信すると、 closed に遷移します。

[24] RST_STREAM, PRIORITY, WINDOW_UPDATE 以外のフレームを受信したら、 接続エラー PROTOCOL_ERROR としなければなりません >>3。

reserved (remote)

[25] reserved (remote) 状態は、ストリームが peer により予約されていることを表します >>3。

[29] RST_STREAM, WINDOW_UPDATE, PRIORITY 以外を送信してはなりません >>3。

[26] 送受信するフレームの種類により、次のような状態遷移があります >>3。

  • [27] HEADERS フレームを受信すると、 half-closed (local) に遷移します。
  • [28] RST_STREAM フレームを送信または受信すると、 closed に遷移します。

[30] HEADERS, RST_STREAM, PRIORITY 以外のフレームを受信したら、 接続エラー PROTOCOL_ERROR としなければなりません >>3。

open

[31] open 状態では、任意のフレームの送受信ができます。

[34] 送信できるフレームの種類の制約はありません >>3。

[32] 本状態に遷移することになったフレームの種類や本状態で送受信するフレームの種類により、次のような状態遷移があります >>3。

  • [33] END_STREAM フラグが設定されたフレームを送信すると、 half-closed (local) 状態に遷移します。
  • [35] END_STREAM フラグが設定されたフレームを受信すると、 half-closed (remote) 状態に遷移します。
  • [36] RST_STREAM フレームを送信または受信すると、 closed に遷移します。

half-closed (local)

[37] half-closed (local) 状態では、メッセージを送信できませんが、受信するかもしれません。

[38] WINDOW_UPDATE, PRIORITY, RST_STREAM 以外のフレームを送信することはできません >>3。

[42] こちらは閉じた (送信しない) 状態ですが、 peer はまだ送信できる状態ですから、 データを受信する準備は継続しなければなりません。 すなわち、 WINDOW_UPDATE フレームを適宜送信する必要があります >>3。[122] 本状態へ遷移させた END_STREAM フラグ付き HEADERS フレームの続きの CONTINUATION フレームを送信することはできます。

[39] 本状態で送受信するフレームの種類により、次のような状態遷移があります >>3。

  • [40] END_STREAM フラグが設定されたフレームを受信すると、 closed 状態に遷移します。
  • [41] RST_STREAM フレームを送信または受信すると、 closed に遷移します。

half-closed (remote)

[43] half-closed (remote) 状態は、 peer がフレームの送信をもう行わないストリームを表します >>3。

[46] 任意のフレームを送信できます >>3。

[44] この状態になると、受信者フロー制御窓を維持する義務はありません >>3。

[47] 本状態で送受信するフレームの種類により、次のような状態遷移があります >>3。

  • [48] END_STREAM フラグが設定されたフレームを送信すると、 closed 状態に遷移します。
  • [49] RST_STREAM フレームを送信または受信すると、 closed に遷移します。

[45] WINDOW_UPDATE >>3, >>134, RST_STREAM, PRIORITY 以外のフレームを受信したら、 ストリームエラー STREAM_CLOSED としなければなりません >>3。

[120] ただし、本状態に遷移させた HEADERS フレームに引き続き CONTINUATION フレームを受信する場合は除きます。

closed

[51] closed 状態は、最終的な状態です >>3。

[93] この状態での動作は、次の各フラグによって変わります。

  • [94] RST_STREAM 送信 (タイムスタンプ)
  • [95] END_STREAM 送信 (タイムスタンプ)
  • [98] RST_STREAM 受信済み
  • [105] END_STREAM 受信済み

[96] この状態に遷移したら、次のようにします。

  1. [90] RST_STREAM フレームを自身が送信したことにより遷移した場合は、「RST_STREAM 送信」タイムスタンプを現在時刻に設定します。
  2. [91] END_STREAM フラグが設定されたフレームを自身が送信したことにより遷移した場合は、「END_STREAM 送信」タイムスタンプを現在時刻に設定します。
  3. [97] RST_STREAM フレームを受信したことにより遷移した場合は、 「RST_STREAM 受信済み」フラグを設定します。
  4. [104] END_STREAM フラグが設定されたフレームを受信したことにより遷移した場合は、 「END_STREAM 受信済み」フラグを設定します。

[99] この状態でフレームを受信したら、次のようにします。

  1. [106] 「END_STREAM 受信済み」フラグが設定されていれば、
    1. [54] 接続エラー STREAM_CLOSED としなければなりません >>3。 停止します。
  2. [102] 「RST_STREAM 受信済み」フラグが設定されていれば、
    1. [103] PRIORITY 以外のフレームなら、
      1. [53] ストリームエラー STREAM_CLOSED としなければなりません >>3。停止します。
  3. [100] RST_STREAM フレームなら、
    1. [101] 「RST_STREAM 受信済み」フラグを設定します。
  4. [107] DATA フレームか HEADERS フレームなら、
    1. [108] END_STREAM フラグが設定されていれば、
      1. [109] 「END_STREAM 受信済み」フラグを設定します。
  5. [112] 「END_STREAM 送信」タイムスタンプが設定されていれば、
    1. [114] WINDOW_UPDATE フレーム >>3, >>134 か RST_STREAM フレームなら、
      1. [92] 十分な時間が経過していれば、 接続エラー PROTOCOL_ERROR としても構いません >>3。
      2. [113] そうでなければ、無視しなければなりません >>3。停止します。
  6. [57] 「RST_STREAM 送信」タイムスタンプが設定されている場合、
    1. [115] 十分な時間が経過していれば、
      1. [116] エラーとしても構いません >>3。 接続エラー PROTOCOL_ERROR が適切そうです。停止します。
    2. [58] 1RTT を過ぎているなら、
      1. [72] 改めて RST_STREAM フレームを送信しても構いません >>71。
    3. [59] フロー制御対象のフレーム (DATA) なら、
      1. [119] 接続フロー制御窓の計算に含めます。 >>3 (フレームが無視されるとしても、相手が RST_STREAM を受信する前にフロー制御窓で数えてから送信しているはずだからです。 >>3)
    4. [61] PUSH_PROMISE フレームなら、
      1. [60] 指定されたストリームを reserved (remote) 状態とします。 (そちらのストリームは不要なら別途 RST_STREAM が必要です。) >>3
    5. [55] 無視しなければなりません >>3 。停止します。
  7. [110] PRIORITY フレームなら、
    1. [124] 依存性木からストリームが削除済みなら、無視します >>3。
    2. [111] 処理するべきです >>3。
  8. [117] それ以外なら、
    1. [118] 接続エラー PROTOCOL_ERROR とするべきです >>3。

[138] Chrome も Firefox も、 STREAM_CLOSED は送信せずに無視するだけのように見えます。

[52] PRIORITY フレーム以外を送信してはなりません >>3。

[123] 本状態へ遷移させた END_STREAM フラグ付き HEADERS フレームの続きの CONTINUATION フレームを送受信することはできます。[18] RST_STREAM フレームの送信によって closed に遷移すると、 peer との状態遷移の時間差が原因で、 この状態となった後にフレームを受信する可能性もあります >>3。 peer が既に送信したり、 送信準備をしたりして、取り消せなかったフレームが到着する場合があります >>3。 RST_STREAM フレーム送信後もフレームを受信する準備をしておかなければなりません >>71。[56] 自身が END_STREAM や RST_STREAM を送信してから相手が受信するまでの時間差があるため、その間に WINDOW_UPDATE や RST_STREAM を受信する可能性があります。 >>3[62] RFC は closed を1つの状態として表していますが、 実際には何により遷移してきたかで処理を分ける必要があり、また時間経過などで処理が変わる可能性があり、 複雑です。しかも RFC は「無視する (無視するとは言っていない)」のような変な書き方になっていて難解です。 >>99 は RFC の規定を出来る限り矛盾せずに整理した結果ですが、 これ以外の解釈もあり得るかもしれません。

[73] (>>58 を除き) RST_STREAM フレームを複数送信するべきではありません >>71。

[140] Firefox は HEADERS を受信する前に RST_STREAM を受信したら接続エラー PROTOCOL_ERROR とします。 Chrome はそれ自体はエラーとせずに無視しますが、その直後に HEADERS を受信したらストリームエラー PROTOCOL_ERROR とします。

[141] Firefox も Chrome も END_STREAM 後の RST_STREAM は無視するようです。相当する要求に対する応答も、 ネットワークエラーとはなりません。

[125] closed 状態のストリームは、一定時間後、依存性木から削除できます。

依存性木を参照。

並行性

[67] 設定 SETTINGS_MAX_CONCURRENT_STREAMS (0x3) は、送信者が認める並行ストリームの最大数を表します >>77, >>3。

[79] 初期状態は無制限です >>77。

[78] 不必要に並列性を損なわないため、 この値を 100 未満とするべきではありませんrecommend。 >>77

[80] 値0は、特別な意味は持ちません。新しいストリームの生成が認められないことを表します。 しかしサーバーは短い時間に限ってのみ 0 を使うべきです。 要求を受け付けたくない時は、接続を閉じる方が適切です。 >>77

[68] この設定は、受信者が開始することを認められたストリームの数を示しています。 従ってクライアントはサーバーの開始するストリームの最大数を指定でき、 サーバーはクライアントの開始するストリームの最大数を指定できます。 >>3, >>77

[81] ここで数に含まれるのは、 open, half-closed (local), half-closed (remote) のいずれかの状態にあるストリームです >>3。

[69] HEADERS フレームを受信した時、 ストリーム数上限を超えるなら、 PROTOCOL_ERROR または REFUSED_STREAM のストリームエラーとしなければなりません。 どちらを選ぶかは、自動的な再試行を有効にしたいかに依ります。 >>3

[70] SETTINGS_MAX_CONCURRENT_STREAMS の値が現在のストリームの数よりも小さくなる場合は、 新しい値を超えたストリームを閉じることもできますし、 ストリームが完了するまで待つこともできます。 >>3

[84] Chrome は接続序文で 1000 を値として設定します。

[87] プッシュメッセージ購読集合資源で使うことがあります。

接続の切断

[74] HTTP/2接続を参照。

[131] GOAWAY フレームを受信したら、以後新しいストリームを作成してはなりません >>130。

[132] しかし既存のストリームの送受信処理は、継続できます。

[133] GOAWAY フレームの送信後であっても、 受信して処理を継続しなければなりません。無視するストリームのフレームも、 ヘッダーブロックやフロー制御の処理は行わなければなりません >>130。

END_STREAM フラグ

[127] DATA フレームや HEADERS フレームの END_STREAM (0x1 = 第0ビット) フラグは、設定されていれば当該ストリームの当該送信者からの最後のフレームであることを表します。 >>126, >>128

[129] 実際には CONTINUATION フレームも直後に送信されるかもしれません >>128。

[121] END_STREAM フラグが設定されたフレームを送受信すると、 closed 状態に遷移します >>3。本フラグの送受信が他のフレームの処理にも影響します。

状態遷移の項を参照。

[135] CONNECT では、 TCP FIN フラグに相当します >>85。

誤り符号 STREAM_CLOSED

[83] STREAM_CLOSED (0x5) は、 ストリームが half-closed の後にフレームを受信したことを示します >>82。