时间戳选项使发送方在每个报文段中放置一个时间戳值。接收方在确认中返回这个数值,从而允许发送方为每一个收到的 A C K计算RT T(我们必须说“每一个收到的 A C K”而不是“每一个报文段”,是因为T C P通常用一个A C K来确认多个报文段)。我们提到过目前许多实现为每一个窗口只计算一个 RT T,对于包含8个报文段的窗口而言这是正确的。然而,较大的窗口大小则需要进行更好的RT T计算。
RFC 1323的3 . 1节给出了需要为较大窗口进行更好的 RT T计算的信号处理的理由。通常RT T通过对一个数据信号(包含数据的报文段)以较低的频率(每个窗口一次)进行采样来进行计算,这就将别名引入了被估计的RT T中。当每个窗口中有8个报文段时,采样速率为数据率的1 / 8,这还是可以忍受的。但是如果每个窗口中有1 0 0个报文段时,采样速率则为数据速率的1 / 1 0 0,这将导致被估计的RT T不精确,从而引起不必要的重传。如果一个报文段被丢失,则会使情况变得更糟。
图1 8 - 2 0显示了时间戳选项的格式。发送方在第 1个字段中放置一个32 bit的值,接收方在应答字段中回显这个数值。包含这个选项的 T C P首部长度将从正常的2 0字节增加为3 2字节。
时间戳是一个单调递增的值。由于接收方只需要回显收到的内容,因此不需要关注时间戳单元是什么。这个选项不需要在两个主机之间进行任何形式的时钟同步。 RFC 1323推荐在1毫秒和1秒之间将时间戳的值加1。
4.4BSD在启动时将时间戳始终设置为0,然后每隔500 ms将时间戳时钟加1。在图2 4 - 7中,如果观察在报文段1和报文段11的时间戳,它们之间的差(8 9个单元)对应于每个单元500 ms的规定,因为实际时间差为44.4秒。
在连接建立阶段,对这个选项的规定与前一节讲的窗口扩大选项类似。主动发起连接的一方在它的S Y N中指定选项。只有在它从另一方的 S Y N中收到了这个选项之后,该选项才会在以后的报文段中进行设置。
我们已经看到接收方 T C P不需要对每个包含数据的报文段进行确认,许多实现每两个报文段发送一个A C K。如果接收方发送一个确认了两个报文段的 A C K,那么哪一个收到的时间戳应当放入回显应答字段中来发回去呢?为了减少任一端所维持的状态数量,对于每个连接只保持一个时间戳的数值。选择何时
更新这个数值的算法非常简单:
这个算法能够处理下面两种情况:
尽管时间戳选项能够更好地计算 RT T,它还为发送方提供了一种方法,以避免接收到旧的报文段,并认为它们是现在的数据的一部分。下一节将对此进行描述。