TCP仿真(OPNET網(wǎng)絡仿真實驗)

高級網(wǎng)絡技術(shù)實驗報告高級網(wǎng)絡技術(shù)第五次實驗實驗名稱：TCP仿真（OPNET網(wǎng)絡仿真實驗）姓 名：學 號：實驗時間：實驗地點：目錄685一、實驗目的 實驗目的仿真TCP協(xié)議中用于擁塞控制的四種算法——慢開始，擁塞避免，快速重傳和快速恢復，比較快速重傳和快速恢復（改進后的TCP）對于慢開始和擁塞避免（傳統(tǒng)的TCP）的改進效果。實驗內(nèi)容參考文件“Lab_Exercices_Modeler.pdf”的“實驗四TCP仿真”，完成以下實驗：在沒有丟包的情況下，只使用慢開始和擁塞避免，觀察擁塞窗口大小的變化；在有丟包的情況下，同時使用四種算法，觀察擁塞窗口大小的變化；增大丟包率，比較改進前和改進后的TCP吞吐量。實驗設備硬件：PC機一臺軟件：網(wǎng)絡模擬軟件OPNET注意事項opnet是款功能強大的網(wǎng)絡仿真商業(yè)軟件，但其提供用于教育的免費版本。請各位同學們到opnet官方網(wǎng)站：，注冊、下載并安裝仿真軟件。我所安裝的是ITG_Academic_Edition_v2000，即opnet的9.1.A版本的教育版。實驗步驟與結(jié)果Lab1:慢開始與擁塞避免算法仿真實驗步驟啟動OPNET建立新的工程和場景新建名為CHAI_TCP的工程和名為NoDrop的場景，并均在InitialTopology中選擇CreateEmptyScenario，在ChooseNetworkScale中選擇ChooseFromMaps，在ChooseMap中選擇europe，然后一直Next到成功建立scenario。如下列截圖所示：配置Applicationdefination 選中應用定義(Applicationdefination)，按下圖定義：配置Profiledefination選中業(yè)務規(guī)格定義(Profiledefination)，，按下圖：建立巴黎子網(wǎng)并配置在巴黎地區(qū)添加subnet，并在子網(wǎng)中添加1個ethernet_server和1個ethernet4_slip8_gtwy，二者用100BaseT相連，如下圖：配置ethernet_server：配置ethernet4_slip8_gtwy：建立斯德哥爾摩子網(wǎng)并配置在斯德哥爾摩地區(qū)添加subnet，并在子網(wǎng)中添加1個ethernet_wkstn和1個ethernet4_slip8_gtwy，二者用100BaseT相連，如下圖：配置ethernet_wkstn：配置ethernet4_slip8_gtwy：創(chuàng)建IP云并配置，如圖：總拓撲圖用PPP_DS3連接Parissubnet和Europa_InternetIPCloud：用PPP_DS3連接Stockholmsubnet和Europa_InternetIPCloud：設置所要收集的統(tǒng)計量在面板上選擇Simulation，在下拉菜單中選擇ChooseIndividualStatistics，在彈出的窗口中，可以看出共有三類Statistics，在NodeStatistics選擇如圖所示的選項：仿真 點擊，按下圖配置：點擊Run,運行成功。在中可以查看實驗數(shù)據(jù)。（二）實驗數(shù)據(jù)CongestionWindowSize：（三）數(shù)據(jù)分析 由實驗數(shù)據(jù)可知，TCP協(xié)議在執(zhí)行慢開始和擁塞避免算法時，其窗口大小初值很小，但呈指數(shù)增長，但當超過所設定的最大窗口門限值（ssthresh）時，其窗口大小增長將呈現(xiàn)線性增長，即執(zhí)行擁塞避免算法。 在我的實驗數(shù)據(jù)中，在大約1m54s左右窗口值從將近1460bytes達到將近65535bytes呈指數(shù)型增長，即慢開始。當達到門限值大約65535bytes之后，開始“加法增大”，即擁塞避免算法。Lab2:同時使用慢開始，擁塞避免和快速重傳算法仿真實驗步驟復制Lab1中場景在Scenario菜單中選擇DuplicateScenario并命名新場景為Tahoe，即出現(xiàn)與剛才網(wǎng)絡模型一模一樣的場景。變更IPCloud的設置 右鍵點擊IPCloud,EuropaInternet,再選擇EditAttributes，設定丟包率PacketDiscardRatio為0.5%.如圖：變更Paris子網(wǎng)的設置雙擊進入Paris子網(wǎng)，右鍵點擊Server_Paris,再選擇EditAttributes。在TCPParameters的選項中，設置FastRetransmit為Enabled，如圖：仿真如Lab1:實驗數(shù)據(jù)CongestionWindowSize：數(shù)據(jù)分析 由實驗數(shù)據(jù)可知，與Lab1類似，TCP協(xié)議在執(zhí)行慢開始和擁塞避免算法時，其窗口大小初值很小，但呈指數(shù)增長，但當超過所設定的最大窗口門限值（ssthresh）時，其窗口大小增長將呈現(xiàn)線性增長。 在我的實驗數(shù)據(jù)中，在大約1m54s左右窗口值從將近1460bytes達到將近65535bytes呈指數(shù)型增長，即慢開始。當達到門限值大約65535bytes之后，開始“加法增大”，即擁塞避免算法。在窗口大小到達大約72725bytes后，應該是收到3個連續(xù)ACK，根據(jù)3個重復的應答報文判斷丟包，并立即重傳丟失的分組，此時置ssthresh為當前擁塞窗口72725bytes的一半，這就是快重傳（Tahoe），然后再轉(zhuǎn)入慢開始。Lab3:同時使用慢開始，擁塞避免，快速重傳和快速恢復算法仿真實驗步驟復制Lab2中場景在Scenario菜單中選擇DuplicateScenario并命名新場景為Reno，即出現(xiàn)與剛才網(wǎng)絡模型一模一樣的場景。變更Paris子網(wǎng)的設置雙擊進入Paris子網(wǎng)，右鍵點擊Server_Paris,再選擇EditAttributes。在TCPParameters的選項中，設置FastRecovery為Reno，如圖：仿真如Lab2:（二）實驗數(shù)據(jù)CongestionWindowSize：（三）數(shù)據(jù)分析 由實驗數(shù)據(jù)可知，與Lab2類似，TCP協(xié)議在執(zhí)行慢開始和擁塞避免算法時，其窗口大小初值很小，但呈指數(shù)增長，但當超過所設定的最大窗口門限值（ssthresh）時，其窗口大小增長將呈現(xiàn)線性增長。 在我的實驗數(shù)據(jù)中，在大約1m54s左右窗口值從將近1460bytes達到將近65535bytes呈指數(shù)型增長，即慢開始。當達到門限值大約65535bytes之后，開始“加法增大”，即擁塞避免算法。在窗口大小到達大約72638bytes后，應該是收到3個連續(xù)ACK，若根據(jù)3個重復的應答報文判斷丟包，并立即重傳丟失的分組，時ssthresh設置為當前擁塞窗口的一半。重傳丟失的數(shù)據(jù)包，并置cwnd＝cwnd＋ndup(ndup為收到的重復ACK數(shù))，進入擁塞避免階段。若收到非重復的ACK時，cwnd＝ssthresh。進入擁塞避免階段。這就是快速重傳/快速恢復（Reno）?？傮w比較慢開始，擁塞避免，快速重傳和快速恢復算法仿真選擇Results菜單中的CompareResults。如下圖，藍線為NoDrop，紅線為Tahoe，綠線為Reno?？梢钥闯鼍G線Reno，數(shù)據(jù)傳輸最為穩(wěn)定。詳細分析見實驗總結(jié)。六、實驗總結(jié)分析以上實驗結(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）算法中：若收到三個重復的ACK，進入快速重傳/快速恢復，此時ssthresh設置為當前擁塞窗口的一半，重傳丟失的數(shù)據(jù)包，并置cwnd＝cwnd＋ndup(ndup為收到的重復ACK數(shù))，并發(fā)新的數(shù)據(jù)包。若收到非重復的ACK時，cwnd＝ssthresh，進入擁塞避免階段。解釋為什么在無線鏈路上運行TCP協(xié)議時最好采用改進后的TCP。（提示：無線鏈路的誤碼率一般較高。）答：TCP假定所有的包丟失都是由擁塞引起的，但在無線鏈路中這個假設不再可靠。無線鏈路上誤碼率較高，帶寬又比較低，同時無線環(huán)境中由于存在較強的突發(fā)干擾和隨機干擾，信道質(zhì)量也在不斷變化，數(shù)據(jù)包的丟失往往比有線鏈路嚴重的多。改進后的TCP可以針對丟包，進行快速重傳和快速恢復，是數(shù)據(jù)傳輸很穩(wěn)定，保持鏈路通暢。相對于原始慢啟動、擁塞控制、快速重傳、快速恢復，后人做了哪些改進？答：最初由V.Jacobson在1988年的論文中提出的TCP的擁塞控制由“慢啟動(Slowstart)”和“擁塞避免(Congestionavoidance)”組成，后來TCPReno版本中又針對性的加入了“快速重傳(Fastretransmit)”、“快速恢復(FastRecovery)”算法，再后來在TCPNewReno中又對“快速恢復”算法進行了改進，近些年又出現(xiàn)了選擇性應答(selectiveacknowledgement,SACK)算法。初期慢啟動，擁塞避免，快速重傳和快速恢復算法見（1）。但從快速恢復的主要步驟看出Reno的快速重傳算法是針對一個包的重傳情況的，然而在實際中，一個重傳超時可能導致許多的數(shù)據(jù)包的重傳，因此當多個數(shù)據(jù)包從一個數(shù)據(jù)窗口中丟失時并且觸發(fā)快速重傳和快速恢復算法時，問題就產(chǎn)生了。因此，人們對其進行了改進，使其可以恢復一個窗口內(nèi)多個包丟失的情況。具體來講就是：Reno在收到一個新的數(shù)據(jù)的ACK時就退出了快速恢復狀態(tài)了，而改進后的需要收到該窗口內(nèi)所有數(shù)據(jù)包的確認后才會退出快速恢復狀態(tài)，從而更一步提高吞吐量。

SACK算法就是改變TCP的確認機制，最初的TCP只確認當前已連續(xù)收到的數(shù)據(jù)，SACK則把亂序等信息會全部告訴對方，從而減少數(shù)據(jù)發(fā)送方重傳的盲目性。比如說序號1，2，3，5，7的數(shù)據(jù)收到了，那么普通的ACK只會確認序列號4，而SACK會把當前的5，7已經(jīng)收到的信息在SACK選項里面告知對端，從而提高性能，當使用SACK的時候，NewReno算法可以不使用，因為SACK本身攜帶的信息就可以使得發(fā)送方有足夠的信息來知道需要重傳哪些包，而不需要重傳哪些包。本試驗中你們使用的快速重傳、快速恢復、慢啟動、擁塞控制的算法和書上講的是一樣的嗎？有什么算法上的不同？本實驗采用的是早期本的傳統(tǒng)的TCP擁塞控制算法。其核心思想如下：Tahoe算法核心：包括3個基本的擁塞控制算法：根據(jù)3個重復的應答報文來判斷丟包，減少了超時重傳的發(fā)