使用WireShark抓包分析TCP協議

浮空花園發表於2020-12-05

一、實驗目的：

以“金庸夢“遊戲的客戶端連線伺服器（10.1.230.41）、斷開伺服器為例，用wireshark抓包分析TCP協議的三次握手連線、四次握手斷開，與計算機網路原理進行驗證。
遊戲客戶端詳見C#實現網遊客戶端與伺服器的連線

二、TCP協議解析

1.連線建立
三次握手連線
在這裡插入圖片描述
三次握手過程分析：

（1）首先A向B發出連線請求報文段，這時首部中的同步位SYN=1。TCP規定，SYN報文段不能攜帶資料。這時，A進入SYN-SENT狀態。
（2）B收到請求後，向A傳送確認。在確認報文段中把SYN和ACK位都置為1。這時B進入SYN-RCVD狀態。
（3）A收到B的確認後，還要向B給出確認。確認報文段的ACK置為1。這時，TCP連線已經建立，A進入ESTABLISHED 狀態，當B收到A的確認後，也會進入 ESTABLISHED 狀態。

第一次握手：客戶 → 伺服器（ACK = 0 ，SYN = 1）
第二次握手：伺服器 → 客戶（ACK = 1 ，SYN = 1）
第三次握手：客戶 → 伺服器（ACK = 1 ，SYN = 0）
2.連線釋放
四次握手斷開

四次握手（兩個二次握手）過程分析：

（1）客戶端 A 的 TCP 程式先向服務端發出連線釋放報文段，並停止傳送資料，主動關閉 TCP 連線,釋放連線報文段中 FIN=1。這時，A進入 FIN—WAIT-1 (終止等待1)狀態，等待 B 的確認。這是 TCP 連線釋放的第一次揮手。
（2）B收到連線釋放報文段後即發出確認釋放連線的報文段，該報文段中，ACK=1。然後B進入CLOSE—WAIT(關閉等待)狀態，此時TCP伺服器程式應該通知上層的應用程式，因而A到B這個方向的連線就釋放了，這時TCP處於半關閉狀態，即A已經沒有資料要發了，但B若傳送資料，A仍要接受，也就是說從B到A這個方向的連線並沒有關閉，這個狀態可能會持續一些時間。這是TCP連線釋放的第二次揮手。
（3）A收到B的確認後，就進入了FIN—WAIT(終止等待2)狀態，等待B發出連線釋放報文段，如果B已經沒有要向A傳送的資料了，其應用程式就通知TCP釋放連線。這時B發出的連結釋放報文段中，FIN=1。這時B進入LAST—ACK(最後確認)狀態，等待A的確認，這是TCP連線的第三次揮手。
（4）A收到B的連線釋放請求後，必須對此發出確認。確認報文段中，ACK=1，而後進入TIME—WAIT(時間等待)狀態。二者都進入CLOSED狀態後，連線就完全釋放了，這是TCP連線的第四次揮手。

第一次握手：客戶 → 伺服器（ACK = 1 ，FIN = 1）
第二次握手：伺服器 → 客戶（ACK = 1 ，FIN = 0）
第三次握手：伺服器 → 客戶（ACK = 1 ，FIN = 1）
第四次握手：客戶 → 伺服器（ACK = 1 ，FIN = 0）

三、抓包分析三次握手連線

開啟WireShark進行抓包後再開啟遊戲客戶端
篩選tcp，很容易找到三次握手
在這裡插入圖片描述
第一次握手
客戶 → 伺服器（ACK = 0 ，SYN = 1）

第二次握手
伺服器 → 客戶（ACK = 1 ，SYN = 1）

第三次握手
客戶 → 伺服器（ACK = 1 ，SYN = 0）

四、抓包分析四次握手斷開

按理來說WireShark可以抓取4次握手斷開，但是我的TCP互動過程中出現了異常
在這裡插入圖片描述
此時重置位RESET值變為1了。
TCP異常終止的幾種情況：

1.客戶端嘗試與伺服器未對外提供服務的埠建立TCP連線，伺服器將會直接向客戶端傳送reset報文。
2.客戶端和伺服器的某一方在互動的過程中發生異常（如程式崩潰等），該方系統將向對端傳送TCP reset報文，告之對方釋放相關的TCP連線。
3.接收端收到TCP報文，但是發現該TCP的報文，並不在其已建立的TCP連線列表內，則其直接向對端傳送reset報文。
4.在互動的雙方中的某一方長期未收到來自對方的確認報文，則其在超出一定的重傳次數或時間後，會主動向對端傳送reset報文釋放該TCP連線。
5.有些應用開發者在設計應用系統時，會利用reset報文快速釋放已經完成資料互動的TCP連線，以提高業務互動的效率。

由於我的TCP異常終止，這裡借用同學的圖。
第一次握手
客戶 → 伺服器（ACK = 1 ，FIN = 1）

第二次握手
伺服器 → 客戶（ACK = 1 ，FIN = 0）

第三次握手
伺服器 → 客戶（ACK = 1 ，FIN = 1）

第四次握手
客戶 → 伺服器（ACK = 1 ，FIN = 0）