TCP擁塞控制算法之NewReno和SACK
TCP擁塞控制算法之NewReno和SACK
2018年05月23日 19:10:03 吃吃愛學習 閱讀數：1446 版權聲明：程序媛吃吃的博客 https://blog.csdn.net/m0_38068229/article/details/80417503一、TCP Reno擁塞控制算法回顧
二、基於TCP Reno擁塞控制算法的改進
- 改進原因分析
TCP Reno 提出的快速恢復算法提高了丟失報文後的吞吐量和頑健性，但是：
僅考慮了每次擁塞發生時只丟失一個報文的情形。實際網絡中，一旦發生擁塞，路由器會丟棄大量的報文，即一次擁塞中丟失多個報文的情形很普遍。
下圖是Reno算法中快速恢復狀態和擁塞避免狀態之間的相互轉換：
- 一次擁塞中丟失多個報文時若采用Reno算法：（TCP Reno收到新的 ACK就會結束快速恢復，進入擁塞避免階段）
會多次將擁塞窗口（cwnd）和慢啟動閾值（ssthresh）減半，造成TCP的發送速率呈指數降低系統吞吐量急劇下降，（當發送窗口小於3時）無足夠的重復ACK可以觸發快速恢復，只能等待超時重傳。TCP Reno 終端會陷入僅通過傳輸超時來發現報文丟失的困境中。
- 超時對於TCP的效果有很大的影響：
- 若遺失的數據包無法使用Fast-Retransmit/ Fast-recovery重送，就必須等待超時來觸發重送的機制，在等待超時的這段時間，TCP不能重送新的數據，使得鏈路的使用率很低；
- 超時之後，cwnd的值會被重設為1，大大較低了TCP的傳輸效果。
所以，網絡在一次擁塞中丟棄了多個報文，被TCP Reno錯誤地分析為傳輸中發生了多次擁塞。過度的窗口減小導致了傳輸超時的發生。因此為了提高一次擁塞中丟棄多個報文情形下TCP的性能，必須使TCP終端減少盲目削減發送窗口的行為。
- New Reno：基於Reno算法的改進
NewReno TCP在Reno TCP的基礎上對快速恢復算法進行修改，只有一個數據包丟失的情況下，其機制和Reno是一樣的；當同時有多個包丟失時就顯示出了它的優勢。
Reno快速恢復算法中發送方收到一個新的ACK就退出快速恢復狀態，New Reno算法中只有當所有報文都被應答後才退出快速恢復狀態。
使TCP終端可以把一次擁塞丟失多個報文的情形與多次擁塞的情形區分開來，進而在每一次擁塞發生後擁塞窗口僅減半一次，從而提高了TCP的頑健性和吞吐量。
兩個概念：部分應答（PACK）、恢復應答（RACK）
記TCP發送端恢復階段中接收到的ACK報文（非冗余ACK）為ACKx，記在接收到ACKx時TCP終端已發出的序列號（SN）最大的報文是PKTy，如果ACKx不是PKTy的應答報文，則稱報文ACKx為部分應答（Partial ACK，簡稱PACK）；若ACKx恰好是PKTy的應答報文則稱報文ACKx為恢復應答（Recovery ACK，簡稱RACK）。
舉例來理解：
如果4、5、6號包丟了，現在只重傳4，只收到了4的ACK，後面的5、6沒有確認，這就是部分應答Partial ACK。如果收到了6的ACK，則是恢復應答Recovery ACK。
TCP發送端接收到恢復應答表明：經過重傳，TCP終端發送的所有報文都已經被接收端正確接收，網絡已經從擁塞中恢復。
NewReno發送端在收到第一個Partial ACK時，並不會立即結束Fast-recovery，而會持續地重送Partial ACK之後的數據包，直到將所有遺失的數據包重送後才結束Fast-recovery。收到一個Partial ACK時，重傳定時器就復位。這使得NewReno的發送端在網絡有大量數據包遺失時不需等待Timeout就能更正此錯誤，減少大量數據包遺失對傳輸效果造成的影響。
NewReno大約每一個RTT時間可重傳一個丟失的數據包，如果一個發送窗口有M個數據包丟失，TCP NewReno的快速恢復階段將持續M個RTT。
- 改進的快速恢復算法具體步驟：
- 重新定義恢復階段
- 進入恢復階段後，發送端重傳被認定為丟失的報文，設置慢啟動閾值（ssthresh）和擁塞窗口大小（cwnd）。ssthresh = cwnd/2，cwnd = ssthresh + 3MSS。
- 收到一個重復ACK，cwnd=cwnd+MSS。
- 當收到PACK（部分應答）時，發送端重傳PACK所確認報文的下一個報文，如果擁塞窗口允許，繼續發送新的數據包。
- 當收到RACK（確認應答）時，發送端認為擁塞中所有被丟棄的報文都已經被重傳，擁塞結束，設置cwnd=ssthresh並退出快速恢復狀態。
快速恢復是基於數據包守恒的原則，即同一時刻能在網絡中傳輸的數據包是恒定的，只有當舊數據包離開網絡後，才能發送新數據包進入網絡。一個重復ACK不僅意味著有一個包丟失了，還表示有發送的數據包離開了網絡，已經在接收區的緩沖區中，不再占用網絡資源，於是將擁塞窗口加一個數據包大小。
三、SACK算法
- Reno和NewReno算法仍存在的問題？
雖然NewReno可以解決大量數據包遺失的問題，但是NewReno在每個RTT時間只能一個數據包遺失的錯誤。為了更有效地處理大量數據包遺失的問題，另一個解決方法就是讓傳送端知道哪些已經被接收端收到，但用此方法必須同時修改傳送端和接收端的傳送機制。
缺乏SACK算法時發送端只能選擇兩種恢復策略：- 每一個RTT時間內至多重傳一個丟棄的包 (Reno和New Reno)
- 重傳所有包，其中包括可能已經正確發送的包。 (Tahoe)
TCP SACK在TCP Reno基礎上增加了：
- 選擇確認（Selective Acknowledgements，SACK）
- 選擇重傳（Selective Retransmission）
- 接收端：在ACK中報告其接收到的不連續的報文，使發送方準確地知道哪些數據包被接收方正確接收。
- 發送端：使用選擇重傳機制，可以在一個窗口中一次重傳所有從一個窗口中丟失的數據包。
減少了時延，提高了網絡吞吐量，使更快地從擁塞狀態恢復。
SACK中加入了一個SACK選項（TCP option field），允許接收端在返回Duplicate ACK時，將已經收到的數據區段（連續收到的數據範圍）返回給發送端，數據區段與數據區段之間的間隔就是接收端沒有收到的數據。發送端就知道哪些數據包已經收到，哪些該重傳，因此SACK的發送端可以在一個RTT時間內重傳多個數據包。
整個TCP選項長度不超過40字節，實際最多不超過4組邊界值。
通過一個wireshark示例來說明接收端的SACK行為:
上圖中ACK確認序列號為12421，SACK的塊左邊界值為13801，SACK的塊右邊界值為15181。明確了這三個參數的數值，我們基本上就可以計算出被丟棄的數據報的序列號和長度了。通過上圖所示的帶有SACK的數據報文，我們可以知道被丟棄的數據報文的TCP序列號為12422，其數據長度為13801-12421=1380B。
改進的快速恢復算法：
pipe：TCP發送端發出的未被確認的數據報文數的估計值，網絡中正在傳輸的分組數估計值；（決定了什麽時候重傳）
scoreboard：發送端保存，記錄從SACK選項中得知的未被確認的分組。（指出了哪些分組需要重傳）
2、發送端每次新發送或重傳一個數據包後，pipe=pipe+1；
發送端每收到一個重復的包含SACK選項的ACK包後（新的分組被接到），pipe=pipe-1；
3、當發送端可以發送數據包時，重傳scoreboard中指示的最後的數據包，如果計分板為空，則發送新的數據包；
4、當發送端收到PACK，pipe=pipe-2。因為PACK表示兩個數據包離開了pipe，一個是丟失的數據包，一個是重傳的數據包；
5、當發送端收到RACK後退出快速重傳階段。
四、基於仿真的TCP擁塞控制算法性能分析
仿真分為兩組：
第一組對服務器進行訪問的用戶數為10，第二組用戶數是90。
仿真結果如圖。當用戶較少。即網絡擁塞情況不明顯時，四種TCP實現的性能差別不大。
當網絡用戶增多導致網絡出現嚴重的擁塞時，SACK和NewReno 顯示了更優越的性能。
當網絡擁塞不嚴重時，Reno，NewReno，SACK TCP都略優於Tahoe TCP；
當網絡出現比較嚴重的擁塞，導致TCP的一個擁塞窗口丟失多個數據包時，
Reno TCP可能會進入超時等待階段，性能甚至差於Tahoe TCP，
NewReno TCP可以較快地從擁塞中恢復，
SACK TCP恢復速度更快，對擁塞的處理更合理。
—————————————————————————————————————————
【參考文獻】：（還有一些參考博客沒有列出，如有侵權可以聯系博主）
吳文紅，李向麗.TCP擁塞控制機制定量性能分析.計算機工程與應用.2008,44(18)
孫偉，溫濤，馮自勤，郭權.基於TCP NewReno的穩態吞吐量分析模型.計算機研究與發展.2010
陳琳，雙雪芹.TCP網絡擁塞控制算法比較研究.長江大學學報.2010,3
許豫飛，TCP擁塞控制算法集齊性能評估.北京郵電大學.2005,3
劉擁民，年曉紅.對SACK擁塞控制算法的研究.信息技術.2003,9
焦程波，竇睿彧，蘭巨龍.無線網絡中選擇性重傳機制性能分析與改進.計算機應用研究.2007.3
James F.Kurose,Keith W.Ross，Computer Networking A Top-Down Approach Sixth Edition.機械工業出版社
TCP擁塞控制算法之NewReno和SACK