選擇重傳協議的滑動窗口大小為什麼必須小於或等於序號空間大小的一半？

12-28

先說傳統的方式，最大是1/4。考慮新舊鑒別的問題，對每個方向，TCP在任何時候都將序號空間一分為二，可能接收的數據範圍只能佔有一半的序號空間，留下另一半來防止過期數據造成干擾：之前的數據包可能因為網路原因而被複制然後再次收到，之前重傳的數據也會因為延遲而在不該收到的時候收到，必須防止它們造成干擾。
現在發送方發出了一整個window的數據，接收方合併回復了一個ack，接下來有兩種情況：發送方收到ack，則發送[wnd，2*wnd -1]之間的數據，由於網路可能亂序，接收方必須能接收這範圍內任意一個序號；發送方沒有收到ack，則會重新發送[0，wnd - 1]之間的數據，接收方必須在收到這些數據時立即重新ack。因此接收方接受範圍是[0，2wnd - 1]。這整個範圍不能超過序號空間一半，所以窗長最大只能是1/4。
SACK沒仔細研究過，真的可以到1/2嗎……如果可以的話，大概是不允許窗口滑動吧，只能整窗長移動，如果整個一幀完成的ack丟了，就等ack重傳？有時間研究吧。

//僅針對選擇重傳協議而言
我們可以不將序號空間分開看看到底會發生什麼
假設n取3,2的三次方為8,序號空間即0~7
S:sender R:receiver

S 發送了0,1,2,3,4,5,6 號幀
R 接受上述幀並且捎帶發送 ACK of 6,但是丟失了
S的0號幀首先超時，S 重發發送0號幀
R收到0號幀，但是因為之前它已經接受0~6,發送了ACK of 6，它會認為0號幀是一個新的幀，而在0號幀之前的一個7號幀丟失。因為是選擇重傳協議，R會接受0號幀( the old)作為新幀(暫時放在緩存區)，並通過發送NAK of 7通知S重發7號幀。
S 發送7號幀
R接受了7和0號幀，並且發送ACK of 0

這就出現了問題：1、R接受錯誤的0號幀作為新的幀 2、S在發送完7號幀之後收到了ACK of 0，而不是ACK of 7，此時對於S而言，它的0號幀早已在ACK of 6中確認。

出現這個問題的主要原因是我們不能區別新舊幀，現在我們將序號空間一分為二，首先發送0~3，繼續走上面的步驟。走到步驟4.的時候R不會接受0作為新幀，因為R知道新的幀是4而不是0。這樣就避免了上面的問題。
僅僅避免這個問題其實怎麼分是都是可以的，我們可以將序號空間三等分，四等分。。。，但是為了儘可能利用資源，均分為兩個部分最佳。

為了說清楚這個問題，先給出以下兩點結論：

1. 幀序號重複使用，但是相同序號內容不同。

2. 發送窗口小於等於接收窗口。

因為發送窗口大於接收窗口部分的幀不能被接收，所以發送窗口大於接收窗口沒有意義，故取發送窗口等於接收窗口。
—————————————————————————分割線————————————————————————
現在以3比特編碼幀序號為例進行解釋，則相應的幀序號為0、1、2、3、4、5、6、7。假設發送窗口為6接收窗口也為6，則發送方可發送序號為0到5的幀，若接收方全部正確接收了這6個幀，並發送了相應的確認幀，則接收方的接收窗口理應更新為6、7、0、1、2、3。
如果確認幀被接收方正確地接收，則可以正確進行下一次傳輸。
如果確認幀全部丟失，發送方收不到確認幀，則發送方就會在超時後重傳序號為0到5的幀，而此時接收方的接收窗口已經更新，對於新接收到的序號為0、1、2、3的數據幀接收方無法區分是新的數據幀還是舊的數據幀，此時出現二義性。
所以為了避免這種情況，應該令發送窗口為4，即使確認幀全部丟失，接收窗口和發送窗口也不會重疊。
—————————————————————————分割線————————————————————————
所以當採用n比特編碼幀序號時，發送窗口的大小最大為2的n-1次方，這樣既保障了傳輸效率又不會產生二義性。