TCP的擁塞控制

Love&Share發表於2021-01-05

1.引言

       計算機網路中的頻寬、交換結點中的快取和處理機等,都是網路的資源。在某段時間,若對網路中某一資源的需求超過了該資源所能提供的可用部分,網路的效能就會變壞。這種情況就叫做擁塞。

       擁塞控制就是防止過多的資料注入網路中,這樣可以使網路中的路由器或鏈路不致過載。擁塞控制是一個全域性性的過程,和流量控制不同,流量控制指點對點通訊量的控制。

2.慢開始與擁塞避免

       傳送方維持一個叫做擁塞視窗cwndcongestion window的狀態變數。擁塞視窗的大小取決於網路的擁塞程度,並且動態地在變化。傳送方讓自己的傳送視窗等於擁塞視窗,另外考慮到接受方的接收能力,傳送視窗可能小於擁塞視窗。

       慢開始演算法的思路就是,不要一開始就傳送大量的資料,先探測一下網路的擁塞程度,也就是說由小到大逐漸增加擁塞視窗的大小。

       這裡用報文段的個數的擁塞視窗大小舉例說明慢開始演算法,實時擁塞視窗大小是以位元組為單位的。如下圖:

       當然收到單個確認但此確認多個資料包的時候就加相應的數值。所以一次傳輸輪次之後擁塞視窗就加倍。這就是乘法增長,和後面的擁塞避免演算法的加法增長比較。

       為了防止cwnd增長過大引起網路擁塞,還需設定一個慢開始門限ssthresh狀態變數。ssthresh的用法如下:

cwnd<ssthresh時,使用慢開始演算法。

cwnd>ssthresh時,改用擁塞避免演算法。

cwnd=ssthresh時,慢開始與擁塞避免演算法任意。

       擁塞避免演算法讓擁塞視窗緩慢增長,即每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd1,而不是加倍。這樣擁塞視窗按線性規律緩慢增長。

       無論是在慢開始階段還是在擁塞避免階段,只要傳送方判斷網路出現擁塞(其根據就是沒有收到確認,雖然沒有收到確認可能是其他原因的分組丟失,但是因為無法判定,所以都當做擁塞來處理),就把慢開始門限設定為出現擁塞時的傳送視窗大小的一半。然後把擁塞視窗設定為1,執行慢開始演算法。如下圖:

      再次提醒這裡只是為了討論方便而將擁塞視窗大小的單位改為資料包的個數,實際上應當是位元組。

3.快重傳和快恢復

       快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認(為的是使傳送方及早知道有報文段沒有到達對方)而不要等到自己傳送資料時捎帶確認。快重傳演算法規定,傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段,而不必繼續等待設定的重傳計時器時間到期。如下圖:

快重傳配合使用的還有快恢復演算法,有以下兩個要點:

①當傳送方連續收到三個重複確認時,就執行“乘法減小”演算法,把ssthresh門限減半。但是接下去並不執行慢開始演算法。

②考慮到如果網路出現擁塞的話就不會收到好幾個重複的確認,所以傳送方現在認為網路可能沒有出現擁塞。所以此時不執行慢開始演算法,而是將cwnd設定為ssthresh的大小,然後執行擁塞避免演算法。如下圖:

4.隨機早期檢測RED

       以上的擁塞避免演算法並沒有和網路層聯絡起來,實際上網路層的策略對擁塞避免演算法影響最大的就是路由器的丟棄策略。在簡單的情況下路由器通常按照先進先出的策略處理到來的分組。當路由器的快取裝不下分組的時候就丟棄到來的分組,這叫做尾部丟棄策略。這樣就會導致分組丟失,傳送方認為網路產生擁塞。更為嚴重的是網路中存在很多的TCP連線,這些連線中的報文段通常是複用路由路徑。若發生路由器的尾部丟棄,可能影響到很多條TCP連線,結果就是這許多的TCP連線在同一時間進入慢開始狀態。這在術語中稱為全域性同步。全域性同步會使得網路的通訊量突然下降很多,而在網路恢復正常之後,其通訊量又突然增大很多。

       為避免發生網路中的全域性同步現象,路由器採用隨機早期檢測(RED:randomearly detection)。該演算法要點如下:

       使路由器的佇列維持兩個引數,即佇列長隊最小門限min和最大門限max,每當一個分組到達的時候,RED就計算平均佇列長度。然後分情況對待到來的分組:

①平均佇列長度小於最小門限——把新到達的分組放入佇列排隊。

②平均佇列長度在最小門限與最大門限之間——則按照某一概率將分組丟棄。

③平均佇列長度大於最大門限——丟棄新到達的分組。

      以概率p隨機丟棄分組,讓擁塞控制只在個別的TCP連線上執行,因而避免全域性性的擁塞控制。

       RED的關鍵就是選擇三個引數最小門限、最大門限、丟棄概率和計算平均佇列長度。平均佇列長度採用加權平均的方法計算平均佇列長度,這和往返時間(RTT)的計算策略是一樣的。

相關文章