http://blog.csdn.net/liuchen1206/article/details/8599542

什麼是滑動視窗協議？ 

   一圖勝千言，看下面的圖。簡單解釋下，傳送和接受方都會維護一個數據幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目的在於控制傳送速度，以免接受方的快取不夠大，而導致溢位，同時控制流量也可以避免網路擁塞。下面圖中的4,5,6號資料幀已經被髮送出去，但是未收到關聯的ACK，7,8,9幀則是等待發送。可以看出傳送端的視窗大小為6，這是由接受端告知的（事實上必須考慮擁塞視窗cwnd，這裡暫且考慮cwnd>rwnd）。此時如果傳送端收到4號ACK，則視窗的左邊緣向右收縮，視窗的右邊緣則向右擴充套件，此時視窗就向前“滑動了”，即資料幀10也可以被髮送。

二：傳送方開啟0號視窗，表示已發出0幀但尚確認返回資訊。 此時接收視窗狀態不變；
 三：傳送方開啟0、1號視窗，表示0、1號幀均在等待確認之列。至此，傳送方開啟的視窗數已達規定限度，在未收到新的確認返回幀之前，傳送方將暫停傳送新的資料幀。接收視窗此時狀態仍未變；
  四：接收方已收到0號幀，0號視窗關閉，1號視窗開啟，表示準備接收1號幀。此時傳送視窗狀態不變；
 五：傳送方收到接收方發來的0號幀確認返回資訊，關閉0號視窗，表示從重發表中刪除0號幀。此時接收視窗狀態仍不變
  六：傳送方繼續傳送2號幀，2號視窗開啟，表示2號幀也納入待確認之列。至此，傳送方開啟的視窗又已達規定限度，在未收到新的確認返回幀之前，傳送方將暫停傳送新的資料幀，此時接收視窗狀態仍不變；
 七：接收方已收到1號幀，1號視窗關閉，2號視窗開啟，表示準備接收2號幀。此時傳送視窗狀態不變；
  八：傳送方收到接收方發來的1號幀收畢的確認資訊，關閉1號視窗，表示從重發表中刪除1號幀。此時接收視窗狀態仍不變。

1位元滑動視窗協議?
 

  上面說的只是滑動視窗協議的理論，實際應用中又有不同。首先就是停等協議(stop－and－wait)，這時接受方的視窗和傳送方的視窗大小都是1，1個位元就夠表示了，所以也叫1位元滑動視窗協議。傳送方這時自然傳送每次只能傳送一個，並且必須等待這個資料包的ACK，才能傳送下一個。雖然在效率上比較低，頻寬利用率明顯較低，不過在網路環境較差，或是頻寬本身很低的情況下，還是適用的。看下面的流程圖：

  停等協議雖然實現簡單，也能較好的適用惡劣的網路環境，但是顯然效率太低。所以有了後退n協議，這也是滑動視窗協議真正的用處，這裡傳送的視窗大小為n，接受方的視窗仍然為1。具體看下面的圖，這裡假設n=9：
   首先發送方一口氣傳送10個數據幀，前面兩個幀正確返回了，資料幀2出現了錯誤，這時傳送方被迫重新發送2-8這7個幀，接受方也必須丟棄之前接受的3-8這幾個幀。
   後退n協議的好處無疑是提高了效率，但是一旦網路情況糟糕，則會導致大量資料重發，反而不如上面的停等協議，實際上這是很常見的，具體可以參考TCP擁塞控制。

選擇重傳協議？
   後退n協議的另外一個問題是，當有錯誤幀出現後，總是要重發該幀之後的所有幀，毫無疑問在網路不是很好的情況下會進一步惡化網路狀況，重傳協議便是用來解決這個問題。原理也很簡單，接收端總會快取所有收到的幀，當某個幀出現錯誤時，只會要求重傳這一個幀，只有當某個序號後的所有幀都正確收到後，才會一起提交給高層應用。重傳協議的缺點在於接受端需要更多的快取。

擁塞控制的物件？ 
   擁塞的原因是負載過大，控制的物件自然是傳送者的流量，TCP中用於控制流量的是滑動視窗協議。視窗的大小取決於對端通告的接收視窗(rwnd)和擁塞控制視窗，即真正的傳送視窗=min(rwnd,cwnd)

慢啟動？ 
   最初的TCP在連線建立成功後會向網路中傳送大量的資料包，這樣很容易導致網路中路由器快取空間耗盡，從而發生擁塞。因此新建立的連線不能夠一開始就大量傳送資料包，而只能根據網路情況逐步增加每次傳送的資料量，以避免上述現象的發生。具體來說，當新建連線時，cwnd初始化為1個最大報文段(MSS)大小，傳送端開始按照擁塞視窗大小發送資料，每當有一個報文段被確認，cwnd就增加1個MSS大小。這樣cwnd的值就隨著網路往返時間(Round TripTime,RTT)呈指數級增長，事實上，慢啟動的速度一點也不慢，只是它的起點比較低一點而已。我們可以簡單計算下： 
  開始          --->    cwnd = 1 
  經過1個RTT後  --->    cwnd = 2*1 = 2 
  經過2個RTT後  --->    cwnd = 2*2= 4 
  經過3個RTT後  --->    cwnd = 4*2 = 8 
如果頻寬為W，那麼經過RTT*log2W時間就可以佔滿頻寬

擁塞避免? 
   從慢啟動可以看到，cwnd可以很快的增長上來，從而最大程度利用網路頻寬資源，但是cwnd不能一直這樣無限增長下去，一定需要某個限制。TCP使用了一個叫慢啟動門限(ssthresh)的變數，當cwnd超過該值後，慢啟動過程結束，進入擁塞避免階段。對於大多數TCP實現來說，ssthresh的值是65536(同樣以位元組計算)。擁塞避免的主要思想是加法增大，也就是cwnd的值不再指數級往上升，開始加法增加。此時當視窗中所有的報文段都被確認時，cwnd的大小加1，cwnd的值就隨著RTT開始線性增加，這樣就可以避免增長過快導致網路擁塞，慢慢的增加調整到網路的最佳值。

如何檢測擁塞？ 
   首先來看TCP是如何確定網路進入了擁塞狀態的，TCP認為網路擁塞的主要依據是它重傳了一個報文段。上面提到過，TCP對每一個報文段都有一個定時器，稱為重傳定時器(RTO)，當RTO超時且還沒有得到資料確認，那麼TCP就會對該報文段進行重傳，當發生超時時，那麼出現擁塞的可能性就很大，某個報文段可能在網路中某處丟失，並且後續的報文段也沒有了訊息，在這種情況下，TCP反應比較“強烈”： 
   1.把ssthresh降低為cwnd值的一半 
   2.把cwnd重新設定為1 
   3.重新進入慢啟動過程。 
從整體上來講，TCP擁塞控制視窗變化的原則是AIMD原則，即加法增大、乘法減小。可以看出TCP的該原則可以較好地保證流之間的公平性，因為一旦出現丟包，那麼立即減半退避，可以給其他新建的流留有足夠的空間，從而保證整個的公平性。

滑動視窗的單位是位元組，但是每傳送的幀是多個位元組的，根據擁賽視窗來定，為了提高速度，TCP並沒有按照位元組單個傳送而是將資料流劃分為片段。片段內所有位元組都是一起傳送和接收的，因此也是一起確認的。確認機制沒有采用message ID欄位，而是使用的片段內最後一個位元組的sequence number。因此一次可以處理不同的位元組數，這一數量即為片段內的sequence number

TCP/ip的流量控制
1. 利用滑動視窗實現流量控制
    如果傳送方把資料傳送得過快，接收方可能會來不及接收，這就會造成資料的丟失。所謂流量控制就是讓傳送方的傳送速率不要太快，要讓接收方來得及接收。
    利用滑動視窗機制可以很方便地在TCP連線上實現對傳送方的流量控制。
    設A向B傳送資料。在連線建立時，B告訴了A：“我的接收視窗是 rwnd = 400 ”(這裡的 rwnd 表示 receiver window) 。因此，傳送方的傳送視窗不能超過接收方給出的接收視窗的數值。請注意，TCP的視窗單位是位元組，不是報文段。TCP連線建立時的視窗協商過程在圖中沒有顯示出來。再設每一個報文段為100位元組長，而資料報文段序號的初始值設為1。大寫ACK表示首部中的確認位ACK，小寫ack表示確認欄位的值ack。

    從圖中可以看出，B進行了三次流量控制。第一次把視窗減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最後減到 rwnd = 0 ，即不允許傳送方再發送資料了。這種使傳送方暫停傳送的狀態將持續到主機B重新發出一個新的視窗值為止。B向A傳送的三個報文段都設定了 ACK = 1 ，只有在ACK=1時確認號欄位才有意義。
    TCP為每一個連線設有一個持續計時器(persistence timer)。只要TCP連線的一方收到對方的零視窗通知，就啟動持續計時器。若持續計時器設定的時間到期，就傳送一個零視窗控測報文段（攜1位元組的資料），那麼收到這個報文段的一方就重新設定持續計時器。
2. 必須考慮傳輸速率
    可以用不同的機制來控制TCP報文段的傳送時機。如： <1>. TCP維持一個變數，它等於最大報文段長度MSS。只要快取中存放的資料達到MSS位元組時，就組裝成一個TCP報文段傳送出去。<2>. 由傳送方的應用程序指明要求傳送報文段，即TCP支援的推送( push )操作。<3>. 傳送方的一個計時器期限到了，這時就把已有的快取資料裝入報文段(但長度不能超過MSS)傳送出去。
    Nagle演算法：若傳送應用程序把要傳送的資料逐個位元組地送到TCP的傳送快取，則傳送方就把第一個資料位元組先發送出去，把後面到達的資料位元組都快取起來。當傳送方接收對第一個資料字元的確認後，再把傳送快取中的所有資料組裝成一個報文段再發送出去，同時繼續對隨後到達的資料進行快取。只有在收到對前一個報文段的確認後才繼續傳送下一個報文段。當資料到達較快而網路速率較慢時，用這樣的方法可明顯地減少所用的網路頻寬。Nagle演算法還規定：當到達的資料已達到 傳送視窗大小的一半或已達到報文段的最大長度時，就立即傳送一個報文段。
    另，糊塗視窗綜合證： TCP接收方的快取已滿，而互動式的應用程序一次只從接收快取中讀取1位元組（這樣就使接收快取空間僅騰出1位元組），然後向傳送方傳送確認，並把視窗設定為1個位元組（但傳送的資料報為40位元組的的話）。接收，傳送方又發來1個位元組的資料（傳送方的IP資料報是41位元組）。接收方發回確認，仍然將視窗設定為1個位元組。這樣，網路的效率很低。要解決這個問題，可讓接收方等待一段時間，使得或者接收快取已有足夠空間容納一個最長的報文段，或者等到接收方快取已有一半空閒的空間。只要出現這兩種情況，接收方就發回確認報文，並向傳送方通知當前的視窗大小。此外，傳送方也不要傳送太小的報文段，而是把資料報積累成足夠大的報文段，或達到接收方快取的空間的一半大小。
 
TCP的擁塞控制
1.  擁塞：即對資源的需求超過了可用的資源。若網路中許多資源同時供應不足，網路的效能就要明顯變壞，整個網路的吞吐量隨之負荷的增大而下降。
    擁塞控制：防止過多的資料注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提：網路能夠承受現有的網路負荷。擁塞控制是一個全域性性的過程，涉及到所有的主機、路由器，以及與降低網路傳輸效能有關的所有因素。
    流量控制：指點對點通訊量的控制，是端到端正的問題。流量控制所要做的就是抑制傳送端傳送資料的速率，以便使接收端來得及接收。
    擁塞控制代價：需要獲得網路內部流量分佈的資訊。在實施擁塞控制之前，還需要在結點之間交換資訊和各種命令，以便選擇控制的策略和實施控制。這樣就產生了額外的開銷。擁塞控制還需要將一些資源分配給各個使用者單獨使用，使得網路資源不能更好地實現共享。
2. 幾種擁塞控制方法
    慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復( fast recovery )。
2.1 慢開始和擁塞避免
    傳送方維持一個擁塞視窗 cwnd ( congestion window )的狀態變數。擁塞視窗的大小取決於網路的擁塞程度，並且動態地在變化。傳送方讓自己的傳送視窗等於擁塞。
    傳送方控制擁塞視窗的原則是：只要網路沒有出現擁塞，擁塞視窗就再增大一些，以便把更多的分組傳送出去。但只要網路出現擁塞，擁塞視窗就減小一些，以減少注入到網路中的分組數。
    慢開始演算法：當主機開始傳送資料時，如果立即所大量資料位元組注入到網路，那麼就有可能引起網路擁塞，因為現在並不清楚網路的負荷情況。因此，較好的方法是先探測一下，即由小到大逐漸增大發送視窗，也就是說，由小到大逐漸增大擁塞視窗數值。通常在剛剛開始傳送報文段時，先把擁塞視窗 cwnd 設定為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞視窗增加至多一個MSS的數值。用這樣的方法逐步增大發送方的擁塞視窗 cwnd ，可以使分組注入到網路的速率更加合理。

 
每經過一個傳輸輪次，擁塞視窗 cwnd 就加倍。一個傳輸輪次所經歷的時間其實就是往返時間RTT。不過“傳輸輪次”更加強調：把擁塞視窗cwnd所允許傳送的報文段都連續傳送出去，並收到了對已傳送的最後一個位元組的確認。
另，慢開始的“慢”並不是指cwnd的增長速率慢，而是指在TCP開始傳送報文段時先設定cwnd=1，使得傳送方在開始時只發送一個報文段（目的是試探一下網路的擁塞情況），然後再逐漸增大cwnd。
    為了防止擁塞視窗cwnd增長過大引起網路擁塞，還需要設定一個慢開始門限ssthresh狀態變數（如何設定ssthresh）。慢開始門限ssthresh的用法如下：
    當 cwnd < ssthresh 時，使用上述的慢開始演算法。
    當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法。
    當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞控制避免演算法。
擁塞避免演算法：讓擁塞視窗cwnd緩慢地增大，即每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd加1，而不是加倍。這樣擁塞視窗cwnd按線性規律緩慢增長，比慢開始演算法的擁塞視窗增長速率緩慢得多。
    無論在慢開始階段還是在擁塞避免階段，只要傳送方判斷網路出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設定為出現擁塞時的傳送方視窗值的一半（但不能小於2）。然後把擁塞視窗cwnd重新設定為1，執行慢開始演算法。這樣做的目的就是要迅速減少主機發送到網路中的分組數，使得發生擁塞的路由器有足夠時間把佇列中積壓的分組處理完畢。
    如下圖，用具體數值說明了上述擁塞控制的過程。現在傳送視窗的大小和擁塞視窗一樣大。

<1>. 當TCP連線進行初始化時，把擁塞視窗cwnd置為1。前面已說過，為了便於理解，圖中的視窗單位不使用位元組而使用報文段的個數。慢開始門限的初始值設定為16個報文段，即 cwnd = 16 。
<2>. 在執行慢開始演算法時，擁塞視窗 cwnd 的初始值為1。以後傳送方每收到一個對新報文段的確認ACK，就把擁塞視窗值另1，然後開始下一輪的傳輸（圖中橫座標為傳輸輪次）。因此擁塞視窗cwnd隨著傳輸輪次按指數規律增長。當擁塞視窗cwnd增長到慢開始門限值ssthresh時（即當cwnd=16時），就改為執行擁塞控制演算法，擁塞視窗按線性規律增長。
<3>. 假定擁塞視窗的數值增長到24時，網路出現超時（這很可能就是網路發生擁塞了）。更新後的ssthresh值變為12（即變為出現超時時的擁塞視窗數值24的一半），擁塞視窗再重新設定為1，並執行慢開始演算法。當cwnd=ssthresh=12時改為執行擁塞避免演算法，擁塞視窗按線性規律增長，每經過一個往返時間增加一個MSS的大小。
強調：“擁塞避免”並非指完全能夠避免了擁塞。利用以上的措施要完全避免網路擁塞還是不可能的。“擁塞避免”是說在擁塞避免階段將擁塞視窗控制為按線性規律增長，使網路比較不容易出現擁塞。

若從滑動視窗的觀點來統一看待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)，其工作過程如圖所示。顯然，選擇重發減少了浪費，但要求接收方有足夠大的緩衝區空間。