摘要

  • RFC 9693 把预置变成测试的一部分：第一阶段在 DUT 中建立受限数量的连接，并由 Responder 记录翻译后的四元组；第二阶段才对这些已知状态测量吞吐量、丢包或时延。
  • 第二阶段无丢包，只能证明一个参数已申明的黑盒实验；它不揭示内部表项，不自动代表互联网流量或 TCP，也不证明生产余量和用户业务连续性。

反向报文不能凭空创造资格

有状态 NAT 的方向并不对称。Initiator 从客户端一侧送入一个新四元组时，DUT 可以创建连接跟踪项，翻译并转发。Responder 若从服务器一侧自行生成一个陌生四元组，DUT 通常会丢弃，因为该报文不属于已存在的连接。

因此，测试系统同时维护两张不同的表。DUT 内部有连接跟踪表，黑盒测试者看不到其大小、策略和内容；Tester 的 Responder 另有状态表，只记录自己确实收到的翻译后四元组。发出多少 tuple、多少报文正向到达、多少 tuple 被记录、多少连接通过反向验证，是四种证据，不能被一个“会话数”字段吞并。

随机端口会把一个测试膨胀成数十亿个状态请求

RFC 4814 建议使用均匀分布的伪随机传输层端口，避免固定模式恰好迎合哈希算法。对无状态转发设备，这扩大了路径覆盖；对有状态 NAT，每个陌生四元组还可能要求创建一个新表项。

即使只有一对 IP，RFC 4814 建议的源、目的端口范围也能产生 3,170,829,312 种组合。再加入源或目的地址范围，潜在流数按四个范围的乘积增长。若测试仪把它们当作普通随机变化，就可能先耗尽状态表，再去测一个已经被预置过程污染的吞吐量。

RFC 9693 保留伪随机原则，同时缩小范围：源端口可以是数万级，目的端口通常更小，以反映临时客户端端口与常用服务端口的差异。地址和端口范围必须随结果公开。“随机流量”不是足够的工作负载说明。

第一阶段决定第二阶段测到了什么

第一阶段只允许 Initiator 发包。DUT 进行翻译并创建新连接；Responder 接收报文、记录翻译后的四元组，但不回包。这个过程同时为 DUT 的不可见表和 Tester 的可见状态表装入同一批连接证据。

所有第二阶段的吞吐量、时延、丢包率或包时延变化测试之前，都必须完成第一阶段。预置速率应安全低于最大建连速率，否则准备过程本身就变成压力测试。于是方法要求先测最大建连速率，再选择更低的预置速率。

RFC 9693 刻意区分两种极端状态。测建连速率时，每个报文使用不同四元组，UDP 超时长于第一阶段，确保每个报文都要求新状态且旧状态不退出。测稳态转发时，第一阶段必须枚举完整 tuple 集合，超时还要覆盖第一阶段、阶段间隔和第二阶段，确保计时区间既不新建也不删除连接。

这不是在模拟所有互联网流量，而是在把“创建状态的成本”和“穿过既有状态的成本”拆开。

正向收到，不等于连接已经可反向使用

黑盒测试不能直接读取 DUT 表项。第一阶段的所有报文即使都到达 Responder，也不能保证每个连接仍存在：建连速率可能过高，表项可能被替换，容量或垃圾回收也可能介入。

验证必须反向进行。Responder 从自己的状态表中逐项取出四元组，以带安全系数的较低速率各发一个报文。全部到达 Initiator，才证明这批受测连接在当时存在，而且正向创建速率与反向验证速率都适合。

边界同样重要。反向丢失不能自动写成“状态表已满”。可能是第一阶段的 R 太高，可能是验证阶段的 r 太高，也可能是 DUT 拒绝新连接、按 LRU 替换旧连接，或满表时批量清理。测试看到的是结果，不是内部原因。

容量首先是区间，而不是营销整数

容量测试从一个确定安全的连接数 C0 和经过验证的建连速率 R0 开始。先指数增加连接数，直到 DUT 崩溃或建连速率严重下降，再用二分搜索把容量收窄到显式误差 E 内。

不同替换策略会产生不同的幸存序列。拒绝新表项会保留早期连接；LRU 会保留后期连接；批量垃圾回收可能让成功验证数低于真实物理容量。一个精确的“收到 N′ 个”并不总等于内部表大小。

拆除也需要独立计量。把已装入的 N 个连接通过实现特定的带外动作删除，以 N 除以耗时得到拆除速率。一次清空整张表与逐项删除的成本可能不同。吞吐量无法替代这项记录。

顺序、时间和 CPU 都属于结果

Responder 的状态表不是中性记事本。RFC 9693 建议轮询写入，使记录持续刷新并与 DUT 状态接近；读取建议伪随机，也允许成本较低的轮询。递增、递减或其他固定顺序可以作为额外实验，因为顺序可能暴露哈希、缓存或替换效应。

超时决定表项是否仍在；阶段长度和间隔决定它是否过期；CPU 核数与亲和性决定软件实现如何扩展；hashsize、nf_conntrack_max、硬件、网卡、操作系统、内核和实现版本都可能改变数字。报告必须保留这些输入。

实验还必须重复。RFC 建议报告中位数、第一和第 99 百分位、重复次数以及二分搜索误差。这样得到的不是一句“很快”，而是可以再次执行的受限声明。

UDP 是测量边界，不是互联网的替身

经典方法使用 UDP，是为了在不违背 TCP 拥塞控制和流量控制的前提下提供任意恒定帧速率，也避免三次握手引入额外状态。但 NAT 对 UDP 与 TCP 可能使用不同超时和代码路径。RFC 9693 明确警告：UDP 结果未必刻画互联网转发；HTTP/HTTPS 等协议应参考 RFC 9411 的方法。

所以，第二阶段零丢包只证明：某一 DUT、软件版本、配置、tuple 集合、顺序、超时、流向、速率和 CPU 分配，成功处理了一个受限工作负载。它不证明内部表与猜测一致，不证明真实用户流量有相同分布，不证明 TCP 表现，不证明生产余量，更不证明业务完成。

这种克制不是基准的缺陷，而是可比性的来源。标准提供共同语法，运行代码提供观测，管理者必须保留两者之间的证据链。

来源