基于OPNET的TCP擁塞控制仿真_第1頁
基于OPNET的TCP擁塞控制仿真_第2頁
基于OPNET的TCP擁塞控制仿真_第3頁
基于OPNET的TCP擁塞控制仿真_第4頁
基于OPNET的TCP擁塞控制仿真_第5頁
已閱讀5頁,還剩12頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、 畢業(yè)論文(設計) 題 目: 基于OPNET的TCP擁塞控制仿真 完 成 人: 班 級: 學 制: 專 業(yè): 指導教師: 完成日期: 目 錄摘要(1)0 引言(1)1 TCP擁塞控制意義(1)1.1網(wǎng)絡的擁塞(1)1.2 QOS的需求(2)1.3網(wǎng)絡的擁塞控制(2)2 TCP擁塞控制(2)2.1 TCP滑動窗口機制(3)2.2 慢啟動(3)2.3 擁塞避免(4)2.4 快速重傳與恢復(4)3 網(wǎng)絡仿真軟件OPNET(5)3.1 OPNET仿真軟件概述(5)3.2 OPNET仿真技術(5)3.2.1 三層建模機制(5)3.2.2 離散事件仿真機制(5)3.2.3 仿真調(diào)度機制(6)3.3 OPN

2、ET仿真流程圖(6)4 仿真實驗(7)4.1 慢啟動與擁塞避免算法仿真(7)4.1.1 實驗步驟(7)4.1.2 實驗數(shù)據(jù)(8)4.1.3 數(shù)據(jù)分析(9)4.2 同時使用慢啟動,擁塞避免和快速重傳算法仿真(9)4.2.1 實驗步驟(9)4.2.2 實驗數(shù)據(jù)(10)4.2.3 數(shù)據(jù)分析(10)4.3 同時使用慢啟動,擁塞避免,快速重傳和恢復算法仿真(10)4.3.1 實驗步驟(10)4.3.2 實驗數(shù)據(jù)(11)4.3.3 數(shù)據(jù)分析(11)4.4 比較慢啟動,擁塞避免,快速重傳和恢復算法仿真(12)4.5 實驗總結(jié)(12)5 結(jié)束語(13)參考文獻(13)Abstract(14)第 14 頁 (共

3、 14 頁)基于OPNET的TCP擁塞控制仿真作 者:蘇亞軍指導教師:蔣華龍摘要:本文分析了TCP擁塞控制的概念、含義及原理算法;搭建網(wǎng)絡性能分析平臺,進行網(wǎng)絡仿真優(yōu)化,利用網(wǎng)絡仿真軟件OPNET進行仿真實驗,分析TCP擁塞控制協(xié)議中的四種不同算法,仿真TCP協(xié)議中用于擁塞控制的四種算法慢開始,擁塞避免,快速重傳和快速恢復,比較快速重傳和快速恢復(改進后的TCP)對于慢開始和擁塞避免(傳統(tǒng)的TCP)的改進效果。關鍵詞:TCP;擁塞控制;網(wǎng)絡仿真;OPNETInternet中擁塞控制的大部分工作是由TCP完成的,目前標準TCP協(xié)議的實現(xiàn)都包含了一些避免和控制網(wǎng)絡擁塞的算法1。當今Internet

4、的可靠性和穩(wěn)定性與TCP擁塞控制機制密不可分,而TCP的成功也要歸功于其穩(wěn)固的擁塞控制機制。隨著應用要求的日益豐富和技術的不斷發(fā)展,要想完全依賴實 現(xiàn)在終端系統(tǒng)上的策略和算法很難滿足服務質(zhì)量(QOS)這樣復雜的要求,為了解決相應的問題,相關網(wǎng)絡技術逐漸轉(zhuǎn)向網(wǎng)絡的中間節(jié)點即路由器上,通過增強它們的功能來實現(xiàn)端到端無法達到的技術,從而達到有效的擁塞控制,保持網(wǎng)絡的良好性能。1 TCP擁塞控制的意義1.1 網(wǎng)絡擁塞擁塞控制現(xiàn)在是Internet研究的熱點,在最初的TCP協(xié)議中只有流量控制(flow control)而沒有擁塞控制,接收端利用TCP報頭將接收能力通知發(fā)送端.這樣的控制機制只考慮了接收端

5、的接收能力,而沒有考慮網(wǎng)絡的傳輸能力,導致了網(wǎng)絡崩潰(congestion collapse)的發(fā)生。在計算機網(wǎng)絡中的鏈路容量,交換節(jié)點中的緩沖區(qū)和處理機等,都是網(wǎng)絡的資源。在某段時間,若對網(wǎng)絡中的某一資源的需求超過了該資源所能提供的可用部分,網(wǎng)絡的性能2就要變壞。這種情況就叫做擁塞(congestion)。若網(wǎng)絡中有許多資源同時產(chǎn)生擁塞。網(wǎng)絡的性能就要明顯變差,整個網(wǎng)絡的吞吐量就將隨輸入的負荷的增大而下降。網(wǎng)絡中的擁塞來源于網(wǎng)絡資源和網(wǎng)絡流量分布的不均衡性.擁塞不會隨著網(wǎng)絡處理能力的提高而消除.擁塞控制算法的分布性、網(wǎng)絡的復雜性和對擁塞控制算法的性能要求又使擁塞控制算法的設計具有很高的難度.

6、到目前為止,擁塞問題還沒有得到很好的解決。因此對擁塞控制的討論是一個很重要的問題。1.2 QOS需求隨著高速網(wǎng)絡技術和多媒體技術3的飛速發(fā)展,人們越來越多地提出了包括多媒體通信在內(nèi)的綜合服務要求,傳統(tǒng)的分組交換網(wǎng)絡,如Internet,是面向非實時的數(shù)據(jù)通信(如FTP 和 E-mail的傳輸)而設計的,采用TCP/IP協(xié)議主要是為了優(yōu)化整個網(wǎng)絡的數(shù)據(jù)吞吐量并保證數(shù)據(jù)通信的可靠性。而當今分布式多媒體應用(如視頻會議、視頻點播、IP可視電話、遠程教育)不僅包括語音、圖像、圖形、視頻、動畫這些類型的多媒體信息。分布式多媒體應用不但對網(wǎng)絡有很高的帶寬要求,而且要求信息傳輸?shù)牡脱舆t和低抖動等,同時,這些

7、應用大都能夠容忍一定程度的信息丟失和錯誤。由此可見,當今高速網(wǎng)絡中的多媒體應用對網(wǎng)絡提出了不同于數(shù)據(jù)應用的服務質(zhì)量要求,需要提供端到端的QOS控制和保證。正因為如此,對于端到端的流量控制和擁塞控制性能的研究是非常重要的。1.3 網(wǎng)絡擁塞控制在計算機網(wǎng)絡系統(tǒng)中,流量控制和擁塞控制保證網(wǎng)絡數(shù)據(jù)通信暢通必不可少的控制手段,眾所周知,要進行網(wǎng)絡擁塞控制,一般有兩種方法,一種是在網(wǎng)絡中進行擁塞控制,一種是在端到端中進行擁塞控制,而我們研究的對象TCP擁塞控制是一種端到端的控制行為。在Internet設計的初期,對于擁塞的控制是通過傳輸控制協(xié)議(Transmission Control Protocol

8、,TCP)中的端到端基于滑動窗口的流量控制完成的。1988年,Van Jacobson 在他的論文中指出了TCP在控制網(wǎng)絡擁塞方面的不足,并提出了“慢啟動”(Slow Start)和“擁塞避免”(Congestion Avoidance)算法,后來,它們被所有的Internet主機支持,在很長的一段時間內(nèi),接收端驅(qū)動的TCP流量控制是唯一可行的擁塞控制方法,實際上,前者只是實現(xiàn)后者的一種技術途徑而已。2 TCP擁塞控制在TCP協(xié)議456中,基本的TCP擁塞控制過程是在發(fā)送數(shù)據(jù)前期,滑動窗口先進入慢啟動階段,在擁塞窗口大于慢啟動門限值時,進入擁塞避免階段,如果檢測到了有分組的丟失,將根據(jù)版本的不

9、同,進入快速重發(fā)階段(FR),或者進入快速恢復階段(FR/FR)本節(jié)先介紹這四個基本過程。2.1 TCP滑動窗口機制與大多數(shù)提供流量控制的協(xié)議一樣,TCP也是使用滑動窗口機制的,但是與其他協(xié)議,如LLC、HDLC和X.25等稍有不同,它將數(shù)據(jù)的確認過程與發(fā)送數(shù)據(jù)的通告分開處理,被傳輸?shù)拿總€字節(jié)都被賦予一個序號,當發(fā)送端傳輸報文段時,為數(shù)據(jù)字段的每一個字節(jié)編排序列號,用(Ai;Wj)的報文形式確認數(shù)據(jù)的傳輸,具體含義如下:(1)序列號為i-1以及以下各字節(jié)已得到確認;下一個期望收到的字節(jié)的序列號是i。(2)同意對方再發(fā)送一個窗口W共j個字節(jié)的數(shù)據(jù)。這j個字節(jié)的序列號為i到i+j-1。TCP中發(fā)送

10、端的發(fā)送速率是受目的主機或網(wǎng)絡中較慢的一個制約的。接受方需要采用某種策略來決定同意發(fā)送方傳送多少數(shù)據(jù)。保守的辦法是僅同意對方傳送緩存空間可以容納的報文段。在時延帶寬的乘積較大的情況下,接受方通過預支緩存空間可以提高吞吐量。本文中幾個用到的名詞解釋:(1)RWND (接收端窗口);(2)CWND(擁塞窗口) 發(fā)送端根據(jù)自己估計的網(wǎng)絡擁塞程度而設置的窗口值,是來自發(fā)送端的流量控制;(3)發(fā)送窗口的上限值minrwnd,cwnd;(4)RTT 一個數(shù)據(jù)包的往返時延;(5)RTO(超時重傳計數(shù)器):描述數(shù)據(jù)包從發(fā)送到失效的時間間隔,是判斷數(shù)據(jù)包丟失與否及網(wǎng)絡是否擁塞的重要參數(shù)。通常設為2RTT或5RT

11、T。 (6)快速重傳閾值(tcprexmtthresh):能觸發(fā)快速重傳的源端收到重復確認包ACK的個數(shù)。當此個數(shù)超過tcprexmtthresh時,網(wǎng)絡就進入快速重傳階段。tcprexmtthresh缺省值為3。2.2 慢啟動(Slow Start)舊的TCP在啟動一個連接時會向網(wǎng)絡發(fā)送許多數(shù)據(jù)包,由于一些路由器必須對數(shù)據(jù)包進行排隊,因此有可能耗盡存儲空間,從而導致TCP連接的吞吐量(throughput)急劇下降。避免這種情況發(fā)生的算法就是慢啟動。當建立新的TCP連接時,擁塞窗口被初始化為一個數(shù)據(jù)包大小(一個數(shù)據(jù)包缺省值為536或512byte)。發(fā)送端端按cwnd大小發(fā)送數(shù)據(jù),每收到一個

12、ACK確認,cwnd就增加一個數(shù)據(jù)包發(fā)送量。顯然,cwnd的增長將隨RTT呈指數(shù)級(exponential)增長:1個、2個、4個、8個。發(fā)送端向網(wǎng)絡中發(fā)送的數(shù)據(jù)量將急劇增加。2.3 擁塞避免(congestion avoidance)當發(fā)現(xiàn)超時或收到3個相同ACK確認幀時,網(wǎng)絡即發(fā)生擁塞(這一假定是基于由傳輸引起的數(shù)據(jù)包損壞和丟失的概率小于1%)。此時就進入擁塞避免階段。慢啟動閾值被設置為當前cwnd的一半;超時時,cwnd被置為1。如果cwnd>ssthresh,則TCP則停止使用slow start 算法改為執(zhí)行擁塞避免算法:使發(fā)送端的擁塞窗口cwnd每經(jīng)過一個往返時延RTT就增加

13、一個MSS的大小,而不管在時間RTT內(nèi)收到幾個ACK,這樣,擁塞窗口AWND按線性規(guī)律緩慢增長,比慢開始算法的擁塞控制窗口增長速率緩慢的多。無論慢啟動階段還是擁塞控制階段,只要發(fā)送端發(fā)現(xiàn)擁塞,根據(jù)是沒有按時接收到ACK或收到重復ACK就要將慢啟動的門限ssthresh設置為出現(xiàn)擁塞時的發(fā)送窗口的一半,然后將擁塞窗口值cwnd重新設置為一,并執(zhí)行慢啟動算法。2.4 快速重傳與恢復(Fast Retransmission and Recover)當數(shù)據(jù)包超時,cwnd被設置為1,重新進入慢啟動,這會導致過大地減小發(fā)送窗口尺寸,降低TCP連接的吞吐量。因此快速重傳和恢復就是在發(fā)送端收到3個或3個以上

14、重復ACK時,就斷定數(shù)據(jù)包已經(jīng)被丟失,并重傳數(shù)據(jù)包,同時將ssthresh設置為當前cwnd的一半,而不必等到RTO超時??焖倩謴退惴ㄅc之前的算法不同之處在于:(1)與慢啟動不同之處是擁塞窗口cwnd不設為1,而是設置為ssthresh3;(2)若收到的重復ACK為n(n>3)則將cwnd設置為sstrshn;(3)若發(fā)送窗口值還同意發(fā)送報文段,就將按擁塞避免的算法繼續(xù)發(fā)送報文端;(4)若收到了確認新的報文段的ACK,就將cwnd縮小到ssthresh。3 網(wǎng)絡仿真軟件OPNET3.1 OPNET仿真軟件概述OPNET公司是全球領先的決策支持工具提供商,總部在美國華盛頓特區(qū),主要面向網(wǎng)絡

15、領域的專業(yè)人士,為網(wǎng)絡專業(yè)人士提供基于軟件方面的預測解決方案。OPNET公司最早是由麻省理工學院(MIT)信息決策實驗室受美國軍方委托而成立的。1987年OPNET公司發(fā)布了第1個商業(yè)化的網(wǎng)絡仿真軟件78,提供了具有重要意義的網(wǎng)絡性能優(yōu)化工具,使得具有預測性的網(wǎng)絡性能管理和仿真成為可能。1987年以來,OPNET迅速而穩(wěn)步地發(fā)展,作為高科技網(wǎng)絡規(guī)劃、仿真及分析工具,OPNET在通信、國防及計算機網(wǎng)絡領域已經(jīng)被廣泛認可和采用。成千上萬的組織使用OPNET軟件來優(yōu)化網(wǎng)絡性能、最大限度地提高通信網(wǎng)絡和應用的可用性。至今OPNET已經(jīng)升級到了11.5以上版本。它的產(chǎn)品線除了Modeler外,還包括IT

16、Guru、SP Guru、OPNET Development Kit 和WDM Guru等。3.2 OPNET仿真技術3.2.1三層建模機制網(wǎng)絡是復雜的系統(tǒng),OPNETModeler建模采用層次化和模塊化的方式,將復雜的體系分解為不同的層次結(jié)構(gòu),每層完成一定的功能,一層內(nèi)又由多個模塊組成,每個模塊完成更小的任務。網(wǎng)絡域、節(jié)點域、進程域是構(gòu)建OPNET Model模型的三個層次。節(jié)點域建模的方法是基于節(jié)點模塊,每個節(jié)點模塊實現(xiàn)節(jié)點行為的某一方面,諸如數(shù)據(jù)生成、數(shù)據(jù)存儲、數(shù)據(jù)的處理或選路和數(shù)據(jù)的傳輸?shù)取6鄠€節(jié)點模塊的集合構(gòu)成功能完整的節(jié)點。模塊間用包流線或統(tǒng)計線相連,其中包流線承載了模塊間數(shù)據(jù)包的

17、傳輸,統(tǒng)計線可實現(xiàn)對模塊待定參數(shù)變化的監(jiān)視,通過modules,paeketstreams和statistic wires的聯(lián)合使用,用戶可對節(jié)點的行為進行仿真。節(jié)點模塊根據(jù)功能可以劃分為處理器類、數(shù)據(jù)流線類和收/發(fā)機類三種。處理器類功能的實現(xiàn)是在進程域中通過Pro-C編程完成的。數(shù)據(jù)流類和收/發(fā)機類是通過管道階段模型實現(xiàn)的。3.2.2 離散事件仿真機制OPNET采用基于離散事件驅(qū)動的仿真機制。事件是指網(wǎng)絡狀態(tài)的變化。當網(wǎng)絡狀態(tài)發(fā)生變化時,模擬機進行仿真,狀態(tài)不發(fā)生變化的時間段,不進行仿真,即被跳過,因而仿真時間是離散的。每個仿真時間點上可以同時出現(xiàn)多個事件,事件的發(fā)生可以有疏密的區(qū)別。仿真中

18、的各個模塊之間通過事件中斷方式傳遞事件信息。每當出現(xiàn)一個事件中斷時都會觸發(fā)一個描述網(wǎng)絡系統(tǒng)行為或者系統(tǒng)處理的進程模型的運行,通過離散事件驅(qū)動的仿真機制實現(xiàn)了在進程級描述通信的并發(fā)性和順序性,再加上事件發(fā)生時刻的任意性,決定了可以仿真計算機和通信網(wǎng)絡中的任何情況下的網(wǎng)絡狀態(tài)和行為。3.2.3 仿真調(diào)度機制在OPNET中使用基于事件列表的調(diào)度機制,合理安排調(diào)度事件,以便執(zhí)行合理的進程來仿真網(wǎng)絡系統(tǒng)的行為。調(diào)度的完成通過仿真軟件的仿真核和仿真工具模塊以及模型模塊來實現(xiàn),事件列表的調(diào)度機制具體描述如下:(1)每個OPNET仿真都維持一個單獨的全局時間表,其中的每個項目和執(zhí)行都受到全局仿真時鐘的控制,仿

19、真中以時間順序調(diào)度事件列表中的事件,需要先執(zhí)行的事件位于表的頭部。當一個事件執(zhí)行后將從事件列表中刪除該事件。(2)仿真核作為仿真的核心管理機構(gòu),采用高效的辦法管理維護事件列表,按順序通過中斷將在隊列頭的事件交給指定模塊,同時接收各個模塊送來的中斷,并把相應事件插入事件列表中間。仿真控制權(quán)伴隨中斷不斷地在仿真核與模塊之間轉(zhuǎn)移。(3)當事件同時發(fā)生時,仿真核按照下面兩種辦法來安排事件在事件列表中的位置:1)按照事件到達仿真核的時間先后順序,先到達先處理(first come first serve)。2)按照事件的重要程度,為事件設置不同的優(yōu)先權(quán),優(yōu)先權(quán)高的先處理。3.3 OPNET仿真流程圖OP

20、NET仿真流程見圖1:圖1 OPNET仿真流程4 仿真實驗4.1 慢啟動與擁塞避免算法仿真4.1.1 實驗步驟(1) 啟動OPNET建立新的工程和場景并分別進行配置:新建名為CHAI_TCP的工程和名為NoDrop的場景,并均在Initial Topology中選擇Create Empty Scenario,在Choose Network Scale中選擇Choose From Maps,在Choose Map中選擇europa,然后一直Next到成功建立scenario。并建立巴黎子網(wǎng)和斯德哥爾摩子網(wǎng)分別進行配置。(2)創(chuàng)建IP云并配置: 圖2 IP云的創(chuàng)建與配置(3)總拓撲圖:圖3 總拓撲

21、圖(4)仿真:配置好后,點擊Run,運行成功:圖4 運行狀態(tài)4.1.2 實驗數(shù)據(jù)查看實驗數(shù)據(jù)。Congestion Window Size:圖5 結(jié)果觀察4.1.3 數(shù)據(jù)分析由實驗數(shù)據(jù)可知,TCP協(xié)議在執(zhí)行慢啟動和擁塞避免算法時,其窗口大小初值很小,但呈指數(shù)增長,但當超過所設定的最大窗口門限值(ssthresh)時,其窗口大小增長將呈現(xiàn)線性增長,即執(zhí)行擁塞避免算法。在本次實驗數(shù)據(jù)中,在大約1m54s左右窗口值從將近1460bytes達到將近65535bytes呈指數(shù)型增長,即慢啟動。當達到門限值大約65535bytes之后,開始“加法增大”,即擁塞避免算法。4.2 同時使用慢啟動,擁塞避免和快

22、速重傳算法仿真4.2.1 實驗步驟(1)復制4.1中場景:在Scenario菜單中選擇Duplicate Scenario并命名新場景為Tahoe,即出現(xiàn)與剛才網(wǎng)絡模型一模一樣的場景。并變更IP Cloud的設置和變更Paris子網(wǎng)的設置。(2)仿真: 如4.1:圖6 運行狀態(tài)4.2.2 實驗數(shù)據(jù)Congestion Window Size:圖7 結(jié)果觀察4.2.3 數(shù)據(jù)分析由實驗數(shù)據(jù)可知,與4.1類似,TCP協(xié)議在執(zhí)行慢啟動和擁塞避免算法時,其窗口大小初值很小,但呈指數(shù)增長,但當超過所設定的最大窗口門限值(ssthresh)時,其窗口大小增長將呈現(xiàn)線性增長。在本次實驗數(shù)據(jù)中,在大約1m54s

23、左右窗口值從將近1460bytes達到將近65535bytes呈指數(shù)型增長,即慢啟動。當達到門限值大約65535bytes之后,開始“加法增大”,即擁塞避免算法。在窗口大小到達大約72725bytes后,應該是收到3個連續(xù)ACK,根據(jù)3個重復的應答報文判斷丟包,并立即重傳丟失的分組,此時置ssthresh為當前擁塞窗口72725bytes的一半,這就是快重傳(Tahoe),然后再轉(zhuǎn)入慢啟動。4.3 同時使用慢啟動,擁塞避免,快速重傳和快速恢復算法仿真4.3.1 實驗步驟(1)復制4.2中場景:在Scenario菜單中選擇Duplicate Scenario并命名新場景為Reno,即出現(xiàn)與剛才網(wǎng)

24、絡模型一模一樣的場景,變更Paris子網(wǎng)的設置。(2)仿真:如4.2:圖8 運行狀態(tài)4.3.2 實驗數(shù)據(jù)Congestion Window Size:圖9 結(jié)果觀察4.3.3 數(shù)據(jù)分析由實驗數(shù)據(jù)可知,與4.2類似,TCP協(xié)議在執(zhí)行慢啟動和擁塞避免算法時,其窗口大小初值很小,但呈指數(shù)增長,但當超過所設定的最大窗口門限值(ssthresh)時,其窗口大小增長將呈現(xiàn)線性增長。在本次實驗數(shù)據(jù)中,在大約1m54s左右窗口值從將近1460bytes達到將近65535bytes呈指數(shù)型增長,即慢啟動。當達到門限值大約65535bytes之后,開始“加法增大”,即擁塞避免算法。在窗口大小到達大約72638by

25、tes后,應該是收到3個連續(xù)ACK,若根據(jù)3個重復的應答報文判斷丟包,并立即重傳丟失的分組,時ssthresh設置為當前擁塞窗口的一半。重傳丟失的數(shù)據(jù)包,并置cwndcwndndup(ndup為收到的重復ACK數(shù)),進入擁塞避免階段。若收到非重復的ACK時,cwndssthresh。進入擁塞避免階段。這就是快速重傳/快速恢復(Reno)。4.4 比較慢啟動,擁塞避免,快速重傳和恢復算法仿真選擇Results菜單中的Compare Results。如下圖,藍線為NoDrop,紅線為Tahoe,綠線為Reno:圖10 算法比較分析可以看出綠線Reno,數(shù)據(jù)傳輸最為穩(wěn)定。4.5 實驗總結(jié)分析以上實驗

26、結(jié)果,得出以下結(jié)論:從實驗數(shù)據(jù)可看出當新建TCP連接時,按cwnd大小發(fā)送數(shù)據(jù),每收到一個ACK確認,就增加一個數(shù)據(jù)包發(fā)送量,這樣慢啟動階段cwnd隨時間呈指數(shù)級增長。慢啟動采用逐漸增大cwnd的方法。為了防止cwnd的無限制增長引起網(wǎng)絡擁塞,cwnd>ssthresh時,使用擁塞避免算法,減緩cwnd的增長速度,其增長速度呈線性增長。在快重傳(Tahoe)算法中:如果收到3個連續(xù)ACK,則Tahoe進入快速重傳階段。根據(jù)3個重復的應答報文來判斷丟包,并立即重傳丟失的分組,此時置ssthresh為當前擁塞窗口的一半,轉(zhuǎn)入慢啟動??焖僦貍?快速恢復階段(Reno)算法中:若收到三個重復的A

27、CK,進入快速重傳/快速恢復,此時ssthresh設置為當前擁塞窗口的一半,重傳丟失的數(shù)據(jù)包,并置cwndcwndndup(ndup為收到的重復ACK數(shù)),并發(fā)新的數(shù)據(jù)包。若收到非重復的ACK時,cwndssthresh,進入擁塞避免階段。5 結(jié)束語Internet自二十世紀六十年代末出現(xiàn)以來,一直以驚人的速度快速增長。同時,伴隨著多媒體技術的飛速發(fā)展,Internet 已逐步由單一的數(shù)據(jù)傳送網(wǎng)向數(shù)據(jù),語音,圖象,視頻等多媒體信息的綜合傳輸網(wǎng)演化。在計算機網(wǎng)絡高速發(fā)展的今天,服務質(zhì)量是人們不可避免的問題。在其中,網(wǎng)絡的擁塞控制起著至關重要的作用。本文利用計算機網(wǎng)絡仿真軟件OPNET,分析TCP

28、擁塞控制協(xié)議中的四種不同算法,仿真TCP協(xié)議中用于擁塞控制的四種算法慢開始,擁塞避免,快速重傳和快速恢復,比較快速重傳和快速恢復(改進后的TCP)對于慢開始和擁塞避免(傳統(tǒng)的TCP)的改進效果。同時收集了數(shù)據(jù),繪出圖形,分析了它們的優(yōu)劣。網(wǎng)絡仿真技術是一種全新的網(wǎng)絡規(guī)劃設計方法,該技術以其獨特的技術手段,成為一種經(jīng)濟、有效和其他傳統(tǒng)方法不可替代的網(wǎng)絡設計的有力工具??梢灶A見,隨著數(shù)據(jù)網(wǎng)絡的日趨復雜、網(wǎng)絡規(guī)模的日漸龐大,對網(wǎng)絡仿真技術的需求必交越來越迫切,網(wǎng)絡仿真的應用也將越來越廣泛。我國雖然起步較晚,但是Internet網(wǎng)絡的迅猛發(fā)展必將強勁地拉動網(wǎng)絡仿真技術的研究和應用。我們相信,未來數(shù)年將

29、是網(wǎng)絡仿真技術蓬勃發(fā)展的時期,今后網(wǎng)絡仿真技術必將成為數(shù)據(jù)網(wǎng)絡規(guī)劃不可缺少的工具。參考文獻1 謝希仁,陸鳴,張興元.計算機網(wǎng)絡M.北京:電子工業(yè)出版社,20042 林闖,單志廣,任豐源.計算機網(wǎng)絡的服務質(zhì)量M.北京:清華大學出版社,20043 王承恕.通信網(wǎng)基礎M.北京:人民郵電出版社,1999:116-144.4 T. Kelly. Scallable TCP: Improving Performance in High Speed Wide Area NetworksJ.ACM Computer Communications Review, 2003, 33(2): 83291. 5 Ye

30、e-Ting Li, Douglas Leith and Eobert N. Shorten. Experimental Evaluation of TCP Protocols for High-Speed NetworksJ. 6 Kevin Fall and Sally Floyd “ Simulation-based Comparisons of Tahoe, Reno, and SACK TCP”. Lawrence Berkeley National Laboratory7 王文博,張金文. OPNET Modeler與網(wǎng)絡仿真M. 人民郵電出版社,2003年10月8 龍華.OPNET Modeler與計算機網(wǎng)絡仿真M. 西安:西安電子科技大學出版社, 2006:31-57.9 魏鴻毅, 慕曉冬, 夏薇.基于OPNET的無線通信網(wǎng)絡性能研究J. 微計算機信息, 2008,24(18):115-117.10 郭艷玲,饒 敏,周淑秋.網(wǎng)絡技術教程M.北京航空航天大學出版社, 200111 于宏毅. 無線移動自組織網(wǎng)M. 北京: 人民郵電出版社, 2004:32-35. 12 馮言志, 馮元, 李金.基于OPNET的Ad Hoc

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論