實(shí)驗(yàn)6 使用Wireshark分析UDP

《實(shí)驗(yàn)6 使用Wireshark分析UDP》由會員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、實(shí)驗(yàn)六使用Wireshark分析UDP一、實(shí)驗(yàn)?zāi)康谋容^TCP和UDP協(xié)議的不同二、實(shí)驗(yàn)環(huán)境與因特網(wǎng)連接的計算機(jī)，操作系統(tǒng)為Windows，安裝有Wireshark、IE等軟件。三、實(shí)驗(yàn)步驟1、打開兩次TCP流的有關(guān)跟蹤記錄，保存在tcp_2transmit.cap中，并打開兩次UDP流中的有關(guān)跟蹤文件udp_2transmit.cap。如圖所示：圖1：TCP流跟蹤記錄圖2：UDP流跟蹤記錄2、分析此數(shù)據(jù)包：（1）TCP傳輸?shù)恼?shù)據(jù)：tcp_2transmit.cap文件的分組1到13中顯示了TCP連接。這個流中的大部分信息與前面的實(shí)驗(yàn)相同。我們在分組1到分組3中看到了打開連接的三次

2、握手。分組10到分組13顯示的則是連接的終止。我們看到分組10既是一個帶有FIN標(biāo)志的請求終止連接的分組，又是一個最后1080個字節(jié)的（序號是3921—5000）的重傳。TCP將應(yīng)用程序?qū)懭牒喜⒌揭粋€字節(jié)流中。它并不會嘗試維持原有應(yīng)用程序?qū)懭说倪吔缰?。我們注意到TCP并不會在單個分組中傳送1000字節(jié)的應(yīng)用程序?qū)懭搿Ｇ?000個字節(jié)會在分組4種被發(fā)送，而分組5則包含了1460個字節(jié)的數(shù)據(jù)-----一些來自第二個緩沖區(qū)，而另一些來自第三個緩沖區(qū)。分組7中含有1460個字節(jié)而分組8中則包含剩余的1080個字節(jié)。（5000-1000-1460-1460=1080）我們注意到實(shí)際報告上的2.

3、48秒是從初始化連接的分組1開始到關(guān)閉連接的分組10結(jié)束。分組11—13未必要計入接收端應(yīng)用程序的時間內(nèi)，因?yàn)橐坏┙邮盏降谝粋€FIN，TCP層便馬上發(fā)送一個關(guān)閉連接的信號。分組11—13只可能由每臺計算機(jī)操作系統(tǒng)得TCP層后臺傳輸。如果我們注意到第一個包含數(shù)據(jù)的分組4和最后一個分組8之間的時間，我們就大約計算出和由UDP接收端所報告的0.01秒相同的時間。這樣的話，增加TCP傳輸時間的主要原因就是分組10中的重傳。公平的說，UDP是幸運(yùn)的，因?yàn)樗械姆纸M都在第一時間被接受了。在這個跟蹤文件中，另一個值得注意的是沒有包含數(shù)據(jù)的分組的數(shù)量。所有來自接收端的分組和幾個來自發(fā)送端的分組只包

4、含了TCP報文段的首部?？偟膩碚f（包括重傳）一共發(fā)送了6822個字節(jié)來支持5000個字節(jié)的數(shù)據(jù)傳輸。這個開銷正好36﹪。(2)UDP正常數(shù)據(jù)傳輸現(xiàn)在我們來觀察UDP流，在udp_transmit.cap文件的分組1到分組11中顯示。雖然像TCP流那樣傳輸了相同的數(shù)據(jù)，但是在這個跟蹤文件中還是很多的不同。和TCP不同，UDP是一個無連接的傳輸協(xié)議。TCP用SYN分組和SYNACK分組來顯示地打開一個連接，而UDP卻直接開始發(fā)送包含數(shù)據(jù)的分組。同樣，TCP用FIN分組和FINACK分組來顯示地關(guān)閉一個連接，而UDP卻只簡單地停止包含數(shù)據(jù)的分組的傳輸。為了解決這個問題，在文件udp_2tr

5、ansmit.cap俘獲的分組中，采取的辦法是ttcp發(fā)送端發(fā)送一個只包含4個字節(jié)的特殊UDP數(shù)據(jù)報來模擬連接建立和連接終止。在發(fā)送任何數(shù)據(jù)之前，發(fā)送端總是發(fā)送一個只包含4個字節(jié)的特殊數(shù)據(jù)報（分組1），而在發(fā)送完所有的數(shù)據(jù)之后，發(fā)送端又發(fā)送額外的5個分組（分組7-11）。接收端也使用第一個特殊的數(shù)據(jù)報來啟動數(shù)據(jù)傳輸?shù)挠嫊r器。如果這個特殊的數(shù)據(jù)報丟失了，它可能用真實(shí)數(shù)據(jù)的第一個分組計時器。不過，如果接收端沒有看到這個特殊的數(shù)據(jù)報，它就不能精確地確定數(shù)據(jù)傳輸?shù)拈_始和傳輸?shù)乃袝r間。與TCP不同，UDP在傳輸?shù)臄?shù)據(jù)中，不會加上序號，因此對于接收端來說不可能確定丟失和重排序重傳的情況。類似的

6、，接收端根據(jù)最后的特殊數(shù)據(jù)報來停止數(shù)據(jù)傳輸計時器。當(dāng)接收端接收到這5個包中的任一個便停止計時，但是發(fā)送5個分組是因?yàn)樵趥鬏數(shù)倪^程中可能丟失其中的一些。如果5個分組全部丟失了，那么接收端便會無限制的等待更多數(shù)據(jù)的到來達(dá)。實(shí)際數(shù)據(jù)的傳輸是在分組2-6里。每一個分組都包含1000個字節(jié)。1000個字節(jié)的應(yīng)用程學(xué)寫入直接轉(zhuǎn)換成UDP數(shù)據(jù)報。另一方面，TCP并不打算保存應(yīng)用程序?qū)懭脒吔缍皇菍⑺鼈儾⑷胍粋€字節(jié)流中。與TCP不同，UDP沒有提供接收端到發(fā)送端的反饋。在TCP的例子里，接收端返回只包含有TCP報文段首部而沒有數(shù)據(jù)的報文段。首部本身則攜帶著關(guān)于哪些數(shù)據(jù)已經(jīng)被成功接收以及接收端能夠接收

7、多少數(shù)據(jù)的信息。我們已經(jīng)知道UDP不提供可靠的數(shù)據(jù)傳輸，因此并不要求什么數(shù)據(jù)已經(jīng)被成功接收的信息。它也不提供任何信息高速發(fā)送端降低速率，因?yàn)榻邮斩嘶蛘呔W(wǎng)絡(luò)本身已經(jīng)淹沒。雖然UDP本身并不提供接收端到發(fā)送端的反饋，但是我們確實(shí)看到幾個從接收端到發(fā)送端的ICMP分組（分組12—14）。ICMP是網(wǎng)絡(luò)層協(xié)議（IP）的一個伴隨協(xié)議，并且有提供一定控制和錯誤報告的功能。在這種情況下，ICMP分組暗示一些UDP數(shù)據(jù)報沒有被傳送到，因?yàn)槎丝诓豢蛇_(dá)。這就意味著當(dāng)數(shù)據(jù)報到達(dá)