Mac端Wireshark抓包工具使用擴展

昨天記錄了Wireshark的基本安裝配置。今天開始真正的使用起來。

前言

關於網絡協議和網絡分層，本篇文章不作介紹，僅記錄使用,可能中間有理解錯誤的地方，請指正。

開始

通常常規的網絡請求對包的大小是有限制的，即MTU"最大傳輸單元"，大多數網絡的MTU是1500字節，也有一些特例的巨幀達到9000字節。假如如今有一個8000字節的數據包進入網絡，若是是巨幀網絡，數據能夠傳輸成功，可是若是進入到1500字節的網絡中，就會被丟棄或者切分。重傳仍是會被丟棄，沒法傳輸成功。

TCP爲了解決這個問題，不是一次把8000字節的數據傳給網絡互聯層，而是根據雙方的MTU決定每次傳多少。以下圖所示，在TCP三次握手的時候，雙方會吧本身的MSS(Maximum Segment Size)告訴對方，MSS加上TCP頭和IP頭的長度，就獲得MTU。

在NO.11的包裏，客戶端聲明本身的MSS是1460，則它的MTU就是1460 + 20（TCP頭）+20（IP頭） = 1500字節
在NO.12的包裏，服務器聲明本身的MSS是1452,意味着MTU是1452 + 20 + 20 = 1492。

TCP/IP的頭信息請自行查看網絡協議書籍文章。

TCP頭結構以下：

IP頭結構以下：

TCP分包

前面介紹了在三次握手時，雙方會把MTU告訴對方，下面看下實際的數據傳輸。

在第一行的包中數據len=1452（紅色劃線部分），而前面的紅色框中顯示的長度爲1492，和前面說的結果一致。
下面能夠看到更多的信息，黃色框圈出來的是當前的序列號爲1，下一段的序列號爲1453,恰好是加上1452的長度。綠色框能夠看到本次傳輸的長度。在上方的列表紅框的右側也能夠看到長度和Seq信息。
還能夠看到發起接收的端口信息。

通過測試，能夠看到數據包最終的大小是按照服務端的MTU來分割的。也就是發包的大小是由MTU較小的一方決定的，那怕客戶端的MTU是9000，也只能用1492的大小去發包。

更多信息

上圖是我從服務器獲取圖片的一個請求，能夠看到不少信息。下面簡單解析下。

感嘆下：以前看網絡協議感受很懵逼，枯燥。對着wireshark明朗多了。

NO.12293 - NO.12295行是HTTP的鏈接過程，能夠看到客服端的MSS是1460，服務端的MSS是1452，這前面都講過了。
NO.12296指明瞭此次請求是GET。平時用AFN這麼久，POST、GET你們也都耳熟能詳。下面就繼續看下GET背後的邏輯是什麼。
NO.12297:服務端發出的確認鏈接信息（有疑問，這一個包我也不太清除。）len=0,seq=1,因此下一個包的Seq = 1 + 0 = 1。就是NO.12300的Seq。

NO.從12297直接到12330，應該是中間還有其餘的包請求，我爲了方便看，對數據請求作了篩選，只顯示此次圖片請求相關的。

從NO.12300到NO.12303是服務器在向客服端發送數據，能夠看到Seq和len的變化。NO.12303有點特殊，與另外幾個相比，多了個PSH字段。這是TCP的狀態標識)。

TCP層有個FLAGS字段，有如下標識：SYN,FIN,ACK,PSH,RST。
SYN:創建鏈接，由於鏈接是雙向的，因此創建鏈接時，雙方都要發一個SYN.
FIN:關閉鏈接，同SYN，由於雙向，因此關閉，雙方都要發一個FIN.
ACK:響應，
PSH:data數據傳輸，
RST:鏈接重置。用於重置一個混亂的鏈接，或者拒絕無效請求.平時抓包要特別注意這個字段。
具體含義和組合意義自行搜索，或者點擊上面的「TCP的狀態標識」查看

NO.12304和NO.12305是客服端的呼應，看NO.12305行：

Seq = 243  ACK = 5788 Win = 256320 Len =0

ACK值

ACK = 5788,5788 值是從NO.12303裏面獲得的，

NO.12303:
Seq = 4357 Len = 1431.
4357 + 1431 = 5788.

NO.12305行的ACK = 5788意思告訴服務器，已經收到了5788之前的數據。理論上，接收方回覆的ACK號剛好等於發送方的下一個Seq號，看NO.12307行。恰好一致。

仔細看列表會發現，服務端發出了4個數據包，可是客服端只發出了兩個應答。這是應爲ACK = 5788表明把以前的包都確認了，TCP的確認是能夠累積的。

Seq值：

看上面的截圖，會發現Seq的值不統一，由於TCP是雙向的，在一個鏈接中，雙方均可以是發送方，因此各自維護了一個Seq.截圖上Seq一直變大的是服務端，由於在傳輸圖片數據。沒變化的是客服端，只是作了個應答，每次應答的Len=0,因此就沒有變化，一直是243.並且這個243也不是憑空出現的。看NO.122295和NO.12296,能夠計算出來。

到如今爲止，咱們已經能夠很好的檢查網絡數據的亂序問題了，只要根據Seq號就能夠比對數據是否有丟失和亂序。

One more thing

哈哈，想到了每次WWDC的One more thing，借來用下。

從新看上面的請求列表。三次握手創建的時候，Seq= 0,而事實上，握手時Seq並非從0開始。之因此在 Wireshark 上看到Seq = 0,是 Wireshark 默認開啓了 Relative sequence numbers，若是想關閉，在Wireshark ->Preferences -> protocols -> TCP中設置。