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的兩端能夠非常easy的推斷出線路上報文的延遲情況。從而制定出一個優化的發包間隔和報文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天呢）不通訊的情況，除了罵娘以外。我也沒辦法了。