[2] ストリームは、HTTP/2接続中の独立したフレームの双方向の流れ (列) です >>1, >>3。 一組の要求と応答を送受信するために使います。 ストリームは HTTP/2 で新たに導入された概念です。
[4] HTTP/2接続は、並行して複数のフレームを開くことができます。 つまり複数のストリームのフレームを混在させて送受信できます。 >>3
[5] ストリームは、サーバーとクライアントのどちらからも確立したり閉じたりできますし、 一方だけで使ったり、両方で使ったりできます。 >>3
[7] HTTP/2接続の開始の時点では、ストリームはありません。
[65] エンドポイントは、各ストリームの次の情報を保持します。GOAWAY フレーム送信時に使います。RST_STREAM タイムスタンプRST_STREAM
フレーム再送判定に使います。
[6] ストリームにおけるフレームの順序には意味があり、 受信者は受信した順序で処理する必要があります。 >>3
[8] エンドポイントは、ストリームの状態を保持します。 >>3
[9] ストリームの状態は、エンドポイントがそれぞれ保持しているもので、 フレームの転送中は peer と異なることがあります。 >>3 また (local) と (remote) のような対となる状態になっていることもあります。
[50] 状態は、フレームの送受信で遷移します。単一のフレームで複数の状態遷移が発生することもあります。
[63] 未知のフレーム型のフレームは無視して捨てなければなりません >>3, >>75。しかし後述の通り、 指定されたフレームの種類以外はエラーとなるとの規定もあります。 どちらの規定が優先されるのかは不明ですが、この両文が RFC では隣に並んでいるので、無視が優先されるとエスパーできます。
[144] GOAWAY フレームを受信したら、
その最終ストリーム識別子よりも大きなストリームについて
RST_STREAM フレームを受信したものとして処理するべきと思われます。
[66] 次の状態があります。
[89] 状態毎に、送信できるフレーム型の制約があります。状態 DATAHEADERSPRIORITYRST_STREAMSETTINGSPUSH_PROMISEPINGGOAWAYWINDOW_UPDATECONTINUATIONその他 idle × ○ ○ × × × × × × × × reserved (local) × ○ ○ ○ × × × × × × × reserved (remote) × × ○ ○ × × × × ○ × × open ○ ○ ○ ○ × ○ × × ○ ○ × half-closed (local) × × ○ ○ × × × × ○ △ × half-closed (remote) ○ ○ ○ ○ × ○ × × ○ ○ × closed × × ○ × × × × × × △ × 接続 × × × × ○ × ○ ○ ○ × ×
[10] ストリームは、作成されると idle 状態となります >>3。
[22] 送信できるフレームの種類の制約は明記されていませんが、
HEADERS と PRIORITY しか送信できないと見られます。
[12] 送受信するフレームの種類により、次のような状態遷移があります >>3。HEADERS フレームを送信または受信すると、 open
に遷移します。PUSH_PROMISE フレームを送信し、
その Promised Stream ID で本ストリームが示されていれば、 reserved (local)
に遷移します。PUSH_PROMISE フレームを受信し、
その Promised Stream ID で本ストリームが示されていれば、 reserved (remote)
に遷移します。
[16] HEADERS と PRIORITY 以外のフレームを受信したら、
接続エラー PROTOCOL_ERROR としなければなりません >>3。
[139] 実際には WINDOW_UPDATE を受信したら Firefox はストリームエラー
PROTOCOL_ERROR とし、 Chrome は無視するようです。
[142] Firefox も Chrome も RST_STREAM
を受信してもエラーとはしないようです。 (closed に遷移しているものと思われます。)
[17] PUSH_PROMISE フレームで約束すると、
ストリームは reserved (local) 状態となります >>3。
[23] HEADERS, RST_STREAM, PRIORITY
以外を送信してはなりません >>3。
[19] 送受信するフレームの種類により、次のような状態遷移があります >>3。HEADERS フレームを送信すると、 half-closed (remote) に遷移します。RST_STREAM フレームを送信または受信すると、 closed に遷移します。
[24] RST_STREAM, PRIORITY, WINDOW_UPDATE 以外のフレームを受信したら、
接続エラー PROTOCOL_ERROR としなければなりません >>3。
[25] reserved (remote) 状態は、ストリームが peer により予約されていることを表します >>3。
[29] RST_STREAM, WINDOW_UPDATE, PRIORITY
以外を送信してはなりません >>3。
[26] 送受信するフレームの種類により、次のような状態遷移があります >>3。HEADERS フレームを受信すると、 half-closed (local) に遷移します。RST_STREAM フレームを送信または受信すると、 closed に遷移します。
[30] HEADERS, RST_STREAM, PRIORITY
以外のフレームを受信したら、
接続エラー PROTOCOL_ERROR としなければなりません >>3。
[31] open 状態では、任意のフレームの送受信ができます。
[34] 送信できるフレームの種類の制約はありません >>3。
[32] 本状態に遷移することになったフレームの種類や本状態で送受信するフレームの種類により、次のような状態遷移があります >>3。END_STREAM フラグが設定されたフレームを送信すると、
half-closed (local) 状態に遷移します。END_STREAM フラグが設定されたフレームを受信すると、
half-closed (remote) 状態に遷移します。RST_STREAM フレームを送信または受信すると、 closed に遷移します。
[37] half-closed (local) 状態では、メッセージを送信できませんが、受信するかもしれません。
[38] WINDOW_UPDATE, PRIORITY, RST_STREAM
以外のフレームを送信することはできません >>3。
WINDOW_UPDATE フレームを適宜送信する必要があります
>>3。[39] 本状態で送受信するフレームの種類により、次のような状態遷移があります >>3。END_STREAM フラグが設定されたフレームを受信すると、
closed 状態に遷移します。RST_STREAM フレームを送信または受信すると、 closed に遷移します。
[43] half-closed (remote) 状態は、 peer がフレームの送信をもう行わないストリームを表します >>3。
[44] この状態になると、受信者フロー制御窓を維持する義務はありません >>3。
[47] 本状態で送受信するフレームの種類により、次のような状態遷移があります >>3。END_STREAM フラグが設定されたフレームを送信すると、
closed 状態に遷移します。RST_STREAM フレームを送信または受信すると、 closed に遷移します。
[45] WINDOW_UPDATE >>3, >>134, RST_STREAM, PRIORITY
以外のフレームを受信したら、
ストリームエラー STREAM_CLOSED としなければなりません >>3。
[93] この状態での動作は、次の各フラグによって変わります。RST_STREAM 送信 (タイムスタンプ)END_STREAM 送信 (タイムスタンプ)RST_STREAM 受信済みEND_STREAM 受信済み
[96] この状態に遷移したら、次のようにします。RST_STREAM フレームを自身が送信したことにより遷移した場合は、「RST_STREAM 送信」タイムスタンプを現在時刻に設定します。END_STREAM フラグが設定されたフレームを自身が送信したことにより遷移した場合は、「END_STREAM 送信」タイムスタンプを現在時刻に設定します。RST_STREAM フレームを受信したことにより遷移した場合は、
「RST_STREAM 受信済み」フラグを設定します。END_STREAM フラグが設定されたフレームを受信したことにより遷移した場合は、
「END_STREAM 受信済み」フラグを設定します。
[99] この状態でフレームを受信したら、次のようにします。END_STREAM 受信済み」フラグが設定されていれば、STREAM_CLOSED としなければなりません >>3。
停止します。RST_STREAM 受信済み」フラグが設定されていれば、RST_STREAM フレームなら、RST_STREAM 受信済み」フラグを設定します。DATA フレームか HEADERS フレームなら、END_STREAM フラグが設定されていれば、END_STREAM 受信済み」フラグを設定します。END_STREAM 送信」タイムスタンプが設定されていれば、WINDOW_UPDATE フレーム >>3, >>134 か
RST_STREAM フレームなら、RST_STREAM 送信」タイムスタンプが設定されている場合、PROTOCOL_ERROR が適切そうです。停止します。RST_STREAM フレームを送信しても構いません >>71。DATA) なら、PUSH_PROMISE フレームなら、RST_STREAM が必要です。) >>3PRIORITY フレームなら、PROTOCOL_ERROR とするべきです >>3。
[138] Chrome も Firefox も、 STREAM_CLOSED
は送信せずに無視するだけのように見えます。
[52] PRIORITY フレーム以外を送信してはなりません >>3。
RST_STREAM フレームの送信によって closed に遷移すると、
peer との状態遷移の時間差が原因で、
この状態となった後にフレームを受信する可能性もあります >>3。
peer が既に送信したり、
送信準備をしたりして、取り消せなかったフレームが到着する場合があります >>3。
RST_STREAM フレーム送信後もフレームを受信する準備をしておかなければなりません >>71。END_STREAM や RST_STREAM
を送信してから相手が受信するまでの時間差があるため、その間に
WINDOW_UPDATE や RST_STREAM を受信する可能性があります。 >>3[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。
[78] 不必要に並列性を損なわないため、 この値を 100 未満とするべきではありません。 >>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] プッシュメッセージ購読集合資源で使うことがあります。
[131] GOAWAY フレームを受信したら、以後新しいストリームを作成してはなりません >>130。
[133] GOAWAY フレームの送信後であっても、
受信して処理を継続しなければなりません。無視するストリームのフレームも、
ヘッダーブロックやフロー制御の処理は行わなければなりません >>130。
END_STREAM フラグ[127] DATA フレームや
HEADERS フレームの
END_STREAM (0x1 = 第0ビット)
フラグは、設定されていれば当該ストリームの当該送信者からの最後のフレームであることを表します。 >>126, >>128
[121] END_STREAM フラグが設定されたフレームを送受信すると、
closed 状態に遷移します >>3。本フラグの送受信が他のフレームの処理にも影響します。
STREAM_CLOSED[83] STREAM_CLOSED (0x5) は、
ストリームが half-closed の後にフレームを受信したことを示します >>82。