摘要

  • RFC 1146 把 Alternate Checksum Request 放在 Kind 14、长度为 3 的 TCP 选项里。两个方向的 SYN 必须携带完全相同的算法编号；少一个、编号不同，或旧实现忽略未知选项，整条连接都继续使用标准 TCP 校验和。
  • SYN 和 RST 无论是否达成协议，都只用标准算法。32 位 Fletcher 结果还需要 Kind 15 承载后一半。RFC 4614 后来记载兴趣不足，RFC 6247 再把 RFC 1146 转为 Historic，并把 14、15 标为 obsolete。

旧主机什么也不做，就阻止了误切换

设想一端安装了支持 RFC 1146 的新 TCP 栈，另一端仍只认识原来的选项集合。新端在 SYN 中加入 Kind 14。旧端能读懂 TCP 头，也能依据选项长度跳过三个 octet，却不知道这个编号代表什么。

RFC 1122 为这种情况给出了兼容规则：有长度信息的未知 TCP 选项应当被忽略，不报错。旧端于是继续正常握手，发出的 SYN 不含匹配请求。

新端看到的不是含糊状态。RFC 1146 明确规定，若双方的 SYN 没有携带同一个算法编号，连接全程使用标准校验和。旧端的沉默不构成同意；它恰好让双边条件不能成立。

因此，没有一方会误以为对方已经换算法。旧端按原规则发送，新端也按原规则解释。未知选项没有把连接切成两个互不理解的世界，而是被转换成一次安全、无声的回退。

为什么提议必须装在旧语言里

TCP 已有一套共同校验规则。RFC 793 规定，对 TCP 头、数据和伪首部的 16 位字求和，再取一补数。RFC 9293 在当前规范中保留了强制性：发送方必须生成，接收方必须检查。

在第一个 SYN 到达前，两端还没有任何关于备用算法的共同状态。若提议本身就用新算法保护，接收者必须先接受一条自己无法验证的消息，才能获知如何验证它。这会让协商建立在循环信任上。

RFC 1146 因而让 Kind 14 所在的 SYN 仍受标准校验和保护。接收方先用已经共同掌握的规则确认报文，再读取里面关于未来普通报文的提议。旧算法不是新算法之外的残余，而是授权新算法的入口。

这个次序也限制了证据。单边出现 Kind 14，只说明这一端提出过请求。只有反向 SYN 也带同一编号，才能说明文本所定义的协议成立。之后还要检查数据报文，才能说明实现真的照做。

两个完全相同的动作，不是一次能力声明

Kind 14 的三个 octet 依次表示选项类型、长度和算法号。编号 0 是标准 TCP 校验和；1 是产生 16 位结果的 8-bit Fletcher；2 是产生 32 位结果的 16-bit Fletcher。

这不是能力列表。发起方选择一个值放入 SYN，响应方也必须在自己的 SYN 中选择同一个值。规范没有“我支持 1 和 2，你任选”的列表，也没有两个不同编号之间的优先级折中。

若一方发 1、另一方发 2，结果不是退到两者中较弱者，而是退回标准算法。若一方没有 Kind 14，结果相同。先前连接的选择、系统级默认值或对方软件版本，都不能替代本次握手里的两次明确动作。

这种设计把解释权绑在每条连接上。发起者只能控制自己的提议；响应者控制自己的回应。两端共同承担后续报文的新含义，所以必须留下两份可验证、方向相反的记录。

SYN 和 RST 始终留在公共出口

即使两端已经为连接选择备用算法，SYN 和 RST 仍必须使用标准校验和。SYN 的原因在协商顺序里：它出现时还没有协议结果。

RST 的原因更能显示状态边界。一个主机可能在没有这条连接状态的情况下发送 reset。它无法可靠找回双方曾选的备用算法。若 RST 也依赖连接私有状态，恰好不认识状态的一方就无法用共同方式拒绝报文。

所以标准校验和既是入口，也是紧急出口。备用算法只获得对已知连接中普通报文的有限管辖权，不能重写所有带 TCP 头的消息。

抓包分析如果把“握手后所有报文都该用新算法”当规则，就会把正常的 RST 判成错误。反过来，只因看到标准校验的 SYN，也不能断定后续没有备用算法。报文类型、方向和连接阶段必须一起读。

32 位结果必须多带一张凭证

算法 1 的 Fletcher 结果是 16 位，可以放进原来的 checksum 字段。算法 2 产生 32 位，现有字段装不下。RFC 1146 把 A 部分放在标准字段，把 B 部分放进 Alternate Checksum Data 选项 Kind 15。

Kind 15 不是另一次协商，而是选择长结果后的持续格式成本。适用的普通报文需要携带额外选项，占用 TCP 头空间，并要求端点、抓包器和中间设备都按握手状态解释它。

规范对错误的 Kind 15 并不宽容。若长度错误，或出现在不该使用它的上下文，接收方应丢弃报文、发送 RST 并中止连接。这与握手前忽略未知 Kind 14 形成鲜明对照。

原因在于两个阶段承担不同风险。协议达成前，忽略未知提议能保持共同基线。协议达成后，一个错误的数据校验字段会让双方对同一报文是否完整产生根本分歧，继续容忍反而不安全。

安全回退也会隐藏没有采用

这种兼容方式很适合试验。只升级一端不会破坏 TCP；旧端照常工作，新端会自动回退。部署者不必先让全网同时升级，才敢把代码装进系统。

但功能收益只在两端都升级、选同一算法，并且路径没有妨碍所需选项时才出现。用户看到的“连接成功”，无法区分备用算法成功和备用算法根本没启用。

如果运营指标只有连接可用率，单边部署就会显得完全成功。实际上它只证明回退做得好。没有专门记录 offered、matched 和 used，新功能缺少推动第二端升级的可见证据。

这不是回退设计错误。若未知选项直接导致失败，试验会制造网络分裂。它说明可部署性和可采用性不是同一个问题：降低兼容风险的机制，也可能降低未采用时的痛感。

规范的状态没有被算法名字替代

RFC 1146 于 1990 年 3 月以 Experimental 发布，并明确不建议用于生产系统。这给出的是可测试机制，不是 TCP 必须迁移的命令。

RFC 1071 更早整理了 Internet checksum 的数学性质和实现技巧，但它不能充当 RFC 1146 的部署证明。其部分示例实现还有 held errata，更应避免把代码片段当成整项机制的成功史。

2006 年的 RFC 4614 在 TCP 文档路线图中说 Alternate Checksum 没有吸引到兴趣。这个表述不能扩大成“从未有人实现”，也不能证明 Fletcher 数学上失败；它只支持兴趣不足这个有限结论。

2011 年的 RFC 6247 正式把 RFC 1146 转为 Historic，并称其没有获得广泛部署，同时要求 IANA 把 Kind 14 和 Kind 15 标成 obsolete。该 RFC 中关于 spoofing 的具体安全讨论属于 T/TCP，不能挪来解释 Alternate Checksum 的退场。

准确的历史并不需要额外戏剧性：这套双边、可回退的实验机制没有形成广泛实践，标准体系随后关闭了它作为当前方案的地位。

IANA 保留号码，是为了不让记忆失效

IANA TCP Parameters 登记表 今天仍列出 14 和 15，并明确标记 obsolete；备用校验和算法表也保留 0、1、2，以及代表 Redundant Checksum Avoidance 的 3。

这些行证明号码曾被分配、含义是什么、当前登记状态如何。它们让历史抓包、旧实现和研究资料仍可被一致解释，也避免旧号码在失忆后被赋予冲突的新用途。

它们不证明当代内核支持，不是流量统计，也不构成使用建议。登记表回答名称与状态，真实部署必须由握手两边和后续报文证明。

因此，“看到号码”“双方同意”“确实使用”“现已废弃”是四类不同事实。把它们压成一句“TCP 支持备用校验和”，既忽略历史时间，也忽略协议状态。

一次沉默如何守住共同基线

旧主机忽略 Kind 14 时，没有执行一段关于 RFC 1146 的专门拒绝逻辑。它只遵守通用 TCP 兼容规则。新主机负责把对方缺少匹配动作解释为回退。

这让不知情的一方无需承担新协议义务，也让知情的一方不能把自己的愿望投射到对方。选择新含义的责任落在提出改变的人身上；证明共同选择需要双方证据。

新校验和得先让旧校验和放行，因为旧规则是双方唯一已经共享的校验规则。它还必须等待另一封同样受旧规则保护的回信。缺少回信时，沉默不是漏洞，而是一条完整的治理规则：没有共同可读的同意，就不改变共同报文的解释。

来源