利用NS2軟體模擬各種TCP版本_背景知識篇(一)
 |
| 封包運作情況 |
目錄
1.背景知識
2.環境建置
3.結果圖與分析
4.參考文獻
1.背景知識
A.壅塞控制
一般而言，TCP的壅塞控制機制主要可分為slow-start、Congestion avoidance、Fast retransmission、Fast recovery 與 Timeout retransmission五個階段：
1. slow-start：也叫做指數增長期，傳送初期或者封包遺失 重傳時整個連線類似於從零開始的狀態，會以指數的方式增長，每收到一個ACK(經過一個RTT)，cwnd就提升一倍。
B.TCP Tahoe
TCP 早期的版本，Tahoe具備 TCP 基本架構，包括慢啟動、壅塞避免、重傳狀態。TCP 在 Tahoe 這版本中加入了快速重傳(Fast retransmit)的方法。快速重傳機制是依據重複(Duplicate) ACKs 作為重送封包的機制，當收到 3 個重複 ACKs，傳送端會將封包視為遺失，不需 Timeout 就進入重送機制(將 ssthresh 的值設為
cwnd 的 1/2，即 cwnd 的值設為 1)，表示的確有個節段遺失，而不是因為順序混亂而引發重複 ACKs。
C.TCP Reno
Reno(RFC 2581)為目前最普遍的版本，修改
Tahoe 演算法並加入快速恢復(Fast recovery)機制。Reno 以快速恢復取代 Tahoe在重傳遺失封包後就進入慢啟動狀態。在 Reno 版本中快速重傳機制在重傳遺失封包後，將 cwnd 設為偵測到遺失時的 1/2，並當每收到一個重複 ACKs 就繼續送出新的封包來提高頻寬利用率，可以更快達到 threshold 值，已進入壅塞避免階段。快速重傳及快速恢復都是使用計算重複
ACKs 的技巧，以維持節段號碼順序。
D.TCP NewReno
NewReno是修改自Reno的TCP版本。這個版本中主要修改了TCP Reno 的Fast recovery演算法。NewReno在收到partial ACK時並不會立刻結束Fast recovery，相反地，NewReno的傳送端會持續地重送partial ACK之後的封包，直到將所有遺失的封包重送後才會結束Fast-recovery，這使得NewReno 的傳送端在網路有大量封包遺失時不需等待timeout就能更正此錯誤，減少大量封包遺失對傳輸效能所造成的影響。NewReno大約每一個RTT時間可重送一個遺失的封包，在Fast-recovery這個階段，若允許的話，傳送端可以繼續送出新的封包以增加link的使用率。
E.TCPwithSelective cknowledgements(SACK)
雖然NewReno可以解決大量封包遺失的問題，但是NewReno在每個RTT時間只能更正一個封包遺失的錯誤。為了更有效處理大量封包遺失的問題，另一種解決的方法就是讓傳送端知道那些已經被接收端收到，但此方法必須同時修改傳送端與接收端的傳送機制。 SACK [2-3]是TCP Reno的另一個衍生版本。在這個版本中，加入了一個SACK選項(option)允許接收端在回傳duplicate ACK時，將已經收到的資料區段 (連續收到的資料範圍) 回傳給傳送端，資料區段與資料區段之間的間隔就是接收端沒有收到的資料。藉由這些資訊，傳送端就知道那些是已經收到的，那些是該重送的，因此SACK的傳送端可以在一個RTT時間之內重送一個以上的封包。
F.TCP Vegas
Brakmo 和 Peterson 提出採用觀察 RTT的變化量來控制 cwnd 的大小，以計算預期的效能比較實際的效能來加以決定是否增加或減少 ssthresh 直，Vegas 修改了 Reno 的技術並重新設計了以下三種方法，如下介紹：修改slow-start (Modified
slow-start)希望能更有效率的利用頻寬並且避免 cwnd 值上升太快而引發封包遺失情況。cwnd 值大約經過 2 個 RTT 時間(Round-Trip Time)後才會增加一倍，而非 Reno，每次的 RTT時間就會使得 cwnd 值改變。
G.TCP版本演進圖
點我進入實作篇~~
留言
張貼留言