Network Working Group D. Mills
Request for Comments: 4330 University of Delaware
Obsoletes: 2030, 1769 January 2006
Category: Informational
Network Working Group D. Mills
Request for Comments: 4330 University of Delaware
Obsoletes: 2030, 1769 January 2006
Category: Informational
Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
用于IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.
本备忘录描述了简单网络时间协议版本4（SNTPv4），它是网络时间协议（NTP）的一个子集，用于同步Internet中的计算机时钟。当基于RFC 1305的完整NTP实现的最终性能既不需要也不合理时，可以使用SNTPv4。当使用当前和以前的NTP和SNTP版本操作时，SNTPv4不需要更改规范或已知的实现，而是澄清了允许在简单的无状态远程过程调用（RPC）中操作的某些设计功能具有与RFC 868中描述的UDP/时间协议类似的精度和可靠性期望的模式。
This memorandum obsoletes RFC 1769, which describes SNTP Version 3 (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation of SNTP.
本备忘录废除了RFC 1769（描述SNTP第3版（SNTPv3））和RFC 2030（描述SNTPv4）。其目的是纠正以前文档中的某些不一致之处，并澄清NTPv3（IPv4）和SNTPv4（IPv4、IPv6和OSI）的头格式和协议操作，这两种格式也用于SNTP。另一个目的是为路由器和其他消费设备的家庭和商业客户机实现提供指导，以保护服务器群体免受滥用。实施SNTP不需要具备NTPv3规范RFC 1305的工作知识。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................5
2. Operating Modes and Addressing ..................................5
3. NTP Timestamp Format ............................................6
4. Message Format ..................................................8
5. SNTP Client Operations .........................................13
6. SNTP Server Operations .........................................16
7. Configuration and Management ...................................19
8. The Kiss-o'-Death Packet .......................................20
9. On Being a Good Network Citizen ................................21
10. Best Practices ................................................21
11. Security Considerations .......................................24
12. Acknowledgements ..............................................24
13. Contributors ..................................................24
14. Informative References ........................................25
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................5
2. Operating Modes and Addressing ..................................5
3. NTP Timestamp Format ............................................6
4. Message Format ..................................................8
5. SNTP Client Operations .........................................13
6. SNTP Server Operations .........................................16
7. Configuration and Management ...................................19
8. The Kiss-o'-Death Packet .......................................20
9. On Being a Good Network Citizen ................................21
10. Best Practices ................................................21
11. Security Considerations .......................................24
12. Acknowledgements ..............................................24
13. Contributors ..................................................24
14. Informative References ........................................25
The Network Time Protocol Version 3 (NTPv3), specified in RFC 1305 [MIL92], is widely used to synchronize computer clocks in the global Internet. It provides comprehensive mechanisms to access national time and frequency dissemination services, organize the NTP subnet of servers and clients, and adjust the system clock in each participant. In most places of the Internet of today, NTP provides accuracies of 1-50 ms, depending on the characteristics of the synchronization source and network paths.
RFC 1305[MIL92]中规定的网络时间协议版本3（NTPv3）广泛用于同步全球互联网中的计算机时钟。它提供全面的机制来访问国家时间和频率分发服务，组织服务器和客户端的NTP子网，并调整每个参与者的系统时钟。在当今互联网的大多数地方，NTP提供1-50毫秒的精度，这取决于同步源和网络路径的特性。
RFC 1305 specifies the NTP protocol machine in terms of events, states, transition functions and actions, and engineered algorithms to improve the timekeeping quality and to mitigate several synchronization sources, some of which may be faulty. To achieve accuracies in the low milliseconds over paths spanning major portions of the Internet, these intricate algorithms, or their functional equivalents, are necessary. In many applications, accuracies on the order of significant fractions of a second are acceptable. In simple home router applications, accuracies of up to a minute may suffice. In such cases, simpler protocols, such as the Time Protocol specified in RFC 868 [POS83], have been used for this purpose. These protocols involve an RPC exchange where the client requests the time of day and the server returns it in seconds past a known reference epoch.
RFC 1305根据事件、状态、转换功能和动作以及工程算法来指定NTP协议机器，以提高计时质量并缓解多个同步源，其中一些可能出现故障。为了在跨越互联网主要部分的路径上实现低毫秒的精确度，这些复杂的算法或其功能等价物是必要的。在许多应用中，精确到秒的重要分数是可以接受的。在简单的家庭路由器应用中，高达一分钟的精度就足够了。在这种情况下，更简单的协议，如RFC 868[POS83]中规定的时间协议，已用于此目的。这些协议涉及一个RPC交换，其中客户端请求一天中的时间，服务器在已知参考历元之后的几秒钟内返回该时间。
NTP is designed for use by clients and servers with a wide range of capabilities and over a wide range of network jitter and clock frequency wander characteristics. Many users of NTP in the Internet of today use a software distribution available from www.ntp.org. The distribution, which includes the full suite of NTP options,
NTP设计用于具有广泛功能的客户端和服务器，并具有广泛的网络抖动和时钟频率漂移特性。当今互联网上的许多NTP用户使用www.NTP.org上提供的软件分发版。发行版包括全套NTP选项，
mitigation algorithms, and security schemes, is a relatively complex, real-time application. Although the software has been ported to a wide variety of hardware platforms ranging from personal computers to supercomputers, its sheer size and complexity is not appropriate for many applications. Accordingly, it is useful to explore alternative strategies using simpler software appropriate for less stringent accuracy expectations.
缓解算法和安全方案是一个相对复杂的实时应用程序。尽管该软件已被移植到从个人电脑到超级计算机的各种硬件平台上，但其庞大的规模和复杂性并不适合许多应用。因此，使用适用于不太严格精度要求的更简单软件探索替代策略是有用的。
This memo describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a simplified access paradigm for servers and clients using current and previous versions of NTP and SNTP. The access paradigm is identical to the UDP/TIME Protocol, and, in fact, it should be easy to adapt a UDP/TIME client implementation, say for a personal computer, to operate using SNTP. Moreover, SNTP is also designed to operate in a dedicated server configuration including an integrated radio clock. With careful design and control of the various latencies in the system, which is practical in a dedicated design, it is possible to deliver time accurate on the order of microseconds.
本备忘录描述了简单网络时间协议版本4（SNTPv4），它是使用当前和以前版本的NTP和SNTP的服务器和客户端的简化访问范例。访问范例与UDP/时间协议相同，而且，事实上，应该很容易使UDP/时间客户机实现（例如个人计算机）适应使用SNTP进行操作。此外，SNTP还设计用于在包括集成无线电时钟的专用服务器配置中运行。通过仔细设计和控制系统中的各种延迟（这在专用设计中是可行的），可以提供微秒级的精确时间。
The only significant protocol change in SNTPv4 from previous SNTP versions is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) (RFC 2460) and OSI (RFC 1629) addressing. However, SNTPv4 includes certain optional extensions to the basic NTP Version 3 (NTPv3) model, including a manycast mode and a public-key-based authentication scheme designed specifically for broadcast and manycast applications. Although the manycast mode is described in this memo, the authentication scheme is described in another RFC to be submitted later. Until such time that a definitive NTPv4 specification is published, the manycast and authentication features should be considered provisional. In addition, this memo introduces the kiss-o'-death message, which can be used by servers to suppress client requests as circumstances require.
SNTPv4与以前的SNTP版本相比，唯一重要的协议变化是修改了报头解释，以适应Internet协议版本6（IPv6）（RFC 2460）和OSI（RFC 1629）寻址。然而，SNTPv4包括对基本NTP版本3（NTPv3）模型的某些可选扩展，包括manycast模式和专门为广播和manycast应用设计的基于公钥的认证方案。尽管本备忘录中描述了manycast模式，但认证方案将在稍后提交的另一个RFC中描述。在最终NTPv4规范发布之前，manycast和身份验证功能应视为临时功能。此外，本备忘录还介绍了kiss-o'-death消息，服务器可以根据情况需要使用该消息来抑制客户端请求。
When operating with current and previous versions of NTP and SNTP, SNTPv4 requires no changes to the protocol or implementations now running or likely to be implemented specifically for future NTP or SNTP versions. The NTP and SNTP packet formats are the same, and the arithmetic operations to calculate the client time, clock offset, and roundtrip delay are the same. To an NTP or SNTP server, NTP and SNTP clients are indistinguishable; to an NTP or SNTP client, NTP and SNTP servers are indistinguishable. Like NTP servers operating in non-symmetric modes, SNTP servers are stateless and can support large numbers of clients; however, unlike most NTP clients, SNTP clients normally operate with only a single server at a time.
当使用当前和以前版本的NTP和SNTP运行时，SNTPv4不需要更改目前正在运行的协议或实现，也不需要更改将来可能专门针对NTP或SNTP版本实施的协议或实现。NTP和SNTP数据包格式相同，用于计算客户端时间、时钟偏移和往返延迟的算术运算相同。对于NTP或SNTP服务器，NTP和SNTP客户端无法区分；对于NTP或SNTP客户端，NTP和SNTP服务器是不可区分的。与在非对称模式下运行的NTP服务器一样，SNTP服务器是无状态的，可以支持大量客户端；但是，与大多数NTP客户端不同，SNTP客户端通常一次只使用一台服务器。
The full degree of reliability ordinarily expected of NTP servers is possible only using redundant sources, diverse paths, and the crafted
只有使用冗余源、不同的路径和精心设计的配置，NTP服务器才有可能实现通常预期的全部可靠性
algorithms of a full NTP implementation. It is strongly recommended that SNTP clients be used only at the extremities of the synchronization subnet. SNTP clients should operate only at the leaves (highest stratum) of the subnet and in configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization. SNTP servers should operate only at the root (stratum 1) of the subnet, and then only in configurations where no other source of synchronization other than a reliable radio clock or telephone modem is available.
完整NTP实现的算法。强烈建议仅在同步子网的末端使用SNTP客户端。SNTP客户端应仅在子网的叶子（最高层）处运行，并且在没有NTP或SNTP客户端依赖于另一个SNTP客户端进行同步的配置中运行。SNTP服务器应仅在子网的根（第1层）处运行，然后仅在除可靠的无线电时钟或电话调制解调器外没有其他同步源的配置中运行。
An important provision in this memo is the interpretation of certain NTP header fields that provide for IPv6 [DEE98] and OSI [COL94] addressing. The only significant difference between the NTP and SNTPv4 header formats is the four-octet Reference Identifier field, which is used primarily to detect and avoid synchronization loops. In all NTP and SNTP versions providing IPv4 addressing, primary servers use a four-character ASCII reference clock identifier in this field, whereas secondary servers use the 32-bit IPv4 address of the synchronization source. In SNTPv4 providing IPv6 and OSI addressing, primary servers use the same clock identifier, but secondary servers use the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source. A further use of this field is when the server sends a kiss-o'-death message, documented later in this memo.
本备忘录中的一项重要规定是对某些NTP头字段的解释，这些字段提供IPv6[DEE98]和OSI[COL94]寻址。NTP和SNTPv4头格式之间唯一的显著区别是四个八位组参考标识符字段，它主要用于检测和避免同步循环。在所有提供IPv4寻址的NTP和SNTP版本中，主服务器在此字段中使用四个字符的ASCII参考时钟标识符，而辅助服务器使用同步源的32位IPv4地址。在提供IPv6和OSI寻址的SNTPv4中，主服务器使用相同的时钟标识符，但辅助服务器使用同步源的IPv6或NSAP地址的MD5哈希的前32位。此字段的另一个用途是当服务器发送kiss-o'-死亡消息时，此消息将在本备忘录后面记录。
NTP Version 4 (NTPv4), now in deployment, but not yet the subject of a standards document, uses the same Reference Identifier field as SNTPv4.
NTP版本4（NTPv4）目前正在部署中，但尚未成为标准文档的主题，它使用与SNTPv4相同的引用标识符字段。
In the case of OSI, the Connectionless Transport Service (CLTS) is used as in [ISO86]. Each SNTP packet is transmitted as the TS-Userdata parameter of a T-UNITDATA Request primitive. Alternately, the header can be encapsulated in a Transport Protocol Data Unit (TPDU), which itself is transported using UDP, as described in RFC 1240 [DOB91]. It is not advised that NTP be operated at the upper layers of the OSI stack, such as might be inferred from RFC 1698 [FUR94], as this could seriously degrade accuracy. With the header formats defined in this memo, it is in principle possible to interwork between servers and clients of one protocol family and another, although the practical difficulties may make this inadvisable.
在OSI的情况下，使用无连接传输服务（CLTS），如[ISO86]所示。每个SNTP分组作为T-UNITDATA请求原语的TS Userdata参数进行传输。或者，报头可以封装在传输协议数据单元（TPDU）中，其本身使用UDP传输，如RFC 1240[DOB91]中所述。不建议在OSI堆栈的上层操作NTP，如根据RFC 1698[FUR94]推断，因为这可能会严重降低精度。使用本备忘录中定义的头格式，原则上可以在一个协议系列和另一个协议系列的服务器和客户端之间进行交互，尽管实际困难可能会使这种方式变得不可取。
In the following, indented paragraphs such as this one contain information not required by the formal protocol specification, but considered good practice in protocol implementations.
在下文中，像这样的缩进段落包含正式协议规范不需要的信息，但被认为是协议实现中的良好实践。
This memo is organized as follows. Section 2 describes how the protocol works, the various modes, and how IP addresses and UDP ports are used. Section 3 describes the NTP timestamp format, and Section
本备忘录的组织结构如下。第2节描述了协议的工作原理、各种模式以及IP地址和UDP端口的使用方式。第3节描述了NTP时间戳格式，第3节
4 the NTP message format. Section 5 summarizes SNTP client operations, and Section 6 summarizes SNTP server operations. Section 7 summarizes operation and management issues. Section 8 describes the kiss-o'-death message, newly minted with functions similar to the ICMP Source Quench and ICMP Destination Unreachable messages. Section 9 summarizes design issues important for good network citizenry and presents an example algorithm designed to give good reliability while minimizing network and server resource demands.
4 NTP消息格式。第5节总结了SNTP客户端操作，第6节总结了SNTP服务器操作。第7节总结了运营和管理问题。第8节描述了kiss-o'-死亡消息，新创建的消息具有类似于ICMP源猝灭和ICMP目标不可访问消息的功能。第9节总结了对优秀网络公民来说非常重要的设计问题，并给出了一个示例算法，该算法旨在提供良好的可靠性，同时最小化网络和服务器资源需求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BRA97].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[BRA97]中所述进行解释。
Unless excepted in context, a reference to broadcast address means IPv4 broadcast address, IPv4 multicast group address, or IPv6 address of appropriate scope. Further information on the broadcast/multicast model is in RFC 1112 [DEE89]. Details of address format, scoping rules, etc., are beyond the scope of this memo. SNTPv4 can operate with either unicast (point to point), broadcast (point to multipoint), or manycast (multipoint to point) addressing modes. A unicast client sends a request to a designated server at its unicast address and expects a reply from which it can determine the time and, optionally, the roundtrip delay and clock offset relative to the server. A broadcast server periodically sends an unsolicited message to a designated broadcast address. A broadcast client listens on this address and ordinarily sends no requests.
除非上下文中另有规定，否则对广播地址的引用是指IPv4广播地址、IPv4多播组地址或适当范围的IPv6地址。有关广播/多播模型的更多信息，请参见RFC 1112[DEE89]。地址格式、范围规则等细节不在本备忘录范围内。SNTPv4可以使用单播（点对点）、广播（点对多点）或多播（多点对点）寻址模式。单播客户端在其单播地址向指定的服务器发送请求，并期望得到一个应答，从中可以确定相对于服务器的时间以及往返延迟和时钟偏移（可选）。广播服务器定期向指定的广播地址发送未经请求的消息。广播客户端侦听此地址，通常不发送任何请求。
Manycast is an extension of the anycast paradigm described in RFC 1546 [PAR93]. It is designed for use with a set of cooperating servers whose addresses are not known beforehand. The manycast client sends an ordinary NTP client request to a designated broadcast address. One or more manycast servers listen on that address. Upon receiving a request, a manycast server sends an ordinary NTP server reply to the client. The client then mobilizes an association for each server found and continues operation with all of them. Subsequently, the NTP mitigation algorithms operate to cast out all except the best three.
Manycast是RFC1546[PAR93]中描述的选播范例的扩展。它设计用于一组事先不知道地址的协作服务器。manycast客户端向指定的广播地址发送普通NTP客户端请求。一个或多个manycast服务器侦听该地址。接收到请求后，manycast服务器会向客户端发送普通NTP服务器回复。然后，客户端为找到的每台服务器移动一个关联，并继续对所有服务器进行操作。随后，NTP缓解算法将除最好的三个算法外的所有算法都排除在外。
Broadcast servers should respond to client unicast requests, as well as send unsolicited broadcast messages. Broadcast clients may send unicast requests in order to measure the network propagation delay between the server and client and then continue operation in listen-only mode. However, broadcast servers may
广播服务器应响应客户端单播请求，并发送未经请求的广播消息。广播客户端可以发送单播请求，以测量服务器和客户端之间的网络传播延迟，然后在仅侦听模式下继续操作。但是，广播服务器可能会
choose not to respond to unicast requests, so unicast clients should be prepared to abandon the measurement and assume a default value for the delay.
选择不响应单播请求，因此单播客户端应准备放弃测量，并假定延迟的默认值。
The client and server addresses are assigned following the usual IPv4, IPv6 or OSI conventions. For NTP multicast, the IANA has reserved the IPv4 group address 224.0.1.1 and the IPv6 address ending :101 with appropriate scope. The NTP broadcast address for OSI has yet to be determined. Notwithstanding the IANA reserved addresses, other multicast addresses can be used that do not conflict with others assigned in scope. The scoping, routing, and group membership procedures are determined by considerations beyond the scope of this memo.
客户端和服务器地址是按照通常的IPv4、IPv6或OSI约定分配的。对于NTP多播，IANA保留了IPv4组地址224.0.1.1和IPv6地址结尾101，并具有适当的作用域。OSI的NTP广播地址尚未确定。尽管有IANA保留地址，但可以使用其他多播地址，这些地址不会与范围中分配的其他地址冲突。范围界定、路由和集团成员资格程序由超出本备忘录范围的考虑因素决定。
It is important to adjust the time-to-live (TTL) field in the IP header of multicast messages to a reasonable value in order to limit the network resources used by this (and any other) multicast service. Only multicast clients in scope will receive multicast server messages. Only cooperating manycast servers in scope will reply to a client request. The engineering principles that determine the proper values to be used are beyond the scope of this memo.
将多播消息的IP报头中的生存时间（TTL）字段调整为合理值以限制此（和任何其他）多播服务使用的网络资源非常重要。只有作用域中的多播客户端将接收多播服务器消息。只有作用域中协作的manycast服务器才会响应客户端请求。确定要使用的正确值的工程原理超出了本备忘录的范围。
In the case of SNTP as specified herein, there is a very real vulnerability that SNTP broadcast clients can be disrupted by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. It is strongly recommended that access controls and/or cryptographic authentication means be provided for additional security in such cases.
在本文指定的SNTP的情况下，存在一个非常真实的漏洞，即SNTP广播客户端可能会被互联网上其他地方行为不端或敌对的SNTP或NTP广播服务器中断。强烈建议在这种情况下提供访问控制和/或加密身份验证手段，以增加安全性。
It is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments including a fully functional NTP server with a number of dependent SNTP broadcast clients on the same subnet, and that IP multicast group addresses will be used only in cases where the TTL is engineered specifically for each service domain. However, these uses are not integral to the SNTP specification.
IP广播地址将主要用于IP子网和LAN段，包括在同一子网上具有多个从属SNTP广播客户端的全功能NTP服务器，并且IP多播组地址将仅在TTL专门为每个服务域设计的情况下使用。但是，这些用途不是SNTP规范的组成部分。
SNTP uses the standard NTP timestamp format described in RFC 1305 and previous versions of that document. In conformance with standard Internet practice, NTP data are specified as integer or fixed-point quantities, with bits numbered in big-endian fashion from 0 starting at the left or most significant end. Unless specified otherwise, all quantities are unsigned and may occupy the full field width with an implied 0 preceding bit 0.
SNTP使用RFC 1305和该文档的早期版本中描述的标准NTP时间戳格式。根据标准互联网实践，NTP数据被指定为整数或定点量，以大端方式从0开始在左边或最高有效端编号。除非另有规定，否则所有数量都是无符号的，可能会占用整个字段宽度，在0位之前有一个隐含的0。
Because NTP timestamps are cherished data and, in fact, represent the main product of the protocol, a special timestamp format has been established. NTP timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits, and the fraction part in the last 32 bits. In the fraction part, the non-significant low-order bits are not specified and are ordinarily set to 0.
由于NTP时间戳是珍贵的数据，事实上代表了协议的主要产品，因此建立了一种特殊的时间戳格式。NTP时间戳表示为64位无符号定点数字，相对于1900年1月1日的0h，以秒为单位。整数部分在前32位，小数部分在后32位。在分数部分，不指定非有效低阶位，通常设置为0。
It is advisable to fill the non-significant low-order bits of the timestamp with a random, unbiased bitstring, both to avoid systematic roundoff errors and to provide loop detection and replay detection (see below). It is important that the bitstring be unpredictable by an intruder. One way of doing this is to generate a random 128-bit bitstring at startup. After that, each time the system clock is read, the string consisting of the timestamp and bitstring is hashed with the MD5 algorithm, then the non-significant bits of the timestamp are copied from the result.
建议使用随机、无偏的位字符串填充时间戳的非有效低位，以避免系统舍入错误，并提供循环检测和重放检测（见下文）。入侵者不能预测位字符串，这一点很重要。一种方法是在启动时生成一个随机的128位位位字符串。之后，每次读取系统时钟时，使用MD5算法对由时间戳和位字符串组成的字符串进行散列，然后从结果中复制时间戳的非有效位。
The NTP format allows convenient multiple-precision arithmetic and conversion to UDP/TIME message (seconds), but does complicate the conversion to ICMP Timestamp message (milliseconds) and Unix time values (seconds and microseconds or seconds and nanoseconds). The maximum number that can be represented is 4,294,967,295 seconds with a precision of about 232 picoseconds, which should be adequate for even the most exotic requirements.
NTP格式允许方便的多精度运算和转换为UDP/时间消息（秒），但会使转换为ICMP时间戳消息（毫秒）和Unix时间值（秒和微秒或秒和纳秒）变得复杂。可以表示的最大数字为4294967295秒，精度约为232皮秒，即使是最特殊的要求也应足够。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that since some time in 1968 (second 2,147,483,648), the most significant bit (bit 0 of the integer part) has been set and that the 64-bit field will overflow some time in 2036 (second 4,294,967,296). There will exist a 232-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will be 0, which by convention is interpreted as an invalid or unavailable timestamp.
请注意，自1968年的某个时间（第二个2147483648）起，已设置最高有效位（整数部分的位0），并且64位字段将在2036年的某个时间溢出（第二个4294967296）。当64位字段为0时，每136年将存在一个232皮秒的间隔，此后将被忽略，按照惯例，该间隔被解释为无效或不可用的时间戳。
As the NTP timestamp format has been in use for over 20 years, it is possible that it will be in use 32 years from now, when the seconds field overflows. As it is probably inappropriate to archive NTP timestamps before bit 0 was set in 1968, a convenient way to extend the useful life of NTP timestamps is the following convention: If bit 0 is set, the UTC time is in the range 1968- 2036, and UTC time is reckoned from 0h 0m 0s UTC on 1 January
由于NTP时间戳格式已经使用了20多年，有可能从现在起32年后，当秒字段溢出时，它将被使用。由于在1968年设置位0之前归档NTP时间戳可能不合适，延长NTP时间戳使用寿命的一种方便方法是以下约定：如果设置位0，UTC时间在1968-2036之间，UTC时间从UTC 1月1日的0小时0秒开始计算
1900. If bit 0 is not set, the time is in the range 2036-2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036. Note that when calculating the correspondence, 2000 is a leap year, and leap seconds are not included in the reckoning.
1900如果未设置位0，则时间在2036-2104范围内，UTC时间从2036年2月7日的6h 28m 16s UTC开始计算。请注意，在计算对应关系时，2000是闰年，闰秒不包括在计算中。
The arithmetic calculations used by NTP to determine the clock offset and roundtrip delay require the client time to be within 34 years of the server time before the client is launched. As the time since the Unix base 1970 is now more than 34 years, means must be available to initialize the clock at a date closer to the present, either with a time-of-year (TOY) chip or from firmware.
NTP用于确定时钟偏移和往返延迟的算术计算要求在启动客户端之前，客户端时间在服务器时间的34年内。由于自Unix base 1970以来的时间现在已超过34年，因此必须有方法在更接近当前的日期初始化时钟，可以使用时间（玩具）芯片，也可以使用固件。
Both NTP and SNTP are clients of the User Datagram Protocol (UDP) specified in RFC 768 [POS80]. The structures of the IP and UDP headers are described in the cited specification documents and will not be detailed further here. The UDP port number assigned by the IANA to NTP is 123. The SNTP client should use this value in the UDP Destination Port field for client request messages. The Source Port field of these messages can be any nonzero value chosen for identification or multiplexing purposes. The server interchanges these fields for the corresponding reply messages.
NTP和SNTP都是RFC 768[POS80]中指定的用户数据报协议（UDP）的客户端。IP和UDP报头的结构在引用的规范文件中进行了描述，此处不再详细说明。IANA分配给NTP的UDP端口号为123。SNTP客户端应在UDP目标端口字段中为客户端请求消息使用此值。这些消息的源端口字段可以是为标识或多路复用目的而选择的任何非零值。服务器将这些字段交换为相应的回复消息。
This differs from the RFC 2030 specifications, which required both the source and destination ports to be 123. The intent of this change is to allow the identification of particular client implementations (which are now allowed to use unreserved port numbers, including ones of their choosing) and to attain compatibility with Network Address Port Translation (NAPT) described in RFC 2663 [SRI99] and RFC 3022 [SRI01].
这与RFC 2030规范不同，后者要求源端口和目标端口均为123。此更改的目的是允许识别特定的客户端实现（现在允许使用无保留的端口号，包括它们选择的端口号），并实现与RFC 2663[SRI99]和RFC 3022[SRI01]中描述的网络地址端口转换（NAPT）的兼容性。
Figure 1 is a description of the NTP and SNTP message format, which follows the IP and UDP headers in the message. This format is identical to the NTP message format described in RFC 1305, with the exception of the Reference Identifier field described below. For SNTP client messages, most of these fields are zero or initialized with pre-specified data. For completeness, the function of each field is briefly summarized below.
图1是NTP和SNTP消息格式的描述，它遵循消息中的IP和UDP头。该格式与RFC 1305中描述的NTP消息格式相同，但下文描述的参考标识符字段除外。对于SNTP客户端消息，这些字段中的大多数为零或使用预先指定的数据初始化。为完整起见，下文简要总结了每个字段的功能。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier (optional) (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Message Digest (optional) (128) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier (optional) (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Message Digest (optional) (128) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. NTP Packet Header
图1。NTP包头
Leap Indicator (LI): This is a two-bit code warning of an impending leap second to be inserted/deleted in the last minute of the current day. This field is significant only in server messages, where the values are defined as follows:
Leap Indicator（LI）：这是一个两位代码，警告在当天的最后一分钟插入/删除即将到来的闰秒。此字段仅在服务器消息中有效，其中的值定义如下：
LI Meaning
---------------------------------------------
0 no warning
1 last minute has 61 seconds
2 last minute has 59 seconds
3 alarm condition (clock not synchronized)
LI Meaning
---------------------------------------------
0 no warning
1 last minute has 61 seconds
2 last minute has 59 seconds
3 alarm condition (clock not synchronized)
On startup, servers set this field to 3 (clock not synchronized), and set this field to some other value when synchronized to the primary reference clock. Once set to a value other than 3, the field is never set to that value again, even if all synchronization sources become unreachable or defective.
启动时，服务器将此字段设置为3（时钟未同步），并在与主参考时钟同步时将此字段设置为其他值。一旦设置为3以外的值，该字段将不再设置为该值，即使所有同步源无法访问或出现故障。
Version Number (VN): This is a three-bit integer indicating the NTP/SNTP version number, currently 4. If necessary to distinguish between IPv4, IPv6, and OSI, the encapsulating context must be inspected.
版本号（VN）：这是一个三位整数，表示NTP/SNTP版本号，当前为4。如果需要区分IPv4、IPv6和OSI，则必须检查封装上下文。
Mode: This is a three-bit number indicating the protocol mode. The values are defined as follows:
模式：这是一个三位数字，指示协议模式。这些值的定义如下：
Mode Meaning
------------------------------------
0 reserved
1 symmetric active
2 symmetric passive
3 client
4 server
5 broadcast
6 reserved for NTP control message
7 reserved for private use
Mode Meaning
------------------------------------
0 reserved
1 symmetric active
2 symmetric passive
3 client
4 server
5 broadcast
6 reserved for NTP control message
7 reserved for private use
In unicast and manycast modes, the client sets this field to 3 (client) in the request, and the server sets it to 4 (server) in the reply. In broadcast mode, the server sets this field to 5 (broadcast). The other modes are not used by SNTP servers and clients.
在单播和多播模式下，客户端在请求中将此字段设置为3（客户端），服务器在应答中将其设置为4（服务器）。在广播模式下，服务器将此字段设置为5（广播）。SNTP服务器和客户端不使用其他模式。
Stratum: This is an eight-bit unsigned integer indicating the stratum. This field is significant only in SNTP server messages, where the values are defined as follows:
地层：这是一个八位无符号整数，表示地层。此字段仅在SNTP服务器消息中有效，其中的值定义如下：
Stratum Meaning
----------------------------------------------
0 kiss-o'-death message (see below)
1 primary reference (e.g., synchronized by radio clock)
2-15 secondary reference (synchronized by NTP or SNTP)
16-255 reserved
Stratum Meaning
----------------------------------------------
0 kiss-o'-death message (see below)
1 primary reference (e.g., synchronized by radio clock)
2-15 secondary reference (synchronized by NTP or SNTP)
16-255 reserved
Poll Interval: This is an eight-bit unsigned integer used as an exponent of two, where the resulting value is the maximum interval between successive messages in seconds. This field is significant only in SNTP server messages, where the values range from 4 (16 s) to 17 (131,072 s -- about 36 h).
轮询间隔：这是一个8位无符号整数，用作2的指数，其中结果值是以秒为单位的连续消息之间的最大间隔。此字段仅在SNTP服务器消息中有效，其中的值范围为4（16秒）到17（131072秒——大约36小时）。
Precision: This is an eight-bit signed integer used as an exponent of two, where the resulting value is the precision of the system clock in seconds. This field is significant only in server messages, where the values range from -6 for mains-frequency clocks to -20 for microsecond clocks found in some workstations.
精度：这是一个8位有符号整数，用作2的指数，其中结果值是系统时钟的精度（以秒为单位）。此字段仅在服务器消息中有效，在服务器消息中，主频时钟的值范围为-6，在某些工作站中，微秒时钟的值范围为-20。
Root Delay: This is a 32-bit signed fixed-point number indicating the total roundtrip delay to the primary reference source, in seconds with the fraction point between bits 15 and 16. Note that this variable can take on both positive and negative values, depending on the relative time and frequency offsets. This field is significant only in server messages, where the values range from negative values of a few milliseconds to positive values of several hundred milliseconds.
根延迟：这是一个32位有符号定点数字，指示到主参考源的总往返延迟，以秒为单位，小数点在位15和16之间。请注意，此变量可以具有正值和负值，具体取决于相对时间和频率偏移。此字段仅在服务器消息中有效，其中的值范围从几毫秒的负值到几百毫秒的正值。
Code External Reference Source
------------------------------------------------------------------
LOCL uncalibrated local clock
CESM calibrated Cesium clock
RBDM calibrated Rubidium clock
PPS calibrated quartz clock or other pulse-per-second
source
IRIG Inter-Range Instrumentation Group
ACTS NIST telephone modem service
USNO USNO telephone modem service
PTB PTB (Germany) telephone modem service
TDF Allouis (France) Radio 164 kHz
DCF Mainflingen (Germany) Radio 77.5 kHz
MSF Rugby (UK) Radio 60 kHz
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
WWVB Boulder (US) Radio 60 kHz
WWVH Kauai Hawaii (US) Radio 2.5, 5, 10, 15 MHz
CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz
LORC LORAN-C radionavigation system
OMEG OMEGA radionavigation system
GPS Global Positioning Service
Code External Reference Source
------------------------------------------------------------------
LOCL uncalibrated local clock
CESM calibrated Cesium clock
RBDM calibrated Rubidium clock
PPS calibrated quartz clock or other pulse-per-second
source
IRIG Inter-Range Instrumentation Group
ACTS NIST telephone modem service
USNO USNO telephone modem service
PTB PTB (Germany) telephone modem service
TDF Allouis (France) Radio 164 kHz
DCF Mainflingen (Germany) Radio 77.5 kHz
MSF Rugby (UK) Radio 60 kHz
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
WWVB Boulder (US) Radio 60 kHz
WWVH Kauai Hawaii (US) Radio 2.5, 5, 10, 15 MHz
CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz
LORC LORAN-C radionavigation system
OMEG OMEGA radionavigation system
GPS Global Positioning Service
Figure 2. Reference Identifier Codes
图2。参考标识符代码
Root Dispersion: This is a 32-bit unsigned fixed-point number indicating the maximum error due to the clock frequency tolerance, in seconds with the fraction point between bits 15 and 16. This field is significant only in server messages, where the values range from zero to several hundred milliseconds.
根频散：这是一个32位无符号定点数字，表示由于时钟频率公差而产生的最大误差，以秒为单位，小数点位于位15和16之间。此字段仅在服务器消息中有效，其中的值范围为零到几百毫秒。
Reference Identifier: This is a 32-bit bitstring identifying the particular reference source. This field is significant only in server messages, where for stratum 0 (kiss-o'-death message) and 1 (primary server), the value is a four-character ASCII string, left justified and zero padded to 32 bits. For IPv4 secondary servers, the value is the 32-bit IPv4 address of the synchronization source. For IPv6 and OSI secondary servers, the value is the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source.
引用标识符：这是标识特定引用源的32位位字符串。该字段仅在服务器消息中有效，其中对于层0（kiss-o'-死亡消息）和层1（主服务器），该值为四个字符的ASCII字符串，左对齐，零填充为32位。对于IPv4辅助服务器，该值是同步源的32位IPv4地址。对于IPv6和OSI辅助服务器，该值是同步源的IPv6或NSAP地址的MD5哈希的前32位。
Primary (stratum 1) servers set this field to a code identifying the external reference source according to Figure 2. If the external reference is one of those listed, the associated code should be used. Codes for sources not listed can be contrived, as appropriate.
主（第1层）服务器根据图2将此字段设置为标识外部参考源的代码。如果外部引用是列出的引用之一，则应使用相关代码。未列出的源代码可以根据情况进行设计。
In previous NTP and SNTP secondary servers and clients, this field was often used to walk-back the synchronization subnet to the root (primary server) for management purposes. In SNTPv4 with IPv6 or OSI, this feature is not available, because the addresses are longer than 32 bits, and only a hash is available. However, a walk-back can be accomplished using the NTP control message and the reference identifier field described in RFC 1305.
在以前的NTP和SNTP辅助服务器和客户端中，出于管理目的，此字段通常用于将同步子网回溯到根（主服务器）。在具有IPv6或OSI的SNTPv4中，此功能不可用，因为地址长度超过32位，并且只有哈希可用。然而，可以使用NTP控制消息和RFC 1305中描述的参考标识符字段来完成回退。
Reference Timestamp: This field is the time the system clock was last set or corrected, in 64-bit timestamp format.
参考时间戳：此字段是系统时钟上次设置或更正的时间，采用64位时间戳格式。
Originate Timestamp: This is the time at which the request departed the client for the server, in 64-bit timestamp format.
Originate Timestamp：这是请求离开客户端到服务器的时间，采用64位时间戳格式。
Receive Timestamp: This is the time at which the request arrived at the server or the reply arrived at the client, in 64-bit timestamp format.
接收时间戳：这是请求到达服务器或应答到达客户端的时间，采用64位时间戳格式。
Transmit Timestamp: This is the time at which the request departed the client or the reply departed the server, in 64-bit timestamp format.
传输时间戳：这是请求离开客户端或应答离开服务器的时间，采用64位时间戳格式。
Authenticator (optional): When the NTP authentication scheme is implemented, the Key Identifier and Message Digest fields contain the message authentication code (MAC) information defined in Appendix C of RFC 1305.
验证器（可选）：当实施NTP认证方案时，密钥标识符和消息摘要字段包含RFC 1305附录C中定义的消息认证码（MAC）信息。
An SNTP client can operate in unicast, broadcast, or manycast modes. In unicast mode, the client sends a request (NTP mode 3) to a designated unicast server and expects a reply (NTP mode 4) from that server. In broadcast client mode, it sends no request and waits for a broadcast (NTP mode 5) from one or more broadcast servers. In manycast mode, the client sends a request (NTP mode 3) to a designated broadcast address and expects a reply (NTP mode 4) from one or more manycast servers. The client uses the first reply received to establish the particular server for subsequent unicast operations. Later replies from this server (duplicates) or any other server are ignored. Other than the selection of address in the request, the operations of manycast and unicast clients are identical.
SNTP客户端可以在单播、广播或多播模式下运行。在单播模式下，客户端向指定的单播服务器发送请求（NTP模式3），并期望该服务器回复（NTP模式4）。在广播客户端模式下，它不发送请求，并等待来自一个或多个广播服务器的广播（NTP模式5）。在manycast模式下，客户端向指定的广播地址发送请求（NTP模式3），并期望从一个或多个manycast服务器得到回复（NTP模式4）。客户端使用接收到的第一个应答来为后续单播操作建立特定服务器。稍后来自此服务器（重复）或任何其他服务器的答复将被忽略。除了在请求中选择地址之外，manycast和unicast客户端的操作是相同的。
Client requests are normally sent at intervals depending on the frequency tolerance of the client clock and the required accuracy. However, under no conditions should requests be sent at less than one minute intervals. Further discussion on this point is in Section 9.
客户机请求通常根据客户机时钟的频率容差和所需的精度以一定的间隔发送。但是，在任何情况下，请求的发送间隔都不得少于一分钟。关于这一点的进一步讨论见第9节。
A unicast or manycast client initializes the NTP message header, sends the request to the server, and strips the time of day from the Transmit Timestamp field of the reply. For this purpose, all the NTP header fields shown above are set to 0, except the Mode, VN, and optional Transmit Timestamp fields.
单播或多播客户端初始化NTP消息头，将请求发送到服务器，并从应答的传输时间戳字段中删除一天中的时间。为此，除模式、VN和可选传输时间戳字段外，上面显示的所有NTP头字段都设置为0。
NTP and SNTP clients set the mode field to 3 (client) for unicast and manycast requests. They set the VN field to any version number that is supported by the server, selected by configuration or discovery, and that can interoperate with all previous version NTP and SNTP servers. Servers reply with the same version as the request, so the VN field of the request also specifies the VN field of the reply. A prudent SNTP client can specify the earliest acceptable version on the expectation that any server of that or a later version will respond. NTP Version 3 (RFC 1305) and Version 2 (RFC 1119) servers accept all previous versions, including Version 1 (RFC 1059). Note that Version 0 (RFC 959) is no longer supported by current and future NTP and SNTP servers.
NTP和SNTP客户端将单播和多播请求的模式字段设置为3（客户端）。他们将VN字段设置为服务器支持的、通过配置或发现选择的、可以与所有以前版本的NTP和SNTP服务器互操作的任何版本号。服务器使用与请求相同的版本进行回复，因此请求的VN字段还指定了回复的VN字段。谨慎的SNTP客户端可以指定可接受的最早版本，期望该版本或更高版本的任何服务器都会响应。NTP版本3（RFC 1305）和版本2（RFC 1119）服务器接受所有以前的版本，包括版本1（RFC 1059）。请注意，当前和未来的NTP和SNTP服务器不再支持版本0（RFC 959）。
Although setting the Transmit Timestamp field in the request to the time of day according to the client clock in NTP timestamp format is not necessary in a conforming client implementation, it is highly recommended in unicast and manycast modes. This allows a simple calculation to determine the propagation delay between the server and client and to align the system clock generally within a few tens of milliseconds relative to the server. In addition, this provides a
尽管在符合要求的客户端实现中，根据NTP时间戳格式的客户端时钟将请求中的传输时间戳字段设置为一天中的时间不是必需的，但强烈建议在单播和多播模式下使用。这允许进行简单的计算，以确定服务器和客户端之间的传播延迟，并在相对于服务器的几十毫秒内调整系统时钟。此外，这还提供了一个
simple method for verifying that the server reply is in fact a legitimate response to the specific client request and thereby for avoiding replays. In broadcast mode, the client has no information to calculate the propagation delay or to determine the validity of the server, unless one of the NTP authentication schemes is used.
一种简单的方法，用于验证服务器应答实际上是对特定客户端请求的合法响应，从而避免重播。在广播模式下，客户端没有信息来计算传播延迟或确定服务器的有效性，除非使用NTP身份验证方案之一。
To calculate the roundtrip delay d and system clock offset t relative to the server, the client sets the Transmit Timestamp field in the request to the time of day according to the client clock in NTP timestamp format. For this purpose, the clock need not be synchronized. The server copies this field to the Originate Timestamp in the reply and sets the Receive Timestamp and Transmit Timestamp fields to the time of day according to the server clock in NTP timestamp format.
为了计算相对于服务器的往返延迟d和系统时钟偏移t，客户机根据NTP时间戳格式的客户机时钟将请求中的传输时间戳字段设置为一天中的时间。为此，时钟不需要同步。服务器将此字段复制到应答中的起始时间戳，并根据NTP时间戳格式的服务器时钟将接收时间戳和发送时间戳字段设置为一天中的时间。
When the server reply is received, the client determines a Destination Timestamp variable as the time of arrival according to its clock in NTP timestamp format. The following table summarizes the four timestamps.
当接收到服务器应答时，客户机根据其NTP时间戳格式的时钟将目标时间戳变量确定为到达时间。下表总结了四个时间戳。
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received by server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received by client
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received by server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received by client
The roundtrip delay d and system clock offset t are defined as:
往返延迟d和系统时钟偏移t定义为：
d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.
d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.
Note that in general both delay and offset are signed quantities and can be less than zero; however, a delay less than zero is possible only in symmetric modes, which SNTP clients are forbidden to use. The following table summarizes the required SNTP client operations in unicast, manycast, and broadcast modes. The recommended error checks are shown in the Reply and Broadcast columns in the table. The message should be considered valid only if all the fields shown contain values in the respective ranges. Whether to believe the message if one or more of the fields marked "ignore" contain invalid values is at the discretion of the implementation.
注意，通常延迟和偏移量都是有符号量，可以小于零；然而，只有在对称模式下才可能出现小于零的延迟，SNTP客户端禁止使用对称模式。下表总结了单播、多播和广播模式下所需的SNTP客户端操作。建议的错误检查显示在表中的回复和广播列中。仅当显示的所有字段包含各自范围内的值时，该消息才应被视为有效。如果标记为“忽略”的一个或多个字段包含无效值，则是否相信该消息由实现自行决定。
Field Name Unicast/Manycast Broadcast
Request Reply
---------------------------------------------------------------
LI 0 0-3 0-3
Field Name Unicast/Manycast Broadcast
Request Reply
---------------------------------------------------------------
LI 0 0-3 0-3
VN 1-4 copied from 1-4 request
从1-4请求复制的VN 1-4
Mode 3 4 5
模式3 4 5
Stratum 0 0-15 0-15
地层0-15 0-15
Poll 0 ignore ignore
轮询0忽略忽略
Precision 0 ignore ignore
精度0忽略忽略忽略
Root Delay 0 ignore ignore
根延迟0忽略忽略忽略
Root Dispersion 0 ignore ignore
根分散度0忽略忽略
Reference Identifier 0 ignore ignore
引用标识符0忽略忽略
Reference Timestamp 0 ignore ignore
参考时间戳0忽略忽略
Originate Timestamp 0 (see text) ignore
起始时间戳0（请参阅文本）忽略
Receive Timestamp 0 (see text) ignore
接收时间戳0（请参阅文本）忽略
Transmit Timestamp (see text) nonzero nonzero
传输时间戳（见正文）非零非零
Authenticator optional optional optional
验证器可选
Although not required in a conforming SNTP client implementation, it is wise to consider a suite of sanity checks designed to avoid various kinds of abuse that might happen as the result of server implementation errors or malicious attack. Following is a list of suggested checks.
尽管在符合SNTP客户端实现中不需要，但明智的做法是考虑一套安全检查，以避免由于服务器实现错误或恶意攻击而可能发生的各种滥用。以下是建议检查的列表。
1. When the IP source and destination addresses are available for the client request, they should match the interchanged addresses in the server reply.
1. 当IP源地址和目标地址可用于客户端请求时，它们应与服务器应答中交换的地址相匹配。
2. When the UDP source and destination ports are available for the client request, they should match the interchanged ports in the server reply.
2. 当UDP源端口和目标端口可用于客户端请求时，它们应与服务器应答中的交换端口相匹配。
3. The Originate Timestamp in the server reply should match the Transmit Timestamp used in the client request.
3. 服务器应答中的起始时间戳应与客户端请求中使用的传输时间戳匹配。
4. The server reply should be discarded if any of the LI, Stratum, or Transmit Timestamp fields is 0 or the Mode field is not 4 (unicast) or 5 (broadcast).
4. 如果LI、地层或传输时间戳字段中的任何一个为0或模式字段不是4（单播）或5（广播），则应丢弃服务器应答。
5. A truly paranoid client can check that the Root Delay and Root Dispersion fields are each greater than or equal to 0 and less than infinity, where infinity is currently a cozy number like one second. This check avoids using a server whose synchronization source has expired for a very long time.
5. 一个真正的偏执狂客户可以检查根延迟和根分散场是否分别大于或等于0和小于无穷大，其中无穷大目前是一个舒适的数字，比如1秒。此检查可避免使用同步源已过期很长时间的服务器。
A SNTP server operating with either an NTP or SNTP client of the same or previous versions retains no persistent state. Because an SNTP server ordinarily does not implement the full suite of grooming and mitigation algorithms intended to support redundant servers and diverse network paths, it should be operated only in conjunction with a source of external synchronization, such as a reliable radio clock or telephone modem. In this case it operates as a primary (stratum 1) server.
使用相同或以前版本的NTP或SNTP客户端运行的SNTP服务器不保留持久状态。由于SNTP服务器通常不实施旨在支持冗余服务器和不同网络路径的全套整理和缓解算法，因此它只能与外部同步源（如可靠的无线电时钟或电话调制解调器）一起运行。在这种情况下，它作为主（第1层）服务器运行。
A SNTP server can operate with any unicast, manycast, or broadcast address or any combination of these addresses. A unicast or manycast server receives a request (NTP mode 3), modifies certain fields in the NTP header, and sends a reply (NTP mode 4), possibly using the same message buffer as the request. A manycast server listens on the designated broadcast address, but uses its own unicast IP address in the source address field of the reply. Other than the selection of address in the reply, the operations of manycast and unicast servers are identical. Broadcast messages are normally sent at intervals from 64 s to 1024 s, depending on the expected frequency tolerance of the client clocks and the required accuracy.
SNTP服务器可以使用任何单播、多播或广播地址或这些地址的任何组合进行操作。单播或多播服务器接收请求（NTP模式3），修改NTP报头中的某些字段，并发送回复（NTP模式4），可能使用与请求相同的消息缓冲区。manycast服务器侦听指定的广播地址，但在应答的源地址字段中使用自己的单播IP地址。除了在应答中选择地址之外，多播服务器和单播服务器的操作是相同的。广播消息通常以64秒到1024秒的间隔发送，这取决于客户端时钟的预期频率容差和所需的精度。
Unicast and manycast servers copy the VN and Poll fields of the request intact to the reply and set the Stratum field to 1.
单播和多播服务器将请求的VN和轮询字段原封不动地复制到应答中，并将层字段设置为1。
Note that SNTP servers normally operate as primary (stratum 1) servers. Although operating at higher strata (up to 15) while synchronizing to an external source such as a GPS receiver is not forbidden, this is strongly discouraged.
请注意，SNTP服务器通常作为主（第1层）服务器运行。尽管在与外部源（如GPS接收器）同步时，在较高地层（高达15层）进行操作是不被禁止的，但强烈建议不要这样做。
If the Mode field of the request is 3 (client), the reply is set to 4 (server). If this field is set to 1 (symmetric active), the reply is set to 2 (symmetric passive). This allows clients configured in either client (NTP mode 3) or symmetric active (NTP mode 1) to interoperate successfully, even if configured in possibly suboptimal ways. For any other value in the Mode field, the request is
如果请求的模式字段为3（客户端），则应答设置为4（服务器）。如果此字段设置为1（对称主动），则应答设置为2（对称被动）。这允许在客户端（NTP模式3）或对称活动（NTP模式1）中配置的客户端成功地进行互操作，即使配置方式可能不太理想。对于模式字段中的任何其他值，请求为
discarded. In broadcast (unsolicited) mode, the VN field is set to 4, the Mode field is set to 5 (broadcast), and the Poll field set to the nearest integer base-2 logarithm of the poll interval.
丢弃的。在广播（未经请求）模式下，VN字段设置为4，模式字段设置为5（广播），轮询字段设置为轮询间隔最接近的整数以2为底的对数。
Note that it is highly desirable that a broadcast server also supports unicast clients. This is so a potential broadcast client can calculate the propagation delay using a client/server exchange prior to switching to broadcast client (listen-only) mode. By design, a manycast server is also a unicast server. There does not seem to be a great advantage for a server to operate as both broadcast and manycast at the same time, although the protocol specification does not forbid it.
注意，广播服务器也支持单播客户端是非常理想的。这使得潜在的广播客户端可以在切换到广播客户端（仅侦听）模式之前，使用客户端/服务器交换计算传播延迟。根据设计，manycast服务器也是单播服务器。服务器同时作为广播和manycast运行似乎没有什么好处，尽管协议规范并不禁止这样做。
A broadcast or manycast server does not send packets if not synchronized to a correctly operating reference source. It may or may not respond to a client request if it is not synchronized, but the preferred option is to respond because this allows reachability to be determined regardless of synchronization state. If the server has never synchronized to a reference source, the LI field is set to 3 (unsynchronized). Once synchronized to a reference source, the LI field is set to one of the other three values and remains at the last value set even if the reference source becomes unreachable or turns faulty.
如果未同步到正确运行的参考源，则广播或manycast服务器不会发送数据包。如果客户端请求未同步，它可能会响应，也可能不会响应，但首选的选项是响应，因为这允许在不考虑同步状态的情况下确定可达性。如果服务器从未同步到参考源，则LI字段设置为3（未同步）。与参考源同步后，LI字段将设置为其他三个值之一，即使参考源无法访问或出现故障，LI字段也将保持为最后设置的值。
If the server is synchronized to a reference source, the Stratum field is set to 1, and the Reference Identifier field is set to the ASCII source identifier shown in Figure 2. If the server is not synchronized, the Stratum field is set to zero, and the Reference Identifier field is set to an ASCII error identifier described below.
如果服务器与参考源同步，则地层字段设置为1，参考标识符字段设置为ASCII源标识符，如图2所示。如果服务器未同步，则地层字段设置为零，参考标识符字段设置为下文所述的ASCII错误标识符。
The Precision field is set to reflect the maximum reading error of the system clock. For all practical cases it is computed as the negative base-2 logarithm of the number of significant bits to the right of the decimal point in the NTP timestamp format. The Root Delay and Root Dispersion fields are set to 0 for a primary server.
精度字段设置为反映系统时钟的最大读取误差。对于所有实际情况，其计算为NTP时间戳格式中小数点右侧有效位数的负底2对数。对于主服务器，根延迟和根分散字段设置为0。
The timestamp fields in the server message are set as follows. If the server is unsynchronized or first coming up, all timestamp fields are set to zero, with one exception. If the message is a reply to a previously received client request, the Transmit Timestamp field of the request is copied unchanged to the Originate Timestamp field of the reply. It is important that this field be copied intact, as an NTP or SNTP client uses it to avoid bogus messages.
服务器消息中的时间戳字段设置如下。如果服务器未同步或首次启动，则所有时间戳字段都设置为零，只有一个例外。如果消息是对先前接收到的客户端请求的回复，则请求的传输时间戳字段将原封不动地复制到回复的发起时间戳字段。必须完整复制此字段，因为NTP或SNTP客户端使用它来避免虚假消息。
If the server is synchronized, the Reference Timestamp is set to the time the last update was received from the reference source. The Originate Timestamp field is set as in the unsynchronized case above. The Transmit Timestamp field is set to the time of day when the
如果服务器已同步，则参考时间戳将设置为从参考源接收上次更新的时间。初始时间戳字段的设置与上面的非同步情况相同。传输时间戳字段设置为
message is sent. In broadcast messages the Receive Timestamp field is set to zero and copied from the Transmit Timestamp field in other messages. The following table summarizes these actions.
消息已发送。在广播消息中，接收时间戳字段设置为零，并从其他消息中的发送时间戳字段复制。下表总结了这些操作。
Field Name Unicast/Manycast Broadcast
Request Reply
----------------------------------------------------------------
LI ignore as needed as needed
Field Name Unicast/Manycast Broadcast
Request Reply
----------------------------------------------------------------
LI ignore as needed as needed
VN 1-4 copied from 4 request
VN 1-4从4请求复制
Mode 3 4 5
模式3 4 5
Stratum ignore 1 1
第11层
Poll ignore copied from log2 poll request interval
轮询忽略从log2轮询请求间隔复制
Precision ignore -log2 server -log2 server significant significant bits bits
精度忽略-log2服务器-log2服务器有效位
Root Delay ignore 0 0
根延迟忽略0
Root Dispersion ignore 0 0
根分散忽略0
Reference Identifier ignore source ident source ident
参考标识符忽略源标识符源标识符
Reference Timestamp ignore time of last time of last source update source update
参考时间戳忽略上次源更新的最后一次源更新的最后一次时间
Originate Timestamp ignore copied from 0 transmit timestamp
起始时间戳忽略从0复制的传输时间戳
Receive Timestamp ignore time of day 0
接收时间戳忽略日期0的时间
Transmit Timestamp (see text) time of day time of day
传输时间戳（见正文）一天中的时间一天中的时间
Authenticator optional optional optional
验证器可选
There is some latitude on the part of most clients to forgive invalid timestamps, such as might occur when the server is first coming up or during periods when the reference source is inoperative. The most important indicator of an unhealthy server is the Stratum field, in
大多数客户机都有一定的自由度来原谅无效的时间戳，例如在服务器第一次启动时或在参考源不工作时可能发生的时间戳。表示服务器不正常的最重要指标是地层字段
which a value of 0 indicates an unsynchronized condition. When this value is displayed, clients should discard the server message, regardless of the contents of other fields.
其值为0表示未同步状态。显示此值时，无论其他字段的内容如何，客户端都应丢弃服务器消息。
Initial setup for SNTP servers and clients can be done using a web client, if available, or a serial port, if not. Some folks hoped that in-service management of NTP and SNTPv4 servers and clients could be performed using SNMP and a suitable MIB to be published, and this has happened in some commercial SNTP servers. But, the means that have been used in the last two decades and probably will be used in the next is the NTP control and monitoring protocol defined in RFC 1305. Ordinarily, SNTP servers and clients are expected to operate with little or no site-specific configuration, other than specifying the client IP address, subnet mask, and gateway.
SNTP服务器和客户端的初始设置可以使用web客户端（如果可用）或串行端口（如果不可用）完成。一些人希望NTP和SNTPv4服务器和客户端的服务管理可以使用SNMP和要发布的适当MIB来执行，这在一些商业SNTP服务器中已经发生。但是，在过去二十年中使用的方法，可能在下一个十年中使用的方法是RFC 1305中定义的NTP控制和监测协议。通常，除了指定客户机IP地址、子网掩码和网关之外，SNTP服务器和客户机预期很少或没有特定于站点的配置。
Unicast clients must be provided with one or more designated server names or IP addresses. If more than one server is provided, one can be used for active operation and one of the others for backup should the active one fail or show an error condition. It is not normally useful to use more than one server at a time, as with millions of SNTP-enabled devices expected in the near future, such use would represent unnecessary drain on network and server resources.
单播客户端必须提供一个或多个指定的服务器名称或IP地址。如果提供了多台服务器，则可以使用一台服务器进行活动操作，如果活动服务器出现故障或出现错误，则可以使用另一台服务器进行备份。一次使用多台服务器通常是没有用的，因为在不久的将来会有数以百万计的支持SNTP的设备，这样的使用会对网络和服务器资源造成不必要的消耗。
Broadcast servers and manycast clients must be provided with the TTL and local broadcast or multicast group address. Unicast and manycast servers and broadcast clients may be configured with a list of address-mask pairs for access control, so that only those clients or servers known to be trusted will be accepted. Multicast servers and clients must implement the IGMP protocol and be provided with the local broadcast or multicast group address as well. The configuration data for cryptographic authentication is beyond the scope of this memo.
广播服务器和多播客户端必须提供TTL和本地广播或多播组地址。单播和多播服务器以及广播客户端可以配置用于访问控制的地址掩码对列表，以便只接受已知受信任的那些客户端或服务器。多播服务器和客户端必须实现IGMP协议，并提供本地广播或多播组地址。加密身份验证的配置数据超出了本备忘录的范围。
There are several scenarios that provide automatic server discovery and selection for SNTP clients with no pre-specified server configuration. For instance, a role server with CNAME such as pool.ntp.org returns a randomized list of volunteer secondary server addresses, and the client can select one or more as candidates. For an IP subnet or LAN segment including an NTP or SNTP server, SNTP clients can be configured as broadcast clients. The same approach can be used with multicast servers and clients. In both cases, provision of an access control list is a good way to ensure that only trusted sources can be used to set the system clock.
有几种方案可以为没有预先指定服务器配置的SNTP客户端提供自动服务器发现和选择。例如，具有CNAME的角色服务器（如pool.ntp.org）返回志愿者辅助服务器地址的随机列表，客户端可以选择一个或多个作为候选服务器。对于包括NTP或SNTP服务器的IP子网或LAN段，SNTP客户端可以配置为广播客户端。同样的方法也可以用于多播服务器和客户端。在这两种情况下，提供访问控制列表是确保只有受信任的源才能用于设置系统时钟的好方法。
In another scenario suitable for an extended network with significant network propagation delays, clients can be configured for manycast addresses, both upon initial startup and after some period when the currently selected unicast source has not been heard. Following the defined protocol, the client binds to the server from which the first reply is received and continues operation in unicast mode.
在另一个适用于具有显著网络传播延迟的扩展网络的场景中，可以在初始启动时以及在未听到当前选择的单播源的一段时间后为多播地址配置客户端。按照定义的协议，客户端绑定到接收第一个应答的服务器，并以单播模式继续操作。
In the rambunctious Internet of today, it is imperative that some means be available to tell a client to stop making requests and to go somewhere else. A recent experience involved a large number of home/office routers all configured to use a particular university time server. Under some error conditions, a substantial fraction of these routers would send packets at intervals of one second. The resulting traffic spike was dramatic, and extreme measures were required to diagnose the problem and to bring it under control. The conclusion is that clients must respect the means available to targeted servers to stop them from sending packets.
在当今杂乱无章的互联网中，有必要采取某种手段来告诉客户停止提出请求，到其他地方去。最近的经验涉及大量家庭/办公室路由器，所有路由器都配置为使用特定的大学时间服务器。在某些错误情况下，这些路由器中的很大一部分会以1秒的间隔发送数据包。由此产生的交通高峰是巨大的，需要采取极端措施来诊断问题并加以控制。结论是，客户端必须尊重目标服务器可用的阻止其发送数据包的方法。
According to the NTP specification RFC 1305, if the Stratum field in the NTP header is 1, indicating a primary server, the Reference Identifier field contains an ASCII string identifying the particular reference clock type. However, in RFC 1305 nothing is said about the Reference Identifier field if the Stratum field is 0, which is called out as "unspecified". However, if the Stratum field is 0, the Reference Identifier field can be used to convey messages useful for status reporting and access control. In NTPv4 and SNTPv4, packets of this kind are called Kiss-o'-Death (KoD) packets, and the ASCII messages they convey are called kiss codes. The KoD packets got their name because an early use was to tell clients to stop sending packets that violate server access controls.
根据NTP规范RFC 1305，如果NTP报头中的地层字段为1，表示主服务器，则参考标识符字段包含标识特定参考时钟类型的ASCII字符串。然而，在RFC 1305中，如果地层字段为0（称为“未指定”），则未提及参考标识符字段。但是，如果地层字段为0，则参考标识符字段可用于传递对状态报告和访问控制有用的消息。在NTPv4和SNTPv4中，这类数据包称为Kiss-o'-Death（KoD）数据包，它们传递的ASCII消息称为Kiss代码。KoD数据包之所以得名，是因为早期的用途是告诉客户端停止发送违反服务器访问控制的数据包。
In general, an SNTP client should stop sending to a particular server if that server returns a reply with a Stratum field of 0, regardless of kiss code, and an alternate server is available. If no alternate server is available, the client should retransmit using an exponential-backoff algorithm described in the next section.
一般来说，如果某个服务器返回一个带有0层字段的回复，不管kiss代码如何，并且有一个备用服务器可用，那么SNTP客户端应该停止向该服务器发送。如果没有备用服务器可用，客户端应使用下一节中描述的指数退避算法重新传输。
The kiss codes can provide useful information for an intelligent client. These codes are encoded in four-character ASCII strings left justified and zero filled. The strings are designed for character displays and log files. Usually, only a few of these codes can occur with SNTP clients, including DENY, RSTR, and RATE. Others can occur more rarely, including INIT and STEP, when the server is in some special temporary condition. Figure 3 shows a list of the kiss codes currently defined. These are for informational purposes only; the list might be modified or extended in the future.
kiss代码可以为智能客户端提供有用的信息。这些代码编码为四个字符的ASCII字符串，左对齐，零填充。字符串用于字符显示和日志文件。通常，这些代码中只有少数可以在SNTP客户机上出现，包括DENY、RSTR和RATE。当服务器处于某种特殊的临时状态时，其他情况可能很少发生，包括INIT和STEP。图3显示了当前定义的kiss代码列表。这些仅供参考之用；该列表将来可能会被修改或扩展。
Code Meaning
--------------------------------------------------------------
ACST The association belongs to a anycast server
AUTH Server authentication failed
AUTO Autokey sequence failed
BCST The association belongs to a broadcast server
CRYP Cryptographic authentication or identification failed
DENY Access denied by remote server
DROP Lost peer in symmetric mode
RSTR Access denied due to local policy
INIT The association has not yet synchronized for the first
time
MCST The association belongs to a manycast server
NKEY No key found. Either the key was never installed or
is not trusted
RATE Rate exceeded. The server has temporarily denied access
because the client exceeded the rate threshold
RMOT Somebody is tinkering with the association from a remote
host running ntpdc. Not to worry unless some rascal has
stolen your keys
STEP A step change in system time has occurred, but the
association has not yet resynchronized
Code Meaning
--------------------------------------------------------------
ACST The association belongs to a anycast server
AUTH Server authentication failed
AUTO Autokey sequence failed
BCST The association belongs to a broadcast server
CRYP Cryptographic authentication or identification failed
DENY Access denied by remote server
DROP Lost peer in symmetric mode
RSTR Access denied due to local policy
INIT The association has not yet synchronized for the first
time
MCST The association belongs to a manycast server
NKEY No key found. Either the key was never installed or
is not trusted
RATE Rate exceeded. The server has temporarily denied access
because the client exceeded the rate threshold
RMOT Somebody is tinkering with the association from a remote
host running ntpdc. Not to worry unless some rascal has
stolen your keys
STEP A step change in system time has occurred, but the
association has not yet resynchronized
Figure 3. Kiss Codes
图3。接吻密码
SNTP and its big brother NTP have been in explosive growth over the last few years, mirroring the growth of the Internet. Just about every Internet appliance has some kind of NTP support, including Windows XP, Cisco routers, embedded controllers, and software systems of all kinds. This is the first edition of the SNTP RFC where it has become necessary to lay down rules of engagement in the form of design criteria for SNTP client implementations. This is necessary to educate software developers regarding the proper use of Internet time server resources as the Internet expands and demands on time servers increase, and to prevent the recurrence of the sort of problem mentioned above.
SNTP和它的老大哥NTP在过去几年中一直处于爆炸性增长，反映了互联网的增长。几乎每个互联网设备都有某种NTP支持，包括Windows XP、Cisco路由器、嵌入式控制器和各种软件系统。这是SNTP RFC的第一版，其中有必要以SNTP客户端实现的设计标准的形式制定参与规则。随着互联网的发展和对时间服务器需求的增加，这对于教育软件开发人员正确使用互联网时间服务器资源是必要的，并防止上述问题再次发生。
NTP and SNTP clients can consume considerable network and server resources if they are not good network citizens. There are now consumer Internet commodity devices numbering in the millions that are potential customers of public and private NTP and SNTP servers. Recent experience strongly suggests that device designers pay particular attention to minimizing resource impacts, especially if large numbers of these devices are deployed. The most important
如果NTP和SNTP客户端不是良好的网络公民，它们可能会消耗大量的网络和服务器资源。现在有数以百万计的消费性互联网商品设备，它们是公共和私人NTP和SNTP服务器的潜在客户。最近的经验强烈表明，设备设计者特别注意最小化对资源的影响，尤其是在部署了大量此类设备的情况下。最重要的
design consideration is the interval between client requests, called the poll interval. It is extremely important that the design use the maximum poll interval consistent with acceptable accuracy.
设计考虑是客户端请求之间的间隔，称为轮询间隔。设计使用与可接受精度一致的最大轮询间隔非常重要。
1. A client MUST NOT under any conditions use a poll interval less than 15 seconds.
1. 客户端在任何情况下都不得使用小于15秒的轮询间隔。
2. A client SHOULD increase the poll interval using exponential backoff as performance permits and especially if the server does not respond within a reasonable time.
2. 在性能允许的情况下，客户机应该使用指数退避来增加轮询间隔，特别是当服务器在合理的时间内没有响应时。
3. A client SHOULD use local servers whenever available to avoid unnecessary traffic on backbone networks.
3. 只要可用，客户机就应该使用本地服务器，以避免骨干网络上不必要的流量。
4. A client MUST allow the operator to configure the primary and/or alternate server names or addresses in addition to or in place of a firmware default IP address.
4. 除固件默认IP地址外，客户机必须允许操作员配置主服务器和/或备用服务器名称或地址，或将其替换为固件默认IP地址。
5. If a firmware default server IP address is provided, it MUST be a server operated by the manufacturer or seller of the device or another server, but only with the operator's permission.
5. 如果提供了固件默认服务器IP地址，则必须是由设备制造商或销售商或其他服务器操作的服务器，但必须获得运营商的许可。
6. A client SHOULD use the Domain Name System (DNS) to resolve the server IP addresses, so the operator can do effective load balancing among a server clique and change IP address binding to canonical names.
6. 客户端应该使用域名系统（DNS）解析服务器IP地址，这样操作员就可以在服务器组之间进行有效的负载平衡，并将IP地址绑定更改为规范名称。
7. A client SHOULD re-resolve the server IP address at periodic intervals, but not at intervals less than the time-to-live field in the DNS response.
7. 客户端应定期重新解析服务器IP地址，但时间间隔不得小于DNS响应中的生存时间字段。
8. A client SHOULD support the NTP access-refusal mechanism so that a server kiss-o'-death reply in response to a client request causes the client to cease sending requests to that server and to switch to an alternate, if available.
8. 客户端应支持NTP访问拒绝机制，以便响应客户端请求的服务器kiss-o'-death应答会导致客户端停止向该服务器发送请求，并切换到备用服务器（如果可用）。
The following algorithm can be used as a pattern for specific implementations. It uses the following variables:
以下算法可用作特定实现的模式。它使用以下变量：
Timer: This is a counter that decrements at a fixed rate. When it reaches zero, a packet is sent, and the timer is initialized with the timeout for the next packet.
定时器：这是一个以固定速率递减的计数器。当它达到零时，发送一个数据包，并用下一个数据包的超时时间初始化计时器。
Maximum timeout: This is the maximum timeout determined from the given oscillator frequency tolerance and the required accuracy.
最大超时：这是根据给定振荡器频率公差和所需精度确定的最大超时。
Server Name: This is the DNS name of the server. There may be more than one of them, to be selected by some algorithm not considered here.
服务器名称：这是服务器的DNS名称。其中可能有多个，由此处未考虑的某些算法选择。
Server IP Address: This is the IPv4, IPv6, or OSI address of the server.
服务器IP地址：这是服务器的IPv4、IPv6或OSI地址。
If the firmware or documentation includes specific server names, the names should be those the manufacturer or seller operates as a customer convenience or those for which specific permission has been obtained from the operator. A DNS request for a generic server name, such as ntp.mytimeserver.com, should result in a random selection of server IP addresses available for that purpose. Each time a DNS request is received, a new randomized list is returned. The client ordinarily uses the first address on the list.
如果固件或文档包含特定的服务器名称，则名称应为制造商或卖方为方便客户而操作的名称，或已获得运营商特定许可的名称。对通用服务器名称（如ntp.mytimeserver.com）的DNS请求应导致随机选择可用于该目的的服务器IP地址。每次收到DNS请求时，都会返回一个新的随机列表。客户机通常使用列表上的第一个地址。
When candidate SNTP or NTP servers are selected, it is imperative to respect the server operator's conditions of access. Lists of public servers and their conditions of access are available at www.ntp.org. A semi-automatic server discovery scheme using DNS is described at that site. Some ISPs operate public servers, although finding them via their help desks can be difficult.
选择候选SNTP或NTP服务器时，必须遵守服务器运营商的访问条件。公共服务器列表及其访问条件可在www.ntp.org上查阅。该站点描述了使用DNS的半自动服务器发现方案。一些ISP运营公共服务器，尽管通过他们的服务台找到它们可能很困难。
A well-behaved client operates as follows (note that steps 2-4 constitute a synchronization loop):
行为良好的客户端的操作如下（请注意，步骤2-4构成了一个同步循环）：
1. Consider the specified frequency tolerance of the system clock oscillator. Define the required accuracy of the system clock, then calculate the maximum timeout. For instance, if the frequency tolerance is 200 parts per million (PPM) and the required accuracy is one minute, the maximum timeout is about 3.5 days. Use the longest maximum timeout possible given the system constraints to minimize time server aggregate load, but never make it less than 15 minutes.
1. 考虑系统时钟振荡器的特定频率容差。定义所需的系统时钟精度，然后计算最大超时。例如，如果频率公差为百万分之二百（PPM），且所需精度为一分钟，则最大超时时间约为3.5天。在给定系统约束的情况下，尽可能使用最长的最大超时时间来最小化服务器聚合负载，但决不能使其少于15分钟。
2. When the client is first coming up or after reset, randomize the timeout from one to five minutes. This is to minimize shock when 3000 PCs are rebooted at the same time power is restored after a blackout. Assume at this time that the IP address is unknown and that the system clock is unsynchronized. Otherwise, use the timeout value as calculated in previous loop steps. Note that it may be necessary to refrain from implementing the aforementioned random delay for some classes of International Computer Security Association (ICSA) certification.
2. 当客户端首次启动或重置后，将超时时间从1分钟随机分配到5分钟。这是为了在断电后恢复电源的同时重新启动3000台电脑时，将冲击降至最低。假设此时IP地址未知，且系统时钟不同步。否则，请使用在前面的循环步骤中计算的超时值。请注意，对于某些类别的国际计算机安全协会（ICSA）认证，可能有必要避免实施上述随机延迟。
3. When the timer reaches zero, if the IP address is not known, send a DNS query packet; otherwise, send an NTP request packet to that address. If no reply packet has been heard since the last timeout, double the timeout, but do not make it greater than the maximum timeout. If primary and secondary time servers have been configured, alternate queries between the primary and secondary servers when no successful response has been received.
3. 当定时器为零时，如果IP地址未知，发送DNS查询包；否则，将NTP请求数据包发送到该地址。如果自上次超时后未听到回复数据包，请将超时加倍，但不要使其大于最大超时。如果已配置主时间服务器和辅助时间服务器，则在未收到成功响应时，在主服务器和辅助服务器之间进行交替查询。
4. If a DNS reply packet is received, save the IP address and continue at step 2. If a KoD packet is received, remove that time server from the list, activate the secondary time server, and continue at step 2. If a received packet fails the sanity checks, drop that packet and also continue at step 2. If a valid NTP packet is received, update the system clock, set the timeout to the maximum, and continue at step 2.
4. 如果接收到DNS应答数据包，则保存IP地址并继续执行步骤2。如果收到KoD数据包，请从列表中删除该时间服务器，激活辅助时间服务器，然后继续执行步骤2。如果接收到的数据包未通过健全性检查，则丢弃该数据包并继续执行步骤2。如果收到有效的NTP数据包，请更新系统时钟，将超时设置为最大值，然后继续执行步骤2。
Without cryptographic authentication, SNTPv4 service is vulnerable to disruption by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. It is strongly recommended that access controls and/or cryptographic authentication means be provided for additional security. This document includes protocol provisions for adding such security mechanisms, but it does not define the mechanisms themselves. A separate document [MIL03] in preparation will define a cryptographic security mechanism for SNTP.
如果没有加密身份验证，SNTPv4服务很容易受到互联网其他地方行为不端或敌对的SNTP或NTP广播服务器的破坏。强烈建议提供访问控制和/或加密身份验证手段，以提高安全性。本文件包括添加此类安全机制的协议条款，但未定义这些机制本身。准备中的单独文件[MIL03]将定义SNTP的加密安全机制。
Jeff Learman was helpful in developing the OSI model for this protocol. Ajit Thyagarajan provided valuable suggestions and corrections.
Jeff Learman有助于为该协议开发OSI模型。Ajit Thyagarajan提供了宝贵的建议和更正。
D. Plonka
普隆卡
J. Montgomery
蒙哥马利
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BRA97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[COL94] Colella, R., Callon, R., Gardner, E., and Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May 1994.
[COL94]Colella，R.，Callon，R.，Gardner，E.，和Y.Rekhter，“互联网上OSI NSAP分配指南”，RFC 1629，1994年5月。
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[DEE89]Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[DEE98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DEE98]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[DOB91] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless transport services on top of UDP: Version 1", RFC 1240, June 1991.
[DOB91]Shue，C.，Haggerty，W.，和K.Dobbins，“UDP之上的OSI无连接传输服务：版本1”，RFC 1240，1991年6月。
[FUR94] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications", RFC 1698, October 1994.
[Furnis，P.，“支持基本通信应用的上层OSI八位组序列”，RFC 16981994年10月。
[ISO86] International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification. International Standards Organization, December 1986.
[ISO86]国际标准8602-信息处理系统-OSI：无连接传输协议规范。国际标准组织，1986年12月。
[MIL92] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[MIL92]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年3月。
[MIL03] Mills, D., "The Autokey Security Architecture, Protocol and Algorithms", http://eecis.udel.edu/~mills/database/reports/ stime/stime.pdf, August 2003.
[MIL03]Mills，D.，“自动密钥安全体系结构、协议和算法”，http://eecis.udel.edu/~mills/database/reports/stime/stime.pdf，2003年8月。
[PAR93] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[PAR93]帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC15461993年11月。
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[POS80]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[POS83] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983.
[POS83]Postel，J.和K.Harrenstien，“时间协议”，STD 26，RFC 868，1983年5月。
[SRI99] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[SRI99]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[SRI01] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[SRI01]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 30222001年1月。
Author's Address
作者地址
David L. Mills Electrical and Computer Engineering Department University of Delaware Newark, DE 19716
David L. Mills电气与计算机工程系德拉瓦大学NeWK，DE 19716
Phone: (302) 831-8247 EMail: mills@udel.edu
电话：（302）831-8247电子邮件：mills@udel.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。