1. 程式人生 > >wireshark抓包分析——TCP/IP協議

wireshark抓包分析——TCP/IP協議

本文來自網易雲社群

當我們需要跟蹤網路有關的資訊時,經常會說“抓包”。這裡抓包究竟是什麼?抓到的包又能分析出什麼?在本文中以TCP/IP協議為例,簡單介紹TCP/IP協議以及如何通過wireshark抓包分析。

Wireshark 是最著名的網路通訊抓包分析工具。功能十分強大,可以擷取各種網路封包,顯示網路封包的詳細資訊。

Wireshark下載安裝,略。注意,若在Windows系統安裝Wireshark,安裝成功後可能會出現Wireshark的兩個圖示,一個是Wireshark(中文版);另外一個是Wireshark Legacy (英文版)。下面的內容會以Wireshark Legacy為例介紹。

開啟Wireshark,開始介面如下:

201808290919453f89cc82-9690-4099-addc-b44d84acb713.png  

Wireshark捕獲的是網絡卡的網路包,當機器上有多塊網絡卡的時候,需要先選擇網絡卡。開始介面中的Interface List,即網絡卡列表,選擇我們需要的監控的網絡卡。點選Capture Options,選擇正確的網絡卡,然後點選"Start"按鈕, 開始抓包。

2018082909200706917650-2573-4c03-bd01-0462e1c625b4.png  

我們開啟瀏覽器輸入任意http網址,連線再關閉,比如:http://blog.csdn.net。然後,我們回到Wireshark介面,點選左上角的停止按鍵。檢視此時Wireshark的抓包資訊。在看抓包資訊之前,先簡單介紹下Wireshark介面的含義。其中,封包列表的面板中顯示編號、時間戳、源地址、目標地址、協議、長度,以及封包資訊。

201808290920260f1a5e4b-8e4f-451d-8994-13764e426f10.png  

封包詳細資訊是用來檢視協議中的每一個欄位。各行資訊分別對應TCP/IP協議的不同層級。以下圖為例,分別表示:傳輸層、網路層、資料鏈路層、物理層,一共四層。如果有應用層資料會顯示第五層,即一共會出現五層。

201808290920377bad3677-03bf-4151-97e7-5d6e09a89bc2.png  

每一層都有一個欄位指向上一層,表明上一層是什麼協議。這大概是因為發包的時候會在資料上依次加上應用層、傳輸層、網路層、鏈路層的頭部,但是對方收到資料包後是從最底層(鏈路層)開始層層剝去頭部解包的,所以在每層上有一個欄位指向上層,表明上層的協議,對方就知道下一步該怎麼解包了。以TCP/IP協議為例,下圖中分別是:IPv4、TCP。由於建立TCP連線用不到應用層協議,所以傳輸層就沒有相應的指明上層(應用層)的欄位了。

2018082909205351047869-4d3c-45f7-b00b-00a7bce465f3.png

在瞭解Wireshark介面後,我們來分析TCP協議。這裡有很多資料包,我們需要先過濾,新增對應的過濾條件。比如,我添加了目標的ip地址和埠號:tcp and ip.addr==47.95.47.253 and tcp.port==53992,此時獲取到的封包列表如下。

2018082909210415dcc5c2-f999-4b48-a6eb-c02f09655d49.png  

在此之前,看下TCP/IP報文的格式。

20180829092121169ae1ab-761a-4861-8a9e-832f840ae973.png  

根據上述報文格式我們可以將wireshark捕獲到的TCP包中的每個欄位與之對應起來,更直觀地感受一下TCP通訊過程。先看三次握手,下圖中的3條資料包就是一次TCP建立連線的過程。

20180829092130d0e2bd9e-7f6c-4a4a-8fad-d09fe445f6fb.png  

第一次握手,客戶端傳送一個TCP,標誌位為SYN=1,序號seq為Sequence number=0, 53992 -> 80,代表客戶端請求建立連線;

20180829092142452391a5-c140-4467-b2ce-ff0b84e74d44.png  

第二次握手,伺服器向客戶端返回一個數據包,SYN=1,ACK=1,80 -> 53992,將確認序號(Acknowledgement Number)設定為客戶的序號seq(Sequence number)加1,即0+1=1;

201808290921493240a120-2f98-4ac0-864e-c5db11c990aa.png  

第三次握手,客戶端收到伺服器發來的包後檢查確認序號(Acknowledgement Number)是否正確,即第一次傳送的序號seq加1(X+1= 0+1=1)。以及標誌位ACK是否為1。若正確,客戶端會再向伺服器端傳送一個數據包,SYN=0,ACK=1,確認序號(Acknowledgement Number)=Y+1=0+1=1,並且把伺服器發來ACK的序號seq(Sequence number)加1傳送給對方,傳送序號seq為X+1= 0+1=1。客戶端收到後確認序號值與ACK=1,53992 -> 80,至此,一次TCP連線就此建立,可以傳送資料了。

20180829092202fba5f063-758d-4963-b95e-dd50d5f821f5.png  

還可以通過直接看標誌位檢視三次握手的資料包,如下圖所示,第一個資料包標誌位【SYN】,這是第一次握手;第二個資料包標誌位【SYN,ACK】,這是第二次握手;第三個資料包標誌位【ACK】,這是第三次握手。

20180829092217b3c30db8-50f8-408c-8e5f-fb7f36fcd22c.png

在三次握手的三個資料包之後,第四個包才是HTTP的, 這說明HTTP的確是使用TCP建立連線的。

2018082909222318fe4621-6c39-4e2f-b06a-2bb77e0a609d.png  

再往下看其他資料包,會發現存在大量的TCP segment of a reassembled PDU,字面意思是要重組的協議資料單元(PDU:Protocol Data Unit)的TCP段,這是TCP層收到上層大塊報文後分解成段後發出去。

201808290922459784ed3b-9f61-4188-b155-a0ab2d25d5f1.png  

      每個資料包的Protocol Length都是1502 Byte,這是因為乙太網幀的封包格式為:Frame = Ethernet Header + IP Header + TCP Header + TCP Segment Data。即:

1、Ethernet Header = 14 Byte = Dst Physical Address(6 Byte)+ Src Physical Address(6 Byte)+ Type(2 Byte),乙太網幀頭以下稱之為資料幀。

2、IP Header = 20 Byte(without options field),資料在IP層稱為Datagram,分片稱為Fragment。

3、TCP Header = 20 Byte(without options field),資料在TCP層稱為Stream,分段稱為Segment(UDP中稱為Message)。

4、TCP Segment Data = 1448 Byte(從下圖可見)。

所以,每個資料包的Protocol Length = 14 Byte + 20 Byte + 20 Byte + 1448 Byte = 1502 Byte。

201808290923017e9191f2-49c7-4fe0-8dc9-2f702434ace9.png  

      我們再來看四次揮手。TCP斷開連線時,會有四次揮手過程,標誌位是FIN,我們在封包列表中找到對應位置,理論上應該找到4個數據包,但我試了好幾次,實際只抓到3個數據包。查了相關資料,說是因為伺服器端在給客戶端傳回的過程中,將兩個連續傳送的包進行了合併。因此下面會按照合併後的三次揮手解釋,若有錯誤之處請指出。

20180829092314c82f2801-d5ad-4ae3-9620-e7c470e08cb3.png  

第一次揮手:客戶端給伺服器傳送TCP包,用來關閉客戶端到伺服器的資料傳送。將標誌位FIN和ACK置為1,序號seq=X=2242,確認序號ack=Z=17602,53992 -> 80;

201808290923262ac1ab41-dbb6-4f55-bb7e-671194b52cb7.png  

第二次揮手:伺服器收到FIN後,伺服器關閉與客戶端的連線,發回一個FIN和ACK(標誌位FIN=1,ACK=1),確認序號ack為收到的序號加1,即X=X+1=2243。序號seq為收到的確認序號=Z=17602,80 -> 53992;

201808290923395482c33b-c1bc-4442-81be-5c5826f572c5.png  

第三次揮手:客戶端收到伺服器傳送的FIN之後,發回ACK確認(標誌位ACK=1),確認序號為收到的序號加1,即Y+1=17603。序號為收到的確認序號X=2243,53992 -> 80。

201808290923559759f633-e235-47b1-990f-3d42d41a2246.png  

      至此,整個TCP通訊過程已經介紹完畢。

      附:TCP通訊過程:

20180829092404d235a095-0627-42c0-8812-62a4d3e4a8c3.jpg

本文來自網易雲社群,經作者李莉授權釋出。