RFC1769_简单网络时间协议(SNTP)

RFC1769——SimpleNetworkTimeProtocol简单网络时间协议(SNTP)RFC文档中文翻译计划1简单网络时间协议(SNTP)（RFC1769——SimpleNetworkTimeProtocol）本备忘录描述简单网络时间协议(SNTP)，这是网络时间协议(NTP)的一个改写本，NTP协议适用于同步因特网上的计算机时钟。当不须要实现RFC1305所描述的NTP完全功能的情况下，可以使用SNTP。它能用单播方式(点对点)和广播方式(点对多点)操作。它也能在IP多播方式下操作（可提供这种服务的地方）。SNTP与当前及以前的NTP版本并没有大的不同。但它是更简单，是一个无状态的远程过程调用(RPC)，其准确和可靠性相似于UDP/TIME协议在RFC868描述中所预期的。本备忘录淘汰相同的标题的RFC1361。它的目的是解释用广播方式操作的协议模式，提供某些地方的进一步说明并且改正一些印刷上的错误。在NTP版本3RFC1305中说明的工作机理对SNTP的实现不是完全需要的。本备忘录的分发没有限制。1.介绍RFC1305[MIL92]指定网络时间协议(NTP)来同步因特网上的计算机时钟。它提供了全面访问国家时间和频率传播服务的机制，组织时间同步子网并且为参加子网每一个地方时钟调整时间。在今天的因特网的大多数地方，NTP提供了1-50ms的精确度，精确度的大小取决于同步源和网络路径等特性。RFC1305指定了NTP协议机制中的事件，状态，传输功能和操作，另外，还有可选择的算法，它改进测时质量并且减少了一些同步源中可能存在的错误。为了获得因特网上主要路径的延时精确到毫秒级，使用一些复杂的算法或者他们的等价算法是必要的。但是，在许多场合这样的精确度是不要求，或许精确到秒已足够了。在这样的情况下，更简单的协议例如“时间协议”[POS83]已被使用。这些协议通过基于RPC交换：客户端请求此刻时间，然后服务器回传从某个已知时间点到现在的秒钟数。NTP被设计成了性能差异很大的客户端及服务器均能适用，且适用于客户端及服务器所在网路有大范围的网络延迟和抖动的情况。今天的因特网上的NTP同步子网的大多数用户使用一个软件包包括了一整套的NTP的选择和算法，是一个比较复杂，实时的应用系统。软件要适用于多种硬件平台：从巨型计算机到个人计算机。要在这样的范围都适用，它的庞大尺寸和复杂性就不适合于很多应用了。按照要求，探求一些可供选择的访问策略(使用适合于精确度要求不是很严格的简单软件)是有用的。本备忘录描述简单网络时间协议(SNTP)，它是一个简化了的NTP服务器和NTP客户端策略。SNTP在协议实现上没有什么更改，在最近也不会有什么变动。访问范例与UDP/TIME协议是一致的，实际上，SNTP应该更容易适用于使用个人计算机的UDP/TIME客户。而且，SNTP也被设计在一个专门的服务器(包括一台集成的无线电时钟)里操作。由于在系统里的那些各种各样反应机制的设计和控制，交付调节时间精确到微秒是可能的。这样的专门设计是切实可行的。强烈建议SNTP仅仅在同步子网的末端被使用。SNTP客户端应该仅在子网的叶子(最高的阶层)操作并在配置过程中没有依靠其它NTP或者SNTP客户端来同步。SNTP服务器应该仅在子网的根(阶层1)操作并在配置过程中，除一台可靠的无线电时钟外中没有其它同步源。只有使用了有冗余的同步源及不同的子网路径及整套NTP实现中的crafted算法，主服务器通常期望的RFC1769——SimpleNetworkTimeProtocol简单网络时间协议(SNTP)RFC文档中文翻译计划2可靠性才有可能达到。这种做法使主同步源在无线电时钟通信失败或者交付了错误时间时，还能用到其它几个无线电时钟和通向其它主要服务器的备份路径。因此，应该仔细考虑客户端中SNTP的使用，而不是在主服务器里的NTP的使用。2.工作模式与地址分配象NTP一样，SNTP能在单播(点向点)或者广播(点对多点)模式中操作。单播客户端发送请求到服务器并且期望从那里得到答复，并且（可选的），得到有关服务器的往返传播延迟和本地时钟补偿。广播服务器周期性地送消息给一指定的IP广播地址或者IP多播地址，并且通常不期望从客户端得到请求，广播客户端监听地址但通常并不给服务器发请求。一些广播服务器可能选择对客户端作出反应请求以及发出未经请求广播消息；同时一些广播客户端可能会送请求仅为了确定在服务器和客户端之间的网络传播延迟。在单播方式下，客户端和服务器的IP地址按常规被分配。在广播方式下，服务器使用一指定的IP播送地址或者IP多播地址，以及指明的媒介访问播送地址，客户端要在这些地址上帧听。为此，IP广播地址将限制在一个单独的IP子网范围，因为路由器不传播IP广播数据报。就以太网而论，例如，以太网媒介访问广播地址(主机部分全部为1)被用于表示IP广播地址。另一方面，IP多播地址将广播的潜在有效范围扩展到整个因特网。其真实范围，组会员和路由由因特网组管理协议(IGMP)确定[DEE89]，对于各种路由协议，超出了这份资料的讨论范围。就以太网而论，例如，以太网媒介访问播送地址(全部为1)要和分配的224.0.1.1的IP多播地址合用。除了IP地址规范和IGMP，在服务器操作IP广播地址或者IP多播地址没有什么不同。广播客户端帧听广播地址，例如在以太网情况下主机地址全部为1的。就广播地址的IP而论，没有更进一步规定的必要了。在IP多组广播情况下，主机可能需要实现IGMP，为的是让本地路由器把消息拦截后送到224.0.1.1多播组。这些考虑不属于这份资料的讨论范围。就当前指定的SNTP而论，其真正的弱点是多目广播客户端可能被一些行为不当或者敌对的在因特网别处的SNTP/NTP多播服务器攻击而瘫痪，因为目前全部这样服务器使用相同的IP多播地址：224.0.1.1组地址。所以有必要，存取控制要基于那些以客户端信任的服务器源地址，即客户端选择仅仅为自己所知的服务器。或者，按照惯列和非正式协议，全部NTP多播服务器现在在每条消息内应包括已用MD5加密的加密位，以便客户端确定消息没有在传输中被修改。SNTP客户端能实现那些必要加密和密钥分发计划在原则上是可能的，但是这在SNTP被设计成的那些简单的系统里不可能被考虑。考虑到没有一个完整的SNTP规范，故IP广播地址将使用在IP子网和局域网部分(指有完整功能的NTP服务器和SNTP客户端在同一子网上的局域网)，而对于IP多播地址来说，将只能用在为达到以上相同目而设计的特例中。尤其，只有服务器实现了RFC1305描述的NTP认证时（包括支持MD5消息位的算法），在SNTP服务器里的IP多播地址才被使用。3.NTP时间戳格式sntp使用在RFC1305及其以前的版本所描述标准NTP时间戳的格式。与因特网标准标准一致，NTP数据被指定为整数或定点小数，位以big-endian风格从左边0位或者高位计数。除非不这样指定，全部数量都将设成unsigned的类型，并且可能用一个在bit0前的隐含0填充全部字段宽度。因为SNTP时间戳是重要的数据和用来描述协议主要产品的，一个专门的时间戳格式已经建立。NTP用时间戳表示为一64bitsunsigned定点数，以秒的形式从1900年1月1日的0：0：0算起。整数部分在前32位里，后32bits（secondsFraction）用以表示秒以下的部分。在SecondsFraction部分，无意义的低位应该设置为0。这种格式把方便的多精度算法和变换用于UDP/TIME的表示（单位：秒），但使得转化为ICMP的时间戳消息表示法(单位：毫秒)的过程变得复杂了。它代表的精度是大约是200picoseconds，这应该足以满足最高的要求了。RFC1769——SimpleNetworkTimeProtocol简单网络时间协议(SNTP)RFC文档中文翻译计划301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Seconds|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|SecondsFraction(0-padded)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+注意，从1968年起，最高有效位(整数部分的0bit位)已经被确定，64位比特字段在2036年将溢出。如果NTP或者SNTP在2036年还在使用的话，一些外部方法将有必要用来调整与1900年及2036年有关的时间(136年的其它倍数也一样)。用这样的限制使时间戳数据变得很讲究(要求合适的方法可容易地被找到)。从今以后每136年，就会有200picosecond的间隔，会被忽略掉，64个比特字段将全部置为0，按照惯列它将被解释为一个无效的或者不可获得的时间戳。RFC1769——SimpleNetworkTimeProtocol简单网络时间协议(SNTP)RFC文档中文翻译计划44.NTP报文格式NTP和SNTP是用户数据报协议(UDP)的客户端[POS80]，而UDP自己是网际协议(IP)[DAR81]的客户端.IP和UDP报头的结构在被引用的指定资料里描述，这里就不更进一步描述了。UDP的端口是123，UDP头中的源断口和目的断口都是一样的，保留的UDP头如规范中所述。以下是SNTP报文格式的描述，它紧跟在IP和UDP报头之后。SNTP的消息格式与RFC-1305中所描述的NTP格式是一致的，不同的地方是：一些SNTP的数据域已被风装，也就是说已初始化为一些预定的值。NTP消息的格式被显示如下。12301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|LI|VN|Mode|Stratum|Poll|Precision|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|根延迟|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|根差量|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|参考标识符|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||参考时间戳(64)|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||原始时间戳(64)|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||接受时间戳(64)|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||传送时间戳(64)|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||||认证符(可选项)(96)|||||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+如下一部分描述，在SNTP里大多数这些字段被预规定的数据给赋初值。为完整起见，每个字段的功能在下面被简要总结。RFC1769——SimpleNetworkT