TCP/IP协议栈中的TimeStamp选项

原文转自：http://www.cnblogs.com/lovemyspring/articles/4271716.html

TCP应该是以太网协议族中被应用最为广泛的协议之一，这里就聊一聊TCP协议中的TimeStamp选项。这个选项是由RFC 1323引入的，该C建议提交于1992年，到今天已经足足有20个年头。不过相信大部分程序猿对这个建议还是相当陌生。
要理解为啥需要用TimeStamp选项，还需要从TCP协议的几个基本设计说起。

TCP协议的几个设计初衷，以及引发的问题：
1. 协议规定收端不需要响应每一个收到的数据报文，只需要收到N个报文后，向发端回复一个ack报文即可。
    这样的规定是为了提高通讯的效率，但是也引入了几个问题：
    A. 发端发出报文后，到底多久能够收到ack是不确定的。
    B. 万一ack报文丢失了，判断需要重发的timeout时间也很难确定。
2. TCP报文中，标示Sequence号的地址长度为32位。
    这就限制了发端最多一次发送2^30长度的数据，就必须等待ack信号。为啥呢？在这个链接里有一些详细的讨论。
    然而对于超高速以太网（1000M以至于10G），这样会影响TCP连接的转发效率。

为解决上面提到的问题，TimeStamp选项主要有两个用途:
1. 测量TCP连接两端通讯的延迟（Round Trip Time Measurement）
    有了RTTM机制，TCP的两端可以很容易的判断出线路上报文的延迟情况，从而制定出一个优化的发包间隔和报文TimeOut时间，从而解决了第一个问题。
2. 处理Sequence号反转的问题（Protect Against Wrapped Sequence Numbers）。
    TCP收端收到一个数据报文后，会先比较本次收到报文的TimeStamp和上次收到报文的TimeStamp。如果本次的比较新，那么可以直接判断本次收到的报文是新的报文，不需要进行复杂的Sequence Number Window Scale计算，从而解决了第二个问题。

然而，RFC1323建议还存在一些隐患。
建议中定义TimeStamp增加的间隔可以使1ms-1s。如果设备按照1ms的速度增加TimeStamp，那么只要一个TCP连接连续24.8天（1ms*2^31）没有通讯，再发送报文，收端比较本次报文和上次报文TimeStamp的动作就会出错。（问题1）
（注：TCP协议中并没有定义KeepAlive。如果应用层代码不定义超时机制，TCP连接就永远不会中断，所以连续24.8天不通讯的情况是却有可能发生的。）
引用Linux相关代码：((s32)(tp->rx_opt.rcv_tsval - tp->rx_opt.ts_recent) < 0)
比如 tp->rx_opt.rcv_tsval = 0x80000020，       tp->rx_opt.ts_recent = 0x10
 ((s32)(tp->rx_opt.rcv_tsval - tp->rx_opt.ts_recent) = (s32)0x80000010，是一个负数，必然小于0。

如果解决问题1呢？
已知按照RFC1323的规定，按照最快TimeStamp增加的速度，也需要24.8天TImeStamp才有可能发生反转。
如果((s32)(tp->rx_opt.rcv_tsval - tp->rx_opt.ts_recent) < 0)判断成立，还可以再用本地收到报文的本地TimeStamp减去上一次收到报文的本地TimeStamp。如果时间大于24.8天，那么就是TimeStamp发生了反转；否则就不是反转的情况。这样做是不是就万无一失了呢？不一定！

别忘了本地TimeStamp的计数器也是个32位，也可能会翻转的。（问题2）
举个极端的例子：假设TCP两端设备的TimeStamp增加间隔不一致，A为1ms，B为10ms。TCP连接连续248天没有通讯；这个时候B向A发送了一个数据报文。 
此时B发送给A的TCP报文中的TimeStamp，正好发生了翻转。然而由于A的计数器是每1ms加一的，248天时间，A的计数器已经归零过5次了。这时候再用本地TimeStamp做判断还是错的。

比较保险的做法是：
如果TCP连接的速度不那么快（2^32/s），本地TimeStamp用最大间隔时间1S。从而规避了（问题2）。
如果TCP连接速度非常快，1S的TimeStamp间隔就有些不合时宜了，可以选小一级，如100ms。如果这时候还会发生连续24800天（为啥是24800天呢）不通讯的情况，除了骂娘以外，我也没办法了。