网络时间协议简介

网络时间协议简介

ID:13817570

大小:102.00 KB

页数:14页

时间:2018-07-24

上传者:U-3151
网络时间协议简介_第1页
网络时间协议简介_第2页
网络时间协议简介_第3页
网络时间协议简介_第4页
网络时间协议简介_第5页
资源描述:

《网络时间协议简介》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

网络时间协议简介      NTP(NetworkTimeProtocol)是由美国德拉瓦大学的DavidL.Mills教授于1985年提出,除了可以估算封包在网络上的往返延迟外,还可独立地估算计算机时钟偏差,从而实现在网络上的高精准度计算机校时,它是设计用来在Internet上使不同的机器能维持相同时间的一种通讯协定。时间服务器(timeserver)是利用NTP的一种服务器,通过它可以使网络中的机器维持时间同步。在大多数的地方,NTP可以提供1-50ms的可信赖性的同步时间源和网络工作路径。      网络时间协议(NTP)的详细说明在RFC-1305[Mills1992]中。RFC-1305对NTP协议自动机在事件、状态、转变功能和行为方面给出了明确的说明。它以合适的算法以增强时钟的准确性,并且减轻多个由于同步源而产生的差错,实现了准确性低于毫秒的时间服务,以满足目前因特网中路径量测的需要。      NTP是一个跨越广域网或局域网的复杂的同步时间协议,它通常可获得毫秒级的精度。RFC2030[Mills1996]描述了SNTP(SimpleNetworkTimeProtocol),目的是为了那些不需要完整NTP实现复杂性的主机,它是NTP的一个子集。通常让局域网上的若干台主机通过因特网与其他的NTP主机同步时钟,接着再向局域网内其他客户端提供时间同步服务。     注:清华大学网络中心的服务器采用NTP协议,所以同时支持NTP和SNTP客户端的时间同步请求。有关NTP更详细的资料,请访问DavidL.Mills的主页。网络时间服务的层状结构       网络延时与时钟偏差的测量TimestampNameIDWhenGeneratedOriginateTimestampT1timerequestsentbyclientReceiveTimestampT2timerequestreceivedatserverTransmitTimestampT3timereplysentbyserverDestinationTimestampT4timereplyreceivedatclientt为服务器和客户端之间的时间偏差;d为两者之间的往返时间∵T2=T1+t+d/2;T2-T1=t+d/2;T4=T3-t+d/2;T3-T4=t-d/2;∴d=(T4-T1)-(T3-T2);t=((T2-T1)+(T3-T4))/2[返回页面顶端] 网络时间服务的实现方式·网络时间服务的实现方式o无线时钟:服务器系统可以通过串口连接一个无线时钟。无线时钟接收GPS(全球卫星定位系统)的卫星发射的信号来决定当前时间。无线时钟是一个非常精确的时间源,但是需要花一定的费用。o时间服务器:还可以使用网络中NTP时间服务器,通过这个服务器来同步网络中的系统的时钟。http://www.eecis.udel.edu/~mills/ntp/servers.html列出了Internet上有效的一级时间服务器。o局域网内的同步:如果只是需要在本局域网内进行系统间的时钟同步,那么就可以使用局域网中任何一个系统的时钟。你需要选择局域网中的一个节点的时钟作“权威的”的时间源,然后其它的节点就只需要与这个时间源进行时间同步即可。使用这种方式,所有的节点都会使用一个公共的系统时钟,但是不需要和局域网外的系统进行时钟同步。如果一个系统在一个局域网的内部,同时又不能使用无线时钟,这种方式是最好的选择。o注:网络中心的一级服务器从GPS获得精确时间。·网络时间服务的工作模式oSever/Clientmode:用户向一个多几个服务器提出服务请求,根据所交换的信息,从中选择认为最准确的时间,并调整本地的时钟。oMulticast/Broadcastmode:此种模式是适用于用在高速的LAN上。利用一个或多个服务器在固定的周期向某个多播地址做广播。oSymmetricmode:二个以上的Server互相进行时间消息的通讯,可以互相校正对方的时间,以维持整个subnet的时间一致性。o注:对校园网用户采用服务器/客户端模式的时间服务。·保持网络节点时间同步的机制ontpdate命令:此命令被用来立即同步客户端和服务器的时间。这是同步客户端和服务器的时间的最快方式。系统每次启动的时候会使用这个命令,用来确保客户端和服务器的时间的同步。这个命令通常指定一个NTP服务器作为一个参数,客户端的时钟被设置为和服务器的时间匹配。当这个命令使用多个NTP服务器作为参数时,客户端会使用最低级的NTP服务器。如果级别相等,客户端会使用加权平均数。ontpd守护进程:此进程在后台持续运行,并且会定时校验客户端的时钟和NTP服务器的时间。xntpd守护进程通常是在系统启动的时候启动。因为客户端的时钟可能产生漂移,以致与实际的NTP时钟有差异。xntpd守护进程会周期性地发送一个NTP服务器的网络请求,并且与客户端的时钟对比,在必要的时候修正客户端的时间,同时将时间差存到名为/etc/ntp.drift文件。默认的xntpd时间检查的间隔为64秒,在第一次检查的时候,客户端的时钟和NTP服务器上的时钟的差异会被记录下来,同时依靠这个时间差异来计划下一次检查。如果这个时间差异很大,下一次的时间检查会很快发生。如果这个差异很小,下一次的检查到来的时间会相应的延长。这样就避免每次都去查询网络中的时间服务器,从而可以减轻网络负载。查询NTP服务器的次数会慢慢变少。直到达到NTP请求的最小值。o注:在命令行方式下,可以采用"ntpd-q"或者"ntpdate[-b]time.edu.cn"进行对时。使用ntpd进行时间同步时,应事先配置好ntp.conf文件。 简单网络时间协议(SNTP)(RFC1769——SimpleNetworkTimeProtocol)本备忘录的状况:本备忘录为Internetcommunity提供了信息,但不规定任何一种类型的Internet标准。本备忘录的分发没有限制。概要本备忘录描述简单网络时间协议(SNTP),这是网络时间协议(NTP)的一个改写本,NTP协议适用于同步因特网上的计算机时钟。当不须要实现RFC1305所描述的NTP完全功能的情况下,可以使用SNTP。它能用单播方式(点对点)和广播方式(点对多点)操作。它也能在IP多播方式下操作(可提供这种服务的地方)。SNTP与当前及以前的NTP版本并没有大的不同。但它是更简单,是一个无状态的远程过程调用(RPC),其准确和可靠性相似于UDP/TIME协议在RFC868描述中所预期的。本备忘录淘汰相同的标题的RFC1361。它的目的是解释用广播方式操作的协议模式,提供某些地方的进一步说明并且改正一些印刷上的错误。在NTP版本3RFC1305中说明的工作机理对SNTP的实现不是完全需要的。本备忘录的分发没有限制。目录1.介绍22.工作模式与地址分配23.NTP时间戳格式34.NTP报文格式45.SNTP客户端操作66.SNTP服务器操作77.参考资料88.安全考虑99.作者的地址91.介绍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算法,主服务器通常期望的可靠性才有可能达到。这种做法使主同步源在无线电时钟通信失败或者交付了错误时间时,还能用到其它几个无线电时钟和通向其它主要服务器的备份路径。因此,应该仔细考虑客户端中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,这应该足以满足最高的要求了。01234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Seconds|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|SecondsFraction(0-padded)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+注意,从1968年起,最高有效位(整数部分的0bit位)已经被确定,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消息的格式被显示如下。12301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|LI|VN|Mode|Stratum|Poll|Precision|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|根延迟|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|根差量|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|参考标识符|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||参考时间戳(64)|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||原始时间戳(64)|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |||接受时间戳(64)|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||传送时间戳(64)|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||||认证符(可选项)(96)|||||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+如下一部分描述,在SNTP里大多数这些字段被预规定的数据给赋初值。为完整起见,每个字段的功能在下面被简要总结。1.闰秒标识器:这是一个二位码,预报当天最近的分钟里要被插入或删除的闰秒秒数。用1/0表示,分别说明如下:LIValue含义--------------------------------------------------------------------------------------000无预告011最近一分钟有61秒102最近一分钟有59秒113警告状态(时钟未同步)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.测试间隔:八位signedinteger,表示连续信息之间的最大间隔,精确到秒的平方及。本字段的值从4(16s)到14(16284s);然而,大多数应用使用6(64s)到10(1024s)。6.精度:八位signedinteger,表示本地时钟精度,精确到秒的平方级。值从-6(主平)到-20(微妙级时钟)。7.根时延:32位带符号定点小数,表示在主参考源之间往返的总共时延,以小数位后15~16bits。数值根据相关的时间与频率可正可负,从负的几毫秒到正的几百毫秒。8.根离散:32位带符号定点小数,表示在主参考源有关的名义错误,以小数位后15~16bits。范围:0~几百毫秒。9.参考时钟标识符:32bits,用来标识特殊的参考源。在stratum0(未指定)或stratum1(基本参考)的情况下,该字段以四个八位字节,左对齐,零填充的string表示。当没有NTP枚举时,使用下列ASCII标识符:阶层代码意思----------------------------------------------------------------1pps精度校准源,例如ATOM(原子钟),PPS代表(每秒脉冲精度源),等等1service除了一般的NTP报时服务外,例如ACTS(计算机自动化报时服务),TIME(UDP/Time协议),TSP(Unix报时服务协议),DTSS.(数字化时间同步服务),等等1radio一般的收音机服务,带有callsigns,例如CHU,DCF77,MSF,TDF,WWV,WWVB,WWVH,等等 1nav无线电导航系统,例如OMEG(欧米加导航系统),LORC(远距离无线电导航系统),等等1satellite一般的卫星业务,例如GOES(地球同步轨道环境卫星),GPS(全球卫星定位服务),等等2address二级参考(4个八位二进制字节表示的NTP服务器因特网地址)--------------------------------------------------------------------------------10.参考时间戳:64bits时间戳,本地时钟被修改的最新时间。11.原始时间戳:客户端发送的时间,64bits。12.接受时间戳:服务端接受到的时间,64bits。13.传送时间戳:服务端送出应答的时间,64bits。14.认证符(可选项):当NTP的认证机制已运行后,这个字段包含认证者的信息(参见RFC1305中的附件C)。在SNTP中本字段一般被来报输入消息所忽略,也不用在输出消息中。5.SNTP客户端操作SNTP客户端与NTP/SNTP服务器通信的模式是一个非持久状态的远程过程调用。在单播方式,客户端发给服务器(方式3)请求并且期望服务器答复(方式4)。在广播方式,客户端送并不请求只是等待一台或更多的服务器的广播消息(方式5),这取决于设置。根据客户端和服务器设置,单播客户端和广播服务器通常在从64给1024s的间隔里发送消息。单播客户端初始化SNTP报文首部,再把消息发送到服务器,然后从服务器回复的报文中剥去时间包。为此,上面提到的所有报文首部字段,除第一个八位字节外都设置成0。在这个八位字节里Li字段设置为0(没有警告)和方式字段设置为3(客户端)。VN字段必须同NTP或者SNTP服务器的软件版本一致;但是,NTP版本3(RFC1305)的服务器也将接受第2(RFC1119)版本的消息以及版本1(RFC1059)的消息,而NTP版本2服务器也将接受NTP为版本1的消息。版本0(RFC959)消息不再被支持。因为今天因特网已有了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小时内有效的时间源。在客户端的判断中,保留字段值也可能被检查。是否相信传送用时间戳取决于对这些字段中的一个或多个字段的有效性判断。字段名请求回答-------------------------------------------------------------Li0闰秒指示器;如果是3(非同步),则放弃该消息VN1(参见正文)忽略方式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(非同步)VN1,2或者33或者从请求包中拷贝方式3(参见正文)2,4或者5(参见正文)阶层忽略服务器阶层投票忽略拷贝请求包精度忽略服务器精度根延迟忽略0根差量忽略0(参见正文)参考标识符忽略来源标识符 参考时间戳忽略0或者当前的时间创造时间戳忽略0或者当前的时间或者从传送时间戳请求复制收到时间戳忽略0或者当前的时间传送时间戳(参见正文)0或者当前的时间Authenticator忽略(不使用)当例如可能发生在刚启动或在运行期间主要参考源不起作用时,有一些多数客户端允许的无效时间戳的范围。一台运行不正常的服务器的最重要的标志是Li字段,其中一3的值表明一种非同步的状态。当这值被出现时,客户端应该丢掉该条服务器消息,而不管其它字段的内容。7.参考资料[DAR81]波斯特尔,J.,"网际协议-DARPA网际计划协议说明",标准5,1981年9月,DARPA,RFC791。[DEE89]迪林,S.,"IP多播的主机扩展。标准5,RFC1112,斯坦福大学,1989年8月。[MIL92]Mills,D,"网络时间协议(第3版本)说明,实现和分析。RFC1305,特拉华大学,1992年3月。[POS80]波斯特尔,J.,"用户数据报协议",标准6,RFC768,USC/Information科学研究所,1980年8月。[POS83]波斯特尔,J.和K.Harrenstien,"时间协议",标准26,RFC868,USC/Information科学研究所,SRI,1983年5月。8.安全考虑安全问题没在这个备忘录里讨论。9.作者的地址DavidL.Mills电工程处特拉华大学纽瓦克,DE19716电话呼叫:(302)831-8247电子邮件:Mills@udel.edu. RFC1769——SimpleNetworkTimeProtocol简单网络时间协议(SNTP)1RFC文档中文翻译计划

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。
关闭