摘要

  • RFC 9221 规定，含有 QUIC DATAGRAM 帧的数据包属于 ack-eliciting；确认该数据包可以让发送端告知其应用，数据报已被发送和接收。
  • 该 RFC 第 5.2 节同时限定：这个确认表示接收方传输层处理了帧，并不保证接收方应用成功处理了数据。

日志里最危险的不是缺少信号，而是让一个正确的信号替太多系统说话。看到 ACK 后，很容易写下“消息已送达”甚至“任务已完成”。RFC 9221 不允许这样跨层推演。它给发送端的是 QUIC 数据包确认所能给出的事实，而不是应用语义的判决书。

RFC 9221 于 2022 年 3 月发布，署名作者包括 Tommy Pauly、E. Kinnear 和 David Schinazi。它为 QUIC 增加了用于不可靠应用数据的 DATAGRAM 帧。这样的帧会使其所在包触发确认需求。一个包含 DATAGRAM 的包得到确认后，发送端实现可以通知本地应用：该数据报已经发送和接收。这是一个有价值的传输层记录，足以说明一项特定的协议处理已经发生。

但第 5.2 节随即划线。确认表示接收方的传输层处理了该帧；它不保证接收方应用成功处理数据。帧被交给了传输层，和内容被解析、验证、写入状态或产生业务结果，是不同的事件。前者不能借后者的名义完成记录。

DATAGRAM 的设计也没有为这个缺口提供暗中的补偿。检测到丢失时，DATAGRAM 数据不会被重传。数据报的复用标识、内容含义和应用确认都由应用协议决定。若一个场景需要交付或处理证明，应用必须自行定义它的确认对象；它要有自己的关联标识、时限、失败路径和观测点。RFC 9000 与 RFC 9002 所规定的 QUIC 与丢失恢复语境，不会把传输确认变成应用处理证据。

收到的 max_datagram_frame_size 也应保持原尺寸。非零值仅说明在这条连接、这个方向上，一个端点愿意接收不超过该大小的 DATAGRAM 帧。它不是发送过某份内容的证据，不是应用使用或理解内容的证据，更不是某项操作完成的证据。RFC 的存在和署名同样只说明公开的协作事实，不能证明任何具体端点、产品、网络或服务正在采用该扩展。

Heng Lu 的最小初始规范与运行代码优先性在这里是一条实际的记录纪律：只保留机制能够局部、确定地核验的最小命题。QUIC ACK 说明的是接收方传输层的处理；应用解析器、状态存储和面向用户的流程必须各自为自己的结果提供证据。

因此，正确做法不是贬低 ACK，而是把它放回可审计的位置。把它作为传输层事实保存；需要更强保证时，再明确寻找应用层确认、关联键、成功条件和失败状态。两类记录可以相互印证，却不能互相冒名。

来源