看到的覺得比較好的介紹滑動窗口算法的文章，轉載學習！
TCP協議作爲一個可靠的面向流的傳輸協議，其可靠性和流量控制由滑動窗口協議保證，而擁塞控制則由控制窗口結合一系列的控制算法實現。
一、滑動窗口協議
關於這部分自己不曉得怎麼敘述纔好，因爲理解的部分更多，下面就用自己的理解來介紹下TCP的精髓：滑動窗口協議。
所謂滑動窗口協議，自己理解有兩點：
1. “窗口”對應的是一段可以被髮送者發送的字節序列，其連續的範圍稱之爲“窗口”；
2. “滑動”則是指這段“允許發送的範圍”是可以隨着發送的過程而變化的，方式就是按順序“滑動”。在引入一個例子來說這個協議之前，我覺得很有必要先了解以下前提：
-1. TCP協議的兩端分別爲發送者A和接收者B，由於是全雙工協議，因此A和B應該分別維護着一個獨立的發送緩衝區和接收緩衝區，由於對等性（A發B收和B發A收），我們以A發送B接收的情況作爲例子；
-2. 發送窗口是發送緩存中的一部分，是可以被TCP協議發送的那部分，其實應用層需要發送的所有數據都被放進了發送者的發送緩衝區；
-3. 發送窗口中相關的有四個概念：已發送並收到確認的數據（不再發送窗口和發送緩衝區之內）、已發送但未收到確認的數據（位於發送窗口之中）、允許發送但尚未發送的數據以及發送窗口外發送緩衝區內暫時不允許發送的數據；
-4. 每次成功發送數據之後，發送窗口就會在發送緩衝區中按順序移動，將新的數據包含到窗口中準備發送；
TCP建立連接的初始，B會告訴A自己的接收窗口大小，比如爲‘20’：
節31-50爲發送窗口
A發送11個字節後，發送窗口位置不變，B接收到了亂序的數據分組：
只有當A成功發送了數據，即發送的數據得到了B的確認之後，纔會移動滑動窗口離開已發送的數據；同時B則確認連續的數據分組，對於亂序的分組則先接收下來，避免網絡重複傳遞：
二、流量控制
流量控制方面主要有兩個要點需要掌握。一是TCP利用滑動窗口實現流量控制的機制；二是如何考慮流量控制中的傳輸效率。
1. 流量控制
所謂流量控制，主要是接收方傳遞信息給發送方，使其不要發送數據太快，是一種端到端的控制。主要的方式就是返回的ACK中會包含自己的接收窗口的大小，並且利用大小來控制發送方的數據發送：
這裏面涉及到一種情況，如果B已經告訴A自己的緩衝區已滿，於是A停止發送數據；等待一段時間後，B的緩衝區出現了富餘，於是給A發送報文告訴A我的rwnd大小爲400，但是這個報文不幸丟失了，於是就出現A等待B的通知||B等待A發送數據的死鎖狀態。爲了處理這種問題，TCP引入了持續計時器（Persistence timer），當A收到對方的零窗口通知時，就啓用該計時器，時間到則發送一個1字節的探測報文，對方會在此時迴應自身的接收窗口大小，如果結果仍未0，則重設持續計時器，繼續等待。
- 傳遞效率
一個顯而易見的問題是：單個發送字節單個確認，和窗口有一個空餘即通知發送方發送一個字節，無疑增加了網絡中的許多不必要的報文（請想想爲了一個字節數據而添加的40字節頭部吧！），所以我們的原則是儘可能一次多發送幾個字節，或者窗口空餘較多的時候通知發送方一次發送多個字節。對於前者我們廣泛使用Nagle算法，即：
*1. 若發送應用進程要把發送的數據逐個字節地送到TCP的發送緩存，則發送方就把第一個數據字節先發送出去，把後面的字節先緩存起來；
*2. 當發送方收到第一個字節的確認後（也得到了網絡情況和對方的接收窗口大小），再把緩衝區的剩餘字節組成合適大小的報文發送出去；
*3. 當到達的數據已達到發送窗口大小的一半或以達到報文段的最大長度時，就立即發送一個報文段；
三、擁塞控制
網絡中的鏈路容量和交換結點中的緩存和處理機都有着工作的極限，當網絡的需求超過它們的工作極限時，就出現了擁塞。擁塞控制就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。常用的方法就是：
1. 慢開始、擁塞控制
2. 快重傳、快恢復
一切的基礎還是慢開始，這種方法的思路是這樣的：
-1. 發送方維持一個叫做“擁塞窗口”的變量，該變量和接收端口共同決定了發送者的發送窗口；
-2. 當主機開始發送數據時，避免一下子將大量字節注入到網絡，造成或者增加擁塞，選擇發送一個1字節的試探報文；
-3. 當收到第一個字節的數據的確認後，就發送2個字節的報文；
-4. 若再次收到2個字節的確認，則發送4個字節，依次遞增2的指數級；
-5. 最後會達到一個提前預設的“慢開始門限”，比如24，即一次發送了24個分組，此時遵循下面的條件判定：
*1. cwnd < ssthresh， 繼續使用慢開始算法；
*2. cwnd > ssthresh，停止使用慢開始算法，改用擁塞避免算法；
*3. cwnd = ssthresh，既可以使用慢開始算法，也可以使用擁塞避免算法；
-6. 所謂擁塞避免算法就是：每經過一個往返時間RTT就把發送方的擁塞窗口+1，即讓擁塞窗口緩慢地增大，按照線性規律增長；
-7. 當出現網絡擁塞，比如丟包時，將慢開始門限設爲原先的一半，然後將cwnd設爲1，執行慢開始算法（較低的起點，指數級增長）；
上述方法的目的是在擁塞發生時循序減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠的時間把隊列中積壓的分組處理完畢。慢開始和擁塞控制算法常常作爲一個整體使用，而快重傳和快恢復則是爲了減少因爲擁塞導致的數據包丟失帶來的重傳時間，從而避免傳遞無用的數據到網絡。快重傳的機制是：
-1. 接收方建立這樣的機制，如果一個包丟失，則對後續的包繼續發送針對該包的重傳請求；
-2. 一旦發送方接收到三個一樣的確認，就知道該包之後出現了錯誤，立刻重傳該包；
-3. 此時發送方開始執行“快恢復”算法：
*1. 慢開始門限減半；
*2. cwnd設爲慢開始門限減半後的數值；
*3. 執行擁塞避免算法（高起點，線性增長）；
http://blog.chinaunix.net/uid-26275986-id-4109679.html
(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)，其工作過程如圖所示。顯然，選擇重發減少了浪費，但要求接收方有足夠大的緩衝區空間。
