第六章《網(wǎng)絡(luò)流量控制與擁塞控制的測試及分析》.docx

第六章 網(wǎng)絡(luò)流量控制與擁塞控制的測試及分析第六章 網(wǎng)絡(luò)流量控制與擁塞控制的測試及分析 6.1 網(wǎng)絡(luò)流量控制 6.1.1流量控制與滑動窗口 流量控制是指通過接收方的反饋來控制發(fā)送方發(fā)送速率的技術(shù)。當(dāng)接收方接收數(shù)據(jù)時，將數(shù)據(jù)存放在接收緩沖區(qū)內(nèi)，由于緩沖區(qū)的大小總是有限的，當(dāng)接收的數(shù)據(jù)量來得過快過多，接收方來不及處理，接收數(shù)據(jù)很快充滿緩沖區(qū)以致超過容量限度時，會產(chǎn)生接收緩沖區(qū)溢出，造成數(shù)據(jù)丟失。使用流量控制技術(shù)，可以防止接收方的緩沖區(qū)溢出。在接收方將要發(fā)生緩沖區(qū)溢出時，由接收方發(fā)送反饋信息給發(fā)送方:“我的接收緩沖將要溢出，請停止發(fā)送”，發(fā)送方收到反饋信息后會停止發(fā)送。當(dāng)接收方經(jīng)過一段時間的處理使接收緩沖騰空、能夠再接收數(shù)據(jù)時，會向發(fā)送方發(fā)送另一個反饋信息:“我的接收緩沖已有空，請繼續(xù)發(fā)送”，此時發(fā)送方就會繼續(xù)向接收方發(fā)送數(shù)據(jù)。 常用的流量控制方法有停等法和滑動窗口法，如果TCP協(xié)議在傳輸數(shù)據(jù)時采用停等法，每次發(fā)送端發(fā)送一個TCP報文段就必須等遠方的接收端確認后才能發(fā)送下一個報文段的話，由于網(wǎng)絡(luò)端端傳輸?shù)臅r延，將耗費大量時間用于等待對方確認，這樣會導(dǎo)致傳輸效率低下。TCP沒有采用停等法，而是采用了滑動窗口法進行流量控制。 和停等法相比，滑動窗口機制可以提高數(shù)據(jù)傳輸?shù)男剩湟话愎ぷ髟砣缦? , 發(fā)送的每個信息幀都有一個序號，設(shè)幀序號用n個二進制位表示，則幀序號從0到n2,1依次循環(huán)使用; , 發(fā)送方和接收方都具有一定容量的緩沖區(qū)(即窗口)，允許發(fā)送站連續(xù)發(fā)送多個幀而不需要等待應(yīng)答; , 發(fā)送窗口就是發(fā)送端允許連續(xù)發(fā)送的幀的序號表，發(fā)送端可以不等待應(yīng)答而連續(xù)發(fā)送的最大幀數(shù)稱為發(fā)送窗口的尺寸，其大小W表示在收到對方確認的信息之前，可T以連續(xù)發(fā)出的最多數(shù)據(jù)幀數(shù)，只有序號在窗口內(nèi)的幀才可以發(fā)送; , 接收窗口是接收方允許接收的幀的序號表，凡落在接收窗口內(nèi)的幀，接收方都必須處理，落在接收窗口外的幀被丟棄。接收方每次允許接收的幀數(shù)稱為接收窗口的尺寸，其大小W為可以連續(xù)接收的最多數(shù)據(jù)幀數(shù)，只有序號在窗口內(nèi)的幀才可以接收，R否則丟棄; , 發(fā)送方可連續(xù)發(fā)送多幀，每次發(fā)送的幀序號數(shù)為上次幀序號數(shù)加1，它必須位于發(fā)送窗口內(nèi)。發(fā)送方保存所有已發(fā)送、但未確認的數(shù)據(jù)幀，以備出錯重發(fā)。連續(xù)發(fā)出多幀后，因還未收到對方確認信息，發(fā)送窗口縮小;當(dāng)收到對方確認回答后，清除已確認的幀所占的幀緩沖區(qū)，因而發(fā)送窗口擴大; , 接收方接收數(shù)據(jù)幀后若未回答，表示此時幀數(shù)據(jù)還未交上層、其幀緩沖未釋放，故接收窗口縮小;若接收方對接收的數(shù)據(jù)幀確認回答后，表示幀數(shù)據(jù)已交上層，接收緩沖區(qū)空出，因此接收窗口相應(yīng)擴大; 圖6.1給出了窗口大小為7，幀序號為0,7的滑動窗口工作過程的示意圖，其中: (a) 為初始狀態(tài)時，發(fā)送方的發(fā)送窗口大小,7，接收方的接收窗口大小,7; (b) 為發(fā)送方發(fā)完0,1,2號幀、接收方收完0,1,2號幀后，發(fā)送窗口和接收窗口分別縮小3幀; (c) 為接收方處理完收到的0,1,2號幀后向發(fā)送方發(fā)出ACK n,3確認0,1,2號幀，接收窗口擴大3幀;發(fā)送方收到ACK n,3確認了0,1,2號幀，發(fā)送窗口也擴大3幀; (d) 為發(fā)送方發(fā)完3,4,5號幀后，發(fā)送窗口縮小3幀;接收方收到3,4號幀后向發(fā)送方發(fā)出ACK n,5確認3,4號幀，接收窗口擴大2幀; 圖6.1 滑動窗口的工作過程 TCP采用了與上圖類似的滑動窗口法進行流量控制，但流量控制不用幀序號計算而以數(shù)據(jù)字節(jié)的序號計算，接收窗口的大小以接收端接收緩沖區(qū)中的空余字節(jié)數(shù)計算，而不是以接收端可以接收的幀數(shù)計算，發(fā)送窗口的大小也是以發(fā)送緩沖區(qū)落在發(fā)送窗口內(nèi)可以發(fā)送的字節(jié)數(shù)計算。接收端用接收窗口中的空余字節(jié)數(shù)及時地向發(fā)送端作出反饋報告，以控制發(fā)送端的發(fā)送流量。 6.1.2 ITS-101滑動窗口機制的模擬 為了進行網(wǎng)絡(luò)的流量控制實驗，在ITS-101協(xié)議分析儀上設(shè)計了一種與TCP協(xié)議相近的KDP協(xié)議，來直觀地模擬TCP流量控制與擁塞控制等過程。KDP協(xié)議由調(diào)用本實驗預(yù)先設(shè)計的MDDL程序?qū)崿F(xiàn)，用戶不必了解它的實現(xiàn)方法。下面以兩臺ITS-101之間的數(shù)據(jù)流傳輸為例說明滑動窗口進行流量控制的工作過程。 (1)連通兩臺ITS-101的兩個Interface1接口，打開Network Message Browser并開啟IP數(shù)據(jù)包的監(jiān)聽功能，如圖6.2所示。 (2)將其中的一臺ITS1的Interface1接口IP地址設(shè)置為“192.168.1.1”，子網(wǎng)掩碼設(shè)置為“255.255.255.0”，模式選擇“Host”;另一臺ITS2的Interface1接口IP地址設(shè)置為“192.168.1.2”，子網(wǎng)掩碼也設(shè)置為“255.255.255.0”，模式也選擇“Host”。 圖6.2 開啟IP數(shù)據(jù)包的監(jiān)聽功能 (3)在Host1打開“C:XClientDataMddlTutorialEx12SlidingWindowSender.mddl”文件，按照(2)的設(shè)置修改源IP地址與目標(biāo)IP地址，如圖6.3所示，并“Save”保存。 圖6.3 修改SlidingWindowSender.mddl程序 (4)在Host2打開“C:XClientDataMddlTutorialEx12SlidingWindowReceiver.mddl”文件，也按照(2)的設(shè)置修改源IP地址與目標(biāo)IP地址，如圖6.4所示，并“Save”保存。 (5)在兩臺主機上分別點擊Reactor-Reset Reactor菜單，清除掉兩臺ITS內(nèi)的MDDL程序，然后將SlidingWindowSender.mddl用“Upld”按鈕上載到ITS1，將SlidingWindowReceiver.mddl上載到ITS2。 (6)打開ITS1的IP報文的發(fā)送窗口(IP Datagram Sender)。在第9欄協(xié)議(Protocol) 部分按下拉箭頭，選擇“User Defined”，并鍵入定義號“7”，這是ITS設(shè)計的KDP所使用的編號，不能用其它值代替。將目標(biāo)IP地址設(shè)置為 “192.168.1.2”，數(shù)據(jù)段部分輸入“check”。如圖6.5所示，輸入完成后點擊Send按鈕，發(fā)送該IP報文。 圖6.4 修改SlidingWindowReceiver.mddl程序 圖6.5 發(fā)送的IP報文格式 (7)在ITS1觀察Network Message Browser窗口，出現(xiàn)如圖6.6所示的記錄1,6。其中，第1條記錄是ITS-101在數(shù)據(jù)傳輸過程中產(chǎn)生的雜包，這里不需要考慮，用黑線劃掉(注意:下文中用黑線劃掉的傳輸記錄也是沒有意義的雜包)。以下介紹其余5條記錄的含義: , 2號記錄表示ITS1向ITS2正常發(fā)送了一個內(nèi)容為“check”的KDP報文(用戶自定義協(xié)議號7在報文瀏覽窗口TYPE欄顯示為“/C8”)，該報文的編號為“0x00”; , 4號記錄表示ITS2向ITS1發(fā)送“ACK01”報文，確認“0x00”號KDP報文已收到，希望ITS1下次發(fā)“0x01”號報文; , 3號記錄時間在4號記錄發(fā)生的時間之后，表示狀態(tài)為對方“ACK01”; , 5號記錄表示狀態(tài)為下面將發(fā)送編號為“0x01”的KDP報文; , 6號記錄表示狀態(tài)為當(dāng)前發(fā)送窗口可用大小(UWND:Usable Window Size)是3。 。 本實驗中，最大發(fā)送窗口和接收窗口都為3圖6.6 啟用滑動窗口后發(fā)送端觀測到的記錄 (8)再點擊圖6.5窗口的Send按鈕，發(fā)送一個相同的KDP報文，觀察到如圖6.6所示的記錄7,12，各記錄的含義與(1),(7)中的描述相似，UWND的大小仍為3。 (9)斷開ITS1與ITS2之間的連線，連續(xù)點擊圖6.5窗口的Send按鈕三次，發(fā)送三個內(nèi)容為“check”的KDP報文，再迅速重新連通ITS1與ITS2的Interface1接口，可以觀察到如圖6.6所示的記錄13,33，各條記錄的含義如下: , 14、16、18號記錄分別表示ITS1向ITS2先后發(fā)送了三個編號分別為“0x02”、“0x03”、“0x04”的KDP報文; , 19,21號記錄表示三個報文都沒有收到ACK報文，都先后進行了超時重傳，如果仍未連通，會繼續(xù)進行重傳; , 22,25號記錄表示此后鏈路重新連通，ITS1接收到ITS2發(fā)送的確認收到“0x02”號報文的“ACK03”報文，此時由于還未收到“0x03”、“0x04”號報文的ACK報文，UWND的大小變?yōu)?; , 26,29號記錄表示ITS1接收到ITS2發(fā)送的確認收到“0x03”號報文的“ACK04”報文，UWND的大小成為2; , 30,33號記錄表示ITS1接收到ITS2發(fā)送的確認收到“0x04”號報文的“ACK05”報文，UWND的大小恢復(fù)為3; (10)為了便于以下步驟的觀察，點擊工具欄的Reset按鈕，清除Network Message Browser窗口的記錄。 (11)再次斷開ITS1與ITS2之間的連線，發(fā)送一個編號為“0x05”的KDP報文，超時重傳4次(注意每次重傳的間隔時間)，此后丟棄該報文，不再重發(fā)，如圖6.7所示的記錄17。 (12)重新連通ITS1與ITS2的Interface1接口，發(fā)送一個編號為“0x06”的KDP報文，得到如圖6.7所示的記錄819，各條記錄的含義如下: 圖6.7 出現(xiàn)丟包后發(fā)送端觀測到的記錄 , 9號記錄表示ITS1向ITS2發(fā)送了“0x06”號的KDP報文; , 12號記錄表示ITS2向ITS1發(fā)送“ACK05”報文，希望ITS1發(fā)送“0x05”號報文; , 10號記錄的SACK06表示ITS1本應(yīng)該收到“0x06”號KDP報文的ACK，實際沒有收到，因為“0x05”號KDP報文沒有到達ITS2; , 11號記錄表示狀態(tài)為對方“ACK05”; , 13號記錄表示狀態(tài)為本方下次將發(fā)送“0x07”號KDP報文; , 14號記錄表示由于未收到“0x05”號和“0x06”號報文的ACK報文，這兩個報文仍然保持在發(fā)送窗口中，所以可用窗口UWND只有1; , 15,19號記錄表示ITS1四次超時重發(fā)“0x06”號報文，由于前面“0x05”號報文已被ITS1丟棄，而ITS2希望收“0x05”號報文，因此ITS1重傳4次“0x06”號報文失敗后也將其丟棄; (13)ITS1發(fā)送一個編號為“0x07”的KDP報文，得到如圖6.7所示的記錄2131，各條記錄的含義與(12)中的記錄相似。ITS2發(fā)給ITS1“ACK05”，仍然希望收“0x05”號報文。ITS1收不到ITS2的“ACK07”，因此四次超時重發(fā)“0x07”號報文，直到丟棄。由于ITS1發(fā)送窗口中“0x05”、“0x06”、“0x07”號報文都沒有收到ACK報文，都保持在發(fā)送窗口中，所以可用窗口UWND大小為0。 注意:如果重新進行實驗時，必須點擊Reactor-Reset Reactor菜單清除兩臺ITS內(nèi)的MDDL程序，然后將MDDL程序”Upld”重新上載一遍再進行實驗。這是因為該實驗中KDP報文的傳送是有序的，重新執(zhí)行后才會得到較好的效果。 6.2 網(wǎng)絡(luò)擁塞控制 6.2.1擁塞控制的方法 擁塞是由于網(wǎng)絡(luò)中的數(shù)據(jù)包傳輸過度，如大量數(shù)據(jù)包集中于一個或者多個路由節(jié)點引起傳輸延時過大。當(dāng)擁塞發(fā)生時，除了延時增加外，路由器還會保持數(shù)據(jù)包，直到它可以發(fā)送，這樣就浪費了大量的網(wǎng)絡(luò)資源。為了避免擁塞出現(xiàn)，TCP協(xié)議使用了下述機制:慢啟動(Slow-Start)、擁塞避免(Congestion Avoidance)和乘法減少(Multiplicative Decrease)，三個階段互相關(guān)聯(lián)、相結(jié)合使用。 TCP一方面保存每一個連接的接收窗口大小(對方接收緩沖區(qū)還有多少空間會在它送來的反饋報文里反映)。另一方面，為了進行擁塞控制，TCP在擁塞發(fā)生時，使用擁塞窗口(CWND，Congestion Window)來限制發(fā)送端發(fā)送數(shù)據(jù)的多少，公式6-1給出了發(fā)送窗口上限值的計算方法，實際允許的發(fā)送窗口應(yīng)等于擁塞窗口與接收窗口兩個窗口的小者。 (6-1) Allowed_Window,min(Receiver_advertisement, Congestion_window)TCP使用三個階段進行擁塞控制: (1)慢啟動階段:每當(dāng)一個新的TCP連接建立或是經(jīng)過一個擁塞期之后，如果要增加TCP報文段的流量，擁塞窗口CWND的計算都必須由CWND,1開始，即一開始先發(fā)送1個TCP報文段(以最大數(shù)據(jù)字段長度的報文段為單位計算，下同)，經(jīng)過報文往返后若沒有超時情況下收到ACK報文，擁塞窗口CWND的大小便增加1，變?yōu)?，因此第二次發(fā)送端發(fā)送2個TCP報文段，如果在超時前又收到ACK報文，則發(fā)送端對每一個發(fā)出報文的確認應(yīng)答擁塞窗口CWND便增加1，這樣CWND變?yōu)?，于是發(fā)送端第三次發(fā)送4個TCP報文段，依次類推，按每次2倍即指數(shù)增長的速度遞增擁塞窗口CWND。 (2)擁塞避免階段:當(dāng)擁塞窗口CWND增長到超過閾值SSTHRESH(Slow Start Threshod)時，便不再按指數(shù)增長而按照線性增長。如SSTHRESH,8，則擁塞窗口CWND為8時，發(fā)送端發(fā)出8個TCP報文段，當(dāng)8個報文確認應(yīng)答在超時前收到，則擁塞窗口只增加1，變?yōu)?，依次類推，擁塞窗口CWND每次按線性增長，變?yōu)?0，11，12，。隨著每次發(fā)送端發(fā)送注入到網(wǎng)絡(luò)里的TCP報文段增加，發(fā)送通路中的各段鏈路里報文段越來越多，這個過程不可能永遠持續(xù)下去，當(dāng)某次發(fā)送導(dǎo)致發(fā)送通路中的某段鏈路上出現(xiàn)飽和時，TCP報文段便會出現(xiàn)丟失，從而導(dǎo)致在發(fā)送端出現(xiàn)超時、收不到確認應(yīng)答。此時進入第三階段:乘法減少階段。 (3)乘法減少階段:當(dāng)發(fā)送超時發(fā)生后，TCP將閾值SSTHRESH減為當(dāng)時擁塞窗口CWND值的一半，并且將擁塞窗口CWND急速減小，重新置為1，此后又進入新一輪的慢啟動增長。 6.2.2 ITS-101擁塞控制機制的模擬 本實驗中，仍然使用KDP來直觀地模擬TCP擁塞控制機制。下面還是以兩臺ITS-101之間的數(shù)據(jù)流傳輸為例說明利用慢啟動、擁塞避免和乘法減少進行擁塞控制的工作過程。 (1)連通兩臺ITS-101的兩個Interface1接口，打開Network Message Browser并開啟IP數(shù)據(jù)包的監(jiān)聽功能，如圖6.2所示。 (2)將其中的一臺ITS1的Interface1接口IP地址設(shè)置為“192.168.1.1”，子網(wǎng)掩碼設(shè)置為“255.255.255.0”，模式選擇“Host”;另一臺ITS2的Interface1接口IP地址設(shè)置為“192.168.1.2”，子網(wǎng)掩碼也設(shè)置為“255.255.255.0”，模式也選擇“Host”。 (3)在Host1打開“C:XClientDataMddlTutorialEx13CongestionWindowSender.mddl”文件，按照圖6.8所示進行修改并保存。 圖6.8 修改CongestionWindowSender.mddl程序 (4)在Host2打開“C:XClientDataMddlTutorialEx13CongestionWindowReceiver.md dl”文件，按照圖6.9所示進行修改并保存。 圖6.9 修改CongestionWindowReceiver.mddl程序 (5)在兩臺主機上分別點擊Reactor-Reset Reactor菜單，清除掉兩臺ITS內(nèi)的MDDL程序，然后將CongestionWindowSender.mddl和CongestionWindowReceiver.mddl分別“Upld”上載到ITS1和ITS2。 (6)打開ITS1的IP Datagram Sender窗口。在第9欄協(xié)議(Protocol)部分按下拉箭頭，選擇“User Defined”，并鍵入定義號“7”，將目標(biāo)IP地址設(shè)置為 “192.168.1.2”，數(shù)據(jù)段部分輸入“check”。與圖6.5所示相同，輸入完成后點擊Send按鈕，發(fā)送該KDP報文。 (7)在ITS1上觀察Network Message Browser窗口，出現(xiàn)如圖6.10所示的記錄1,5。本節(jié)中用黑線劃掉的傳輸記錄也是沒有意義的雜包。各條記錄的含義如下: , 2號記錄表示ITS1向ITS2發(fā)送了一個內(nèi)容為“check”、編號為“0x00”的KDP報文(用戶自定義協(xié)議號7在報文瀏覽窗口TYPE欄顯示為“/C8”); , 4號記錄表示ITS2向ITS1發(fā)送確認“0x00”號KDP報文的“ACK01”報文，該記錄發(fā)生的時間在3號記錄發(fā)生的時間之前; , 3號記錄表示狀態(tài)為對方“ACK01”; , 5號記錄表示當(dāng)前擁塞窗口(CWND)的大小是1，即慢啟動初始值為1。 (8)點擊圖6.5窗口的Send按鈕，再發(fā)送一個KDP報文，觀察到如圖6.10所示的記錄6,10，各記錄的含義與(7)相似，CWND的值按指數(shù)增長，結(jié)果變?yōu)榱?012,002。 (9)再發(fā)送一個KDP報文，觀察到如圖6.10所示的記錄11,15，CWND的值仍然按指數(shù)增長，結(jié)果變?yōu)榱?022,004。 (10)再發(fā)送一個KDP報文，觀察到如圖6.10所示的記錄16,20，此時CWND的值成線性增長增加1，變?yōu)?04，1,005。說明已過慢啟動門限(SSTHRESH)值4，進入擁塞避免階段。 (11)再依次發(fā)送KDP報文，觀察到如圖6.10所示的記錄21,30，CWND的值仍然按線性增長，每次增加1，依次變?yōu)?06、007。 圖6.10 KDP擁塞控制時ITS1觀測到的記錄 圖6.11 連續(xù)發(fā)送KDP報文后ITS1觀測到的記錄 (12)再依次發(fā)送14個KDP報文，共計觀測到100條記錄，最后10條記錄如圖6.11所示。此時CWND的大小依然按線性增長，每次加1，最后一次為007，114,21。 (13)斷開ITS1與ITS2之間的連線，用來人工模擬擁塞現(xiàn)象發(fā)生，再發(fā)送一個KDP報文，此時收不到對方確認的ACK。當(dāng)出現(xiàn)SSTHRESH的值后，再迅速重新連通ITS1與ITS2的Interface1接口，可以觀察到如圖6.12所示的記錄101,107，各條記錄的含義如下: , 102號記錄表示ITS1向ITS2發(fā)送了一個編號為“0x14”的KDP報文; , 103號記錄表示連接斷開，ITS1發(fā)送超時未收到ACK，認為產(chǎn)生了擁塞，向ITS2重發(fā)編號為“0x14”的KDP報文; , 104號記錄表示ITS1將SSTHRESH的值調(diào)整為CWND/2=21/2?11; , 105號記錄表示連接重新連通，ITS1狀態(tài)為“ACK021”(即希望下次發(fā)送“0x15”號報文); , 106號記錄表示ITS2向ITS1發(fā)送“ACK0x15”報文; , 107號記錄表示擁塞發(fā)送后，擁塞窗口CWND的值又調(diào)整為慢啟動的初始值1。 圖6.12 擁塞發(fā)生后發(fā)送端觀測到的記錄 圖6.13 CWND超過閾值后發(fā)送端觀測到的記錄 (14)再依次發(fā)送三個相同的KDP報文，觀察到如圖6.12所示的記錄108,122，此時由于CWND小于SSTHRESH，它的值成指數(shù)增長，依次變?yōu)?012,002、0022,004、0042,008。 (15)再發(fā)送一個KDP報文，觀察到如圖6.12所示的記錄123,127，此時CWND2,0082,016將會超過SSTHRESH值011，它的值調(diào)整為011。 (16)再依次發(fā)送5個KDP報文，觀察到如圖6.13所示的記錄，此時由于CWND的值超過SSTHRESH值，它的值按線性增長，每次增加1，依次變?yōu)榱?11、012、013、014、015、016。 注意:在如果重新進行該實驗時，也必須點擊Reactor-Reset Reactor菜單清除兩臺ITS內(nèi)的MDDL程序，然后將MDDL程序重新上載一遍再進行實驗，才會得到正確的效果。 6.3 網(wǎng)絡(luò)干擾模擬 6.3.1 網(wǎng)絡(luò)干擾 這里的網(wǎng)絡(luò)干擾可以是由外界各種因素對通信線路或者通信設(shè)備產(chǎn)生的干擾，也可以是由于網(wǎng)絡(luò)流量的變化對線路與設(shè)備的傳輸能力產(chǎn)生的干擾。流量控制與擁塞控制一般需要在受到干擾的網(wǎng)絡(luò)中進行測試，用前述方法測試網(wǎng)絡(luò)時，只是在發(fā)送端與接收端之間使用手工斷開連接的方式來模擬網(wǎng)絡(luò)干擾?使得接收端收不到報文、發(fā)送端也收不到接收端的ACK確認報文，因而導(dǎo)致發(fā)送端超時重發(fā)。使用這樣的測試方法，發(fā)送端既不容易控制，也與實際網(wǎng)絡(luò)有一定差距。 為了模擬一種更為真實的網(wǎng)絡(luò)環(huán)境，可在前述實驗中，在兩臺ITS-101實驗儀中間再插入一臺ITS-101實驗儀，設(shè)置為Gateway工作方式，模擬通路中的路由器。并編制相應(yīng)的mddl程序“Upld”到該臺實驗儀中，模擬通路中路由器可能遭受到的各種網(wǎng)絡(luò)干擾。編制相應(yīng)程序名的mddl程序，分別用來模擬以下干擾情形之一: , Packet Lost:網(wǎng)絡(luò)傳輸數(shù)據(jù)時報文丟失; , Packet Delay:網(wǎng)絡(luò)傳輸數(shù)據(jù)時報文延遲; , Packet Error:網(wǎng)絡(luò)傳輸數(shù)據(jù)時候報文損壞; , Bandwidth Limit:網(wǎng)絡(luò)在某時段某鏈路上所能發(fā)送的報文數(shù)量與大小受限。 下面以數(shù)據(jù)包丟失和數(shù)據(jù)包延遲為例，說明通路中加插一臺ITS-101以模擬路由器及相連鏈路受干擾情形的實現(xiàn)方法，為流量和擁塞控制實驗提供一個更逼真的網(wǎng)絡(luò)測試環(huán)境。 6.3.2 運用ITS-101模擬數(shù)據(jù)包丟失 下面以一臺ITS-101模擬中間路由器丟包，首尾兩臺ITS-101分別模擬數(shù)據(jù)包發(fā)送端和接收端，說明數(shù)據(jù)包丟失的模擬過程。 (1)按照圖6.14所示的拓撲結(jié)構(gòu)連接三臺ITS-101，打開Network Message Browser并開啟IP數(shù)據(jù)包和以太幀的監(jiān)聽功能。 圖6.14 本實驗網(wǎng)絡(luò)拓撲結(jié)構(gòu) (2)設(shè)置ITS1的IP地址和路由表，如圖6.15所示，點擊“Set&Close”按鈕保存。 圖6.15 ITS1的網(wǎng)絡(luò)配置 (3)設(shè)置ITS3的IP地址和路由表，如圖6.16所示，點擊“Set&Close”按鈕保存。 圖6.16 ITS3的網(wǎng)絡(luò)配置 (4)設(shè)置ITS2的IP地址，并選定“Gateway”模式，點擊“Set&Close”按鈕保存。 (5)在Host2打開“C:XClientDataMddlTutorialEx10PktLost.mddl”文件，該文件中的圖6.18所示的語句可以產(chǎn)生50,的丟包率，點擊“Upld”按鈕將該文件上載到ITS2。 (6)在Host1上編輯ICMP數(shù)據(jù)報文，如圖6.19所示，輸入完成后點擊“Send”按鈕將該報文從ITS1的Interface1接口發(fā)送向ITS3的Interface2接口。 (7)連續(xù)點擊“Send”按鈕，發(fā)送多個圖6.19所示的ICMP報文，可以發(fā)現(xiàn)有許多報文收不到回復(fù)，這是因為ITS1發(fā)送的報文和從ITS3回復(fù)的報文有50,的概率被丟棄。 圖6.17 ITS2的網(wǎng)絡(luò)配置 圖6.18 上載PktLost.mddl程序 6.3.3 運用ITS-101模擬數(shù)據(jù)包延遲 下面以一臺ITS-101模擬中間路由器上數(shù)據(jù)包延遲，首尾兩臺ITS-101分別模擬數(shù)據(jù)包發(fā)送端和接收端，說明數(shù)據(jù)包延遲的模擬過程。 (1),(4)與6.3.2中的(1),(4)操作相同。 (5)在Host2點擊Reactor-Reset Reactor菜單清除ITS2內(nèi)存中以前的MDDL程序，然后打開“C:XClientDataMddlTutorialEx10PktDelay.mddl”文件。該文件使用與PktLost.mddl相同的方法產(chǎn)生了50,的概率，但是這50,概率的數(shù)據(jù)包沒有被丟棄，而是被延遲了1秒傳送。點擊“Upld”按鈕將該文件上載到ITS2。 圖6.19 發(fā)送的ICMP報文格式 (6)由ITS1向ITS3連續(xù)發(fā)送6個圖6.19所示的ICMP報文，得到如圖6.20所示的數(shù)據(jù)包檢測記錄?？梢钥闯?，第2、3個ICMP報文的回復(fù)報文基本沒有延遲;第1、5、6個ICMP報文的回復(fù)報文延遲了大約1秒;第4個ICMP報文的回復(fù)報文延遲了大約2秒。 圖6.20 延遲發(fā)生后發(fā)送端觀測到的記錄 6.4 實驗六 網(wǎng)絡(luò)流量控制與擁塞控制的測試及分析 6.4.1 實驗?zāi)康?掌握運用滑動窗口機制進行流量控制的方法，掌握運用慢啟動、擁塞避免和乘法減小三階段機制進行擁塞控制的方法。 6.4.2 實驗準備 (1)實驗設(shè)備 , TCP/IP通信協(xié)議實驗系統(tǒng)一套; , 裝有ITS-101軟件的PC機3臺。 (2)預(yù)備知識 , 熟悉TCP流量控制的工作原理，學(xué)習(xí)運用ITS-101模擬滑動窗口機制進行流量控制的方法; , 熟悉TCP擁塞控制的工作原理，學(xué)習(xí)運用ITS-101模擬慢啟動、擁塞避免和乘法減小三階段機制進行擁塞控制的方法; , 學(xué)習(xí)運用在通路中間加插ITS-101、模擬路由器上數(shù)據(jù)包丟失和數(shù)據(jù)包延遲的方法。 6.4.3 實驗內(nèi)容 圖6.21 實驗網(wǎng)絡(luò)拓撲結(jié)構(gòu) (1)ITS-101路由器丟包模擬 , 按照圖6.21拓撲連接網(wǎng)絡(luò)，設(shè)置IP地址和路由。 , 在ITS2上載“C:XClientDataMddlTutorialEx10PktLost4.mddl”文件。該程序上載后，從ITS1發(fā)出的報文經(jīng)過ITS2向ITS3轉(zhuǎn)發(fā)時，第4，5n個報文會被丟棄(n,0, 1, 2, 3, 4, )。 , 從ITS1向ITS3發(fā)送圖6.19所示的ICMP報文，觀察數(shù)據(jù)包丟棄情況，檢查結(jié)果是否與上述說明相符。 (2)ITS-101流量控制測試 , 參照圖6.3，按圖6.21拓撲上給出的新地址，將“SlidingWindowSender.mddl”程序中發(fā)送信包的源、目的地址修改為新的ITS1、ITS3地址，然后上載到ITS1。 , 將“PktLost4.mddl”上載到ITS2。 , 參照圖6.4，按圖6.21拓撲上給出的新地址，將“SlidingWindowReceiver.mddl” 程序中發(fā)送確認信包的源、目的地址修改為新的ITS3、ITS1地址，然后上載到ITS3。 , 使用ITS1發(fā)送如圖6.5所示的KDP報文，在發(fā)送端和接收端觀察數(shù)據(jù)包傳輸狀況，記錄UWND的值。 , 連續(xù)發(fā)送相同的KDP報文，記錄發(fā)送端UWN