摘要

  • 1985 年关于网络时间的证据分散在三份文件中：RFC 958 描述 NTP 报文，RFC 956 讨论时钟选择算法，RFC 957 记录实验。
  • 实验结果取决于具体链路和测试条件。达到毫秒量级需要大量样本，这不是对整个互联网所有时钟的精度保证。

报文里有时间，不等于时钟已经同步

时间服务可以返回一个时间值，但这并不能说明时钟是否可信、消息在网络中延迟了多少，也没有说明多次观测应如何合并。早期 NTP 文档恰好把这些问题拆开了。

1985 年 9 月发布的 RFC 958 规定了 NTP 的数据表示和消息格式。数据包不只携带时间，还包括参考时钟的类型、本地时钟精度、估计误差和漂移率。四个时间戳分别标记请求离开客户端、到达服务器、响应离开服务器和返回客户端的时刻，供双方估算偏移和往返时延。但 RFC 958 没有规定如何从多个时钟中选择来源，也没有定义滤波观测值的算法；这些工作被留给后续研究。

这一区分很重要，因为实际时钟的偏差可能来自硬件、软件、无线电接收、网络时延或操作失误。RFC 956 把同步视作统计估计问题：比较观测、识别异常值，再估算哪个时间来源更可靠。一次读数不足以判定一台时钟好坏。

测试链路本身也在传输数据

RFC 957 提供了实验层面的证据。它记录了 DCnet 的时钟设计，以及涉及主机、参考时钟和多种链路的测试。有些测试专门观察通过同时承载普通数据的路径进行同步时会发生什么。它关注的是计时消息与常规流量共享网络的效果，而不只是安静实验室里的一次请求与应答。

1985 年 6 月下旬至 7 月初的一组测试包括六台主机、三个参考时钟和多种通信链路。试验时间并非偶然：测试安排与美国国家标准局广播时间中插入闰秒的时点重合。报告还考察了电网频率能否充当时钟参考，同时把“观察电网频率”和“用它校正本地时钟”区分开来。

报告没有把这些设置压缩成适用于整个互联网的单一分数。不同主机与链路的结果并不相同。它给出的结论带有条件：在受测 ARPANET 路径上，样本数量足够大时，时钟同步可以达到数毫秒量级。RFC 956 也报告了其测试数据约十毫秒量级的结果，并强调需要大量样本。这些是实验结果，不是服务承诺。

三份文件，三种证据

它们回答不同问题。RFC 958 说明通信双方交换什么；RFC 956 介绍如何解释带噪声的观测；RFC 957 说明一套特定实现和实验安排表现如何。把它们混为一谈，会把报文格式写成算法，或把一次实验写成普遍运行的证明。

1988 年的 RFC 1059 后来将 NTP 描述为包含架构、协议和同步算法，并指出它相较 RFC 958 已经显著演进。这个后续版本帮助我们看清 1985 年哪些部分尚未定型，但它不能证明每个系统在何时采用了新规范。

历史上的成果并非一只完美时钟，而是一条证据链：报文携带时间信息，算法比较不同来源并处理异常读数，实验再测量真实路径上的结果。引用早期精度数字时，应连同路径、参考时钟、样本数和条件一起说明。“数据包报告了时间”与“网络把时钟同步了”并不是同一个结论。

来源