摘要

  • RFC 1644 的 TCP Accelerated Open 将初始 SYN 中的 CC 与服务器保存的客户端旧值比较。新值更大时，服务器可以更新缓存并在普通三次握手结束前把数据交给用户进程。
  • CC.NEW 表示连续性假设已经失效：重启、计数回绕或未知历史都会使服务器清除缓存并退回普通握手。CC.ECHO 则让客户端核对 SYN/ACK 是否对应本次开启时的计数。
  • 这些机制界定的是旧传输副本，不是对端身份、授权或应用提交。RFC 6247 后来因缺乏广泛部署并有安全问题报告，将 T/TCP 改列 Historic。

缓存先于业务作出判断

RFC 1644 是 1994 年的 Experimental 方案，服务于短促的请求—响应交换。主动开启方可以把请求和 32 位连接计数一并放入首个 SYN。服务器为每个客户端主机保留最近一次有效 CC。

若新 CC 大于缓存值，TAO 测试通过。服务器据此认为 SYN 属于新的连接实例，更新缓存，并把其中的数据交给应用进程。若值不大于旧值，服务器无法判断它是旧副本还是乱序到达，于是回到普通三次握手。

这项比较只证明两个本地状态之间的次序关系。它依赖客户端计数保持单调、缓存仍在有效期内，以及缓存键仍代表同一上下文。它不证明谁控制远端主机，也不说明进程会如何处置字节。

CC.NEW 是一项罕见而重要的失信声明。客户端在重启、计数可能回绕或缺少先前记录时，不再假装缓存连续；服务器清除旧项并要求完整握手。回程的 CC.ECHO 把 SYN/ACK 绑定到客户端本次开启的计数。它是报文关联证据，不是密码学身份凭证。

“至多一次”没有跨过应用提交线

RFC 1644 明确把“transaction”限定为传输层的基本请求—响应序列，并说明它不包含多阶段提交等应用事务语义。最短 T/TCP 交换仍需三个报文段。

数据交给进程之后，仍可能发生解析失败、授权拒绝、局部写入、下游调用、持久提交后响应丢失，或执行完成但客户端超时。客户端只看到沉默时，CC 无法区分“未送达”“已送达未执行”和“已执行但回执丢失”。

因此，付款、配置更改或其他不可逆动作必须拥有应用自己的稳定操作 ID、持久去重记录与结果回执。传输缓存只能约束旧报文重现，不能为业务结果签字。

历史状态也不能被忽略。RFC 6247 在 2011 年把 RFC 1644 移至 Historic，指出相关扩展未被广泛使用，并提到 T/TCP 的安全问题报告。现行 TCP 标准基线是 RFC 9293。1994 年设计不能充当当代内核、路径或中间盒安全性的证据。

快速退出仍有条件

T/TCP 还用 CC 区分短连接的新旧实例，从而缩短 TIME-WAIT。但连接持续时间超过最大报文段生存期时，仍需普通的等待；交易假设失效后，行为应平滑回到标准 TCP。

这正是文章的边界：一次缓存命中只授权一个本地状态转移，CC.ECHO 只验证一次回程关联。应用是否执行成功，必须由另一套证据回答。

来源与边界

  • RFC 1644：TAO、CC、CC.NEW、CC.ECHO 与 TIME-WAIT 规则。
  • RFC 6247：Historic 重分类及部署、安全边界。
  • RFC 9293：现行 TCP 规范。
  • RFC 2140：另一个关于跨连接共享主机对 TCB 观测的主题。
  • Minimum Initial Specification：只把可验证的最小规则放进共同层的设计原则。

这些来源不证明当前部署、认证身份、中间盒安全、应用正确性或业务上的恰好一次完成。