摘要

  • ACK Delay 表示接收端从收到最大已确认包到发送 ACK 之间主动控制的等待。
  • latest_rtt 先由本地发送与收到 ACK 的时间形成，之后才考虑 ACK Delay。
  • 解码和调整必须结合 ack_delay_exponent、握手阶段、max_ack_delay 与 min_rtt 下限。

一种看似合理的监控流程是：测量发送到 ACK 到达的时间，解码 ACK Delay，将其相减，再把结果标成网络时延。问题在于，这个字段描述的是接收端报告的、有意引入的等待，不是网络路径上的独立传感器。它不能直接说明传播时延、网络排队、单向时延，也不能说明远端主机上发生的全部等待。

ACK Delay 的对象非常具体：接收端收到最大数据包编号所对应的数据包后，到发送 ACK 之间的主动等待。ACK 帧中的其他 ACK range 并不会因此各自获得一个同样的延迟值。接收端无法控制的时间，例如数据包在操作系统路径中等待 QUIC 处理的时间，也不应被混入 ACK Delay。密钥不可用造成的等待可以按协议规则计入，但这仍不等于完整的主机驻留时间或应用处理时间。

发送端先以本地时间形成 latest_rtt：从最大的新确认、且会触发 ACK 的数据包发出，到 ACK 到达之间的间隔。这个原始样本保留了实际观察到的整个确认间隔。ACK Delay 是随后计算 smoothed_rtt 与 rttvar 时使用的输入。编码字段必须配合 ack_delay_exponent 和传输参数解码；缺少这些信息，一个原始数值并不是可直接使用的时长。默认指数是 3，max_ack_delay 以毫秒表示，默认值为 25 ms，但默认值不能替代连接实际协商出的上下文。

min_rtt 采用不同的原则：它只来自本地发送和收到确认的观察，不会因对端报告的 ACK Delay 而降低。它可以防止错误报告把估算值压得过低，却不是单向时延或纯网络时延的测量。握手确认后，发送端要在解码后的 ACK Delay 与对端 max_ack_delay 中取较小者，并且不能让调整后的样本低于 min_rtt。握手确认前，max_ack_delay 不作为上限；密钥可用性等原因可能造成更长的早期等待。

超过 max_ack_delay 的报告并没有唯一解释。握手确认后，算法会把超出部分按路径时延处理，但这项观察本身不能区分对端调度器延迟、此前 ACK 丢失，还是接收端不合规。受保护数据包中的认证只能证明字段来自对端，不能证明报告一定准确。它也不能证明应用处理时间、服务响应、持久化完成或业务结果。

因此应保存一份证据账本：连接与路径身份、包号空间、最大新确认包及发送时间、ACK 到达和处理时间、原始 latest_rtt、原始与解码后的 ACK Delay、ack_delay_exponent、对端 max_ack_delay、握手确认状态、当前 min_rtt、实际采用的上限与下限、调整样本、smoothed_rtt、rttvar 和 PTO。ACK range、密钥可用性、本地处理、此前 ACK 丢失和应用时间也应独立记录。报告值、观察值和推导值不能合并成一个“网络真相”。