目錄
一、 主機的IP地址配置與連通性測試
1.1 IP地址配置
1.2 連通性測試
1.3 網絡地址規划表
二、 數據鏈路層抓包分析
2.1 MAC幀格式
2.2 MAC地址分析
三、 網絡層抓包分析
3.1 IP報文
3.2 ARP協議
3.3 ICMP協議
四、 傳輸層抓包分析
4.1 TCP協議3次握手
4.2 TCP協議4次揮手
4.3 UDP協議
五、 應用層抓包分析
5.1 www （HTTP協議）分析
5.2 直播
六、總結
一、 主機地址的IP地址配置與連通性測試
1.1 IP地址配置
根據學校校園網自動配置給我們的網關地址：172.24.48.1，推算出子網掩碼應該設為255.255.240.0，同時計算出以學號命名最后一位的IP地址172.24.48.31為有效地址，因此配置使用此地址為主機地址。
具體配置操作如下：
首先打開“網絡與Internet”設置，找到自己的網卡，我的電腦的網卡為圖中的以太網。
雙擊以太網查看以太網狀態，點擊屬性
在屬性中找到IPV4地址的配置選項，雙擊打開
根據之前的計算，我將我的主機IP地址配置為172.24.48.31，子網掩碼為：255.255.240.0，網關為：172.24.48.1。隨后進行連通性測試。
1.2 連通性測試
配置好主機的IP地址后，我對其進行連通性測試，打開Windows的命令提示符，輸入指令：ping www.baidu.com，用來測試主機與百度的連通性，結果如下圖。
根據圖片可知，主機與百度成功連通，連通性測試通過！！！
1.3 網絡地址規划表
| 源地址 |
目標地址 |
域名 |
| 172.24.48.31 |
183.232.231.174 |
www.baidu.com |
| 172.24.48.31 |
112.17.1.202 |
www.iqiyi.com |
| 10.137.0.2 |
172.24.48.31 |
無 |
二、 數據鏈路層抓包分析
2.1 MAC幀格式
MAC幀的幀頭包括三個字段。前兩個字段分別為6字節長的目的地址字段和源地址字段，目的地址字段包含目的MAC地址信息，源地址字段包含源MAC地址信息。第三個字段為2字節的類型字段，里面包含的信息用來標志上一層使用的是什么協議，以便接收端把收到的MAC幀的數據部分上交給上一層的這個協議。
MAC幀的數據部分只有一個字段，其長度在46到1500字節之間，包含的信息是網絡層傳下來的數據。MAC幀的幀尾也只有一個字段，為4字節長，包含的信息是幀校驗序列FCS（使用CRC校驗）。
2.2 MAC地址分析
MAC地址就是在媒體接入層上使用的地址，也叫物理地址、硬件地址或鏈路地址，由網絡設備制造商生產時寫在硬件內部。MAC地址與網絡無關，也即無論將帶有這個地址的硬件（如網卡、集線器、路由器等）接入到網絡的何處，都有相同的MAC地址，它由廠商寫在網卡的BIOS里。
我使用了wireshark抓包軟件，對MAC地址進行了抓包分析，抓包結果如下圖：
根據報文可以看到，源地址為Caswell_eb:09:4a，其MAC地址為：08:35:71:eb:09:4a；目的地址為Hewlettp_40:9b:e4，其MAC地址為：48:ba:4e:40:9b:e4
三、 網絡層抓包分析
3.1 IP報文分析
使用wireshark抓包軟件抓包，得到以下結果：
根據抓包結果，IP地址的報文含義為：
1. Version是版本，證明此IP地址為IPV4的地址；
2. Header Length是頭部長度，這里頭部長度為20字節；
3. Differentiated Services Field就是服務類型，3位優先權字段（現在已棄用），4位TOS字段，和一位保留字段，4位TOS分別表示：最小延時，最大吞吐量，最高可靠性，最小成本，四個相互沖突，只能選擇其一；
4. Total Length是總長度，此報文長度為60字節
5. Identification為位標識，唯一的標識主機發送的報文，如果IP數據報在數據鏈路層被分片了，那么每一個片里面的這個id都是相同的；
6. Flags為標識，第一位保留，第二位置為1表示禁止分片，這時候如果報文長度超過MTU，IP模塊就會丟棄報文，第三位表示“更多分片”，如果分片的話，最后一個分片置為1，其他是0，類似於一個結束標記。
7. TTL協議 檢驗和這幾個部分，上層協議為TCP，再下是頭部檢驗和。
8. 源地址和目的地址，此報文的源地址為：172.24.48.31，目的地址為：183.232.231.172
3.2 ARP協議
ARP協議是地址解析協議，是已知目標主機的IP地址，，解析對應的MAC地址。其工作機制為：
1. 首先在廣播域中發送一份稱作ARP請求的以太網數據幀，域內每一台主機都能收到。ARP請求數據真中包含目的主機的IP地址及請求者自身的MAC地址，請求目的IP的主機答復。
2. 目的IP主機收到ARP請求后，會將自身的IP地址和MAC打包成數據幀，答復請求。
使用wireshark進行對ARP的抓包分析，結果如下：
在第30幀中，我的主機發起了ARP請求，源地址為172.24.48.31，源MAC地址為：48:ba:4e:40:9b:e4，目的地址為172.24.48.1。對其發送ARP請求幀。
在第31幀中，目的地址172.24.48.31收到ARP請求數據幀后，做出應答，打包回復自身MAC地址。這里源地址為：172.24.48.1，MAC地址為：08:35:71:eb:09:4a，目的地址為：172.24.48.31，MAC地址為：48:ba:4e:40:9b:e4。
3.3 ICMP協議
ICMP的全稱是 Internet Control Message Protocol ，Internet控制消息協議。它是TCP/IP協議族的一個子協議，用於在IP主機、路由器之間傳遞控制消息。控制消息是指網絡通不通、主機是否可達、路由是否可用等網絡本身的消息。這些控制消息雖然並不傳輸用戶數據，但是對於用戶數據的傳遞起着重要的作用。
同時，ping協議是ICMP中的一個重要的協議，所以使用Ping協議來對ICMP協議分析。
選用了Ping百度的域名（www.baidu.com）來進行抓包，根據DNS解析可以得到百度的IP為183.232.231.172。根據ICMP協議，type=8為Ping請求，Code=0，Checksum=0x4bf8為校驗和，ICMP的報文數據為32bytes。
Type = 0則為應答報文，Code=0，Checksum=0x53f8為校驗和，ICMP的報文數據為32bytes。
四、 傳輸層抓包分析
4.1 TCP 3次握手
TCP是面向連接的傳輸層協議，所謂面向連接就是在真正的數據傳輸開始前要完成的連接建立的過程，否則不會進入真正的數據傳輸階段。
TCP 的連接建立過程稱為三次握手。
在此，我對百度進行了抓包，分析主機與百度建立連接的過程。根據DNS服務器的解析，百度（www.baidu.com）使用了代理服務器，其IP地址為183.232.231.172、183.232.231.174。
第一次握手：在第5幀中，可以看到我的主機172.24.48.31，向百度183.232.231.174發出了請求報文，查看報文，其首部的同部位SYN=1，並選擇序號seq=0。
第二次握手：在第7幀中，可以看到百度183.232.231.174，向主機172.24.48.31發出了確認報文。ACK=1，返回確認號ack=0+1=1。同時，百度向主機發起連接請求，SYN=1，其選擇的序號seq=0。
第三次握手：在第8幀中，主機收到了百度發出的連接請求報文段后，給百度給出確認報文，ACK=1，確認號ack=0+1=1。同時，主機的TCP通知應用層的進程，連接已經建立可以開始通信。
隨后，主機會與百度進行HTTP協議的通信。
4.2 TCP 4次揮手
TCP連接是全雙工的，因此每個斷開連接的話必須每個方向單獨進行關閉。一方結束數據傳輸就發送FIN來終止這個方向傳輸，對方收到FIN也要通知應用層這個方向的傳輸已終止，因此TCP斷開連接需要四個過程。
因為試了很多次，都不能抓包到釋放與百度的TCP連接的報文，只好選用其他網站的。
這次抓包是IP地址為10.137.0.2對我的主機172.24.48.31發起的終止連接請求，具體分析如下：
第一次揮手：在第22幀中，10.137.0.2使連接釋放報文段的FIN=1，ACK=1，seq=1向主機172.24.48.31發出連接釋放報文，等待主機確認。
第二次握手：在第25幀中，我的主機172.24.48.31收到10..137.0.2的連接釋放報文后，向其發送確認號ACK=1，ack=1+1=2，seq=1的確認報文，確認連接釋放，同時通知應用層的進程，連接已關閉。此時，TCP連接處於半關閉狀態。
第三次揮手：在第54幀中，我的主機沒有需要傳輸的數據了，因此我的主機172.24.48.31向10.137.0.2發送FIN=1，ACK=1，ack=1+1=2，seq=1的連接釋放報文。
第四次揮手：在第57幀中，10.137.0.2收到主機172.24.48.31發出的連接釋放報文段后，做出確認，使ACK=1，ack=1+1=2，seq=1+1=2，向主機發出確認報文，在此TCP 完成釋放。
4.3 UDP協議
UDP協議全稱用戶數據報協議，提供了不面向連接的通信，通信是不需要接力連接，且不對傳輸送數據包進行可靠的保證，可靠性由應用層來負責。
因為DNS服務器使用的就是UDP協議，所以抓包分析DNS解析就可以分析UDP協議。
可見，DNS使用的是UDP協議，其中
Source port為源端口，用於發送數據包的端口
Destination port為目的端口，數據包要送達的端口
Length為UDP長度，數據包的字節長度
Checksum為校驗和，用來確保UDP的首部和數據部分的完整性
五、 應用層抓包分析
5.1 www（HTTP協議）分析
在之前的TCP三次握手建立好連接后，主機就開始與百度通信，與其建立HTTP連接。
在第9幀中，主機172.24.48.31與183.232.231.174建立HTTP協議的連接，請求方法為GET，請求版本為HTTP/1.1，域名為www.baidu.com。
5.2 直播
直播抓包選用了愛奇藝的網站：www.iqiyi.com
根據DNS服務器的解析，www.iqiyi.com有兩個IP地址分別為：112.17.1.202和112.13.64.135
通過抓包可以知道，直播類網站也是先進行TCP 3次握手連接，連接后使用HTTP協議進行通信的。
六、 總結
經過了大概半個學期的IP通信的學習，我感覺自己對IP通信有了比較深入的理解。這次的網絡抓包作業對於我還是挺有挑戰的，網絡的抓包還是第一次嘗試。上課講了理論知識在這兒全都能用的上，但是要能熟練的使用還是有點困難的。這次的抓包作業，我覺得最大的問題就是抓包很難抓到想要的數據，有很多時候抓到的數據都是不完整的，所以我也是嘗試了很多次才抓到想要的數據的。這次的抓包作業讓我學會很多技能，使我更加深入的了解IP通信在各個層面的功能，同時也鞏固了我的基礎知識，收獲很大。