合肥學(xué)院TCPIP協(xié)議分析及應(yīng)用實驗報告 (1)_第1頁
合肥學(xué)院TCPIP協(xié)議分析及應(yīng)用實驗報告 (1)_第2頁
合肥學(xué)院TCPIP協(xié)議分析及應(yīng)用實驗報告 (1)_第3頁
合肥學(xué)院TCPIP協(xié)議分析及應(yīng)用實驗報告 (1)_第4頁
合肥學(xué)院TCPIP協(xié)議分析及應(yīng)用實驗報告 (1)_第5頁
已閱讀5頁,還剩12頁未讀 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

1、計算機科學(xué)與技術(shù)系 實 驗 報 告專業(yè)名稱 網(wǎng)絡(luò)工程 課程名稱 TCP/IP協(xié)議 項目名稱 TCP/UDP 班 級 學(xué) 號 姓 名 同組人員 實驗日期 2014.11 1、 實驗?zāi)康呐c要求:1、 實驗?zāi)康?TCP:1) 掌握TCP協(xié)議的報文格式2) 掌握TCP連接的建立和釋放過程3) 掌握TCP數(shù)據(jù)傳輸中編號與確認的過程4) 掌握TCP協(xié)議校驗和的計算方法5) 理解TCP的重傳機制UDP:1) 掌握UDP協(xié)議的報文格式2) 掌握UDP協(xié)議校驗和的計算方法3) 理解UDP協(xié)議的優(yōu)缺點2、實驗環(huán)境2、 實驗內(nèi)容1、 實驗原理TCP:1) TCP報文格式16位源端口號16位目的端口號32位序號32位

2、確認序號4位首部長度保留(6位)URGACKPSHRSTSYNFIN16位窗口大小16位校驗和16位緊急指針選項數(shù)據(jù)2) TCP連接的建立TCP是面向連接的協(xié)議。在面向連接的環(huán)境中,開始傳輸數(shù)據(jù)之前,在兩個終端之間必須先建立一個連接。對于一個要建立的連接,通信雙方必須用彼此的初始化序列號seq和來自對方成功傳輸確認的應(yīng)答號ack(指明希望收到的下一個八位組的編號)來同步,習(xí)慣上將同步信號寫為SYN,應(yīng)答信號寫為ACK。 整個同步的過程稱為三次握手.3) TCP連接的釋放對于一個已經(jīng)建立的連接,TCP使用四次握手來結(jié)束通話(使用一個帶有FIN附加標(biāo)記的報文段)。4) TCP重傳機制TCP每發(fā)送一

3、個報文段,就對這個報文段設(shè)置一次計時器。只要計時器設(shè)置的重傳時間到期,但還沒有收到確認,就要重傳這一報文段。5) 實驗流程概述1 在機房調(diào)試好需做的拓撲結(jié)構(gòu)2 根據(jù)拓撲結(jié)構(gòu),配置小組成員各自電腦的IP地址,子網(wǎng)掩碼和網(wǎng)管3 根據(jù)課件中的具體實驗要求和實驗步驟進行操作UDP:1) UDP報文格式每個UDP報文稱為一個用戶數(shù)據(jù)報(User Datagram)。用戶數(shù)據(jù)報分為兩個部分:UDP首部和UDP數(shù)據(jù)區(qū)。 源端口目的端口報文長度校驗和數(shù)據(jù)2) UDP單播與廣播 在UDP單播通訊模式下,客戶端和服務(wù)端之間建立一個單獨的數(shù)據(jù)通道。 從一臺服務(wù)端傳送出的數(shù)據(jù)包只能由一個客戶端接收。 眾所周知,UDP

4、協(xié)議是不可靠的,數(shù)據(jù)包可能在傳輸過程中丟失、重復(fù)、沒有按照發(fā)送順序到達, 而且作為UDP數(shù)據(jù)包,其大小還受限于數(shù)據(jù)包的最大上限。 在UDP廣播通訊模式下,一個單獨的數(shù)據(jù)包拷貝發(fā)送給網(wǎng)絡(luò)上所有主機。 當(dāng)不能明確具體的服務(wù)器,而又要求該服務(wù)時,UDP廣播提供了傳輸不區(qū)分種類的消息的便捷方式。在多數(shù)情況下UDP廣播僅僅作為本地網(wǎng)絡(luò)通信形式。受限的廣播地址是55。該地址用于主機配置過程中IP數(shù)據(jù)報的目的地址,此時,主機可能還不知道它所在網(wǎng)絡(luò)的網(wǎng)絡(luò)掩碼,甚至連它的IP地址也不知道。在任何情況下,路由器都不轉(zhuǎn)發(fā)目的地址為受限廣播地址的數(shù)據(jù)報,這樣的數(shù)據(jù)報僅出現(xiàn)在本地網(wǎng)絡(luò)中。 已知

5、網(wǎng)絡(luò)主機的IP地址和子網(wǎng)掩碼,可以算得指向主機所在子網(wǎng)的廣播。 子網(wǎng)廣播地址 = (主機IP) “或” (子網(wǎng)掩碼取反)。3) UDP校驗和的計算3、實驗具體步驟及結(jié)果TCP:練習(xí)一:察看TCP連接的建立和釋放1. 主機B、C、D啟動協(xié)議分析器進行數(shù)據(jù)捕獲,并設(shè)置過濾條件(提取TCP協(xié)議)。2. 主機A啟動仿真編輯器,進入TCP連接視圖。在“服務(wù)器信息/IP地址”中填入主機C的IP地址;使用“端口掃描”獲取主機C的TCP端口列表,在“服務(wù)器信息/端口”中填入主機C的一個TCP端口(大于1024);點擊“連接”按鈕進行連接。3. 察看主機B、C、D捕獲的數(shù)據(jù),填寫下表。字段名稱報文1報文2報文3

6、Sequence Number375730584018801033583757305841Acknowledgement Number037573058411880103359ACK011SYN1104. TCP連接建立時,前兩個報文的首部都有一個“maximum segment size”字段,它的值是多少?作用是什么?結(jié)合IEEE802.3協(xié)議規(guī)定的以太網(wǎng)最大幀長度分析此數(shù)據(jù)是怎樣得出的 maximum segment size=14605. 主機A斷開與主機C的TCP連接。 6. 察看主機B、C、D捕獲的數(shù)據(jù),填寫下表。 字段名稱報文4報文5報文6報文7Sequence Number58

7、810841235714588363571458836588108413Acknowledgement Number35714588365881084135881084133571458837ACK1111SYN00007. 結(jié)合步驟3、5所填的表,理解TCP的三次握手建立連接和四次握手的釋放連接過程,理解序號、確認號等字段在TCP可靠連接中所起的作用。練習(xí)二:利用仿真編輯器編輯并發(fā)送TCP數(shù)據(jù)包1) 主機B啟動協(xié)議分析器捕獲數(shù)據(jù),設(shè)置過濾條件(提取http協(xié)議)。 2) 主機A上啟動仿真編輯器,在界面初始狀態(tài)下,程序會自動新建一個單幀,可以利用仿真編輯器打開時默認的以太網(wǎng)幀進行編輯。 3)

8、填寫該幀的以太網(wǎng)協(xié)議首部,其中:源MAC地址:主機A的MAC地址。目的MAC地址:服務(wù)器的MAC地址。協(xié)議類型或數(shù)據(jù)長度:0800(IP協(xié)議)。4) 填寫IP協(xié)議頭信息,其中: 高層協(xié)議類型:6(上層協(xié)議為TCP)。 總長度:40(IP首部+TCP首部)。 源IP地址:主機A的IP地址。 目的IP地址:服務(wù)器的IP地址(0)。 其它字段任意。 應(yīng)用前面學(xué)到的知識計算IP首部校驗和。 5) 填寫TCP協(xié)議信息,其中: 源端口:任意大于1024的數(shù),不要使用下拉列表中的端口。 目的端口:80(HTTP協(xié)議)。 序列號:選擇一個序號ISN(假設(shè)1942589885),以后的數(shù)據(jù)都

9、按照這個來填。 確認號:0。 首部長度和標(biāo)志位:5002(即長度20字節(jié),標(biāo)志SYN=1)。 窗口大?。喝我?。 緊急指針:0。 使用協(xié)議仿真編輯器的“手動計算”方法計算校驗和;再使用協(xié)議仿真編輯器的“自動計算”方法計算校驗和。將兩次計算結(jié)果相比較,若結(jié)果不一致,則重新計算。 TCP在計算校驗和時包括哪些內(nèi)容?將設(shè)置完成的數(shù)據(jù)幀復(fù)制2份;修改第二幀的TCP 層的“首部長度和標(biāo)志”位為5010(即標(biāo)志位ACK=1),TCP層的“序號”為1942589885+1。修改第三幀的TCP層的“首部長度和標(biāo)志”位為5011(即標(biāo)志位ACK=1、FIN=1),TCP層的“序號”為1942589885+1。 6

10、) 在發(fā)送該TCP連接請求之前,先ping 一次目標(biāo)服務(wù)器,讓目標(biāo)服務(wù)器知道自己的MAC地址。 7) 使用“仿真編輯器/工具菜單/TCP屏蔽/啟動屏蔽”功能,為TCPIP協(xié)議棧過濾掉收到的TCP數(shù)據(jù)。 8) 點擊菜單欄中的“發(fā)送”按鈕,在彈出對話框中選擇發(fā)送第一幀。9) 我們假設(shè)接收字節(jié)序號為:3246281765,修改第二幀和第三幀的TCP層的“ACK確認序號”的值:3246281766。 10) 計算第二幀的TCP校驗和,將該幀發(fā)送。對服務(wù)器的應(yīng)答報文進行確認。11) 計算第三幀的TCP校驗和,將該幀發(fā)送。斷開連接,完成TCP連接的全過程。12) 協(xié)議分析器一端截獲相應(yīng)的請求及應(yīng)答報文并分

11、析,注意觀察“會話分析”中的會話過程。 13) 仿真端主機使用“仿真編輯器/工具菜單/TCP屏蔽/停止屏蔽”功能,恢復(fù)正常網(wǎng)絡(luò)功能。綜合發(fā)送報文:UDP:練習(xí)一:編輯并發(fā)送UDP數(shù)據(jù)報本練習(xí)將主機A和B作為一組,主機C和D作為一組,主機E和F作為一組?,F(xiàn)僅以主機A和B為例,說明實驗步驟。1. 主機A打開協(xié)議仿真編輯器。編輯發(fā)送給主機B的UDP數(shù)據(jù)報。MAC層:目的MAC地址:接收方MAC地址。 源MAC地址:發(fā)送方MAC地址。 協(xié)議類型或數(shù)據(jù)長度:0800,即IP協(xié)議。 IP層: 總長度:包括IP層、UDP層和數(shù)據(jù)長度。 高層協(xié)議類型: 17,即UDP協(xié)議。 首部校驗和:其他所有字段填充完畢后

12、填充此字段。 源IP地址:發(fā)送方IP地址。 目的IP地址:接收方IP地址。 UDP層: 有效負載長度:UDP層及其上層協(xié)議長度。 計算校驗和,其他字段默認. UDP在計算校驗和時包括那些內(nèi)容? 2. 在主機B上啟動協(xié)議分析器,并設(shè)置過濾條件(提取UDP協(xié)議)開始捕獲數(shù)據(jù)。3. 主機A發(fā)送已編輯好的數(shù)據(jù)報。4. 主機B停止捕獲數(shù)據(jù),在捕獲到的數(shù)據(jù)中查找主機A所發(fā)送的數(shù)據(jù)報。 練習(xí)二:UDP單播通信1. 主機B、C、D、E、F上啟動“開始/程序/網(wǎng)絡(luò)協(xié)議仿真教學(xué)系統(tǒng) 通用版/工具/UDP工具”,作為服務(wù)器端,監(jiān)聽端口設(shè)置為2483。2. 主機C、E上啟動協(xié)議分析器開始捕獲數(shù)據(jù)。3. 主機A上啟動“

13、開始/程序/網(wǎng)絡(luò)協(xié)議仿真教學(xué)系統(tǒng) 通用版/工具/UDP工具”,作為客戶端,以主機C的IP為目的IP地址,以2483為端口,填寫數(shù)據(jù)并發(fā)送。4. 察看主機B、C、D、E、F上的“UDP工具”接收的信息。哪臺主機上的“UDP工具”接收到主機A發(fā)送的UDP報文?5. 察看主機C協(xié)議分析器上的UDP報文,并回答以下問題:UDP是基于連接的協(xié)議嗎?闡述此特性的優(yōu)缺點。解:不是,優(yōu)點:傳輸效率高,不需進行編號,不必進行連接建立和連接終止;缺點:使用UDP的進程不能向UDP發(fā)送數(shù)據(jù)流,也不能期望UDP將這個數(shù)據(jù)流分割成為許多不同的相關(guān)聯(lián)的用戶數(shù)據(jù)報。相反,每個請求必須足夠小,使其能夠裝入到用戶數(shù)據(jù)報中。UD

14、P報文交互中含有確認報文嗎?闡述此特性的優(yōu)缺點。解:沒有,優(yōu)點:提高傳輸效率;缺點:在傳輸過程中可能有丟失、重復(fù)、亂序的現(xiàn)象。6. 主機A上使用仿真編輯器向主機E發(fā)送UDP報文,其中:“目的IP地址” 設(shè)置為主機E的IP地址。 “目的端口”設(shè)置為2483?!靶r灪汀痹O(shè)置為0。發(fā)送此報文,并回答以下問題:主機E上的UDP通信程序是否接收到此數(shù)據(jù)包?UDP是否可以使用0作為校驗和進行通信?解:主機E可以收到數(shù)據(jù)包。UDP可以使用0作為校驗和進行通信。7. 將第6步中編輯的數(shù)據(jù)包的校驗和修改為一個錯誤值,并將其發(fā)送。8. 察看主機E協(xié)議分析器上捕獲的數(shù)據(jù),并回答以下問題:簡述UDP的差錯處理能力。練

15、習(xí)三:UDP廣播通信1. 主機B、C、D、E、F上啟動“開始/程序/網(wǎng)絡(luò)協(xié)議仿真教學(xué)系統(tǒng) 通用版/工具/UDP工具”,作為服務(wù)器端,監(jiān)聽端口設(shè)為2483。2. 主機B、C、D、E、F上啟動協(xié)議分析器捕獲數(shù)據(jù),并設(shè)置過濾條件(提取UDP協(xié)議)3. 主機A上啟動“開始/程序/網(wǎng)絡(luò)協(xié)議仿真教學(xué)系統(tǒng) 通用版/工具/UDP工具”,作為客戶端,以55為目的地址,以2483為端口,填寫數(shù)據(jù)并發(fā)送。4. 察看主機B、C、D、E、F上的“UDP連接工具”接收的信息。 哪臺主機接收到主機A發(fā)送的UDP報文?5. 察看協(xié)議分析器上捕獲的UDP報文,并回答以下問題: 主機A發(fā)送的報文的目的M

16、AC地址和目的IP地址的含義是什么? 解:目的MAC地址為FFFFFF-FFFFFF,廣播地址;目的IP地址為55,受限廣播地址。若將主機A發(fā)送的報文的目的MAC地址改為某一主機的MAC地址,結(jié)果會怎樣?為什么? 解:主機A發(fā)送的報文的目的MAC地址為某一主機的MAC地址,而目的IP地址無論是某一主機的IP地址,還是55,結(jié)果都是只有目的MAC地址所對應(yīng)的主機可收到主機A發(fā)送的報文。因為目的MAC地址對應(yīng)主機才是真正接收數(shù)據(jù)的主機。若將主機A發(fā)送的報文的目的IP地址改為某一主機的IP地址,結(jié)果會怎樣?為什么? 解:兩種情況:如果目的MAC為廣

17、播地址,則結(jié)果為所有主機都可接收主機A的報文;如果目的MAC為某一主機的MAC,則主機A發(fā)送的數(shù)據(jù)只能被該主機接收。原因:目的MAC地址對應(yīng)主機才是真正接收數(shù)據(jù)的主機。3、 實驗分析與小結(jié):1 發(fā)送tcp數(shù)據(jù)包時,前幾次實驗發(fā)送后抓不到數(shù)據(jù),后來發(fā)現(xiàn)要求實驗步驟中有一條,發(fā)送該TCP連接請求之前,先ping 一次目標(biāo)服務(wù)器,讓目標(biāo)服務(wù)器知道自己的MAC地址。進行此步操作后,實驗便可正常進行。2 計算校驗和需學(xué)會手動計算,自動計算時,原先表格中的校驗和需要改為0000,才能計算出正確的校驗和。4、 其它1.試用具體例子說明為什么在運輸連接建立時要使用三次握手。說明如不這樣做可能會出現(xiàn)什么情況。

18、解:三次握手解決了連接建立過程中要解決的三個問題:(1) 要使每一方能夠確定對方的存在。(2) 要允許雙發(fā)協(xié)商一些參數(shù)(如最大報文段長度、最大窗口大小、服務(wù)質(zhì)量等)。(3) 能夠?qū)\輸實體資源(如緩存大小、連接表中的項目等)進行分配。如不這樣做:主機A共發(fā)送了兩個連接請求報文段,其中的第二個到達了主機B?,F(xiàn)在假定出現(xiàn)另一種情況,即主機A發(fā)送的第一個連接請求報文段并沒有丟失,而是在某些網(wǎng)絡(luò)結(jié)點滯留時間太長,以致延誤到在這次的連接釋放以后才傳送到主機B。本來這是一個已經(jīng)失效的報文段,但主機B收到此失效的連接請求報文段后,就誤認為是主機A又發(fā)出一次新的連接請求。于是就向主機A發(fā)出確認報文段,同意建立連接。主機A由于并沒有要求建立連接,因此不會理睬主機B的確認,也不會向主機B發(fā)送數(shù)據(jù)。但主機B卻以為運輸連接就這樣建立了,并一直等待主機A發(fā)來數(shù)據(jù)。主機B的許多資源就這樣白白浪費了。2.使用TCP對實時話音數(shù)據(jù)的傳輸有沒有什么問題?使用UDP在傳送數(shù)據(jù)文件時會有什么問題? 解:TCP協(xié)議可能導(dǎo)致實時語音通訊的延遲。使用UDP傳出的數(shù)據(jù)可能導(dǎo)致數(shù)據(jù)文件

溫馨提示

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

評論

0/150

提交評論