摘要

  • RFC 2063 设想，读表器失效时计量器继续工作；重启后可读取仍被保留的累计流量，但漏采造成的时间分辨率损失依然存在。恢复范围还受规则、流状态、内存与计数回绕约束。原始架构第 2.5、3.3、4.5 节
  • 冗余计量器保护测量环节，独立读表器保护采集连续性。异步读数不必完全相同；1999 年进一步明确的多读表器规则，也不能倒推成所有 1997 年实现已有的能力。1997 年架构、1999 年修订

先看一个假设场景：唯一的读表器停机，计量器仍按原规则处理数据包。最后一次成功采集留下旧总数，重启后的采集读到新总数，以及这条流的首次、末次活动时间。假定同一流的状态连续、完整保留，且没有造成歧义的计数回绕，两次累计值之差就能给出跨越停读期的新增用量。这个场景用于解释机制，并非某次真实事故；它对应的是 RFC 2063 第 2.5 节所讨论的读表器失效模型。

谁保存了哪一部分证据

RFC 2063 于 1997 年 1 月发表，作者是 Nevil Brownlee、Cyndi Mills 和 Greg Ruth，所列机构分别为 The University of Auckland、BBN Systems and Technologies、GTE Laboratories, Inc.。它属于实验性文件，明确不构成互联网标准；第 1 节还说明，其任务是组织所需信息、系统要求与实现取舍，而非规定一种协议。原始文件及范围说明

这里的“流”是人为划定的计量单元：独立的 IP 数据包按观察到的属性和配置规则归类，形成带有起止时间、可归属某个对象的一部分流量。归属对象可以是用户、主机、网络或网络组，取决于所选粒度，并不据此成为经过认证的合同付款人。该架构的计数方案将每个被计数的数据包只记入一条流；交叠的分析口径需要更细、互不重叠的分类，再由后处理组合。第 2.1、3.2—3.3 节

管理器设置测量规则、粒度、流表容量、非活动超时和采样参数，也指定读表器应向谁采集、多久一次、读取哪些流和属性。计量器据此选择性记录活动，把累计包数、字节数及首末活动时间留在流表中。读表器负责可靠地传出用量数据，其记录带有计量器标识、时间戳、采集规则标识、流描述与计数，并按计量器存入磁盘文件。分析应用再据这些记录推导速率。几个角色可以共处一台机器，但保存的证据不同；在 RFC 2063 的当时模型中，每个计量器或读表器各受一个管理器控制。第 2.1—2.4、5.2 节

后来的累计值能补到哪一步

第 3.3 节推荐读出后继续累加，而非每读一次便清零，因而后续记录常能覆盖漏失记录中的用量。相减之前仍须检查计量器身份、规则集标识 Rule Set ID、流描述和起始时间：地址相同的后续记录，也可能属于重新建立的流。规则集本身就是解释数据的一部分，单凭计数变大不足以证明它沿用了同一计量口径和同一流状态。第 3.2—3.3 节

首末活动时间划出了活动边界，却没有保存区间内的逐次变化。不同的突发分布可以留下相同的累计值，甚至相同的首末时间。因此，在上述连续性条件成立时，差值除以两次成功采集的时间间隔，至多给出该间隔的平均速率；将其摊成逐分钟曲线，还要加入流量如何分布的假设。这是从记录内容与缺失观测推出的限制，并非 RFC 记载过的故障测量结果。第 2.5、3.1、5.2 节

异步读表留下各自的观察时刻

架构允许随时读取整表、若干行或部分属性，不要求同步。两台读表器即使采用相同周期，只要采集时刻错开，累计记录就可能不同；差异本身不足以证明数据损坏，覆盖同一段用量的累计记录也不能直接相加。独立读表器可以在另一台停止时继续采集；同一网段上的冗余计量器则是在一个测量端失效时继续计数。两者保护的环节需要分别判断。第 2.2、2.5 节

同期的实验性 RFC 2064 在计量器管理信息库（MIB）中规定了独立采集所需的机制：流表索引采用无状态设计，TimeFilter 配合 GetBulk 可读取自上次采集后有变化的行及选定属性。这里并没有一个供所有读表器共享的同步快照。flowReaderLastTime 在一次遍历开始时写入，并与 flowReaderPreviousTime 配合辅助回收判断，不能据此认定整张表的读取已经完成，或得到的是同一瞬间的一致快照。注册或相关写入的认证失败时，读取仍可能继续，而非活动流的回收可能受阻。RFC 2064 第 3.2 节及读表器信息表

流表会回收，年份也不能合并

累计状态的寿命有资源约束。RFC 2063 第 3.2 节要求闲置流至少被一个读表器采集后才回收；第 4.5 节以 LastCollectTime 和非活动控制讨论保留策略，并将多读表器所需的最少采集者数目或指定名单留待进一步完善。流表触及内存高水位时，可以切换到粒度更粗的备用规则集，并缩短采集间隔以加快回收。第 4.6、5.3 节还讨论了为维持计量器运行而承受短暂数据损失的可能。因此，读表器重启后的恢复能力始终受仍存状态限制。RFC 2063

RFC 2064 已用登记表追踪读表器，依据各登记读表器的采集情况安排回收，并用 flowReaderTimeout 删除超时登记行；它也区分由主管理器负责的全局控制项。1999 年 10 月的信息类文件 RFC 2722 取代 RFC 2063，在架构层面进一步写明各读表器的上次采集时间、等待所有登记读表器采集后回收，以及失败读表器的超时移除，同时允许并行规则集与多个管理器。不能把不同文件里的控制规则压成一个没有年代差别的模型。同期 MIB、后续架构第 2.3—2.4、4.5 节

规则集切换也有明确边界。RFC 2064 已提出在单个计量器上切换到内容相同、编号不同的规则集以取得快照效果；RFC 2722 第 2.5 节进一步说明，可交替使用两份相同规则集，让读表器读取停止累加的旧集，从而取得一致的旧集记录，但不能保证多个计量器同时切换。这是有时点、有范围的文献说明，不是所有 1997 年部署都已具备这些行为的证明。RFC 2064 第 3.2 节、RFC 2722 第 2.5 节

恢复止于尚存的状态

RFC 2063 第 6.3 节分别处理各类失效：管理器停机时，计量器与读表器应继续工作；计量器计划停机前可请求最后一次采集；意外重启则可能经通知或读表器轮询被发现，再装回正确规则。恢复配置无法重建未被测量的流量或已经消失的状态，拟议的通知也不保证送达，更不自动构成经过认证的证据。异常情况处理

这套架构没有固定数据传输协议，SNMP 是一种可选路径；完整性与保密性要由管理和采集协议提供。它把费率、公平性、激励及成本回收目标留在范围之外，用量记录也不足以证明收费授权、账单效力、有效交付或付款。本文所追问的边界更窄：记录仍在时能确认多少用量，缺少中间观察时还能确认多少时间细节。第 1、5.3、10 节

来源与适用范围

这些文献支持架构机制、文件地位与修订关系，不能据此认定当下采用率、产品兼容性或与其他流量技术的谱系。Lu Heng 的三篇文章属于后来的解释视角，分别帮助区分发表与实际运行、共同语义与本地选择、结构描述与方案倡议；它们不提供 1997 年的部署证据，也不能证明历史作者的主观意图。

RFC 2063：原始架构：1997 年 1 月实验性文件，本文角色分工、累计计数与故障恢复模型的主要依据。

RFC 2063：官方记录：标注实验性地位，并注明已被 RFC 2722 取代。

RFC 2063：官方勘误查询：无匹配勘误记录并不证明设计完善，也不能代替对恢复条件的核查。

RFC 2064：同期计量器管理信息库：1997 年 1 月实验性 MIB，用于核对独立扫描、读表器登记、采集时间与回收条件。

RFC 2722：后续架构修订：1999 年 10 月的信息类文件，保留停读造成时间分辨率损失的说明，并进一步明确多读表器生命周期与单个计量器内的规则集切换。

RFC 2720：后续计量器管理信息库：1999 年 10 月的 MIB，仅作后续背景，不据此认定现代部署。

RFC 1272：流量测量的背景：1991 年 11 月的架构理由与背景说明，区分计量和成本回收政策。

Lu Heng：运行代码与实际采用：后来的解释框架；本文借其区分文本发表与实际采用的判断，限定架构文件能证明什么。

Lu Heng：最低共同约定与本地选择：后来的观点；本文仅借其关于共同规则、本地业务安排和实际采用的区分，审视测量语义与采集、保留选择的关系。

Lu Heng：以现实而非倡议为产品：后来的编辑立场；在本文中的有限用途是交代结构和假设，而非为某套运营安排背书。