TCP擁塞控制算法仿真實(shí)驗(yàn)設(shè)計(jì)

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

(1. 齊齊哈爾大學(xué) 計(jì)算機(jī)與控制工程學(xué)院， 黑龍江 齊齊哈爾 161006；2. 齊齊哈爾大學(xué) 網(wǎng)絡(luò)信息中心， 黑龍江 齊齊哈爾 161006)

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

1 NS2技術(shù)簡(jiǎn)介

NS2(network Simulator version 2)是一種面向?qū)ο?、離散事件驅(qū)動(dòng)的網(wǎng)絡(luò)模擬器，并能運(yùn)行在多種操作系統(tǒng)的環(huán)境中。NS2存在一套內(nèi)建的類庫(kù)，可以方便搭建網(wǎng)絡(luò)實(shí)驗(yàn)?zāi)Ｐ?，?gòu)建網(wǎng)絡(luò)實(shí)驗(yàn)教學(xué)環(huán)境，實(shí)現(xiàn)多種協(xié)議的仿真。

利用NS2進(jìn)行網(wǎng)絡(luò)仿真可分為兩個(gè)過(guò)程，一個(gè)是利用自帶的網(wǎng)絡(luò)元素，編寫(xiě)Otcl仿真腳本，無(wú)需對(duì)NS進(jìn)行擴(kuò)展；二是需要擴(kuò)展網(wǎng)絡(luò)元素，添加新的類和編寫(xiě)新的腳本[4]。NS2仿真過(guò)程見(jiàn)圖1所示。

圖1 NS2仿真過(guò)程示意圖

NS2仿真過(guò)程可分為模型創(chuàng)建、模擬實(shí)現(xiàn)和仿真結(jié)果分析[5]。第一步構(gòu)造一個(gè)虛擬的網(wǎng)絡(luò)測(cè)試環(huán)境，包括各節(jié)點(diǎn)間建立的連接、節(jié)點(diǎn)之上各級(jí)代理以及各條線路傳輸?shù)膮?shù)設(shè)置等；第二步根據(jù)實(shí)際要求對(duì)路由協(xié)議進(jìn)行初始化、節(jié)點(diǎn)代理和記錄運(yùn)行情況，編寫(xiě)Otcl腳本；第三步進(jìn)行結(jié)果的追蹤。當(dāng)NS2仿真結(jié)束后，對(duì)產(chǎn)生的一個(gè)或多個(gè)跟蹤文件，可以通過(guò)調(diào)用相應(yīng)的觀察器，例如Nam、Gnuplot對(duì)文件進(jìn)行分析及處理。其中Nam是可視化工具，將整個(gè)仿真過(guò)程以動(dòng)畫(huà)的方式展現(xiàn)出來(lái)，而Gnuplo是繪圖工具，可將擁塞窗口變化情況和端到端吞吐量等性能參數(shù)以圖形的方式展現(xiàn)出來(lái)。

2 TCP擁塞控制算法研究

2.1 TCP擁塞控制的基本方法

目前在Internet上，為了避免突發(fā)性的網(wǎng)絡(luò)數(shù)據(jù)所導(dǎo)致的網(wǎng)絡(luò)擁塞和報(bào)文丟失，TCP中設(shè)置了擁塞窗口(cwnd)機(jī)制，其擁塞控制的基本方法有慢啟動(dòng)(Slow Start)、擁塞避免(Congestion Avoidance)、快重傳(Fast Retransmit)和快恢復(fù)(Fast Recovery)。

慢啟動(dòng)算法用于探測(cè)網(wǎng)絡(luò)的可用帶寬，其擁塞窗口以指數(shù)方式增加。擁塞避免算法試圖避免網(wǎng)絡(luò)擁塞的發(fā)生，并盡可能探測(cè)可用帶寬，使用AIMD(additive increase multiplicative decrease)機(jī)制來(lái)改變擁塞窗口的大小?？熘貍骱涂旎謴?fù)算法就是在發(fā)送端收到3個(gè)重復(fù)確認(rèn)(Duplication ACK)時(shí)，就判定數(shù)據(jù)包已丟失，并重傳緩存中的數(shù)據(jù)包，同時(shí)將擁塞窗口的門限(ssthresh)設(shè)置為當(dāng)前cwnd的1/2，而不必等到重傳計(jì)時(shí)器(RTO)超時(shí)。

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

/Initialization/

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

cwnd=1;

ssthresh=65535(bytes); /當(dāng)新確認(rèn)包ACK到達(dá)時(shí)

if(cwnd

/Slow Start /

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

else

/Congestion Avoidance /

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

對(duì)于慢啟動(dòng)和擁塞避免兩個(gè)階段，當(dāng)重傳計(jì)時(shí)器超時(shí)，則分別執(zhí)行下列算法：

if(timeout)

{ssthresh=cwnd /2;

cwnd=1;}

同樣，在慢啟動(dòng)和擁塞避免兩個(gè)階段，如果發(fā)送端收到3個(gè)重復(fù)的確認(rèn)ACK，則分別執(zhí)行下列的快重傳和快恢復(fù)算法：

/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的基本結(jié)構(gòu)，包括慢啟動(dòng)、擁塞避免和快重傳3種基本方法。假定發(fā)送端收到3個(gè)重復(fù)確認(rèn)(Duplicate ACK)，即不等重傳計(jì)算器超時(shí)(RTO)，發(fā)送端就立即重傳緩存中已發(fā)送的數(shù)據(jù)包，并將ssthresh的值設(shè)為cwnd的1/2，之后將cwnd的值重置為1。

2.2.2 TCP Reno

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

2.2.3 TCP New Reno

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

2.2.4 TCP Sack

Sack是TCP Reno的另一個(gè)衍生版本，在此版本中，加入一個(gè)Sack選項(xiàng)，對(duì)來(lái)自數(shù)據(jù)窗口中的多個(gè)數(shù)據(jù)包，TCP一般采用累計(jì)確認(rèn)的機(jī)制。當(dāng)接收端緩存隊(duì)列中出現(xiàn)序號(hào)不連續(xù)的數(shù)據(jù)時(shí)，允許接收端在返回的重復(fù)確認(rèn)中，將已收到的數(shù)據(jù)區(qū)段返回給發(fā)送端，這樣，發(fā)送端就會(huì)有選擇地重傳丟失數(shù)據(jù)包，并在一個(gè)RTT時(shí)間內(nèi)重傳一個(gè)以上的數(shù)據(jù)包，提高了TCP性能。

2.2.5 TCP Vegas

TCP Vegas是利用RTT來(lái)測(cè)量網(wǎng)絡(luò)狀況的擁塞控制算法[7-8]，通過(guò)觀察RTT值的變化情況來(lái)決定是否增加或減少cwnd的值。如果RTT變大，Vegas就認(rèn)為網(wǎng)絡(luò)發(fā)生了擁塞，開(kāi)始減小cwnd；如果RTT變少，Vegas就認(rèn)為網(wǎng)絡(luò)擁塞已經(jīng)解除，再次增加cwnd。這樣，在理想情況下cwnd就會(huì)穩(wěn)定在一個(gè)合適值上。該算法的最大好處在于擁塞控制機(jī)制的觸發(fā)只與RTT的改變有關(guān)。

3 TCP擁塞控制算法的仿真與實(shí)現(xiàn)

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

3.1.1 往返時(shí)間(RTT)對(duì)TCP性能的影響

本實(shí)驗(yàn)采用NS2.35進(jìn)行仿真[9]，網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)如圖2所示。

圖2 RTT仿真拓?fù)浣Y(jié)構(gòu)圖

根據(jù)圖2拓?fù)洌蓷lTCP連接，第一條存在于S0到D0之間(FTP0)，第二條存在于S1到D1之間(FTP1)，由于FTP0的往返時(shí)間較短，仿真時(shí)間設(shè)定為40 s。

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

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

從圖中可以看出，F(xiàn)TP0的往返時(shí)間較短，所以在慢啟動(dòng)期間，F(xiàn)TP0以較快的速度增加cwnd的窗口值。由于確認(rèn)包的往返時(shí)間也較短，在帶寬滿載之前，F(xiàn)TP0有較多的時(shí)間利用慢啟動(dòng)增加其窗口大小。同樣，在重新進(jìn)入擁塞避免后，F(xiàn)TP0仍然以較快的速度發(fā)送數(shù)據(jù)，這是因?yàn)镕TP0的慢啟動(dòng)門限值比FTP1大，使得FTP0的速度明顯比FTP1快并且總是有較好的執(zhí)行效果。

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

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

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

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

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

3.1.2 重傳計(jì)時(shí)器超時(shí)(RTO)對(duì)TCP性能的影響

本實(shí)驗(yàn)使用NS2.35進(jìn)行仿真，網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖如圖6所示。

圖5 不同TCP算法的吞吐量運(yùn)行情況

圖6 RTO仿真拓?fù)浣Y(jié)構(gòu)圖

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

表2 各種TCP版本的吞吐量比較(計(jì)時(shí)器長(zhǎng)度不同)

圖7 各種TCP算法在不同計(jì)時(shí)器長(zhǎng)度下的運(yùn)行情況

在該實(shí)驗(yàn)中，在慢啟動(dòng)時(shí)由于TCP的連接都是以指數(shù)方式增加，網(wǎng)絡(luò)的緩沖區(qū)很快就會(huì)被用完，這將導(dǎo)致大量數(shù)據(jù)包的丟失。從表2中可以看到，超時(shí)對(duì)Reno的影響很大，將超時(shí)計(jì)時(shí)器的值設(shè)置小些(觀察case2的第二行，設(shè)為0.1 s)，由于FTP1恢復(fù)的時(shí)間較短，所以Reno的平均吞吐量明顯變好(由原來(lái)657.2 kbit/s變?yōu)?97.8 kbit/s)。雖然類似的情形也發(fā)生在TCP New Reno中，但由于New Reno在超時(shí)發(fā)生之前利用快恢復(fù)機(jī)制重新發(fā)送數(shù)據(jù)包，所以差異并不明顯。Tahoe只要收到重復(fù)確認(rèn)，就開(kāi)始慢啟動(dòng)并重傳數(shù)據(jù)包，故吞吐量沒(méi)有變化(觀察case1的第二行和case2的第二行)；Vegas 和Sack則是因?yàn)闆](méi)有發(fā)生超時(shí)，而在本實(shí)驗(yàn)中都得到相同的運(yùn)行結(jié)果。

3.2 4種典型版本的TCP擁塞控制算法實(shí)驗(yàn)設(shè)計(jì)

采用NS2.35進(jìn)行實(shí)驗(yàn)，仿真網(wǎng)絡(luò)拓?fù)鋱D如圖8所示。

圖8 網(wǎng)絡(luò)仿真實(shí)驗(yàn)拓?fù)鋱D

其中FTP源節(jié)點(diǎn)到路由器R0的帶寬為10 Mbit/s，延遲為1 ms。路由器R0到R1的帶寬為1 Mbit/s，延遲為4 ms。路由器R1到FTP Sink的帶寬為10 Mbit/s，延遲為1 ms。路由器隊(duì)列管理使用DropTail[10-12]。假設(shè)有大量數(shù)據(jù)通過(guò)R0經(jīng)過(guò)R1發(fā)送到固定節(jié)點(diǎn)FTP sink。其仿真時(shí)間設(shè)定為10 s。

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

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

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

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

在Sack算法中，發(fā)送端可明確知道哪些數(shù)據(jù)包已經(jīng)被接收端收到，并能針對(duì)丟失的數(shù)據(jù)包盡快重傳(例如，本實(shí)驗(yàn)中的32號(hào)數(shù)據(jù)包)，縮短重傳時(shí)間，減少觸發(fā)timeout的機(jī)會(huì)，提高了網(wǎng)絡(luò)的吞吐量，見(jiàn)表3。

表3 不同TCP版本平均吞吐量的對(duì)比

通過(guò)在NS2腳本中添加吞吐量的計(jì)算公式，計(jì)算代碼如下：

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

$ns flush-trace

吞吐量的結(jié)果如圖10所示。

圖10 4種版本TCP算法的吞吐量運(yùn)行情況

不同版本的TCP擁塞控制算法吞吐量對(duì)比見(jiàn)表3所示。

由表3和圖10可以看出：TCP Tahoe因?yàn)闆](méi)有快恢復(fù)機(jī)制而性能最差；TCP New Reno和TCP Sack是基于TCP Reno的改進(jìn)方案，在丟包率較高的情況下，它們的吞吐量具有一定改善，明顯高于TCP Reno；而TCP Sack又優(yōu)于TCP New Reno，因?yàn)門CP Sack的發(fā)送端有較好的快恢復(fù)特性，增加網(wǎng)絡(luò)的穩(wěn)定性和魯棒性。

4 結(jié)語(yǔ)

本文對(duì)影響TCP性能參數(shù)RTT和RTO設(shè)置問(wèn)題進(jìn)行了探討，給出各種擁塞控制算法的仿真實(shí)驗(yàn)對(duì)比。結(jié)果表明，RTT設(shè)置較短，其cwnd就越大，平均端到端吞吐量就越高，并能及時(shí)進(jìn)行擁塞控制。當(dāng)RTO設(shè)置相對(duì)較小時(shí)，即由原來(lái)的0.5 s變?yōu)?.1 s ，TCP Reno算法表現(xiàn)出良好的性能，由于該算法的快恢復(fù)的時(shí)間較短，因此它的吞吐量明顯增大，而其他算法的吞吐量不變或增加不夠明顯。對(duì)典型的4種TCP擁塞控制算法運(yùn)行效果進(jìn)行仿真分析，TCP Tahoe和TCP Reno是基于窗口機(jī)制，存在一定的局限性，只能解決一個(gè)數(shù)據(jù)包丟失的恢復(fù)問(wèn)題。但在丟包率較高的情況下，TCP New Reno和TCP Sack的吞吐量明顯高于TCP Reno。而TCP Sack又優(yōu)于TCP New Reno，具有較好的網(wǎng)絡(luò)特性。