合肥學(xué)院TCPIP協(xié)議分析及應(yīng)用實(shí)驗(yàn)報(bào)告 (1)

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

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

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

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

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

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

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

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

9、按照這個來填。 確認(rèn)號：0。 首部長度和標(biāo)志位：5002（即長度20字節(jié)，標(biāo)志SYN=1）。 窗口大?。喝我?。 緊急指針：0。 使用協(xié)議仿真編輯器的“手動計(jì)算”方法計(jì)算校驗(yàn)和；再使用協(xié)議仿真編輯器的“自動計(jì)算”方法計(jì)算校驗(yàn)和。將兩次計(jì)算結(jié)果相比較，若結(jié)果不一致，則重新計(jì)算。 TCP在計(jì)算校驗(yàn)和時包括哪些內(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) 點(diǎn)擊菜單欄中的“發(fā)送”按鈕，在彈出對話框中選擇發(fā)送第一幀。9) 我們假設(shè)接收字節(jié)序號為：3246281765，修改第二幀和第三幀的TCP層的“ACK確認(rèn)序號”的值：3246281766。 10) 計(jì)算第二幀的TCP校驗(yàn)和，將該幀發(fā)送。對服務(wù)器的應(yīng)答報(bào)文進(jìn)行確認(rèn)。11) 計(jì)算第三幀的TCP校驗(yàn)和，將該幀發(fā)送。斷開連接，完成TCP連接的全過程。12) 協(xié)議分析器一端截獲相應(yīng)的請求及應(yīng)答報(bào)文并分

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

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

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

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

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

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

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

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