摘要

  • RFC 7683 的 OC-Reduction-Percentage = 100，要求响应节点对其原本会发送、且命中当前过载控制状态的全部新请求实施处置；规范明确指出，无状态的丢弃算法并不保证流量绝对下降。
  • 若要证明运行结果，必须按节点、应用、报告类型与时间，把过载报告、已接受的 OCS、逐请求处置记录、实际流量以及有效吞吐连接起来。一个百分比不能替代这条证据链。

看似结果的命令

“降低百分之百”在日常语言里通常是事后读数，仿佛起点有一百，终点自然是零。Diameter Overload Indication Conveyance（DOIC）里的这个数却出现在行动之前。RFC 7683 将 OC-Reduction-Percentage 定义为：相对于发送方本来会发送的流量，请求它减少的比例。数值为 100 时，严重过载的报告节点要求所有范围内的新流量接受降载处置。

这条 OLR 能可靠证明一件事：报告节点发出了什么请求。它并不同时提供入口计数器，不说明每个客户端都支持 DOIC，也不保证每个响应节点持有同一版本的状态。被选中的请求可能被限流，也可能改道至别处。前者还可能触发错误和重试，后者则把负载搬到了另一条路径。报告的语气很确定，证明对象却很窄。

Ben Campbell 的工作轨迹恰好贯穿这条边界。IETF Datatracker 将他介绍为实时通信领域的独立顾问，并记录了他在 IAB、ART 区域以及多个工作组的任职经历。他是 RFC 7068、RFC 7683 与 RFC 8583 的共同作者。三份文件分别处理过载控制的要求、DOIC 的基本机制，以及负载信息与过载命令的区别。它们共同坚持的不是“一个数说明一切”，而是每个节点只对自己拥有的知识和动作负责。

两个节点，各自做一半决定

RFC 7683 把角色分为报告节点与响应节点。报告节点判断自己或所代表的对象进入过载，并决定需要请求多大比例的流量缩减；具体计算方法由实现选择。它把 OLR 放进应答。响应节点接收报告、维护 Overload Control State（OCS），再决定哪些单个请求接受降载；选择方法同样由实现决定。

默认丢弃算法要求响应节点把指定比例的新请求交给降载处置。但规范随即限定了承诺：算法是无状态的，所以不能保证发送流量出现绝对幅度的下降；它保证的是指定比例的新请求被选中。即使比例是 100，证明的仍是选择规则，而不是之后某个观测点的计数。

处置方式进一步拉开“选择”与“消失”的距离。应用规则可以让请求改道，也可以将其限流。RFC 8581 针对 Diameter Agent 的 Peer Overload Report，优先建议把需要降载的请求转向其他对等节点；备选容量不足时，才必须把请求压到可承受水平。受保护节点的入口流量可能下降，而网络总流量、备选节点负载或应用重试同时上升。只看第一张图，会把成本转移误写成流量消失。

“全部”藏在 OCS 的范围里

RFC 7683 最初规定了 Host Report 与 Realm Report。前者适用于按主机路由的请求，后者适用于按域路由的请求；Application-ID 也参与状态匹配。RFC 8581 又加入面向代理过载的 Peer Report，其状态由 Application-ID 与对等节点的 Diameter 身份共同确定。

所以，100 所指的“全部”是所有命中某个有效 OCS 的请求，不是整个 Diameter 系统。不同应用、不同主机、不同域或不支持该扩展的发送方都可能在范围之外。对于 Peer Report，如果 SourceID 与实际送来应答的对等节点身份不符，响应节点必须忽略报告。这条规则防止错误或恶意插入的控制信息接管流量，也说明来源身份本身就是证据的一部分。

状态还有版本与寿命。OLR 带有 OC-Sequence-Number 和有效期。更大的序列号更新同一状态，相等或更小的序列号会被视为旧报告而忽略。改变有效期或缩减比例都必须递增序列号；只要旧报告尚未失效，这个顺序约束在报告节点重启后仍要成立。复盘真正要问的是：某个响应节点在处理某个请求时，接受并持有的是哪一版 OCS？

报告沉默，不代表状态结束

运维界面常把字段消失解释为告警恢复。DOIC 明确拒绝这种猜法。应答里没有 OC-OLR 时，响应节点不能删除 OCS；OLR 缺席的含义是“没有变化”。报告节点可以用有效期为零的更新显式结束状态，也可以让它按原定有效期自然到期。

即使结束，恢复也不是开关从 0 跳回 100。RFC 7683 建议响应节点退出百分之百降载时保持克制，例如先发送探测消息，避免流量突然回灌并再次压垮报告节点。RFC 8581 对 Peer Report 也要求受控地结束降载。因此，发送结束、状态到期、试探恢复与业务恢复是四个可能不同的时点。

如果复盘只在第一条不含 OLR 的消息处画一条“恢复线”，它不仅缺少精度，还读错了状态机。若只在 OCS 到期处宣布服务恢复，它又把控制状态的终止当成了性能观测。

三类报告不能直接相加

RFC 8581 允许同一消息同时包含 Host、Realm 与 Peer 三类过载报告。处理顺序不是把三个比例各自套在原始流量上。响应节点先对 Host 或 Realm 报告实施降载，再对存活下来的消息执行 Peer Report 的处置，并应考虑前一步已经减少的数量，以免产生振荡。

因此，三个百分比并不是三只独立的丢包仪表。把它们相加会凭空造出共同分母。正确的记录应逐层保留：候选请求有多少，多少命中 Host 或 Realm OCS，多少留下，留下的请求中多少命中 Peer OCS，最后多少被改道、限流或正常发送。没有这些集合，任何精确到小数点的“综合降载率”都可能只是一幅漂亮的错图。

负载与过载使用两把相反的尺

RFC 8583 把 load 与 overload 分开。节点始终有负载，过载却是异常状态；“已经满载”和“宣告过载”之间甚至可能没有统一阈值。Load Report 是供接收方做均衡或预判的提示。OLR 则明确要求减少 offered load，文件将它描述为报告节点与响应节点之间的一种契约。

两套数值的方向也不同。Diameter Load 的数值越高，实际负载越低：65535 表示零负载，0 表示百分之百负载。RFC 7683 的 Reduction Percentage 恰好相反：0 表示无需降载，100 表示全部命中请求都要处置。若数据平台把两者都存进一个没有单位的“percent”字段，系统可以在没有任何解析错误的情况下把业务含义完全颠倒。

RFC 7068 给出了控制报文之外的评判标准：过载下的总体有效吞吐，是衡量方案价值的最终尺度。这个结果只能观测，不能从 OLR 推导。报告证明请求，OCS 证明节点持有的状态，逐请求日志证明选择与处置，计数器证明流量，应用遥测证明真正完成的工作。每一层都不能冒充下一层。

事故复盘需要怎样的回执链

第一张回执属于报告决定：哪个节点、针对哪个 Application-ID 和报告类型、用哪个实现版本判定过载，并在何时计算出缩减比例。第二张回执保存原始 OLR，包括序列号、有效期、算法、比例与发送时间。

随后要为每个响应节点留下接收证据：它是否宣告支持相应能力，是否接受来源，序列号是创建、更新还是因为过旧而被忽略，OCS 在本地何时生效、何时结束。第三层把每个命中请求连接到该 OCS，记录正常路由、改道或限流。

到这一步，流量图才有解释基础。应同时比较受保护节点与备选节点的入口、原本计划发送的基线、被拒绝或重试的请求、相同时间窗内的有效吞吐，以及应用延迟、错误和完成交易。证据在哪一层中断，结论就停在哪一层。“节点 A 持有一条百分之百 OCS”可以成立，而“网络流量归零”仍然未知。

来源