摘要

  • 对等待更新答复的既有会话，RETRY_AND_TERMINATE 在 Tx 到期时允许服务继续，并保持 PendingU；之后若出现发送失败或协议定义的临时错误，才终止服务。
  • 生效策略可能覆盖本地配置；迁移既有信用控制会话，还必须满足故障转移许可与状态处理要求，不能只验证备用服务器是否可达。

“重试，然后终止”听起来像一条很坚决的规则。但在 Diameter 的信用控制过程中，规则名称没有说出全部时间顺序：一个计时器已经到点，服务仍可以继续，请求也仍然没有结案。此时发生的消耗不是仪表盘上的一个待处理符号，而是已经交付出去的服务。

这不是对某家运营商事故的描述，而是标准明确容纳的一种行为。范围也必须说清：会话已经建立，客户端发出更新请求，正在 PendingU 状态等待答复。在 RETRY_AND_TERMINATE 下，应用计时器 Tx 到期的动作是允许服务、继续留在 PendingU；后续若确定发送失败，或收到协议所定义的临时错误，则终止服务并转入 Idle。RFC8506 第 7 节表 4给出了这组转换，第 5.7 节解释相应的失败处理过程。

因此，管理问题不宜停留在“故障时放行还是阻断”。更有用的问法是：究竟哪个事件结束了继续提供服务的容忍？谁批准了前面的等待？最终成功的答复，是否把等待期间的消耗从管理视野里抹掉了？

请求还在等待，服务已经发生

按会话进行的信用控制，包含单位预留、中间更新和最终用量报告。这里的单位不必是钱，可以是时间、数据量或者服务数量。第 5.3 节说明，额度被消耗、有效期届满以及某些服务条件变化，都可能触发中间请求；为减少中断，也可以提前提出请求。它是围绕用量和授权展开的持续交换，不是每次都从零开始的余额查询。

下面的三个事件，只描述采用 RETRY_AND_TERMINATE 的既有会话更新，不能套用于所有初次接入。

更新等待期间发生的事件 标准规定的处理
Tx 到期 允许服务，仍处于 PendingU
收到成功的更新答复 停止 Tx，回到 Open
发生发送失败或收到临时错误通知 终止服务，进入 Idle

“临时错误”在这里是协议中的错误类别，并不是对响应慢的随口形容。“发送失败”则包括无法与目标及适用的备用目标通信、请求最终超时等情形。若把这些都归为一个笼统的“超时告警”，就会丢掉同一策略先继续、后终止的原因。

第 13 节建议 Tx 取十秒，但建议值不是任意运营网络的实测配置，也不是保证最多承担十秒消耗的上限。额度有效期对应的 Validity-Time、服务器会话监督所用的计时器，又各有用途。不能把几个不同位置的时钟拼成一个未经验证的统一服务承诺。

继续服务同样不等于客户端凭空增加了一笔无限额度。第 5.3 节把已报告用量与随后获得的新授权连接起来；报告旧用量后、拿到新授权前，客户端并不因此自动拥有一笔新的可用单位。标准中的临时服务动作，应放在这个交换过程内理解，而不是解释成免费使用权。

三种策略，不是一张全局通行证

第 8.14 节列出 TERMINATE、CONTINUE 和 RETRY_AND_TERMINATE；没有收到故障处理属性时，默认使用 TERMINATE。在 PendingU 中，TERMINATE 会在 Tx 到期时终止服务。另外两种策略在这一步都允许服务，但在后续发送失败或临时错误出现时分叉：CONTINUE 仍允许服务，RETRY_AND_TERMINATE 则终止。尝试备用目标还取决于是否支持故障转移、是否存在可用替代目标。

这些规则并不意味着任何负面答复都可以忽略。表 4 对 END_USER_SERVICE_DENIED 明确要求终止服务，不因 CCFH 的取值而改变。初次询问如果与 AA-Request 结合，也有另一套状态机，并会在 Tx 到期时断开。本文讨论更新等待，不能把它扩大为所有首次认证流程。RFC8506 的范围是信用授权，服务自身的身份认证与授权不在其范围内；继续策略不是绕过身份验证的总开关。

即使理解了状态转换，也不能只看本地配置就断定责任落点。第 5.7 节规定，归属域 AAA 服务器给出的值优先于本地值，而信用控制服务器答复中的值又会覆盖已有设置。复盘时真正需要的是相关时刻生效的策略及其来源。一张默认配置截图，未必能说明当时为什么继续。

备用地址之外，还有一整段状态

让服务临时继续，与把既有会话的信用控制消息流移到另一台服务器，是两个不同决定。第 5.7 节和第 8.4 节要求后者遵循 CC-Session-Failover。该属性缺失时按 FAILOVER_NOT_SUPPORTED 处理，不能把这条既有会话消息流迁移到替代服务器。给新会话选择备用服务器则是另一回事。传输路径上的对等节点切换也应单独看待：它可能产生重复请求，却不等于已经获准迁移带状态的信用控制会话。

标准建议在主、备服务器间转移会话和账户状态，并要求支持会话故障转移的实现正确检测重复、乱序消息；至于服务器之间究竟如何传递状态，则留给实现解决。Session-Id 和 CC-Request-Number 可以标识请求，但字段存在并不能证明预留状态已正确复制。只验证备用地址能够响应，仍然少了一半问题。

核算也不会因为服务不中断就自动完成。第 5.7 节建议使用备用用量核算流；其中 CONTINUE 搭配 DELIVER_AND_GRANT 的例子，明确依赖核算系统收集信息并与信用控制服务器交换。因此，不能把“继续”写成不计量、不收费，或者已经发生确定损失。第 5.4 节所述最终询问仍然涉及已用单位报告和未用预留的结算。反过来，服务器释放了预留，也不能单独证明客户端已经停止交付服务。

标准能说明什么，不能证明什么

官方条目将 RFC8506 列为 2019 年 3 月的 Proposed Standard，并注明其替代 RFC4006。勘误查询在 2026 年 9 月 8 日检查时没有返回匹配条目。这既不是厂商符合性证明，也不说明实际部署规模或事故概率。本文没有运营商流量、客户数量或损失金额可供推算。

卢恒关于“现实而非倡议才是产品”的论述，为这里提供的是编辑方法：先讲清机制，不急于把连续服务定性为英明或冒险。他对互联网治理代理问题的分析，可以用来追问谁作决定、谁承担后果，但不能直接证明某个 Diameter 团队存在激励错配。可确认的事实更具体：请求仍在等待，服务消耗已经可以发生。