Wireshark抓包數據：理解與分析

wireshark是一個非常好用的抓包工具，本文根據平時抓包經驗，對之前wireshark抓包的一些常見知識點進行了整理。

有不當之處，歡迎指正

 

1.SYN，FIN會消耗一個序號，單獨的ACK不消耗序號

2.WIN表示可以接收數據的滑動窗口（接收緩沖區）是多少，如果A發到B的包的win為0，就是A告訴B說我現在滑動窗口為0了，飽了，你不要再發給我了，就說明A端環境有壓力

3.ACK可以理解為應答。A發給B的ack是告訴B，我已收到你發的數據包，收到ack號這里了，你下次要發seq為ack號的給我

 

4.連續傳輸的時候，且無亂序，無丟包的情況下：上一個包的seq + len  = 下一個包的 seq，如：

包55976：

包55977：

7801（55977的seq ） = 6501（55976的seq） + 1300（55976的len）

 

5.［TCP Previous segment not captured］

在TCP傳輸過程中，同一台主機發出的數據段應該是連續的，即后一個包的Seq號等於前一個包的Seq Len（三次握手和四次揮手是例外）。

如果Wireshark發現后一個包的Seq號大於前一個包的Seq Len，就知道中間缺失了一段數據。中間缺失的數據有的時候是由於亂序導致的，在后面的包中還可以找到

如：包55974

包55975：

5201（55975的seq ） ！= 1（55974的seq ） + 1300（55974的len ）

 

6.在TCP傳輸過程中（不包括三次握手和四次揮手），同一台主機發出的數據包應該是連續的，即后一個包的Seq號等於前一個包的Seq Len。
也可以說，后一個包的Seq會大於或等於前一個包的Seq。當Wireshark發現后一個包的Seq號小於前一個包的Seq Len時，就會認為是亂序了。跨度大的亂序卻可能觸發快速重傳

包55979：

包55980

seq(55979) > seq(55980)，55980應該是緊跟着55974的（1301 =1300 + 1），從到達的時間來看，是亂序了

 

7.關於SLE和SRE：

SACK在數據丟包需要重傳時起作用。

比如，服務器已發送的數據為1~34454個包，但是，客戶端只收到了“1~1301，5201~6501”這些序列的包，也就是說“1302~5200”這些包已經丟了。

這個時候，客戶端會向服務器請求發送ACK，說我收到了seq為1301的包，同時也亂序收到了"SLE為5201，SRE為6501"的包。

那么，服務器就知道，接着從seq=1302的包開始發送，發送到seq=5200的包的時候，就不用在發送seq=5201的包了，因為客戶端已經收到了。
如果ACK中不帶SLE和SRE會怎樣呢？那服務器就會重發從"1302"開始之后的所有的包，包括其實客戶端已經收到的"5201~6501"序號的包，那就浪費網絡帶寬了

 

8.[TCP Dup ACK]

當亂序或者丟包發生時，接收方會收到一些Seq號比期望值大的包。它每收到一個這種包就會Ack一次期望的Seq值，以此方式來提醒發送方，於是就產生了一些重復的Ack。

同時，這些重復的ACK中，也會更新SLE和SRE的值，因為盡管ACK的值不變，即期望的seq沒有收到，但可能又會新收到后面的亂序的包

 

9.關於Seq，Ack，Win，Len的理解：

1.指明本次數據發送的信息：本次發送的數據起始序號是Seq，發送的長度是Len

2.發送端告訴接收端：我期望的Ack是多少，即希望接收端下次發從seq為ack號的給我，同時我還可以接收Win大小的數據，即接收端可以發送（Ack，Ack + Win）區間內的數據給發送端

 

10.[TCP Window Update]

這種情況下，Seq，Ack，Len都沒有變，唯一變的是Win大小。說明這個ACK只是表明發送端接收數據的滑動窗口更新了

一般出現這種情況，就是由於發送端的應用程序將數據從接收數據緩沖區中取出來了，導致接收緩沖區大小更新

 

11.關於TCP重傳：

決定報文是否有必要重傳的主要機制是重傳計時器（retransmission timer），它的主要功能是維護重傳超時（RTO）值。當報文使用TCP傳輸時，重傳計時器啟動，收到ACK時計時器停止。報文發送至接收到ACK的時間稱為往返時間（RTT）。對若干次時間取平均值，該值用於確定最終RTO值。在最終RTO值確定之前，確定每一次報文傳輸是否有丟包發生使用重傳計時器，下圖說明了TCP重傳過程。

當報文發送之后，但接收方尚未發送TCP ACK報文，發送方假設源報文丟失並將其重傳。重傳之后，RTO值加倍；如果在2倍RTO值到達之前還是沒有收到ACK報文，就再次重傳。如果仍然沒有收到ACK，那么RTO值再次加倍。如此持續下去，每次重傳RTO都翻倍，直到收到ACK報文或發送方達到配置的最大重傳次數。

所以TCP RTO的值會越來越大

如圖所示：

1.37527的包，在75.55s發出，期望的ack=120656

2.知道42504的包，即103.85s的時候，才收到seq=120656的包，很顯然，這個ack是超時重傳的，因為中間過了28s的時間

3.在75.55-103.85期間，112.90.135.235應該進行過多次重傳，但是都丟失了。知道103.85這個時間點的重傳，才到達了客戶端

4.每次重傳后，RTO的時間會變大，所以如果重傳一直不成功，兩次重傳之間的間隔時間也會越來越大，從而導致等待數據到達時間也會越來越長