摘要

  • RFC 832 从 NIC 主机表读取 TCP、Telnet、FTP 与 SMTP 声明，再主动连接三个服务端口，把未接受、拒绝、不可达、无响应和接受分别记录。
  • 负面结果会在次日复测，整项调查又按周重做；因此“状态”属于一次带时间、路径和观察点的实验，而不是主机永久携带的标签。
  • RFC 844 换到 BBN 的 Class C 网络后，只成功连到此前 187 个 Telnet 接受者中的 127 个。执行证据可以纠正目录，却不能证明普遍可达、完整合规，更不能赋予测量者对远端主机的权力。

目录写的是声明

RFC 832 最值得保留的不是某个百分比，而是表头中的 Claims。

调查使用 1982 年 12 月 2 日的 NIC 主机表。表中可以用 T 表示一般 TCP 能力，用 t、f、s 分别表示 Telnet、FTP、SMTP。RFC 没有把这些标记重命名为“事实”或“合规”，而是在旁边增加三个实测结果栏。一台没有声明服务的主机仍可能接受连接；一台写有声明的主机也可能拒绝或沉默。

更早的 RFC 801 解释了为什么声明不足。1981 年的 NCP/TCP 迁移计划收录了各站点和供应者提供的实现状态：有些已可用，有些仍属实验，有些正在开发或只是计划。文档明说这些信息很快会过时。它还列出不能偷掉的实现责任，包括校验和验证、IP 分片重组、TCP 段重排、选项处理和有用的错误报告。

打开一个端口无法验证这份清单。Smallberg 的方法因此没有夸大问题。它只问：从这一观察主机，在这一时间窗，向这一知名服务发起连接，会得到什么传输层结果？

“失败”不是一个状态

调查没有把所有负面观测压成红灯。refused 表示对方返回了明确拒绝；unreachable 表示路径给出了不可达证据；dead 表示在测量方法和时限内没有得到有用响应；空白只表示没有被接受，不额外虚构原因；accepted 则表示连接尝试跨过了调查设定的门槛。

FTP 还有 accepted+：允许 anonymous 用户以 guest 作为口令。这个额外符号恰好说明普通 accepted 的证明力很窄。它没有证明登录成功、文件传输完成、应用行为正确，也没有证明操作者身份。

12 月 7 日的测试分两个时段进行，总计超过八小时。被记录为 dead、refused 或 unreachable 的主机在 12 月 8 日重试。复测可以降低临时故障、路由波动或偶然时刻造成的误判，却不能消除观察点的局限。

315 台列名主机中，83 台接受 Telnet，70 台接受 FTP，63 台接受 SMTP。其余主机并没有因此“违反互联网”。有的承担特殊任务，本来就不开放这些服务；有的暂时停机；有的服务策略不同。调查测量的是自己选择的表面，不是成员资格。

每周快照都撤销上一张照片的永久性

RFC 833 在 12 月 14 日再次测量，并披露一个看似琐碎的处理变化：重复列出的主机与前一周采用了略有不同的去重方式，因此总行数发生变化。这句话保护了证据链。否则，分母变化很容易被误读为部署进展或倒退。

后续调查持续到 1983 年 2 月。RFC 847 汇总了十二次观测：Telnet 接受数从 12 月 7 日的 83 上升到 2 月 22 日的 190；FTP 从 70 到 181；SMTP 从 63 到 178。TCP 迁移不再只是截止日期或实现者报告，而是逐渐出现在远端响应中。

曲线却不是单向的。12 月的 Telnet 接受数先为 103，随后是 102 和 95。FTP、SMTP 也曾回落。真实网络不会服从行政进度条：主机表版本、停机、路由、测试时段、去重和服务策略都会改变观测。

最后一份 RFC 846 仍然逐项写明坐标：来源是 2 月 18 日主机表，2 月 22 日从 ISI-VAXA 测试，负面结果在 23 日复测。它没有宣布迁移已经成为永恒事实，只提供了更新的一次可复核记录。

换一个观察点，命题也换了

RFC 844 是这组文献中最重要的自我约束。RFC 843 在 2 月 8 日和 9 日从 ISI-VAXA 找到 187 台接受 Telnet 的主机。随后，BBN 从 Class C 网络 192.1.2.0/24 上的一台终端集中器，重新连接这 187 台机器。

第二次实验不只要求远端端口监听。网关必须知道如何返回 Class C 地址，主机必须正确处理地址类别，ICMP 和路由行为也会进入结果。最终只有 127 台被记为 OK，占 67.9%。

这不能倒推 ISI 的结果为假，也不能把另外 60 台定义为“不支持 TCP”。RFC 844 说明测试是手工输入地址，只做了三轮，有些主机可能因停机而被漏掉。它证明的是观察依赖性。

两个实验实际回答不同问题。第一个命题是：“该服务在 ISI 的时间窗内接受连接。”第二个命题是：“该服务还能从一个 Class C 站点，经由相应路由和主机实现条件被访问。”观察位置一变，原先隐藏的依赖就显现出来。

汇总表也需要来源

RFC 847 把每周接受数、主机总数和百分比放入一张表，并估计有 37 台特殊用途主机，占 11%，不应被期待开放三个服务，所以合理上限是 89% 而非 100%。不开放 Telnet 不等于不属于互联网。

这张汇总表也留下可见错误。第一行 FTP 把 70/315 印成 26%，实际约为 22%；RFC 842 的一个 Telnet 分母写成 382，而相邻服务是 328；RFC 843 的 FTP 分母出现 389，而该次主机规模为 329；RFC 845 的一处日期又被写成 1982 年 2 月。

这些异常不是删掉整组调查的理由，而是保留分子、分母、方法和原始 RFC 的理由。只要证据链还在，派生值就能重算；如果只剩一个漂亮百分比，错误反而失去可纠正性。

测量权没有扩张成管理权

测量者决定探测端口、时段和结果词汇。远端运营者决定运行什么软件、开放什么服务，并承担实际运行后果。一次 accepted 不授权测量者操作主机；一次 timeout 也不转移所有权，不证明失职。

运行事实之所以高于目录声明，是因为其他参与者能够本地复现它。但证据的权威必须与命题同样狭窄。端口接受可以证明一次连接被接受，不能认证所有 TCP 要求、操作者身份、服务质量或全网可达。

RFC 832 没有造出完美普查。它造出了一条公开链路：声明、实验、分类结果、复测、下一版实验。主机表说 TCP，网络可以用不止一种方式回答。

来源与证据边界

这些 RFC 记录迁移计划、带日期的目录声明、连接实验及其汇总。它们不证明今天的部署、完整协议合规、运营者身份、服务授权或业务完成。任何负面结果都受原文所写观察点、路径、方法和时间限制。