前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >速读原著-TCP/IP(ICMP时间戳请求与应答)

速读原著-TCP/IP(ICMP时间戳请求与应答)

作者头像
cwl_java
发布2020-03-03 10:38:35
1.6K0
发布2020-03-03 10:38:35
举报
文章被收录于专栏:cwl_Javacwl_Javacwl_Java

6.4 ICMP时间戳请求与应答

I C M P时间戳请求允许系统向另一个系统查询当前的时间。返回的建议值是自午夜开始计算的毫秒数,协调的统一时间( Coordinated Universal Time, UTC)(早期的参考手册认为U T C是格林尼治时间)。这种I C M P报文的好处是它提供了毫秒级的分辨率,而利用其他方法从别的主机获取的时间(如某些 U n i x系统提供的r d a t e命令)只能提供秒级的分辨率。由于返回的时间是从午夜开始计算的,因此调用者必须通过其他方法获知当时的日期,这是它的一个缺陷。

I C M P时间戳请求和应答报文格式如图 6 - 6所示。

在这里插入图片描述
在这里插入图片描述

请求端填写发起时间戳,然后发送报文。应答系统收到请求报文时填写接收时间戳,在发送应答时填写发送时间戳。但是,实际上,大多数的实现把后面两个字段都设成相同的值(提供三个字段的原因是可以让发送方分别计算发送请求的时间和发送应答的时间)。

6.4.1 举例

我们可以写一个简单程序(取名为 i c m p t i m e),给某个主机发送 I C M P时间戳请求,并打印出返回的应答。它在我们的小互联网上运行结果如下:

在这里插入图片描述
在这里插入图片描述

程序打印出I C M P报文中的三个时间戳:发起时间戳( o r i g)、接收时间戳( r e c v)以及发送时间戳( x m i t)。正如我们在这个例子以及下面的例子中所看到的那样,所有的主机把接收时间戳和发送时间戳都设成相同的值。

我们还能计算出往返时间(r t t),它的值是收到应答时的时间值减去发送请求时的时间值。d i f f e r e n c e的值是接收时间戳值减去发起时间戳值。这些值之间的关系如图6 - 7所示。

在这里插入图片描述
在这里插入图片描述

如果我们相信RT T的值,并且相信RT T的一半用于请求报文的传输,另一半用于应答报文的传输,那么为了使本机时钟与查询主机的时钟一致,本机时钟需要进行调整,调整值是d i f f e r e n c e减去RT T的一半。在前面的例子中, b s d i的时钟比s u n的时钟要慢7 ms和8 ms。

由于时间戳的值是自午夜开始计算的毫秒数,即 U T C,因此它们的值始终小于86 400 000( 2 4×6 0×6 0×1 0 0 0 )。这些例子都是在下午 4 : 0 0以前运行的,并且在一个比 U T C慢7个小时的时区,因此它们的值比82 800 000(2 3 0 0小时)要大是有道理的。

如果对主机b s d i重复运行该程序数次,我们发现接收时间戳和发送时间戳的最后一位数总是0。这是因为该版本的软件( 0 . 9 . 4版)只能提供1 0 m s的时间分辨率(说明参见附录 B)。如果对主机s v r 4运行该程序两次,我们发现 S V R 4时间戳的最后三位数始终为 0:

在这里插入图片描述
在这里插入图片描述

由于某种原因, S V R 4在I C M P时间戳中不提供毫秒级的分辨率。这样,对秒以下的时间差调整将不起任何作用。

如果我们对子网 1 4 0 . 2 5 2 . 1上的其他主机运行该程序,结果表明其中一台主机的时钟与s u n相差3 . 7秒,而另一个主机时钟相差近 7 5秒:

在这里插入图片描述
在这里插入图片描述

另一个令人感兴趣的例子是路由器 g a t e w a y(一个C i s c o路由器)。它表明,当系统返回一个非标准时间戳值时(不是自午夜开始计算的毫秒数, U T C),它就用32 bit时间戳中的高位来表示。我们的程序证明了一点,在尖括号中打印出了接收和发送的时间戳值(在关闭高位之后)。另外,不能计算发起时间戳和接收时间戳之间的时间差,因为它们的单位不一致。

在这里插入图片描述
在这里插入图片描述

如果我们在这台主机上运行该程序数次,会发现时间戳值显然具有毫秒级的分辨率,而且是从某个起始点开始计算的毫秒数,但是起始点并不是午夜 U T C(例如,可能是从路由器引导时开始计数的毫秒数)。

作为最后一个例子,我们来比较 s u n主机和另一个已知是准确的系统时钟—一个N T Pstratum 1服务器(下面我们会更多地讨论 N T P,网络时间协议)。

在这里插入图片描述
在这里插入图片描述

如果我们把d i f f e r e n c e的值减去RT T的一半,结果表明s u n主机上的时钟要快3 8 . 5~51.5 ms。

6.4.2 另一种方法

还可以用另一种方法来获得时间和日期。

  1. 在1 . 1 2节中描述了日期服务程序和时间服务程序。前者是以人们可读的格式返回当前的时间和日期,是一行A S C I I字符。可以用t e l n e t命令来验证这个服务:
在这里插入图片描述
在这里插入图片描述

另一方面,时间服务程序返回的是一个 3 2 b i t的二制进数值,表示自 U T C,1 9 0 0年1月1日午夜起算的秒数。这个程序是以秒为单位提供的日期和时间(前面我们提过的 r d a t e命令使用的是T C P时间服务程序)。

  1. 严格的计时器使用网络时间协议( N T P),该协议在 RFC 1305中给出了描述 [ M i l l s 1 9 9 2 ]。这个协议采用先进的技术来保证 L A N或WA N上的一组系统的时钟误差在毫秒级以内。对计算机精确时间感兴趣的读者应该阅读这份 R F C文档。
  2. 开放软件基金会( O S F)的分布式计算环境( D C E)定义了分布式时间服务( D T S),它也提供计算机之间的时钟同步。文献 [ R o s e n b e rg, Kenney and Fisher 1992]提供了该服务的其他细节描述。
  3. 伯克利大学的 U n i x系统提供守护程序 t i m e d( 8 ),来同步局域网上的系统时钟。不像N T P和D T S,t i m e d不在广域网范围内工作。
本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-03-01 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 6.4 ICMP时间戳请求与应答
    • 6.4.1 举例
      • 6.4.2 另一种方法
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档