注意！是TCP不是HTTP的3次握手與4次揮手（#...#）

引言

在開發中,時不時會聽到關於HTTP的三次握手和四次揮手，在面試中也會被問道HTTP的三次握手和四次揮手，不少開發者可能都會有這這種誤解，認爲三次握手和四次揮手都是HTTP協議的，實際上，這是錯誤的。正確的來講，三次揮手與四次握手是在TCP中進行的。

TCP中的三次握手

首先Client端發送鏈接請求報文，Server段接受鏈接後回覆ACK報文，併爲此次鏈接分配資源。Client端接收到ACK報文後也向Server段發生ACK報文，並分配資源，這樣TCP鏈接就創建了。

• seq Sequence Number是發送數據包中的第一個字節的序列號，32位。

• ack Acknowledgment Number是確認序列號，32位。

• ACK 表示Acknowledgment Number字段有意義

• PSH 表示Push功能，RST表示復位TCP鏈接

• SYN 表示SYN報文（在創建TCP鏈接的時候使用）

• FIN 表示沒有數據須要發送了（在關閉TCP鏈接的時候使用）

• Source Port是源端口，16位。

• Destination Port是目的端口，16位。

• Data Offset是數據偏移，4位，該字段的值是TCP首部（包括選項）長度除以4。 [1]

• 標誌位： 6位，URG表示Urgent Pointer字段有意義： 經過下面的圖片，咱們來詳細分析下TCP三次握手

（1）最初兩端的TCP進程都處於CLOSED關閉狀態，A（Client）主動打開鏈接，而B（Server）被動打開鏈接。（A、B關閉狀態CLOSED——B收聽狀態LISTEN——A同步已發送狀態SYN-SENT——B同步收到狀態SYN-RCVD——A、B鏈接已創建狀態ESTABLISHED）

• 第一次握手：起初兩端都處於CLOSED關閉狀態，A（Client）將標誌位SYN置爲1，隨機產生一個值seq=x，並將該數據包發送給B（Server），A（Client）進入SYN-SENT狀態，等待B（Server）確認；
• 第二次握手：B（Server）收到鏈接請求報文段後，如贊成創建鏈接，則向A（Client）發送確認，在確認報文段中（SYN=1，ACK=1，確認號ack=x+1，初始序號seq=y），B（Server）TCP服務器進程進入SYN-RCVD（同步收到）狀態；
• 第三次握手：TCP客戶進程收到B（Server）的確認後，要向B（Server）給出確認報文段（ACK=1，確認號ack=y+1，序號seq=x+1）（初始爲seq=x，第二個報文段因此要+1），ACK報文段能夠攜帶數據，不攜帶數據則不消耗序號。TCP鏈接已經創建，A進入ESTABLISHED（已創建鏈接）。
• 當B收到A的確認後，也進入ESTABLISHED狀態。

（2）總結三次握手過程：

• 第一次握手：起初兩端都處於CLOSED關閉狀態，Client將標誌位SYN置爲1，隨機產生一個值seq=x，並將該數據包發送給Server，Client進入SYN-SENT狀態，等待Server確認；
• 第二次握手：Server收到數據包後由標誌位SYN=1得知Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack=x+1，隨機產生一個值seq=y，並將該數據包發送給Client以確認鏈接請求，Server進入SYN-RCVD狀態，此時操做系統爲該TCP鏈接分配TCP緩存和變量；
• 第三次握手：Client收到確認後，檢查ack是否爲x+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=y+1，而且此時操做系統爲該TCP鏈接分配TCP緩存和變量，並將該數據包發送給Server，Server檢查ack是否爲y+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client和Server就能夠開始傳輸數據。

起初A和B都處於CLOSED狀態——B建立TCB，處於LISTEN狀態，等待A請求——A建立TCB，發送鏈接請求（SYN=1，seq=x），進入SYN-SENT狀態——B收到鏈接請求，向A發送確認（SYN=ACK=1，確認號ack=x+1，初始序號seq=y），進入SYN-RCVD狀態——A收到B的確認後，給B發出確認（ACK=1，ack=y+1，seq=x+1），A進入ESTABLISHED狀態——B收到A的確認後，進入ESTABLISHED狀態。

TCB傳輸控制塊Transmission Control Block，存儲每個鏈接中的重要信息，如TCP鏈接表，到發送和接收緩存的指針，到重傳隊列的指針，當前的發送和接收序號。

（3）爲何A還要發送一次確認呢？能夠二次握手嗎？

• **主要爲了防止已失效的鏈接請求報文段忽然又傳送到了B，於是產生錯誤。**如A發出鏈接請求，但因鏈接請求報文丟失而未收到確認，因而A再重傳一次鏈接請求。後來收到了確認，創建了鏈接。數據傳輸完畢後，就釋放了鏈接，A發出了兩個鏈接請求報文段，其中第一個丟失，第二個到達了B，可是第一個丟失的報文段只是在某些網絡結點長時間滯留了，延誤到鏈接釋放之後的某個時間纔到達B，此時B誤認爲A又發出一次新的鏈接請求，因而就向A發出確認報文段，贊成創建鏈接，不採用三次握手，只要B發出確認，就創建新的鏈接了，此時A不理睬B的確認且不發送數據，則B一致等待A發送數據，浪費資源。

（4）Server端易受到SYN攻擊？

• 服務器端的資源分配是在二次握手時分配的，而客戶端的資源是在完成三次握手時分配的，因此服務器容易受到SYN洪泛攻擊，SYN攻擊就是Client在短期內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server則回覆確認包，並等待Client確認，因爲源地址不存在，所以Server須要不斷重發直至超時，這些僞造的SYN包將長時間佔用未鏈接隊列，致使正常的SYN請求由於隊列滿而被丟棄，從而引發網絡擁塞甚至系統癱瘓。

• 防範SYN攻擊措施：下降主機的等待時間使主機儘快的釋放半鏈接的佔用，短期受到某IP的重複SYN則丟棄後續請求。

TCP中的四次揮手

二、四次揮手

（1）四次揮手的詳述

  假設Client端發起中斷鏈接請求，也就是發送FIN報文。Server端接到FIN報文後，意思是說"我Client端沒有數據要發給你了"，可是若是你還有數據沒有發送完成，則沒必要急着關閉Socket，能夠繼續發送數據。因此你先發送ACK，"告訴Client端，你的請求我收到了，可是我還沒準備好，請繼續你等個人消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端肯定數據已發送完成，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，準備好關閉鏈接了"。Client端收到FIN報文後，"就知道能夠關閉鏈接了，可是他仍是不相信網絡，怕Server端不知道要關閉，因此發送ACK後進入TIME_WAIT狀態，若是Server端沒有收到ACK則能夠重傳。「，Server端收到ACK後，"就知道能夠斷開鏈接了"。Client端等待了2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，我Client端也能夠關閉鏈接了。Ok，TCP鏈接就這樣關閉了！    經過下面的圖片，咱們來詳細分析下TCP三次握手

數據傳輸結束後，通訊的雙方均可釋放鏈接，A和B都處於ESTABLISHED狀態。（A、B鏈接創建狀態ESTABLISHED——A進入等待1狀態FIN-WAIT-1——B關閉等待狀態CLOSE-WAIT——A進入等待2狀態FIN-WAIT-2——B最後確認狀態LAST-ACK——A時間等待狀態TIME-WAIT——B、A關閉狀態CLOSED）

• A的應用進程先向其TCP發出鏈接釋放報文段（FIN=1，序號seq=u），並中止再發送數據，主動關閉TCP鏈接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。
• B收到鏈接釋放報文段後即發出確認報文段，（ACK=1，確認號ack=u+1，序號seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，A到B的鏈接釋放。
• A收到B的確認後，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的鏈接釋放報文段。
• B沒有要向A發出的數據，B發出鏈接釋放報文段（FIN=1，ACK=1，序號seq=w，確認號ack=u+1），B進入LAST-ACK（最後確認）狀態，等待A的確認。
• A收到B的鏈接釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，須要通過時間等待計時器設置的時間2MSL後，A才進入CLOSED狀態。

（2）總結四次揮手過程：

• 起初A和B處於ESTABLISHED狀態——A發出鏈接釋放報文段並處於FIN-WAIT-1狀態——B發出確認報文段且進入CLOSE-WAIT狀態——A收到確認後，進入FIN-WAIT-2狀態，等待B的鏈接釋放報文段——B沒有要向A發出的數據，B發出鏈接釋放報文段且進入LAST-ACK狀態——A發出確認報文段且進入TIME-WAIT狀態——B收到確認報文段後進入CLOSED狀態——A通過等待計時器時間2MSL後，進入CLOSED狀態。

（3）爲何A在TIME-WAIT狀態必須等待2MSL的時間？（MSL最長報文段壽命Maximum Segment Lifetime，MSL=2）

• 緣由：1）**保證A發送的最後一個ACK報文段可以到達B。**這個ACK報文段有可能丟失，使得處於LAST-ACK狀態的B收不到對已發送的FIN+ACK報文段的確認，B超時重傳FIN+ACK報文段，而A能在2MSL時間內收到這個重傳的FIN+ACK報文段，接着A重傳一次確認，從新啓動2MSL計時器，最後A和B都進入到CLOSED狀態，若A在TIME-WAIT狀態不等待一段時間，而是發送完ACK報文段後當即釋放鏈接，則沒法收到B重傳的FIN+ACK報文段，因此不會再發送一次確認報文段，則B沒法正常進入到CLOSED狀態。

• 緣由：2）防止「已失效的鏈接請求報文段」出如今本鏈接中。A在發送完最後一個ACK報文段後，再通過2MSL，就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失，使下一個新的鏈接中不會出現這種舊的鏈接請求報文段。

（4）爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？

• 由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

（5）爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

• 雖然按道理，四個報文都發送完畢，咱們能夠直接進入CLOSE狀態了，可是咱們必須假象網絡是不可靠的，有可能最後一個ACK丟失。因此TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

（6）優化，咱們能夠經過修改系統參數來優化服務器

• tcp_tw_reuse: 是否重用處於TIME_WAIT狀態的TCP連接 （設爲true）
• tcp_max_tw_buckets: 處於TIME_WAIT狀態的SOCKET最大數目 （調大，這個參數千萬不要調小了）
• tcp_fin_timeout: 處於FIN_WAIT_2的時間 （調小）