簡單理解什麼是TCP/IP三次握手和四次揮手

為什麼要進行三次握手

先送給大家一個笑話：

嗨，我想聽一個 TCP 的笑話。
你好，你想聽 TCP 的笑話麼？
嗯，我想聽一個 TCP 的笑話。
好的，我會給你講一個TCP 的笑話。
好的，我會聽一個TCP 的笑話。
你準備好聽一個TCP 的笑話麼？
嗯，我準備好聽一個TCP 的笑話
Ok，那我要發 TCP 笑話了。大概有 10 秒，20 個字。
嗯，我準備收你那個 10 秒時長，20 個字的笑話了。
抱歉，你的連線超時了… 你好，你想聽 TCP 的笑話麼？
我給你們講個 UDP 的笑話吧。

在計算機網路中，資訊的傳遞是不穩定的，所以為了確保傳輸資訊的完整性，TCP進入了歷史舞臺。

• 三次握手的目的在於確認傳送方與接收方的傳送與接收資訊的能力都是完好可用的。然後便是建立連線，進行可靠傳輸
  聽起來有點拗口。
  再來看下三次握手的示意圖：
  

• 這裡還需要引入TCP報文的基礎知識：
  TCP報文的頭部資訊中包含有確認ACK、同步SYN、終止FIN
  確認ACK：僅當ACK=1時確認號欄位有效，ACK=0無效
  同步SYN：SYN=1表示這是一個連線請求報文或者接受連線報文
  終止FIN：FIN=1表示本條報文資料傳送完畢

第一次：客戶端傳送SYN=1的報文給服務端
第二次：服務端傳送SYN=1，ACK=1的報文給客戶端
第三次：客戶端傳送ACK=1的報文給服務端

看起來好像很簡單，實際上比這複雜的多，傳送的請求中還包含校驗資訊。

那麼它們都有什麼作用呢？

客戶端向服務端傳送連線請求，並帶上自己的確認號，服務端收到請求後，返回給客戶端一條報文，並帶上客戶端的確認號和自己的確認號。
這時候客戶端和服務端都不知道自己的傳送和接收功能是不是完整 。
當客戶端收到服務端傳送回來的報文時，客戶端知道了自己的傳送功能沒問題，接收功能也OK。
但是，這時候服務端還不知道自己的各項功能是不是OK
然後，客戶端又發給服務端一條確認資訊，告訴服務端我收到了你的請求，你的確認號是XXX，服務端收到後檢視資訊無誤，知道了自己的傳送和接收功能 也都是正常的。
連線建立。

四次揮手

因為TCP是面向連線的傳輸控制協議，建立了連線，那就有需要斷開的時候。

第一次：客戶端向服務端傳送FIN=1的報文，告訴伺服器資料傳送完畢，請求斷開連線。
第二次：服務端收到請求後，傳送ACK=1的報文給客戶端，客戶端收到後，客戶端到服務端的連線斷開。
此時，連線處於半關閉狀態，客戶端無法向服務端傳送資料，但是服務端仍能向客戶端傳送資料，客戶端還會接收。
第三次：伺服器端確認沒有資料需要繼續傳送後，向客戶端傳送FIN=1的報文，請求斷開連線。
第四次：客戶端收到服務端斷開連線的請求後，傳送ACK=1的報文，告訴服務端可以斷開連線。

• 但是此時的連線並沒有真正的斷開。
• TCP連線必須等待2MSL後才能真正的釋放掉。
  MSL：MSL是Maximum Segment Lifetime英文的縮寫，中文可以譯為“報文最大生存時間”，他是任何報文在網路上存在的最長時間，超過這個時間報文將被丟棄。
  等待的原因是為了確保斷開連線的請求能夠到達服務端，避免影響下一次連線的建立。