使用Wireshark分析-以太網幀與ARP協議-IP協議-ICMP-UDP協議-TCP協議-協議HTTP-DNS協議

實驗一 Wireshark的使用

一、實驗目的
1、熟悉並掌握Wireshark的基本使用；
2、瞭解網絡協議實體間進行交互以及報文交換的情況。
二、實驗環境
與因特網連接的計算機，操作系統爲Windows，安裝有Wireshark、IE等軟件。
三、 實驗步驟

1. 啓動Web瀏覽器（如IE）；

2. 啓動Wireshark；

3. 開始分組捕獲：單擊工具欄的 按鈕，出現如圖1所示對話框，[options]按鈕可以進行系統參數設置，在絕大部分實驗中，使用系統的默認設置即可。當計算機具有多個網卡時，選擇其中發送或接收分組的網絡接口（本例中，第一塊網卡爲虛擬網卡，第二塊爲以太網卡）。單擊“Start”開始進行分組捕獲；
   

                   		 圖1 
   

4. 在運行分組捕獲的同時，在瀏覽器地址欄中輸入某個網頁的URL，如：
   

5. 當完整的頁面下載完成後，單擊捕獲對話框中的“stop”按鈕，停止分組捕獲。此時， Wireshark主窗口顯示已捕獲的你本次通信的所有協議報文；

6. 在協議篩選框中輸入“http”，單擊“apply”按鈕，分組列表窗口將只顯示HTTP協議報文。

7. 選擇分組列表窗口中的第一條http報文，它是你的計算機發向服務器（www.njxzc.edu.cn）的HTTP GET報文。當你選擇該報文後，以太網幀、IP數據報、TCP報文段、以及HTTP報文首部信息都將顯示在分組首部子窗口中，其結果如圖2。
   

                   		 圖2 
   

四、 問題與思考
在實驗基礎上，回答以下問題：
(1) 列出在第5步中分組列表子窗口所顯示的所有協議類型；
(2) 從發出HTTP GET報文到接收到對應的HTTP OK響應報文共需要多長時間？（分組列表窗口中Time列的值是從Wireshark開始追蹤到分組被捕獲的總的時間數，以秒爲單位）
(3) 你主機的IP地址是什麼？你訪問的服務器的IP地址是什麼？

 

實驗二 使用Wireshark分析以太網幀與ARP協議

一、實驗目的
分析以太網幀，MAC地址和ARP協議
二、實驗環境
與因特網連接的計算機網絡系統；主機操作系統爲windows；使用Wireshark、IE等軟件。
三、實驗步驟：
1、俘獲和分析以太網幀
（1）選擇 工具->Internet 選項->刪除文件
（2）啓動Wireshark 分組嗅探器
（3）在瀏覽器地址欄中輸入如下網址：
http://gaia.cs.umass.edu/wireshark-labs 會出現美國權利法案。
（4）停止分組俘獲。在俘獲分組列表中（listing of captured packets）中找到HTTP GET 信息和響應信息，如圖1所示。

                   圖1　HTTP GET信息和響應信息

（如果你無法俘獲此分組，在Wireshark下打開文名爲ethernet–ethereal-trace-1的文件進行學習）。
HTTP GET信息被封裝在TCP分組中，TCP分組又被封裝在IP數據報中，IP數據報又被封裝在以太網幀中）。在分組明細窗口中展開Ethernet II信息（packet details window）。

四、問題與思考
1、你所在的主機48-bit Ethernet 地址是多少？
2、Ethernet 幀中目的地址是多少？這個目的地址是gaia.cs.umass.edu的Ethernet 地址嗎？

 

實驗三 使用Wireshark分析IP協議

一、實驗目的
1、分析IP協議
2、分析IP數據報分片
二、實驗環境
與因特網連接的計算機，操作系統爲Windows，安裝有Wireshark、IE等軟件。
三、實驗步驟
IP協議是因特網上的中樞。它定義了獨立的網絡之間以什麼樣的方式協同工作從而形成一個全球戶聯網。因特網內的每臺主機都有IP地址。數據被稱作數據報的分組形式從一臺主機發送到另一臺。每個數據報標有源IP地址和目的IP地址，然後被髮送到網絡中。如果源主機和目的主機不在同一個網絡中，那麼一個被稱爲路由器的中間機器將接收被傳送的數據報，並且將其發送到距離目的端最近的下一個路由器。這個過程就是分組交換。
IP允許數據報從源端途經不同的網絡到達目的端。每個網絡有它自己的規則和協定。IP能夠使數據報適應於其途徑的每個網絡。例如，每個網絡規定的最大傳輸單元各有不同。IP允許將數據報分片並在目的端重組來滿足不同網絡的規定。
在4_1_JoiningTheInternet下打開已俘獲的分組，分組名爲：dhcp_isolated.cap。感興趣的同學可以在有動態分配IP的實驗環境下俘獲此分組，此分組具體俘獲步驟如下：
1、使用DHCP獲取IP地址
（1）打開命令窗口,啓動Wireshark。
（2）輸入“ipconfig /release”。這條命令會釋放主機目前的IP地址，此時，主機IP地址會變爲0.0.0.0
（3）然後輸入“ipconfig /renew”命令。這條命令讓主機獲得一個網絡配置，包括新的IP地址。
（4）等待，直到“ipconfig /renew”終止。然後再次輸入“ipconfig /renew” 命令。
（5）當第二個命令“ipconfig /renew” 終止時，輸入命令“ipconfig /release” 釋放原來的已經分配的IP地址
（6）停止分組俘獲。如圖1所示：

                     圖1 Wireshark俘獲的分組

下面，我們對此分組進行分析：
IPconfig 命令被用於顯示機器的IP地址及修改IP地址的配置。當輸入命ipconfig /release命令時，用來釋放機器的當前IP地址。釋放之後，該機沒有有效的IP地址並在分組2中使用地址0.0.0.0作爲源地址。
分組2是一個DHCP Discover(發現)報文，如圖2所示。當一臺沒有IP地址的計算機申請IP地址時將發送該報文。DHCP Discovery報文被髮送給特殊的廣播地址：255.255.255.255，該地址將到達某個限定廣播範圍內所有在線的主機。理論上，255.255.255.255能夠廣播到整個因特網上，但實際上並不能實現，因爲路由器爲了阻止大量的請求淹沒因特網，不會將這樣的廣播發送到本地網之外。
在DHCP Discover報文中，客戶端包括自身的信息。特別是，它提供了自己的主機名(MATTHEWS)和其以太網接口的物理地址(00:07:e9:53:87:d9)。這些信息都被DHCP用來標識一個已知的客戶端。DHCP服務器可以使用這些信息實現一系列的策略，比如，分配與上次相同的IP地址，分配一個上次不同的IP地址，或要求客戶端註冊其物理層地址來獲取IP地址。
在DHCP Discover報文中，客戶端還詳細列出了它希望從DHCP服務器接收到的信息。在Parameter Request List中包含了除客戶端希望得到的本地網絡的IP地址之外的其他數據項。這些數據項中許多都是一臺即將連入因特網的計算機所需要的數據。例如，客戶端必須知道的本地路由器的標識。任何目的地址不在本地網的數據報都將發送到這臺路由器上。也就是說，這是發向外網的數據報在通向目的端的路徑上遇到的第一臺中間路由器。

                 圖2 DHCP Discovery

客戶端必須知道自己的子網掩碼。子網掩碼是一個32位的數，用來與IP地址進行“按

                    圖2 Parameter Request List

位邏輯與運算”從而得出網絡地址。所有可以直接通信而不需要路由器參與的機器都有相同的網絡地址。因此，子網掩碼用來決定數據報是發送到本地路由器還是直接發送到本地目的主機。
客戶端還必須知道它們的域名和它們在本地域名服務器上的標識。域名是一個可讀的網絡名。
IP地址爲192.168.0.1的DHCP服務器回覆了一個DHCP OFFER報文。該報文也廣播到255.255.255.255，因爲儘管客戶端還不知道自己的IP地址，但它將接收到發送到廣播地址的報文。這個報文中包含了客戶端請求的信息，包括IP地址、本地路由器、子網掩碼、域名和本地域名服務器。
在分組5中，客戶端通過發送DHCP Request（請求）報文表明自己接收到的IP地址。最後，在分組6中DHCP服務器確認請求的地址並結束對話。此後，在分組7中客戶端開始使用它的新的IP地址作爲源地址。
在分組3和分組7到12的地址ARP協議引起了我們的注意。在分組3中，DHCP服務器詢問是否有其它主機使用IP地址192.168.0.100（該請求被髮送到廣播地址）。這就允許DHCP服務器在分配IP之前再次確認沒有其它主機使用該IP地址。在獲取其IP地址之後，客戶端會發送3個報文詢問其他主機是否有與自己相同的IP地址。前4個ARP請求都沒有迴應。在分組10—13中，DHCP服務器再次詢問哪個主機擁有IP地址192.168.0.100，客戶端兩次回答它佔有該IP同時提供了自己的以太網地址。
通過DHCP分配的IP地址有特定的租用時間。爲了保持對某個IP的租用，客戶端必須更新租用期。當輸入第二個命令ipconfig /renew後，在分組14和15中就會看到更新租用期的過程。DHCP Request請求更新租用期。DHCP ACK包括租用期的長度。如果在租用期到期之前沒有DHCP Request發送，DHCP服務器有權將該IP地址重新分配給其他主機。
最後，在分組16時輸入命令ipconfig /release後的結果。在DHCP服務器接收到這個報文後，客戶停止對該IP的使用。如有需要DHCP服務器有權重新對IP地址進行分配。
2、分析IPv4中的分片
在第二個實驗中，我們將考察IP數據報首部。俘獲此分組的步驟如下：
（1） 啓動Wireshark，開始分組俘獲（“Capture”-----“interface…”----“start”）。
（2） 啓動pingplotter（pingplotter 的下載地址爲www.pingplotter.com）,在“Address to trace:”下面的輸入框裏輸入目的地址，選擇菜單欄“Edit”—“Options”—“Packet”,在“Packet size(in bytes defaults=56):”
右邊輸入IP數據報大小：5000，按下“OK”。最後按下按鈕“Trace”,你將會看到pingplotter窗口顯示如下內容，如圖3所示：

                          圖3 ping plotter

（3） 停止Wireshark。設置過濾方式爲：IP，在Wireshark窗口中將會看到如下情形,如圖4所示。
在分組俘獲中，你應該可以看到一系列你自己電腦發送的“ICMP Echo Request”和由中間路由器返回到你電腦的“ICMP TTL-exceeded messages。

          　　　　    圖4 用Ｗireshark 所俘獲的分組

（4） 如果你無法得到上圖的分組信息，也可使用已經下載的IP分片分組文件：fragment_5000_isolated.cap。然後在Wireshark中，選擇菜單欄“File”—“Open”導入上述文件進行學習。
下面，我們來分析fragment_5000_isolated.cap中的具體分組：
IP層位於傳輸層和鏈路層之間。在fragment_5000_isolated.cap中傳輸層協議是UDP，鏈路層協議是以太網。發送兩個UDP數據報，每個包含5000個字節的數據部分和8字節的UDP首部。在分組1到4和分組5到8分別代表了先後發送的兩個UDP數據報。
當IP層接收到5008字節的UDP數據報時，它的工作是將其作爲IP數據報在以太網傳輸。以太網要求一次傳輸的長度不大於1514個字節，其中有14字節是以太網幀首部。
IP被迫將UDP數據報作爲多個分片發送。每個分片必須包含以太網幀首部、IP數據報首部。每個分片還會包含UDP數據報的有效負載（首部和數據）的一部分。
IP將原始數據報的前1480個字節（含1472個字節的數據和含8個字節的UDP首部）放在第一個分片中。後面兩個分片每個均含1480個字節的數據，最後一個分片中包含的數據爲568個字節）。
爲了讓接收段重組原始數據，IP使用首部的特殊字段對分片進行了編號。標識字段用於將所有的分片連接在一起。分組1到4含有相同的標識號0xfd2b,分組5到8的標識號是0xfd2c.片漂移量指明瞭分組中數據的第一個字節在UDP數據報中的偏移量。例如分組1和分組5的偏移量都是0，因爲它們都是第一個分片。
最後在標識字段中有一位用來指明這個分片後是否還有分片。分組1到分組3和分組5到分組7均對該位置進行了置位。分組4和分組8由於是最後一個分片而沒有對該位置位。

四、問題與思考
打開文件dhcp_isolated.cap、fragment_5000_isolated.cap，回答以下問題：
1、DHCP服務器廣播的本地路由器或默認網關的IP地址是多少？
2、在dhcp_isolated.cap中，由DHCP服務器分配的域名是多少？
3、在fragment_5000_isolated.cap中，我們看到通過UDP數據報發送的5000字節被分成了多少分片？在網絡中，一次能傳輸且不需要分片的最大數據單元有多大？

 

實驗四 利用Wireshark分析ICMP

一、實驗目的
分析ICMP
二、實驗環境
與因特網連接的計算機，操作系統爲Windows，安裝有Wireshark、IE等軟件。
三、實驗步驟
Ping和traceroute命令都依賴於ICMP。ICMP可以看作是IP協議的伴隨協議。ICMP報文被封裝在IP 數據報發送。
一些ICMP報文會請求信息。例如：在ping中，一個ICMP迴應請求報文被髮送給遠程主機。如果對方主機存在，期望它們返回一個ICMP迴應應答報文。
一些ICMP報文在網絡層發生錯誤時發送。例如，有一種ICMP報文類型表示目的不可達。造成不可達的原因很多，ICMP報文試圖確定這一問題。例如，可能是主機關及或整個網絡連接斷開。
有時候，主機本身可能沒有問題，但不能發送數據報。例如IP首部有個協議字段，它指明瞭什麼協議應該處理IP數據報中的數據部分。IANA公佈了代表協議的數字的列表。例如，如果該字段是6，代表TCP報文段,IP層就會把數據傳給TCP層進行處理；如果該字段是1，則代表ICMP報文，IP層會將該數據傳給ICMP處理。如果操作系統不支持到達數據報中協議字段的協議號，它將返回一個指明“協議不可達”的ICMP報文。IANA同樣公佈了ICMP報文類型的清單。
Traceroute是基於ICMP的靈活用法和IP首部的生存時間字段的。發送數據報時生存時間字段被初始化爲能夠穿越網絡的最大跳數。每經過一箇中間節點，該數字減1。當該字段爲0時，保存該數據報的機器將不再轉發它。相反，它將向源IP地址發送一個ICMP生存時間超時報文。
生存時間字段用於避免數據報載網絡上無休止地傳輸下去。數據報的發送路徑是由中間路由器決定的。通過與其他路由器交換信息，路由器決定數據報的下一條路經。最好的“下一跳”經常由於網絡環境的變化而動態改變。這可能導致路由器形成選路循環也會導致正確路徑衝突。在路由循環中這種情況很可能發生。例如，路由器A認爲數據報應該發送到路由器B，而路由器B又認爲該數據報應該發送會路由器A，這是數據報便處於選路循環中。
生存時間字段長爲8位，所以因特網路徑的最大長度爲28 -1即255跳。大多數源主機將該值初始化爲更小的值（如128或64）。將生存時間字段設置過小可能會使數據報不能到達遠程目的主機，而設置過大又可能導致處於無限循環的選路中。
Traceroute利用生存時間字段來映射因特網路徑上的中間節點。爲了讓中間節點發送ICMP生存時間超時報文，從而暴露節點本身信息，可故意將生存時間字段設置爲一個很小的書。具體來說，首先發送一個生存時間字段爲1的數據報，收到ICMP超時報文，然後通過發送生存時間字段設置爲2的數據報來重複上述過程，直到發送ICMP生存時間超時報文的機器是目的主機自身爲止。
因爲在分組交換網絡中每個數據報時獨立的，所以由traceroute發送的每個數據報的傳送路徑實際上互不相同。認識到這一點很重要。每個數據報沿着一條路經對中間節點進行取樣，因此traceroute可能暗示一條主機間並不存在的連接。因特網路徑經常變動。在不同的日子或一天的不同時間對同一個目的主機執行幾次traceroute命令來探尋這種變動都會得到不同的結果。
爲了體現Internet路由的有限可見性，許多網絡都維護了一個traceroute服務器traceroute。Traceroute服務器將顯示出從本地網到一個特定目的地執行traceroute的結果。分佈於全球的traceroute服務器的相關信息可在http://www.traceroute.org上獲得。
1、ping 和 ICMP
利用Ping程序產生ICMP分組。Ping向因特網中的某個特定主機發送特殊的探測報文並等待表明主機在線的回覆。具體做法：
（1）打開Windows命令提示符窗口（Windows Command Prompt）。
（2）啓動Wireshark 分組嗅探器，在過濾顯示窗口（filter display window）中輸入icmp,開始Wireshark 分組俘獲。
（3）輸入“ping –n 10 hostname” 。其中“-n 10”指明應返回10條ping信息。
（4）當ping程序終止時，停止Wireshark 分組俘獲。
實驗結束後會出現如圖所示的命令窗口：

          　　　　    	圖1 命令窗口

停止分組俘獲後，會出現如圖2所示的界面：

          　　　　 圖2 停止分組俘獲後Wireshark的界面	

圖3是在分組內容窗口中顯示了ICMP協議的詳細信息。觀察這個ICMP分組，可以看出，此ICMP分組的Type 8 and Code 0 即所謂的ICMP “echo request” 分組。

          　　　　    圖3 ICMP協議詳細信息

根據操作回答“四、問題與思考”中的1-3題。
2. ICMP和Traceroute
在Wireshark 下，用Traceroute程序俘獲ICMP分組。Traceroute能夠映射出通往特定的因特網主機途徑的所有中間主機。
源端發送一串ICMP分組到目的端。發送的第一個分組時，TTL=1；發送第二個分組時，TTL=2，依次類推。路由器把經過它的每一個分組TTL字段值減1。當一個分組到達了路由器時的TTL字段爲1時，路由器會發送一個ICMP錯誤分組（ICMP error packet）給源端。
(1) 啓動Window 命令提示符窗口
(2) 啓動Wireshark分組嗅探器，開始分組俘獲。
（3）Tracert命令在c:\windows\system32下，所以在MS-DOS 命令提示行或者輸入“tracert hostname” or “c:\windows\system32\tracert hostname” (注意在Windows 下, 命令是 “tracert” 而不是“traceroute”。)如圖4所示：
（4）當Traceroute 程序終止時，停止分組俘獲。

               圖4 命令提示窗口顯示Traceroute程序結果

圖5顯示的是一個路由器返回的ICMP錯誤分組（ICMP error packet）。注意到ICMP錯誤分組中包括的信息比Ping ICMP中錯誤分組包含的信息多。

               圖5 一個擴展ICMP錯誤分組信息的Wireshark 窗口

根據操作回答“四、問題與思考”中的4-5題。

四、問題與思考
在實驗的基礎上，回答以下問題：
（1）你所在主機的IP地址是多少？目的主機的IP地址是多少？
（2）查看ping請求分組，ICMP的type 和code是多少？
（3）查看相應得ICMP響應信息，ICMP的type 和code又是多少？
（4）查看ICMP echo 分組 ，是否這個分組和前面使用 ping命令的ICMP echo 一樣？
（5）ICMP錯誤分組比ICMP echo 分組多包含的信息有哪些？
（6）連接層的IP地址是多少？
（7）ICMP的type 和code是多少?

 

實驗五 使用Wireshark分析UDP協議

一、實驗目的
比較TCP和UDP協議的不同
二、實驗環境
與因特網連接的計算機，操作系統爲Windows，安裝有Wireshark、IE等軟件。
三、實驗步驟
1、打開兩次TCP流的有關跟蹤記錄，保存在tcp_2transmit.cap中，並打開兩次UDP流中的有關跟蹤文件udp_2transmit.cap 。如圖所示：

              		 圖1 TCP 流跟蹤記錄

            	   	 圖2 UDP流跟蹤記錄

2、分析此數據包：
（1）TCP傳輸的正常數據：
tcp_2transmit.cap文件的分組1到13中顯示了TCP連接。這個流中的大部分信息與前面的實驗相同。我們在分組1到分組3中看到了打開連接的三次握手。分組10到分組13顯示的則是連接的終止。我們看到分組10既是一個帶有FIN標誌的請求終止連接的分組，又是一個最後1080個字節的（序號是3921—5000）的重傳。
TCP將應用程序寫入合併到一個字節流中。它並不會嘗試維持原有應用程序寫人的邊界值。我們注意到TCP並不會在單個分組中傳送1000字節的應用程序寫入。前1000個字節會在分組4種被髮送，而分組5則包含了1460個字節的數據-----一些來自第二個緩衝區，而另一些來自第三個緩衝區。分組7中含有1460個字節而分組8中則包含剩餘的1080個字節。（5000-1000-1460-1460=1080）
我們注意到實際報告上的2.48秒是從初始化連接的分組1開始到關閉連接的分組10結束。分組11—13未必要計入接收端應用程序的時間內，因爲一旦接收到第一個FIN，TCP層便馬上發送一個關閉連接的信號。分組11—13只可能由每臺計算機操作系統得TCP層後臺傳輸。
如果我們注意到第一個包含數據的分組4和最後一個分組8之間的時間，我們就大約計算出和由UDP接收端所報告的0.01秒相同的時間。這樣的話，增加TCP傳輸時間的主要原因就是分組10中的重傳。公平的說，UDP是幸運的，因爲它所有的分組都在第一時間被接受了。
在這個跟蹤文件中，另一個值得注意的是沒有包含數據的分組的數量。所有來自接收端的分組和幾個來自發送端的分組只包含了TCP報文段的首部。總的來說（包括重傳）一共發送了6822個字節來支持5000個字節的數據傳輸。這個開銷正好36﹪。
(2)UDP正常數據傳輸
現在我們來觀察UDP流，在udp _transmit.cap文件的分組1到分組11中顯示。雖然像TCP流那樣傳輸了相同的數據，但是在這個跟蹤文件中還是很多的不同。
和TCP不同，UDP是一個無連接的傳輸協議。TCP用SYN分組和SYN ACK分組來顯示地打開一個連接，而UDP卻直接開始發送包含數據的分組。同樣，TCP用FIN分組和FIN ACK分組來顯示地關閉一個連接，而UDP卻只簡單地停止包含數據的分組的傳輸。
爲了解決這個問題，在文件udp_2transmit.cap俘獲的分組中，採取的辦法是ttcp發送端發送一個只包含4個字節的特殊UDP 數據報來模擬連接建立和連接終止。在發送任何數據之前，發送端總是發送一個只包含4個字節的特殊數據報（分組1），而在發送完所有的數據之後，發送端又發送額外的5個分組（分組7-11）。
接收端也使用第一個特殊的數據報來啓動數據傳輸的計時器。如果這個特殊的數據報丟失了，它可能用真實數據的第一個分組計時器。不過，如果接收端沒有看到這個特殊的數據報，它就不能精確地確定數據傳輸的開始和傳輸的所有時間。與TCP不同，UDP 在傳輸的數據中，不會加上序號，因此對於接收端來說不可能確定丟失和重排序重傳的情況。
類似的，接收端根據最後的特殊數據報來停止數據傳輸計時器。當接收端接收到這5個包中的任一個便停止計時，但是發送5個分組是因爲在傳輸的過程中可能丟失其中的一些。如果5個分組全部丟失了，那麼接收端便會無限制的等待更多數據的到來達。
實際數據的傳輸是在分組2-6裏。每一個分組都包含1000個字節。1000個字節的應用程學寫入直接轉換成UDP數據報。另一方面，TCP並不打算保存應用程序寫入邊界而只是將它們併入一個字節流中。
與TCP不同，UDP沒有提供接收端到發送端的反饋。在TCP的例子裏，接收端返回只包含有TCP報文段首部而沒有數據的報文段。首部本身則攜帶着關於哪些數據已經被成功接收以及接收端能夠接收多少數據的信息。我們已經知道UDP不提供可靠的數據傳輸，因此並不要求什麼數據已經被成功接收的信息。它也不提供任何信息高速發送端降低速率，因爲接收端或者網絡本身已經淹沒。
雖然UDP本身並不提供接收端到發送端的反饋，但是我們確實看到幾個從接收端到發送端的ICMP分組（分組12—14）。ICMP是網絡層協議（IP）的一個伴隨協議，並且有提供一定控制和錯誤報告的功能。在這種情況下，ICMP分組暗示一些UDP數據報沒有被傳送到，因爲端口不可達。這就意味着當數據報到達那個端口的時候，沒有接收端在那個端口監聽。我們注意到ICMP分組攜帶着一些未傳遞UDP數據報的信息。
當ttcp接收端看到一個只具有4個字節數據的特殊數據報時，它便會知道數據傳輸是完整的，並且會因此關閉正在監聽的端口。事實上ttcp發送端發送5個這樣的分組，並且後面的分組到達的時候發現接收端已經沒有在監聽了。當發送端發送所有的數據而沒有相應的接收標誌的時候，將會看到相似的行爲。
TCP和UDP的另外一個不同之處在於TCP連接時點對點的，換句話說，TCP的使用是在一個連接端和一個發送端之間的。而對於UDP來說，一個發送端可能發向多個接收端（例如廣播和組播通信）或者多個發送端能夠發送給一個接收端。如果多個發送端都發給這個接收端的話，這個接收端會爲每個發送端報告統計信息。
TCP和UDP的最後一個不同之處是它們首部的大小。UDP首部總是8個字節，而TCP首部大小是變化的，但是它絕對不會少於20個字節。這也就是說傳輸5000個字節的實際數據TCP的開銷是36﹪。

四、問題與思考
在實驗的基礎上，回答以下問題：
1、在udp_2transmit.cap中觀察DUP首部。長度字段是包括首部和數據還是隻包括數據？
2、我們觀察到使用ICMP報文來報告UDP數據報不可達。爲什麼TCP不用這個來指示丟失的報文段呢？
3、我們計算TCP成功傳輸5000個字節的實際數據的開銷是36﹪。在這個開銷中都包括什麼？如果沒有重傳，這個開銷是多少？

 

實驗六 使用Wireshark分析TCP協議

一、實驗目的
分析TCP協議
二、實驗環境
與因特網連接的計算機，操作系統爲Windows，安裝有Wireshark、IE等軟件。
三、實驗步驟
1、TCP介紹
（1）連接建立：
TCP連接通過稱爲三次握手的三條報文來建立的。在Wireshark中選擇open->file,選擇文件tcp_pcattcp_n1.cap，其中分組3到5顯示的就是三次握手。
第一條報文沒有數據的TCP報文段，並將首部SYN位設置爲1。因此，第一條報文常被稱爲SYN分組。這個報文段裏的序號可以設置成任何值，表示後續報文設定的起始編號。連接不能自動從1開始計數，選擇一個隨機數開始計數可避免將以前連接的分組錯誤地解釋爲當前連接的分組。觀察分組3，Wireshark顯示的序號是0。選擇分組首部的序號字段，原始框中顯示“94 f2 2e be”。Wireshark顯示的是邏輯序號，真正的初始序號不是0。如圖1所示：

               圖１：邏輯序號與實際初始序號

SYN分組通常是從客戶端發送到服務器。這個報文段請求建立連接。一旦成功建立了連接，服務器進程必須已經在監聽SYN分組所指示的IP地址和端口號。如果沒有建立連接，SYN分組將不會應答。如果第一個分組丟失，客戶端通常會發送若干SYN分組，否則客戶端將會停止並報告一個錯誤給應用程序。
如果服務器進程正在監聽並接收到來的連接請求，它將以一個報文段進行相應，這個報文段的SYN位和ACK位都置爲1。通常稱這個報文段爲SYNACK分組。SYNACK分組在確認收到SYN分組的同時發出一個初始的數據流序號給客戶端。
分組4的確認號字段在Wireshark的協議框中顯示1，並且在原始框中的值是“94 f2 2e bf”（比“94 f2 2e be”多1）。這解釋了TCP的確認模式。TCP接收端確認第X個字節已經收到，並通過設置確認號爲X+1來表明期望收到下一個字節號。分組4的序號字段在Wireshark的協議顯示爲0，但在原始框中的實際值卻是“84 ca be b3”。這表明TCP連接的雙方會選擇數據流中字節的起始編號。所有初始序號邏輯上都視同爲序號0。
最後，客戶端發送帶有標誌ACK的TCP報文段，而不是帶SYN的報文段來完成三次握手的過程。這個報文段將確認服務器發送的SYNACK分組，並檢查TCP連接的兩端是否正確打開合運行。
（2）關閉連接
當兩端交換帶有FIN標誌的TCP報文段並且每一端都確認另一端發送的FIN包時，TCP連接將會關閉。FIN位字面上的意思是連接一方再也沒有更多新的數據發送。然而，那些重傳的數據會被傳送，直到接收端確認所有的信息。在tcp_pcattcp_n1.cap中，通過分組13至16我們可以看到TCP連接被關閉。
2、TCP重傳
當一個TCP發送端傳輸一個報文段的同時也設置了一個重傳計時器。當確認到達時，這個計時器就自動取消。如果在數據的確認信息到達之前這個計時器超時，那麼數據就會重傳。
重傳計時器能夠自動靈活設置。最初TCP是基於初始的SYN和SYN ACK之間的時間來設置重傳計時器的。它基於這個值多次設置重傳計時器來避免不必要的重傳。在整個TCP連接中，TCP都會注意每個報文段的發送和接到相應的確認所經歷的時間。TCP在重傳數據之前不會總是等待一個重傳計算器超時。TCP也會把一系列重複確認的分組當作是數據丟失的徵兆。
在Wireshark中選擇file-〉open,打開文件pcattcp_retrans_t.cap和pcattcp_retrans_r.cap，對所俘獲的分組進行分析如下：
（1） SACK選項協商
在上面的每次跟蹤中，我們能觀察建立連接的三次握手。在SYN分組中，發送端在TCP的首部選項中通過包括SACK permitted選項來希望使用TCP　SACK。在SYN ACK包中接收端表示願意使用SACK。這樣雙方都同意接收選擇性確認信息。SACK選項如圖2所示：

               			圖2 SACK選項

在TCP SACK選項中，如果連接的一端接收了失序數據，它將使用選項區字段來發送關於失序數據起始和結束的信息。這樣允許發送端僅僅重傳丟失的數據。TCP接收端不能傳遞它們接收到的失序數據給處於等待狀態的應用程序，因爲它總是傳遞有序數據。因此，接收到的失序數據要麼被丟掉，要麼被存儲起來。
接收端的存儲空間是有限的，TCP發送端必須保存一份已發送的數據的副本，以防止數據需要重發。發送端必須保存數據直到它們收到數據的確認信息爲止。
接收端通常會分配一個固定大小的緩衝區來存儲這些失序數據和需要等待一個應用程序讀取的數據。如果緩衝區空間不能容納下更多數據，那麼接收端只有將數據丟棄，即使它是成功到達的。接收端的通知窗口字段用來通知發送端還有多少空間可以用於輸入數據。如果數據發送的速度快於應用程序處理數據的速度，接收端就會發送一些信息來告知發送端其接收窗口正在減小。在這個跟蹤文件中，接收端通知窗口的大小是變化的，從16520個字節到17520個字節。
TCP發送端在發送之前有一個容納數據的有限空間。然而，和接收端不同的是，發送端是限制自己的發送速率。如果緩衝區的空間滿了，嘗試寫入更多數據的應用程序將被阻塞直到有更多的空間可以利用爲止。
（2）分組的丟失與重傳
用顯示過濾器tcp.analysis.retransmission搜索重傳。在pcattcp_retrans_t.cap中應用該過濾器，在這個跟蹤文件中，我們看見分組12是這9次重傳的第一次。如圖所示3：

               	圖3 pcattcp_retrans_t.cap中９次重傳

通過觀察分組12的細節，我們發現序號是1001，我們發現分組5也有同樣的序號。有趣的是，分組5是對1001到2460號字節的傳輸，而分組12卻是對1001到2000號字節的重傳。分組20是對2001到2460號字節的重傳。
分組4是對1到1000號字節的傳輸，分組5是對1001到2460號字節的傳輸，分組7是對2461到3920號字節的傳輸。
我們已檢查了發送端上獲取的所有跟蹤記錄。我們從接收端的角度來看同一個連接，我們會發現有些不同。在pcattcp_retrans_r.cap中，我們發現1到1000號字節是在分組4裏被傳送的，而2461到3920號字節是在分組6（而不是分組7）中被傳送的。在這個跟蹤文件中，分組5是1到1000號字節的確認。我們沒有看到1001到2460號字節的傳輸。但是他們確實被傳輸送了，只是在發送端和接收端的某個環節丟失了。
現在我們來看接收端是如何處理這些丟失字節的。在分組4達到以後，接收端會以確認號1001（分組5）作爲響應。在分組6的2461到3920號字節達到之後，接收端仍然以確認號1001（分組7）作爲響應。即使它接到的是附加數據，確認號仍然是它期望收到的下一個有序字節的序號。同樣在含有3921到5381號字節的分組8到達之後，接收端仍然以1001響應。
最後，1001到2000號字節被重傳。在這兩次跟蹤中，我們都在分組12裏看到這種情況。於是接收端增加它的確認號到2001。
最終2001到2460號字節被重傳。在這次重傳之後，接收端可以立即從確認字節2001跳到確認字節11221。
四、問題與思考
在實驗的基礎上，回答以下問題：
1、 客戶服務器之間用於初始化TCP連接的TCP SYN報文段的序號（sequence number）是多少？在該報文段中，是用什麼來標識該報文段是SYN報文段的？
2、 服務器向客戶端發送的SYNACK報文段序號是多少？該報文段中，ACKnowledgement字段的值是多少？
3、 找出pcattcp_retrans_t.cap中所有在到達接收端之前丟失的分組。對於每個丟失的報文段，找出重傳分組（提示：找出第一個丟失的字節和重傳它們的分組）．
4、 當接收端發送一個TCP報文段來確認收到的數據時，這個報文段也可能丟失。在pcattcp_retrans_t.cap和pcattcp_retrans_r.cap中存在這樣的丟失嗎？你是怎麼得到這樣的答案的？

 

實驗七 利用Wireshark分析協議HTTP

一、實驗目的
分析HTTP協議
二、實驗環境
與因特網連接的計算機，操作系統爲Windows，安裝有Wireshark、IE等軟件。
三、實驗步驟
1、利用Wireshark俘獲HTTP分組
（1）在進行跟蹤之前，我們首先清空Web 瀏覽器的高速緩存來確保Web網頁是從網絡中獲取的，而不是從高速緩衝中取得的。之後，還要在客戶端清空DNS高速緩存，來確保Web服務器域名到IP地址的映射是從網絡中請求。在WindowsXP機器上，可在命令提示行輸入ipconfig/flushdns完成操作。
（2）啓動Wireshrk 分組俘獲器。
（3）在Web 瀏覽器中輸入：http://www.google.com
（4）停止分組俘獲。

               圖1 利用Wireshark俘獲的HTTP分組

在URL http://www.google.com中，www.google.com 是一個具體的web 服務器的域名。最前面有兩個DNS分組。第一個分組是將域名www.google.com轉換成爲對應的IP 地址的請求，第二個分組包含了轉換的結果。這個轉換是必要的，因爲網絡層協議——IP協議，是通過點分十進制來表示因特網主機的，而不是通過www.google.com這樣的域名。當輸入URL http：//www.google.com時，將要求Web服務器從主機www.google.com上請求數據，但首先Web瀏覽器必須確定這個主機的IP地址。
隨着轉換的完成，Web瀏覽器與Web服務器建立一個TCP連接。最後，Web 瀏覽器使用已建立好的TCP連接來發送請求“GET/HTTP/1.1”。這個分組描述了要求的行爲（“GET”）及文件（只寫“/”是因爲我們沒有指定額外的文件名），還有所用到的協議的版本（“HTTP/1.1”）。
2、HTTP GET/response交互
（1）在協議框中，選擇“GET/HTTP/1.1” 所在的分組會看到這個基本請求行後跟隨着一系列額外的請求首部。在首部後的“\r\n”表示一個回車和換行，以此將該首部與下一個首部隔開。
“Host”首部在HTTP1.1版本中是必須的，它描述了URL中機器的域名，本例中是www.google.com。這就允許了一個Web服務器在同一時間支持許多不同的域名。有了這個數不，Web服務器就可以區別客戶試圖連接哪一個Web服務器，並對每個客戶響應不同的內容，這就是HTTP1.0到1.1版本的主要變化。
User-Agent首部描述了提出請求的Web瀏覽器及客戶機器。
接下來是一系列的Accpet首部，包括Accept（接受）、Accept-Language（接受語言）、Accept-Encoding（接受編碼）、Accept-Charset（接受字符集）。它們告訴Web服務器客戶Web瀏覽器準備處理的數據類型。Web服務器可以將數據轉變爲不同的語言和格式。這些首部表明了客戶的能力和偏好。
Keep-Alive及Connection首部描述了有關TCP連接的信息，通過此連接發送HTTP請求和響應。它表明在發送請求之後連接是否保持活動狀態及保持多久。大多數HTTP1.1連接是持久的（persistent）,意思是在每次請求後不關閉TCP連接，而是保持該連接以接受從同一臺服務器發來的多個請求。
（2）我們已經察看了由Web瀏覽器發送的請求，現在我們來觀察Web服務器的回答。響應首先發送“HTTP/1.1 200 ok”，指明它開始使用HTTP1.1版本來發送網頁。同樣，在響應分組中，它後面也跟隨着一些首部。最後，被請求的實際數據被髮送。
第一個Cache-control首部，用於描述是否將數據的副本存儲或高速緩存起來，以便將來引用。一般個人的Web瀏覽器會高速緩存一些本機最近訪問過的網頁，隨後對同一頁面再次進行訪問時，如果該網頁仍存儲於高速緩存中，則不再向服務器請求數據。類似地，在同一個網絡中的計算機可以共享一些存在高速緩存中的頁面，防止多個用戶通過到其他網路的低速網路連接從網上獲取相同的數據。這樣的高速緩存被稱爲代理高速緩存（proxy cache）。在我們所俘獲的分組中我們看到“Cache-control”首部值是“private”的。這表明服務器已經對這個用戶產生了一個個性化的響應，而且可以被存儲在本地的高速緩存中，但不是共享的高速緩存代理。
在HTTP請求中，Web服務器列出內容類型及可接受的內容編碼。此例中Web服務器選擇發送內容的類型是text/html且內容編碼是gzip。這表明數據部分是壓縮了的HTML。
服務器描述了一些關於自身的信息。此例中，Web服務器軟件是Google自己的Web服務器軟件。響應分組還用Content-Length首部描述了數據的長度。最後，服務器還在Date首部中列出了數據發送的日期和時間。
根據俘獲窗口內容，回答“四、實驗報告內容”中的1-6題。
3、HTTP條件GET/response交互
（1）啓動瀏覽器，清空瀏覽器的緩存。
（2）啓動Wireshark分組俘獲器，開始Wireshark分組俘獲。
（3）在瀏覽器地址欄中如下網址：
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file2.html
你的瀏覽器中將顯示一個具有五行的非常簡單的HTML文件。
（4）在你的瀏覽器中重新輸入相同的URL或單擊瀏覽器中的“刷新”按鈕。
（5）停止Wireshark分組俘獲，在顯示過濾篩選說明處輸入“http”,分組列表子窗口中將只顯示所俘獲到的HTTP報文。
根據操作回答“四、實驗報告內容”中的7-10題。
4、獲取長文件
（1）啓動瀏覽器，將瀏覽器的緩存清空。
（2）啓動Wireshark 分組俘獲器，開始Wireshark分組俘獲。
（3）在瀏覽器地址欄中輸入如下網址:
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file3.html
瀏覽器將顯示一個相當大的美國權力法案
（4）停止Wireshark分組俘獲，在顯示過濾篩選說明處輸入“http”,分組列表子窗口中將只顯示所俘獲到的HTTP報文。
根據操作回答“四、實驗報告內容”中的11-14題。
5、嵌有對象的HTML文檔
（1）啓動瀏覽器，將瀏覽器的緩存清空。
（2）啓動Wireshark分組俘獲器。開始Wireshark分組俘獲。
（3）在瀏覽器地址欄中輸入如下網址：
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file4.html
瀏覽器將顯示一個具有兩個圖片的短HTTP文件。
（4）停止Wireshark分組俘獲，在顯示過濾篩選說明處輸入“http”,分組列表子窗口中將只顯示所俘獲到的HTTP報文。
根據操作回答“四、實驗報告內容”中的15-16題。
6、HTTP認證
（1）啓動瀏覽器，將瀏覽器的緩存清空。
（2）啓動Wireshark分組俘獲器。開始Wireshark分組俘獲。
（3）在瀏覽器地址欄中輸入如下網址：
http://gaia.cs.umass.edu/wireshark-labs/protected_pages/HTTP-wireshark-file5.html
瀏覽器將顯示一個HTTP文件，輸入所需要的用戶名和密碼(用戶名：wireshark-students,密碼:network)。
（4）停止Wireshark分組俘獲，在顯示過濾篩選說明處輸入“http”,分組列表子窗口中將只顯示所俘獲到的HTTP報文。
根據操作回答“四、問題與思考”中的17-18題。

四、問題與思考
在實驗的基礎上，回答以下問題：
（1）你的瀏覽器運行的是HTTP1.0，還是HTTP1.1？你所訪問的服務器所運行的HTTP版本號是多少？
（2）你的瀏覽器向服務器指出它能接收何種語言版本的對象？
（3）你的計算機的IP地址是多少？服務器gaia.cs.umass.edu的IP地址是多少？
（4）從服務器向你的瀏覽器返回的狀態代碼是多少？
（5）你從服務器上所獲取的HTML文件的最後修改時間是多少？
（6）返回到你的瀏覽器的內容以供多少字節？
（7）分析你的瀏覽器向服務器發出的第一個HTTP GET請求的內容，在該請求報文中，是否有一行是：IF-MODIFIED-SINCE？
（8）分析服務器響應報文的內容，服務器是否明確返回了文件的內容？如何獲知？
（9）分析你的瀏覽器向服務器發出的第二個“HTTP GET”請求，在該請求報文中是否有一行是：IF-MODIFIED-SINCE？如果有，在該首部行後面跟着的信息是什麼？
（10）服務器對第二個HTTP GET請求的響應中的HTTP狀態代碼是多少？服務器是否明確返回了文件的內容？請解釋。
（11）你的瀏覽器一共發出了多少個HTTP GET請求？
（12）承載這一個HTTP響應報文一共需要多少個data-containing TCP報文段？
（13）與這個HTTP GET請求相對應的響應報文的狀態代碼和狀態短語是什麼？
（14）在被傳送的數據中一共有多少個HTTP狀態行與TCP-induced”continuation”有關？
（15）你的瀏覽器一共發出了多少個HTTP GET請求？這些請求被髮送到的目的地的IP地址是多少？
（16）瀏覽器在下載這兩個圖片時，是串行下載還是並行下載？請解釋。
（17）對於瀏覽器發出的最初的HTTP GET請求，服務器的響應是什麼(狀態代碼和狀態短語)?
（18）當瀏覽器發出第二個HTTP GET請求時，在HTTP GET報文中包含了哪些新的字段？

 

實驗八 利用Wireshark分析DNS協議

一、實驗目的
分析DNS協議
二、實驗環境
與因特網連接的計算機，操作系統爲Windows，安裝有Wireshark、IE等軟件。
三、實驗步驟
nslookup工具允許運行該工具的主機向指定的DNS服務器查詢某個DNS記錄。如果沒有指明DNS服務器，nslookup將把查詢請求發向默認的DNS服務器。其命令的一般格式是：
nslookup –option1 –option2 host-to-find dns-server
1、打開命令提示符（Command Prompt），輸入nslookup命令。

圖中顯示三條命令，第一條命令：nslookup www.mit.edu “提出一個問題”
即：“將主機www.mit.edu 的IP地址告訴我”。屏幕上出現了兩條信息：（1）“回答這一問題”DNS服務器的名字和IP地址；（2）www.mit.edu 主機名字和IP地址。
第二條命令：nslookup –type=NS mit.edu
在這個例子中，我們提供了選項“-type=NS”，域爲mit.edu。執行這條命令後，屏幕上顯示了DNS服務器的名字和地址。接着下面是三個MIT DNS服務器，
每一個服務器是MIT校園裏權威的DNS服務器。
第三條命令：nslookup www.aiit.or.kr bitsy.mit.edu
在這個例子中，我們請求返回bitsy.mit.edu DNS server 而不是默認的DNS服務器(uzzdns.edu.cn)。此例中，DNS 服務器bitsy.mit.edu提供主機www.aiit.or.kr 的
IP地址。
2、ipconfig
ipconfig用來顯示TCP/IP 信息, 你的主機地址、DNS服務器地址，適配器等信息。如果你想看到所有關於你所在主機的信息，可在命令行鍵入：
ipconfig /all

ipconfig在管理主機所儲存的DNS信息非常有用。
如果查看DNS緩存中的記錄用命令：ipconfig /displaydns
要清空DNS緩存，用命令：ipconfig /flushdns
3、利用Wireshark捕獲DNS信息
（1）利用ipconfig命令清空你的主機上的DNS緩存。
（2）啓動瀏覽器，將瀏覽器的緩存清空。
（3）啓動Wireshark分組俘獲器，在顯示過濾篩說明處輸入
“ip.addryour_IP_address”(如：ip.addr202.202.210.104)，過濾器（filter）將會刪除所有目的地址和源地址都與指定IP地址不同的分組。
（4）開始Wireshark俘獲。
（5）在瀏覽器的地址欄中輸入：http://www.ietf.org
（6）停止分組俘獲。
（7）重複上面的實驗，只是將命令替換爲：nslookup –type=NS mit.edu
（8）重複上面的實驗，只是將命令替換爲：
nslookup www.aiit.or.kr bitsy.mit.edu
四、問題與思考
在實驗的基礎上，回答以下問題：
（1）你的瀏覽器運行的是HTTP1.0，還是HTTP1.1？你所訪問的服務器所運行的HTTP版本號是多少？
（2）你的瀏覽器向服務器指出它能接收何種語言版本的對象？
（3）你的計算機的IP地址是多少？服務器gaia.cs.umass.edu的IP地址是多少？
（4）從服務器向你的瀏覽器返回的狀態代碼是多少？
（5）你從服務器上所獲取的HTML文件的最後修改時間是多少？
（6）返回到你的瀏覽器的內容以供多少字節？
（7）分析服務器響應報文的內容，服務器是否明確返回了文件的內容？如何獲知？
（8）服務器對第二個HTTP GET請求的響應中的HTTP狀態代碼是多少？服務器是否明確返回了文件的內容？請解釋。
（9）與這個HTTP GET請求相對應的響應報文的狀態代碼和狀態短語是什麼？
（10）你的瀏覽器一共發出了多少個HTTP GET請求？這些請求被髮送到的目的地的IP地址是多少？
（11）對於瀏覽器發出的最初的HTTP GET請求，服務器的響應是什麼(狀態代碼和狀態短語)?
（12）當瀏覽器發出第二個HTTP GET請求時，在HTTP GET報文中包含了哪些新的字段？
（13）DNS查詢報文的目的端口號是多少？DNS查詢響應報文的源端口號是多少？

 

如有不足之處，還望指正 ¹。

---

1. 如果對您有幫助可以點贊、收藏、關注，將會是我最大的動力 ↩︎