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

1、實(shí)驗(yàn)六 使用Wireshark分析UDP一、實(shí)驗(yàn)?zāi)康谋容^TCP和UDP協(xié)議的不同二、實(shí)驗(yàn)環(huán)境與因特網(wǎng)連接的計(jì)算機(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é)的（序號是39215000）的重傳。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í)際報(bào)告上的2.48秒是從初始化連接的分

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

4、重傳）一共發(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分組和SYN ACK分組來顯示地打開一個連接，而UDP卻直接開始發(fā)送包含數(shù)據(jù)的分組。同樣，TCP用FIN分組和FIN ACK分組來顯示地關(guān)閉一個連接，而UDP卻只簡單地停止包含數(shù)據(jù)的分組的傳輸。為了解決這個問題，在文件udp_2transmit.cap俘獲的分組中，采取的辦法

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

6、當(dāng)接收端接收到這5個包中的任一個便停止計(jì)時(shí)，但是發(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ù)報(bào)。另一方面，TCP并不打算保存應(yīng)用程序?qū)懭脒吔缍皇菍⑺鼈儾⑷胍粋€字節(jié)流中。與TCP不同，UDP沒有提供接收端到發(fā)送端的反饋。在TCP的例子里，接收端返回只包含有TCP報(bào)文段首部而沒有數(shù)據(jù)的報(bào)文段。首部本身則攜帶著關(guān)于哪些數(shù)據(jù)已經(jīng)被成功接收以及接收端能夠接收多少數(shù)據(jù)的信息。我們已經(jīng)知道UDP不提供可靠的數(shù)據(jù)傳輸，因此

7、并不要求什么數(shù)據(jù)已經(jīng)被成功接收的信息。它也不提供任何信息高速發(fā)送端降低速率，因?yàn)榻邮斩嘶蛘呔W(wǎng)絡(luò)本身已經(jīng)淹沒。雖然UDP本身并不提供接收端到發(fā)送端的反饋，但是我們確實(shí)看到幾個從接收端到發(fā)送端的ICMP分組（分組1214）。ICMP是網(wǎng)絡(luò)層協(xié)議（IP）的一個伴隨協(xié)議，并且有提供一定控制和錯誤報(bào)告的功能。在這種情況下，ICMP分組暗示一些UDP數(shù)據(jù)報(bào)沒有被傳送到，因?yàn)槎丝诓豢蛇_(dá)。這就意味著當(dāng)數(shù)據(jù)報(bào)到達(dá)那個端口的時(shí)候，沒有接收端在那個端口監(jiān)聽。我們注意到ICMP分組攜帶著一些未傳遞UDP數(shù)據(jù)報(bào)的信息。當(dāng)ttcp接收端看到一個只具有4個字節(jié)數(shù)據(jù)的特殊數(shù)據(jù)報(bào)時(shí)，它便會知道數(shù)據(jù)傳輸是完整的，并且會因此關(guān)閉正

8、在監(jiān)聽的端口。事實(shí)上ttcp發(fā)送端發(fā)送5個這樣的分組，并且后面的分組到達(dá)的時(shí)候發(fā)現(xiàn)接收端已經(jīng)沒有在監(jiān)聽了。當(dāng)發(fā)送端發(fā)送所有的數(shù)據(jù)而沒有相應(yīng)的接收標(biāo)志的時(shí)候，將會看到相似的行為。TCP和UDP的另外一個不同之處在于TCP連接時(shí)點(diǎn)對點(diǎn)的，換句話說，TCP的使用是在一個連接端和一個發(fā)送端之間的。而對于UDP來說，一個發(fā)送端可能發(fā)向多個接收端（例如廣播和組播通信）或者多個發(fā)送端能夠發(fā)送給一個接收端。如果多個發(fā)送端都發(fā)給這個接收端的話，這個接收端會為每個發(fā)送端報(bào)告統(tǒng)計(jì)信息。TCP和UDP的最后一個不同之處是它們首部的大小。UDP首部總是8個字節(jié)，而TCP首部大小是變化的，但是它絕對不會少于20個字節(jié)。這也就是說傳輸5000個字節(jié)的實(shí)際數(shù)據(jù)TCP的開銷是36。四、實(shí)驗(yàn)報(bào)告回答下面的問題：1、在udp_2transmit.cap中觀察DUP首部