要約

  • STREAM は stream ID、オフセット、符号化フィールドによって、一つの順序付きストリーム内のバイト範囲を示す。
  • 送信、損失回復、アプリケーションへの配送を経ても、元の STREAM フレーム境界は保存されない。
  • メッセージやトランザクションを主張するには、上位プロトコルのフレーミング、解析結果、処理の証跡が必要である。

トレースに完全な STREAM フレームが表示されると、それを一件の完了した要求として記録しがちになる。しかし、その観測が示すのは、特定のストリーム上の特定の位置にバイト範囲が配置されたことだけである。トランスポート上のフレームは、アプリケーションメッセージの宣言ではない。

RFC 9000 はストリームを、アプリケーションに公開される順序付きバイトストリームとして扱う。受信側は stream ID と Offset を使ってバイトを配置する。この順序は一つのストリームの内部に限られる。異なる stream ID のデータは、キャプチャ上で前後に並んでいても、アプリケーションの実行順序を得ない。トレースの表示順は、処理順の証明ではない。

OFF、LEN、FIN はトランスポート層の符号化フィールドである。OFF がなければデータはオフセットゼロから始まり、LEN がなければパケットの残りがデータになる。FIN は送信方向の最終バイト境界を示し、最終サイズはオフセットとデータ長から決まる。これらはアプリケーションの文法、レコード区切り、要求の完了、成功を示すものではない。

損失回復では、失われたパケット全体や元のフレーム分割をそのまま再送しない。ストリーム情報は、新たに構成された STREAM フレームで再び送られる。後続のフレームは別の範囲を示しながら、同じ論理バイトを運ぶことがある。したがって、最初に観測したフレームの境界をメッセージの識別子として追跡することはできない。同じ範囲の重複は受信後に破棄できるが、同じオフセットのバイト内容は変わってはならない。異なる内容はプロトコル違反である。

エンドポイントは、通知されたフロー制御の範囲内で順不同に到着したストリームデータをバッファできる能力を持たなければならず、その上限は広告されたフロー制御限界である。実装が順不同の配送情報をアプリケーションに公開することは別個の任意機能であり、QUIC の要件ではない。QUIC は共通のメッセージモデルを定めない。上位プロトコルでは、一つのメッセージが複数フレームにまたがることも、一つのフレームが複数の構造を運ぶことも、大きな構造の一部だけを運ぶこともある。FIN は送信方向を閉じても、内容が正当、解析済み、処理済み、コミット済み、成功済みであることを証明しない。

運用台帳には、観測 ID と時刻、エンドポイントの方向、packet number space と packet number、stream ID と方向、オフセット、符号化された長さまたはパケット残余の規則、バイト範囲のフィンガープリント、FIN と判明した最終サイズ、重複範囲の扱い、再送の追跡情報、ACK の証拠、再構成の完了、アプリケーションのフレームまたはレコード識別子、パーサ結果、処理レシート、永続的な業務結果を分けて記録する。原文が不要なら、プライバシーに配慮した指紋を使える。これは運用上の推奨であり、QUIC の要件ではない。

証明できる範囲は限定される。STREAM は特定のストリームにバイト範囲が符号化されたことを示し、認証済みパケット処理はトランスポート終端での受信の証拠になり得る。しかし、メッセージ、要求、応答、実行、永続的なコミット、成功を単独で証明しない。ストリーム間の順序も証明しない。メッセージ境界、最終サイズ、暗号化データの範囲、ACK の証拠は別々の論点である。