摘要

  • QUIC 接收方只有在成功移除数据包保护并处理其中全部帧后，才能确认该数据包。
  • 对 STREAM 帧而言，“处理”只要求把数据排入等待应用接收的队列，并不要求应用已经收到或消费这些字节。
  • 若要声称交付或完成，必须把 ACK 与帧、流偏移、重传谱系以及应用自身的回执连接起来。

一个监控面板在承载请求的数据包进入 ACK 范围时亮起绿色“已交付”。如果它正是新获确认、会触发 ACK 且被选作测量的数据包，就可能产生一个 RTT 样本；确认也会让发送方停止重传已经获确认的信息。但接收进程恰好阻塞在读取回调之前：它尚未解析数据，也没有写入数据库或触发远端动作。面板把一张传输层收据，提升成了应用结果。

RFC 9000 第 13.1 节给出了精确边界。接收方不得在成功移除数据包保护并处理完其中每一个帧之前发送确认。对 STREAM 帧来说，处理是把数据排入队列，为应用协议接收做准备；并不要求数据已经交给应用或被应用消费。因此，ACK 是对端 QUIC 栈处理数据包的有力证据，却止步于应用消费之前。

还要看被确认的对象。RFC 9000 第 19.3 节规定，ACK 范围列出同一数据包编号空间内已经接收并处理的数据包编号。这些编号标识受保护的传输数据包，而不是业务消息。一个数据包可携带多种帧，一个应用消息也可能跨越多个 STREAM 帧和数据包。

流状态进一步揭示了这种错位。RFC 9000 第 2.2 节定义了有序字节流，并明确指出 STREAM 帧边界在传输、重传和交付时不会保留。RFC 9000 第 3.2 节又区分了所有流数据已经到达的 Data Recvd，与应用读完全部数据后才进入的 Data Read。传输完整接收、应用开始接收和应用完成读取，是三个不同的状态转换。

ACK 的可见性也不是逐包可见的回执账本。按照 RFC 9000 第 13.2 节，会触发确认的数据包必须依照协议规则，在对端公布的最大延迟内获得确认；不触发确认的数据包则可能等到后续流量再一起确认。ACK 帧本身可能丢失，较老的 ACK 范围最终也可能被省略。因此，发送方没有看到某个 ACK，并不能立即证明接收方未处理数据包。

重传也不会保留原数据包身份。RFC 9000 第 13.3 节重传的是信息，而不是整个丢失数据包。相同 STREAM 偏移的数据可在新帧、新数据包编号中再次出现。通常，一旦承载该信息的某个数据包被确认，发送方就停止重传已经获确认的信息。若要判断字节去向，必须把 ACK 范围连到原始帧，再连到流 ID、偏移、长度、FIN 状态和每次重传。即使完成这条连接，证据仍然只到传输接收队列为止。

恢复算法也保持同样范围。RFC 9002 第 5.1 节从最新确认且会触发 ACK 的最大编号数据包生成 RTT 样本，并按规则处理 ACK Delay。它测量的是传输反馈路径，不是应用服务耗时。RFC 9002 第 6.1 节结合后续 ACK、数据包阈值和时间阈值推断丢包，同时容忍乱序。缺少 ACK 不是即时丢包证明，收到 ACK 也不是应用成功证明。

可用证据应形成阶梯。第一层保存连接、编号空间、包号、发送与 ACK 时间、ACK Delay 和所载帧。第二层保存 STREAM ID、偏移、长度、FIN、丢包判定和重传谱系。第三层保存接收栈入队事件，以及应用读取或回调事件。第四层保存应用消息或事务 ID、协议级确认、持久化提交、实际副作用和最终响应。

每一层回答不同问题：对端处理了受保护数据包；这些字节到达对端 QUIC 接收队列；进程读取了字节；应用接受了消息；请求动作已经完成持久化确认。不能用一个绿色状态替代五个不同的事实。

这个边界直接影响重试权限。把 ACK 当成完成，可能让仍在队列中或死锁中的工作失去恢复机会；把暂时不可见的 ACK 当成立即失败，则可能重复已经处理的请求。只有知道操作身份和幂等语义的那一层，才有资格判断能否安全重试。

QUIC 的证据之所以强，正因为它的主张很窄。应用结果仍须由应用自己出具回执。