一、流量控制（滑動視窗協議）

 1、流量控制是管理兩端的流量，以免會產生髮送過塊導致收端溢位，或者因收端處理太快而浪費時間的狀態。用的是：滑動視窗，以位元組為單位

2、視窗有3種動作：展開（右邊向右），合攏（左邊向右），收縮（右邊向左）這三種動作受接收端的控制。

合攏：表示已經收到相應位元組的確認了

展開：表示允許快取傳送更多的位元組

收縮（非常不希望出現的，某些實現是禁止的）：表示本來可以傳送的，現在不能傳送；但是如果收縮的是那些已經發出的，就會有問題；為了避免，收端會等待到快取中有更多快取空間時才進行通訊。

發端視窗的大小取決於收端的視窗大小rwnd（TCP報文的視窗大小欄位）和擁塞視窗大小cwnd（見擁塞控制）

發端視窗大小 = min{ rwnd , cwnd };

3、關閉視窗：視窗縮回有個例外，就是傳送rwnd=0表示暫時不願意接收資料。這種情況下，發端不是把視窗收縮，二是停止傳送資料。（為了比避免死鎖，會用一些探測報定時傳送試探，見定時器一節）

4、問題：某些時候，由於發端或收端的資料很慢，會引起大量的1位元組資料痛惜，浪費很多資源。

（1）、發端的程序產生資料很慢時候，時不時的來個1位元組資料，那麼TCP就會1位元組1位元組的傳送，效率很低。

解決方法（Nagle演算法）：

a、將第一塊資料發出去

b、然後等到傳送快取有足夠多的資料（最大報文段長度），或者等到收端確認的ACK時再發送資料。

c、重複b的過程

（2）、收端程序由於消耗資料很慢，所以可能會有這麼一種情況，收端會發送其視窗大小為1的資訊，然後有是1位元組的傳輸

解決辦法（2種）

a、Clark方法：在接收快取的一半變空，或者有足夠空間放最大報文長度之前，宣告接收視窗大小為0

b、推遲確認：在對收到的報文段確認之前等待到足夠的接收快取，或者等待到一個時間段（現在一般定義500ms）

二、滑動視窗機制

(1).視窗機制
    滑動視窗協議的基本原理就是在任意時刻，傳送方都維持了一個連續的允許傳送的幀的序號，稱為傳送視窗；同時，接收方也維持了一個連續的允許接收的幀的序號，稱為接收視窗。傳送視窗和接收視窗的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動視窗協議視窗大小一般不同。傳送方視窗內的序列號代表了那些已經被髮送，但是還沒有被確認的幀，或者是那些可以被髮送的幀。下面舉一個例子（假設傳送視窗尺寸為2，接收視窗尺寸為1）：

   分析：①初始態，傳送方沒有幀發出，傳送視窗前後沿相重合。接收方0號視窗開啟，等待接收0號幀；②傳送方開啟0號視窗，表示已發出0幀但尚確認返回資訊。此時接收視窗狀態不變；③傳送方開啟0、1號視窗，表示0、1號幀均在等待確認之列。至此，傳送方開啟的視窗數已達規定限度，在未收到新的確認返回幀之前，傳送方將暫停傳送新的資料幀。接收視窗此時狀態仍未變；④接收方已收到0號幀，0號視窗關閉，1號視窗開啟，表示準備接收1號幀。此時傳送視窗狀態不變；⑤傳送方收到接收方發來的0號幀確認返回資訊，關閉0號視窗，表示從重發表中刪除0號幀。此時接收視窗狀態仍不變；⑥傳送方繼續傳送2號幀，2號視窗開啟，表示2號幀也納入待確認之列。至此，傳送方開啟的視窗又已達規定限度，在未收到新的確認返回幀之前，傳送方將暫停傳送新的資料幀，此時接收視窗狀態仍不變；⑦接收方已收到1號幀，1號視窗關閉，2號視窗開啟，表示準備接收2號幀。此時傳送視窗狀態不變；⑧傳送方收到接收方發來的1號幀收畢的確認資訊，關閉1號視窗，表示從重發表中刪除1號幀。此時接收視窗狀態仍不變。

    若從滑動視窗的觀點來統一看待1位元滑動視窗、後退n及選擇重傳三種協議，它們的差別僅在於各自視窗尺寸的大小不同而已。1位元滑動視窗協議：傳送視窗=1，接收視窗=1；後退n協議：發視窗>1，接收視窗>1；選擇重傳協議：傳送視窗>1,接收視窗>1。

(2).1位元滑動視窗協議

    當傳送視窗和接收視窗的大小固定為1時，滑動視窗協議退化為停等協議（stop－and－wait）。該協議規定傳送方每傳送一幀後就要停下來，等待接收方已正確接收的確認（acknowledgement）返回後才能繼續傳送下一幀。由於接收方需要判斷接收到的幀是新發的幀還是重新發送的幀，因此傳送方要為每一個幀加一個序號。由於停等協議規定只有一幀完全傳送成功後才能傳送新的幀，因而只用一位元來編號就夠了。其傳送方和接收方執行的流程圖如圖所示。

(3).後退n協議

    由於停等協議要為每一個幀進行確認後才繼續傳送下一幀，大大降低了通道利用率，因此又提出了後退n協議。後退n協議中，傳送方在發完一個數據幀後，不停下來等待應答幀，而是連續傳送若干個資料幀，即使在連續傳送過程中收到了接收方發來的應答幀，也可以繼續傳送。且傳送方在每傳送完一個數據幀時都要設定超時定時器。只要在所設定的超時時間內仍收到確認幀，就要重發相應的資料幀。如：當傳送方傳送了N個幀後，若發現該N幀的前一個幀在計時器超時後仍未返回其確認資訊，則該幀被判為出錯或丟失，此時傳送方就不得不重新發送出錯幀及其後的N幀。

   從這裡不難看出，後退n協議一方面因連續傳送資料幀而提高了效率，但另一方面，在重傳時又必須把原來已正確傳送過的資料幀進行重傳（僅因這些資料幀之前有一個數據幀出了錯），這種做法又使傳送效率降低。由此可見，若傳輸通道的傳輸質量很差因而誤位元速率較大時，連續測協議不一定優於停止等待協議。此協議中的傳送視窗的大小為k，接收視窗仍是1。

(4).選擇重傳協議

    在後退n協議中，接收方若發現錯誤幀就不再接收後續的幀，即使是正確到達的幀，這顯然是一種浪費。另一種效率更高的策略是當接收方發現某幀出錯後，其後繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方仍可收下來，存放在一個緩衝區中，同時要求傳送方重新傳送出錯的那一幀。一旦收到重新傳來的幀後，就可以原已存於緩衝區中的其餘幀一併按正確的順序遞交高層。這種方法稱為選擇重發(SELECTICE REPEAT)，其工作過程如圖所示。顯然，選擇重發減少了浪費，但要求接收方有足夠大的緩衝區空間。

三、TCP滑動視窗（Sliding Window）

滑動視窗協議可以用圖四來形象表示。

圖中我們已經將位元組進行了1到11的編號。由接收者通告的視窗稱為提議視窗（offered window），它覆蓋了第4到第9個位元組，意味著接收方已經確認了第3位元組之前（包括第3位元組）的資料，並且通告視窗的大小是6。視窗大小與確認的順序號（acknowledged sequence number）有關。傳送者計算它的可用視窗（usable window），用以度量它可以立即傳送多少資料。

隨著接收者對收到資料的確認，滑動視窗隨時向右移動。視窗兩端的相關運動增加或減少著視窗大小。我們使用3個術語來描述視窗邊緣（edge）的左右運動。

1．              當視窗左邊緣靠近右邊緣時稱視窗閉合（window closes）。視窗閉合發生在資料已經發送並被確認的情況下。

2．              當視窗右邊緣向右移動時稱視窗開啟（window opens）。視窗打開發生在另一端的接收程序讀取已確認資料的時候，它釋放了TCP接收緩衝區的空間。

3．              當視窗右邊緣向左移動時稱視窗收縮（window shrinks）。Host Requirement RFC強烈不鼓勵這種做法，但TCP必須能夠在一端發生這種情況時進行處理。

     圖五表示了這三個術語。由於視窗的左邊緣是受從連線另一端收到的確認號來控制的，因此它不會向左移動。如果收到一個ACK要求將左邊緣向左移動，那麼它是一個重複的（duplicate）的確認，並被丟棄。

如果視窗左邊緣重合了右邊緣，就稱它為零視窗（zero window）。它將停止傳送者傳輸任何資料。

示例

圖六顯示了圖一資料傳輸中TCP滑動視窗的動態變化

以此圖為例，我們可以總結幾個要點：

1．  傳送者不必傳送滿視窗大小的資料。

2．  收到接收者對資料的確認後，視窗向右滑動。這是由於視窗大小與確認順序號相關。

3．  從段7到段8的變化，可以看出視窗可以減小，但視窗右邊緣不能向左移動。

4．  接收者不必等待視窗被填滿才傳送確認。在許多實現中，接收者每收到兩個段傳送一個確認。