TCP流量控制和擁塞控制
轉自：https://www.cnblogs.com/wxgblogs/p/5616829.html
RED不是等到已經發生擁塞後才把所有隊列尾部的分組全部丟棄，而是在檢測到網絡擁塞的早期征兆時（即路由器的平均隊列長度超過一定門限值時），以概率p隨機丟棄分組，讓擁塞控制只在個別的TCP連接上執行，因而避免全局性的擁塞控制。
RED的關鍵就是選擇三個參數最小門限、最大門限、丟棄概率和計算平均隊列長度。最小門線必須足夠大，以保證路由器的輸出鏈路有較高的利用率。而最大門限和最小門限只差也應該足夠大，是的在一個TCP往返時間RTT中隊列的正常增長仍在最大門限之內。經驗證明：使最大門限等於最小門限的二倍是合適的。
TCP的流量控制
所謂的流量控制就是讓發送方的發送速率不要太快，讓接收方來得及接受。利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制。TCP的窗口單位是字節，不是報文段，發送方的發送窗口不能超過接收方給出的接收窗口的數值。
如圖所示，說明了利用可變窗口大小進行流量控制。設主機A向主機B發送數據。雙方確定的窗口值是400.再設每一個報文段為100字節長，序號的初始值為seq=1,圖中的箭頭上面大寫ACK，表示首部中的卻認為為ACK，小寫ack表示確認字段的值。
接收方的主機B進行了三次流量控制。第一次把窗口設置為rwind=300，第二次減小到rwind=100最後減到rwind=0，即不允許發送方再發送過數據了。這種使發送方暫停發送的狀態將持續到主機B重新發出一個新的窗口值為止。
假如，B向A發送了零窗口的報文段後不久，B的接收緩存又有了一些存儲空間。於是B向A發送了rwind=400的報文段，然而這個報文段在傳送中丟失 了。A一直等待收到B發送的非零窗口的通知，而B也一直等待A發送的數據。這樣就死鎖了。為了解決這種死鎖狀態，TCP為每個連接設有一個持續計時器。只 要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器，若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶1字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
TCP報文段發送時機的選擇
TCP的擁塞控制
1.擁塞控制的原理 在某段時間，若對網絡中的某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變化，這種情況叫做擁塞。網絡擁塞往往是由許多因素引起的，簡單的提高節點處理機的速度或者擴大結點緩存的存儲空間並不能解決擁塞問題。擁塞問題的是指往往是整個系統的各個部分不匹配，只有各個部分平衡了，問題才會得到解決。 2.擁塞控制和流量控制的差別 所謂擁塞控制就是防止過多的數據註入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網絡能承受現有的網絡負荷。擁塞問題是一個全局性的問題,涉及到所有的主機、所有的路由器、以及與降低網絡傳輸性能有關的所有因素。流量控制往往指的是點對點通信量的控制，是個端到端的問題。流量控制所要做的就是控制發送端發送數據的速率，以便使接收端來得及接受。 3.擁塞控制設計 擁塞控制是很難設計的，因為它是一個動態的問題，許多情況下，甚至正是擁塞控制機制本身成為引起網絡性能惡化甚至死鎖的原因。從控制理論的角度來看擁塞控制這個問題，可以分為開環控制和閉環控制兩種方法。開環控制就是在設計網絡時事先將有關擁塞發生的所有因素考慮周到，一旦系統運行起來就不能在中途改正。 閉環控制是基於反饋環路的概念，包括如下措施： 1）監測網路系統以便檢測擁塞在何時、何地發生 2）把擁塞發生的信息傳送到可采取行動的地方 3）調整網絡系統的行動以解決出現的問題。 4.擁塞控制方法 因特網建議標準RFC2581定義了進行擁塞控制的四種算法，即慢開始（Slow-start)、擁塞避免（Congestion Avoidance)、快重傳（Fast Restrangsmit)和快回復（Fast Recovery）。我們假定 1）數據是單方向傳送，而另外一個方向只傳送確認 2）接收方總是有足夠大的緩存空間，因為發送窗口的大小由網絡的擁塞程度來決定。慢開始和擁塞避免
發送方維持一個叫做擁塞窗口cwnd（congestion window）的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，並且動態地在變化。發送方讓自己的發送窗口等於擁塞窗口，另外考慮到接受方的接收能力，發送窗口可能小於擁塞窗口。發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就增大一些，以便把更多的分組發送出去。但是只要網絡出現擁塞，擁塞窗口就減小一些，以減少註入到網絡的分組數。
慢開始算法的思路就是：最初的TCP在連接建立成功後會向網絡中發送大量的數據包，這樣很容易導致網絡中路由器緩存空間耗盡，從而發生擁塞。因此新建立的連接不能夠一開始就大量發送數據包，而只能根據網絡情況逐步增加每次發送的數據量，以避免上述現象的發生。具體來說，當新建連接時，cwnd初始化為1個最大報文段(MSS)大小，發送端開始按照擁塞窗口大小發送數據，每當有一個報文段被確認，cwnd就增加至多1個MSS大小。用這樣的方法來逐步增大擁塞窗口CWND。
這裏用報文段的個數的擁塞窗口大小舉例說明慢開始算法，實時擁塞窗口大小是以字節為單位的。如下圖：
為了防止cwnd增長過大引起網絡擁塞，還需設置一個慢開始門限ssthresh狀態變量。ssthresh的用法如下：
當cwnd<ssthresh時，使用慢開始算法。
當cwnd>ssthresh時，改用擁塞避免算法。
當cwnd=ssthresh時，慢開始與擁塞避免算法任意。
擁塞避免算法思路：讓擁塞窗口緩慢增長，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口按線性規律緩慢增長。
無論是在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認，雖然沒有收到確認可能是其他原因的分組丟失，但是因為無法判定，所以都當做擁塞來處理），就把慢開始門限設置為出現擁塞時的發送窗口大小的一半。然後把擁塞窗口設置為1，執行慢開始算法。這樣做的目的就是要迅速減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。
乘法減小和加法增大
乘法減小：是指不論在慢開始階段還是擁塞避免階段，只要出現超時，就把慢開始門限減半，即設置為當前的擁塞窗口的一半（於此同時，執行慢開始算法）。當網絡出現頻繁擁塞時，ssthresh值就下降的很快，以大大將小註入到網絡中的分組數。
加法增大：是指執行擁塞避免算法後是擁塞窗口緩慢增大，以防止網絡過早出現擁塞。
快重傳和快恢復
一條TCP連接有時會因等待重傳計時器的超時而空閑較長的時間，慢開始和擁塞避免無法很好的解決這類問題，因此提出了快重傳和快恢復的擁塞控制方法。快重傳算法並非取消了重傳機制，只是在某些情況下更早的重傳丟失的報文段（如果當發送端接收到三個重復的確認ACK時，則斷定分組丟失，立即重傳丟失的報文段，而不必等待重傳計時器超時）。 快重傳要求接收方在收到一個失序的報文段後就立即發出重復確認（為的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。如下圖：
快重傳配合使用的還有快恢復算法，有以下兩個要點:
①當發送方連續收到三個重復確認時，就執行“乘法減小”算法，把ssthresh門限減半。但是接下去並不執行慢開始算法。
②考慮到如果網絡出現擁塞的話就不會收到好幾個重復的確認，所以發送方現在認為網絡可能沒有出現擁塞。所以此時不執行慢開始算法，而是將cwnd設置為ssthresh減半後的大小，然後執行擁塞避免算法。如下圖：
在采用快恢復算法時，慢開始算法只是在TCP連接建立時和網絡出現超時時才使用。
接受窗口又稱為通知窗口。因此從接收方對發送方的流量控制角度考慮，發送方的發送窗口一定不能超過對方給出的接受窗口的RWND。
也就是說：發送窗口的上限=Min[rwnd,cwnd].
隨機早期檢測RED
以上的擁塞避免算法並沒有和網絡層聯系起來，實際上網絡層的策略對擁塞避免算法影響最大的就是路由器的丟棄策略。在簡單的情況下路由器通常按照先進先出的策略處理到來的分組。當路由器的緩存裝不下分組的時候就丟棄到來的分組，這叫做尾部丟棄策略。這樣就會導致分組丟失，發送方認為網絡產生擁塞。更為嚴重的是網絡中存在很多的TCP連接，這些連接中的報文段通常是復用路由路徑。若發生路由器的尾部丟棄，可能影響到很多條TCP連接，結果就是這許多的TCP連接在同一時間進入慢開始狀態。這在術語中稱為全局同步。全局同步會使得網絡的通信量突然下降很多，而在網絡恢復正常之後，其通信量又突然增大很多。
為避免發生網路中的全局同步現象，路由器采用隨機早期檢測(RED:randomearly detection)。該算法要點如下：
使路由器的隊列維持兩個參數，即隊列長隊最小門限min和最大門限max，每當一個分組到達的時候，RED就計算平均隊列長度。然後分情況對待到來的分組：
①平均隊列長度小於最小門限——把新到達的分組放入隊列排隊。
②平均隊列長度在最小門限與最大門限之間——則按照某一概率將分組丟棄。
③平均隊列長度大於最大門限——丟棄新到達的分組。
RED不是等到已經發生擁塞後才把所有隊列尾部的分組全部丟棄，而是在檢測到網絡擁塞的早期征兆時（即路由器的平均隊列長度超過一定門限值時），以概率p隨機丟棄分組，讓擁塞控制只在個別的TCP連接上執行，因而避免全局性的擁塞控制。
RED的關鍵就是選擇三個參數最小門限、最大門限、丟棄概率和計算平均隊列長度。最小門線必須足夠大，以保證路由器的輸出鏈路有較高的利用率。而最大門限和最小門限只差也應該足夠大，是的在一個TCP往返時間RTT中隊列的正常增長仍在最大門限之內。經驗證明：使最大門限等於最小門限的二倍是合適的。
平均隊列長度采用加權平均的方法計算平均隊列長度，這和往返時間（RTT）的計算策略是一樣的。
轉自：https://www.cnblogs.com/wxgblogs/p/5616829.html
TCP流量控制和擁塞控制