一、視窗機制的分類

在TCP協議當中視窗機制分為兩種：

1.固定的視窗大小

2.滑動視窗

二、固定視窗存在的問題

如下圖所示：

我們假設這個固定視窗的大小為1，也就是每次只能傳送一個數據，只有接收方對這個資料進行了確認後才能傳送第二個資料。在圖中我們可以看到，傳送方每傳送一個數據接收方就要給傳送方一個ACK對這個資料進行確認。只有接收了這個確認資料以後傳送方才能傳輸下個數據。

存在的問題：如果視窗過小，當傳輸比較大的資料的時候需要不停的對資料進行確認，這個時候就會造成很大的延遲。

                    如果視窗過大，我們假設傳送方一次傳送100個數據，但接收方只能處理50個數據，這樣每次都只對這50個數據進行確認。傳送方下一次還是傳送100個數據，但接受方還是隻能處理50個數據。這樣就避免了不必要的資料來擁塞我們的鏈路。

因此，我們引入了滑動視窗

二、滑動視窗（以位元組為單位）

1.概述

    滑動視窗通俗來講就是一種流量控制技術。

    它本質上是描述接收方的TCP資料報緩衝區大小的資料，傳送方根據這個資料來計算自己最多能傳送多長的資料，如果傳送方收到接收方的視窗大小為0的TCP資料報，那麼傳送方將停止傳送資料，等到接收方傳送視窗大小不為0的資料報的到來

2.工作原理

第一次傳送資料這個時候的視窗大小是根據鏈路頻寬的大小來決定的。

假設這時候的視窗是3.這個時候接收方收到資料以後會對資料進行確認告訴哦傳送方我下次希望收到的資料是多少。

在上圖中：我們看到接收方傳送的ACK = 3（這是對傳送方傳送序列2的回答確認，下一次接收方期望接收到的是3序列訊號），這個時候傳送方收到這個資料以後就知道我第一次傳送的3個數據對方只收到了兩個，就知道第三個資料對方沒有收到，下次返送的時候就從第3個數據開始發。這時候視窗大小就變為了2.

如下圖所示：

看到接收方傳送的ACK是5就表示他下一次希望收到的資料是5，傳送方就知道我剛才傳送的2個數據對方收到了，這個時候開始傳送第5個數據。

*****當鏈路變好或者變差，這個視窗還會發生變化，並不是第一次協商好了以後就永遠不會變化了。

3.死鎖狀態

（1）概述：

    當接收端向傳送端傳送零視窗報文段後不久，接收端的接收快取又有了一些儲存空間，於是接收端向傳送端傳送了Windows size = 2的報文段，然而這個報文段在傳輸過程中丟失了。傳送端一直等待收到接收端傳送的非零視窗的通知，而接收端一直等待發送端傳送資料，這樣就死鎖了。

（2）解決方法

    TCP為每個連線設有一個持續計時器。只要TCP連線的一方收到對方的零視窗通知，就啟動持續計時器，若持續計時器設定的時間到期，就傳送一個零視窗探測報文段（僅攜帶1位元組的資料），而對方就在確認這個探測報文段時給出了現在的視窗值。

4.TCP報文段的傳送時機（傳輸效率問題）

可以用以下三種不同的機制控制TCP報文段的傳送時機：

（1）TCP維持一個變數MSS，等於最大報文段的長度。只要緩衝區存放的資料達到MSS位元組時，就組裝成了一個TCP報文段傳送出去

（2）由傳送方的應用程序指明要傳送的報文段，即：TCP支援推送操作

（3）傳送方的一個計時器期限到了，這時就把當前已有的快取資料裝入報文段（但長度不能超過MSS）傳送出去。

5.Nagle演算法（控制TCP報文段的傳送時機）

（1）主旨：避免大量傳送小包

（2）初衷：避免傳送大量的小包，防止小包氾濫於網路，在理想情況下，對於一個TCP連線而言，網路上每次只能有一個小包存在。它更多的是端到端意義上的優化

【CORK演算法：提高網路利用率，理想情況下，完全避免傳送小包，僅僅傳送滿包以及不得不發的小包】

    傳送方將第一個資料位元組傳送出去，把後面到達的資料位元組快取起來。當傳送方接收對第一個資料字元的確認後，再把傳送快取中的所有資料組裝成一個報文段再發送出去，同時繼續對隨後到達的資料進行快取。只有在收到對前一個報文段的確認之後，才繼續傳送下一個報文段。規定一個TCP連線最多隻能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能傳送其它的小分組。當資料到達較快而網路速率較慢時，用這樣的方法可以明顯的減少所用的網路頻寬。

    Nagle演算法還規定：當達到的資料已經達到傳送視窗大小的一半或者已經達到報文段的最大長度時，就可以立即傳送一個報文段。

6.糊塗視窗綜合症（接收端糊塗，網路上小包氾濫的原因之一）

（1）概述：

        TCP接收方的快取已滿，而互動式的應用程序一次只從接收快取區中讀取1位元組（這樣就使接收快取空間僅騰出1位元組），然後向傳送方傳送確認，並把視窗設定為1個位元組（但傳送的資料報為40位元組的話），然後，傳送方又發來1位元組的資料（傳送方的IP資料報是41位元組），接收方發回確認，仍將視窗設定為1個位元組，這樣，網路效率就會很低

（2）解決辦法

        a.你糊塗我不糊塗法。即Nagle演算法。

         可讓接收方等待一段時間，使得或者  接收快取已有足夠的空間容納一個  最長的報文段，或者等到接收方快取已有一半的空閒空間。只要出現這兩種情況，接收方就發回確認報文，並向傳送方通知當前的視窗大小。此外，傳送方也不要傳送太小的報文段，而是把資料報文積累為足夠大的報文段或達到接收方快取的空間的一半大小。

            b.治療接收端的糊塗（其中一種機制是延遲ACK（還有其它機制，例如不傳送小視窗通告等））

               對於接收方而言， 延遲ACK可以拖延ACK傳送時間，進而延遲視窗通告，在這段時間內，接收視窗有機會進一步放大

               對於傳送方而言， 不理會接收端的小視窗通告等於說不馬上1傳送小包，小包有時間積累成大包