摘要

  • RFC 1106 提出 advisory NAK 与 30 位 TCP 接收窗口。它明确说这些扩展曾借助 NASA 资源实现并运行成功，同时也明确说它们是实验协议，不是 Internet 标准提案。
  • 两个月后的 RFC 1110 找到局部环境没有覆盖的条件：窗口扩大到 30 位，序列号仍只有 32 位，编号可能在四次往返后重新使用；一个被长时间滞留的旧副本便可能被当成新数据。
  • NAK 只能证明接收方在某一时刻看见序列缺口。它不能区分迟到与永久丢失，也不能判断噪声或拥塞，更不能证明发送方重传、恢复或交付。

真正危险的不是测试成功，而是删掉测试条件

1989 年 6 月的 RFC 1106 留下一句很容易被压缩过度的话：两个 TCP 扩展已经实现，并利用 NASA 的资源证明可以工作。同一段状态说明随即限定了这句话——这是实验协议，不作为 Internet 标准提出，只是后续研究的起点。

这两句话并不互相否定。代码可以在给定拓扑、链路行为与缓冲条件下运行；测试者也可以如实记录吞吐和恢复。局部观测没有义务预先包含所有 Internet 状态，但使用结果的人有义务保留哪些状态没有出现。

RFC 1106 自己把最大空白写进摘要：拥塞与噪声仍无法区分，实验机制是否适用于整个 Internet，而不只是高带宽时延网络，还需要研究。它描述的是隔离卫星网络里的用途，不是对任意存储转发路径的证明。

今天的 RFC Editor 资料页 把文档列为 Historic、Legacy，并指向 RFC 6247；IETF Datatracker 保存当前记录。后来的状态改变的是权威与采用，不会把当年的有限实现抹掉。

接收方看见的是空位，不是原因

RFC 1106 的 NAK 试图缩短长时延链路上的恢复等待。当后到的数据暴露出序列缺口时，接收方指出第一个尚未收到的位置，请发送方尽快重传，让累计确认的左边界继续前进。

文档没有假装接收方知道更多。它明确承认，接收方无法判断缺失数据只是迟到，还是永远不会到达。对正在路上的数据发出 NAK，会额外制造一个副本；不对真正丢失的数据发出 NAK，又会让很长的数据管道停下来。

因此 NAK 被定义成 advisory 信息。它本身不可靠，不另行重传；发送方可以忽略，也可以立即重发；NAK 若损坏或消失，最终仍由普通 TCP 机制恢复。日志里的 NAK sent 只证明“此刻这里有缺口，并提出了请求”，不证明丢失、原因、重传、恢复或交付。

更不能从缺口推导拥塞。噪声、队列丢弃、路径乱序、异常时延都可能形成相同外观。观察缺席的端点，并不会因此获得观察整条路径的能力。

大窗口说的是接收内存，不是网络承诺

另一个扩展针对 16 位窗口的 64 KiB 上限。高带宽与长往返时延叠加时，这个上限不足以“填满管道”。RFC 1106 把接收窗口扩展到 30 位：低位仍在原 TCP 头部，高位通过 option 携带。

连接双方需要在 SYN 与 SYN-ACK 阶段同意使用，之后每个数据包都应带上窗口高位。握手证明双方采用了同一种解释，不证明这套解释在所有路径条件下安全。

接收窗口也不是路径带宽。它是接收端按自身缓冲策略愿意容纳的未确认数据量。RFC 1106 特别提醒，缓冲是稀缺机器资源；任意放大可能耗尽内存、拖垮其他任务，甚至导致机器崩溃。文档提到 NASA 正在考虑只允许确有需要的程序请求大窗口。那是一项局部资源治理，不是网络已经提供容量的证据。

四次往返后，旧编号变成了新编号

1989 年 8 月，A. McKenzie 的 RFC 1110 用两页文字指出了核心问题。Internet 会丢包，也会乱序和复制。TCP 的 32 位序列号并非真正永不重复，它依靠窗口大小和数据包生存期的约束，让旧数据在编号再次有效之前退出网络。

RFC 1110 的计算很直接：16 位窗口只占序列空间的 1/65,536，编号约在 65,536 次往返后才重新使用。RFC 1106 把窗口放到 30 位，却没有增加 32 位序列空间，于是编号四次往返后就可能复用。NAK 又可能在一次往返后触发副本。若旧数据包在网络中滞留约五次往返，它返回时可能正好落入新的窗口周期，旧内容便有机会冒充当前内容。

这个反例没有推翻“实验运行过”。RFC 1110 甚至给出一种相容解释：如果隔离卫星网近似无记忆，只会按序交付或直接丢失，不会把旧包长期保存后乱序送达，那么问题不出现。一般 Internet 允许更多状态，外推才失败。

后来的 Internet 没有把三个问题再绑成一个选项

RFC 4614 后来把 RFC 1106 记为对一般用途有缺陷，把 RFC 1110 记为对它的否定，并说明这些 options 没有被更广泛社区采用；它同时提到 NAK 在 SCPS-TP 中有较窄用途。局部采用不能自动扩大成 RFC 1106 整套设计的 Internet 采用。

2011 年的 RFC 6247 正式把 RFC 1106 与 RFC 1110 移到 Historic，并把它们放在“从未得到广泛使用”的一组 TCP 扩展里。这里的关键词是“广泛”：它与“从未实现”不是同一句话。

RFC 7323 采用的是另一种 Window Scale：握手中的 offer，不是承诺；描述哪些段已到与未到，交给 SACK；防止序列号循环后的旧副本，交给时间戳与 PAWS。不能据此声称 RFC 1106 直接催生了这些机制，但它们的分离说明，大窗口、丢失证据与旧副本安全本来就不是一个状态。

归档应当同时保存成功和未覆盖状态

可信的实验记录需要带上环境：实现版本、拓扑、包生存期假设、是否允许乱序与复制、错误模型、缓冲上限、窗口值、流量模式、观察点，以及哪些条件没有测试。

如果只留下“成功”，局部结果会被移植到未观测世界；如果只留下“Historic”，真实发生过的实验又会被后来的分类抹除。RFC 1106 与 RFC 1110 放在一起，恰好保留了两种必要证据：什么确实运行过，以及什么从未被那次运行证明。

来源