linux tcp 时间戳,简单了解TCP首部时间戳

一、时间戳

TCP属于协议层的第三次，封包被称为segment。具体详见时间戳的作用和时间戳产生的背景。

1.1 计算RTT

发送一个报文时将发送时间写入时间戳选项，在收到的ACK报文时通过其时间戳选项的回显值就能知道它确认的是什么时候发送的报文，用当前时间减去回显时间就可以得到一个RTT。

1.2 防止序号回绕

避免TCP出现报文无法辨识导致混乱。

TCP判断数据新旧的方法是检查数据的序列号是否位于sun.una到sun.una + 2**31的范围内，而序列号空间的总大小为2*32，即约4.29G。在万兆局域网中，4.29G字节数据回绕只需几秒钟，这时TCP就无法准确判断数据的新旧。由此引入了时间戳。

手法：收到一个报文时记录选项中的时间戳值，收到下一个报文时将其中的时间戳与上次的进行对比即可。时间戳同样存在回绕问题，回绕速度只与对端主机时钟频率有关。Linux以本地时钟计数(jiffies)作为时间戳的值，假设时钟计数加1需要1ms，则只需要约24.8天就能回绕一半，只要报文的生存时间小于这个值的话判断新旧数据就不会出错，被称为PAWS(Protect Against Wrapped Sequence numbers)。但随着硬件时钟频率的提升，时间戳回绕的速度也会加快，用时间戳解决序列号回绕问题的方法早晚会遇到困境。

二、RTO的计算

详见TCP三次握手第八个疑症。TCP交互过程中，如果发送的包一直没收到ACK确认，是要一直等下去吗？显然不能一直等(如果发送的包在路由过程中丢失了，对端都没收到又如何给你发送确认呢？)，这样协议将不可用，既然不能一直等下去，那么该等多久？

等太长时间的话，数据包都丢了很久了才重发，没有效率，性能差；等太短时间的话，可能ACK还在路上快到了，这时候却重传了，造成浪费，同时过多的重传会造成网络拥塞，进一步加剧数据的丢失。我们不能去猜测一个重传超时时间，应该是通过一个算法去计算，并且这个超时时间应该是随着网络状况在变化的。为了使我们的重传机制更高效，如果我们能够比较准确知道在当前网络状况下，一个数据包从发出去到回来的时间RTT——Round Trip Time，就能得到RTO了。

[1] 首先采样计算RTT值

[2] 然后计算平滑的RTT，称为Smoothed Round Trip Time (SRTT)，SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)

[3] RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]