目錄服務器
1、 主機的IP地址配置與連通性測試網絡
1.1IP地址配置學習
1.2連通性測試測試
1.3網絡地址規劃表網站
2、 數據鏈路層抓包分析spa
2.1 MAC幀格式3d
2.2 MAC地址分析代理
3、 網絡層抓包分析htm
3.1 IP報文進程
3.2 ARP協議
3.3 ICMP協議
4、 傳輸層抓包分析
4.1 TCP協議3次握手
4.2 TCP協議4次揮手
4.3 UDP協議
5、 應用層抓包分析
5.1 www (HTTP協議)分析
5.2 直播
6、總結
1、 主機地址的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、 數據鏈路層抓包分析
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、 網絡層抓包分析
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、 傳輸層抓包分析
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、 應用層抓包分析
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協議進行通訊的。
6、 總結
通過了大概半個學期的IP通訊的學習,我感受本身對IP通訊有了比較深刻的理解。此次的網絡抓包做業對於我仍是挺有挑戰的,網絡的抓包仍是第一次嘗試。上課講了理論知識在這兒全都能用的上,可是要能熟練的使用仍是有點困難的。此次的抓包做業,我以爲最大的問題就是抓包很難抓到想要的數據,有不少時候抓到的數據都是不完整的,因此我也是嘗試了不少次才抓到想要的數據的。此次的抓包做業讓我學會不少技能,使我更加深刻的瞭解IP通訊在各個層面的功能,同時也鞏固了個人基礎知識,收穫很大。