TCP/IP详解--TCP首部选项中时间戳选项的作用

在TCP选项字段中为TCP预留有时间戳功能，不管在网络层面还是应用层面，TCP时间戳往往被大家认为是一个系统行为，并忽略其存在。其实在某些环境下，TCP时间戳同样可以成为大家在时延问题troubleshooting定位时的一个利器。

首先，让我们先来回顾一下TCP时间戳的理论知识。

1） TCP时间戳位于TCP选项中，kind=8；lenth=10；data由timestamp和timestamp echo两个值组成，各4个字节的长度。

2） TCP时间戳理论作用有3个：序列号回绕，乱序的时间判断依据，避免确认二义性，以及计算RTT。

3） TCP时间戳工作方式：双方各自维护自己的时间戳，时间戳的值随时间单调递增（规定为1ms-1s/次，常见值为1ms、10ms）。本端发送timesstamp值，对方收到后在后续的ACK的timestamp echo回应本端的值，并在timestamp中发送自己的时间戳。TCP记录发送时间戳和收到回应的时间, 从而获得RTT。

如图，设备A发出首个请求为a2时刻，然后设备B回复ACK将a2放入时间戳回显中，设备A在收到这个回显后结合当前自己的时间戳就可以计算出RTT。

回顾完理论概念后，我们来实例看下TCP时间戳在定位中所起的作用。

某用户系统出现数据库响应数据延迟较高的问题，在该用户环境中服务器和数据库间存在几个带FW模块的网络设备，但由于资源及流程问题，用户只部署了一个捕获点。

链路如下：Server——6509-1——6509-2——DB，用户在65上span了一份数据。

首先，先从报文中确认延迟包采样的位置。

我们采样第19号包，延迟为0.45秒，显然也不是应用响应延迟（这是连续的响应数据的第二个包）。产生问题的可能性有两种，一是服务器的TCPIP协议栈问题，二是网络导致的问题。从单点的问题来看暂时无法判断，我们可以选择再部署一个新的捕获点或移动捕获点到服务器侧来确认这样的问题。

在这个报文我们发现是具有TCP时间戳选项的，这是一个非常有利的要素，这表示我们未必需要再部署新捕获点了。

在获得时间戳前，我们先来确认两点。

一是真实的网络延迟情况，可以通过三次握手时间得到，根据三次握手，可以看到网络时间延迟在1ms级别左右，非常小。

二是服务器方TCP时间戳增加一次的大致时间，通过5、6两个包的间隔为110ms，而5号包TCP时间戳为8209278，6号包为8209289，可以得到应该为10ms。

接下来，通过sniffer、dali、wireshark等工具我们可以轻松地获取前后的TCP时间戳，我们可以用下表来展示。

下面，我们来解读下这些数据。

1） 根据时间戳回显来看，在数据库发出第19号包时，还没有收到第18号ACK。而实际19和17号包到达捕获点的间隔时间远大于三次握手时得到的RTT。

2） 看20、21号包的时间戳回显结果。结合捕获点获得的延迟间隔。显然19号包在到达捕获点后，很快就被服务器接收到。

3） 回到17号和19号间的发包间隔时间。两者的时间戳数值相隔为（8209341-8209289）=52。而根据捕获点获得的delta延迟2个包的间隔为（0.039+0.476）s=515ms。 根据之前得到的10ms/次的时间戳递增速度，可以得到网络上所看到的延迟，和实际在数据库发出数据包时就已经体现在时间戳上的基本一致，这样我们就可以排除网络延迟的可能性。

这样就可以避免再布点的麻烦，以提高问题点位置的定位效率。

最后，介绍下常见系统的TCP时间戳开关。

1）centos（Linux）

查看默认值的方法：[root@localhost ~]# cat /proc/sys/net/ipv4/tcp_timestamps

0表示关闭，1表示打开。

修改该值的方法：vim /etc/sysctl.conf 添加 net.ipv4.tcp_timestamps=0 or 1

2）Windows 修改注册表，查找 “Tcp1323Opts”

(HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\Tcpip\Parameters下)

Tcp1323Opts

说明：该参数控制 RFC 1323 时间戳与窗口缩放选项。默认情况下，启用时间戳与窗口缩放，但是可以使用标志位进行控制。0 位控制窗口缩放，1 位控制时间戳。

值为0（禁用 RFC 1323 选项）

值为1（仅启用窗口缩放）

值为2（仅启用时间戳）

值为3（两个选项均启用）