實驗報告原文
1. 實驗內容
- 捕獲在連接Internet 過程中產生的網絡層分組：DHCP 分組，ARP 分組，IP 數據分組，ICMP 分組。
- 分析各種分組的格式，說明各種分組在建立網絡連接過程中的作用。
- 分析IP 數據分組分片的結構。通過本次實驗瞭解計算機上網的工作過程，學習各種網絡層分組的格式及其作用，理解長度大於1500 字節IP 數據組分片傳輸的結構。
2. 實驗環境
- Microsoft Windows 10.0.18362.836
- Wireshark Version 3.2.3 (v3.2.3-0-gf39b50865a13)
- Win10Pcap v10.2-5002
3. 實驗流程
3.1 ICMP報文的捕獲與解析
3.1.1 ICMP概述
ICMP（Internet Control Message Protocol）Internet控制報文協議。它是TCP/IP協議簇的一個子協議，用於在IP主機、路由器之間傳遞控制消息。控制消息是指網絡通不通、主機是否可達、路由是否可用等網絡本身的消息。這些控制消息雖然並不傳輸用戶數據，但是對於用戶數據的傳遞起着重要的作用。
ICMP 是 TCP/IP 模型中網絡層的重要成員，與 IP 協議、ARP 協議、RARP 協議及 IGMP 協議共同構成 TCP/IP 模型中的網絡層。ping 和 tracert是兩個常用網絡管理命令，ping 用來測試網絡可達性，tracert 用來顯示到達目的主機的路徑。ping和 tracert 都利用 ICMP 協議來實現網絡功能，它們是把網絡協議應用到日常網絡管理的典型實例。
ICMP報文包含在IP數據報中，屬於IP的一個用戶，IP頭部就在ICMP報文的前面，所以一個ICMP報文包括IP頭部、ICMP頭部和ICMP報文，IP頭部的Protocol值爲1就說明這是一個ICMP報文，ICMP頭部中的類型（Type）域用於說明ICMP報文的作用及格式，此外還有一個代碼（Code）域用於詳細說明某種ICMP報文的類型，所有數據都在ICMP頭部後面。ICMP報文的種類有兩種，即ICMP差錯報告報文和ICMP詢問報文。
3.1.2 ICMP數據報的捕獲
-
運行Wireshark軟件，在首頁選擇網絡連接，進入捕獲。
-
在頂層過濾器處輸入
icmp過濾出ICMP報文。
![在這裏插入圖片描述]()
-
新建一個命令提示符窗口，輸入
ping www.bupt.edu.cn並回車執行，觀察Wireshark捕獲的數據報。
![在這裏插入圖片描述]()
3.1.3 捕獲的ICMP報文
由於MAC地址的全球唯一性，這裏已將MAC地址抹去，用全x和全y代替源MAC和目的MAC.
request
0000 yy yy yy yy yy yy xx xx xx xx xx xx 08 00 45 00
0010 00 3c 43 b5 00 00 80 01 00 00 c0 a8 1f b8 d3 44
0020 45 f0 08 00 46 ae 00 01 06 ad 61 62 63 64 65 66
0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76
0040 77 61 62 63 64 65 66 67 68 69
reply
0000 xx xx xx xx xx xx yy yy yy yy yy yy 08 00 45 00
0010 00 3c 4e 88 00 00 34 01 3e a4 d3 44 45 f0 c0 a8
0020 1f b8 00 00 4e ae 00 01 06 ad 61 62 63 64 65 66
0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76
0040 77 61 62 63 64 65 66 67 68 69
3.1.4 解析ICMP報文
3.1.4.1 以太網報頭和IP報頭
| 單元的字節數 | 值（默認二進制，其他進制會說明） | 內容解釋 |
|---|---|---|
| 14 | 略 | 以太網報頭 |
| 1 | 01000101 | IP數據報的報頭開始。包含版本(4 bits)和首部長度(4 bits)。 版本：0100，表示IPv4 首部長度：0101，表示首部共有20字節（單位爲4 bytes） |
| 1 | 00000000 | 服務類型/區分服務，因爲沒有使用區分服務所以這裏不起作用。 |
| 2 | 00000000 00111100 |
總長度，指分組的長度，即首部和數據之和的長度，單位爲字節。 這裏表示60 bytes. |
| 2 | 01000011 10110101 |
標識，由發送方產生，用於接收方重組數據報時確定哪些分段（分片）屬於同一個數據報。 這裏表示標識號位17333. |
| 2 | 00000000 00000000 |
包含標誌(3 bits)和片偏移(13 bits). 標誌：000，表示是否進行了分段/分片，目前只有前兩個比特有意義。最低位是MF，MF=1表示後面還有分段，MF=0表示這是最後一個分段。中間一位是DF，只有DF=0時才允許分段。 這裏表示允許分段、是最後一個分段。 分段偏移量：00000 00000000，指出較長的分組在分段後某片在原分組中的相對位置。分段偏移量以8 個字節爲偏移單位。這裏表示這個分片是原分組的從第0*8=0個字節起始的。 |
| 1 | 10000000 | 生存時間，記爲TTL（Time To Live）。爲了限制數據報在網絡中的生存時間，用“跳數” 作爲單位。數據報每經過一個路由器，其TTL 值就減1。 這裏表示起始的TTL爲128. |
| 1 | 00000001 | 協議，指出此數據報攜帶的數據使用何種協議，以便目的主機的IP 層將數據部分上交給哪個處理過程。 這裏表示使用ICMP協議(1)。 |
| 2 | 00000000 00000000 |
首部檢驗和，只檢驗數據報的首部不包括數據部分，這裏不採用CRC 校驗碼而採用checksum。 這裏爲0是因爲開啓了網卡的“硬件校驗和”的功能。開啓了這個功能之後協議棧就不會進行校驗和的計算了，有助於提高網絡性能。關閉網卡的硬件校驗和功能後這裏會有有效的校驗和。 |
| 4 | 11000000 10101000 00011111 10111000 |
源地址。 這裏爲192.168.31.184 |
| 4 | 11010011 01000100 01000101 11110000 |
目標地址。 這裏爲211.68.69.240 |
3.1.4.2 ICMP報文
| 單元的字節數 | 值（默認二進制，其他進制會說明） | 內容解釋 |
|---|---|---|
| 1 | 00001000 | 類型（Type）字段，根據類型和代碼字段可以劃分爲差錯報告和詢問兩種類型的ICMP報文，不同的搭配有不同的含義。 此處類型爲8，含義見“代碼”字段處的描述。 |
| 1 | 00000000 | 代碼（Code）字段，與類型搭配。 此處代碼爲0，類型爲8，查表知爲詢問的ICMP報文，爲Echo request——回顯請求（Ping請求）。 |
| 2 | 01000110 10101110 |
校驗和字段，對整個ICMP報文進行校驗，計算方法與IPv4數據包採用的計算方法相同。 此處爲0x46ae，校驗正確。 |
| 2 | 00000000 00000001 |
含義可變，爲Ping請求時表示標識符，Unix系統在實現ping程序時把ICMP報文中的標識符字段置成發送進程的ID號。這樣即使在同一臺主機上同時運行了多個ping程序實例，ping程序也可以識別出返回的信息。 此處可以解讀爲1(BE，大端序)或256(LE，小端序). |
| 2 | 00000110 10101101 |
含義可變，爲Ping請求時表示序號，序列號從0開始，每發送一次新的回顯請求就加1。ping程序打印出返回的每個分組的序列號，允許我們查看是否有分組丟失，失序或重複。 此處爲0x06ad(BE)或者0xad06(LE). |
| 16 | 32個字節的迷惑數據 | 含義可變，爲Ping請求時，RFC792的echo and echo reply message對data的唯一的要求是echo reply報文中的data的值必須和echo報文中的data的值相同，因此可以推測data字段的值可以是任意的，根據不同的ping程序實現有不同的意義。 在Microsoft給出的ping的樣例代碼中，data的前4個字節的數據是用於計算往返時間的時間戳，後面全是0x02. |
3.2 ARP報文的捕獲與解析
3.2.1 ARP概述
ARP（Address Resolution Protocol），是根據IP地址獲取物理地址的一個TCP/IP協議。主機發送信息時將包含目標IP地址的ARP請求廣播到局域網絡上的所有主機，並接收返回消息，以此確定目標的物理地址；收到返回消息後將該IP地址和物理地址存入本機ARP緩存中並保留一定時間。
3.2.2 ARP數據報的捕獲
-
運行Wireshark軟件，在首頁選擇網絡連接，進入捕獲。
-
在頂層過濾器處輸入
arp過濾出ARP報文。
![在這裏插入圖片描述]()
-
任取一條報文，這裏取第一條報文。
3.2.3 捕獲的ARP報文
0000 yy yy yy yy yy yy xx xx xx xx xx xx 08 06 00 01
0010 08 00 06 04 00 02 xx xx xx xx xx xx c0 a8 1f b8
0020 yy yy yy yy yy yy c0 a8 1f 01
3.2.4 解析ARP報文
| 單元的字節數 | 值（默認二進制，其他進制會說明） | 內容解釋 |
|---|---|---|
| 14 | 略 | 以太網報頭 |
| 2 | 00000000 00000001 |
ARP報頭的開始。 硬件類型，表示ARP報文可以在哪種類型的網絡上傳輸。 此處爲1，表示爲以太網地址。 |
| 2 | 00001000 00000000 |
上層協議類型，表示硬件地址要映射的協議地址類型。 此處爲0x0800，表示IPv4協議。 |
| 1 | 00000110 | MAC地址長度，標識MAC地址長度，以字節爲單位。 此處爲6，表示MAC地址長度爲6字節。 |
| 1 | 00000100 | IP協議地址長度，標識IP得知長度，以字節爲單位。 此處爲4，表示IP地址長度爲4字節。 |
| 2 | 00000000 00000010 |
操作類型，指定本次ARP報文類型。1標識ARP請求報文，2標識ARP應答報文。 此處爲2，表示應答報文。 |
| 6 | xx xx xx xx xx xx(hex) | 源MAC地址，標識發送設備的硬件地址。 此處爲xx-xx-xx-xx-xx-xx. |
| 4 | 11000000 10101000 00011111 10111000 |
源IP地址，標識發送方設備的IP地址。 此處爲192.168.31.184 |
| 6 | yy yy yy yy yy yy(hex) | 目的MAC地址，表示接收方設備的硬件地址。如果爲全0，則表示任意地址（因爲當前不知道）。 此處爲yy-yy-yy-yy-yy-yy. |
| 4 | 11000000 10101000 00011111 00000001 |
目的IP地址，表示接受方的IP地址。 此處爲192.168.31.1 |
3.3 DHCP報文的捕獲與解析
3.3.1 DHCP概述
DHCP（Dynamic Host Configuration Protocol，動態主機配置協議）通常被應用在大型的局域網絡環境中，主要作用是集中的管理、分配IP地址，使網絡環境中的主機動態的獲得IP地址、Gateway地址、DNS服務器地址等信息，並能夠提升地址的使用率。
DHCP協議採用客戶端/服務器模型，主機地址的動態分配任務由網絡主機驅動。當DHCP服務器接收到來自網絡主機申請地址的信息時，纔會向網絡主機發送相關的地址配置等信息，以實現網絡主機地址信息的動態配置。
DHCP消息的格式是基於BOOTP（Bootstrap Protocol）消息格式。
DHCP共有八種報文類型，分別爲DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK、DHCP NAK、DHCP Release、DHCP Decline、DHCP Inform。一個典型的向DHCP申請IP地址的過程如下：
3.3.2 DHCP數據報的捕獲
-
運行Wireshark軟件，在首頁選擇網絡連接，進入捕獲。
-
在頂層過濾器處輸入
DHCP過濾出DHCP報文。
-
任取一條報文，這裏取第一條報文。
![在這裏插入圖片描述]()
3.3.3 捕獲的DHCP報文
源MAC地址被替換爲全x，主機名稱被替換爲全z。
0000 ff ff ff ff ff ff xx xx xx xx xx xx 08 00 45 00
0010 01 5e 90 5f 00 00 80 11 00 00 00 00 00 00 ff ff
0020 ff ff 00 44 00 43 01 4a f9 d5 01 01 06 00 27 81
0030 16 ee 00 00 80 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 xx xx xx xx xx xx 00 00 00 00
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0110 00 00 00 00 00 00 63 82 53 63 35 01 03 3d 07 01
0120 xx xx xx xx xx xx 32 04 c0 a8 1f b8 0c 0f zz zz
0130 zz zz zz zz zz zz zz zz zz zz zz zz zz 51 12 00
0140 00 00 zz zz zz zz zz zz zz zz zz zz zz zz zz zz
0150 zz 3c 08 4d 53 46 54 20 35 2e 30 37 0e 01 03 06
0160 0f 1f 21 2b 2c 2e 2f 77 79 f9 fc ff
3.3.4 解析DHCP報文
IP報頭在ICMP報文的解析中已詳細闡述，此處不再重複解析。
3.3.4.1 UDP數據報頭
| 單元的字節數 | 值（默認二進制，其他進制會說明） | 內容解釋 |
|---|---|---|
| 14 | 略 | 以太網報頭 |
| 20 | 略 | IP報頭 |
| 2 | 00000000 01000100 |
UDP報頭的開始。 源端口字段，包含發送數據報的應用程序所使用的 UDP 端口。接收端的應用程序利用這個字段的值作爲發送響應的目的地址。如果設爲全0，則接收端不能發送回覆。 此處爲68. |
| 2 | 00000000 01000011 |
目的端口字段，接收端計算機上 UDP 軟件使用的端口。 此處爲67. |
| 2 | 00000001 01001010 |
長度，表示 UDP 數據報長度，包含 UDP 報文頭和 UDP 數據長度。因爲 UDP 報文頭長度是 8 個字節，所以這個值最小爲 8。 此處爲330. |
| 2 | 11111001 11010101 |
校驗和，進行檢驗和計算時，會添加一個僞首部一起進行運算。 此處爲0xf9d5. |
3.3.4.2 DHCP數據報
| 單元的字節數 | 值（默認二進制，其他進制會說明） | 內容解釋 |
|---|---|---|
| 1 | 00000001 | 報文的操作類型，分爲請求報文和響應報文。1：請求報文，2：應答報文。 此處爲1，表示請求報文。 |
| 1 | 00000001 | DHCP客戶端的MAC地址類型，通常爲1，表示以太網的MAC地址。 此處爲1，表示以太網MAC。 |
| 1 | 00000110 | DHCP客戶端的MAC地址長度。 此處爲6，表示DHCP客戶端的MAC地址長度爲6. |
| 1 | 00000000 | DHCP報文經過的DHCP中繼的數目，默認爲0。DHCP請求報文每經過一個DHCP中繼，該字段就會增加1。沒有經過DHCP中繼時值爲0。(若數據包需經過router傳送，每站加1，若在同一網內，爲0。) 此處爲0，表示沒有經過中繼。 |
| 4 | 00100111 10000001 00010110 11101110 |
請求標識，用來標識一次IP地址請求過程。在一次請求中所有報文的請求標識都是一樣的。 此處爲0x278116ee. |
| 2 | 00000000 00000000 |
DHCP客戶端從獲取到IP地址或者續約過程開始到現在所消耗的時間，以秒爲單位。在沒有獲得IP地址前該字段始終爲0。(DHCP客戶端開始DHCP請求後所經過的時間。尚未使用時固定爲0。) 此處爲0，表示未獲得IP地址。 |
| 2 | 10000000 00000000 |
標誌位，只使用第0比特位，是廣播應答標識位，用來標識DHCP服務器應答報文是採用單播還是廣播發送，0表示採用單播發送方式，1表示採用廣播發送方式。其餘位尚未使用。 此處首位爲1，表示廣播。 |
| 4 | 00000000 00000000 00000000 00000000 |
DHCP客戶端的IP地址。僅在DHCP服務器發送的ACK報文中顯示，在其他報文中均顯示0，因爲在得到DHCP服務器確認前，DHCP客戶端是還沒有分配到IP地址的。 此處爲全0，表示沒有分配到地址。 |
| 4 | 00000000 00000000 00000000 00000000 |
DHCP服務器分配給客戶端的IP地址，僅在DHCP服務器發送的Offer和ACK報文中顯示，其他報文中顯示爲0。 此處全0，因爲這不是分配地址的報文。 |
| 4 | 00000000 00000000 00000000 00000000 |
下一個爲DHCP客戶端分配IP地址等信息的DHCP服務器IP地址，僅在DHCP Offer、DHCP ACK報文中顯示，其他報文中顯示爲0。(用於bootstrap過程中的IP地址) 此處爲全0，因爲還不知道DHCP服務器地址。 |
| 4 | 00000000 00000000 00000000 00000000 |
DHCP客戶端發出請求報文後經過的第一個DHCP中繼的IP地址，如果沒有經過DHCP中繼，則顯示爲0。(轉發代理（網關）IP地址) 此處爲全0，因爲沒有中繼。 |
| 16 | xx xx xx xx xx xx 00 00 00 00 00 00 00 00 00 00(hex) |
DHCP客戶端的MAC地址，在每個報文中都會顯示對應DHCP客戶端的MAC地址。後跟10字節的填充位，全部爲0. 此處用全x做隱藏。 |
| 64 | 00 共64個(hex) | 爲DHCP客戶端分配IP地址的DHCP服務器名稱（DNS域名格式），在Offer和ACK報文中顯示發送報文的DHCP服務器名稱，其他報文顯示爲0。 |
| 128 | 00 共128個(hex) | DHCP服務器爲DHCP客戶端指定的啓動配置文件名稱及路徑信息，僅在DHCP Offer報文中顯示，其他報文中顯示爲空。 |
| 4 | 01100011 10000010 01010011 01100011 |
後續可選字段的格式。 此處爲爲固定值，表示DHCP格式。 |
| …… | …… | 可選字段 |
3.3.5 DHCP的工作流程
3.3.5.1 捕獲申請IP地址時的DHCP數據報
爲了觀察計算機向DHCP服務器申請IP地址的典型流程，將計算機的網絡斷開後重連，並使用Wireshark捕獲。
- 新建命令提示符窗口，輸入
ipconfig /release
系統將釋放已獲取的IP地址，此時計算機連接到了熱點，但是沒有Internet連接，適配器屬性中的IP地址無效，在Wireshark中看到了DHCP release的報文。
- 由於試驗用計算機使用無線網絡，將熱點的連接斷開後再重連即可。
說明：另一種方法是在命令提示符中使用
ipconfig /renew
但在實際測試時，命令提示符被阻塞在無線連接獲取IP的過程中，所以採用了手動開關無線網絡連接。
- 在Wireshark的頂層過濾器中輸入
DHCP
篩選出DHCP報文。可以看到在連接過程中產生了DHCP Discover, DHCP Offer, DHCP Request和DHCP ACK數據報。
3.3.5.2 DHCP典型工作流程中的數據報解析
-
DHCP客戶端接入到網絡後，如果設置爲使用DHCP獲取IP地址，則其發送DHCP Discover數據報。
- 源MAC地址是自己的MAC地址，目的MAC地址是全F的廣播。
- 源IP是0.0.0.0，因爲話還沒有獲取到IP，目的IP是255.255.255.255的廣播。
![在這裏插入圖片描述]()
-
DHCP服務器收到客戶端發的DHCP Discover之後，會在自己的地址池中拿出一個沒有分配的地址以及配套的參數（如：掩碼、DNS、網關、域名、租期……），然後以一個DHCP Offer包發送出去。這時客戶端還沒有獲得IP，DHCP服務器端現在還無法定位客戶端，所以用廣播來回應。
這個DHCP Offer數據包的地址如下：
- 源MAC是DHCP服務器的MAC，目的MAC是的廣播
- 源IP是DHCP服務器的IP，目的IP是255.255.255.255的廣播。
![在這裏插入圖片描述]()
- 客戶端收到這個DHCP Offer後，會再發出一個DHCP Request給服務器來申請這個Offer中包含的地址。
這個時候，客戶端還沒有正式拿到地址，所以還需要向DHCP服務器申請。
- 客戶端的源IP還是0.0.0.0，目的IP還是255.255.255.255.
- 源MAC是客戶端的MAC，目的MAC是全F的廣播包。
4. 服務器收到客戶端的請求後，會發出一個DHCP ACK用來確認這個IP地址可以分配給這個客戶端。
客戶端收到DHCP ACK數據包纔算正式拿到了這個IP。
3.4 長IP分組的分片捕獲與解析
3.4.1 長IP分組的分片的捕獲
-
運行Wireshark軟件，在首頁選擇網絡連接，進入捕獲。
-
在頂層過濾器處輸入
ip.src eq 211.68.69.240 or ip.dst eq 211.68.69.240說明：
- 過濾器支持邏輯表達式，可以將多個條件組合，此處用了or。
- ip.src eq <IP地址> 表示篩選IP數據報中源地址爲給定IP地址的數據報，ip.dst eq <IP地址>同理篩選目標地址。所以這段篩選條件的含義是：篩選發送到/接收自211.68.69.240的IP數據報。
-
新建命令提示符窗口，輸入
ping 211.68.69.240 -l 8000 -n 1說明：
- ping的-l參數可以手動指定數據報的長度，單位爲字節，此處規定爲8000字節。
- ping的-n參數可以手動指定ping的次數，默認爲4次，由於此處需要分片，爲了容易分辨，只ping一次。
![在這裏插入圖片描述]()
![在這裏插入圖片描述]()
3.4.2 長分組分片的分析
IP報頭在ICMP報文的解析中已詳細闡述，此處不再重複解析。
這裏着重分析IP數據報的分片，選取request的分組進行分析。
此處略去截圖
3.4.2.2 分片的分析
可以看到，總長8000字節的分組被分片成了6個分片，關於分片的信息彙總如下：
| 分片編號 （按時間戳從早到晚） |
協議類型 | DF標誌位 | MF標誌位 | 分片偏移(Fragment Offset) | 長度(Total length) |
|---|---|---|---|---|---|
| 1 | IP | 0 | 1 | 0 | 1500 |
| 2 | IP | 0 | 1 | 1480 | 1500 |
| 3 | IP | 0 | 1 | 2960 | 1500 |
| 4 | IP | 0 | 1 | 4440 | 1500 |
| 5 | IP | 0 | 1 | 5920 | 1500 |
| 6 | ICMP | 0 | 0 | 7400 | 628 |
可以看出：
- 最後一個分片的裏IP數據報頭的數據長度字段並不是620而是628，是因爲實際組成的IP數據報裏的數據長度是8000+8=8008字節。ping畢竟是ICMP報文，要帶ICMP的Header和內容，佔8個字節。
分片時的ICMP報文在第一個分片內，可以觀察其值找出，在Wireshark裏不是很好找，因爲Wireshark總是往還原出的原IP數據報跳轉。
想一想也是合理的，畢竟服務器最先收到的是第一個分片，服務器可能會讀取到ICMP報文才允許接收後面的分片。 - DF(Don’t Fragment)字段爲1時不允許分片，爲0時允許。一般不管有沒有分片都設置爲0.
- MF(More Fragment)字段爲1表示後續還有分片，爲0時表示這是最後一個分片。當路由器或主機收到某個分片時，會檢查該字段，如果收齊了全部的分片，將會還原IP分組。
- 根據RFC894標準的規定，以太網封裝IP數據包的最大長度是1500字節（所以，數據鏈路層的最大傳輸單元（Maximum Transmission Unit，MTU）是1500字節）。而網絡層中IP數據報的報頭固定長度爲20字節，報頭的可變部分不常用，所以單個IP數據報能攜帶的數據的最大長度爲1480字節。
- IP數據報頭的分片偏移字段填寫的是該分片的首個字節在原IP數據報中的偏移量。比如分片1共發送了從第0個字節到第1399個字節共1400字節，那麼第2個分片的數據部分的起始字節應當是第1400個字節，所以該字段填寫1400，後續分片以此類推。
4. 實驗總結
本實驗利用Wireshark軟件，對多種網絡層的協議的數據報進行了捕獲和分析，包括ICMP, ARP, DHCP和IP數據報。
結合之前上課時學習的這些協議的數據報的結構和功能，對這些協議的功能有了進一步的瞭解，將上課內容付諸實踐，通過實踐加深了理解。
在實驗中熟悉了Wireshark軟件的使用，瞭解了其篩選器的語法。起初因爲Wireshark與Windows10的兼容性問題無法找到適配器，在查詢資料後安裝了Win10Pcap解決了這一問題。
在實驗中體會到了現行網絡的分層結構的特點，每一層各司其職，將原始數據經過一層一層的封裝，最終發出。許多字段都發揮着重要作用，閃現着算法的智慧光輝。
本次實驗花費的時間約爲1小時，之後花了較長的時間來整理數據和書寫報告。