摘要

  • RFC 5390 的三服务器 UDP 示例表明，503、代理换服和事务重传叠加时，一次客户端请求在超时前最多可形成十八次请求以及十八次响应；这是标准中的有界模型，不是通用实测倍率。
  • 503 没有可靠表达究竟哪一项资源过载、还能接收多少负载以及信号适用于哪个对象，因此既可能把工作复制到同一故障域，也可能误停健康容量，还可能让流量在两个满载节点之间来回摆动。
  • 后续 RFC 将监测、控制判断、反馈和上游执行拆开。收到拒绝、安装限流、完成事务、成功建立通话是四种不同凭据，任何一个都不能替代下一个。

十八不是流量预测，而是一张成本清单

RFC 3261 给 SIP 提供了一个看似合理的临时拒绝路径。服务器可以返回 503，并可附带 Retry-After；代理收到拒绝后可以尝试另一台服务器。只要第一台机器局部失效、第二台仍有独立容量，这种切换就能把冗余变成可用服务。

RFC 5390 刻意选择了相反的状态。负载均衡代理面对 S1、S2、S3 三台服务器，但三台都已过载。请求先到 S1，收到 503 后转向 S2，再转向 S3。每个节点仍需接收报文、解析状态、进入调度并生成拒绝。列表里有三个地址，现实里却没有三份独立容量。

响应也不会瞬间出现。过载服务器在艰难地产生 503 时，使用 UDP 的客户端可能已经按事务定时器重传。RFC 的核算包括客户端到代理在内的四段 SIP 事务，并假定每段在超时前最多发生七次重传。在这个限定拓扑和限定传输条件下，一次原始请求最多带来十八次请求以及同样多的响应。

因此，十八不能被写成某个现网的常见倍率，也不能脱离三服务器、UDP、定时器和超时假设。它的价值是迫使运营者把“拒绝”之后仍然发生的成本记入账本。若账本只数进入系统的原始请求，恢复路径制造的副本就会被错误地归入新需求。

可靠传输也没有消除决策错误。RFC 在同一场景中指出，即使 TCP 不发生分段重传，一次请求仍会产生三次下游请求和四次响应。传输改变了副本数量，却没有告诉代理：三个候选节点共享同一项稀缺状态。

一张绿色的 503 图表无法证明负载已经下降

服务器正确发出 503，只能证明某条处理路径对某次请求作出了拒绝决定。它没有证明 CPU、队列或数据库连接已经回落；没有证明代理停止发送；没有证明另一个目的地健康；更没有证明用户最终获得结果。

这几件事常被一个“过载保护生效”状态合并。合并之后，系统甚至可以因为更快地产生拒绝而显得更健康。响应量上升、超时下降，也许只是机器把全部能力用于回答“不能处理”，而不是恢复有用事务。

RFC 5390 把 useful throughput 放在第一项要求里，正是为了阻止这种自我庆祝。可用吞吐需要把准入、完成、状态释放以及通话结果连起来。一个终止既有会话的 BYE 可能释放资源；一个新 INVITE 可能继续占用资源。两者都只是一个请求，却不能用相同的价值解释。

基于事实层次来看，503 是符号层证据，服务器资源是运行状态，上游限流是另一主体的行动，完成通话才是用户结果。它们可以有关联，却不是同一事实。只有逐段保留时间、对象和责任人，才有资格声称控制已经闭环。

上游换了代理，却没有换到新的资源

RFC 5390 又在 P1、P2 之上增加一层代理。P1 已经尝试过 S1、S2、S3，因而知道整个下游集合都在过载。但这份知识没有以可执行范围传回上层。上层于是改试 P2，P2 又把相同三台服务器走了一遍。

从拓扑图看，分支数增加了；从资源图看，仍然只有同一个耗尽集合。P1 发出的失败可能被理解成 P1 自身的状态，而不是其共享后端的状态。RFC 3261 曾为避免这种误解而不鼓励直接向上传递 503，但不传递也让下一条分支失去避免重复搜索所需的因果信息。

这说明冗余不能按主机名或节点数量计算。两台前端若依赖同一数据库，对需要该数据库的事务而言就是一个故障域。两条路由若最终进入同一 PSTN 网关，也不提供两份成功机会。只有能说明新增了哪项独立资源，重试才有恢复含义。

“所有服务器都试过了”于是可能同时是算法尽责和系统浪费。审计不能只看尝试次数，还要保留每次选择时所依据的依赖图，以及前一分支已经获得了哪些证据。缺少这些，重试树越大，事实反而越难还原。

范围不清也会把健康机器一起关掉

同一缺陷还能产生相反后果。RFC 5390 指出，RFC 3261 对 503 的适用范围没有给出足够清晰的界限：它是针对一个 IP 地址、一个主机名，还是一个 URI？部分实现按主机名处理。如果 DNS SRV 把该名称解析到一组成员，其中一台返回 503 就可能让代理暂时避开整个名称。

此时不是过多请求打向坏资源，而是健康容量被策略隔离。一条局部观测被扩大成集群结论，原本仍能接单的成员也失去流量。过载放大与容量闲置看似相反，根源却相同：接收者不知道信号描述的确切对象。

RFC 5390 的要求 18 因而规定，过载指示必须明确适用于 IP 地址、主机还是 URI。范围不是装饰字段，而是行动授权的边界。服务器有资格报告自己的本地状态，却不能靠同一个错误码顺带断言兄弟节点、共享服务或 DNS 名称整体都处于相同状态。

控制面至少应保存观测对象、观测时刻、有效期、接收邻居，以及接收者最终禁用了什么。只有这样，事后才能区分“保护了故障节点”和“误停了健康集群”。单独保存 503 总数无法回答这个问题。

二元暂停把两台满载服务器变成了钟摆

Retry-After 可以给服务器一段清空积压的时间，但基础动作是全有或全无。RFC 5390 描述两台都处在满容量的服务器。S1 发出拒绝并要求暂停后，代理把全部流量转到 S2。S2 立即承受约两倍容量，也开始拒绝；等 S1 的计时器到期，流量又整体摆回去。

每个局部判断都可能准确。问题出在执行器：收到一个真实的过载信号后，它只能选择零流量或全部流量，无法表示服务器仍可稳定处理的比例或速率。局部诚实因此没有自动产生全局稳定。

标准也明确限定了这个例子。当上游由很多相互独立、各自只贡献很小份额的客户端组成时，服务器选择性地向一部分客户端返回 503，可以近似形成更细的减载。文章不能由此宣称 Retry-After 总会造成振荡。可以确认的是，基础机制没有为 RFC 5390 关注的拓扑提供可证明的分级与收敛。

要求 7 要求识别过载程度，要求 21 要求当负载回到容量以下时吞吐能够稳定下来。它们改变的不是错误文案，而是控制系统的数学性质：信号必须带来适度行动，行动又必须能被结果校正。

同一个错误码掩盖了需要相反动作的原因

实践中的 503 并不总是表示 SIP 处理器耗尽。一台网关可能仍有充足的信令能力，却因某条 PSTN 路径不可用而无法完成特定呼叫；另一组前端可能处理能力正常，但共享数据库已经失败。前者换路由可能成功，后者换一台前端只会回到同一故障点。

上游仅凭代码无法判断应当继续寻找还是立刻减载。重试可能挽救请求，也可能复制无用工作；停止重试可能保护系统，也可能放弃健康容量。要求 6 因而要求有明确的过载指示，把资源过载与其他失败区分。要求 8、9 则同时约束两端：不要继续向已知或未知过载目标发送，又不要阻止真正健康的目标工作。

要求 14 还关注连接建立和重启后的注册，要求给出清晰的重试说明。原因、对象范围、减载幅度和有效时间是四个维度。把它们塞进一个通用代码，就等于让接收者凭猜测补齐缺失政策。

最小共同规范不需要掌握整个运营网络。它只需把可互操作的事实表达清楚，并避免越权。下游报告其测得的本地状态；上游决定如何调整自己发送的流量。二者通过窄接口协作，而不是互相假定对方的责任。

后续设计把监测、判断、反馈和执行分开

RFC 6357 为控制环路命名了不同角色。monitor 观察受保护的 SIP 处理器；control function 把样本转成反馈；下游把反馈交给相邻节点；上游 actuator 在多余请求抵达稀缺处理器之前执行减少、延迟、拒绝或改道。

拆开角色以后，故障才可定位。监测可能准确，但反馈已经过期；反馈可能送达，执行器却未安装限制；执行器可能满足总速率，却丢掉了错误的消息类别；流量可能真的降低，但共享依赖仍未恢复。每一种情况都需要不同修复，不能被同一个“保护已开启”吞掉。

RFC 6357 也指出，本地拒绝仍然消耗服务器资源，所以只能充当最后一道保护，不能独自防止拥塞崩溃。真正减载必须尽量发生在上游，避免多余工作进入瓶颈后才付费拒绝。

RFC 7339 随后在最上层 Via 头参数中逐跳携带过载信息。该 Via 项会由相邻客户端消费，因此反馈绑定在一段邻接关系上。oc 在默认 loss-based 方案中表达削减，oc-validity 限定有效期，oc-seq 排序更新，oc-algo 标记算法类别。字段发布只是形成了一张反馈凭据，并不证明执行器已经响应，也不证明整条呼叫路径都支持它。

百分比与速率上限是两种不同承诺

RFC 7339 要求支持基于丢弃比例的算法。服务器可以要求某个上游少转发一定比例的请求。这种反馈相对轻量，但比例会随输入变化：外部提供的流量继续上升时，被允许通过的那一部分也可能上升。

RFC 7415 增加了可选的速率型算法。服务器为客户端给出最大请求速率，在下一次更新前保持该上限。它把执行边界变得更明确，但需要更多按客户端维护的控制状态，因为不同上游未必适合同一数字。

两种数值都不是服务保证。每秒最多 150 个请求，不等于完成 150 个事务，更不等于成功建立 150 次通话。不同消息消耗不同，优先级仍由上游本地政策选择。标准提供交换证据，没有替运营者决定哪一类业务应得到稀缺份额。

因此应分别留存反馈值、序列和有效期，实际安装的比例或速率，输入与转发量，被丢弃或改道的消息类别，完成事务以及用户结果。满足限流数字可以保护 CPU，同时仍可能饿死能释放资源的终止消息。控制合规和业务有效不能共用一张收据。

证据边界

冻结证据能够证明 RFC 5390 的文本、信息类状态、其中列举的部署问题，以及 RFC 6357、RFC 7339、RFC 7415 描述的后续控制结构。它不能证明任何当前运营商、产品或网络已经部署这些机制，也不能把某次真实中断归因于十八次请求模型。

十八这个数字必须始终与三服务器拓扑、UDP 事务、重传行为和超时条件一起出现。双服务器振荡例子也只说明少数大型上游关系下的风险，不能替代对具体网络的测量。单个现网 503 同样不能证明原因就是资源过载。

能够带走的是一条控制不变量：拒绝不等于减少。可信系统必须展示被测资源、因果范围、反馈版本、上游行动、本地优先级和有用结果。少一项，就只能确认系统发出了合法错误，不能确认它正在恢复。