前言

TCP協議為資料提供可靠的端到端的傳輸，處理資料的順序和錯誤恢復，保證資料能夠到達其應到達的地方。TCP協議是面向連線的，在兩臺主機使用TCP協議進行通訊之前，會先建立一個TCP連線（三次握手），雙方不再繼續通訊時，會將連線釋放（正常情況下四次揮手）。下面就抓包分析TCP三次握手和四次揮手的過程。

建立連線——三次握手

第一次握手

客戶端192.168.1.148傳送一個建立TCP連線的請求包給伺服器端174.143.213.184。可以從資料包中得出，建立連線源埠為57678，目標埠為80，確認編號為0。同步標誌位SYN被置為1，表示請求連線建立。TCP首部長度大於20位元組，說明選項中也附帶了一些內容，給出最大段長度為1460位元組，允許使用選擇確認等。

第二次握手

伺服器端收到請求後，傳送給客戶端確認包。該資料包中包含伺服器的初始序列號為0，以及對請求包的確認，所以確認號為1也是期望下一個收到的包的位元組流編號是從2開始的。

第三次握手

客戶端向伺服器端發出確認包，序號是從1開始，確認號為1，標誌位只有ACK被置為1，說明這是一個確認包。於是便完成TCP連線建立。在這個包傳送後，客戶端就已將可以向伺服器端請求資料，正常通訊了。

關閉連線——三次揮手

四次揮手過程

放一張以前做的圖介紹TCP四次揮手的過程：

當客戶端向伺服器端發起連線關閉請求時，因為伺服器端還有資料傳送給客戶端所以不能立馬將連線關閉，於是先回復客戶端ACK表示你的請求我已經收到

以上過程是標準的釋放過程，但是在實際通訊當中，可能只會有三次揮手。當客戶端傳送FIN包給伺服器端，伺服器端因為沒有資料再傳給客戶端，於是就會在回覆給客戶端的FIN的ACK包中將FIN欄位置位1，傳送給客戶端的包就為ACK+FIN，表示我也要求連線關閉。然後，客戶端回覆一個ACK確認收到FIN+ACK包，伺服器端就關閉連線，客戶端等待2MSL後也關閉連線。

上圖就是三次揮手的資料包截圖

第一次揮手

客戶端192.168.1.140向伺服器端172.143.213.184請求斷開連線。

第二次揮手

因為伺服器端沒有資料傳給客戶端於是將回復給客戶端的ACK包中FIN置為1，表示也請求連線斷開。

第三次揮手

客戶端對伺服器端的FIN+ACK進行回覆。伺服器端收到該ACK包就關閉連線。

小結

回頭想一想TCP為什麼是三次握手呢，兩次好像也是可以的。但是，這裡存在一個問題，網路中的包是會延遲的，如果有一個很久以前的連線請求傳送到了伺服器端（實際上客戶端已經發送了新的連線請求給伺服器端，完成了資料請求並且連線已經關閉），伺服器端並不知道這是以前的連線請求，於是也會回覆一個ACK並且等待客戶端的下一次請求。客戶收到該ACK不會回覆，就會造換成伺服器端一直等待並且超時重發ACK包。所以，兩次握手是不可以的，四次握手也是顯得多餘的。三次握手最後一次客戶端回覆ACK給伺服器端，伺服器端收到後，才分配資源等待客戶端的正式請求。
總結一句話需要三次握手的原因是：客戶傳送確認伺服器傳送的接收連線報文是為了防止以前的連線請求即失效連線請求傳送到伺服器而造成錯誤。