TCP/IP協(xié)議棧中的TimeStamp選項
TCP應(yīng)該是以太網(wǎng)協(xié)議族中被應(yīng)用最為廣泛的協(xié)議之一，這里就聊一聊TCP協(xié)議中的TimeStamp選項。這個選項是由RFC 1323引入的，該C建議提交于1992年，到今天已經(jīng)足足有20個年頭。不過相信大部分程序猿對這個建議還是相當(dāng)陌生。
要理解為啥需要用TimeStamp選項，還需要從TCP協(xié)議的幾個基本設(shè)計說起。
TCP協(xié)議的幾個設(shè)計初衷，以及引發(fā)的問題：
1. 協(xié)議規(guī)定收端不需要響應(yīng)每一個收到的數(shù)據(jù)報文，只需要收到N個報文后，向發(fā)端回復(fù)一個ack報文即可。
這樣的規(guī)定是為了提高通訊的效率，但是也引入了幾個問題：
A. 發(fā)端發(fā)出報文后，到底多久能夠收到ack是不確定的。
B. 萬一ack報文丟失了，判斷需要重發(fā)的timeout時間也很難確定。
2. TCP報文中，標(biāo)示Sequence號的地址長度為32位。
這就限制了發(fā)端最多一次發(fā)送2^30長度的數(shù)據(jù)，就必須等待ack信號。為啥呢？在這個鏈接里有一些詳細的討論。
然而對于超高速以太網(wǎng)（1000M以至于10G），這樣會影響TCP連接的轉(zhuǎn)發(fā)效率。
為解決上面提到的問題，TimeStamp選項主要有兩個用途:
1. 測量TCP連接兩端通訊的延遲（Round Trip Time Measurement）
有了RTTM機制，TCP的兩端可以很容易的判斷出線路上報文的延遲情況，從而制定出一個優(yōu)化的發(fā)包間隔和報文TimeOut時間，從而解決了第一個問題。
2. 處理Sequence號反轉(zhuǎn)的問題（Protect Against Wrapped Sequence Numbers）。
TCP收端收到一個數(shù)據(jù)報文后，會先比較本次收到報文的TimeStamp和上次收到報文的TimeStamp。如果本次的比較新，那么可以直接判斷本次收到的報文是新的報文，不需要進行復(fù)雜的Sequence Number Window Scale計算，從而解決了第二個問題。
然而，RFC1323建議還存在一些隱患。
建議中定義TimeStamp增加的間隔可以使1ms-1s。如果設(shè)備按照1ms的速度增加TimeStamp，那么只要一個TCP連接連續(xù)24.8天（1ms*2^31）沒有通訊，再發(fā)送報文，收端比較本次報文和上次報文TimeStamp的動作就會出錯。（問題1）
（注：TCP協(xié)議中并沒有定義KeepAlive。如果應(yīng)用層代碼不定義超時機制，TCP連接就永遠不會中斷，所以連續(xù)24.8天不通訊的情況是卻有可能發(fā)生的。）
引用Linux相關(guān)代碼：((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，是一個負數(shù)，必然小于0。
如果解決問題1呢？
已知按照RFC1323的規(guī)定，按照最快TimeStamp增加的速度，也需要24.8天TImeStamp才有可能發(fā)生反轉(zhuǎn)。
如果((s32)(tp->rx_opt.rcv_tsval - tp->rx_opt.ts_recent) < 0)判斷成立，還可以再用本地收到報文的本地TimeStamp減去上一次收到報文的本地TimeStamp。如果時間大于24.8天，那么就是TimeStamp發(fā)生了反轉(zhuǎn)；否則就不是反轉(zhuǎn)的情況。這樣做是不是就萬無一失了呢？不一定！
別忘了本地TimeStamp的計數(shù)器也是個32位，也可能會翻轉(zhuǎn)的。（問題2）
舉個極端的例子：假設(shè)TCP兩端設(shè)備的TimeStamp增加間隔不一致，A為1ms，B為10ms。TCP連接連續(xù)248天沒有通訊；這個時候B向A發(fā)送了一個數(shù)據(jù)報文。
此時B發(fā)送給A的TCP報文中的TimeStamp，正好發(fā)生了翻轉(zhuǎn)。然而由于A的計數(shù)器是每1ms加一的，248天時間，A的計數(shù)器已經(jīng)歸零過5次了。這時候再用本地TimeStamp做判斷還是錯的。
比較保險的做法是：
如果TCP連接的速度不那么快（2^32/s），本地TimeStamp用最大間隔時間1S。從而規(guī)避了（問題2）。
如果TCP連接速度非常快，1S的TimeStamp間隔就有些不合時宜了，可以選小一級，如100ms。如果這時候還會發(fā)生連續(xù)24800天（為啥是24800天呢）不通訊的情況，除了罵娘以外，我也沒辦法了。