rfc1769.txt

最近的中文RFC文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：陈华鹏(shenmusic  [e-mail])
译文发布时间：2001-7-14
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保
留本文档的翻译及版权信息。
               


Network Working Group                                                        D. Mills
Request for Comments: 1769                                     University of Delaware
Obsoletes: 1361                                                            March 1995
Category: Informational

                 简单网络时间协议( SNTP) 

                      （RFC1769 ——Simple Network Time Protocol）


本备忘录的状况：

    本备忘录为Internet community提供了信息，但不规定任何一种类型的 Internet 标准。 本备
忘录的分发没有限制。 

概要
    本备忘录描述简单网络时间协议(SNTP)，这是网络时间协议(NTP) 的一个改写本，NTP协议
适用于同步因特网上的计算机时钟。当不须要实现RFC 1305 所描述的NTP完全功能的情况下，
可以使用SNTP。它能用单播方式(点对点)和广播方式(点对多点)操作。它也能在IP 多播方式下
操作（可提供这种服务的地方）。SNTP与当前及以前的NTP版本并没有大的不同。但它是更简单，
是一个无状态的远程过程调用(RPC)，其准确和可靠性相似于UDP/TIME 协议在RFC868描述中所
预期的。
本备忘录淘汰相同的标题的RFC 1361。它的目的是解释用广播方式操作的协议模式，提供
某些地方的进一步说明并且改正一些印刷上的错误。在NTP版本3 RFC 1305中说明的工作机理对
SNTP的实现不是完全需要的。本备忘录的分发没有限制。 

目录

1.	介绍	2
2.	工作模式与地址分配	2
3.	NTP时间戳格式	3
4.	NTP 报文格式	4
5.	SNTP 客户端操作	6
6.	SNTP 服务器操作	7
7.	参考资料	8
8.	安全考虑	9
9.	作者的地址	9

1.	介绍 
    RFC 1305 [MIL92] 指定网络时间协议(NTP)来同步因特网上的计算机时钟。它提供了全面
访问国家时间和频率传播服务的机制，组织时间同步子网并且为参加子网每一个地方时钟调整
时间。 在今天的因特网的大多数地方， NTP 提供了1-50 ms 的精确度，精确度的大小取决于
同步源和网络路径等特性。 
    RFC 1305 指定了NTP协议机制中的事件，状态，传输功能和操作，另外，还有可选择的算
法，它改进测时质量并且减少了一些同步源中可能存在的错误。为了获得因特网上主要路径的
延时精确到毫秒级，使用一些复杂的算法或者他们的等价算法是必要的。但是，在许多场合这
样的精确度是不要求，或许精确到秒已足够了。在这样的情况下，更简单的协议例如“时间协
议”[POS83 ]已被使用。这些协议通过基于RPC交换：客户端请求此刻时间，然后服务器回传从
某个已知时间点到现在的秒钟数。 
    NTP被设计成了性能差异很大的客户端及服务器均能适用，且适用于客户端及服务器所在网
路有大范围的网络延迟和抖动的情况。今天的因特网上的NTP同步子网的大多数用户使用一个软
件包包括了一整套的NTP 的选择和算法，是一个比较复杂，实时的应用系统。软件要适用于多
种硬件平台：从巨型计算机到个人计算机。要在这样的范围都适用，它的庞大尺寸和复杂性就
不适合于很多应用了。按照要求，探求一些可供选择的访问策略( 使用适合于精确度要求不是
很严格的简单软件)是有用的。 
本备忘录描述简单网络时间协议(SNTP)，它是一个简化了的NTP服务器和NTP客户端策
略。SNTP在协议实现上没有什么更改，在最近也不会有什么变动。 访问范例与UDP/TIME 协议
是一致的，实际上，SNTP应该更容易适用于使用个人计算机的 UDP/TIME 客户。而且，SNTP 也
被设计在一个专门的服务器( 包括一台集成的无线电时钟)里操作。由于在系统里的那些各种各
样反应机制的设计和控制，交付调节时间精确到微秒是可能的。这样的专门设计是切实可行的。 
    强烈建议SNTP 仅仅在同步子网的末端被使用。 SNTP 客户端应该仅在子网的叶子( 最高的
阶层) 操作并在配置过程中没有依靠其它NTP或者SNTP客户端来同步。SNTP 服务器应该仅在子
网的根( 阶层1) 操作并在配置过程中，除一台可靠的无线电时钟外中没有其它同步源。只有使
用了有冗余的同步源及不同的子网路径及整套NTP实现中的crafted 算法，主服务器通常期望的
可靠性才有可能达到。这种做法使主同步源在无线电时钟通信失败或者交付了错误时间时，还
能用到其它几个无线电时钟和通向其它主要服务器的备份路径。因此，应该仔细考虑客户端中
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 多播地址来说，将只能用在
为达到以上相同目而设计的特例中。尤其，只有服务器实现了RFC 1305 描述的NTP认证时（包
括支持MD5消息位的算法），在SNTP 服务器里的IP 多播地址才被使用。  
3.	NTP时间戳格式
    sntp使用在RFC 1305 及其以前的版本所描述标准NTP时间戳的格式。与因特网标准标准一
致， NTP 数据被指定为整数或定点小数，位以big-endian风格从左边0位或者高位计数。除非
不这样指定，全部数量都将设成unsigned的类型，并且可能用一个在bit0前的隐含0填充全部字
段宽度。
    因为SNTP时间戳是重要的数据和用来描述协议主要产品的，一个专门的时间戳格式已经建
立。 NTP用时间戳表示为一64 bits unsigned 定点数，以秒的形式从1900 年1月1 日的0：0：
0算起。整数部分在前32位里，后32bits（seconds Fraction）用以表示秒以下的部分。在Seconds 
Fraction 部分，无意义的低位应该设置为0。这种格式把方便的多精度算法和变换用于UDP/TIME 
的表示（单位：秒），但使得转化为ICMP的时间戳消息表示法(单位：毫秒)的过程变得复杂了。
它代表的精度是大约是200 picoseconds，这应该足以满足最高的要求了。 
       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)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

注意，从1968 年起，最高有效位(整数部分的0 bit位) 已经被确定，64 位比特字段在2036 年
将溢出。 如果NTP或者SNTP在2036 年还在使用的话，一些外部方法将有必要用来调整与1900
年及2036 年有关的时间 (136 年的其它倍数也一样)。 用这样的限制使时间戳数据变得很讲究
(要求合适的方法可容易地被找到)。从今以后每136 年，就会有200picosecond 的间隔，会被
忽略掉，64 个比特字段将全部置为0 ，按照惯列它将被解释为一个无效的或者不可获得的时间
戳。  

4.	NTP 报文格式 
    NTP 和SNTP 是用户数据报协议( UDP) 的客户端 [POS80 ]，而UDP自己是网际协议( IP) 
[DAR81 ] 的客户端. IP 和UDP 报头的结构在被引用的指定资料里描述，这里就不更进一步描
述了。UDP的端口是123，UDP头中的源断口和目的断口都是一样的，保留的UDP头如规范中所述。
    以下是SNTP 报文格式的描述，它紧跟在IP 和UDP 报头之后。SNTP的消息格式与RFC-1305
中所描述的NTP格式是一致的，不同的地方是：
一些SNTP的数据域已被风装，也就是说已初始化为一些预定的值。NTP 消息的格式被显示如下。 
                    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   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            根延迟                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            根差量                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          参考标识符                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                          参考时间戳(64)                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                           原始时间戳(64)                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                           接受时间戳 (64)                     |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                          传送时间戳(64)                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                         认证符(可选项) (96)                   |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
如下一部分描述，在SNTP 里大多数这些字段被预规定的数据给赋初值。为完整起见，每个字段
的功能在下面被简要总结。 

1.	闰秒标识器：这是一个二位码，预报当天最近的分钟里要被插入或删除的闰秒秒数。用1/0
表示，分别说明如下：
LI             Value                    含		义
----------------------------------------------------------------------------------
----00              0                        无预告
01              1                     最近一分钟有61秒
10              2                     最近一分钟有59秒
11              3                     警告状态（时钟未同步）

2.	版本号：这是一个三bits的整数，表示NTP的版本号，现在为3。
3.	模式：这是一个三bits的整数，表示模式，定义如下：
mode                      	  含		义
0	保留
1	对称性激活
2	被动的对称性
3	客户端几
4	服务器
5	广播
6	为NTP控制性系保留