TCP協(xié)議中Window Scale Option問題【完全解決】

jiufei19

經過和eexplorer的探討，我昨天仔細將他的說明和自己的考慮重新認真思索了一遍，終于徹底解決了2**31的問題，下面我將分析詳細說明如下，希望能給大家?guī)椭�（假如沒有錯誤的話:" />:" /> ）

1、參考圖1


1、下面我們分析下對應2**32的序號空間，究竟發(fā)送和接收窗口需要多大？
a）我們首先假定滑動窗口大小剛好容納整個32bits序號空間，于是表示當發(fā)送方沒有是收到接收方的ACK之前，最多可以發(fā)送2**32字節(jié)數(shù)據(jù)
b）本圖為初始連接的狀態(tài)
c）假定發(fā)送方發(fā)送了2**32字節(jié)數(shù)據(jù)后，尚未收到接收方的任何ACK，于是發(fā)送方開始等待，也即snd.una=1（不失一般性，假定SYN分段序號為0）
d）因為已經發(fā)送了2**32字節(jié)數(shù)據(jù)，所以下一次發(fā)送的分段的序號將從0重新開始，并且我們假定在某個時刻發(fā)送方收到了接收方發(fā)回的ACK，該ACK確認了頭1000個字節(jié)的數(shù)據(jù)，并且1001開始的部分分段可能正在途中（被delayed），我們不妨假定正好1001-2000的分段被延遲了，尚未到達接收方
e）因為發(fā)送方收到了ACK1000，于是發(fā)送方可以繼續(xù)發(fā)送新的分段，這里一定要注意，發(fā)送方可以發(fā)送的新的數(shù)據(jù)量并不是只限1-1000這1千字節(jié)，因為究竟可以發(fā)送多大數(shù)據(jù)量取決于此ACK1000種所攜帶的窗口大小，而這個窗口大小又取決于接收方應用讀取接收方TCP緩存的大小，顯然這個讀取的大小并不固定為1000字節(jié)，其實該大小和1000沒有任何關系，完全是接收方應用的read行為，所以此時完全存在接收方應用所讀的數(shù)據(jù)大于1000字節(jié)的情況，于是這個窗口的大小隨ACK1000返回給發(fā)送方后，發(fā)送方此時就可能發(fā)送1001-2000開始的序號分段，那么問題就出現(xiàn)了，當新的1001分段發(fā)出后，將和老的1001分段序號完全相同，則接收方將如何判斷哪個是old，哪個是new？另外，如果此時發(fā)送方因為超時而重發(fā)1-1000分段，那么同樣因為接收方當前正準備接收1-1000分段，這樣也造成了混淆，于是我們知道滑動窗口不可能和序號空間一樣大

2、因為滑動窗口的大小必須是2的整數(shù)次冪，所以我們接下來分析是否可以為2**31

參考圖2






a）上圖顯示了當滑動窗口為32bit序號空間一半的情況
b）同理按照剛才的分析，此時發(fā)送方在未收到接收方的ACK時，最多可以發(fā)送2**31字節(jié)數(shù)據(jù)，于是snd.una=1，此時發(fā)送方暫停發(fā)送
c）并且我們假定接收方全部正確收到了，于是我們有rcv.wup=2**31，接收窗口右邊界=rcv.wup+rcv.wnd
d）因為發(fā)送方一直沒有收到ACK，所以此時發(fā)送方可能超時然后重發(fā)認為丟失的那些分段，這些分段的序號從0-2**31-1不妨設為seq=0，那么問題就產生了，這個seq=0的分段對于接收方而言到底是old還是new？
e）顯然接收方無法正確判斷�。�！注意，這里的關鍵問題都是因為下一個要接收的正確分段序號已經開始回繞了，導致重發(fā)的分段和新發(fā)分段的序號可能重疊，所以解決問題的辦法只有是想法讓下一個準備接收的分段序號不和重發(fā)的分段重疊，或者反過來即便要重疊，則必須通過PAWS那樣引入另外的參數(shù)來區(qū)別


3、既然2**31不能為滑動窗口的最大值，那么只能考慮2**30了，于是


參考圖3

接前面的分析，因為滑動窗口的大小只能是2的整數(shù)次冪，所以目前只能為2**30，這樣，我們就很自然得到下面這個結論
rcv.wup+rcv.wnd – snd.una <= 2**31
此時因為下一個即將接收的分段序號沒有到達32bit的最大值，所以不會出現(xiàn)回繞，則發(fā)送方此時只能是重發(fā)1-2**30內的序號分段，那么此時接收方就能輕易判斷出此時發(fā)來的分段都是重復的old分段


通過上面分析，我們就可以自然得出window scale option的因子最大只能是14bit了


再次感謝eexplorer的熱心幫助！





[ 本帖最后由 jiufei19 于 2010-1-20 12:14 編輯 ]

hritian

好繞。
滑動窗口一定要是2的冪次方嗎？

jiufei19

我也不想這么繞，真希望大家能指出我是否分析有誤哈

渣渣鳥

不錯，有真的研究精神。

學習。

eexplorer

原帖由 hritian 于 2010-1-20 22:00 發(fā)表
好繞。
滑動窗口一定要是2的冪次方嗎？

應該這么說，實際用的滑動窗口的大小并不一定是2^n。但是我們是在討論最大允許的滑動窗口的大小，因為window scale option是一個shift count，
所以最大是64K << 16 = 2^32，接下來就是64K << 15 = 2 ^31...

而jiufei19的分析已經排除了2^32, 2^31兩種情況。

我前面一直沒完全同意jiufei19的結論也就是和你有一樣的疑問，今天突然想到了原因

jiufei19

就是說，在討論“最大取值”這個前提下，那么根據(jù)上面的分析，32，31均不可能，則只有30才是最大可能值了

kutong

如果在一個MSL內發(fā)送了3.5G數(shù)據(jù)呢?接收方1G的窗口內還是可能有可能收到重發(fā)的序號為1的數(shù)據(jù),照樣分不清是新是舊.只要是快速的網(wǎng)絡,必須引入時間戳才能解決問題.
2**31的問題參考 tcp/ip詳解 卷2 24章,這些序號的比較是用補碼來實現(xiàn)的,補碼有一些很好的數(shù)學特性.

watson100

回復 21# jiufei19


這有一個地方不明白，想請教一下。


d）因為發(fā)送方一直沒有收到ACK，所以此時發(fā)送方可能超時然后重發(fā)認為丟失的那些分段，這些分段的序號從0-2**31-1不妨設為seq=0，那么問題就產生了，這個seq=0的分段對于接收方而言到底是old還是new？

我的理解是：這個時候接收方的窗口是從2**31--2*32-1，并不包含0的呀，所以對seq=0是直接丟棄呀。

uiojkl227

回復 26# jiufei19


   
請問下，tcp sender在ack.syn宣告了win=0，在什么情況下sender不會發(fā)送window update報文呢？三次握手建立完畢。

發(fā)現(xiàn)timestamps的值如下

Timestamps: TSval 0, TSecr 0

是否會導致此問題呢？

bluememery10

序號空間是2^31次方的問題，是由于tcp的序號比較方式，
參考《TCP/IP詳解 卷二》 第24章 24.7 TCP的序號

通過序號比較來確定給定序號是新序號或重傳序號。而比較a和b的序號大小 通過 a-b =a+(b的補碼)運算，計算結果按有符號數(shù)判斷，如果b位于a后面2^31范圍內，結果為負，如果b位于a前面2^31范圍內，結果為證，結果為負，說明a小于b，是新序號則接收，結果是正則是舊序號丟棄。
留有一半空間也可以緩解序號回繞問題，但網(wǎng)絡足夠快的話還是會回繞，解決回繞是通過時間戳來做。