TCP擁塞控制算法仿真實驗設計

滕艷平， 杜 鵑， 谷文成， 廉佐政， 孫曉濱

(1. 齊齊哈爾大學 計算機與控制工程學院， 黑龍江 齊齊哈爾 161006；2. 齊齊哈爾大學 網絡信息中心， 黑龍江 齊齊哈爾 161006)

計算機網絡是一門理論與應用結合緊密的課程，涉及很多協議和算法。傳輸控制協議(Transmission Control Protocol，TCP)又是網絡體系結構中一個非常重要的協議，它能提供可靠的端到端通信服務。研究表明，目前Internet中有95%數據包使用TCP協議進行傳輸[1]，并且TCP協議又能進行流量控制和擁塞控制。TCP擁塞控制算法對于確保網絡的魯棒性、穩定性和動態性具有十分重要的作用[2-3]。驗證擁塞控制算法的有效性和進行相關性能的測試，目前常用的網絡仿真工具有OPNET和NS2等。本文給出在NS2仿真環境下，針對各種版本的TCP設計一組仿真實驗項目，并對其性能進行對比分析。在計算機網絡的實驗教學中，利用NS2仿真可以讓學生更直觀理解網絡協議的工作原理，對影響網絡性能因素進行分析和驗證，增強學生實踐動手能力，提高網絡實驗課程的教學質量。

1 NS2技術簡介

NS2(network Simulator version 2)是一種面向對象、離散事件驅動的網絡模擬器，并能運行在多種操作系統的環境中。NS2存在一套內建的類庫，可以方便搭建網絡實驗模型，構建網絡實驗教學環境，實現多種協議的仿真。

利用NS2進行網絡仿真可分為兩個過程，一個是利用自帶的網絡元素，編寫Otcl仿真腳本，無需對NS進行擴展；二是需要擴展網絡元素，添加新的類和編寫新的腳本[4]。NS2仿真過程見圖1所示。

圖1 NS2仿真過程示意圖

NS2仿真過程可分為模型創建、模擬實現和仿真結果分析[5]。第一步構造一個虛擬的網絡測試環境，包括各節點間建立的連接、節點之上各級代理以及各條線路傳輸的參數設置等；第二步根據實際要求對路由協議進行初始化、節點代理和記錄運行情況，編寫Otcl腳本；第三步進行結果的追蹤。當NS2仿真結束后，對產生的一個或多個跟蹤文件，可以通過調用相應的觀察器，例如Nam、Gnuplot對文件進行分析及處理。其中Nam是可視化工具，將整個仿真過程以動畫的方式展現出來，而Gnuplo是繪圖工具，可將擁塞窗口變化情況和端到端吞吐量等性能參數以圖形的方式展現出來。

2 TCP擁塞控制算法研究

2.1 TCP擁塞控制的基本方法

目前在Internet上，為了避免突發性的網絡數據所導致的網絡擁塞和報文丟失，TCP中設置了擁塞窗口(cwnd)機制，其擁塞控制的基本方法有慢啟動(Slow Start)、擁塞避免(Congestion Avoidance)、快重傳(Fast Retransmit)和快恢復(Fast Recovery)。

慢啟動算法用于探測網絡的可用帶寬，其擁塞窗口以指數方式增加。擁塞避免算法試圖避免網絡擁塞的發生，并盡可能探測可用帶寬，使用AIMD(additive increase multiplicative decrease)機制來改變擁塞窗口的大小。快重傳和快恢復算法就是在發送端收到3個重復確認(Duplication ACK)時，就判定數據包已丟失，并重傳緩存中的數據包，同時將擁塞窗口的門限(ssthresh)設置為當前cwnd的1/2，而不必等到重傳計時器(RTO)超時。

下面是TCP擁塞控制的算法幾個主要步驟：

/Initialization/

win=min(cwnd, rwnd); /發送端窗口上限取接收窗口和擁塞窗口最小值

cwnd=1;

ssthresh=65535(bytes); /當新確認包ACK到達時

if(cwnd

/Slow Start /

cwnd=cwnd+ 1; /擁塞窗口按指數方式增加

else

/Congestion Avoidance /

cwnd=cwnd+ 1 /cwnd ; /擁塞窗口按線性方式增加

對于慢啟動和擁塞避免兩個階段，當重傳計時器超時，則分別執行下列算法：

if(timeout)

{ssthresh=cwnd /2;

cwnd=1;}

同樣，在慢啟動和擁塞避免兩個階段，如果發送端收到3個重復的確認ACK，則分別執行下列的快重傳和快恢復算法：

/Fastretransmit and Fast recovery /

if(three duplication ACK)

{ssthresh=cwnd /2;

cwnd=ssthresh;}

2.2 各種版本的TCP擁塞控制算法概述

2.2.1 TCP Tahoe

TCP最早的版本稱之為Tahoe，Tahoe具備TCP的基本結構，包括慢啟動、擁塞避免和快重傳3種基本方法。假定發送端收到3個重復確認(Duplicate ACK)，即不等重傳計算器超時(RTO)，發送端就立即重傳緩存中已發送的數據包，并將ssthresh的值設為cwnd的1/2，之后將cwnd的值重置為1。

2.2.2 TCP Reno

TCP Reno是目前最廣泛使用的TCP版本[6]，對Tahoe算法進行了修改，并加入快恢復功能。在使用快重傳后，重發丟失的數據包，會將ssthresh和cwnd的值都設為檢測到數據包丟失時擁塞窗口的1/2，并進入快恢復階段。當發送端收到重傳數據包ACK就會直接進入擁塞避免階段。Tahoe針對一個數據包丟失情況，其性能較佳，但對多個數據包的丟失，會引起窗口的振蕩，進而引發較大延時。

2.2.3 TCP New Reno

TCP New Reno是Reno的修改版，在一個發送窗口丟失多個數據包的情況下，對Reno中的快重傳和快恢復方法進行了改進，使得快恢復階段利用部分應答(Partical ACK)來觸發重傳，只有當全部的丟包都被重傳確認后才退出快恢復階段。New Reno大約每一個RTT時間可重傳一個丟失的數據包，如若允許，在快恢復階段，發送端還可繼續發送新的數據包，以增加鏈路的使用效率。

2.2.4 TCP Sack

Sack是TCP Reno的另一個衍生版本，在此版本中，加入一個Sack選項，對來自數據窗口中的多個數據包，TCP一般采用累計確認的機制。當接收端緩存隊列中出現序號不連續的數據時，允許接收端在返回的重復確認中，將已收到的數據區段返回給發送端，這樣，發送端就會有選擇地重傳丟失數據包，并在一個RTT時間內重傳一個以上的數據包，提高了TCP性能。

2.2.5 TCP Vegas

TCP Vegas是利用RTT來測量網絡狀況的擁塞控制算法[7-8]，通過觀察RTT值的變化情況來決定是否增加或減少cwnd的值。如果RTT變大，Vegas就認為網絡發生了擁塞，開始減小cwnd；如果RTT變少，Vegas就認為網絡擁塞已經解除，再次增加cwnd。這樣，在理想情況下cwnd就會穩定在一個合適值上。該算法的最大好處在于擁塞控制機制的觸發只與RTT的改變有關。

3 TCP擁塞控制算法的仿真與實現

3.1 影響TCP性能因素及仿真效果

3.1.1 往返時間(RTT)對TCP性能的影響

本實驗采用NS2.35進行仿真[9]，網絡拓撲結構如圖2所示。

圖2 RTT仿真拓撲結構圖

根據圖2拓撲，建立兩條TCP連接，第一條存在于S0到D0之間(FTP0)，第二條存在于S1到D1之間(FTP1)，由于FTP0的往返時間較短，仿真時間設定為40 s。

Reno版本FTP0和FTP1的cwnd變化情況如圖3所示。

圖3 Reno版本FTP0和FTP1的cwnd變化情況

從圖中可以看出，FTP0的往返時間較短，所以在慢啟動期間，FTP0以較快的速度增加cwnd的窗口值。由于確認包的往返時間也較短，在帶寬滿載之前，FTP0有較多的時間利用慢啟動增加其窗口大小。同樣，在重新進入擁塞避免后，FTP0仍然以較快的速度發送數據，這是因為FTP0的慢啟動門限值比FTP1大，使得FTP0的速度明顯比FTP1快并且總是有較好的執行效果。

圖4為不同版本算法的FTP0和FTP1的cwnd變化情況。左上為Tahoe算法，右上為New Reno算法，左下為Sack算法，右下為Vegas算法。

表1和圖5反映了5種算法的吞吐量變化情況。

FTP0的平均吞吐量明顯高于FTP1，這由于FTP0的RTT較短。因此，在有線的因特網中，當發生擁塞時，距擁塞處較近的發送端能得到快速反應，并及時進行擁塞控制，表現出良好性能。但對RTT的設置不能太短，這樣就可以避免在同一時間所有TCP將cwnd減半的情況發生，使緩存隊列長度能穩定在較高值上。

圖4 不同版本算法FTP0和FTP1的cwnd變化情況

表1 不同TCP版本的FTP0和FTP1的吞吐量比

3.1.2 重傳計時器超時(RTO)對TCP性能的影響

本實驗使用NS2.35進行仿真，網絡拓撲結構圖如圖6所示。

圖5 不同TCP算法的吞吐量運行情況

圖6 RTO仿真拓撲結構圖

在該實驗中，分成2個小組進行，其中一組的FTP0和FTP1的tcptick的值(RTO)都設為0.5 s，另一組則分別設為0.5 s(FTP0)以及0.1 s(FTP1)。表2為吞吐量對比分析,圖7為不同算法的仿真實驗結果。

表2 各種TCP版本的吞吐量比較(計時器長度不同)

圖7 各種TCP算法在不同計時器長度下的運行情況

在該實驗中，在慢啟動時由于TCP的連接都是以指數方式增加，網絡的緩沖區很快就會被用完，這將導致大量數據包的丟失。從表2中可以看到，超時對Reno的影響很大，將超時計時器的值設置小些(觀察case2的第二行，設為0.1 s)，由于FTP1恢復的時間較短，所以Reno的平均吞吐量明顯變好(由原來657.2 kbit/s變為697.8 kbit/s)。雖然類似的情形也發生在TCP New Reno中，但由于New Reno在超時發生之前利用快恢復機制重新發送數據包，所以差異并不明顯。Tahoe只要收到重復確認，就開始慢啟動并重傳數據包，故吞吐量沒有變化(觀察case1的第二行和case2的第二行)；Vegas 和Sack則是因為沒有發生超時，而在本實驗中都得到相同的運行結果。

3.2 4種典型版本的TCP擁塞控制算法實驗設計

采用NS2.35進行實驗，仿真網絡拓撲圖如圖8所示。

圖8 網絡仿真實驗拓撲圖

其中FTP源節點到路由器R0的帶寬為10 Mbit/s，延遲為1 ms。路由器R0到R1的帶寬為1 Mbit/s，延遲為4 ms。路由器R1到FTP Sink的帶寬為10 Mbit/s，延遲為1 ms。路由器隊列管理使用DropTail[10-12]。假設有大量數據通過R0經過R1發送到固定節點FTP sink。其仿真時間設定為10 s。

將不同版本的TCP的擁塞窗口和吞吐量進行對比分析。通過對追蹤文件分析來觀察擁塞窗口的變化，得到不同TCP版本的執行效果，并使用gnuplot來實現可視化過程。4種擁塞控制算法的cwnd變化情況如圖9所示。從圖9中可以看出，Tahoe的擁塞窗口變化情況，即在擁塞窗口為20時啟動了擁塞避免機制，線性增加窗口大小，當Tahoe發現了網絡數據包丟失時，就立刻將cwnd的大小調整為初始值1，重新進入慢啟動階段。

圖9 不同版本TCP算法的cwnd變化情況對比

與Tahoe算法相比，Reno算法檢測到數據包丟失時，會將cwnd的大小設定為發生擁塞時的窗口的一半(本實驗所得cwnd值為10)，然后運行擁塞避免算法。由于不需要再次進行慢啟動，所以得到的平均吞吐量要比Tahoe算法好，見表3。

為了進一步比較Reno和New Reno的運行效果，將圖8中R0與R1之間的緩存設得小一些(例如15個數據包)，在仿真實驗中，若發送20個以上的數據包就會產生丟包現象。針對上述情況，Reno在收到Partical ACK(比如，序號為33的確認)，就會離開Fast Recovery階段。由于Reno沒有足夠的重復確認來觸發快重傳，因此當超時(timeout)后就進入慢啟動階段。但New Reno在收到Partical ACK(比如，ack=33,35,37等)，仍維持在Fast Recovery階段，直到所有丟失的數據包都被重傳為止。由于在重傳時不需要等待RTO超時，因此New Reno的吞吐量明顯比Reno高。但New Reno也有瞬間快發新的數據包情況，可通過Maxburst參數設置來改進。

在Sack算法中，發送端可明確知道哪些數據包已經被接收端收到，并能針對丟失的數據包盡快重傳(例如，本實驗中的32號數據包)，縮短重傳時間，減少觸發timeout的機會，提高了網絡的吞吐量，見表3。

表3 不同TCP版本平均吞吐量的對比

通過在NS2腳本中添加吞吐量的計算公式，計算代碼如下：

puts[format″average throughput:%.1f Kbps″ [expr [$tcp set ack_]*([$tcp set packetSize_])*8/1000.0/10]]

$ns flush-trace

吞吐量的結果如圖10所示。

圖10 4種版本TCP算法的吞吐量運行情況

不同版本的TCP擁塞控制算法吞吐量對比見表3所示。

由表3和圖10可以看出：TCP Tahoe因為沒有快恢復機制而性能最差；TCP New Reno和TCP Sack是基于TCP Reno的改進方案，在丟包率較高的情況下，它們的吞吐量具有一定改善，明顯高于TCP Reno；而TCP Sack又優于TCP New Reno，因為TCP Sack的發送端有較好的快恢復特性，增加網絡的穩定性和魯棒性。

4 結語

本文對影響TCP性能參數RTT和RTO設置問題進行了探討，給出各種擁塞控制算法的仿真實驗對比。結果表明，RTT設置較短，其cwnd就越大，平均端到端吞吐量就越高，并能及時進行擁塞控制。當RTO設置相對較小時，即由原來的0.5 s變為0.1 s ，TCP Reno算法表現出良好的性能，由于該算法的快恢復的時間較短，因此它的吞吐量明顯增大，而其他算法的吞吐量不變或增加不夠明顯。對典型的4種TCP擁塞控制算法運行效果進行仿真分析，TCP Tahoe和TCP Reno是基于窗口機制，存在一定的局限性，只能解決一個數據包丟失的恢復問題。但在丟包率較高的情況下，TCP New Reno和TCP Sack的吞吐量明顯高于TCP Reno。而TCP Sack又優于TCP New Reno，具有較好的網絡特性。