1. Introduction (简介)
本文档构成 Network Time Protocol (网络时间协议, NTP) 第3版的正式规范, 该协议用于在一组分布式时间服务器和客户端之间同步计时. 它定义了 NTP 使用的架构, 算法, 实体和协议, 主要面向实现者. 配套文档 [MIL91a] 总结了在典型互联网条件下的需求, 分析模型, 算法分析和性能. 另一份文档 [MIL91b] 描述了 NTP 时间尺度及其与当前使用的其他标准时间尺度的关系. NTP 最初在 RFC-958 [MIL85c] 中描述, 但此后经历了重大演变, 最终形成了 RFC-1119 [MIL89] 中描述的最新 NTP 第2版. 它建立在 Internet Protocol (互联网协议, IP) [DAR81a] 和 User Datagram Protocol (用户数据报协议, UDP) [POS80] 之上, 提供无连接传输机制; 但它也很容易适配到其他协议套件. NTP 从 Time Protocol (时间协议) [POS83b] 和 ICMP Timestamp message (ICMP 时间戳消息) [DAR81b] 演变而来, 但专门设计为即使在涉及多个网关, 高度分散延迟和不可靠网络的典型互联网路径上使用时, 也能保持准确性和健壮性.
服务环境由第2节中描述的实现模型和服务模型组成. 实现模型基于多进程操作系统架构, 尽管也可以使用其他架构. 服务模型基于可返回时间设计, 该设计仅依赖于测量的时钟偏移量, 但不需要可靠的消息传递. 同步子网使用自组织, 分层主从配置, 同步路径由最小权重生成树确定. 虽然可能存在多个主节点 (主服务器), 但不需要选举协议.
NTP 本身在第3节中描述. 它提供了协议机制, 原则上可以将时间同步到纳秒量级的精度, 同时在下个世纪保持无歧义的日期. 该协议包括规定本地时钟特性和估计其可能同步的时间服务器误差的条款. 它还包括与多个相互怀疑的, 分层分布的主要参考源 (如无线电同步时钟) 一起操作的条款.
第4节描述了对连续收集的时钟偏移量样本进行去毛刺和平滑处理的有用算法. 这些算法从 [MIL85a] 中建议的算法演变而来, 经过 [MIL85b] 中描述的实验结果的改进, 并在过去三年的典型操作条件下进一步演变. 此外, 由于在美国多个站点运行包括无线电时钟在内的多服务器子网以及在美国和欧洲拥有客户端的经验, 已经开发出可靠的算法 [DEC89], [MIL91a], 用于从可能包含故障时钟的群体中选择良好的时钟, 并在第4节中描述.
NTP 可实现的精度在很大程度上取决于本地时钟硬件的精度以及对设备和进程延迟的严格控制. 必须包含根据 NTP 产生的校正来调整软件逻辑时钟时间和频率的条款. 第5节描述了从 [MIL83b] 和 [MIL88b] 中描述的 Fuzzball 实现演变而来的本地时钟设计. 该设计包括偏移量调整, 频率补偿和去毛刺机制, 即使在与主要参考源的同步丢失后的较长时间内, 也能达到毫秒量级的精度.
与 Internet Protocol (IP) 和 User Datagram Protocol (UDP) 一起使用的 NTP 数据包格式的具体细节在附录 A 中介绍, 而建议的辅助 NTP 控制消息的详细信息 (当综合网络监控设施不可用时可以使用) 在附录 B 中介绍. 附录 C 包含可选认证机制的规范和实现细节, 该机制可用于控制访问和防止未经授权的数据修改, 而附录 D 包含 NTP 第3版与以前版本之间差异的列表. 附录 E 扩展了与计算机网络和 NTP 特有的精密时间尺度和日历日期相关的问题. 附录 F 描述了一种可选算法, 通过组合多个时钟的时间偏移量来提高精度. 附录 G 提供了 NTP 本地时钟算法的详细数学模型和分析. 附录 H 分析了误差的来源和传播, 并提出了与时间传输服务相关的正确性原则. 附录 I 说明了第4节中描述的时钟过滤, 时钟选择和相关算法的 C 语言代码段.
1.1. Related Technology (相关技术)
互联网协议套件中已规定了其他机制来记录和传输事件发生的时间, 包括 Daytime protocol (白天协议) [POS83a], Time Protocol (时间协议) [POS83b], ICMP Timestamp message (ICMP 时间戳消息) [DAR81b] 和 IP Timestamp option (IP 时间戳选项) [SU81]. 互联网中测量时钟偏移量和往返延迟的实验结果在 [MIL83a], [MIL85b], [COL88] 和 [MIL88a] 中讨论. 其他同步算法在 [LAM78], [GUS84], [HAL84], [LUN84], [LAM85], [MAR85], [MIL85a], [MIL85b], [MIL85c], [GUS85b], [SCH86], [TRI86], [RIC88], [MIL88a], [DEC89] 和 [MIL91a] 中讨论, 而基于这些算法的协议在 [MIL81a], [MIL81b], [MIL83b], [GUS85a], [MIL85c], [TRI86], [MIL88a], [DEC89] 和 [MIL91a] 中描述. NTP 使用从这些算法演变而来的技术, 并结合了线性系统和一致性方法. 数字电话网络同步的线性方法在 [LIN80] 中总结, 而时钟同步的一致性方法在 [LAM85] 中总结.
Digital Time Service (数字时间服务, DTS) [DEC89] 与 NTP 具有许多相同的服务目标. DTS 设计在受管 LAN 或 LAN 集群环境中运行时, 非常强调配置管理和正确性原则, 而 NTP 在非受管的全球互联网环境中运行时, 非常强调服务的准确性和稳定性. 在 DTS 中, 同步子网由 clerks (客户端), servers (服务器), couriers (信使) 和 time providers (时间提供者) 组成. 就 NTP 术语而言, time provider 是主要参考源, courier 是旨在从一个或多个远程主服务器导入时间以进行本地重新分发的辅助服务器, 而 server 旨在为可能许多终端节点或 clerks 提供时间. 与 NTP 不同, DTS 在时钟选择中不需要或使用模式或层级信息, 也不包括过滤计时噪声, 从一组假定正确的时钟中选择最准确的时钟或补偿固有频率误差的条款.
事实上, NTP 的最新修订采用了 DTS 的某些功能以支持正确性原则. 这些包括界定时间传输过程中固有的最大误差的机制, 以及使用可证明正确 (在规定假设下) 的机制来拒绝时钟选择过程中不适当的对等节点. 这些功能在本文档的第4节和附录 H 中描述.
Fuzzball 路由协议 [MIL83b] (有时称为 Hellospeak) 将时间同步直接纳入路由协议设计. 一个或多个进程与外部参考源 (如无线电时钟或 NTP 守护进程) 同步, 路由算法构建以这些进程为根的最小权重生成树. 然后, 时钟偏移量沿生成树的弧分发到系统中的所有进程, 并使用本文档第5节中描述的过程校正各种进程时钟. 虽然可以看出 Hellospeak 的设计强烈影响了 NTP 的设计, 但 Hellospeak 本身不是互联网协议, 不适合在其本地网络环境之外使用.
Unix 4.3bsd 时间守护进程 timed [GUS85a] 使用单个主时间守护进程来测量多个从属主机的偏移量并向它们发送定期校正. 在此模型中, 主节点使用选举算法 [GUS85b] 确定, 该算法旨在避免没有主节点被选出或选出多个主节点的情况. 选举过程需要广播能力, 这不是互联网的普遍特性. 虽然此模型已扩展为支持分层配置, 其中一个网络上的从属节点充当另一个网络上的主节点 [TRI86], 但该模型需要手工制作的配置表来建立层次结构并避免循环. 除了繁重但可能不频繁的选举过程开销外, 偏移量测量/校正过程每次更新需要的消息数量是 NTP 的两倍.
[KOP87] 中描述了一种具有类似 NTP 功能的方案. 该方案适用于多服务器 LAN, 其中一组可能许多时间服务器中的每一个使用定期带时间戳的消息确定其相对于集合中每个其他服务器的本地时间偏移量, 然后使用 [LUN84] 的 Fault-Tolerant Average (容错平均, FTA) 算法确定本地时钟校正. FTA 算法在最多 k 个服务器可能出现故障的情况下很有用, 它对偏移量进行排序, 丢弃 k 个最高和最低的偏移量, 并对其余偏移量取平均值. 如 [SCH86] 中所述, 该方案最适合支持广播的 LAN 环境, 在互联网环境中会产生不可接受的开销. 此外, 由于本文第4节给出的原因, FTA 算法的统计特性在具有高度分散延迟的互联网环境中可能不是最优的.
关于在某些时钟不可信的社区中维护准确时间的问题, 已经进行了大量研究. truechimer (真实计时器) 是一种将计时精度维持在先前发布 (且受信任) 标准内的时钟, 而 falseticker (虚假计时器) 是不满足此条件的时钟. 确定特定时钟是 truechimer 还是 falseticker 是一个有趣的抽象问题, 可以使用 [LAM85] 和 [SRI87] 中总结的一致性方法来解决.
收敛函数对系统中时钟之间的偏移量进行操作, 通过减少或消除由 falseticker 引起的误差来提高精度. 收敛函数有两类: 涉及交互收敛算法的和涉及交互一致性算法的. 交互收敛算法使用统计聚类技术, 如 [HAL84] 的容错平均算法, [LUN84] 的 CNV 算法, [MIL85a] 的多数子集算法, [RIC88] 的非拜占庭算法, [SCH86] 的自我中心算法, [MAR85] 和 [DEC89] 的交叉算法以及本文档第4节中的算法.
交互一致性算法旨在检测可能在连续读数或对不同读者指示严重不一致偏移量的故障时钟进程. 这些算法使用涉及连续轮次读数的一致性协议, 可能经过中继并可能通过数字签名增强. 示例包括 [HAL84] 的烟火算法和 [SRI87] 的最优算法. 然而, 这些算法需要大量消息, 特别是当涉及大量时钟时, 并且旨在检测在互联网经验中很少发现的故障. 出于这些原因, 本文档不再进一步考虑它们.
在实践中, 除了统计基础之外, 不可能确定哪些是 truechimer, 哪些是 falseticker, 特别是在分层配置和统计噪声较大的互联网中. 虽然可以界定时间传输过程中的最大误差 (假设为硬件组件采用足够宽松的容差), 但这通常会导致相当差的精度和稳定性. NTP 设计及其前身所采用的方法涉及相互耦合的振荡器和最大似然估计以及时钟选择过程, 以及允许相对于主要参考源正确性的规定假设做出可证明的误差界限断言的设计. 从分析角度来看, 分布式 NTP 对等节点系统作为一组耦合的锁相振荡器运行, 更新算法充当相位检测器, 本地时钟充当受控振荡器, 但在时间传输过程的每个步骤中计算确定性误差界限.
第3节中描述的特定偏移量测量和计算过程是某些数字电话网络 [LIN80] 中使用的可返回时间系统的变体. 时钟过滤和选择算法的设计使时钟同步子网自组织成分层主从配置 [MIT80]. 就计时精度和稳定性而言, NTP 与数字电话系统的相似性并非偶然, 因为此类系统已被广泛研究 [LIN80], [BRA80]. NTP 模型的独特之处在于自适应配置, 轮询, 过滤, 选择和正确性机制, 这些机制使系统的动态特性适应无处不在的互联网环境.