作者在 2008-12-16 19:48:43 发布以下内容

SNTP协议的分析

林晓帆，李超，陈高云

(成都信息工程学院软件工程系,四川省成都市邮政编码610225）

联系作者e-mail:xiaoflin68@163.com

摘要:

SNTP是简单网络时间协议（Simple Network Time protocol）的简称，它是目前Internet网上实现时间同步的一种重要工程化方法。本文对SNTP协议的工作原理、工作模式、时间戳格式、信息帧格式进行了研究，最后对SNTP协议的应用提出一些有益的建议。

关键词:SNTP;时间同步;时间戳格式;报文格式

中图法分类号:TP393.04　　　文献标识码: A

Title Analysis for SNTP protocol

LIN Xiaofan , LI Chao , CHEN Gaoyun

（Department of software engineering, Chengdu university of information technology, chengdu 610225）

Abstract:

SNTP is abbreviation for simple network time protocol. At present it is an important engineering method for time synchronization in Internet. This paper describe principle,mode,timestamp format,message format of SNTP, finally we give some advice for application.

Key words: SNTP; time synchronization ; ,timestamp format ; message format

0引言

在一些需要精确时间同步的场合，如电力通讯、通信计费、分布式网络计算、气象预报等，仅靠计算机本身提供的时钟信号是远远不够的。据统计，计算机时间与国际标准时间偏差在1分钟以上的占到90%以上，这是因为计算机的时钟信号来源于自带的简单晶体振荡器，而这种晶体振荡器守时性很差，调整好时间后，一般每天都有都有几秒钟的时间漂移。上面提及的应用对时间准确度的要求均是需要秒级的，NTP协议就是提供精确网络时间服务的一种重要方法。NTP协议是网络时间协议的简称（Network Time Protocol），目前它被广泛用于在Internet上进行计算机时钟同步，它通过提供完全的机制来访问国际标准时间，在大多数情况下，NTP根据同步源和网络路径的不同，能够提供1-50MS的时间精确度。

NTP协议为了保证高度的精确性，需要很复杂算法，但是在实际很多应用中，秒级的精确度就足够了，在这种情况下，SNTP协议出现了，它通过简化原来的访问协议，在保证时间精确度的前提下，使得对网络时间的开发和应用变得容易。SNTP主要对NTP协议涉及有关访问安全、服务器自动迁移部分进行了缩减。

SNTP协议目前的版本号是SNTP V4，它能与以前的版本兼容，更重要的是SNTP能够与NTP协议具有互操作性，即SNTP客户可以与NTP服务器协同工作，同样NTP客户也可以接收SNTP服务器发出的授时信息。这是因为NTP和SNTP的数据包格式是一样的，计算客户时间、时间偏差以及包往返时延的算法也是一样的。因此NTP和SNTP实际上是无法分割的。

本文主要对SNTP协议进行分析，主要涉及协议工作原理、工作模式、时间戳格式、报文格式，最后对SNTP协议的应用提出一些建议。

1 SNTP协议工作原理

SNTP协议采用客户/服务器工作方式，服务器通过接收GPS信号或自带的原子钟作为系统的时间基准，客户机通过定期访问服务器提供的时间服务获得准确的时间信息，并调整自己的系统时钟，达到网络时间同步的目的。客户和服务器通讯采用UDP协议，端口为123。授时原理可以用下面的图作一个描述：

图1：授时原理图

T1:客户方发送查询请求时间(以客户方时间系统为参照)，标记为Originate Timestamp；

T2:服务器收到查询请求时间(以服务器时间系统为参照)，标记为Receive Timestamp；

T3:服务器回复时间信息包时间(以服务器时间系统为参照)，标记为Transmit Timestamp；

T4:客户方收到时间信息包时间(以客户方时间系统为参照)，标记为Destination Timestamp；

D1：请求信息在网上传播所消耗的时间

D2：回复信息在网上传播所消耗的时间

现已知T1 、T2、T3、T4，希望求得以调整客户方时钟有：

(1)

假设请求和回复在网上传播的时间相同，即D1=D2，则可解得：

(2)

可以看到，、D只与T2T1差值、T3T4差值相关，而与T2T3差值无关，即最终的结果与服务器处理请求所需的时间无关。据此，客户方A即可通过T1、T2、T3、T4计算出时差θ去调整本地时钟。

2 SNTP协议工作模式

SNTP协议可以使用单播、广播或多播模式进行工作。单播模式是指一个客户发送请求到预先指定的一个服务器地址，然后从服务器获得准确的时间、来回时延和与服务器时间的偏差。广播模式是指一个广播服务器周期地向指定广播地址发送时间信息，在这组地址内的服务器侦听广播并且不发送请求。多播模式是对广播模式的一种扩展，它设计的目的是对地址未知的一组服务器进行协调。在这种模式下，多播客户发送一个普通的NTP请求给指定的广播地址，多个多播服务器在此地址上进行侦听。一旦收到一个请求信息，一个多播服务器就对客户返回一个普通的NTP服务器应答，然后客户依此对广播地址内剩下的所有服务器作同样的操作，最后利用NTP迁移算法筛选出最好的三台服务器使用。

客户和服务器地址可以采用通常的IPV4或IPV6。IANA保留IPV4地址224.0.1.1，保留IPV6以：101结束的地址作为NTP广播或多播的地址。用户也可以根据具体情况，建立自己的地址空间，只要不与已经使用的地址空间冲突。

为了局限广播或多播服务占用太多的网络资源，调节多播信息IP头中的TTL值到一个合理的水平非常重要。只有在地址范围内的多播客户能接收到多播信息，只有在地址范围内的服务器组能够对客户的响应进行应答。在Internet上，SNTP广播或多播客户极易受到来自其它SNTP服务器的攻击，因此在Internet上使用该服务时，一定要采用访问控制和加密的措施。

3 SNTP数据格式

SNTP协议同其它的网络应用层协议一样，都具有一定的数据格式，它主要涉及时间的表示，即时间戳的格式，数据如何组帧在网络上传输，即信息帧格式。

3.1 SNTP时间戳格式

SNTP时间戳是该协议的重要产品，用来对时间进行精确表示。它由一个64位无符号浮点数组成，整数部分为头32位，小数部分为后32位；单位为秒，时间相对于1900年1月零点。它能表示的最大数字为4，294，967，295秒，同时具有232PS的精确性，这能满足最苛刻的时间要求。值得注意的是在1968年的某一个时间（2，147，483，648秒）时间戳的最高位已被设置为1，在2036年的某一个时间（4，294，967，295秒）64位字段将会溢出，所有位将会被置为零，此时的时间戳将会被视为无效。为了解决这一问题，尽量延长SNTP时间戳的使用时间，一种可能的办法为：如果最高位设置为1，UTC时间范围为1968-2036之间，时间计算起点从1900年1月0点0分0秒开始计算；如果最高位设置为0，UTC时间范围为2036-2104之间，时间计算起点从2036年2月7日6点28分16秒开始计算；

3.2 SNTP信息帧格式

SNTP协议是UDP协议的客户，它利用UDP的123端口提供服务，SNTP客户在设置请求信息时要把UDP目的端口设置为该值，源端口可以为任何非零值，服务器在响应信息中对这些值进行交换。同其它应用层协议一样，SNTP协议的数据通信也是按数据帧的格式进行，下图是对SNTP信息帧格式的描述：

图2：SNTP信息帧格式

LI：当前时间闰秒标志。字段长度为2位整数，只在服务器端有效。取值定义为：

LI=0：无警告；

LI=1：最后一分钟是61秒；

LI=2：最后一分钟是59秒；

LI=3：警告（时钟没有同步）

服务器在开始时，LI设置为3，一旦与主钟取得同步后就设置成其它值。

VN：版本号。字段长度为3位整数，当前版本号为4。

Mode：指示协议模式。字段长度为3位，取值定义为：

Mode=0：保留

Mode=1：对称主动；

Mode=2：对称被动；

Mode=3：客户；

Mode=4：服务器；

Mode=5：广播；

Mode=6：保留为NTP控制信息；

Mode=7：保留为用户定义；

在单播和多播模式，客户在请求时把这个字段设置为3，服务器在响应时把这个字段设置为4。在广播模式下，服务器把这个字段设置为5。

Stratum：指示服务器工作的级别，该字段只在服务器端有效，字段长度为8位整数。取值定义为：

Stratum=0：故障信息；

Stratum=1：一级服务器；

Stratum=2-15：二级服务器；

Stratum=16-255：保留；

Poll Interval：指示数据包的最大时间间隔，以秒为单位，作为2的指数方的指数部分，该字段只在服务器端有效。字段长度为8位整数，取值范围从4-17，即16秒到131,072秒。

Precision：指示系统时钟的精确性，以秒为单位，作为2的指数方的指数部分，该字段只在服务器端有效。字段长度为8位符号整数，取值范围从-6到-20。

Root Delay：指示与主时钟参考源的总共往返延迟，以秒为单位，该字段只在服务器端有效。字段长度为32位浮点数，小数部分在16位以后，取值范围从负几毫秒到正几百毫秒。

Root Dispersion：指示与主时钟参考源的误差，以秒为单位，该字段只在服务器端有效。字段长度为32位浮点数，小数部分在16位以后，取值范围从零毫秒到正几百毫秒。

Reference Identifier：指示时钟参考源的标记，该字段只在服务器端有效。对于一级服务器，字段长度为4字节ASCII字符串，左对齐不足添零。对于二级服务器，在IPV4环境下，取值为一级服务器的IP地址，在IPV6环境下，是一级服务器的NSAP地址。

Reference Timestamp：指示系统时钟最后一次校准的时间，该字段只在服务器端有效，以前面所述64位时间戳格式表示。

Originate Timestamp：指示客户向服务器发起请求的时间，以前面所述64位时间戳格式表示。

Transmit Timestamp：指示服务器向客户发时间戳的时间，以前面所述64位时间戳格式表示。

Authenticator（可选）：当需要进行SNTP认证时，该字段包含密钥和信息加密码。

4 SNTP服务器的基本工作过程

下面以最常用的SNTP工作模式-单播模式，来说明SNTP服务器的工作过程：

协议 | 阅读 12723 次

文章评论，共3条

vfdff(作者)

2008-12-16 19:56

简单网络协议 SNTP 
 
组织：中国互动出版网（http://www.china-pub.com/） 
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） 
E-mail：ouyang@china-pub.com 
译者：陈华鹏(shenmusic hpchen@eastcom.com) 
译文发布时间：2001-7-14 
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。 
 
Network Working Group 
Request for Comments: 1769 
Obsoletes: 1361 
Category: Informational 
 
D. Mills 
University of Delaware 
March 1995 
 
本备忘录的状态 
 
本备忘录为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. 介绍 
 
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，这应该足以满足最高的要求了。 
 
 
 
注意，从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 消息的格式被显示如下。 
 
 
 
如下一部分描述，在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控制性系保留 
7 为自用保留 
 
在点对点模式下，客户端机在请求中设置此字段为3，服务器在回答时设置此字段为4；在广播模式下，服务器在回答时设置此字段为5。 
 
4. stratum（层）：这是一个8bits的整数（无符号），表示本地时钟的层次水平，数值定义如下： 
 
stratum 含义 
0 未指定或难以获得 
1 主要参考（如无线电时钟钟） 
2-15 第二参考（通过NTP/SNTP） 
16-255 保留 
 
5．测试间隔：八位signed integer，表示连续信息之间的最大间隔，精确到秒的平方及。本字段的值从4（16s）到14（16284s）；然而，大多数应用使用6（64s）到10（1024s）。 
 
6．精度：八位signed integer，表示本地时钟精度，精确到秒的平方级。值从-6（主平）到-20（微妙级时钟）。 
 
7. 根时延：32位带符号定点小数，表示在主参考源之间往返的总共时延，以小数位后15~16bits。数值根据相关的时间与频率可正可负，从负的几毫秒到正的几百毫秒。 
 
8. 根离散：32位带符号定点小数，表示在主参考源有关的名义错误，以小数位后15~16bits。范围：0~几百毫秒。 
 
9. 参考时钟标识符：32bits，用来标识特殊的参考源。在stratum 0（未指定）或stratum 1（基本参考）的情况下，该字段以四个八位字节，左对齐，零填充的string表示。当没有NTP枚举时，使用下列ASCII标识符： 
 
阶层代码意思 
1 pps 精度校准源，例如ATOM(原子钟)，PPS代表(每秒脉冲精度源)，等等 
1 service 除了一般的NTP报时服务外，例如ACTS (计算机自动化报时服务)，TIME（UDP/Time协议)，TSP(Unix 报时服务协议)，DTSS. (数字化时间同步服务)，等等 
1 radio 一般的收音机服务，带有callsigns，例如CHU， DCF77， MSF， TDF， WWV， WWVB， WWVH，等等 
1 nav 无线电导航系统，例如OMEG(欧米加导航系统)， LORC(远距离无线电导航系统)，等等   
1 satellite 一般的卫星业务，例如GOES(地球同步轨道环境卫星)，GPS(全球卫星定位服务)，等等   
2 address 二级参考(4个八位二进制字节表示的NTP服务器因特网地址） 
 
10. 参考时间戳：64bits时间戳，本地时钟被修改的最新时间。 
 
11. 原始时间戳：客户端发送的时间，64bits。 
 
12. 接受时间戳：服务端接受到的时间，64bits。 
 
13. 传送时间戳：服务端送出应答的时间，64bits。 
 
14. 认证符（可选项）：当NTP的认证机制已运行后，这个字段包含认证者的信息（参见RFC1305 中的附件C）。在SNTP中本字段一般被来报输入消息所忽略，也不用在输出消息中。 
 
5. SNTP 客户端操作 
 
SNTP客户端与NTP/SNTP 服务器通信的模式是一个非持久状态的远程过程调用。在单播方式，客户端发给服务器(方式3) 请求并且期望服务器答复 (方式4)。在广播方式，客户端送并不请求只是等待一台或更多的服务器的广播消息(方式5) ，这取决于设置。根据客户端和服务器设置，单播客户端和广播服务器通常在从64 给1024 s 的间隔里发送消息。 
 
单播客户端初始化SNTP 报文首部，再把消息发送到服务器，然后从服务器回复的报文中剥去时间包。为此，上面提到的所有报文首部字段，除第一个八位字节外都设置成0。在这个八位字节里Li 字段设置为0( 没有警告) 和方式字段设置为3(客户端)。VN 字段必须同NTP 或者SNTP 服务器的软件版本一致；但是，NTP 版本3( RFC 1305)的服务器也将接受第2( RFC 1119) 版本的消息以及版本1( RFC 1059)的消息，而NTP 版本2服务器也将接受NTP 为版本1的消息。版本0 ( RFC 959) 消息不再被支持。因为今天因特网已有了NTP 服务器操作的3个版本，推荐VN 字段设置1。 
 
在单播及广播方式下，单播服务器回答及广播以上所述的所有字段；但是，在SNTP下，各字段中，只有传送时间戳在非零情况下才有明确的意思.这个字段的整数部分包含服务器此刻的时间，其格式与UDP/TIME 协议相同[POS83].这个字段的fraction部分通常是有效的, SNTP的精确度证明可以精确到秒。如果传送用时间戳字段是全0，则该消息将被忽略。 
 
在广播方式下，客户端没有附加信息用以计算在服务器和客户端之间的传播延迟，因为在此方式下，传送用时间戳和接收时间戳字段是没有意义的。即使在单播方式，大多数客户端也会选择忽略原始时间戳和接收时间戳字段。但是，在单播方式下，一种简单的计算可以用来计算与服务器有关的往返传播延迟d及本地时钟补偿t，通常对在数十毫秒内。为此，客户端在请求包中将本地时钟时间按NTP的格式写入源时间戳。当收到答复时，客户端将目的时间戳作为到达时间，并根据它的本地时钟，将其转变成NTP格式。下述表格总结4个时间戳。 
 
用时间戳名字 ID  产生 
原始时间戳 T1 时间请求由客户端送 
收到时间戳 T2 时间请求在服务器收到 
传送时间戳 T3 时间答复通过服务器送 
目的地时间戳 T4 时间答复在客户端收到 
 
往返传播延迟d和本地时钟补偿t定义为： 
 
D =( T4 - T1) - ( T2 - T3) 
 
T =(( T2 - T1) +( T3 - T4)) /2。 
 
下述表格是SNTP客户端操作的总结。在表格里显示有两种推荐的错误检查方式。在全部NTP 版本里，如果Li 字段为3；或者阶层字段不在第1-15范围里；或者传送用时间戳是0，服务器决不同步或者不予同步成过去24小时内有效的时间源。在客户端的判断中，保留字段值也可能被检查。是否相信传送用时间戳取决于对这些字段中的一个或多个字段的有效性判断。 
 
字段名请求回答 
Li 0 闰秒指示器；如果是3(非同步)，则放弃该消息 
VN 1( 参见正文) 忽略 
方式 3( 客户端) 忽略 
阶层 0 忽略 
轮询 0 忽略 
精度 0 忽略 
根延迟 0 忽略 
根差量 0 忽略 
参考标识符 0 忽略 
参考时间戳 0 忽略 
原始用时间戳 0 忽略( 参见正文) 
收到用时间戳 0 忽略( 参见正文) 
传送天的时间戳 0 时间；如果是0(非同步)，则忽略该消息 
Authenticator (不使用) 忽略 
 
6. SNTP 服务器操作 
 
SNTP 服务器与NTP 或者SNTP客户端操作的模式是一种没有持久状态的RPC 模式。全套的NTP 算法用来支持冗余校验和不同的网络路径，SNTP服务器通常不实现全套的NTP 算法，建议一台SNTP 服务器只与一个外部同步的时钟源一道操作，例如一台可靠的无线电时钟。这样的话，服务器总是工作在阶层1。 
 
服务器可以工作在单播方式或广播方式或两者同时都用。当单播方式的服务器得到一条请求消息时，就在NTP或者SNTP 的来报头里修改特定字段，并把消息返回给发送人，也许还使用了与请求相同的信息缓冲区。如果不同步到一台正确操作的无线电时钟的话，服务器可能也可能不回答请求，但是回答是首选的，因为可达性可以忽略同步状态如何。在单播方式下，VN 和poll字段被完整地复制到应答包中的相同字段。如果请求的方式字段是3(客户端)，那么在答复过程中它设置成4(服务器)；否则，为了与NTP规范相符，这个字段设置成2(被动的对称性)。 
 
在广播方式下，服务器只有在已同步的情况下，才发消息给一个正常运行的参考时钟。在此方式下， VN 字段设置成3(针对当前的SNTP 版本)，方式字段设成5(广播)。字段poll设置服务器测试间隔，接近秒的平方。一台服务器既支持广播方式，同时也支持单播方式，这是非常合乎需要的。这对一些潜在的广播客户端来说尤其必要，因为这样做，能使用客户端机/服务器的消息来计算传播延迟，这一方法要优于只定时接收广播消息的方法。 
 
在单播方式和广播方式下保留的字段被同样地设置。假定服务器是被同步成一台无线电时钟或者其它正确的主要参考源，则阶层字段设置为1(主要服务器)，Li 字段设置为0；如果不是，阶层字段设置0，Li 字段设置3。精度字段的设置反映出本地时钟的最大的读数误差。对所有的实际情况来说，在NTP格式里被计算的值是小数点右边的有效数值，值被表示成负数时间戳形式。为了主服务器，根延迟和根差量字段可以设置成0，根差量字段能设置成任意数值(表示时钟的最大的期望误差值)。参考标识符设置指明主要参考源，如在上面在表格里说明的。 
 
这些时间戳字段被设置如下。如果服务器未被同步或是首先启动的话，全部时间戳字段设置成零。如果同步，参考用时间戳设置成最后更新时间（来源于无线电时钟）或者设置成消息被送出的时间（如果更新时间不可以获得）。接收时间戳和传送时间戳字段设置成当时消息发出的时间。在单播方式下，原始时间戳字段直接从请求包的传送时间戳拷贝过来。因为客户端要用它来检查应答，所以复制完整很重要。用广播方式下，这个字段被设置成消息被送出的时间。下面的表格总结这些操作。 
 
字段名请求回答 
Li 忽略 0(正常)，3(非同步) 
VN 1， 2 或者3 3 或者从请求包中拷贝 
方式 3(参见正文) 2，4 或者5(参见正文) 
阶层忽略服务器阶层 
投票忽略拷贝请求包 
精度忽略服务器精度 
根延迟忽略 0 
根差量忽略 0(参见正文) 
参考标识符忽略来源标识符 
参考时间戳忽略 0 或者当前的时间 
创造时间戳忽略 0 或者当前的时间或者从传送时间戳请求复制 
收到时间戳忽略 0 或者当前的时间 
传送时间戳忽略 0 或者当前的时间 
Authenticator 忽略 (不使用) 
 
当例如可能发生在刚启动或在运行期间主要参考源不起作用时，有一些多数客户端允许的无效时间戳的范围。一台运行不正常的服务器的最重要的标志是Li 字段，其中一3 的值表明一种非同步的状态。当这值被出现时，客户端应该丢掉该条服务器消息，而不管其它字段的内容。 
 
7. 参考资料 
 
[DAR81 ]波斯特尔， J.，" 网际协议 - DARPA网际计划协议说明"，标准5，1981 年9月，DARPA， RFC 791。 
[DEE89 ]迪林， S.，" IP 多播的主机扩展。标准5， RFC 1112，斯坦福大学， 1989 年8月。 
[MIL92 ] Mills, D，" 网络时间协议( 第3 版本) 说明，实现和分析。 RFC 1305，特拉华大学， 1992 年3月。 
[POS80 ]波斯特尔， J.，" 用户数据报协议"，标准6， RFC 768， USC/Information 科学研究所， 1980 年8月。 
[POS83 ]波斯特尔， J. 和K. Harrenstien，" 时间协议"，标准26， RFC 868，USC/Information 科学研究所， SRI， 1983 年5月。 
8. 安全考虑 
 
安全问题没在这个备忘录里讨论。 
 
9. 作者的地址 
 
David L. Mills 
电工程处 
特拉华大学 
纽瓦克， DE 19716 
电话呼叫： ( 302) 831-8247 
电子邮件： Mills@udel.edu.

赞回复

vfdff(作者)

2008-12-16 20:39

ICMP，IP,UDP,TCP报头部分都有checksum（检验和）字段。ICMP和IP报头校验和的计算都很简单，使用RFC1071中给出的方法即可完成（如下）。 
 
//计算校验和 
USHORT checksum(USHORT *buffer,int size) 
{ 
unsigned long cksum=0; 
while(size>1) 
{ 
  cksum+=*buffer++; 
  size-=sizeof(USHORT); 
} 
if(size) 
{ 
  cksum+=*(UCHAR *)buffer; 
} 
//将32位数转换成16 
while (cksum>>16) 
  cksum=(cksum>>16)+(cksum & 0xffff); 
return (USHORT) (~cksum); 
} 
    UDP/TCP报头中的校验和的计算比较复杂的，要用到 UDP/TCP伪首部：先要填充伪首部各个字段，然后再将UDP/TCP报头以后（包括报头）的数据附加到伪首部的后面，再对位首部使用上述校验和计算，所得到的值才是UDP/TCP报头部分的校验和。 
 
位首部可以用如下的结构体表示： 
typedef struct{ 
ULONG  sourceip;    //源IP地址 
ULONG  destip;      //目的IP地址 
BYTE mbz;           //置空(0) 
BYTE ptcl;          //协议类型 
USHORT plen;        //TCP/UDP数据包的长度(即从TCP/UDP报头算起到数据包结束的长度单位:字节) 
}Psd_Header; 
 
 
这个过程是一个很繁琐的过程，计算过几次后再也忍受不了做这样重复的工作，于是写了一个通用的计算函数。这个函数使用起来我感觉非常方便：先封装好你的数据包（完整的，包括以太头），然后将数据包的首地址作为参数，调用该函数即可。函数将帮你完成IP报头以及UDP/TCP报头部分校验和的计算。 
 
//------------------------------------------------------------------------- 
// PacketCheckSum 
// 计算数据包的校验和 
// 参数:packet-待处理数据(将封装好的数据包的指针) 
//------------------------------------------------------------------------- 
void PacketCheckSum(unsigned char packet[]) 
{ 
Dlc_Header *pdlc_header=NULL; //以太头指针 
Ip_Header  *pip_header=NULL;  //IP头指针 
unsigned short attachsize=0; //传输层协议头以及附加数据的总长度 
pdlc_header=(Dlc_Header *)packet; 
//判断ethertype,如果不是IP包则不予处理 
if(ntohs(pdlc_header->ethertype)!=0x0800) return; 
pip_header=(Ip_Header  *)(packet+14); 
//TCP包 
if(0x06==pip_header->proto) 
{ 
   
  Tcp_Header *ptcp_header=NULL; //TCP头指针 
  Tcp_Psd_Header *ptcp_psd_header=NULL; 
   
  ptcp_header=(Tcp_Header *)(packet+14+((pip_header->ver_len)&15)*4); 
  attachsize=ntohs(pip_header->total_len)-((pip_header->ver_len)&15)*4; 
  ptcp_psd_header=(Tcp_Psd_Header *)malloc(attachsize+sizeof(Tcp_Psd_Header)); 
  if(!ptcp_psd_header) return; 
  memset(ptcp_psd_header,0,attachsize+sizeof(Tcp_Psd_Header)); 
  //填充伪TCP头 
  ptcp_psd_header->destip=pip_header->destIP; 
  ptcp_psd_header->sourceip=pip_header->sourceIP; 
  ptcp_psd_header->mbz=0; 
  ptcp_psd_header->ptcl=0x06; 
  ptcp_psd_header->tcpl=htons(attachsize); 
  //计算TCP校验和 
  ptcp_header->chksum=0; 
  memcpy((unsigned char *)ptcp_psd_header+sizeof(Tcp_Psd_Header), 
   (unsigned char *)ptcp_header,attachsize); 
  ptcp_header->chksum=checksum((unsigned short *)ptcp_psd_header, 
   attachsize+sizeof(Tcp_Psd_Header)); 
   
  //计算ip头的校验和 
  pip_header->checksum=0; 
  pip_header->checksum=checksum((unsigned short *)pip_header,20); 
  return; 
} 
 
//UDP包 
if(0x11==pip_header->proto) 
{ 
  Udp_Header *pudp_header=NULL; //UDP头指针 
  Udp_Psd_Header *pudp_psd_header=NULL; 
  pudp_header=(Udp_Header *)(packet+14+((pip_header->ver_len)&15)*4); 
  attachsize=ntohs(pip_header->total_len)-((pip_header->ver_len)&15)*4; 
  pudp_psd_header=(Udp_Psd_Header *)malloc(attachsize+sizeof(Udp_Psd_Header)); 
  if(!pudp_psd_header) return; 
        memset(pudp_psd_header,0,attachsize+sizeof(Udp_Psd_Header)); 
  //填充伪UDP头 
  pudp_psd_header->destip=pip_header->destIP; 
  pudp_psd_header->sourceip=pip_header->sourceIP; 
  pudp_psd_header->mbz=0; 
  pudp_psd_header->ptcl=0x11; 
  pudp_psd_header->udpl=htons(attachsize); 
   
  //计算UDP校验和 
  pudp_header->chksum=0; 
  memcpy((unsigned char *)pudp_psd_header+sizeof(Udp_Psd_Header), 
   (unsigned char *)pudp_header,attachsize); 
  pudp_header->chksum=checksum((unsigned short *)pudp_psd_header, 
   attachsize+sizeof(Udp_Psd_Header)); 
    
  //计算ip头的校验和 
  pip_header->checksum=0; 
  pip_header->checksum=checksum((unsigned short *)pip_header,20);   
  return; 
} 
return; 
} 
 
需要几个头文件，以及库： 
 
#include <winsock2.h> 
#include <windows.h> 
#include "packet.h" 
#pragma comment(lib,"ws2_32.lib") 
 
 
 
最后附上我使用的数据包的结构体（比较多）： 
 
 
//数据包结构体 
#pragma pack(1) 
/*物理帧头结构*/ 
typedef struct { 
   BYTE  desmac[6];      //目的MAC地址 
   BYTE  srcmac[6];      //源MAC地址 
   USHORT  ethertype;    //帧类型 
}Dlc_Header; 
/*Arp帧结构*/ 
typedef struct { 
   USHORT hw_type;       //硬件类型Ethernet:0x1 
   USHORT prot_type;     //上层协议类型IP:0x0800 
   BYTE hw_addr_len;     //硬件地址长度:6 
   BYTE prot_addr_len;   //协议地址(IP地址)的长度:4 
   USHORT flag;          //1表示请求,2表示应答 
   BYTE send_hw_addr[6]; //源MAC地址 
   UINT send_prot_addr;  //源IP地址 
   BYTE targ_hw_addr[6]; //目的MAC地址 
   UINT targ_prot_addr;  //目的IP地址 
   BYTE padding[18];     //填充数据   
}Arp_Frame; 
/*ARP包=DLC头+ARP帧*/ 
typedef struct { 
Dlc_Header dlcheader;//DLC头 
Arp_Frame arpframe;  //ARP帧 
}ARP_Packet; 
/*IP报头结构*/ 
typedef struct { 
BYTE  ver_len;       //IP包头部长度,单位：4字节 
BYTE  tos;           //服务类型TOS 
USHORT total_len;    //IP包总长度 
USHORT ident;        //标识 
USHORT frag_and_flags;  //标志位 
BYTE ttl;           //生存时间 
BYTE proto;         //协议 
USHORT checksum;    //IP首部校验和 
UINT  sourceIP;  //源IP地址(32位) 
UINT  destIP;    //目的IP地址(32位) 
}Ip_Header; 
/*TCP报头结构*/ 
typedef struct { 
USHORT srcport;   // 源端口 
USHORT dstport;   // 目的端口 
UINT seqnum;      // 顺序号 
UINT acknum;      // 确认号 
BYTE dataoff;     // TCP头长 
BYTE flags;       // 标志（URG、ACK等） 
USHORT window;    // 窗口大小 
USHORT chksum;    // 校验和 
USHORT urgptr;    // 紧急指针 
}Tcp_Header; 
//TCP伪首部用于进行TCP校验和的计算,保证TCP效验的有效性 
typedef struct{ 
ULONG  sourceip;    //源IP地址 
ULONG  destip;      //目的IP地址 
BYTE mbz;           //置空(0) 
BYTE ptcl;          //协议类型(IPPROTO_TCP) 
USHORT tcpl;        //TCP包的总长度(单位:字节) 
}Tcp_Psd_Header; 
/*UDP报头*/ 
typedef struct  { 
USHORT srcport;     // 源端口 
USHORT dstport;     // 目的端口 
USHORT total_len;   // 包括UDP报头及UDP数据的长度(单位:字节) 
USHORT chksum;      // 校验和 
}Udp_Header; 
/*UDP伪首部-仅用于计算校验和*/ 
typedef struct tsd_hdr 
{ 
ULONG  sourceip;    //源IP地址 
ULONG  destip;      //目的IP地址 
BYTE  mbz;           //置空(0) 
BYTE  ptcl;          //协议类型(IPPROTO_UDP) 
USHORT udpl;         //UDP包总长度(单位:字节) 
}Udp_Psd_Header; 
/*ICMP报头*/ 
typedef struct{ 
BYTE i_type;     //类型类型是关键:0->回送应答(Ping应答) 8->回送请求(Ping请求) 
BYTE i_code;     //代码这个与类型有关当类型为0或8时这里都是0 
USHORT i_cksum;  //ICMP包校验和 
USHORT i_id;     //识别号(一般用进程ID作为标识号) 
USHORT i_seq;    //报文序列号(一般设置为0) 
//UINT timestamp;  //时间戳 
BYTE padding[32];//填充数据 
}Icmp_Header; 
/*ICMP数据包*/ 
typedef struct 
{ 
Dlc_Header dlc_header;  //以太帧 
Ip_Header  ip_header;   //IP头 
Icmp_Header icmp_header;//ICMP帧 
}Icmp_Packet; 
/*攻击信息*/ 
typedef struct 
{ 
unsigned char flag;     //攻击数据包类型1-arp,2-tcp,3-udp 
unsigned int srcip;     //攻击者IP 
unsigned char code[33]; //攻击特征码 
}Attack_Infor; 
#pragma pack()

赞回复

vfdff(作者)

2009-01-12 19:49

简单网络时间协议( 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控制性系保留 
7    为自用保留 
 
在点对点模式下，客户端机在请求中设置此字段为3，服务器在回答时设置此字段为4；在广播 
模式下，服务器在回答时设置此字段为5。 
 
4.    stratum（层）：这是一个8bits的整数（无符号），表示本地时钟的层次水平，数值定义 
如下： 
stratum                    含        义 
0    未指定或难以获得 
1    主要参考（如无线电时钟钟） 
2-15    第二参考（通过NTP/SNTP） 
16-255    保留 
 
5．测试间隔：八位signed integer，表示连续信息之间的最大间隔，精确到秒的平方及。本 
字段的值从4（16s）到14（16284s）；然而，大多数应用使用6（64s）到10（1024s）。 
6．精度：八位signed integer，表示本地时钟精度，精确到秒的平方级。值从-6（主平）到 
-20（微妙级时钟）。 
7.    根时延：32位带符号定点小数，表示在主参考源之间往返的总共时延，以小数位后 
15~16bits。数值根据相关的时间与频率可正可负，从负的几毫秒到正的几百毫秒。 
8.    根离散：32位带符号定点小数，表示在主参考源有关的名义错误，以小数位后15~16bits。 
范围：0~几百毫秒。 
9.    参考时钟标识符：32bits，用来标识特殊的参考源。在stratum 0（未指定）或stratum 1 
（基本参考）的情况下，该字段以四个八位字节，左对齐，零填充的string表示。当没有 
NTP枚举时，使用下列ASCII标识符： 
    阶层     代码                  意思 
---------------------------------------------------------------- 
      1        pps          精度校准源，例如ATOM(原子钟)，PPS代表( 
每秒脉冲精度源)，等等 
      1          service        除了一般的NTP报时服务外，例如ACTS 
                          (计算机自动化报时服务)，TIME（UDP/Time协议)， 
TSP(Unix 报时服务协议)，DTSS. 
                            (数字化时间同步服务)，等等 
      1         radio          一般的收音机服务，带有callsigns，例如CHU， 
                            DCF77， MSF， TDF， WWV， WWVB， WWVH，等等 
      1     nav        无线电导航系统，例如OMEG(欧米加导航系统)， 
LORC(远距离无线电导航系统)，等等 
      1     satellite    一般的卫星业务，例如GOES(地球同步轨道环境卫星)， 
GPS(全球卫星定位服务)，等等 
      2     address        二级参考(4个八位二进制字节表示的NTP服务器因特网 
                    地址） 
-------------------------------------------------------------------------------- 
 
10.    参考时间戳：64bits时间戳，本地时钟被修改的最新时间。 
11.    原始时间戳：客户端发送的时间，64bits。 
12.    接受时间戳：服务端接受到的时间，64bits。 
13.    传送时间戳：服务端送出应答的时间，64bits。 
14.    认证符（可选项）：当NTP的认证机制已运行后，这个字段包含认证者的信息（参见RFC1305 
中的附件C）。在SNTP中本字段一般被来报输入消息所忽略，也不用在输出消息中。 
 
5.    SNTP 客户端操作 
SNTP客户端与NTP/SNTP 服务器通信的模式是一个非持久状态的远程过程调用。在单播方 
式，客户端发给服务器(方式3) 请求并且期望服务器答复 (方式4)。在广播方式，客户端送并 
不请求只是等待一台或更多的服务器的广播消息(方式5) ，这取决于设置。根据客户端和服务 
器设置，单播客户端和广播服务器通常在从64 给1024 s 的间隔里发送消息。   
    单播客户端初始化SNTP 报文首部，再把消息发送到服务器，然后从服务器回复的报文中剥 
去时间包。为此，上面提到的所有报文首部字段，除第一个八位字节外都设置成0。在这个八 
位字节里Li 字段设置为0( 没有警告) 和方式字段设置为3(客户端)。VN 字段必须同NTP 或者 
SNTP 服务器的软件版本一致；但是，NTP 版本3( RFC 1305)的服务器也将接受第2( RFC 1119) 
版本的消息以及版本1( RFC 1059)的消息，而NTP 版本2服务器也将接受NTP 为版本1的消息。 
版本0 ( RFC 959) 消息不再被支持。因为今天因特网已有了NTP 服务器操作的3个版本，推荐 
VN 字段设置1。 
    在单播及广播方式下，单播服务器回答及广播以上所述的所有字段；但是，在SNTP下，各 
字段中，只有传送时间戳在非零情况下才有明确的意思.这个字段的整数部分包含服务器此刻的 
时间，其格式与UDP/TIME 协议相同[POS83].这个字段的fraction部分通常是有效的, SNTP的精 
确度证明可以精确到秒。如果传送用时间戳字段是全0，则该消息将被忽略。 
     在广播方式下，客户端没有附加信息用以计算在服务器和客户端之间的传播延迟，因为在 
此方式下，传送用时间戳和接收时间戳字段是没有意义的。即使在单播方式，大多数客户端也 
会选择忽略原始时间戳和接收时间戳字段。但是，在单播方式下，一种简单的计算可以用来计 
算与服务器有关的往返传播延迟d及本地时钟补偿t，通常对在数十毫秒内。为此，客户端在请 
求包中将本地时钟时间按NTP的格式写入源时间戳。当收到答复时，客户端将目的时间戳作为到 
达时间，并根据它的本地时钟，将其转变成NTP格式。下述表格总结4个时间戳。 
 
      用时间戳名字           ID            产生 
      ------------------------------------------------------------ 
      原始时间戳           T1         时间请求由客户端送 
      收到时间戳           T2         时间请求在服务器收到 
      传送时间戳           T3         时间答复通过服务器送 
      目的地时间戳         T4         时间答复在客户端收到 
 
往返传播延迟d和本地时钟补偿t定义为： 
 
                       D =( T4 - T1) - ( T2 - T3) 
 
                    T =(( T2 - T1)  ( T3 - T4)) /2。 
 
下述表格是SNTP客户端操作的总结。在表格里显示有两种推荐的错误检查方式。在全部NTP 版 
本里，如果Li 字段为3；或者阶层字段不在第1-15范围里；或者传送用时间戳是0，服务器决不 
同步或者不予同步成过去24小时内有效的时间源。在客户端的判断中，保留字段值也可能被检 
查。是否相信传送用时间戳取决于对这些字段中的一个或多个字段的有效性判断。   
      字段名               请求             回答 
      ------------------------------------------------------------- 
      Li                        0         闰秒指示器；如果是3 
                                           (非同步)，则放弃该消息 
      VN                        1( 参见正文)    忽略 
      方式            3( 客户端)      忽略 
      阶层                  0             忽略 
      轮询                   0               忽略 
      精度                    0             忽略 
      根延迟                   0               忽略 
      根差量              0               忽略 
      参考标识符             0               忽略 
      参考时间戳          0               忽略 
      原始用时间戳        0         忽略( 参见正文) 
      收到用时间戳        0         忽略( 参见正文) 
      传送天的时间戳        0         时间；如果是0 
                                             (非同步)，则忽略该消息 
      Authenticator.      (不使用)        忽略 
 
6.    SNTP 服务器操作 
    SNTP 服务器与NTP 或者SNTP客户端操作的模式是一种没有持久状态的RPC 模式。全套的NTP 
算法用来支持冗余校验和不同的网络路径，SNTP服务器通常不实现全套的NTP 算法，建议一台 
SNTP 服务器只与一个外部同步的时钟源一道操作，例如一台可靠的无线电时钟。这样的话，服 
务器总是工作在阶层1。 
    服务器可以工作在单播方式或广播方式或两者同时都用。当单播方式的服务器得到一条请 
求消息时，就在NTP或者SNTP 的来报头里修改特定字段，并把消息返回给发送人，也许还使用 
了与请求相同的信息缓冲区。如果不同步到一台正确操作的无线电时钟的话，服务器可能也可 
能不回答请求，但是回答是首选的，因为可达性可以忽略同步状态如何。在单播方式下，VN 和 
poll字段被完整地复制到应答包中的相同字段。如果请求的方式字段是3(客户端)，那么在答复 
过程中它设置成4(服务器)；否则，为了与NTP规范相符，这个字段设置成2(被动的对称性)。 
 
在广播方式下，服务器只有在已同步的情况下，才发消息给一个正常运行的参考时钟。在此方 
式下， VN 字段设置成3(针对当前的SNTP 版本)，方式字段设成5(广播)。字段poll设置服务器 
测试间隔，接近秒的平方。一台服务器既支持广播方式，同时也支持单播方式，这是非常合乎 
需要的。这对一些潜在的广播客户端来说尤其必要，因为这样做，能使用客户端机/服务器的消 
息来计算传播延迟，这一方法要优于只定时接收广播消息的方法。 
    在单播方式和广播方式下保留的字段被同样地设置。假定服务器是被同步成一台无线电时 
钟或者其它正确的主要参考源，则阶层字段设置为1(主要服务器)，Li 字段设置为0；如果不是， 
阶层字段设置0，Li 字段设置3。精度字段的设置反映出本地时钟的最大的读数误差。对所有的 
实际情况来说，在NTP格式里被计算的值是小数点右边的有效数值，值被表示成负数时间戳形式。 
为了主服务器，根延迟和根差量字段可以设置成0，根差量字段能设置成任意数值(表示时钟的 
最大的期望误差值)。参考标识符设置指明主要参考源，如在上面在表格里说明的。 
    这些时间戳字段被设置如下。如果服务器未被同步或是首先启动的话，全部时间戳字段设 
置成零。如果同步，参考用时间戳设置成最后更新时间（来源于无线电时钟）或者设置成消息 
被送出的时间（如果更新时间不可以获得）。接收时间戳和传送时间戳字段设置成当时消息发 
出的时间。在单播方式下，原始时间戳字段直接从请求包的传送时间戳拷贝过来。因为客户端 
要用它来检查应答，所以复制完整很重要。用广播方式下，这个字段被设置成消息被送出的时 
间。下面的表格总结这些操作。 
      字段名               请求                 回答 
      ---------------------------------------------------------- 
      Li             忽略            0(正常)， 3 
                                                 (非同步) 
      VN             1， 2 或者3           3 或者从请求包中拷贝 
      方式            3(参见正文)         2，4 或者5(参见正文) 
      阶层                   忽略                  服务器阶层 
      投票                   忽略                  拷贝请求包 
      精度                    忽略                  服务器精度 
      根延迟                   忽略                  0 
      根差量            忽略            0(参见正文) 
      参考标识符             忽略                  来源标识符 
      参考时间戳          忽略                  0 或者当前的时间 
      创造时间戳          忽略                  0 或者当前的时间或者从 
传送时间戳请求复制 
      收到时间戳            忽略                  0 或者当前的时间 
      传送时间戳        (参见正文)          0 或者当前的时间 
      Authenticator         忽略            (不使用) 
当例如可能发生在刚启动或在运行期间主要参考源不起作用时，有一些多数客户端允许的无效 
时间戳的范围。一台运行不正常的服务器的最重要的标志是Li 字段，其中一3 的值表明一种 
非同步的状态。当这值被出现时，客户端应该丢掉该条服务器消息，而不管其它字段的内容。 
 
7.    参考资料 
[DAR81 ]波斯特尔， J.，" 网际协议 - DARPA网际计划协议说明"，标准5，1981 年9月， DARPA， 
RFC 791。 
 
 
[DEE89 ]迪林， S.，" IP 多播的主机扩展。标准5， RFC 1112，斯坦福大学， 1989 年8 
月。 
 
 
[MIL92 ] Mills, D，" 网络时间协议( 第3 版本) 说明，实现和分析。 RFC 1305，特拉华大 
学， 1992 年3月。 
 
 
[POS80 ]波斯特尔， J.，" 用户数据报协议"，标准6， RFC 768， USC/Information 科学研 
究所， 1980 年8月。 
 
 
[POS83 ]波斯特尔， J. 和K. Harrenstien，" 时间协议"，标准26， RFC 868， USC/Information 
科学研究所， SRI， 1983 年5月。 
 
8.    安全考虑 
安全问题没在这个备忘录里讨论。 
9.    作者的地址 
David L. Mills

赞回复

vfdff的博客

vfdff

浏览1940932次