首先，是需要明白一些欄位的含義，這樣三次握手、四次握手的流程圖就立馬可以很輕鬆地理解，並迅速手繪了。

（至於這兩個流程圖，網上鋪天蓋地都是，這裡就不貼出來了。）

SYN:該欄位被設定為1（即true），表示請求建立連線

FIN：該欄位被設定為1（即true），表示請求關閉連線

seq:該欄位為請求序列號，譬如為seq=x, 能夠標示一個請求包，在眾多包種區分其身份

ack:該欄位為確認欄位，譬如ack=x+1，表示已經收到對方發來的seq=x的請求包。

然後TCP是個可以雙向通訊的協議，

一次 “請求連線——確認”操作，可以確保一方做好了傳送準備，另一方做好了接收準備，因此可以建議一個單向的連線；

一次 “請求關閉——確認”操作，可以確保一方發完了資料希望關閉傳送，另一方收到請求關閉接收，最後關閉掉一個單向的連線。

其實，無論是建立連線的過程，還是關閉連線的過程，實際上都由兩個單向連線的 建立過程/關閉過程組成的，也就是在邏輯流程上都可以認為是兩個二次握手，即都需要四次。只不過，三次握手中，服務端確認客戶端連線的那個過程，即是第一次單向連線的確認，又是第二次單向連線的請求，它把兩次互動合併成了一次，因此就變成了三次握手。

（至於說三次握手單純是因為避免這種情況：客戶端過去已經發送的請求，再次到達服務端，導致再次建立連線，而客戶端對此無應答，因此導致服務端資源白白浪費。這應該不是根本原因，因為每個請求包都有seq序列號呀，序列號相同的請求包再次到達，在協議設計上，完全可以用seq判斷出是否是已經過時的請求包。）

一、建立TCP連線：三次握手協議

客戶端：我要對你講話，你能聽到嗎；

服務端：我能聽到；而且我也要對你講話，你能聽到嗎；

客戶端：我也能聽到。

…….

互相開始通話

……..    

二：關閉TCP連線：四次握手協議

客戶端：我說完了，我要閉嘴了；

服務端：我收到請求，我要閉耳朵了；

（客戶端收到這個確認，於是安心地閉嘴了。）

…….

    服務端還沒傾訴完自己的故事，於是繼續嘮嘮叨叨向客戶端說了半天，直到說完為止

…….

服務端：我說完了，我也要閉嘴了；

客戶端：我收到請求，我要閉耳朵了；（事實上，客戶端為了保證這個確認包成功送達，等待了兩個最大報文生命週期後，才閉上耳朵。）

（服務端收到這個確認，於是安心地閉嘴了。）

#.客戶端收到請求包後，為什麼要等待兩個最大報文生命週期後，才閉上耳朵呢？

    為了以防萬一，因為最後一個發往服務端B的確認包有可能丟失。若丟失，服務端這裡過了響應超時時間timeOut，會再次往客戶端A傳送關閉連線請求，這時候客戶端得保證自己還沒閉上耳朵，還能接收請求才行。