TCP IP 滑動視窗

這樣的傳輸方式有乙個缺點：資料報的往返時間越長，通訊的效率就越低。

為解決這個問題，tcp 引入了視窗這個概念。即使在往返時間較長的情況下，它也不會降低網路通訊的效率。

那麼有了視窗，就可以指定視窗大小，視窗大小就是指無需等待確認應答，而可以繼續傳送資料的最大值。

視窗的實現實際上是作業系統開闢的乙個快取空間，傳送方主機在等到確認應答返回之前，必須在緩衝區中保留已傳送的資料。如果按期收到確認應答，此時資料就可以從快取區清除。

假設視窗大小為3個 tcp 段，那麼傳送方就可以「連續傳送」3個 tcp 段，並且中途若有 ack 丟失，可以通過「下乙個確認應答進行確認」。如下圖：

圖中的 ack 600 確認應答報文丟失，也沒關係，因為可以通過下乙個確認應答進行確認，只要傳送方收到了 ack 700 確認應答，就意味著 700 之前的所有資料「接收方」都收到了。這個模式就叫累計確認或者累計應答。

注意:

tcp 頭里有乙個欄位叫window，也就是視窗大小。

這個欄位是接收端告訴傳送端自己還有多少緩衝區可以接收資料。於是傳送端就可以根據這個接收端的處理能力來傳送資料，而不會導致接收端處理不過來。

所以，通常視窗的大小是由接收方的視窗大小來決定的。

傳送方傳送的資料大小不能超過接收方的視窗大小，否則接收方就無法正常接收到資料。

我們先來看看傳送方的視窗，下圖就是傳送方快取的資料，根據處理的情況分成四個部分，其中深藍色方框是傳送視窗，紫色方框是可用視窗：

在下圖，當傳送方把資料「全部」都一下傳送出去後，可用視窗的大小就為 0 了，表明可用視窗耗盡，在沒收到 ack 確認之前是無法繼續傳送資料了。

可用視窗耗盡

在下圖，當收到之前傳送的資料32~36位元組的 ack 確認應答後，如果傳送視窗的大小沒有變化，則滑動視窗往右邊移動 5 個位元組，因為有 5 個位元組的資料被應答確認，接下來52~56位元組又變成了可用視窗，那麼後續也就可以傳送52~56這 5 個位元組的資料了。

32 ~ 36 位元組已確認

tcp 滑動視窗方案使用三個指標來跟蹤在四個傳輸類別中的每乙個類別中的位元組。其中兩個指標是絕對指標（指特定的序列號），乙個是相對指標（需要做偏移）。

那麼可用視窗大小的計算就可以是：

可用視窗大 = snd.wnd -（snd.nxt - snd.una）

接下來我們看看接收方的視窗，接收視窗相對簡單一些，根據處理的情況劃分成三個部分：

其中三個接收部分，使用兩個指標進行劃分:

並不是完全相等，接收視窗的大小是約等於傳送視窗的大小的。

因為滑動視窗並不是一成不變的。比如，當接收方的應用程序讀取資料的速度非常快的話，這樣的話接收視窗可以很快的就空缺出來。那麼新的接收視窗大小，是通過 tcp 報文中的 windows 欄位來告訴傳送方。那麼這個傳輸過程是存在時延的，所以接收視窗和傳送視窗是約等於的關係。