三次握手四次揮手

一直都知道 TCP 創建鏈接時須要三次握手，釋放鏈接時須要四次揮手，也大概能說出整個過程，可是一直對其中的設計思想理解不深，停留在「只可意會，不可言傳」的階段。此次寫一篇博客嘗試將其中的思想表達出來。

 

 

 

TCP 建連三次握手

首先解釋一下每一個步驟的做用：
一、a 時刻，A 準備就緒，發送 SYN 包給 B，嘗試創建鏈接
二、b 時刻，B 收到 A 發來的 SYN 包，知道 A 要請求建連，回 SYN ACK 包，告訴 A 本身收到了建連請求，能夠建連了
三、c 時刻，A 收到了 B 的回覆，知道 B 準備好了，鏈路通暢，能夠發送數據了。回  ACK 告知 B 收到了 B 的回覆，下面要開始發送該數據了
四、d 時刻，B 收到了 A 的回覆，知道 A 接下來要發數據了。至此，AB 雙方都確認整個鏈路已經可靠了，接下來能夠發送數據了。

 

爲何要屢次確認呢？爲何不能夠 A 上來就直接發送數據給 B 呢？
這裏首先要明確一點，TCP 是傳輸層的協議，是創建在物理層、數據鏈路層、網絡層之上的協議，而底層的網絡是不可靠的，可能路由出問題，可能網關出問題，可能網線出問題，A 無法保證本身發出來的消息 B 必定能收到，因此必定要反饋機制，即 ACK，這樣才能在不可靠的網絡層智商構建可靠的傳輸層。

 

類比一下生活中的例子，能夠幫助咱們理解
示例1，假設咱們在火車上打電話，通話質量不好，咱們的通話過程可能會是下面這樣：

 

 

AB 雙方首先須要確認彼此都能挺到對方的聲音，也就是保證電話通道是可靠的，以後纔會開始說正事。若是一上來就直接說正事，可能 A 說完以後 B 根本就沒有聽到。
實際打電話過程當中，若是遇到了斷線的狀況，雙方可能須要進行屢次「握手」確認。

 

示例2，假設咱們給剛認識的人第一次打電話，通話過程多是下面這樣：

 

 

AB 雙方都要確認對方的身份，也就是保證通話是在跟本身人進行，確保電話通道是可靠的，不是跟騙子通話，而後纔會開始說正事。若是一上來沒有確認身份，不能保證通道是跟本身人進行的，那直接說出重要的事，極可能就泄漏了機密。

 

總之，握手過程的最終目的就是保證雙方都準備就緒，通路是可靠的，以後就能夠放心的發送重要數據了。

 

那爲何必定是三次呢，爲何不是兩次或者四次呢？
先來講一下爲何不能少。
一次能夠嗎？不能夠。設想一下，A 對 B 說：我要給你發數據。而後不等 B 的回覆，接下來就開始發數據了。這時候根本不能保證 B 已經準備好了，那 A 發出來的數據就無法保證 B 必定能收到。聯想生活中的場景，你隔着很遠的距離向對方喊話：我要把蘋果扔給你。而後不關心對方有沒有聽到，就直接扔了，那最終的結果一般就是對方接不到蘋果，由於對方可能根本沒有收到消息。
兩次能夠嗎？不能夠。設想一下，A 對 B 說：我要給你發數據，而後 B 收到消息後給 A 回覆：收到，A 在收到 B 的回覆後開始發送數據。這時候 A 端是能夠準備就緒的，可是 B 端不知道 A 端當前的狀態。由於 B 在收到 A 的消息的時候，可能已通過去了很長時間，B 在回消息的時候，A 可能已經不在線了，此時 B 是不能直接發數據的。若是 A 再給 B 回一個 ACK，B 就能夠確認當前鏈路狀態了，這就變成了三次握手。

接下來講一下爲何不是四次。既然三次已經能夠保證創建可靠通訊，就不須要額外的一次交互了。

 

下面是幾個生活中相關的示例：

 

 

 

 

 

 

 

 

 

 

 TCP 斷鏈四次揮手
一、a 時刻，A 向 B 發出 FIN 包，表示本身沒有數據要發送了
二、b 時刻，B 收到 FIN 包，回覆 FIN ACK，表示收到了 A 的 FIN 包，不會再接收 A 的數據了
三、B 在發完 FIN ACK 後，可能還有數據要發給 A，這個數據是不能中止發送的，有數據仍是須要繼續發送
四、d 時刻，B 發完了數據，也發出 FIN 包，告訴 A 本身的數據發完了，再也不發送數據了
五、e 時刻，A 收到了 B 的 FIN 包，知道 B 也沒有數據要發送了，回覆 FIN ACK。此時，鏈接能夠斷開了

建連只須要交互三次，斷連卻須要四次，這是爲何呢？其實斷開鏈接和創建鏈接仍是不同的。建連的時候，只要雙方都告知對方本身準備好了就能夠，可是斷連的時候，一方提出要斷開鏈接，再也不發數據，另外一方不能當即斷開，由於這一方可能還有數據要發送，直到數據所有發送完成後才能確認斷開。

 

下面是幾個生活中相關的示例：

 

 

 

以上是對於三次握手、四次揮手的簡單介紹，裏面沒有更詳細的狀態介紹，以後的博客會介紹，這裏先放兩張圖。
TCP 三次握手

 

 

 

TCP 四次揮手