動畫講解TCP，再不懂請來打我

TCP 三次握手和四次揮手過程對於面試是必考的一個，其中有些小細節也更受到面試官的青睞。

圖片來自 Pexels

對於這部分的掌握我將會以動畫的形式呈現給每個人，這樣將複雜的知識簡單化，理解起來也容易了很多，尤其對於一個初學者來說。

TCP 三次握手

思維導圖如下：

TCP 是什麼

TCP(Transmission Control Protocol 傳輸控制協議)是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。

我們知道了上述瞭解到了 TCP 的定義，通俗一點的講，TCP 就是一個雙方通信的一個規範標準(協議)。

我們在學習 TCP 握手過程之前，首先必須瞭解 TCP 報文頭部的一些標誌信息。

因為在 TCP 握手的過程中，會使用到這些報文信息，如果沒有掌握這些信息，在學習握手過程中，整個人處於懵逼狀態，也是為了能夠深入 TCP 三次握手的原理。

TCP 頭部報文

①Source Port 和 Distination Port

兩者分別為「源端口號」和「目的端口號」。源端口號就是指本地端口，目的端口就是遠程端口。

一個數據包(Pocket)被解封裝成數據段(Segment)後就會涉及到連接上層協議的端口問題。

可以這麼理解，我們可以想象發送方很多的窗戶，接收方也有很多的窗戶，這些窗口都標有不同的端口號，源端口號和目的端口號就分別代表從哪個規定的串口發送到對方接收的窗口。

不同的應用程度都有著不同的端口，之前網絡分層的文章中有提到過。

擴展：應用程序的端口號和應用程序所在主機的 IP 地址統稱為 Socket(套接字)，IP：端口號，在互聯網上 Socket 唯一標識每一個應用程序。

源端口+源 IP+目的端口+目的 IP 稱為“套接字對”，一對套接字就是一個連接，一個客戶端與服務器之間的連接。

②Sequence Number

稱為「序列號」。用於 TCP 通信過程中某一傳輸方向上字節流的每個字節的編號，為了確保數據通信的有序性，避免網絡中亂序的問題。

接收端根據這個編號進行確認，保證分割的數據段在原始數據包的位置。

再通俗一點的講，每個字段在傳送中用序列號來標記自己位置的，而這個字段就是用來完成雙方傳輸中確保字段原始位置是按照傳輸順序的。(發送方是數據是怎樣一個順序，到了接受方也要確保是這個順序)

PS：初始序列號由自己定，而後緒的序列號由對端的 ACK 決定：SN_x = ACK_y(x 的序列號 = y 發給 x 的 ACK)，這裡後邊會講到。

③Acknowledgment Number

稱為「確認序列號」。確認序列號是接收確認端所期望收到的下一序列號。確認序號應當是上次已成功收到數據字節序號加 1，只有當標誌位中的 ACK 標誌為 1 時該確認序列號的字段才有效，主要用來解決不丟包的問題。

若確認號=N，則表明：到序號 N-1 為止的所有數據都已正確收到。

在這裡，現在我們只需知道它的作用是什麼，就是在數據傳輸的時候是一段一段的，都是由序列號進行標識的，所以說，接收端每接收一段，之後就想要的下一段的序列號就稱為「確認序列號」。

④TCP Flag

TCP 首部中有 6 個標誌比特，它們中的多個可同時被設置為 1，主要是用於操控 TCP 的狀態機的，依次為 URG，ACK，PSH，RST，SYN，FIN。

不要求初學者全部掌握，在這裡只講三個重點的標誌：

ACK：這個標識可以理解為發送端發送數據到接收端，發送的時候 ACK 為 0，標識接收端還未應答，一旦接收端接收數據之後，就將 ACK 置為 1，發送端接收到之後，就知道了接收端已經接收了數據。

此標誌表示「應答域有效」，就是說前面所說的 TCP 應答號將會包含在 TCP 數據包中;有兩個取值：0 和 1，為 1 的時候表示應答域有效，反之為 0。

SYN：表示「同步序列號」，是 TCP 握手的發送的第一個數據包。

用來建立 TCP 的連接。SYN 標誌位和 ACK 標誌位搭配使用，當連接請求的時候，SYN=1，ACK=0 連接被響應的時候，SYN=1，ACK=1;這個標誌的數據包經常被用來進行端口掃描。

掃描者發送一個只有 SYN 的數據包，如果對方主機響應了一個數據包回來 ，就表明這臺主機存在這個端口。

看下面動畫：

FIN：表示發送端已經達到數據末尾，也就是說雙方的數據傳送完成，沒有數據可以傳送了，發送 FIN 標誌位的 TCP 數據包後，連接將被斷開。這個標誌的數據包也經常被用於進行端口掃描。

這個很好理解，就是說，發送端只剩最後的一段數據了，同時要告訴接收端後邊沒有數據可以接受了，所以用 FIN 標識一下，接收端看到這個 FIN 之後，哦!這是接受的最後的數據，接受完就關閉了。

動畫如下：

Window Size：稱為滑動窗口大小。所說的滑動窗口，用來進行流量控制。

為什麼進行 TCP 三次握手

原因如下：

• 為了確認雙方的接收與發送能力是否正常。
• 指定自己的初始化序列號，為後面的可靠傳送做準備。
• 如果是 HTTPS 協議的話，三次握手這個過程，還會進行數字證書的驗證以及加密密鑰的生成到。

如果你瞭解 UDP 的話，TCP 的出現正式彌補了 UDP 不可靠傳輸的缺點。但是 TCP 的誕生，也必然增加了連接的複雜性。

TCP 三次握手過程

TCP 三次握手的過程掌握最重要的兩點就是客戶端和服務端狀態的變化，另一個是三次握手過程標誌信息的變化，那麼掌握 TCP 的三次握手就簡單多了。

下面我們就以動畫形式進行拆解三次握手過程：

初始狀態：客戶端處於 Closed(關閉)狀態，服務器處於 Listen(監聽)狀態。

第一次握手：客戶端發送請求報文將 SYN=j(1)初始化序列號發送給客戶端，發送完之後客戶端處於 SYN_Send 狀態。

第二次握手：服務端受到 SYN 請求報文之後，如果同意連接，會以自己的SYN(服務端)=K(0)和 ack(1)=SYN(客戶端)+1(ACK=1)報文作為應答，服務器為 SYN_Receive 狀態。

第三次握手：客戶端接收到服務端的 SYN+ACK，然後發送 ack=SYN(服務端)+1(ACK=1)確認包作為應答，客戶端轉為 Established 狀態。

為什麼不是一次、兩次握手

防止了服務器端的一直等待而浪費資源。為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。

如果此時客戶端發送的延遲的握手信息服務器收到，然後服務器進行響應，認為客戶端要和它建立連接，此時客戶端並沒有這個意思。

但 Server 卻以為新的運輸連接已經建立，並一直等待 Client 發來數據。這樣，Server 的很多資源就白白浪費掉了。

TCP 四次分手

下面我們接著用生動有趣的動畫給大家分享 TCP 四次揮手(分手)過程。

思維導圖如下：

為何要 TCP 三次握手/四次分手

TCP 的三次握手和四次分手和你戀愛是一模一樣的，從相識到相戀到分手，然後認識另一個女孩再不管重複這個過程就是數據傳輸在網絡中不斷建立起三次握手和四次分手過程。

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

因為上篇文章 TCP 三次握手中的為什麼要進行三次握手部分講解的不怎麼詳細，於是我就收集了一些資料，做了一個總結，在這裡補充下。

①為什麼要進行三次握手?

在謝希仁著《計算機網絡》第四版中講“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤”。

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

然後此時你不耐煩了，去和微信另一個女孩表白，然後另一個女孩告訴你同意了，然後你心裡很高興，把高興的心情分享給了女孩，女孩知道了你和她在一起很高興，此時三次握手完畢，你戀愛了。

突然，到了第二天，發給第一個女孩的信息才收到，女孩認為你要和他表白，此時你已經和另一個女孩戀愛了，然後第一個女孩給你發微信同意了你的表白，但是你不理睬，那個女孩還在苦苦等待你給她分享此時的高興心情。

現在我們發現如果沒有分享高興的心情給女孩(也就是第三次握手過程)，那麼那個女孩一直等待，白白浪費了心思，所謂的千年都等不了一回。

如果你是客戶端，女孩是服務端，服務端收到延遲的報文，以為你要和它連接，所以會給你發送確認同意連接，但你一直不搭理它，所以服務端的資源也就這麼白白浪費掉了。所以知道為什麼要進行三次握手了吧。

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

②為什麼要 TCP 四次分手?

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

對於初學者來說，定義太枯燥、無味，其實意思就是你和你女朋友聊天是面向連接的，只有連接起來才可以通信的。

可靠就是你發送的信息可以保證送達到對方，全雙工意思就是你不僅可以給你女朋友發消息，而且她也可以給你發信息。

為什麼非要進行 TCP 四次分手?我們接著上回說到，你現在和第二個女孩子戀愛了，突然有一天發現第一個女孩子是因為沒有收到你的表白而錯過了在一起的時機，那麼你要和第二個女孩子分手。

那過程對應在 TCP 四次分手是怎麼樣子的?

你要給第二個女孩子微信發消息，我們分手吧，此時第二個女孩子收到消息知道了，非常傷心，就屏蔽了你。

但是，此時你還沒有屏蔽她，她完全可以給你繼續發消息，她給你發消息說，好吧，此時你收到了確認消息，此時是第二次分手過程。那麼女孩又給你發送消息，渣男，永遠不要來找我。

此時你又接收到消息，看到消息之後發了一個拜拜，然後你就直接屏蔽拉黑了對方，此時女孩微信顯示你刪除了對方，然後就把你也拉黑刪除了。那麼四次分手到此為止，恭喜你，成功獲得下一個女孩子。

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

TCP 四次分手過程

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

第一次分手：第一次分手無論是客戶端還是服務端都可以發起，因為 TCP 是全雙工的。

假如客戶端發送的數據已經發送完畢，發送 FIN=1 告訴服務端，客戶端所有數據已經全發完了，服務端你可以關閉接收了，但是如果你們服務端有數據要發給客戶端，客戶端照樣可以接收的。

此時客戶端處於 FIN=1 等待服務端確認釋放連接狀態。

第二次分手：服務端接收到客戶端的釋放請求連接之後，知道客戶端沒有數據要發給自己了，然後服務端發送 ACK=1 告訴客戶端受到你發給我的信息，此時服務端處於 CLOSE_WAIT 等待關閉狀態。

第三次分手：此時服務端向客戶端把所有的數據發送完了，然後發送一個 FIN=1，用於告訴客戶端，服務端的所有數據發送完畢，客戶端你也可以關閉接受數據連接了。

此時服務端狀態處於 LAT_ACK 狀態，來等待確認客戶端是否收到了自己的請求。

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

為什要有 2MSL 等待延遲

對應這樣一種情況，最後客戶端發送的 ACK=1 給服務端的過程中丟失了，服務端沒收到，服務端怎麼認為的?我已經發送完數據了，怎麼客戶端沒回應我?是不是中途丟失了?

然後服務端再次發起斷開連接的請求，一個來回就是 2MSL，這裡的兩個來回由那一個來回組成的?

客戶端給服務端發送的 ACK=1 丟失，服務端等待 1MSL 沒收到，然後重新發送消息需要 1MSL。

如果再次接收到服務端的消息，則重啟 2MSL 計時器，發送確認請求。客戶端只需等待 2MSL，如果沒有再次收到服務端的消息，就說明服務端已經接收到自己確認消息;此時雙方都關閉的連接，TCP 四次分手完畢。

如果雙方建立連接，一方出問題

如果雙方建立連接，一方出問題怎麼辦?為了防止出現上述戀愛故事中千年等一回的情況，已經建立連接，但是服務端一直等待接收，發送端出現問題一直不能發送。

所以設計一個保活的計時器，如果一方出現問題，另一方過了這個計時器的時間，就發送試探報文，以後每隔 75 秒發送一次。若一連發送 10 個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。

最後為大家整理的三次握手和四次分手整張圖，如下：

最後希望你和你的女朋友永遠三次握手，永不四次分手。