TCP傳輸流量控制和擁塞避免方案

先來了解2個TCP的概念：

MSS：Maximum Segment Size，TCP一次傳輸發(fā)送的最大數(shù)據(jù)段長度。

RTT：Round-Trip Time，往返時延，表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的確認（接收端收到數(shù)據(jù)后便立即發(fā)送確認），總共經(jīng)歷的時延。

TCP傳輸大塊數(shù)據(jù)時，肯定需要進行數(shù)據(jù)分段，而每個分段所能攜帶的最大數(shù)據(jù)就是1個MSS，假設大塊數(shù)據(jù)為100個MSS，那么發(fā)送方發(fā)送的方式大概有如下兩種：

1、 每次發(fā)送1個，收到接收方確認后，才發(fā)送下1個；

2、 一口氣發(fā)送100個，然后收到對方一起確認；

顯然，方式1中，一個RTT只能處理一個包，這樣的傳輸效率太低了。而方式2看似很美好，實際會存在兩個問題，一個是接收方的接收窗口未必能一次性接收這么多數(shù)據(jù)，另外一個是網(wǎng)絡的帶寬也不一定足夠大，容易出現(xiàn)丟包事故。前一個問題就是標題中的流量控制(Flow control)，TCP采用的是滑動窗口機制(Sliding window)，后一個問題就是標題中的擁塞控制(Congestion control)。發(fā)送方的發(fā)送窗口或者說網(wǎng)絡傳輸交互就取決于這兩個問題的控制，誰控制的更嚴格，誰就占據(jù)了決定性因素，這也是為什么兩者總是一起出現(xiàn)一起被討論。

流量控制(Flow control):

TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to receive and process it reliably. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate.

TCP使用端到端流量控制協(xié)議來避免發(fā)送方發(fā)送數(shù)據(jù)太快，以致TCP接收方不能可靠地接收和處理數(shù)據(jù)。在不同網(wǎng)絡速度的機器進行通信的環(huán)境中，具有流量控制機制至關重要。

圖一

圖一為通過Wireshark抓包192.168.2.1和192.168.2.198的交互截圖，可以看到有個標記Win，這個標記的含義就是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)。于是發(fā)送端就可以根據(jù)這個接收端的處理能力來發(fā)送數(shù)據(jù)，而不會導致接收端處理不過來。

[TCP zerowindow]& [TCP window Full]

提到Win標記，就順便談一下Wireshark的[TCP zerowindow]和[TCP window Full]，當Win=0時，Wireshark就會打上TCP zerowindow，表示緩存區(qū)已滿，不能再接收數(shù)據(jù)了。當Wireshark在一個包上打上TCP window Full，就表示這個包的發(fā)送方已經(jīng)把對方聲明的接收窗口耗盡了。兩者的共同特點都是傳輸暫停，前者的含義是發(fā)送方無法再接收數(shù)據(jù)，后者表示發(fā)送方無法再發(fā)送數(shù)據(jù)。

回過頭來再來說滑動窗口。

圖二截取自《TCP/IP詳解》

圖三取自參考資料

圖四取自參考資料

圖二和圖三可以知道接收方會通知發(fā)送方當前已接收到的信息和可用窗口信息。

圖三和圖四可以看出來窗口滑動的過程。

總結：TCP的流量控制由滑動窗口來實現(xiàn)的，滑動窗口控制流量取決于接收方的窗口大小。

擁塞控制(Congestion control):

流量控制是端到端的交互，如果只是局域網(wǎng)內(nèi)的兩臺設備交互，我想通過滑動窗口大概能控制得不差，但是實際網(wǎng)絡的情況非常復雜，發(fā)送方和接收方之間還有路由器和交換機，網(wǎng)絡傳輸線路又復雜，這個時候就需要擁塞控制。

擁塞控制主要有四個算法：慢啟動、擁塞避免、快速重傳和快速恢復。

慢啟動：

討論慢啟動算法先來了解下?lián)砣翱诘母拍?，這是慢啟動算法為TCP發(fā)送方新增的窗口，congestion window，簡稱cwnd。對應上文，發(fā)送方取擁塞窗口和滑動窗口的最小值作為發(fā)送上限，即誰嚴格誰起決定因素。

1、 連接建立開始，發(fā)送方不了解網(wǎng)絡的情況，cwnd初始化比較小的值，RFC建議2-4個MSS，具體視MSS的大小而定；

If (MSS <= 1095 bytes)

then win <= 4 * MSS;

If (1095 bytes < MSS < 2190 bytes)

then win <= 4380;

If (2190 bytes <= MSS)

then win <= 2 * MSS; 摘自rfc3390.

2、 如果發(fā)送出去的包都被ACK，說明還未到達擁塞點，則增加擁塞窗口，RFC建議的是每收到n個ACK，則cwnd新增n個MSS，呈指數(shù)關系增長，雖然這個過程看似比較快，但是基數(shù)比較低，所以被稱為“慢啟動”。

擁塞避免：

其實慢啟動除了維護了cwnd，還維護了慢啟動臨界值ssthresh，一般將ssthresh設置為65535字節(jié)。在cwnd<=ssthresh時，還是處于慢啟動環(huán)節(jié)，一旦>ssthresh，開始進入擁塞避免。

RFC建議擁塞避免環(huán)節(jié)，無論一個RTT可以收到多少個ACK，每一次確認都只新增1個MSS，呈線性關系增長，避免快速的觸碰到網(wǎng)絡擁塞點。

圖五取自參考資料

快速重傳和快速恢復：

進入擁塞避免之后，最終還是會碰到擁塞點，發(fā)送方此時遲遲得不到確認，當然得不到確認也有可能是因為延遲確認導致的。發(fā)送方此時決定等待一段時間，如果一段時間后還是得不到確認，就發(fā)起重傳，這個過程叫做超時重傳。從發(fā)出原始包到重傳該包的時間叫做RTO(Retransmission TimeOut)。

進入超時重傳后，RFC建議將cwnd設置為1個MSS，而對于ssthresh，RFC5681建議的是發(fā)生擁塞時未被ACK的數(shù)據(jù)量的1/2，但必須大于等于2個MSS。然后重新進入慢啟動環(huán)節(jié)。超時重傳因為需要等待RTO之后才能進入新的恢復環(huán)節(jié)，所以對網(wǎng)絡性能的影響是比較大的。所以各路大神又想到了一個新的方式，看能否無需等待RTO，就發(fā)起重傳，這種方式叫做快速重傳。快速重傳規(guī)定在收到3個及以上重復ACK時就觸發(fā)重傳，不再進入慢啟動環(huán)節(jié)，然后直接進入擁塞避免，這個就是快速恢復算法。為什么是3個？因為1-2個重復ACK，很有可能是亂序，只有在3個及以上的時候才是有可能丟包了。
編輯：hfy