要約

  • MAX_DATA と MAX_STREAM_DATA は絶対オフセット上限であり、新規バイト量や空きメモリの測定値ではない。
  • 後から小さい値を送ってもクレジットは取り消せず、DATA_BLOCKED が見えなくても送信可能とは証明できない。
  • 容量判断には、クレジットをオフセット、最終サイズ、アプリ消費、バッファ占有、輻輳状態と結合した記録が必要だ。

監視画面が MAX_DATA の 16 MiB への上昇を見て、16 MiB の余力と表示する。まず計算が違う。この値は累積上限であり、既に使ったストリームオフセットも含む。意味も違う。送信側に台帳を伸ばす許可を与えるだけで、空き RAM やアプリケーションの読取速度を直接測ってはいない。

RFC 9000 §4.1 は接続単位とストリーム単位の二つの制限を同時に課す。前者は全 STREAM データを、後者は一つのストリームを制限する。実際の送信余地は、最大接続上限と累積消費、対象ストリームの最大上限と最大オフセットの両方で決まる。

値は増分ではなく絶対値だ。後で届いた小さな MAX_DATA や MAX_STREAM_DATA は効力を持たず、送信側は上限を増やさないフレームを無視する。「最後に見た値」ではなく、受理済みの最大値と対応する消費量を保存しなければならない。

RFC 9000 §19.9 では、終端状態のストリームを含む全 STREAM データの最終サイズ合計が接続上限に収まる必要がある。RFC 9000 §4.5 は最終サイズを消費済みクレジットとして定義する。終了やリセットは会計を確定させるのであり、過去のオフセットを消して接続枠を回復させるわけではない。

RFC 9000 §19.10 のストリーム会計は最大オフセットを使う。損失や並べ替えにより、それが現在連続して渡せるバイト数を上回ることがある。受信パケットの総バイトや瞬間的なバッファ使用量は、この台帳の代用にならない。

RFC 9000 §4.2 は、クレジットをいつ、どれだけ増やすかを実装に委ねる。小幅な更新を頻繁に行えば制御負荷が増え、頻度を落とせば大きな増分と受信側の資源コミットが必要になる。RTT とアプリ消費速度による自動調整は可能だが、それでも広告値を空きメモリへ直接換算することはできない。

クレジットはスループット保証でもない。RFC 9000 §4.3 は、利用可能クレジットを帯域遅延積より大きく保てなければ受信スループットが流量制御に制約されるとする。必要条件にはなり得るが、輻輳ウィンドウ、損失、スケジューリング、送信側処理という別の制約は残る。

DATA_BLOCKED も完全な証明ではない。RFC 9000 §19.12 は、書きたいのに接続上限で止まった送信側がこのフレームを送るべきだとする。しかし送信は必須ではなく、§4.2 は受信側がそれを待ってからクレジットを増やすことを禁じる。不在は余力の証明ではない。

運用記録には、最大接続上限、累積消費、各ストリームの最大上限とオフセット、最終サイズ、観測したブロック、アプリ消費境界、バッファ占有、輻輳ウィンドウ、RTT、損失、更新時刻が必要だ。MAX_DATA が証明するのはプロトコル上の送信許可だけである。