このドキュメントは個人的なまとめに過ぎませんが、誤った情報がある場合はコメントで指摘してもらえると助かります。

まず、自分がしていた誤解として最新の安定版のQUIC（IETFでRFCになっているものを指す。以下IETF-QUICと呼ぶ）は以前までの HTTP/2として実現されていたころとは違い、HTTPプロトコルとは別のプロトコルとして規定されている。
つまり、QUIC上にHTTPプロトコルが載せられるのであって、QUICとHTTP/3は実際は個別なものとして扱われている。

ここから先は自分が調べたところから、つらつらと述べていく。

ストリームとパケットとフレーム

ストリームはIETF-QUICプロトコルに用意されている仮想的なピア間での通信方法を指す。
また、パケットは実際に送られるUDPのデータグラムであり、その中にはフレームが含まれる。

ストリームに使われるフレーム

ストリームは仮想的であるものの各フレームによって管理されるようにIETF-QUICプロトコルに定義されている。以下がストリームについて扱ったフレームの種類である。

• Stream Frame
  • これによってアプリケーションプロトコルのデータがストリーム上で送信される
• Reset Stream Frame
  • Abrupt Termination（突然終了） するときに使われるフレーム
• Stream Data Blocked Frame
  • 送信側がFlow Control Limit の制限によって送信が制限されているときに使うフレーム
• Max Stream Data Frame
  • Flow Control Limit の制限を相手に知らせるために送るフレーム
• Stop Sending Frame
  • 受信側がStreamをとりやめたいときにこのフレームを送り、送信側に伝える

ストリームのための順序付きバイトストリーム

QUICのストリームでは順序付けられたバイトストリームが送られる。このバイトストリームの順序はオフセットと呼ばれる値によって管理される。
送信側は配信する際にFlow Control Limitの上限までバッファリングしなくてはならない。（おそらくすべて受け取ったことが確認するまでは）
もし受信側が同じオフセットのバイトストリームを受け取った場合、Protocol Validation Errorとして扱う。また送信側が同じオフセットのバイトストリームを送る必要が生じた場合も同じオフセットで送らなければならず、オフセット番号を変えてはいけない。
またストリームのフレーム境界は以下のいかなる時でも、保証されていることを期待しないこと。（ここよく分からなかった。原文: STREAM frame boundaries are not expected to be preserved.）

• データ送信時
• パケットロス後に再送信されるとき
• 受信者のアプリケーションに届けられたとき