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

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

简单网络时间协议 ( SNTP

(RFC1769 —— Simple Network Time Protocol

本备忘录描述简单网络时间协议 (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 被设计成的那些简单的系统里不可能被考虑。

相关文档
最新文档