TCP三次握手、四次揮手程序及原理

TCP 協議簡述
TCP 提供面向有連接的通信傳輸，面向有連接是指在傳送資料之前必須先建立連接，資料傳送完成后要釋放連接，
無論哪一方向另一方發送資料之前，都必須先在雙方之間建立一條連接，在TCP/IP協議中，TCP協議提供可靠的連接服務，連接是通過三次握手進行初始化的，
同時由于TCP協議是一種面向連接的、可靠的、基于位元組流的運輸層通信協議，TCP是全雙工模式，所以需要四次揮手關閉連接，

TCP包首部
網路中傳輸的資料包由兩部分組成：一部分是協議所要用到的首部，另一部分是上一層傳過來的資料，首部的結構由協議的具體規范詳細定義，在資料包的首部，明確標明了協議應該如何讀取資料，反過來說，看到首部，也就能夠了解該協議必要的資訊以及所要處理的資料，包首部就像協議的臉，

所以我們在學習TCP協議之前，首先要知道TCP在網路傳輸中處于哪個位置，以及它的協議的規范，下面我們就看看TCP首部的網路傳輸起到的作用：

下面的圖是TCP頭部的規范定義，它定義了TCP協議如何讀取和決議資料：

TCP首部承載這TCP協議需要的各項資訊，下面我們來分析一下：

• TCP埠號:
  TCP的連接是需要四個要素確定唯一一個連接：
  （源IP，源埠號）+ （目地IP，目的埠號）
  所以TCP首部預留了兩個16位作為埠號的存盤，而IP地址由上一層IP協議負責傳遞
  源埠號和目地埠各占16位兩個位元組，也就是埠的范圍是2^16=65535
  另外1024以下是系統保留的，從1024-65535是用戶使用的埠范圍

• TCP的序號和確認號：
  32位序號 seq：Sequence number 縮寫seq ，TCP通信程序中某一個傳輸方向上的位元組流的每個位元組的序號，通過這個來確認發送的資料有序，比如現在序列號為1000，發送了1000，下一個序列號就是2000，
  32位確認號 ack：Acknowledge number 縮寫ack，TCP對上一次seq序號做出的確認號，用來回應TCP報文段，給收到的TCP報文段的序號seq加1，

• TCP的標志位
  每個TCP段都有一個目的，這是借助于TCP標志位選項來確定的，允許發送方或接收方指定哪些標志應該被使用，以便段被另一端正確處理，
  用的最廣泛的標志是 SYN，ACK 和 FIN，用于建立連接，確認成功的段傳輸，最后終止連接，

1. SYN：簡寫為S，同步標志位，用于建立會話連接，同步序列號；
2. ACK： 簡寫為.，確認標志位，對已接收的資料包進行確認；
3. FIN： 簡寫為F，完成標志位，表示我已經沒有資料要發送了，即將關閉連接；
4. PSH：簡寫為P，推送標志位，表示該資料包被對方接收后應立即交給上層應用，而不在緩沖區排隊；
5. RST：簡寫為R，重置標志位，用于連接復位、拒絕錯誤和非法的資料包；
6. URG：簡寫為U，緊急標志位，表示資料包的緊急指標域有效，用來保證連接不被阻斷，并督促中間設備盡快處理；

TCP 三次握手建立連接
所謂三次握手(Three-way Handshake)，是指建立一個 TCP 連接時，需要客戶端和服務器總共發送3個報文，

三次握手的目的是連接服務器指定埠，建立 TCP 連接，并同步連接雙方的序列號和確認號，交換 TCP 視窗大小資訊，在 socket 編程中，客戶端執行 connect() 時，將觸發三次握手，

三次握手程序的示意圖如下：

• 第一次握手：

• 客戶端將TCP報文標志位SYN置為1，隨機產生一個序號值seq=J，保存在TCP首部的序列號(Sequence Number)欄位里，指明客戶端打算連接的服務器的埠，并將該資料包發送給服務器端，發送完畢后，客戶端進入SYN_SENT狀態，等待服務器端確認，

• 第二次握手：

• 服務器端收到資料包后由標志位SYN=1知道客戶端請求建立連接，服務器端將TCP報文標志位SYN和ACK都置為1，ack=J+1，隨機產生一個序號值seq=K，并將該資料包發送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態，

• 第三次握手：

• 客戶端收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該資料包發送給服務器端，服務器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手，隨后客戶端與服務器端之間可以開始傳輸資料了，

注意:我們上面寫的ack和ACK，不是同一個概念：

• 小寫的ack代表的是頭部的確認號Acknowledge number， 縮寫ack，是對上一個包的序號進行確認的號，ack=seq+1，

• 大寫的ACK，則是我們上面說的TCP首部的標志位，用于標志的TCP包是否對上一個包進行了確認操作，如果確認了，則把ACK標志位設定成1，

下面我自己做實驗，開一個HTTP服務，監聽80埠，然后使用Tcpdump命令抓包，看一下TCP三次握手的程序：

1. sudo tcpdump -n -t -S -i enp0s3  port 80 


4. 第一次握手，標志位Flags=S
5. IP 10.0.2.2.51323 > 10.0.2.15.80: Flags [S], seq 84689409, win 65535, options [mss 1460], length 0
6. 第二次握手，標志位Flags=[S.]
7. IP 10.0.2.15.80 > 10.0.2.2.51323: Flags [S.], seq 1893430205, ack 84689410, win 64240, options [mss 1460], length 0
8. 第三次握手，標志位Flags=[.]
9. IP 10.0.2.2.51323 > 10.0.2.15.80: Flags [.], ack 1893430206, win 65535, length 0
10. 建立連接后，客戶端發送http請求 
11. IP 10.0.2.2.51321 > 10.0.2.15.80: Flags [P.], seq 1:753, ack 1, win 65535, length 752: HTTP: GET / HTTP/1.1

tcpdump命令決議一下：
-i : 指定抓包的網卡是enp0s3
-n: 把域名轉成IP顯示
-t: 不顯示時間
-S: 序列號使用絕對數值，不指定-S的話，序列號會使用相對的數值
port: 指定監聽埠是80
host:指定監聽的主機名

我們看下實戰中TCP的三次握手程序：

• 第一次握手，客戶端51323埠號向服務器端80號埠發起連接，此時標志位flags=S，即SYN=1標志，表示向服務端發起連接的請求，同時生成序列號seq=84689409
• 第二次握手，服務端標志位flags=[S.]，即SYN+ACK標志位設定為1，表示對上一個請求連接的報文進行確認，同時設定ack=seq+1=184689410，生成序列號seq=1893430205
• 第三次握手，客戶端對服務端的回應進行確認，所以此時標志位是[.]即ACK=1，同時回傳對上一個報文的seq的確認號，ack=1893430206

至此，三次握手完成，一個TCP連接建立完成，接下來就是雙端傳輸資料了

為什么需要三次握手？
我們假設client發出的第一個連接請求報文段并沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server，

本來這是一個早已失效的報文段，但server收到此失效的連接請求報文段后，就誤認為是client再次發出的一個新的連接請求，于是就向client發出確認報文段，同意建立連接，

假設不采用“三次握手”，那么只要server發出確認，新的連接就建立了，由于現在client并沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送資料，但server卻以為新的運輸連接已經建立，并一直等待client發來資料，這樣，server的很多資源就白白浪費掉了，

所以，采用“三次握手”的辦法可以防止上述現象發生，例如剛才那種情況，client不會向server的確認發出確認，server由于收不到確認，就知道client并沒有要求建立連接，

TCP 三次握手跟現實生活中的人與人打電話是很類似的：

三次握手：

“喂，你聽得到嗎？”
“我聽得到呀，你聽得到我嗎？”
“我能聽到你，今天 balabala……”

TCP 四次揮手關閉連接
四次揮手即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開，在socket編程中，這一程序由客戶端或服務端任一方執行close來觸發，
由于TCP連接是全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料發送任務后，發送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連接上仍然能夠發送資料，直到這一方向也發送了FIN，首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，

四次揮手程序的示意圖如下：

揮手請求可以是Client端，也可以是Server端發起的，我們假設是Client端發起：

• 第一次揮手： Client端發起揮手請求，向Server端發送標志位是FIN報文段，設定序列號seq，此時，Client端進入FIN_WAIT_1狀態，這表示Client端沒有資料要發送給Server端了，
• 第二次分手：Server端收到了Client端發送的FIN報文段，向Client端回傳一個標志位是ACK的報文段，ack設為seq加1，Client端進入FIN_WAIT_2狀態，Server端告訴Client端，我確認并同意你的關閉請求，
• 第三次分手： Server端向Client端發送標志位是FIN的報文段，請求關閉連接，同時Client端進入LAST_ACK狀態，
• 第四次分手 ： Client端收到Server端發送的FIN報文段，向Server端發送標志位是ACK的報文段，然后Client端進入TIME_WAIT狀態，Server端收到Client端的ACK報文段以后，就關閉連接，此時，Client端等待2MSL的時間后依然沒有收到回復，則證明Server端已正常關閉，那好，Client端也可以關閉連接了，

為什么連接的時候是三次握手，關閉的時候卻是四次握手？

建立連接時因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文，其中ACK報文是用來應答的，SYN報文是用來同步的，所以建立連接只需要三次握手，

由于TCP協議是一種面向連接的、可靠的、基于位元組流的運輸層通信協議，TCP是全雙工模式，
這就意味著，關閉連接時，當Client端發出FIN報文段時，只是表示Client端告訴Server端資料已經發送完畢了，當Server端收到FIN報文并回傳ACK報文段，表示它已經知道Client端沒有資料發送了，但是Server端還是可以發送資料到Client端的，所以Server很可能并不會立即關閉SOCKET，直到Server端把資料也發送完畢，
當Server端也發送了FIN報文段時，這個時候就表示Server端也沒有資料要發送了，就會告訴Client端，我也沒有資料要發送了，之后彼此就會愉快的中斷這次TCP連接，

為什么要等待2MSL？
MSL：報文段最大生存時間，它是任何報文段被丟棄前在網路內的最長時間，
有以下兩個原因：

• 第一點：保證TCP協議的全雙工連接能夠可靠關閉：
  由于IP協議的不可靠性或者是其它網路原因，導致了Server端沒有收到Client端的ACK報文，那么Server端就會在超時之后重新發送FIN，如果此時Client端的連接已經關閉處于CLOESD狀態，那么重發的FIN就找不到對應的連接了，從而導致連接錯亂，所以，Client端發送完最后的ACK不能直接進入CLOSED狀態，而要保持TIME_WAIT，當再次收到FIN的收，能夠保證對方收到ACK，最后正確關閉連接，

• 第二點：保證這次連接的重復資料段從網路中消失
  如果Client端發送最后的ACK直接進入CLOSED狀態，然后又再向Server端發起一個新連接，這時不能保證新連接的與剛關閉的連接的埠號是不同的，也就是新連接和老連接的埠號可能一樣了，那么就可能出現問題：如果前一次的連接某些資料滯留在網路中，這些延遲資料在建立新連接后到達Client端，由于新老連接的埠號和IP都一樣，TCP協議就認為延遲資料是屬于新連接的，新連接就會接收到臟資料，這樣就會導致資料包混亂，所以TCP連接需要在TIME_WAIT狀態等待2倍MSL，才能保證本次連接的所有資料在網路中消失，

本文轉自csdn碼農富哥

標籤：其他

上一篇：統計學習：線性可分支持向量機(SVM)

下一篇：【轉載】C++多執行緒類Thread（C++11）