NTP之前：Time与Daytime协议

# 在NTP之前，还有Time和Daytime协议 来源：https://www.jeffgeerling.com/blog/2026/rfc-867-868-time/ 在为VCF Midwest（https://vcfmw.org/）的古董Mac电脑搭建NTP时间演示时，我发现了RFC 867（https://www.rfc-editor.org/info/rfc867/）和RFC 868（https://www.rfc-editor.org/info/rfc868/），它们分别是"Daytime"和"Time"协议。 RFC 867 Daytime协议 我第一次接触任何形式的网络时间是在2000年，当时我从二手的PowerBook 180c升级到第一台"新"电脑Power Mac G3。随着Mac OS 8.5的推出，Apple在"日期与时间"控制面板中添加了"网络时间服务器"选项。 我记得通过PPP拨号上网，然后点击"立即设置时间"按钮，看着电脑时钟更新。当时我并没有多想，但这比之前我通过"报时电话"设置手表要精确得多——这曾是我能定期接触到的最准确的时间源。 但在NTP（RFC 1059，https://www.rfc-editor.org/info/rfc1059/，1988年）出现之前，从远程服务器获取时间的方式要随意得多。通过Time协议（RFC 868），时间请求简单到： 1. 连接到服务器的37端口（TCP连接或发送空UDP数据报） 2. 接收一个32位二进制数作为时间 就这样！ 在80年代中期，这是一种极其高效的时间传输方法，这很有帮助，因为网络字节很宝贵，你也不需要复杂的程序来处理32位时间。 但这种简单方法存在缺陷。特别是当请求通过互联网路由，经过多个不确定的跃点时： - 这个32位数字只是"自1900年1月1日00:00（午夜）GMT以来的秒数"，因此你能获得的最佳时间精度永远只有1秒（NTP提供64位精度，可以精确到微秒以上）。 - 没有对实际请求或响应进行时间戳标记，因此无法计算网络延迟或随时间平均延迟。 - 32位整数值将在2036年2月7日耗尽，导致类似Unix Y2K38纪元末日（https://en.wikipedia.org/wiki/Year_2038_problem）的"Y2K36"漏洞。（NTP也有同样的问题，但引入了纪元（https://www.ntp.org/reflib/y2k/）来解决。） 但在1983年RFC发布时，它只是网络中计算机从具有稳定时钟的服务器获取时间的便捷方式（许多计算机没有实时时钟）。它并不用于分布式数据库等关键服务，特别是在计算中1秒以上的时间精度并不常见（假设你确实*有*全球时钟！）。 Daytime协议（RFC 867）简洁但模糊。它定义了一个协议，可以返回整个日期和时间戳的可读输出，例如： ``` Tuesday, February 22, 1982 17:37:43-PST ``` 模糊性在于格式未指定，留给实现者： > "Daytime没有特定语法。建议将其限制为ASCII打印字符、空格、回车和换行符。Daytime应该只有一行。一个流行的语法是：星期，月 日，年 时间-时区。例如：Tuesday, February 22, 1982 17:37:43-PST" 紧接着，它建议了另一种格式`dd mmm yy hh:mm:ss zzz`，这用于SMTP！ 有趣的事实：NIST仍在`time.nist.gov`上运行RFC 867/868 Daytime服务（https://www.nist.gov/pml/time-and-frequency-division/time-distribution/internet-time-service-its#daytime-protocol-rfc-867）！ ``` $ nc time.nist.gov 13 61281 26-08-29 23:31:43 50 0 0 771.1 UTC(NIST) * ``` 这使用了一种定制响应，与RFC中的两种格式都不匹配： ``` JJJJJ YR-MO-DA HH:MM:SS TT L H msADV UTC(NIST) OTM ``` 其中`JJJJJ`是修正儒略日（https://en.wikipedia.org/wiki/Julian_day），OTM是"准时标记"，标记时间在收到时应该是正确的……但根据我的研究，这更像是一个"最佳猜测"，在旧式电话时间系统（https://www.nist.gov/pml/time-and-frequency-division/time-distribution/automated-computer-time-service-acts）1（https://www.jeffgeerling.com/blog/2026/rfc-867-868-time/#fn:1）中更有用，这些系统在*某些*方面更具确定性。 NIST的肯定是我在奇怪时间格式（http://www.leapsecond.com/java/gpsclock.htm）中见过的一种！ Time和Daytime协议都由Jon Postel（https://en.wikipedia.org/wiki/Jon_Postel）（又名"互联网之神"）指导，他还以SMTP、IANA和Postel法则（https://en.wikipedia.org/wiki/Robustness_principle）闻名。 我常常想知道，在编写这些协议和服务的初期亲历时代浪潮是什么感觉。而我当时更担心的是如何在家族的任天堂上获取时间。即使以当时我幼儿的大脑也无法理解网络时间传输！ ## 运行自己的Time和Daytime服务器 在了解了Time和Daytime后，我决定在VCF Midwest的展位上添加一些彩蛋——其中一个就是在37和13端口分别提供Time/Daytime服务。 如果你想运行*自己的*Time/Daytime服务器，在Linux中很简单——它们内置于`xinetd`（https://linux.die.net/man/8/xinetd）中。以下说明适用于Pi OS / Debian，但在其他发行版上类似： ``` # 安装并启用xinetd sudo apt install xinetd sudo systemctl enable xinetd # 编辑time和daytime配置 sudo nano /etc/xinetd.d/time -> 将service time tcp的disable设置为"no" -> 将service time udp的disable设置为"no" sudo nano /etc/xinetd.d/daytime -> 将service daytime tcp的disable设置为"no" -> 将service daytime udp的disable设置为"no" # 重启xinetd sudo systemctl restart xinetd ``` 确保防火墙开放了37和13端口，然后从网络上的另一台电脑： ``` # Time $ nc 10.0.37.60 37 | xxd -g 1 00000000: ee 3f 24 b3 .?$. # 通过`date`命令验证Time值： $ date -r $(( 0xee3f24c8 - 2208988800 )) Sun Aug 30 16:53:12 CDT 2026 # Daytime $ nc -v 10.0.37.60 13 Connection to 10.0.37.60 port 13 [tcp/daytime] succeeded! 30 AUG 2026 16:49:26 CDT ``` 上述`date`转换命令中的`2208988800`是1900年与1970年之间的差值（秒），这是必需的，因为UNIX时间（https://en.wikipedia.org/wiki/Unix_time）的纪元是1970年（而Time和NTP是1900年）。 如果你将参加VCF Midwest——特别是如果你有连接到展会网络的古董电脑——我可以给你一个准确的Time。或者Daytime，也行！