摘要

  • STREAM 帧通过 stream ID、偏移量和编码字段，在一个有序流中定位字节范围。
  • 传输、丢包恢复和交付给应用时，都不会保留原始 STREAM 帧的边界。
  • 要判断消息、请求或事务，必须补充应用层的分帧、解析和处理证据。

最容易出现的误判来自一张看似明确的图：导出工具显示一帧完整的 STREAM，运维人员于是记下一次完成的请求。但这帧首先只是传输容器。它说明某个流上的某段字节被编码，并不说明这段字节对应一个应用消息。

RFC 9000 把流描述为提供给应用的有序字节流。接收端根据 stream ID 和 Offset 把字节放回流中的位置。有序性只属于同一个流。不同 stream ID 的字节不会因为抓包文件按某种顺序列出它们，就获得跨流的执行顺序。全局观察顺序不是应用执行顺序。

OFF、LEN 和 FIN 是传输编码字段。OFF 表示是否存在 Offset；没有该字段时，数据从偏移量零开始。LEN 表示是否存在 Length；没有该字段时，数据占据数据包剩余部分。FIN 确定发送方向的最终字节边界，最终大小由偏移量和数据长度确定。这些字段不提供应用语法，也不宣布记录、请求或业务成功。

丢包恢复进一步说明了边界不能被当作消息身份。QUIC 不会完整重传丢失的数据包，也不会重新制作原来的帧分段。流信息会在新构造的 STREAM 帧中再次发送。后续帧可能覆盖不同的字节范围，却承载逻辑上相同的流信息。因此，原始帧的外形没有持续的证明意义。相同范围可能重复到达并被丢弃；同一偏移量上的字节不能改变。若同一偏移出现不同内容，那是协议违规，而不是新的应用消息。

接收端需要在公告的流控限制内缓存乱序到达的数据，以便交付有序字节流。实现可以把乱序信息暴露给应用，但 QUIC 本身没有规定统一的应用消息格式。某个应用协议可能让一条消息跨越多帧，也可能让一帧承载多个结构，或者只承载一个更大结构的片段。FIN 可以结束流，却不能证明内容有效、已解析、已执行、已提交或成功。

证据台账应把字段分开保存：连接观察标识和时间、端点方向、QUIC packet number space 与 packet number、stream ID 及方向、偏移量、编码长度或数据包剩余部分规则、字节范围指纹、FIN 与已知的最终大小、重复范围处置、重传谱系、确认信息、重组完成状态、应用协议帧或记录标识、解析器结果、处理回执和持久业务结果。无需保存原文时，可用隐私安全的指纹替代。台账是 BTW 的运营建议，不是 QUIC 要求。

证明边界必须保持克制。STREAM 帧能够证明某个流上的一段字节被编码；经过认证的数据包处理还可以构成传输端点收到这些字节的证据。但它不能单独证明消息、请求、响应、执行、提交或成功，也不能证明不同流之间的顺序。消息边界、最终字节边界、密码学字节范围与 ACK 证据仍是不同的问题。