摘要

  • 2026 年 9 月发布的 RFC 10052 新增可选控制 TLV，发送方可请求反射包的长度、数量和包间隔。
  • C 标志只说明反射器是否因出口 MTU 或本地速率、总量上限而缩减响应；它不是容量、路径或应用成功的判定。
  • 探测流量可以更接近某些应用流量特征，但“更接近”不等于“代表”，更不等于已经测出用户体验。

“请求八个，收到八个”是一个完整句子，也是一句很容易被滥用的话。它完整地描述了一次收包记录，却没有说明这八个包代表哪个应用、哪条路径、哪类队列，以及哪个用户结果。

RFC 10052 在 2026 年 9 月成为 Proposed Standard。它为 STAMP 增加一种非对称响应能力：一个 Session-Sender 发出一个测试包，Session-Reflector 可以按请求返回不同长度或多个响应包。标准使用的措辞是让测试“更接近”应用流量条件。这里的“更接近”是工程手段，不是等价证明。

三个字段先是一份委托

新的 Reflected Test Packet Control TLV 在 IANA STAMP 注册表中编号为 12。它继承 RFC 8762 的基本 STAMP 交换，也使用 RFC 8972 的扩展框架。发送方填入期望的反射包长度、包数量和相邻响应之间的纳秒间隔。

但这三个数只是委托。反射器先计算协议允许的实际长度：它不能小于当前模式和所有相关扩展所需的最小包，也要做四字节对齐。如果计算结果超过出口接口 MTU，它不会硬发所请求的序列，而是只回一个 MTU 大小的包。

数量同样受本地权力约束。支持该 TLV 的反射器必须限制单次请求引发的数据速率和总数据量。请求越界时，它只回一个包。请求数量为零时，默认不返回响应并丢弃请求，尽管本地策略可以另作处理；如果目标本来就是“不回复”，RFC 更推荐专门的 Return Path 控制方式。

这套设计没有把反射器变成远程流量放大器。代价是监控系统必须分栏：请求了什么，反射器接受了什么，实际发出了什么，采集端最终看到了什么。把四栏合并为一个“包数”，会把安全边界改写成假确定性。

C=0 不是绿色通行证

IANA 把第 3 位分配给 C 标志，名称为 Conformant。发送方发包时必须把它置零，反射器忽略收到的值。反射器只在两类例外中把 C 置一：所需长度超过出口 MTU，或者所需速率/总量超过本地上限。其他情况下，各响应包中的 C 保持为零。

单个响应包的长度还能帮助判断是哪一类例外：短于所请求长度，指向 MTU；长度仍等于请求值，指向速率或总量限制。这是一张很清楚的本地处理凭证。

它仍然不是端到端凭证。C=0 不说明序列全部到达，不说明中途没有改路、丢包或排队，也不说明应用使用相同五元组、DSCP、负载分布和节奏。C=1 更不能直接翻译为“网络容量不足”，因为触发它的可能只是反射器主动设置的保守上限。

Lu Heng 在现实层级中强调，符号、制度、执行和结果不能互相替代。映射到这次测量：TLV 是指令层，C 是反射器声明，接口计数器是本地执行记录，抓包是观察记录，应用遥测是应用记录，客户行为才是结果记录。屏幕可以把它们画在一张图上，证据却不能因此跨层。

凭证 能证明什么 单独不能证明什么
控制 TLV 发送方请求了某种响应形状 反射器实际发出了它
C 标志 两类规定例外是否被触发 链路通过容量测试
反射器计数 本机记录了响应发送 包已抵达采集器
采集端抓包 此观察点看到了这些包 应用经历了同样条件
应用遥测 指定工作负载出现某种表现 所有应用或路径都会如此

RFC 给出旋钮，没有给出最终指标

RFC 10052 第 4.1 节明确把接入速率指标和测量方法排除在范围之外。它实现的是 RFC 7497 提出的控制需求，例如非对称包大小和速率。怎样把这些包转换成容量结论，仍需另一个完整方法。

RFC 7497 还区分业务在线时的 In-Service 测试与停业或维护窗口中的 Out-of-Service 测试。探测包若与用户流量特征不同，可能受到不同处理；探测流量过多，又可能制造拥塞、扭曲自己的结果。RFC 7799把主动测量定义得很直白：它会生成专用流量。因此，仪器不是透明观察窗，它进入了被测系统。

RFC 9097 与 RFC 9946 分别提供更具体的单向 IP 容量方法和 UDP 速度测试协议，讨论逐步加压、端点位置、背景业务和负载调整。正因为这些条件不可省略，一串完美响应只是一种测量输入，不是自己签名的容量报告。

多播筛选不是用户抽样

在多播网络里，一个根节点的请求可能让多个叶子反射器同时回复。RFC 10052 定义二层与三层 Address Group 子 TLV，可以按硬件地址掩码或 IP 前缀缩小响应范围。文中甚至给出“十六个中命中一个”的掩码示例。

这句话不能改写成“随机抽到十六分之一用户”。地址往往与设备厂商、部署批次、区域或拓扑相关。确定性掩码能降低负载、复现实验，却不自动获得统计代表性。要谈代表性，必须另有总体、抽样框、偏差说明和分母。

多播还把放大风险变成真实控制问题。标准要求速率约束，建议第一次控制请求只要一个响应，并要求该能力可由管理员控制且默认关闭。伪造请求可能被用来制造拒绝服务，因此必须保护身份，并建议采用 STAMP 认证模式或 HMAC TLV。RFC 8085提供 UDP 负载的通用约束。

采集器的位置也是实验条件

配合 RFC 9503 的 Return Path 与 Return Address 机制，响应可以发往独立采集器。RFC 7594 的 LMAP 框架为测量代理、控制器和采集器定义角色。RFC 10052 举例说，测试包的去程可能贴近摄像头视频流，返回包则去往另一处分析。

这个例子恰好提醒我们：返回路径被有意分开了。采集器只能证明自己在某个时钟和观察点收到了什么。即使去程相近，探测流也可能命中不同哈希、队列和策略。若要说“代表视频应用”，还必须取得视频侧路径与应用凭证。

Datatracker 正式记录、草案历史和 IETF 9 月活动报告证明了规范如何完成发布。RFC 当前状态页、纯文本与 XML让字段语义可核验。它们都不是部署普查。

Lu Heng 的运行代码优先要求把规范落到具名实现、版本、配置与回读结果。最小初始规范说明，RFC 保持控制面的最小化并非缺陷：指标、阈值和采用决定应该留在本地。代理问题则要求逐一标明谁选了包形、反射上限、地址组、采集点和解释规则。

八个包可以是高质量证据。前提是管理层不让它替第九张尚未取得的凭证说话。

Sources