在上一篇我們瞭解的TCP的報文格式和TCP連線管理機制：TCP初認識

今天來理解什麼是三次握手，什麼是四次揮手

什麼是三次握手

在網路資料傳輸中，傳輸層協議TCP(傳輸控制協議)是建立連線的可靠傳輸，TCP建立連線的過程，我們稱為三次握手。
第一次，客戶端向伺服器傳送SYN同步報文段，請求建立連線
第二次，伺服器確認收到客戶端的連線請求，並向客戶端傳送SYN同步報文，表示要向客戶端建立連線
第三次，客戶端收到伺服器端的確認請求後，處於建立連線狀態，向伺服器傳送確認報文
客戶端是在收到確認請求後，先建立連線
伺服器是在收到最後客戶端的確認後，建立連線
發起連線請求的一定是客戶端

為什麼建立連線時要進行三次握手？

我們可以分析一次握手肯定是不行的，這樣伺服器都不一定能收到連線請求

那麼如果是兩次握手呢?

如果是兩次握手，連線過程應該是這樣的，當伺服器收到對端的連線請求時，就認為連線建立好了，進入ESTABLISHED狀態。客戶端在收到伺服器發來的同步確認報文後，就認為連線建立好了，進入ESTABLISHED，在報文都能正常收到的情況下，兩次握手是可以安全建立連線的。
但是存在這樣的情況，假設第二次握手的報文丟失了，當前的狀態是，伺服器認為連線已經建立好了，可是客戶端沒有收到同步確認報文，認為連線還沒有建立好，此時，伺服器端的連線其實是無效連線，客戶端因為沒有收到確認，便會向伺服器重傳同步報文，同樣，在伺服器收到客戶端的同步報文時，認為連線已經建立好了，同樣糟糕的事情發生了，伺服器給客戶端傳送的同步確認報文丟失了，或者是說有人惡意向伺服器不斷髮送SYN同步報文（SYN洪水）。那麼伺服器端就會有大量的無效連線，伺服器處理連線的數量是有限的，當有大量的無效連線建立後，伺服器處理有效連線是能力就會受限，且建立連線會消耗大量是資源，至此有可能導致伺服器崩潰。
這樣看來兩次握手是不可行的。

三次握手為什麼是可行的呢？

在上面的兩次握手的方案中，我們看到建立連線過程中，是伺服器先處於連線建立好的狀態，出現差錯時，客戶端沒有連線建立成功，致使伺服器可能有大量的無效連線，導致伺服器安全問題。
那麼在三次握手方案中，客戶端收到伺服器的同步確認報文後，就認為連線建立好了（先處於連線建立好的狀態），而伺服器是要收到客戶端的確認報文後才認為連線建立好了。
那麼也可能存在這樣的問題，在最後一次握手時，伺服器沒有收到客戶端的確認報文，此時的狀態是，客戶端處於建立連線狀態，伺服器處於沒有建立連線狀態，此時客戶端負責維護這次連線

1. 三次握手中，是誰先發起請求，誰來負責維護這次連線，那麼會出現上面類似SYN洪水的問題嗎？顯然是不會的，自己發出SYN，最終無效連線還是建立在自己這方，客戶端也不會這麼無聊吧
2. 而當客戶端嘗試向伺服器傳送資料時，伺服器看到的是，還沒有建立連線的資料，伺服器會響應一個帶有RST標誌位的報文，告知客戶端你需要先建立連線，此時當客戶端收到這個報文時，就會重新發起建立連線的請求。

總結下來就是，三次握手中，即使建立連線失敗，對伺服器是沒有影響的，保證伺服器的安全，而對客戶端而言，也不過是多次建立連線而已。並且在經過驗證，三次握手的成功率也是非常高的。

四次握手可行嗎？

很明顯，三次握手已經可以滿足我們的需求了，也就沒必要多一次而浪費資源了。
在兩次握手和三次握手的方案中，我們發現要保證客戶端先建立連線的話，能保證連線的安全建立。若是偶數次握手，或者是說讓伺服器先建立連線，就是不安全不可行的方案。所以四次 握手是不可行的。

什麼是四次揮手

在網路資料傳輸中，傳輸層協議斷開連線的過程我們稱為四次揮手
第一次，A端像B端傳送FIN結束報文段，準備關閉連線
第二次，B端確認A端的FIN，表示自己已經收到對方關閉連線的請求
中間這段時間，A端停止向B端傳送資料，但是B端可以向A端傳送資料，要將自己未處理完任務處理完
第三次，B端向A端傳送FIN結束報文段，準備關閉連線
第四次，A端確認B端的FIN，進入TIME_WAIT狀態，此時A端程序已經退出，但是連線還在
當B端收到A端的ACK之後，先斷開連線
當A端等待2 MSL之後，確認的B端接收到ACK後，再斷開連線
發起斷開連線請求的一端最後要進入有一個TIME_WAIT狀態
發起連線請求的可以是客戶端也可以是伺服器端

為什麼斷開連線要四次?
不像建立連線的過程,伺服器端在呼叫了accept()之後,剩下的都交給核心來處理,使用者空間不用做什麼,斷開連線是,A端呼叫close()關閉檔案描述符後,A端就停止傳送資料了進行傳送,B端收到後結束報文段之後,的得知A端要斷開連線了,但是B端可能有自己還沒有處理完的資料,不能立即斷開連線,就要先給出回覆,表示自己已經收到訊息了,然後將自己的資料處理完之後,可以斷開連線的時候,再呼叫close()發出斷開連線請求,在收到A端的確認回覆之後,斷開連線,這樣看來每一步都不能少,但是有時候若伺服器端沒有什麼要處理的資料,就看可以直接呼叫close()捎帶上響應報文,此時就是3次
為什麼先發起斷開連線請求的一端最後要等待 2MSL？
MSL為一段報文從一段到一段的最大時間，也稱為報文的最大生存時間，我們假設在上面的四次揮手過程中最後A端在收到B端的FIN之後，就關閉連線，最後B端在收到A端的確認報文之後也斷開連線，這種情況是我們預期的
試想是否存在這樣的情況，在A端已經關閉連線後，但是發給B端的ACK報文中途丟失，此時B端就會重發FIN結束報文段，但是A端已經關閉與這臺伺服器的連線，並且已經開始了一段新的連線，那麼A端收到這個過期的FIN，誤認為是關閉當前連線，給出錯誤處理。
也就是說A端等待 2MSL就 可以保證在B端沒有收到A 到ACK時，B端重發的FIN,A端來的及處理，然後重新確認等待2 MSL，保證了最後的ACK 報文 B端成功收到。