簡介
Wireshark（前稱Ethereal）是一個網路封包分析軟體，可分析網路狀態，丟包率等。
由於公司做的即時通訊業務，其中IM模組採用TCP傳送資料和控制信令（心跳包）底層採用protobuf傳輸資料，音視訊採用TRP協議，然後給大客戶集團提供私有化部署，由於客戶網路環境複雜，所以需具備一定的抓包分析能力。
下面介紹常見的TCP層的常用FLAGS。
| 標誌位 | 描述 |
|---|---|
| SYN | 建立聯機 |
| ACK | 確認 |
| PSH | 有 DATA資料傳輸 |
| FIN | 關閉連線 |
| RST | 連線重置 |
一般地，只是單個的一個SYN，它表示的只是建立連線。當出現SYN和ACK可能同時為1，我們認為客戶端與伺服器建立了一個連線。而當出現FIN包或RST包時，我們便認為客戶端與伺服器端斷開了連線；而RST一般是在FIN之後才會出現為1的情況，表示的是連線重置。
Wireshark 抓包步驟
- 首先根據域名獲取對應的ip,終端輸入
ping 域名
telnet ip 埠
- 開啟Wireshark，首頁選擇要抓取的通道（Wi-Fi,網路卡等），然後設定過濾規則，點選右上角箭頭配置過濾規則，或者點選某一條右鍵選中
Apply as Filter，ip.src==103.219.186.235 or ip.dst==103.219.186.235
TCP三次握手
第一次握手：主機A傳送位碼為syn＝1，隨機產生seq number=1234567的資料包到伺服器，主機B由SYN=1知道，A要求建立聯機；
第二次握手：主機B收到請求後要確認聯機資訊，向A傳送ack number=(主機A的seq+1)，syn=1，ack=1，隨機產生seq=7654321的包；
第三次握手：主機A收到後檢查ack number是否正確，即第一次傳送的seq number+1，以及位碼ack是否為1，若正確，主機A會再傳送ack number=(主機B的seq+1)，ack=1，主機B收到後確認seq值與ack=1則連線建立成功。
複製程式碼
1. 客戶端傳送 SYN 報文 到伺服器
2. 伺服器接收到後 回覆 SYN + ACK 報文
3.客戶端接收到服務端的 SYN+ACK 報文後，回覆 ACK報文
TCP 四次揮手，簡略分析
（1）客戶端A傳送一個FIN，用來關閉客戶A到伺服器B的資料傳送。
（2）伺服器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將佔用一個序號。
（3）伺服器B關閉與客戶端A的連線，傳送一個FIN給客戶端A。
（4）客戶端A發回ACK報文確認，並將確認序號設定為收到序號加1。
複製程式碼抓包異常資料解讀
1.［TCP Previous segment not captured］丟包
在TCP傳輸過程中，同一臺主機發出的資料段應該是連續的，即後一個包的Seq號等於前一個包的Seq + Len（三次握手和四次揮手是例 外）當後Seq>前Seq +Len，就知道中間缺失了一段資料。
2.[TCP Dup ACK x#y]
當亂序或者丟包發生時，接收方會收到一些Seq號比期望值大的包。此時就會Ack就說我想獲取seq=28852的資料包而你給了我其他包。
3、[TCP Spurious Retransmission] 丟包重傳
4、[TCP Fast Retransmission] 快速重傳
當傳送方收到3個或以上[TCP Dup ACK]，就意識到之前發的包可能丟了，於是快速重傳它（這是RFC的規定）。
5、[TCP Retransmission] 超時重傳
如果一個包真的丟了，又沒有後續包可以在接收方觸發[Dup Ack]，就不會快速重傳，只能超時重傳。
6、幾種TCP連線中出現RST的情況
1.埠未開啟
伺服器程式埠未開啟而客戶端來連線。這種情況是最為常見和好理解的一種了。去telnet一個未開啟的TCP的埠可能會出現這種錯誤。
2. 請求超時
檢視2次包的時間間隔
3. 服務端關閉的socket
4. 防護牆拒絕了請求
5. 移動鏈路
行動網路下，國內是有5分鐘後就回收信令，也就是IM產品，如果心跳>5分鐘後伺服器再給客戶端發訊息，就會收到rst。也要查行動網路下IM 保持<5min 心跳。
6. 負載等裝置
負載裝置需要維護連線轉發策略，長時間無流量，連線也會被清除，而且很多都不告訴兩層機器，新的包過來時才通告rst。
Apple push 服務也有這個問題，而且是不可預期的偶發性連線被rst；rst 前第一個訊息write 是成功的，而第二條寫才會告訴你連線被重置
7. 超過超時重傳次數、網路暫時不可達
如有疏漏，請指出不勝感激，部分圖片來自網路，如有侵權請聯絡刪除。
參考：
www.wireshark.org/
blog.csdn.net/yuanbinquan…
blog.csdn.net/yuanbinquan…