這一次，徹底弄懂TCP三次握手，四次揮手

什麼是“三次握手，四次揮手”

TCP 是一種面向連線的單播協議，在傳送資料前，通訊雙方必須在彼此間建立一條連線。

所謂的“連線”，其實是客戶端和伺服器的記憶體裡儲存的一份關於對方的資訊，如 IP 地址、埠號等。

TCP 可以看成是一種位元組流，它會處理 IP 層或以下的層的丟包、重複以及錯誤問題。

在連線的建立過程中，雙方需要交換一些連線的引數。這些引數可以放在 TCP 頭部。

TCP 提供了一種可靠、面向連線、位元組流、傳輸層的服務，採用三次握手建立一個連線。採用四次揮手來關閉一個連線。

TCP 服務模型

在瞭解了建立連線、關閉連線的“三次握手和四次揮手”後，我們再來看下 TCP 相關的東西。

一個 TCP 連線由一個 4 元組構成，分別是兩個 IP 地址和兩個埠號。一個 TCP 連線通常分為三個階段：啟動、資料傳輸、退出(關閉)。

當 TCP 接收到另一端的資料時，它會傳送一個確認，但這個確認不會立即傳送，一般會延遲一會兒。

ACK 是累積的，一個確認位元組號 N 的 ACK 表示所有直到 N 的位元組(不包括 N)已經成功被接收了。

這樣的好處是如果一個 ACK 丟失，很可能後續的 ACK 就足以確認前面的報文段了。

一個完整的 TCP 連線是雙向和對稱的，資料可以在兩個方向上平等地流動，給上層應用程式提供一種雙工服務。

一旦建立了一個連線，這個連線的一個方向上的每個 TCP 報文段都包含了相反方向上的報文段的一個 ACK。

序列號的作用是使得一個 TCP 接收端可丟棄重複的報文段，記錄以雜亂次序到達的報文段。

因為 TCP 使用 IP 來傳輸報文段，而 IP 不提供重複消除或者保證次序正確的功能。

另一方面，TCP 是一個位元組流協議，絕不會以雜亂的次序給上層程式傳送資料。

因此 TCP 接收端會被迫先保持大序列號的資料不交給應用程式，直到缺失的小序列號的報文段被填滿。

TCP 頭部

源埠和目的埠在 TCP 層確定雙方程式，序列號表示的是報文段資料中的第一個位元組號，ACK 表示確認號。

該確認號的傳送方期待接收的下一個序列號，即最後被成功接收的資料位元組序列號加 1，這個欄位只有在 ACK 位被啟用的時候才有效。

當新建一個連線時，從客戶端傳送到服務端的第一個報文段的 SYN 位被啟用，這稱為 SYN 報文段。

這時序列號欄位包含了在本次連線的這個方向上要使用的第一個序列號，即初始序列號 ISN，之後傳送的資料是 ISN 加 1。

因此 SYN 位欄位會消耗一個序列號。這意味著使用重傳進行可靠傳輸，而不消耗序列號的 ACK 則不是。

頭部長度(圖中的資料偏移)以 32 位字為單位，也就是以 4bytes 為單位，它只有 4 位，最大為 15，因此頭部最大長度為 60 位元組，而其最小為 5，也就是頭部最小為 20 位元組(可變選項為空)。

• ACK —— 確認，使得確認號有效。
• RST —— 重置連線(經常看到的 reset by peer)就是此欄位搞的鬼。
• SYN —— 用於初如化一個連線的序列號。
• FIN —— 該報文段的傳送方已經結束向對方傳送資料。

當一個連線被建立或被終止時，交換的報文段只包含 TCP 頭部，而沒有資料。

狀態轉換

三次握手和四次揮手的狀態轉換如下圖：

為什麼要“三次握手，四次揮手”

三次握手

換個易於理解的視角來看為什麼要三次握手。

客戶端和服務端通訊前要進行連線，“三次握手”的作用就是雙方都能明確自己和對方的收、發能力是正常的。

第一次握手：客戶端傳送網路包，服務端收到了。這樣服務端就能得出結論：客戶端的傳送能力、服務端的接收能力是正常的。

第二次握手：服務端發包，客戶端收到了。這樣客戶端就能得出結論：服務端的接收、傳送能力，客戶端的接收、傳送能力是正常的。

從客戶端的視角來看，我接到了服務端傳送過來的響應資料包，說明服務端接收到了我在第一次握手時傳送的網路包，並且成功傳送了響應資料包，這就說明，服務端的接收、傳送能力正常。

而另一方面，我收到了服務端的響應資料包，說明我第一次傳送的網路包成功到達服務端，這樣，我自己的傳送和接收能力也是正常的。

第三次握手：客戶端發包，服務端收到了。這樣服務端就能得出結論：客戶端的接收、傳送能力，服務端的傳送、接收能力是正常的。

第一、二次握手後，服務端並不知道客戶端的接收能力以及自己的傳送能力是否正常。

而在第三次握手時，服務端收到了客戶端對第二次握手作的迴應。從服務端的角度，我在第二次握手時的響應資料傳送出去了，客戶端接收到了。所以，我的傳送能力是正常的。而客戶端的接收能力也是正常的。

經歷了上面的三次握手過程，客戶端和服務端都確認了自己的接收、傳送能力是正常的。之後就可以正常通訊了。

每次都是接收到資料包的一方可以得到一些結論，傳送的一方其實沒有任何頭緒。

我雖然有發包的動作，但是我怎麼知道我有沒有發出去，而對方有沒有接收到呢?

而從上面的過程可以看到，最少是需要三次握手過程的。兩次達不到讓雙方都得出自己、對方的接收、傳送能力都正常的結論。

其實每次收到網路包的一方至少是可以得到：對方的傳送、我方的接收是正常的。

而每一步都是有關聯的，下一次的“響應”是由於第一次的“請求”觸發，因此每次握手其實是可以得到額外的結論的。

比如第三次握手時，服務端收到資料包，表明看服務端只能得到客戶端的傳送能力、服務端的接收能力是正常的。

但是結合第二次，說明服務端在第二次傳送的響應包，客戶端接收到了，並且作出了響應，從而得到額外的結論：客戶端的接收、服務端的傳送是正常的。

用表格總結一下：

四次揮手

TCP 連線是雙向傳輸的對等的模式，就是說雙方都可以同時向對方傳送或接收資料。

當有一方要關閉連線時，會傳送指令告知對方，我要關閉連線了。這時對方會回一個 ACK，此時一個方向的連線關閉。

但是另一個方向仍然可以繼續傳輸資料，等到傳送完了所有的資料後，會傳送一個 FIN 段來關閉此方向上的連線。接收方傳送 ACK 確認關閉連線。

注意，接收到 FIN 報文的一方只能回覆一個 ACK, 它是無法馬上返回對方一個 FIN 報文段的，因為結束資料傳輸的“指令”是上層應用層給出的，我只是一個“搬運工”，我無法瞭解“上層的意志”。

“三次握手，四次揮手”怎麼完成?

其實三次握手的目的並不只是讓通訊雙方都瞭解到一個連線正在建立，還在於利用資料包的選項來傳輸特殊的資訊，交換初始序列號 ISN。

三次握手是指傳送了 3 個報文段，四次揮手是指傳送了 4 個報文段。注意，SYN 和 FIN 段都是會利用重傳進行可靠傳輸的。

三次握手原理：

• 客戶端傳送一個 SYN 段，並指明客戶端的初始序列號，即 ISN(c)。
• 服務端傳送自己的 SYN 段作為應答，同樣指明自己的 ISN(s)。為了確認客戶端的 SYN，將 ISN(c)+1 作為 ACK 數值。這樣，每傳送一個 SYN，序列號就會加 1，如果有丟失的情況，則會重傳。
• 為了確認伺服器端的 SYN，客戶端將 ISN(s)+1 作為返回的 ACK 數值。

四次揮手原理：

• 客戶端傳送一個 FIN 段，幷包含一個希望接收者看到的自己當前的序列號 K。同時還包含一個 ACK 表示確認對方最近一次發過來的資料。
• 服務端將 K 值加 1 作為 ACK 序號值，表明收到了上一個包。這時上層的應用程式會被告知另一端發起了關閉操作，通常這將引起應用程式發起自己的關閉操作。
• 服務端發起自己的 FIN 段，ACK=K+1, Seq=L。
• 客戶端確認。ACK=L+1

為什麼建立連線是三次握手，而關閉連線卻是四次揮手呢?這是因為服務端在 LISTEN 狀態下，收到建立連線請求的 SYN 報文後，把 ACK 和 SYN 放在一個報文裡傳送給客戶端。

而關閉連線時，當收到對方的 FIN 報文時，僅僅表示對方不再傳送資料了但是還能接收資料，己方是否現在關閉傳送資料通道，需要上層應用來決定，因此，己方 ACK 和 FIN 一般都會分開傳送。

“三次握手，四次揮手”進階

ISN

三次握手的一個重要功能是客戶端和服務端交換 ISN(Initial Sequence Number), 以便讓對方知道接下來接收資料的時候如何按序列號組裝資料。

如果 ISN 是固定的，攻擊者很容易猜出後續的確認號：

ISN = M + F(localhost, localport, remotehost, remoteport) 複製程式碼

M 是一個計時器，每隔 4 毫秒加 1。F 是一個 Hash 演算法，根據源 IP、目的 IP、源埠、目的埠生成一個隨機數值。要保證 Hash 演算法不能被外部輕易推算得出。

序列號迴繞

因為 ISN 是隨機的，所以序列號容易就會超過 2^31-1。而 TCP 對於丟包和亂序等問題的判斷都是依賴於序列號大小比較的。

此時就出現了所謂的 TCP 序列號迴繞(sequence wraparound)問題怎麼解決?

/* 
* The next routines deal with comparing 32 bit unsigned ints 
* and worry about wraparound (automatic with unsigned arithmetic). 
*/ 
static inline int before(__u32 seq1, __u32 seq2){ 
    return (__s32)(seq1-seq2) < 0; 
} 

#define after(seq2, seq1) before(seq1, seq2) 複製程式碼

上述程式碼是核心中的解決迴繞問題程式碼。__s32 是有符號整型的意思，而 __u32 則是無符號整型。

序列號發生迴繞後，序列號變小，相減之後，把結果變成有符號數了，因此結果成了負數。

假設seq1=255， seq2=1（發生了迴繞）。 
seq1 = 1111 1111 seq2 = 0000 0001 
我們希望比較結果是 
seq1 - seq2= 
1111 1111 
-0000 0001 
----------- 
1111 1110 
 
由於我們將結果轉化成了有符號數，由於最高位是1，因此結果是一個負數，負數的絕對值為 
0000 0001 + 1 = 0000 0010 = 2 
 
因此seq1 - seq2 < 0 複製程式碼

檢視是否有連線溢位 
netstat -s | grep LISTEN 複製程式碼

[root@server ~]#  netstat -s | egrep "listen|LISTEN" 
667399 times the listen queue of a socket overflowed 
667399 SYNs to LISTEN sockets ignored 複製程式碼

上面看到的 667399 times ，表示全連線佇列溢位的次數，隔幾秒鐘執行下，如果這個數字一直在增加的話肯定全連線佇列偶爾滿了。

檢視 Accept queue 是否有溢位：

[root@server ~]#  netstat -s | grep TCPBacklogDrop 複製程式碼