摘要

  • RFC 9565 把 IPFIX 信息元素 6 的解释连接到 IANA TCP Header Flags 注册表，并要求按观察结果导出已分配和未分配的控制位。
  • 输出位图是流内所有包的按位“或”：置位只表示至少一次出现，不保留顺序、方向、次数或同包共现关系。
  • 要据此作出 TCP 状态判断，必须另行保留 Template、字段长度、观察时期、导出器能力、方向和包级或端点级凭据。

数据库里只有一个整数。分析界面把它翻译成 SYN、ACK、FIN，于是读者脑中自动补出一次完整连接：发起、确认、传输、关闭。真正发生的也可能是另一回事——SYN 在超时前被反复重传，ACK 来自相反方向，FIN 只在观察窗口末端短暂出现。两段完全不同的历史，经按位聚合后可以得到同一个值。

RFC 9565 解决的是一项真实的互操作问题。旧定义把一份 TCP 标志位快照写进 IPFIX 文本，而位的权威分配会继续演进。新规范保留 unsigned16 的 flags 语义，让实现查阅 IANA 的 TCP Header Flags 注册表，并要求无论某一控制位已经分配还是尚未分配，只要量测过程看见它，就应当如实导出。

这是对“看见了什么”的改善，不是对“事情怎样发生”的复原。

位图是一张存在性收据

规则很窄：某个 Flow 的任一被观察包带有某位，输出中的该位就设为一；否则清零。聚合完成后，无法知道由哪个包贡献、出现几次、两个标志是否同处一包、来自哪个端点，也无法知道谁先谁后。

因此，SYN 与 ACK 同时出现在位图中不等于三次握手完成。RST 出现不等于能够判断谁终止连接。FIN 与 ACK 并存也不等于正常关闭。Flow 是量测系统依据键值、观察点、方向规则及活动/非活动超时划定的记录；TCP 状态机则运行在端点。两者可能有关联，却不是同一权威。

将 tcpControlBits 用作候选筛选很合理，例如找出出现罕见控制位的流。风险在于自动化越过证据边界，把“至少看见一次”升级为“已建立”“已响应”或“有恶意意图”。

长度不是编码细节，而是可见范围

IPFIX Data Record 依靠 Template 解释，Template 同时声明信息元素及长度。RFC 9565 允许缩减尺寸：如果 tcpControlBits 只用一个八位组，它仅覆盖位 8 至 15，对位 4 至 7不作断言。无法量测完整宽度的进程应使用这种形式，而不是伪装成看见了十六位。

若采集器在入库时一律扩成十六位整数，并丢掉原始长度，未被观察的上半部分便会成为看似确定的零。“不知道”被改写为“确认不存在”。所以 Template 标识与序列、Observation Domain、导出器版本及生效时期必须和数值一起保存。

最低四位也不能随意命名为标志。它们对应 TCP Data Offset 区域，在 tcpControlBits 中必须清零或忽略；头部长度应由 tcpHeaderLength 表达。把十六个位全部等同处理，会制造注册表从未授予的含义。

注册表在前进，运行中的设备不会同步换代

RFC 9293 记录常见的 CWR、ECE、URG、ACK、PSH、RST、SYN 和 FIN。RFC 8311 又改变了一个此前与 NS 实验用途有关的位置。更早的 RFC 7125 路径曾要求某些位置输出为零。于是今天读到的零具有多种来源：包中确实未出现、字段只有八位、旧软件强制清零，或观察窗口根本没有覆盖相关包。

反过来，旧采集器标成“保留”的一位，可能已被 IANA 合法分配，也可能正是值得保存的异常观察。RFC 9565 的选择是先忠实保存，再按相应时代的注册表解释。删除未知位只会让本地词典战胜运行事实。

这正是 Heng Lu 所强调的现实分层。IANA 管理符号权威，RFC 规定互操作合同，运行代码实施量测，包和端点产生网络事实。最终整数只是压缩收据，不能越权成为端点状态、应用结果或完整历史。