[55] HTTP/2 ストリームは、優先度を持ちます。 複数のメッセージの送受信は、優先度を参考に順序が決定されます。
[5] エンドポイントは、各ストリームについて、 peer が当該ストリームに資源を割り当てる際に (他のストリームに対して) どの程度優先するべきかを指定できます。 >>2
[6] エンドポイントは、 (送信能力が限られる時に) 送信するストリームを選ぶに当たり、 優先度を使うことができます。 >>2
[57] 優先度の指定は、 peer に対するヒントに過ぎません。 その値によって他のストリームに対する転送処理の順序が保証されるわけではありません >>2。 具体的な順序の決定方法も規定されていません。
[47] なお優先度の使い方は、fingerprinting vector です >>46。
[12] あるストリームから他のストリームへの依存性を指定することができます。 依存性の関係において、 依存している方のストリームを依存ストリーム、 依存されている方のストリームを親ストリームといいます >>12。
[56] ストリームの親ストリームは、1つです。 ストリームの依存ストリームは、0個以上の任意の個数存在できます。 従って依存性の関係は、ストリームを節点とする木になります。 これを依存性木といいます。
[15] 同じ親ストリームを持つ依存ストリームは、 互いに順序を持ちません。 >>2
[20] 依存ストリームには、 1 以上 256 以下の整数の重みが割り当てられます >>2。
[61] なお、節点としては通常のストリームの他に、ストリーム識別子
0x0 の (ダミーの) ストリームを使います >>2。
[10] HEADERS フレームや PRIORITY
フレームを使って、依存ストリームと重みを明示的に指定できます。
[3] その場合の変更操作は、次のようにします。
[70] HEADERS フレームの
PRIORITY (0x20 = 第5ビット) フラグは、
設定されていれば、排他的 (E) フラグ、ストリーム依存性欄、重み欄が存在することを表します。 >>66
設定されていなければこれらの欄は存在しません。
[67] HEADERS フレームや
PRIORITY フレームの
E (排他的) フラグは、
ストリーム依存性が排他的かどうかを表す1ビットのフラグです >>66, >>34。
[68] HEADERS フレームや
PRIORITY フレームのストリーム依存性欄は、
ストリームが依存するストリームのストリーム識別子を表す31ビットの欄
(ネットワークバイト順 >>50) です。 >>66, >>34
[71] 存在しないストリームが指定された時、受信者がどうするべきなのかは定かではありません。 idle 状態も含め、適切なストリームを表していれば、それについて依存性を設定するべきでしょう。 peer が開始するべきストリームが指定された時どうするべきなのかは不明です。 Chrome も Firefox も、そのような指定を受信してもエラーとはしません。
[69] HEADERS フレームや
PRIORITY フレームの重み欄は、
ストリームの優先度の重みを表す符号無し8ビット整数です。
重みは 1 以上 256 以下で、ここで指定するのはそれより 1 小さい値です。
>>66, >>34
[33] PUSH_PROMISE フレームによって予約されたストリームは、
元のストリームに依存します >>2。
[64] エンドポイントは、ストリームの情報を依存性木から削除することも認められています。
[22] その場合、削除ストリームの依存ストリームは、 削除ストリームの親ストリームの依存ストリームとなります。 依存性の重みは、削除されるストリームの重みを各依存ストリームの重みで分配した値とします。 >>2
[24] 依存性で指定されたストリームに優先度が関連付けられていない場合は、 既定優先度 (重み 16) を割り当てます >>2。
[26] これらの問題を防ぐため、閉じたストリームの優先度の状態を一定期間保持し続けるべきです。 >>2
[27] idle や closed の状態のストリームにも優先度を割り当てたり他のストリームの親ストリームとしたりできますから、 これを依存性の木の中でストリームをまとめる節点を作り、 優先度を柔軟に表現するために使うことができます。 >>2, >>34
[28] こうした SETTINGS_MAX_CONCURRENT_STREAMS 制限に含まれないストリームの優先度情報を多数保持するのは大変かもしれませんから、
優先度を保持する量は制限しても構いません。保持する量は負荷に依存するかもしれません。 >>2
[30] しかし制限する場合、最低でも SETTINGS_MAX_CONCURRENT_STREAMS
分のストリームの状態は保持するべきです >>2。
[31] 活性のストリームの状態は、保持するよう試みるべきです >>2。
[32] 閉じたストリームの優先度を保持している場合は、
PRIORITY フレームを受信したら、
依存ストリームの優先度を変更するべきです >>2。
[17] 依存性木における依存ストリームには、 その親ストリームや祖先のすべてが閉じられるか、 それ以上の進捗ができなくなったかの場合に限り、 資源を割り当てるべきです >>2。
[21] 同じ親ストリームを持つストリームには、 重みの比率によって資源を割り当てるべきです >>2。
[74] 依存性木はサーバーの処理順序の指定として用いられることが想定されているようです。 プロトコル上はサーバーも優先度を指定できますが、クライアントがそれをどう利用するか (しないか) は明らかではありません。
PRIORITY フレーム[35] PRIORITY フレーム (フレーム型 0x2)
は、ストリームの優先度について送信者がヒントを示すものです。 >>34
[42] 常にストリーム識別子を指定しなければなりません >>34。
0x0 を指定することはできません。
[41] フラグはありません >>34。0 でなければなりません >>51。 受信者は無視しなければなりません >>51。
[43] 受信者は、ストリーム識別子が 0x0 なら、
接続エラー PROTOCOL_ERROR としなければなりません >>34。
[45] 受信者は、payload の長さが 5 以外なら、
ストリームエラー FRAME_SIZE_ERROR としなければなりません
>>34。
[75] Chrome も Firefox も、 HEADERS または PUSH_PROMISE
より先に PRIORITY を受信すると (RFC 的には open 状態で受け入れられるはずですが)
接続エラー PROTOCOL_ERROR とします。
[53] half-closed (local) でも受信するかもしれません >>52。 依存ストリームの優先度の設定に使われます >>52。
[54] closed でも受信するかもしれません。処理するべきです。 しかし依存性木から削除した後なら、無視できます。 >>52
[58] PRIORITY フレームは、無駄な処理をさせるために濫用できます。
エンドポイントは利用状況を監視して制限するべきです。
接続エラー ENHANCE_YOUR_CALM としても構いません。 >>59
[77] Fold request type into destination (annevk著, ) <https://github.com/whatwg/fetch/commit/d7052e2b6d24d04caa2cea8ef664923ecdb1e35c>
APNsはHTTP/2 PRIORITYフレームを無視するので、ストリーム上でこれを送信することはできません。
[79] Copy priority for service worker passthrough requests (jakearchibald著, ) <https://github.com/whatwg/fetch/commit/b281c58a6dde6c36fd18d62d2b05e3899cd6d595>
[80] Copy priority so service worker pass-through requests don't lose it by jakearchibald · Pull Request #785 · whatwg/fetch () <https://github.com/whatwg/fetch/pull/785>