摘要

  • RFC 3423 把传输层 ACK 与 CRANE DATA ACK 分开：前者帮助发现丢包和无响应服务器，后者只确认接收端已经正确处理记录，并把计费信息放入持久存储。
  • 即使 DATA ACK 已经推进，也不能直接推出完整账单。DSN 是否连续、是否切换过备用服务器、重复记录是否消除、模板版本是否一致、通道是否安全以及下游是否正确计费，都需要独立回执。

两个绿灯之间的一次坠落

设想网络设备发出一条使用量记录。可靠传输把字节交给远端，ACK 返回，链路图变绿。就在接收进程准备写盘时，它崩溃了。此时“分组已送达”是真话，“计费记录已安全保存”却是假话。

RFC 3423正面处理了这个瞬间。它在 2002 年 11 月发表，记录的是 XACCT Technologies 的 Common Reliable Accounting for Network Element，简称 CRANE。它的纯文本版本、RFC Editor 资料页、IETF 文档页、历史记录、引用关系与勘误检索共同限定了它的身份：这是一份 Informational 文档，不是 Internet Standard；它说明一种厂商提出的协议，不证明今天仍有多少系统部署它。

CRANE 面向网络设备向中介、BSS 与 OSS 大批量输出计费或其他记录。它真正值得保留的历史问题不是某家公司是否成功，而是一个精确的证明边界：谁有资格说“已经到达”，谁有资格说“已经处理并持久化”。

传输栈不掌管账本

CRANE 要求底层传输可靠、面向连接并保持顺序。TCP 可以承担；文档也允许并偏好当时 RFC 2960定义的 SCTP，理由包括消息边界、认证能力和更快的连接故障检测。这个“偏好”只属于 2002 年规范，不能拿来推断实际采用率。

规范明确说，传输层确认用于快速发现丢失的数据包与无响应服务器；CRANE 层则在消息被处理、计费信息进入持久存储以后再确认。第一个 ACK 观察的是通信；第二个 ACK 声称的是应用状态。

RFC 2975对计费管理的整体问题已有更宽的讨论，其中包括非易失存储、重复消除与代理确认的风险。RFC 3423 的贡献，是把其中一段做成可以在协议上看到的分界。可靠传输只能把责任送到应用门口，不能替应用签收账本。

DATA ACK 是一条连续前沿

每个 DATA 消息带有 Data Sequence Number，也就是 DSN。客户端启动或切换服务器后，用首条消息的 S 位标明 DSN 同步点；每创建一条新 DATA，号码增加一。服务器只接受按序记录，遇到越序消息就丢弃。

DATA ACK 携带的是“最后一条已正确处理、且处在连续序列中的 DSN”。它不是接收端看见过的最大数字。假如 3122 尚未到达，即使 3123 已经撞到门口，也不能把确认前沿写成 3123。服务器会重发当前 ACK，促使客户端立即补发缺口。

这张回执比传输 ACK 更接近计费记录，却仍然有限。它没有证明号码对应正确用户，没有证明费率计算正确，没有证明已生成或结清发票，也没有承诺存储介质永远不会在以后损坏。它只是在特定会话、特定接收端和特定时间上，声明连续处理与持久写入已经推进到哪里。

完整序列不一定存在于同一台服务器

一个 CRANE 会话可以配置多个有优先级的服务器。客户端向自己认为正在运行且优先级最高的接收端发送。若所有服务器都不可用，记录留在客户端队列中，直到某台恢复或队列耗尽；后者应该触发告警。

切换可能由四类证据引发：传输层报告端口无响应；未确认记录的总字节数超过阈值并持续到定时器期满；当前服务器发送 STOP；或者更高优先级服务器恢复。规范提供信号和机制，却把具体切换算法留给实现。

文档给出的数字例子非常重要：服务器 1 先收到 3042 至 3095；服务器 2 收到 3096 至 3122；服务器 1 又从 3123 继续。没有任何一台单机保存完整片段，但发送端仍有责任让中介或计费系统得到完整序列。

重发还会产生重复候选。记录若改投另一服务器，DATA 中要设置 Duplicate 位；下游利用 DSN 去除重复。这个位只表示“可能是重发”，并不证明另一份副本真的存在，更不证明去重已经执行。可用性通过多路径提高时，唯一性风险也会跟着增长。

持久保存错误解释，仍然是错误

为了减少每条记录的描述开销，CRANE 先协商模板。模板定义字段的顺序、类型和含义；某个 key 可以启用或停用。同一会话的客户端和所有服务器应共享相同模板集合与相同启停状态。

每条记录同时带 Template ID 与 Configuration ID。只有两者结合，接收端才知道用哪一版结构解释字节。服务器可以保留一小段旧配置历史，应避免“未来配置”的消息提前到达；模板变更前，也应该等待旧配置下的 DATA 获得确认。

模板谈判还规定了控制权。服务器只有一次提出修改的机会；客户端决定最终集合，并向所有服务器发送 FINAL TMPL DATA；接收端此后必须接受并确认，不得再次修改，从而避免在冗余节点间无限循环。

所以，写入磁盘的字节完全无损，也可能因为配置上下文丢失而失去意义。存储完整性、模式一致性与业务语义是三件事。

同时代的计费协议不是同一种回执

RFC 3423 在引言中比较了 RADIUS 与 Diameter。RFC 2865描述 RADIUS 访问，RFC 2866描述 RADIUS Accounting；之后的 Diameter 基础协议先见于 RFC 3588，再由 RFC 6733取代。RFC 3334则讨论策略驱动计费的要求。

更晚的 IPFIX 文档提供另一组背景：RFC 7011定义协议，RFC 7012定义信息模型，RFC 7013讨论实现与部署考虑。这些资料显示高吞吐记录、模板与可靠性问题反复出现，却不能证明 CRANE 与后来系统之间存在实际部署继承或互操作。

规范中的 MUST、SHOULD 等词遵循 RFC 2119。MUST 证明文档要求了什么，不证明任何具体程序已经遵守。

DATA ACK 没有附带强安全保证

RFC 3423 的安全章节承认，协议本身不提供强机密性与完整性。静态配置客户端与服务器地址，可以形成管理上的信任清单，但若没有额外保护，仍会受到地址欺骗影响。文档建议按环境使用 IPsec 或 TLS 等底层安全服务。

因此，收到 DATA ACK 不自动证明对方身份，也不自动证明消息未被改变，更不代表这台服务器有权作出财务决定。端点认证、通道完整性、模板一致、持久写入和账务接受必须分别观察。

来源、方法与边界

本文还采用 Heng Lu 关于现实层次与运行代码优先的分析方法：规范、实现、配置、收到的字节、磁盘状态和业务结果互相关联，却不能相互替代。

这些来源足以解释协议语义与历史位置，不足以证明当前部署、普及程度、实测性能、具体事件或仍在销售的产品。把历史机制写清楚，不等于替它制造当代事实。