使用wireshark抓取TCP包傳輸分析

• 2019 年 12 月 12 日
• 筆記

前言

介紹

本篇文章是使用wireshrak對某個https請求的tcp包進行分析。

目的

通過抓包實際分析了解tcp包。

準備工作

在我自己機子上安裝的是wireshark2.2.6版本，隨機查找了某個TCP連接，並跟蹤流。

傳輸

創建連接

• No58: 10.60.45.187:17932(後面簡稱客戶端)向131.25.61.68:443(後面簡稱服務端)發送了SYN請求連接，此時客戶端發送的seq=0，ack=0。
• No79：服務端向客戶端發送了SYN+ACK確認連接，此時服務端發送的seq=0,ack=1。
• No81：客戶端接收到服務端的SYN+ACK向服務端響應ACK包，此時客戶端發送的seq=1，ack=1。由於抓到的tcp是使用了https協議，建里連接需要先進行認證,步驟如下圖所示。
  

握手

• No84: 客戶端向服務端發起握手請求，具體包格式及內容這裡不做詳細分析。
  

  這裡SSL總長度為239位元組(其中ContentType為1位元組，Version為2位元組,Length為2位元組，再加上後續握手協議長度234。)。

• No103: 服務端接收到客戶端握手請求後響應ACK包，此時seq=1,ack=1。這個發送的是一個特殊的TCP Window Update,服務端告知客戶端服務端有足夠的快取大小(8192)，可以正常接收客戶端數據。若出現了TCP Window Full包表示快取區已滿，客戶端會停止發送，直到接收到了TCP Window Update包。(Window值表示滑動窗口，允許接收到多個包同時響應一個ACK包)
• No104: 伺服器向客戶端發送握手，由於服務端需要返回證書、演算法等資訊,因此包可能會大於1460位元組，會發生拆包現象(No136可看到該包總大小為5984KB,拆分了5個包發送)。當前服務端發送的seq=1,ack=240(當前包大小為1460，No84說明客戶端包大小為239。)
  
• No105: 伺服器向客戶端發送握手數據，這個包標記的是TCP Previous segment not captured，說明發送包可能出現了亂序或丟包現象，這個包的seq=2921，而No104的下一個包seq應該為1461，No104和No105中間seq=1461的包可能丟包或亂序傳輸。
  
• No106: 伺服器向客戶端發送握手數據，這個包的seq=4381，因為No105的下一個包的seq和這個包一樣，所以這兩個包是按順序傳輸的。當前包的下一個包seq=5841。
  
• No108: 這個包是客戶端向服務端發送的一個ACK 其中ack=1461，表示客戶端確認收到了No104這個包。
  
• No118: 伺服器向客戶端發送ACK包，這個包標記的是TCP Out-Of-Order，由於No105包顯示出現了丟包現象，因此tcp將No104以前的包全部重傳，這個包實際就是No104。
  
• No119: 客戶端向服務端發送ACK包，這個包標記的是TCP Dup ACK 108#1,表示重傳ACK包，這個包是由於No118包引起的(#N表示重傳N次，這裡重傳了1次)，因為No118包服務端向客戶端發送了一個亂序的包，而客戶端在No108包已經確認接收到No104這個包，seq應該為1461，所以，客戶端再一次重傳108包告知服務端客戶端已經接收到No104包，這個包實際服務端已經接收到了因此會被丟棄。
• No123和No124: 伺服器向客戶端發送握手數據，包標記的是TCP Retransmission,兩個包的seq分別為1461和2921，由於服務端認為已經發了這兩個包(實際seq=1461的包沒發，由No105可看出，seq=2921的包發了，但是客戶端沒有響應響應的ACK包)，然後長時間收不到客戶端的ACK包，因此服務端會重發這兩個包。
  
• No127: 客戶端向服務端發送ACK包。seq=240，ack=5841，表示已經接收到服務端seq=5841以前的所有包。
• No132: 伺服器向客戶端發送握手數據，包標記的是TCP Spurious Retransmission，表示這個包已經發送過。該報的seq=1461,即No123重傳的包，雖然客戶端向服務端發送了ACK包收到了seq=5841以前的包，但是服務端可能沒有收到這個ACK包。
  
• No133: 客戶端向服務端發送ACK包。seq=240，ack=5841。包標記的是TCP Dup ACK 127#1。由於客戶端在No127已經返回了ack=5841，但是服務端在No132還是重傳了之前已經傳過的包，所以客戶端認為No127包可能服務端沒有收到，所有這裡重傳了No127這個ACK包，這個包服務端已經接收到了，因此會被丟棄。
• No136: 服務端向客戶端發送的最後一個握手包。seq=5841。下個包seq=5985，在這包匯總了5個分段包內容和資訊。
  
  
• No140:客戶端向服務端發送ACK包。seq=240，ack=5985。
  

生成密鑰

• No141: 客戶端接收到服務端的握手請求後，生成密鑰對發送給服務端。由於No103開始的包都是服務端向客戶端發送數據，因此客戶端的seq一直是240。
  
• No147: 服務端向客戶端重發No136包。因為No140這個包客戶已經確認收到seq=5985以前的包了，因此服務端發的這個包發生了虛假重傳。
• No148: 客戶端向服務端發送ACK包。這個包標記為TCP Dup ACK 140#1是由於No147這個包服務端發生虛假重傳，因此客戶端重新發送No140包。
• No152: 服務端向客戶端發送，包標記為Change Cipher Spec, Encrypted Handshake Message,這是對握手資訊進行加密。
• No153: 客戶端向服務端發送ACK包，接收到了No152包。

發送數據

• No154-No159: 客戶端向服務端發送數據。
• No166和No167: 服務端向客戶端發送了2個ACK包。
• No170: 服務端向客戶端發送數據。
• No171: 客戶端發送給服務端ACK包，確認收到No170這個包。
• No178: 服務端向客戶端發送數據，這個包是No170分段後剩餘的數據。
• No179: 客戶端發送給服務端ACK包，seq=8331，ack=8770，確認收到No178這個包。
  

  No152到No179都是正常傳輸的包，這裡不做詳細分析了。

斷開連接

• No180: 客戶端接收完服務端數據後就斷開連接了，所以發送了一個FIN包,同時客戶端進入到FIN_WAIT_1狀態。

理論上服務端發送完就主動關閉http連接， 但是抓包看確是客戶端先發送的FIN+ACK包，因此說明服務端發送的FIN+ACK的包可能丟包，客戶端沒收到或收到慢了。

• No187: 服務端發送客戶端FIN+PSH+ACK，seq=7552,ack=8331。這包不但傳了FIN關閉連接，又傳了PSH。說明No178包服務端發出來，客戶端返回的ACK包(No179以及No180)服務端沒收到（這中間可能網路處理問題）。
• No188: 由於No187包標記為TCP Out-Of-Order,因此客戶端認為服務端的包亂序了，因此，因此客戶端重傳No179。

• No189: 服務端接收到客戶端的FIN包,也接受到No188包，返回客戶端一個ACK包，seq也更新成最新的8770,客戶端進入FIN_WAIT_2狀態。

• No198: 服務端發送給客戶端RST重置連接，可能是由於No179到No187之間網路出現了問題，導致連接異常，因此服務端發送了一個RST重置連接。

結論

上面抓的包經分析可能出現多次網路異常或網路波動，出現了亂序，重傳，虛假重傳及連接重置等TCP包。

若分析有誤，希望加以指正。

參考文獻

1. 《TCP-IP詳解卷1：協議》18~20章
2. 常見的TCP資訊
3. https建立連接
4. https建立連接的過程

本文地址：https://www.cnblogs.com/Jack-Blog/p/8486792.html

作者：傑哥很忙

本文使用「CC BY 4.0」創作共享協議。歡迎轉載，請在明顯位置給出出處及鏈接。