摘要

  • 最初的鲁棒性原则针对不完美规范：发送端只发规范形式；技术瑕疵不影响明确含义时，接收端可以继续处理。
  • 沉默宽容拿走了发送端修复错误所需的反馈。偏差一旦部署，后来实现就必须复制缺陷才能兼容。
  • 现代修复并不抛弃韧性，而是用明确错误动作、主动维护和 TLS GREASE 一类持续测试代替猜测意图。

先有歧义，后有格言

RFC 760 先承认一个现实：规范即使力求明确，也可能产生不同解释。早期互联网由不同团队同时写规范、写代码；等待文字完美，会让可用互操作迟迟不能发生。只要含义仍然清楚，接收端容忍技术错误，是合理的启动期分工。

RFC 793 把这项安排压缩成 TCP 的鲁棒性原则：自己的行为要保守，对别人的输入要宽容。格言离开了启动背景，逐渐像一条永恒道德律。

活下来不等于替对方解释

RFC 1122 实际上区分了几种责任。软件要承受罕见甚至恶意输入；枚举字段不能因为出现第五个值就崩溃；发送端不应滥用合法却冷僻的功能去触发对端缺陷；错误还要留下记录。

这些责任并不等于“猜发送者想说什么”。保护本机、为扩展保留未知值、约束输出、保存证据，各有清楚边界。两个宽容解析器可能对同一畸形消息推断出两个含义，表面会话仍在，内部状态却已分叉。RFC 1958 后来重申严格发送、宽容接收，也让接收者继续背负别人制造的歧义。

被容忍的错误有了客户

接收端静默修补，发送端便看不到失败。下一版本继续发同样的格式；其他接收端为避免“是我断了现有流量”，也加入例外。例外进入测试、运维和客户预期。

最终，已部署代码代替书面语法成为真正的合规测试。新实现若不复刻怪癖，就无法进入生态。这是一种控制倒置：发送端控制错误输出，修复成本却分摊给所有未来接收者。

BGP 给恢复动作划了边界

RFC 7606 说明，韧性不必依靠猜测。它对畸形 BGP 属性规定具体后果：把受影响路由视为撤回、在语义允许时丢弃属性，或在无法安全解析时采取更强动作，并要求保留问题 UPDATE 的诊断证据。

接收端没有虚构一条“看起来合理”的路由。它限制损害，保留事实，让连通性与正确性的取舍可审查。

TLS 开始主动使用未来

扩展点写在标准里，却长期只见熟悉值，部署中的不宽容就不会暴露。第一项真正扩展到来时，原本承诺的空间可能早已僵化。

RFC 8701 为 TLS 保留 GREASE 值，由客户端持续发送陌生值，让服务器不断证明未知扩展不会破坏协商。RFC 9170 把经验推广开来：扩展机制必须被主动、反复使用；仅有登记和文本，不会保存未来能力。

维护成为协议的一部分

RFC 9413 没有否定抵抗软件缺陷与攻击的能力。它否定的是把所有意外输入都当成可猜测对象。长期沉默宽容会造成协议腐化、逐错兼容、老实现无法改变、新实现无法发现全部暗规则。

替代方案是主动维护：报告分歧，更新规范与实现，明确异常条件，安全时让错误可见，记录临时绕行并安排退出。有时严格反馈会排除旧实现；这种排除必须有规范依据、部署证据和迁移计划，而不能意外撕裂兼容集合。

该文件属于信息性文件，其适用性章节明确以软件能够更新为条件。被冻结的设备可能需要有范围的兼容例外。范围、责任人与到期条件，正是防止例外重新成为法律的边界。

来源与证据边界

这条演变链见于 RFC 760、RFC 793、RFC 1122、RFC 1958、RFC 7606、RFC 8701、RFC 9170 与 RFC 9413。它们证明书面规则和代表性机制，不证明所有实现行为一致。历史结论也应保持有限：可以吸收边界明确的损害，不能隐藏会由陌生人继承的语义歧义。