今天我們來講一下TCP的三次握手和四次揮手，先來張思維導圖。

 一、TCP是什麼

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連線的、可靠的、基於位元組流的傳輸層通訊協議。

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

我們在學習TCP握手的過程之前，首先必須要了解TCP報文頭部的一些標識資訊。因為TCP握手的過程中，會使用到這些報文資訊，如果沒有掌握這些資訊，在學習握手的過程中，整個人都處於懵逼狀態，也是為了能夠深入TCP三次握手的原理。

1、TCP頭部報文

 （1）Source Port 和 Destination Port

兩者分別為【源埠號】和【目的埠號】，源埠號就是指本地埠，目的埠就是遠端埠。一個數據包（Pocket）被解分成資料段（Segment）後就會涉及到連線上層協議的埠問題。那麼可以這麼理解，我們可以想象傳送方很多的窗戶，接收方也有很多的窗戶，這些視窗都標有不同的埠號，源埠號和目的埠號就分別代表從哪個規定的視窗傳送到對方接收的視窗。不同的應用程式都有著不同的埠。

 擴充套件：應用程式的埠號和應用程式所在主機的IP地址統稱為Socket（套接字），IP，埠號，在網際網路上Socket唯一標識每一個應用程式。

源埠號+源IP+目的埠號+目的IP 成為“套接字對”，一對套接字就是一個連線，一個客戶都安於服務端之間的連線。

（2）Sequence Number

稱為【序列號】，用於TCP通訊過程中某一傳輸方向上位元組流的每個位元組的編號，為了確保資料通訊的有序性，避免網路中亂序問題。接收端根據這個編號進行確認，保證分割的資料段在原始資料包的位置。

再通俗一點的將，每個欄位再傳輸中用序列號來標記自己的位置，而這個欄位就是用來完成雙方傳輸中確保欄位原始位置是按照順序傳輸的，（傳送方的資料是怎麼一個順序，到了接收方也要確保是這個順序）

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

（3）Acknowledgement Number

稱為【確認序列號】，確認序列號是接收確認端所期望收到的下一個序列號，確認序列號應上是上次已經成功收到的資料位元組序列號加1，只有當標誌位中的ACK標識為1的確認序列號的欄位才有效。主要用來就解決不丟包的問題。若確認序列號=N，則表明：到序列號N-1位置的所有資料都已正確收到。

在這裡，現在我們只需要知道他們的作用是什麼，就是在資料傳輸的時候是一段一段的，都是由序列號進行標識的，所以說，接收端沒接受一段，之後就想要的下一段序列號就稱為【確認序列號】。

（4）TCP Flag

TCP首部中有6個標識bite，他們中的多個可同時被設定為1，主要是用於操控TCP的狀態機的，依次為 URG、ACK、PSH、RST、SYN、FIN。不要求初學者全部掌握，這裡面只講三個重點的標識：

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

FIN：表示傳送端已經達到資料末尾，也就是說雙方的資料傳輸完成，沒有資料可以傳送的。傳送FIN標識位的TCP資料包後，連線將被斷開，這個標識的資料包也經常被用於進行埠掃描。

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

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

二、為什麼進行TCP三次握手

原因如下：

1、為了確認雙方的接受與傳送能力是否正常

2、指定自己的初始化序列號，為後面的可靠傳輸做準備

3、如果是HTTPS協議的話，三次握手的這個過程還會進行數字證書的驗證以及加密金鑰的生成。

如果你瞭解UDP的話，TCP的出現正是彌補了UDP不可靠傳輸的缺點，但是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狀態

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

防止了伺服器端的一直等待而浪費資源，為了防止已失效的連線請求報文突然又傳送到了服務端而產生的錯誤。如果此時客戶端傳送的延時的握手資訊服務端收到了，然後服務端進行響應，認為客戶端要和他建立連線，此時，客戶端並沒有這個意思。但服務端卻認為連線已經建立，並一直等待客戶端傳送資料，這樣，服務端的很多資源就白白浪費掉了。

五、TCP四次分手

下面我們接著給大家分享一下TCP四次揮手(分手)的過程

思維導圖如下：

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

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

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

1、為什麼要進行三次握手：

本問上面第四段也講到了，三次握手的目的是：為了防止已經失效的連線請求報文突然又傳送到了服務端而產生錯誤。

舉個簡單易懂的例子，你在微信對一個女孩表白，這條資訊由於網路的問題延時傳送了。

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

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

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

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

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

2、為什麼TCP要四次分手

我們知道，TCP協議是一種面向連線的、可靠的、基於位元組流的運輸層通訊協議，而且TCP是全雙工模式。對於初學者來說，定義太枯燥，無味，其實意思就是你和女孩聊天是面向連線的，只有連線起來才可以通訊。可靠就是你傳送的資訊可以保證送達到對方，全雙工意思就是你不僅可以傳送訊息給女孩，那個女孩也可以傳送訊息給你。

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

你要給第二個女孩子微信發訊息，我們分手吧，此時第二個女孩收到訊息知道了，非常傷心，就遮蔽了你。但是此時你還沒有遮蔽她，她完全可以給你繼續發訊息，她給你發訊息說：好吧。此時你收到了確認訊息，此時是第二次分手過程。那麼女孩又給你傳送訊息：渣男，永遠不要來找我。此時你又收到訊息，看到訊息後發了一個拜拜，然後你就直接遮蔽拉黑了對方。此時女孩微信顯示你刪除了對方，然後就把你也拉黑刪除了。那麼四次分手就到此為止，恭喜你，成功分手。

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

3、TCP四次分手過程

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

 （1）第一次分手：第一次分手無論是客戶端還是服務端都可以發起。因為TCP是全雙工的。加入客戶端傳送的資料已經發送完畢，傳送FIN=1告訴服務端，客戶端所有的資料全部發送完畢，服務端可以關閉接收了。但是如果服務端又資料要發給客戶端，客戶端照樣可以接收的。此時客戶端處於FIN=1等待服務端確認釋放連線狀態。

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

（3）第三次分手：此時服務端向客戶端把所有的資料傳送完了，然後傳送一個FIN=1，用於告訴客戶端，服務端的所有資料傳送完畢，客戶端你也可以關閉接收資料連線了。此時服務端狀態處於LAT_ACK狀態，來等待確認客戶端是否收到了自己的請求。

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

（5）為什麼要有2MSL等待延遲

對應這樣一種情況，最後客戶端傳送的ACK=1給服務端的過程丟失了，服務端沒能收到，服務端怎麼認為的？我已經發送完資料了，怎麼客戶端沒有迴應我？是不是中途丟失了？然後服務端再次發起斷開連線的請求，一個來回就是2MSL，客戶端給服務端傳送的ACK=1丟失，服務端等待1MSL沒收到，然後重新發送訊息需要1MSL。如果再次接收到服務端的訊息，則重啟2MSL計時器，傳送確認請求。客戶端只需等待2MSL，如果沒有再次收到服務端的訊息，說明服務端已經接收到自己確認訊息了，此時對方都關閉連線，TCP四次分手完畢。

（6）如果雙方建立連線，一方出問題

如果雙方建立連線，一方出問題怎麼辦？為了防止出現上述戀愛故事中的千年等一回的情況，已經建立連線，但是服務端一直等待接收，客戶端出現問題一直不能傳送。所以設計一個保活的計時器，如果一方出現問題，另一方過了這個計時器的時間，就傳送試探報文，以後每隔75秒傳送一次，若一連發送10個探測報文仍然沒有反應，服務端就認為客戶端除了故障，接著就關閉連線。

最後為大家整理的三次握手和四次揮手的整張圖：

 最後，希望各位都能找到女朋友，哈哈。

好了，今天的知識就分享到這裡