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時，就會認為是亂序了?？缍却蟮膩y序卻可能觸發快速重傳 包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的時間會變大，所以如果重傳一直不成功，兩次重傳之間的間隔時間也會越來越大，從而導致等待數據到達時間也會越來越長

參考文章：
1.Wireshark抓包常見問題解析：http://www.xianren.org/net/wireshark-q.html 2.wireshark抓包常見提示含義解析 ：http://blog.csdn.net/u012398362/article/details/52276067 3.Wireshark抓包工具--TCP數據包seq ack等解讀 ：http://blog.csdn.net/wang7dao/article/details/16805337 4.一站式學習Wireshark（四）：網絡性能排查之TCP重傳與重復ACK：http://blog.jobbole.com/71427/ 5.wireshark中帶有SLE和SRE的SACK包詳解 ：http://blog.csdn.net/season_hangzhou/article/details/48318599

總結

以上是生活随笔為你收集整理的wireshark抓包数据：理解与分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。