从wireshark抓包看TCP头部时间戳

article/2025/4/25 23:10:14

本文于2020年8月23日首发于个人公众号“码农的修炼之道”，欢迎关注。

不知道大家有没有注意到，wireshark抓取tcp报文的时候，大部分时候的报文是如下图所示的，其中带了Seq，Win和Len字段，分别对应了报文序列号、滑动窗口和tcp报文长度。
wireshark抓包1
有时候，也会在报文中看到TSval 和 TSecr 这两个参数，如下图所示。
wireskark抓包2
那么这个参数来源于哪里呢？又有什么作用呢？

1、原理

时间戳（TCP Timestamps Option，TSopt）来源于TCP报文头部的Option选项。这个选项在 TCP 头部的位置如下所示。
在这里插入图片描述
比如下图，我们抓包的报文中的时间戳选项在option中。

TCP的时间戳由四部分构成：类别（kind）、长度（Length）、发送方时间戳（TS value）、回显时间戳（TS Echo Reply）。时间戳选项类别（kind）的值等于 8，用来与其它类型的选项区分。长度（length）等于 10。两个时间戳相关的选项都是 4 字节。
在这里插入图片描述
是否使用时间戳选项是在三次握手里面的 SYN 报文里面确定的。那么这个时间戳选项有什么作用吗？主要有两个作用：

两端往返时延测量（RTT）
序列号回绕（PAWS）

2、RTT原理

由于在真实的网络中，各种丢包情况普遍存在，因此有一套超时重传机制，也就是我们以前说的 TCP中的几种定时器《聊聊TCP中的几个定时器》，那么超时重传的时间如何设置呢？

为了动态地设置，TCP引入了RTT（Round Trip Time），也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间，从而可以方便地设置Timeout——RTO（Retransmission TimeOut），以让我们的重传机制更高效。

但是实际上RTT的计算比较复杂，如下图a所示，发生了重传，如果按照第一次的报文和ACK计算出来的RTT就比较大了，不合理。如图b所示，重传后收到了原始报文的ACK，这样计算出来的RTT偏小，也不合理。
RTT原理
因此，在启用 Timestamps 选项以后，因为 ACK 包里包含了 TSval 和 TSecr，这样无论是正常确认包，还是重传确认包，都可以通过这两个值计算出 RTT。关于RTO计算算法，资料也比较多了。比如RFC793中定义的经典算法是这样的:
RFC793
比如目前Linux下使用的RTO计算算法为Jacobson / Karels 算法：
RFC2988

3、序列号回绕PAWS

TCP 的序列号用 32bit 来表示，因此在 2^32 字节的数据传输后序列号就会溢出回绕。TCP 的窗口经过窗口缩放可以最高到 2^30，也就是1G，在高速网络中，序列号在很短的时间内就会被重复使用。

如果有 Timestamps 的存在，内核会维护一个为每个连接维护一个 ts_recent 值，记录最后一次通信的的 timestamps 值，当收到的数据包中 timestamps 值小于 ts_recent 值，就会丢弃掉这个数据包。等收到的数据包的timestamps 值大于 ts_recent，这个包可以被正常接收。

实际上timestamps 值是一个单调递增的值，这个选项不要求两台主机进行时钟同步。两端 timestamps 值增加的间隔也可能步调不一致，比如一条主机以每 1ms 加一的方式递增，另外一条主机可以以每 200ms 加一的方式递增。此外，timestamps 是一个双向的选项，如果只要有一方不开启，双方都将停用。

在Linux下可以通过下面方式开启或关闭timestamp功能。