TCP 滑動視窗協議

tcp的滑動視窗協議是；以位元組為單位的。現假設a收到

b發來的確認報文段，其中視窗是

20，而確認號是

31，這個資訊表明，接收方希望接受的資料是

31號資料，所以也就代表我們

31號之前的資料都已經正確接收了，我們也不必在傳送快取中為它們保留了，視窗可以向前滑動，我們根據這些確認報文裡的資訊可以構造我們的滑動視窗。

我們傳送視窗裡的資料都是可以傳送出去的，但是傳送視窗裡沒有收到確認的資料還必須保留下來，防止需要重傳。

根據觀察，我們也不難發現，我們的滑動視窗越大，在沒有收到確認的情況下，可以傳送的資料就越多，這個視窗的大小不僅僅和接收方的接收能力有關，還和網路的狀況有關，可能網路情況不太好的話，我們還有考慮擁塞視窗。

傳送視窗是由前沿和後沿共同決定的。傳送視窗後沿可以不動或者前移。不動，是因為發出去的資料，一直沒有收到確認，向前移動是傳送的資料收到了確認，就不需要再為他繼續儲存了。而傳送視窗的後沿可以前移，可以不動，也可以後退。前移是，可能我們的視窗沒變，然後收到了確認的資料，視窗整理向前移動了，也有可能是我們雖然沒有收到確認資料，但是我們接收方的所給報文段裡視窗增大了。而前沿不動有可能有兩種情況，是視窗大小不變，但是我們未收到任何確認，還有一種情況是收到了確認，但是視窗變小了，所以沒動。前沿也有可能後退，就是對方通知視窗變小了，這一般強烈不建議這樣，因為可能在調整之前，要把原來可以傳送的值傳送了，但是這時候視窗又變小了，可能會有錯誤發生。

這幅圖中我們可以看到，管理我們的傳送視窗需要三個指標。我們可以看一看它們劃定部分的意義。

p3-p1=a的傳送視窗；

p2-p1=已傳送但是未收到確認的位元組數；、

p3-p2=允許傳送但是尚未傳送的位元組數；

觀察上圖我們可以發現，我們的a中，有

31-41

的資料已經傳送但是沒有收到確認，而我們的可用視窗在減小。而在我們的b中，

32、33沒有按序到達，所以，

b只能給按序到達資料的最高序號給出確認，因此

b發確認號的時候，它還是只能發

31號。假設我們已經按序到達了，

31-33

，然後發出了

34的確認，我們的傳送視窗會向前移動

3個，因為我們收到確認就不必為它保留了。

a這時可以繼續傳送的範圍是42到

53。a繼續傳送完

42-53

後，指標p2和

p3重合。傳送視窗內的序號都已用完，但還沒有收到確認。所以

a的可用視窗已經減小到

0，因此必須停止傳送。

我們網路可能存在這種情況，a的資料全部正確到達了，但是

b的確認滯留在了網路中。在沒有手打

b的確認的時候，

a不能猜測：「或許

b收到了把！」為了確保可靠傳輸，

a只能認為

b還沒有收到這些資料。於是，

a在經過一段時間後就重傳這些資料，重新設定超時計時器，知道收到

b的確認位置。如果

a收到確認號落在傳送視窗內，那麼

a就可以使傳送視窗繼續向前滑動，並傳送新的資料。

可以發現，傳送方的引用程序把位元組流寫入tcp的傳送快取，接收方的應用程序從

tcp的接收快取中讀取位元組流。我們可以討論一下視窗和快取的關係。

傳送快取用來暫時存放：

1）傳送應用程式傳送給傳送方tcp準備傳送的資料；

2）tcp已傳送出單尚未收到確認的資料；

傳送視窗通常只是傳送快取的一部分。已被確認的資料應當從傳送快取中刪除，因此傳送快取和傳送視窗的後沿是重合的。傳送應用程式最後寫入傳送快取的位元組減去最後被確認的位元組，就是還保留在傳送快取中的被寫入的位元組數。傳送應用程式必須控制寫入快取的速率

，不能太快，否則傳送快取就會沒有存放資料的空間。

再看一下b圖的接收方的情況

1）按序到達的，單尚未被接收方應用程式讀取的資料；

2）未按序到達的資料；

如果收到的分組別檢測出有差錯，則樣丟棄。如果接受應用程式來不及讀取收到的資料，接受快取就會被填滿，使接受視窗減小到0.泛指，如果接受應用程式能夠及時從接受快取中讀取收到的資料，接收視窗就可以增大，但最大不能超過接收快取的大小。

TCP 滑動視窗協議

TCP 滑動視窗協議

TCP 滑動視窗協議

TCP 滑動視窗協議

相關推薦