摘要

  • 在对端地址通过验证之前，作出响应的 QUIC 端点发送量不得超过从该地址收到字节数的三倍。
  • 这本账限制的是特定阶段内利用伪造源地址造成的放大，不等于客户端身份认证，也不能消除其他拒绝服务风险。
  • 运维判断必须保留字节计数和验证状态切换，才能区分合规等待、丢包与资源饱和。

设想服务端收到一个 QUIC Initial 数据报，准备好握手 flight，并逐步用完允许的发送额度。剩余握手字节已经就绪，网络路径可能仍然畅通，进程也可能有充足的 CPU 和内存；但服务端必须等待客户端再发来数据，或者等待客户端地址完成验证。

这不是实现细节，而是 RFC 9000 划定的安全边界。攻击者可以伪造受害者的源地址，诱使服务端把响应流量发向受害者。为限制这种反射，端点在响应未经验证的地址时，发出的数据不得超过从该地址收到数据的三倍。

正确的理解方式是一套累计账本。收到的字节提高上限，发出的字节消耗预算。它不是让每个入站包分别获得三倍放大许可，也不能只观察最后一个数据报就得出当前额度。

第 8.1 节 把这套规则用于连接建立。服务端要统计所有能够唯一归属于该连接的数据报载荷字节。服务端发出的 Initial 或 Handshake 包若丢失，已经消耗的预算不会因此自动恢复；与此同时，客户端若看到自己发送的数据都已获确认，也可能没有理由继续发送。RFC 因此明确描述了触及抗放大限制后可能出现的僵局。

运维记录应当回答：未经验证地址贡献了多少收到字节，服务端已发送多少，当前三倍上限和余额是多少，何时因额度停止发送，还有多少握手数据待发，以及新增客户端流量或验证完成后是否解除了阻塞。缺少这些事实时，丢包、预算耗尽和服务器资源压力在粗粒度超时图上很容易混为一谈。

地址验证本身也是有限结论。连接建立期间，收到 Handshake 包或成功校验 Initial 中的令牌都可能改变状态；Retry 可以要求客户端回送其在声明地址收到的令牌。对新路径而言，第 8.2 节 使用 PATH_CHALLENGE 和匹配的 PATH_RESPONSE 验证特定本地地址与对端地址之间的可达性。只有 ACK 并不足够，因为恶意对端可以伪造它。

这些信号都不证明地址背后是谁。它们说明对端能够在传输地址接收数据，或令牌符合服务端规则；它们不是对人员、设备、账号或应用的身份认证。地址验证完成后，端点可以超过三倍上限继续发送。连接仍受拥塞控制、流量控制、密码状态和应用策略约束，但抗放大账本不是永久速率上限。

把它宣传成完整 DDoS 防护同样危险。RFC 9000 第 21.2 节 讨论握手拒绝服务，第 21.9 节 讨论消耗处理能力和连接状态的滥用；另行的第 21.3 节 才描述验证令牌与地址重新分配留下的放大风险。验证前的带宽上限无法为 CPU、内存、连接表、已认证洪泛或验证后的应用负载定价。

作为编辑性运维建议，监控应分开回答三个问题：地址是否未验证、什么证据会改变状态；收到、发出和剩余字节各是多少；独立的包速率、CPU、内存和连接状态指标是否承压。前两项解释协议预算，第三项才进入更广泛的拒绝服务判断。

建议保留的完整回执包括：连接与路径标识；本地和对端 IP/端口二元组；观测时间；验证状态、状态切换及验证方法；从未经验证地址收到的字节和向其发送的字节；当前三倍上限与剩余预算；待发送握手 flight 字节；Retry 或令牌结果；适用时的 PATH_CHALLENGE/PATH_RESPONSE 结果；丢包与重传上下文；首次及末次受限时间戳；验证后的结果；以及分别记录的 CPU、内存、连接状态和包速率压力指标。