如何解析wireshark抓包

這期內容當中小編將會給大家帶來有關如何解析wireshark抓包，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

關于wireshark抓包的那點事兒

三次握手

172.18.254.177為客戶    111.13.2.158為服務端

1、主動打開。發送SYN，協商window size 、TCP MSS seq=0  len=0 MSS=1460 win=65535最大窗口大小

 客戶端為syn_sent

 服務端為syn_recv

2、接收到syn。回復syn ack  seq=0  ack=1=0+1  確認自己的最大win=14480 MSS=1460

  客戶端為established

  服務端為syn_recv

3、接到到syn 回復ack seq=1 ack=1=0+1  至此三次握手成功建立。

  客戶端為established

  服務端為established

四次斷開

1、主動關閉，發送fin。Seq=328

   服務端狀態為fin_wait1

客戶端狀態為closed_wait

2、客戶端發送確認ack  ack=329=328+1

服務端狀態為fin_wait2

3、客戶端發送fin seq=133

   客戶端狀態為last_ack

   服務端狀態為time_wait

4、服務端發送ack  ack=134=133+1

   客戶端狀態closed

    服務端狀態closed

數據包ACK=segment len+seq = 下一個要接收的數據包的seq

圖1

圖2

圖3

由圖1 數據包情況可以看出 359 seq=1441 segment len=1440 所以下一個回包的ack=1441+1440=2881 從圖2中可以確認ack確實為2881.

圖2 數據包情況可以看出 360  seq=349  segment len=0 所以下一個回包的ack=349+0=349，從圖3可以確認ack確實為349.

圖1 359 的ack=349 則圖2 350 的seq=349 ack=2881 推斷圖3 361的seq=2881 . 

一條完整會話（session）指的是，相同的傳輸協議中兩個不同IP之間的兩個不同端口的互相通信，如果IP或端口變化剛屬于不同的會話，其seq和ack也是相互獨立的，沒有任何關聯。

TCP segment of a reassembled PDU (TCP數據包重組的一部分)

分段的數據包的ACKnum相同，

當請求的數據包大于TCP MSS時會將數據分為多個數據包進行傳輸。

局域網內的TCP MSS大小為1460=1500-20（IP包頭）-20（TCP包頭）

server=124.192.132.36  client=192.168.10.111

(378、381、384、387) seq=349不變，ack一直增加。說明client端一直在接收server端的數據，且一直在給client應答。

server=124.192.132.36  client=192.168.10.111

（376、377、379） ack=349沒有變化。seq不斷增加，說明server端一直在向client發送數據包，不用給client應答，而是等待client端的應答。

由以上可以看出client不用對server端的每一個包都做一一應答，可以接收幾個包后統一做應答。

TCP window update （TCP 窗口更新）

TCP zero window

TCP window full

是TCP通信中的一個狀態，它可以發生的原因有很多，但最終歸結于發送者傳輸數據的速度比接收者讀取的數據還快，這使得接受端的在緩沖區必須釋放一部分空間來裝發送過來的數據，然后向發送者發送Windows Update，告訴給發送者應該以多大的速度發送數據，從而使得數據傳輸與接受恢復正常。

或者一個TCP Window變為0了, 或者接近0了, 這就會警告數據發送方沒有更多空間來接受更多數據了.文件傳輸會停止, 直到收到一個update說buffer已經清空了.

Tcp window full :服務端向客戶端發送的一種窗口警告。

Tcp zero window：客戶端向服務端發送的一種窗口警告。

Tcp keep-alive: 會話保持，一般由服務端發出。

以下是針對上圖的數據包進行分析

客戶端：192.168.10.111   服務端：42.250.12.36

131：服務端向客戶端發出tcp window full，表示無法再接受新的數據，

132：客戶端向服務端發送tcp zero window ，表示沒有window可以接收新數據

137：服務端向客戶端發送keep-live，保持會話，直至客戶端有足夠的window可以再次接收數據。

138：客戶端再次向服務端發送 tcp zere window ，提示服務端目前沒有足夠的window可以接收新數據。

139：客戶端向服務端發送 tcp window update，表示buffer已經清空。并提示服務端現在已經有足夠的window 大小為    17280。

140：由于收到了客戶端發送的window  buffer已經清空，所以繼續發送數據。

TCP DUP ACK  （重復的ACK）

表示數據段已丟失， 574是數據丟失的位置，#1 代表丟失一次。

一般情況下，當網絡延時增大導致網絡速度變慢，是產生重復ACK的一個主要原因。或者是服務端或者客戶端響應速度變慢或者沒沒有響應。

TCP out-of-order

由于收到的數據包亂序，有可能是網絡擁塞或者路由上存在負載分擔的情況，導致后發送的數據包先達到。

TCP Restransmission  重傳

170號數據包是為167號數據包做的重傳操作，所以seq  ack都是一樣的，seq=2070  ack=6264

TCP previous segment not captured  之前的分段未收到

說明亂序了，未收到之前的數據包，也要進行重傳，1932的ack=83066，也就是要求server端下次發送seq=83066的包，結果 1933發送的數據包seq=85946.說明server端收到過client端發送的數據包ack=85946，則判斷之前的一個數據包未收到。在1934 對1932數據包進行重傳操作。

上述就是小編為大家分享的如何解析wireshark抓包了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。