TCP慢啓動，擁塞控制，ECN 筆記

TCP慢啓動，擁塞控制，ECN 筆記

1，TCP慢啓動

TCP在鏈接過程的三次握手完成後，開始傳數據，並非一開始向網絡通道中發送大量的數據包，這樣很容易致使網絡中路由器緩存空間耗盡，從而發生擁塞；而是根據初始的cwnd大小逐步增長髮送的數據量，cwnd初始化爲1個最大報文段(MSS)大小（這個值可配置不必定是1個MSS）；每當有一個報文段被確認，cwnd大小指數增加。 
開始 —> cwnd = 1 
1個RTT後 —> cwnd = 2*1 = 2 
2個RTT後 —> cwnd = 2*2= 4 
3個RTT後 —> cwnd = 4*2 = 8

2，擁塞避免

cwnd不能一直這樣無限增加下去，必定須要某個限制。TCP使用了一個叫慢啓動門限(ssthresh)的變量，一旦cwnd>=ssthresh（大多數TCP的實現，一般大小都是65536），慢啓動過程結束，擁塞避免階段開始； 
擁塞避免：cwnd的值再也不指數級往上升，開始加法增長。此時當窗口中全部的報文段都被確認時，cwnd的大小加1，cwnd的值就隨着RTT開始線性增長，這樣就能夠避免增加過快致使網絡擁塞，慢慢的增長調整到網絡的最佳值。 
非ECN環境下的擁塞判斷，發送方RTO超時，重傳了一個報文段；

• 1，把ssthresh下降爲cwnd值的一半；
• 2，把cwnd從新設置爲1；
• 3，從新進入慢啓動過程。

3，快速重傳

快速重傳，TCP在收到重複的3次ACK時，會認爲重傳隊列中的第一個報文段被網絡丟棄，但因爲收到的重複的3次ACK，則認爲該報文段以後的三個報文已經被接收端收到，則不等待重傳定時器超時，直接重發重傳隊列中的第一個報文段。

• 1，把ssthresh設置爲cwnd的一半
• 2，把cwnd再設置爲ssthresh的值(具體實現有些爲ssthresh+3)
• 3，從新進入擁塞避免階段。

4，快速恢復

快速恢復的數據包守恆原則，即同一個時刻在網絡中的數據包數量恆定，「老」數據包離開後，才能向網絡中發送「新」的數據包。若是發送方收到一個重複的ACK，TCP的ACK機制就代表有一個數據包離開，此時cwnd加1。

• 1，當收到3個重複ACK時，把ssthresh設置爲cwnd的一半，把cwnd設置爲ssthresh的值加3，而後重傳丟失的報文段，加3的緣由是由於收到3個重複的ACK，代表有3個「老」的數據包離開了網絡。
• 2，再收到重複的ACK時，擁塞窗口增長1。
• 3，當收到新的數據包的ACK時，把cwnd設置爲第一步中的ssthresh的值。緣由是由於該ACK確認了新的數據，說明從重複ACK時的數據都已收到，該恢復過程已經結束，能夠回到恢復以前的狀態了，也即再次進入擁塞避免狀態。

5，ECN（Explicit Congestion Notification），WWDC 2017 再次提到

5.1，現有TCP在擁塞時出現的問題

非ECN環境下，在網絡中間路由器丟包時，TCP協議經過RTO超時來重傳丟失的包，保證數據可靠性。 
對於網絡鏈路中的路由器來講，當中間路由器隊列過載致使丟包後，各主機之間的TCP鏈接並不感知中間路由器的轉發隊列的忙閒狀態。而是在RTO定時器超時以後，因爲沒有收到ACK，開始重傳報文。而這個定時器的時間相對較長，一般從幾秒到幾十秒不等。報文丟棄致使多路TCP開始下降發送速率，甚至在一個窗口發送完畢以後，TCP的重傳定時器沒有超時以前，整個發送過程會偶爾停滯。在全部TCP下降性能以後，路由器的轉發隊列擁塞獲得緩解，再也不丟棄報文，全部TCP又會同時提升發送速率，到達必定程度以後，路由器又開始丟棄報文，並重復剛纔TCP的重傳過程。該現象的問題有：

• 一、丟包致使TCP重傳，該重傳定時器的時間較長，對時延敏感的應用來講，影響用戶感覺。
• 二、丟包以後，全部TCP開始進行退避，下調發送性能，擁塞獲得緩解，但此時的網絡利用率沒法達到最優。
• 三、在擁塞緩解以後，TCP爲了得到發送的最優性能，又繼續擴大發送窗口，直到發現丟包，重複上述問題過程。

5.2，中間路由器擁塞控制隊列

路由器的轉發隊列一般實現了RED功能，即路由器會根據當前隊列的平均長度來作丟包決策，並隨機丟棄一些TCP報文段，而不是等到隊列滿載，很好地避免了全部TCP同時超時的問題。

5.3，ECN設計

經過在TCP和IP首部的修改，能解決如下問題：

• 1，全部的TCP發送端儘快感知中間路徑的擁塞，主動減少cwnd；
• 2，對於在中間路由器中超過平均隊列長度的TCP報文進行ECN標記，並繼續進行轉發，不丟棄報文，避免了報文丟棄和發送端重傳；
• 3，因爲顯式的標識擁塞的發生，不用再等待RTO超時（時間比較長）再重發數據，提高了時延敏感應用的直觀感覺。
• 4，與非ECN網絡環境相比，網絡利用率更高，再也不是在過載和輕載之間來回震盪。

5.4，對IP和TCP首部的修改

IP首部的修改

 0  1  2  3  4  5  6 7
 +-----+-----+-----+-----+-----+-----+-----+-----+
 | DS FIELD, DSCP | ECN FIELD |
 +-----+-----+-----+-----+-----+-----+-----+-----+

 DSCP: differentiated services codepoint
 ECN: Explicit Congestion Notification
 The Differentiated Services and ECN Fields in IP.

 +-----+-----+
 | ECN FIELD |
 +-----+-----+
 ECT CE [Obsolete] RFC 2481 names for the ECN bits.
  0  0 Not-ECT
  0  1 ECT(1)
  1  0 ECT(0)
  1  1 CE

 The ECN Field in IP.

IP首部的TOS字段中的第7和8bit的res字段被從新定義爲ECN字段，其中有四個取值，在RFC3168中描述，00表明該報文並不支持ECN，因此路由器的將該報文按照原始非ECN報文處理便可，即，過載丟包。01和10這兩個值針對路由器來講是同樣的，都代表該報文支持ECN功能，若是發生擁塞，則ECN字段的這兩個將修改成11來表示報文通過了擁塞，並繼續被路由器轉發。針對01和10的具體區別請參考RFC3168。 
因此路由器轉發側要支持ECN，須要有如下新增功能：

• 一、 當擁塞發生時，針對ECN=00的報文，走原有普通非ECN流程，即，進行RED丟包。
• 二、 當擁塞發生時，針對ECN=01或ECN=10的報文，都須要修改成ECN=11，並繼續轉發流程。
• 三、 當擁塞發生時，針對ECN=11的報文，須要繼續轉發。
• 四、 爲了保證與不支持ECN報文的公平性，在隊列超過必定長度時，須要考慮對支持ECN報文的丟棄。

TCP首部的修改

0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  | | | C | E | U | A | P | R | S | F |
 | Header Length | Reserved | W | C | R | C | S | S | Y | I |
 | | | R | E | G | K | H | T | N | N |
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 CWR: Congestion Window Reduce
 ECE: ECN-Echo
 The new definition of bytes 13 and 14 of the TCP Header.

針對主機側的修改，首部將bit8和bit9的res字段修改成CWR和ECE。在RFC3168中的設計以下：

• 一、 在TCP接收端收到IP頭中的ECN=11標記，並在回覆ACK時將ECE bit置1。並在後續的ACK總均將ECE bit置1。
• 二、 在TCP發送端收到ECE bit置1的ACK報文時，須要將本身的發送速率減半，並在發送下一個報文時，將CWR bit置1。
• 三、 在接收端收到CWR bit置1的報文時，後續的ECE bit將再也不置1。直到再次收到IP首部ECN=11時，重複上述過程。
• 四、 TCP發送端在收到一個ECE=1時，縮小發送窗口，而且在本次RTT時間內將再也不再次縮小發送窗口。
• 五、 TCP接收端向發送端迴應ACK時，若是該ACK是一個不帶數據的「純」ACK，那麼必須IP首部ECN=00，由於TCP沒有機制對純ACK進行響應，就沒法針對純ACK發送擁塞通知。
• 六、 對於支持IP ECN的主機，TCP層在發送報文時須要將IP首部中的ECN置爲01或10。

總結

記錄和轉載別人的博客，加深記憶。

參考

• 《TCP/IP詳解，卷1：協議》
• http://blog.csdn.net/itmacar/article/details/12278769
• ECN：http://blog.csdn.net/xxx_500/article/details/8584323