摘要

  • RFC 1025 把互通拆成可观察的步骤：连接能否建立、数据能否往返、连接能否正常关闭、无需重启能否再来一次，以及能否经由网关与别的实现对话。
  • 这套计分法整理了有用证据，却没有把一次通过变成普遍正确、性能排名或实际部署的证明。

“正确”当时还需要争论

1987 年 9 月，Jon Postel 发布了一份短文，直截了当地回顾了 TCP 和 IP 仍在演进时，人们怎样检验它们。RFC 1025 写道，当时实现很少，要判断某个实现是否“正确”，现实办法就是让它和另一个实现互相测试，再讨论结果究竟说明了什么。测试可能促成代码修改，讨论也可能反过来修改规范。

这段话把早期 bake-off 放在了现代认证实验室之外。接受检验的不是一件已经定型的产品，也不是一份无可争辩的完整规则。它是一套仍在成形的协议，由少数实现者共同推进；在文字最终定稿之前，不同机器上的实际行为必须先变得可见。一次通信失败是证据，却不是自动生效的裁决。人们还得判断：是实现误读了规则，规则本身不完整，还是测试问错了问题。

RFC 1025 是回顾，不是对每次活动的逐分钟记录。它说，早期测试清单见于 1978 年 10 月的 IEN 69；同年 12 月 4 日，四个 TCP 实现在 Reston 做了演示；1979 年 1 月 27 至 28 日，六个实现聚集到 USC 信息科学研究所；1980 年 4 月又通过网络举行了分布式 bake-off。1987 年的 RFC 只对这次 1980 年活动的流程、测试和计分作了轻微编辑后重印。这个时间顺序说明，测试实践是在一次次互联中累积出来的，并非协议完成后才发下的一场正式考试。RFC 1025、IEN 69、IEN 77

一次对话有好几个环节

最初级的组别几乎从最小动作开始：TCP 与自己建立连接得一分；发送并接收数据得一分；平稳关闭、没有崩溃再得一分。无需重新初始化 TCP 就能重复以上过程，另得两分。经测试网关完成一次完整对话，则得五分。

这些分数把“已连接”这个笼统标签拆成不同事件。建立连接，说明两端能创建状态；传输数据，说明这种状态能承载实际内容；正常关闭，检验这段关系如何结束；不重启再做一次，检验首次使用后实现是否仍可用；经过网关，则多了一个中间环节和网络边界。单次握手回答不了所有这些问题。

中级组别把自测与互操作的差别摆到了台面上：与另一个 TCP 建立连接、交换数据、正常关闭，各得两分；无需重启而重复一次得四分；经由测试网关完成对话得十分。RFC 1025 还说明，分数会按联系到的不同 TCP 分别计算；它举例说，每个其他实现最多可以贡献二十分。目标是 N 平方连接性：检验可能的对端组合所组成的网格，而不只是证明预先挑好的两个系统能够通信。

证据的单位因此发生了变化。一次结果属于一对实现、一条路径和一种测试条件。A 能和 B 通信，并不能证明 B 能和 C 正常通信，也不能证明 A 穿过一个改变数据包交付方式的网关后仍然可靠。矩阵把单次演示容易遮住的接缝显露出来。

网关可以故意让路径变糟

RFC 1025 最令人难忘的装置叫 “flakeway”：一台故意设置成不稳定的网关，可以在运行中调节丢弃、损坏后继续转发、以及重排数据报的比例。名字带着玩笑意味，目的却很严肃：路径本身也成为实验变量。只在干净路径上成功的连接，证据范围很窄；如果数据包会消失、被改动或乱序到达，系统仍能继续交换数据，结论就更有分量。

校验和规则让测试更难取巧。RFC 1025 明确要求启用校验和：关闭校验和测试就没有分数。不能靠关闭本来负责发现损坏的机制，来制造表面上的成功。

之后的重量级 TCP 测试远超普通对话：同时和多个对端维持连接、处理紧急数据、跨越序列号回绕边界，以及处理一个把多种报头功能叠在一起的 “Kamikaze” 报文。计分表还区分符合规范的“合法攻击”和违反规范的“脏攻击”：用符合规范的报文击倒对手得30分，用违规报文击倒对手得20分。这种措辞像比赛，因为测试就是要让实现的薄弱处在对抗性交互中显形。它不意味着无效报文成为正常运行条件，也不意味着一次崩溃足以证明普遍风险。

另有一组针对主机与网关的 IP 测试，涵盖分片与重组、源路由、返回路由、路由建议、Source Quench、服务标记和若干选项。能发现网关没有递减 TTL、转发 TTL 为零的数据报或错误处理校验和，也能得分。TCP 负责主机之间的对话；IP 则在互联网络和网关之间搬运数据报。分开计分对应的是两类不同工作。RFC 793、RFC 791

测试清单继续追问连接的生命周期和边缘情形：反复打开再关闭一条连接；同时开多条连接，检查数据有没有串线；让本地 TCP 崩溃后再尝试打开原连接；向不接受连接的 socket 发起请求；向零窗口接收方发送；用“消防水管”式的数据流连续灌入；检验紧急数据；让序列号越过回绕点。最后一项把违规报文、半开连接和即将回绕的序列号组合在一起。网络不会总在整洁的条件下工作，规则之间相互碰撞时才更需要测试。

总分有它的边界

计分表还奖励最长对话、最多并发连接，甚至“最佳借口”。这些细节让 bake-off 好记，却也说明总分不能轻易变成一个统一排名。有些分数衡量连接的基本生命周期，有些计功能、网关处理或并行维持对话的能力。它们并非同一种性质的不同刻度。

RFC 1025 在最后一节承认了这一点。前面的测试检查基本功能和若干难例，却不衡量性能，也不检查较新的机制是否已经实现。它把 John Nagle 的流程、Van Jacobson 的慢启动和往返时延测量、以及 SQuID 流程列为另行考虑的项目。随后，它列出一些可能的性能测试：用 FTP 或 NETBLT 在以太网或 ARPANET 上传输一兆字节文件，以及测量一个字符经 TCP 发给 Echo Server 再返回所需的时间。RFC 提醒，性能结果极受测试环境影响。RFC 896、RFC 862

这个边界很重要。某些对端之间的连接能够建立、传输和关闭，并不能说明系统换一条路、换一种负载或启用测试没涵盖的机制后会有多快。两个系统互通成功，也不等于所有主机都用同一套软件、所有部署都通过了测试，或者所有边界情形都已经穷尽。证据有适用范围，RFC 1025 自己把范围写了出来。

测试属于协议的实际运行过程

早期互联网的实现文化没有等到规范和运行现实完全分开。Bake-off 提供了可重复观察分歧的场所：这一端能打开连接，那一端不行；这一对实现经重启后仍可工作；那个网关处理报头出了问题；受损数据包被发现了，或者没有。观察结果可以带来代码修复、文字澄清，也可以要求修改规则本身。

与计分的新奇相比，这个反馈回路更能说明它的历史意义。算术本身不会让网络变正确，它让独立实现之间的具体行为变得可讨论。共享规则只有在不同系统都能实际使用时才有意义；测试只有在边界足够清楚、工程师可以争辩某个结果能证明什么时才真正有用。

后来的 RFC 留下了这种实践的一个切片。它把兼容性看作多组对话构成的网，把恢复看作不同生命周期事件的序列，也要求沿途测试故障处理，而不只看两端。文中自己的保留意见，阻止这张矩阵冒充性能总评或所有 TCP 新机制的完整清单。这样读来，RFC 1025 既不是胜利宣言，也不是现代合规证书。它记录的是一个年轻互联网如何尝试把“能用”变成一个其他实现也能质疑的问题。

资料来源