ARQ與滑動窗口概念
滑動窗口協議，是TCP使用的一種流量控制方法。該協議允許發送方在停止並等待確認前可以連續發送多個分組。由於發送方不必每發一個分組就停下來等待確認，因此該協議可以加速數據的傳輸。
自動重傳請求（Automatic
Repeat-reQuest，ARQ）是OSI模型中數據鏈路層的錯誤糾正協議之一。它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的信息傳輸。如果發送方在發送後一段時間之內沒有收到確認幀，它通常會重新發送。ARQ可能包括停止等待ARQ協議、回退ARQ和連續ARQ協議，錯誤檢測（Error
Detection）、正面確認（Positive Acknowledgment）、超時重傳（Retransmission after Timeout）和 負面確認及重傳（Negative Acknowledgment and Retransmission）等機制。
他們的概念是差不多的只是作用於不同的網絡層。數據鏈路層的滑動窗口是“個數固定”的。而TCP的滑動窗口是“個數可變”的，可以由接收端設置WIN字段來修改。
傳統自動重傳請求分成爲三種，即停等式(stop-and-wait）ARQ，回退n幀（go-back-n）ARQ，以及選擇性重傳（selective repeat）ARQ。後兩種協議是滑動窗口技術與請求重發技術的結合，由於窗口尺寸開到足夠大時，幀在線路上可以連續地流動，因此又稱其爲連續ARQ協議。三者的區別在於對於出錯的數據報文的處理機制不同。三種ARQ協議中，複雜性遞增，效率也遞增。除了傳統的ARQ，還有混合ARQ（Hybrid-ARQ）。
當發送窗口和接收窗口的大小都等於 1時，就是停止等待協議。
停止並等待ARQ協議(stop-and-wait)
停止並等待協議的工作原理如下：
- 發送點對接收點發送數據包，然後等待接收點回復ACK並且開始計時。
- 在等待過程中，發送點停止發送新的數據包。
- 當數據包沒有成功被接收點接收時候，接收點不會發送ACK. 這樣發送點在等待一定時間後，重新發送數據包。
- 反覆以上步驟直到收到從接收點發送的ACK.
發送點的等待時間應當至少大於傳輸點數據包發送時間（數據包容量除以發送點傳輸速度），接收點ACK接收時間（ACK容量除以接收點傳輸速度），數據在連接上的傳送時間，接收點檢驗接收數據是否正確的時間之和。在實際應用當中，等待時間是這個和的2到3倍。
這個協議的缺點是較長的等待時間導致低的數據傳輸速度。在低速傳輸時，對連接頻道的利用率比較好，但是在高速傳輸時，頻道的利用率會顯著下降。
回退n幀的ARQ
在回退n幀的ARQ中，當發送方接收到接收方的狀態報告指示報文出錯後，發送方將重傳過去的n個報文。 回退N，發送窗口大於1，接收窗口等於1。允許發送方可以連續發送信息幀，但是，一旦某幀發生錯誤，必須重新發送該幀及其後的n幀。這種方式提高了信道的利用率，但允許已發送有待於確認的幀越多，可能要退回來重發的幀也越多。回退的基本原理圖：
如果當前發送的是數據鏈路層上的最後一個幀（無論是數據幀還是確認幀），但不幸的是該幀出錯或丟失了，此種情況也適用於中間某一幀開始的所有後繼幀全部出錯或丟失的情況（同樣可以是數據幀或確認幀），那麼發送端會一直等待下去，而且接收端對此也毫無察覺。
爲了解決這個問題，需要採用超時機制。可以有多種定時方案，在早期方案中採用的一種是獨立的定時器，發送端每發送一個數據幀就啓動一次，當收到確認幀後，定時器復位；如果直到超時還沒有收到確認幀，則重發該幀以及後繼的幀。
其原理如圖下所示：
連續ARQ協議(Continuous ARQ)
爲了克服停止並等待ARQ協議長時間等待ACK的缺點。這個協議會連續發送一組數據包，然後再等待這些數據包的ACK.
連續 ARQ 協議的工作原理圖：
如圖所示，結點 A 向結點 B 發送數據幀。當結點 A 發完 0 號幀後，不是停止等待，而是繼續發送後續的 1 號幀、2 號幀等。由於連續發送了許多幀，所以應答幀不僅要說明是對哪一幀進行確認或否認，而且應答幀本身也必須編號。
結點 B 正確地收到了 0 號幀和 1 號幀，並送交其主機。現在設 2 號幀出了差錯，於是結點 B 就將有差錯的 2 號幀丟棄。結點 B 運行的協議可以有兩種選擇：一種是在出現差錯時就向結點 A 發送否認幀，另一種則是在出現差錯時不做任何響應。我們現在假定採用後一種協議，這種協議比較簡單，使用得較多。
選擇重傳 (Selective Repeat)
- 發送點連續發送數據包但對每個數據包都設有個一個計時器。
- 當在一定時間內沒有收到某個數據包的ACK時，發送點只重新發送那個沒有ACK的數據包
這個方法的缺點是接收點收到的數據包的順序可能不是發送的數據包順序。因此在數據包裏必須含有順序字符來幫助接受點來排序。
- 接收點丟棄從第一個沒有收到的數據包開始的所有數據包。
- 發送點收到NACK後，從NACK中指明的數據包開始重新發送
這個辦法的問題是如何正確選擇表明數據包的順序字符的數量。這個數量因當包括ACK或者ACK從接收點到達發送點的時間。
滑動窗口
TCP滑動窗口用來暫存兩臺計算機間要傳送的數據分組。每臺運行TCP協議的計算機有兩個滑動窗口：一個用於數據發送，另一個用於數據接收。發送端待發數據分組在緩衝區排隊等待送出。被滑動窗口框入的分組，是可以在未收到接收確認的情況下最多送出的部分。滑動窗口左端標誌X的分組，是已經被接收端確認收到的分組。隨着新的確認到來，窗口不斷向右滑動。
TCP協議軟件依靠滑動窗口機制解決傳輸效率和流量控制問題。它可以在收到確認信息之前發送多個數據分組。這種機制使得網絡通信處於忙碌狀態，提高了整個網絡的吞吐率，它還解決了端到端的通信流量控制問題，允許接收端在擁有容納足夠數據的緩衝之前對傳輸進行限制。在實際運行中，TCP滑動窗口的大小是可以隨時調整的。收發端TCP協議軟件在進行分組確認通信時，還交換滑動窗口控制信息，使得雙方滑動窗口大小可以根據需要動態變化，達到在提高數據傳輸效率的同時，防止擁塞的發生。
稱窗口左邊沿向右邊沿靠近爲窗口合攏，這種現象發生在數據被髮送和確認時。當窗口右邊沿向右移動時將允許發送更多的數據，稱之爲窗口張開。這種現象發生在另一端的接收進程讀取已經確認的數據並釋放了TCP的接收緩存時。
當右邊沿向左移動時，稱爲窗口收縮。Host Requirements RFC強烈建議不要使用這種方式。但TCP必須能夠在某一端產生這種情況時進行處理。 如果左邊沿到達右邊沿，則稱其爲一個零窗口。
滑動窗口原理圖：
在這個圖中，我們將字節從1至11進行標號。接收方通告的窗口稱爲提出的窗口，它覆蓋了從第4字節到第9字節的區域，表明接收方已經確認了包括第3字節在內的數據，且通告窗口大小爲6。我們知道窗口大小是與確認序號相對應的。發送方計算它的可用窗口，該窗口表明多少數據可以立即被髮送。當接收方確認數據後，這個滑動窗口不時地向右移動。窗口兩個邊沿的相對運動增加或減少了窗口的大小。我們使用三個術語來描述窗口左右邊沿的運動：
-
稱窗口左邊沿向右邊沿靠近爲窗口合攏。這種現象發生在數據被髮送和確認時。
-
當窗口右邊沿向右移動時將允許發送更多的數據，我們稱之爲窗口張開。這種現象發生在另一端的接收進程讀取已經確認的數據並釋放了T C P的接收緩存時。
- 當右邊緣向左移動時，稱之爲窗口收縮。
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、推遲確認：在對收到的報文段確認之前等待到足夠的接收緩存，或者等待到一個時間段