1. Wireshark介紹
1.1 客戶端界面
打開Wireshark后，能夠看到三個區域。最上方是工具欄區域，可以開始捕獲、停止捕獲等操作。中間是Cpature Filter區域，能夠在開始捕獲前指定過濾規則。下方是可以捕獲的網絡設備，雙擊其中一個設備后就開始進行網絡流量的捕獲。
結果的展示主要分三個區域，最上方是請求和響應列表，每一條記錄表示一次請求或響應的交互。中間是對選中的交互解析后的結果。最下方是原始的數據格式。
在請求列表上方，我們可以指定 Display Filter，用於篩選已經捕獲到的數據。
1.2 Display Filter 的常用方法
待補充
1.3 界面上一些小TIPS
左邊的實線連起來的表示同一次會話發生的各個階段。
對勾表示選中項目對應的請求。
HTTP請求選中后，能夠看到對應的請求和響應。
Wireshark會幫我們將多次請求合並。
在選中的項目上右鍵選擇Follow->HTTP Stream可以將這次請求的所有相關的請求列出，幫助我們快速過濾。
2. 使用Wireshark分析TCP三次握手過程
2.1 三次握手原理
先來看一下基本的原理。
第一次握手：建立連接時，客戶端發送SYN到服務器，並進入SYN_SENT狀態。
第二次握手：服務器收到請求后，回送SYN+ACK信令到客戶端，此時服務器進入SYN_RECV狀態。
第三次握手：客戶端收到SYN+ACK包，向服務器發送確認ACK包，客戶端進入ESTABLISHED狀態，服務器收到請求后也進入ESTABLISHED狀態，完成三次握手，此時TCP連接成功，客戶端與服務器開始傳送數據。
2.2 第一次握手
第一次握手：建立連接時，客戶端發送SYN到服務器，並進入SYN_SENT狀態。
SYN ：標志位，表示請求建立連接。
Seq = 0 ：初始建立連接值為0，數據包的相對序列號從0開始，表示當前還沒有發送數據。
Ack =0：初始建立連接值為0，已經收到包的數量，表示當前沒有接收到數據。
WIN = 8192 來自Window size: 8192。
MSS = 1460 來自 Maximum segment size: 1460 byte ，最長報文段，TCP包所能攜帶的最大數據量，不包含TCP頭和Option。一般為MTU值減去IPv4頭部(至少20字節)和TCP頭部(至少20字節)得到。
WS = 4 來自windows scale : 2 (multiply by 4)： 窗口擴張，放在TCP頭之外的Option，向對方聲明一個shift count，作為2的指數，再乘以TCP定義的接收窗口，得到真正的TCP窗口。
2.3 第二次握手
第二次握手：服務器收到請求后，回送SYN+ACK信令到客戶端，此時服務器進入SYN_RECV狀態。
Seq = 0 ：初始建立值為0，表示當前還沒有發送數據
Ack = 1 : 表示當前端成功接收的數據位數，雖然客戶端沒有發送任何有效數據，確認號還是被加1，因為包含SYN或FIN標志位。盡管客戶端沒有發送任何有效數據，確認號還是被加1，這是因為接收的包中包含SYN或FIN標志位（並不會對有效數據的計數產生影響，因為含有SYN或FIN標志位的包並不攜帶有效數據。
2.4 第三次握手
第三次握手：客戶端收到SYN+ACK包，向服務器發送確認ACK包，客戶端進入ESTABLISHED狀態，服務器收到請求后也進入ESTABLISHED狀態，完成三次握手，此時TCP連接成功，客戶端與服務器開始傳送數據。
ACK ：標志位，表示已經收到記錄
Seq = 1 ：表示當前已經發送1個數據
Ack = 1 : 表示當前端成功接收的數據位數，雖然客戶端沒有發送任何有效數據，確認號還是被加1，因為包含SYN或FIN標志位。盡管客戶端沒有發送任何有效數據，確認號還是被加1，這是因為接收的包中包含SYN或FIN標志位（並不會對有效數據的計數產生影響，因為含有SYN或FIN標志位的包並不攜帶有效數據)
2.5 為什么是三次握手
這個問題的本質是, 信道不可靠, 但是通信雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在消息中包含什么信息, 三次通信是理論上的最小值. 所以三次握手不是TCP本身的要求, 而是為了滿足”在不可靠信道上可靠地傳輸信息”這一需求所導致的.
也是為了最小的代價驗證會話雙方的收發功能正常:
- 第一次握手成功：說明客戶端的數據可以被服務端收到，說明客戶端的發功能可用，說明服務端的收功能可用。但客戶端自己不知道數據是否被接收。
- 第二次握手成功：說明服務端的數據可以被客戶端收到，說明服務端的發功能可用，說明客戶端的收功能可用。同時客戶端知道自己的數據已經正確到達服務端，自己的發功能正常。但是服務端自己不知道數據是否被接收。
- 第三次握手成功：說明服務端知道自己的數據已經正確到達客戶端端，自己的發功能正常。至此服務成功建立。
3. 請求數據的過程
客戶端和服務端建立連接后，開始傳輸數據。下圖中首先是客戶端發起一個GET請求，服務端收到請求后首先返回確認信息。待服務端處理完成后，將數據返回給客戶端，客戶端對收到的數據進行確認，完成一次數據交互的過程。
交互過程中，SEQ表示發送的數據，LEN表示發送的數據長度，下一次的SEQ就等於當前SEQ加上LEN。ACK表示接收的數據位。客戶端和服務端分別計算自己的增長值。對應上圖最后一次服務端返回數據時SEQ是2737，LEN是450。客戶端對接收數據做了兩次返回確認，第一次ACK是2737，表示還沒有完成數據接收。第二次ACK是3187，等於服務端SEQ＋LEN（2737+450）表示已經完成了全部數據的接收。
4. 分析四次揮手過程
4.1 理論基礎
- 第一次揮手：客戶端 發送一個[FIN+ACK]，表示自己沒有數據要發送了，想斷開連接，並進入FIN_WAIT_1狀態（不能再發送數據到服務端，但能夠發送控制信息ACK到服務端）。
- 第二次揮手：服務端收到FIN后，知道不會再有數據從客戶端傳來，發送ACK進行確認，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），服務端進入CLOSE_WAIT狀態。
- 第三次揮手：服務端發送FIN給對方，表示自己沒有數據要發送了，服務端進入LAST_ACK狀態，然后直接斷開TCP會話的連接，釋放相應的資源。
- 第四次揮手：客戶端收到了服務端對FIN的ACK后，進入FIN_WAIT2狀態（等待服務端完成資源釋放的一系列工作：然后釋放你為創建這個連接所分配的資源，並通知我你關閉了）; 客戶端收到了服務端的FIN信令后，進入TIMED_WAIT狀態，並發送ACK確認消息。客戶端在TIMED_WAIT狀態下，等待2MSL一段時間，沒有數據到來的，就認為對面已經收到了自己發送的ACK並正確關閉了進入CLOSE狀態，自己也斷開了到服務端的TCP連接，釋放所有資源。當服務端收到客戶端的ACK回應后，會進入CLOSE狀態，並關閉本端的會話接口，釋放相應資源。TIME_WAIT狀態持續2MSL(MSL是數據分節在網絡中存活的最長時間）。
網絡上比較主流的文章都說關閉TCP會話是四次揮手，但是實際上為了提高效率通常合並第二、三次的揮手，即三次揮手。
4.2 實例分析
關閉連接需要四次握手。
客戶端向服務端發送FIN為1的報文，服務端返回確認，關閉客戶端與服務端通信的部分。
服務端向客戶端發送FIN為1的報文，客戶端返回確認，關閉服務端與客戶端通信的部分。
本文分析的過程是基於最簡單的網絡交互模式，實際上目前HTTPS已經廣泛普及，而且網絡交互中會發生各種各樣的意外情況，對於這些情況的分析就需要更多的網絡知識。相信本文能夠作為一個很好的入門，幫助大家了解網絡協議。
轉自：https://www.cnblogs.com/cocowool/p/wireshark_tcp_http.html