動畫：用動畫給女友講解 TCP 四次分手過程

1、寫在前邊

你們好，咱們又見面了，作爲一個業餘的動畫師，上次的用動畫的形式講解 TCP 三次握手過程再各大平臺收到了廣大讀者的喜好，說文章有趣、有貨、有內容，也受到了不少讀者的關注。不少讀者留言說何時用動畫講一講 TCP 四次揮手的過程，爲了應你們的要求，今天咱們就生動有趣的用動畫給你們分享 TCP 四次揮手（分手）過程。

動畫：用動畫給面試官解釋 TCP 三次握手過程

上次的三次握手動畫是給面試官看的，那麼今天我們換種更加有樂趣的方式，用動畫和你女(男)朋友講解 TCP 四次分手過程，講解完，考驗一下你女（男）朋友和不和你分手呢。什麼？首先你先有一個女（男）朋友，這一點小鹿早就考慮到了各大單身人士。

獲取方式:

若是你沒有女友，公衆號後臺回覆「女友」，便可獲取。小鹿不要臉的說，做爲一個優秀的動畫師，女性讀者也是不少的，哈哈，公衆號回覆「男友」，小鹿會給你隨機發放一個，嘿嘿，不信你試試。還等什麼，把你女（男）朋友拉過來給她（他）講吧。

2、思惟導圖

3、爲什麼要進行 TCP 三次握手/四次分手？

TCP 的三次握手和四次分手和你戀愛是如出一轍的，從相識到相戀到分手，而後認識另外一個女孩再無論重複這個過程就是數據傳輸在網絡中不斷創建起三次握手和四次分手過程。

戀愛就戀愛吧，分手就分手吧，握手握來握去，揮手揮來揮去不嫌麻煩嗎？

由於上篇文章 TCP 三次握手中的爲何要進行三次握手部分講解的不怎麼詳細，小鹿課下就收集了一些資料，作了一個總結，在這裏補充下。

3.1 爲何要進行三次握手？

在謝希仁著《計算機網絡》第四版中講「三次握手」的目的是「爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤」。

舉個簡單易懂的例子，你在微信對一個女孩表白，這條信息因爲網絡問題延遲發送了。

而後此時你不耐煩了，去和微信另外一個女孩表白，而後另外一個女孩告訴你贊成了，而後你內心很高興，把高興的心情分享給了女孩，女孩知道了你和她在一塊兒很高興，此時三次握完畢，你戀愛了。

忽然，到了次日，發給第一個女孩的信息才收到，女孩認爲你要和他表白，此時你已經和另外一個女孩戀愛了，而後第一個女孩給你發微信贊成了你的表白，可是你不理睬，那個女孩還在苦苦等待你給她分享此時的高興心情。如今咱們發現若是沒有分享高興的心情給女孩（也就是第三次握手過程），那麼那個女孩一直等待，白白浪費了心思，所謂的千年都等不了一回。

若是你是客戶端，女孩是服務端，服務端收到延遲的報文，覺得你要和它鏈接，因此會給你發送確認贊成鏈接，但你一直不搭理它，因此服務端的資源也就這麼白白浪費掉了。因此知道爲何要進行三次握手了吧。

在《計算機網絡》書中講「三次握手」的目的是爲了解決「網絡中存在延遲的重複分組」的問題。

3.2 爲何要 TCP 四次分手？

咱們知道，TCP協議是一種面向鏈接的、可靠的、基於字節流的運輸層通訊協議，並且TCP是全雙工模式。

對於初學者來講，定義太枯燥、無味，其實意思就是你和你女友聊天是面向鏈接的，只有鏈接起來才能夠通訊的，可靠就是你發送的信息能夠保證送達到對方，全雙工意思就是你不只能夠給你女友發消息，並且她也能夠給你發信息。

爲何非要進行 TCP 四次分手？咱們接着上回說到，你如今和第二個女孩子戀愛了，忽然有一天發現第一個女孩子是由於沒有收到你的表白而錯過了在一塊兒的時機，那麼你要和第二個女孩子分手，那過程對應在 TCP 四次分手是怎麼樣子的？

你要給第二個女孩子微信發消息，咱們分手吧，此時第二個女孩子收到消息知道了，很是傷心，就屏蔽了你。可是，此時你尚未屏蔽她，她徹底能夠給你繼續發消息，她給你發消息說，好吧，此時你收到了確認消息，此時是第二次分手過程。那麼女孩又給你發送消息，渣男，永遠不要來找我。此時你又接收到消息，看到消息以後發了一個拜拜，而後你就直接屏蔽拉黑了對方，此時女孩微信顯示你刪除了對方，而後就把你也拉黑刪除了。那麼四次分手到此爲止，恭喜你，成功得到下一個女孩子。

上述過程就闡述了爲何要進行 TCP 四次分手，爲了可以讓對方屏蔽你直至最後雙方互相刪除掉，而後你又能夠和另外一個女孩三次握手了。

4、TCP 四次分手過程

初始化狀態：客戶端和服務端都在鏈接狀態，接下來開始進行四次分手斷開鏈接操做。

• 第一次分手：第一次分手不管是客戶端仍是服務端均可以發起，由於 TCP 是全雙工的。

假如客戶端發送的數據已經發送完畢，發送FIN = 1 告訴服務端，客戶端全部數據已經全發完了，服務端你能夠關閉接收了，可是若是大家服務端有數據要發給客戶端，客戶端照樣能夠接收的。此時客戶端處於FIN = 1等待服務端確認釋放鏈接狀態。

• 第二次分手：服務端接收到客戶端的釋放請求鏈接以後，知道客戶端沒有數據要發給本身了，而後服務端發送ACK = 1告訴客戶端受到你發給個人信息，此時服務端處於 CLOSE_WAIT 等待關閉狀態。

• 第三次分手：此時服務端向客戶端把全部的數據發送完了，而後發送一個FIN = 1，用於告訴客戶端，服務端的全部數據發送完畢，客戶端你也能夠關閉接受數據鏈接了。此時服務端狀態處於LAT_ACK狀態，來等待確認客戶端是否收到了本身的請求。

• 第四次分手：此時若是客戶端收到了服務端發送完的信息以後，就發送ACK = 1，告訴服務端，客戶端已經收到了你的信息。可是咱們發現上圖中有一個 2 MSL 的延遲等待。

5、爲什要有 2 MSL 等待延遲？

對應這樣一種狀況，最後客戶端發送的ACK = 1給服務端的過程當中丟失了，服務端沒收到，服務端怎麼認爲的？我已經發送完數據了，怎麼客戶端沒回應我？是否是中途丟失了？而後服務端再次發起斷開鏈接的請求，一個來回就是2MSL，這裏的兩個來回由那一個來回組成的？

客戶端給服務端發送的ACK = 1丟失，服務端等待 1MSL沒收到，而後從新發送消息須要1MSL。若是再次接收到服務端的消息，則重啓2MSL計時器，發送確認請求。客戶端只需等待2MSL，若是沒有再次收到服務端的消息，就說明服務端已經接收到本身確認消息；此時雙方都關閉的鏈接，TCP 四次分手完畢。

6、若是雙方創建鏈接，一方出問題怎麼辦？

若是雙方創建鏈接，一方出問題怎麼辦？爲了防止出現上述戀愛故事中千年等一回的狀況，已經創建鏈接，可是服務端一直等待接收，發送端出現問題一直不能發送。

因此設計一個保活的計時器，若是一方出現問題，另外一方過了這個計時器的時間，就發送試探報文，之後每隔 75 秒發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉鏈接。

小結

今天用動畫的形式給你女（男）朋友講了 TCP 四次分手的過程，文章的內容以及展示形式是最基礎的內容。

最後小鹿爲你們整理的三次握手和四次分手整張圖，以下：

最後但願你和你的女友永遠三次握手，永不四次分手。

❤️ 不要忘記留下你學習的腳印 [點贊 + 收藏 + 評論]

文章都看完了，爲什麼不妨點個贊呢？嘻嘻，那就說明你很自私，你怕那麼好的文章讓別人也看到。開個小小玩笑。

其實我也很自私，我把個人一直以來堅持原創的公衆號:「小鹿動畫學編程」偷偷給你，裏邊匯聚了小鹿以動畫形式講解的數據結構與算法、網絡原理、Web 等技術文章。

做者Info：

【做者】：小鹿

【原創公衆號】小鹿動畫學編程

【簡介】：和小鹿同窗一塊兒用動畫的方式從零基礎學編程，將Web前端領域、數據結構與算法、網絡原理等通俗易懂的呈獻給小夥伴。公衆號回覆 「資料」 送一從零自學資料大禮包！

【轉載說明】：轉載請說明出處，謝謝合做！~