摘要

  • RFC 3539 要求 AAA 代理和服务器假定重复事务可能从任何连接到达。备用连接上的副本甚至可能先于原连接上的消息到达；连接被判定故障，并不能证明原事务已经死亡。
  • 对依赖既有状态的认证，同一逻辑请求可能先得到 Accept，随后在另一台服务器得到 Reject。端到端标识、重复处置、客户端选答、NAS 执行、计费去重与用户结果必须分别留下收据。

高可用流程最容易制造的语言错觉，是把“重发”说成“转移”。真正发生的动作往往不是把一份工作从旧路径搬走，而是在无法确认旧路径结局时，把同一份工作再交给一条新路径。旧副本没有因此消失，旧服务器也没有因此失去完成权。

2003 年 6 月发布的 RFC 3539 是 Proposed Standard，标题为《认证、授权与计费（AAA）传输配置》。它没有报道某家运营商的故障，也没有声称某个 Diameter 或 RADIUS 系统发生过相反回复。它提供的是一条很窄却很重要的证据边界：传输恢复不能替认证结果签字。

连接故障与事务消亡是两条时间线

AAA 客户端可以同时具备多个代理或服务器连接，把它们设为主备，也可以在它们之间分担负载。当客户端决定切换时，原连接上的分组未必已经全部离开网络。备用副本可能先到，原副本也可能稍后到达。

因此，RFC 3539 明确要求代理和服务器准备处理重复，并假定重复可能从任何连接出现。连接五元组、TLS 会话或者某一跳的 socket，只描述传输路径；它们不是业务意图的唯一身份。

主连接关闭，只能证明一个本地通信关系结束。它不能证明远端服务器没有收到请求，不能证明代理没有向下游转发，也不能证明一个已经作出的答复不会迟到。备用连接恢复，只能证明新路径可用；它不能证明系统现在只有一份待决工作。

审计至少要保存两种时钟：对等体失效时钟和逻辑事务存活时钟。把前者当成后者，正是“切换完成所以原请求不存在”这一错误结论的来源。

Watchdog 只对直接对等体有管辖权

RFC 3539 要求 AAA 协议支持应用层 watchdog，用来更快发现传输故障或直接对等体的应用功能故障。它刻意不把下游代理、服务器或数据库的状态纳入同一判断，也不是集群心跳。

来自对等体的任何 AAA Response 都可以被当作它仍然存活的证据。反过来，普通业务请求没有答复，并不足以宣布对等体宕机，因为沉默可能来自更远处。按文档描述，只有对 watchdog 请求也不答复，才支持相应的失效转换。

这个范围限制有助于避免下游抖动向上游扩散，却也限定了监控结论。收到 watchdog 答复，只能说明相邻应用端点完成了一次存活交换。它不能证明 home realm 可达，不能证明授权库新鲜，不能证明另一个副本看到了相同状态，更不能证明 NAS 已经放行用户。

定时器也不是单纯的“越快越好”。文档给出的未加抖动默认 Twinit 是 30 秒，允许最低降到 6 秒（不含抖动），但警告过短间隔会提高重复和误切换、误回切的概率。更早放弃真正失效的对等体，意味着也更早复制一个只是延迟的请求。

所以，定时器配置是在分配风险：等待风险留给用户，重复风险留给决策系统。它没有消灭风险。

Pending queue 只知道“我还没收到答案”

为了执行故障转移，客户端或代理需要为每个对等体维护待处理消息队列。收到与请求匹配的回答后，队列删除该项；启动切换时，仍在队列里的消息会被发送给可用的备用代理。

队列的知识非常有限。“待处理”表示本节点还没有看到可以关单的回答，不表示远端没有执行。请求可能已经越过远端提交点，Accept 可能正在旧路径上返回，也可能卡在代理之后。队列无法通过本地缺少回答来推断这些事实。

因此，重发收据要保存切换触发条件、watchdog 代次、原对等体、备用对等体、切换前队列快照、请求内容摘要、端到端身份、重传标志与两次发送时间。只写“重试一次”，会把原样副本、重新构造、改变目标和改变内容混成一件事。

RFC 6733 在后来的 Diameter Base Protocol 中继续引用 RFC 3539 的传输失效算法。它要求在可能的情况下把待处理请求发往备用代理，并用重传请求标志说明这一状态；它也提醒故障转移可能产生多份相同请求或回答。

Hop-by-Hop 与 End-to-End 不能相互代替

Hop-by-Hop Identifier 用于一段相邻交换，让节点把回答与自己的待处理请求对应起来。End-to-End Identifier 与 Origin-Host 的组合用于跨代理识别重复。前者回答“哪个本地队列项可以退休”，后者回答“这些不同路径上的消息是否属于同一逻辑请求”。

这两层身份都重要，却都不是唯一执行保证。端到端标识不是加密认证，不证明请求新鲜，不锁住所有服务器，也不自动回滚已发生的效果。它能把证据聚在一起，不能替证据作出处置。

当服务器发现重复时，真正困难的工作才开始：返回缓存答复，复用已经持久化的决定，等待权威节点，拒绝重新求值，还是再次运行策略？RFC 6733 规定重复请求通常应返回相同答案（除逐跳细节），目的正是阻止同一逻辑工作变成第二次随意决策。

但这一规则需要可查的持久决定。如果第一次答复没有保存、缓存已经过期、两台服务器共享状态滞后，公共标识不能凭空创造一致性。识别重复、抑制重复、协调冲突和补偿副作用，是四个不同控制面。

Accept 与 Reject 可以分别自洽

RFC 3539 对计费与认证作了有用区分。计费重复可以借助 Accounting Session-Id、Event-Timestamp 和 NAS 身份清理。这个例子本身就在说明：相同事件需要多维身份，而不是只看某个传输分组。

认证请求则可能依赖先前建立的状态。文档举出同时在线限制：第一份请求到达时，用户尚未被认为已经登录，所以得到 Accept；它建立或触发了状态变化。重复副本随后到达另一台服务器，该服务器看到用户已经在线，在只允许一个会话的规则下返回 Reject。

两台服务器都可能正确执行了各自看到的状态。冲突来自状态时间差和非幂等操作，而不必来自恶意或软件损坏。

客户端如果同时收到两份回答，RFC 指出结果会取决于谁先到。于是，一个本来没有写在授权政策里的因素开始决定访问：网络延迟。备用服务器靠得更近，Reject 可能抢先；旧路径上的 Accept 如果更早到达并被 NAS 应用，后来的 Reject 又可能只剩下告警价值。

这是文档描述的机制示例，不是现实事故证明。管理层应该从中得到的结论是：如果到达顺序可以决定结果，就必须把选答规则写出来、记录下来，或者在服务器端让重复永远返回同一持久决定。

只保存“赢家”会销毁冲突证据

客户端日志不能只写最终使用的 Result-Code。每份回答都应包含发出服务器、对应端到端身份、服务器状态 epoch、适用限制、重复查询结果、决定提交时间和到达时间。客户端再单独记录验证、排序与选答规则。

“最先到达”也需要定义。是进程先读到、先通过认证检查、先写入本地状态、先发给 NAS，还是先在 NAS 生效？并发系统里，这些次序可能不相同。

保留落选回答不是为了制造噪声，而是为了分清三类问题：传输层重复、策略层不一致和执行层竞态。没有落选回答，运营团队只会看到一次普通 Accept 或普通 Reject，无法知道高可用路径曾经让同一请求获得两种裁决。

一份可靠选答收据至少要写：收到哪些回答、各自如何通过完整性与关联检查、是否属于同一身份、选择了哪一份、根据哪条规则，以及另一份如何处置。

Accept 还没有变成访问

服务器返回 Accept，只证明它在自己的协议和状态边界内作出了允许决定。NAS 仍需验证回答、把它绑定到待处理请求、安装访问属性或配置，并改变实际会话状态。用户还要能通过数据面使用服务。

Reject 同样有限。如果另一份 Accept 已经被执行，迟到的 Reject 不能倒推出“用户从未获得访问”。它可能触发清理，也可能被识别为重复后丢弃，还可能成为未解决的矛盾。

计费又有独立证据面。Session-Id、事件时间与 NAS 身份要与去重处置绑定，随后才能判断审计或账单是否只计算一次。收到 Accounting-Start 不等于计费正确；丢弃一个重复也不等于之前没有产生双重副作用。

完整链条包括：逻辑请求、直接对等体存活、故障转移复制、每台服务器的决定、客户端选答、NAS 执行、计费处置和用户结果。每个所有者只能为自己的表面签字。

不把 Diameter 字段写成 RADIUS 的旧名字

经典 RADIUS 使用自己的事务坐标：单字节 Identifier、Request Authenticator、传输上下文和共享秘密参与请求回答匹配与重传。RFC 2865、RFC 2866 和 RFC 5080 约束这些机制。

它们不是 Diameter Hop-by-Hop Identifier、End-to-End Identifier 与 Origin-Host 的前身别名。本文不重复已有的 RADIUS 事务身份主题，而是处理 RFC 3539 所描述的跨连接副本和依赖状态的第二次决策。

两套协议共享的抽象原则只有一条：副本必须带着足够身份继续代表同一意图；系统还必须保留足够决定状态，防止同一意图获得多个效果。

一份可复核的故障转移收据

第一层保存请求：源身份、端到端键、不可变内容摘要、用户或会话范围、应用与创建时间。第二层保存直接对等体：连接代次、最后有效回答、watchdog 请求与回答、timer、jitter 和失效分类。

第三层保存复制：旧对等体、备用代理、队列快照、重传标志和发送时间。第四层在每个服务器保存状态版本、适用约束、重复查找、是否复用既有决定、发出结果与提交时间。

第五层由客户端保存全部回答、关联检查与选答。第六层由 NAS 保存实际配置与访问状态。第七层把计费事件与会话、NAS 和去重处置连接起来。第八层观察用户服务。

管理报告可以精确表述为：“这个直接对等体没有回答这次 watchdog；这些仍待处理的逻辑身份被复制到这个备用代理；多份服务器决定按这条规则协调；NAS 应用了这份回答；会话与计费得到这些观察。”少一层，就写明未知。

证据边界

本文不指认任何运营商、供应商、AAA realm、RADIUS 或 Diameter 部署、账户、登录、NAS、事故、宕机、安全事件、重复收费或受影响用户，也不报告采用率、现行配置、实测延迟或相反回答发生频率。

RFC 3539 被准确描述为 2003 年 6 月的 Proposed Standard。RFC 3588 只作为历史 Diameter 背景，已经被 RFC 6733 取代。RFC 6733 保留失效算法和重复身份规则，不证明任何命名系统正确实现。RFC 8174 约束规范性术语，RFC 6298 提供重传计时背景，都不是 AAA 运行事实。

Lu Heng 关于运行代码优先和最小初始规范的文章是公开说明的编辑视角，用来区分文本、实现、本地决定与观察结果。它们不证明 RFC 作者意图，也不证明部署事实。

有限结论是：故障转移可能在原请求消失之前复制同一 AAA 请求。共同身份让副本可被识别；只有幂等处置、显式选答、执行收据与结果观察，才能证明效果只有一次。

来源