TCP三次握手和四次揮手

• 序列號seq： 佔4個字節，用來標記數據段的順序，TCP把連接中發送的所有數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號後，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。

• 確認號ack： 佔4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是期望接收到下一個字節的編號；因此當前報文段最後一個字節的編號+1即爲確認號。

• 確認ACK： 佔1位，僅當ACK=1時，確認號字段纔有效。ACK=0時，確認號無效

• 同步SYN： 連接建立時用於同步序號。當SYN=1，ACK=0時表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個連接請求，或連接接受報文。SYN這個標誌位只有在TCP建產連接時纔會被置1，握手完成後SYN標誌位被置0。

• 終止FIN： 用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接

• 補充： ACK、SYN和FIN這些大寫的單詞表示標誌位，其值要麼是1，要麼是0；ack、seq小寫的單詞表示序號。

三次握手過程與作用

剛開始客戶端處於CLOSE的狀態，服務端處於LISTEN狀態。
第一次握手：

• 建立連接時，客戶端發送SYN包（同時隨機生成初始序列號seq=x，並進入SYN_SENT狀態，等待服務器確認。
• TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但需要消耗掉一個序號。這個三次握手中的開始。表示客戶端想要和服務端建立連接。

第二次握手：

• 服務器收到SYN包，發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲自己隨機初始化一個序列號 seq=y，此時服務器進入SYN_RECV狀態。
• 這個報文也不能攜帶數據，但是同樣要消耗一個序號。這個報文帶有SYN(建立連接)和ACK(確認)標誌，詢問客戶端是否準備好。

第三次握手：

• 客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態。

• 第三次的ACK報文段可以攜帶數據，但是如果不攜帶數據則不消耗序號。這裏客戶端表示我已經準備好。
  

三次握手的作用

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

面試常見問題：

①（ISN）是固定的嗎？

• 三次握手的一個重要功能是客戶端和服務端交換ISN(Initial Sequence Number), 以便讓對方知道接下來接收數據的時候如何按序列號組裝數據。
• 如果ISN是固定的，攻擊者很容易猜出後續的確認號，因此 ISN 是動態生成的。

②什麼是半連接隊列？

• 服務器第一次收到客戶端的 SYN 之後，就會處於 SYN_RCVD 狀態，此時雙方還沒有完全建立其連接，服務器會把此種狀態下請求連接放在一個隊列裏，我們把這種隊列稱之爲半連接隊列。當然還有一個全連接隊列，就是已經完成三次握手，建立起連接的就會放在全連接隊列中。如果隊列滿了就有可能會出現丟包現象。
• 補充一點關於SYN-ACK 重傳次數的問題：　服務器發送完SYN－ACK包，如果未收到客戶確認包，服務器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超 過系統規定的最大重傳次數，系統將該連接信息從半連接隊列中刪除。注意，每次重傳等待的時間不一定相同，一般會是指數增長，例如間隔時間爲 1s, 2s, 4s, 8s, ….

③三次握手過程中可以攜帶數據嗎？

• 很多人可能會認爲三次握手都不能攜帶數據，其實第三次握手的時候，是可以攜帶數據的。也就是說，第一次、第二次握手不可以攜帶數據，而第三次握手是可以攜帶數據的。

• 假如第一次握手可以攜帶數據的話，如果有人要惡意攻擊服務器，那他每次都在第一次握手中的 SYN 報文中放入大量的數據，因爲攻擊者根本就不理服務器的接收、發送能力是否正常，然後瘋狂着重複發 SYN 報文的話，這會讓服務器花費很多時間、內存空間來接收這些報文。也就是說，第一次握手可以放數據的話，其中一個簡單的原因就是會讓服務器更加容易受到攻擊了。

• 而對於第三次的話，此時客戶端已經處於 established 狀態，也就是說，對於客戶端來說，他已經建立起連接了，並且也已經知道服務器的接收、發送能力是正常的了，所以能攜帶數據頁沒啥毛病。

④爲什麼要三次握手呢？有人說兩次握手就好了

• 舉例：已失效的連接請求報文段。

• 客戶端發送了第一個連接的請求報文，但是由於網絡不好，這個請求沒有立即到達服務端，而是在某個網絡節點中滯留了，直到某個時間纔到達server，本來這已經是一個失效的報文，但是server端接收到這個請求報文後，還是會想client發出確認的報文，表示同意連接。假如不採用三次握手，那麼只要server發出確認，新的建立就連接了，但其實這個請求是失效的請求，client是不會理睬server的確認信息，也不會向服務端發送確認的請求，但是server認爲新的連接已經建立起來了，並一直等待client發來數據，這樣，server的很多資源就沒白白浪費掉了，採用三次握手就是爲了防止這種情況的發生server會因爲收不到確認的報文，就知道client並沒有建立連接。這就是三次握手的作用。

四次揮手過程詳解

第一次揮手：

• TCP發送一個FIN(結束)，用來關閉客戶到服務端的連接。客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。
• TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。

第二次揮手

• ​ 服務端收到這個FIN，他發回一個ACK報文 確認收到序號爲收到序號+1，和SYN一樣，一個FIN將佔用一個序號。​ 服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。
• TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。

第三次揮手：

• ​ 服務端發送一個**FIN(結束)**到客戶端，服務端關閉客戶端的連接。服務器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。

第四次揮手：

• ​ 客戶端發送ACK 報文確認，並將確認的序號+1，這樣關閉完成。​ 客戶端收到服務器的連接釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
• 服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
  

面試常問：

①爲什麼是4次揮手呢？

• 爲了確保數據能夠完成傳輸。關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這裏的ACK報文和FIN報文多數情況下都是分開發送的。

②tcp握手的時候爲何ACK(確認)和SYN(建立連接)是一起發送。揮手的時候爲什麼是分開的時候發送呢？

• 因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉 SOCKET，所以只能先回復一個ACK報文，告訴Client端，“你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。

③客戶端突然掛掉了怎麼辦？

• 正常連接時，客戶端突然掛掉了，如果沒有措施處理這種情況，那麼就會出現客戶端和服務器端出現長時期的空閒。解決辦法是在服務器端設置保活計時器，每當服務器收到客戶端的消息，就將計時器復位。超時時間通常設置爲2小時。若服務器超過2小時沒收到客戶的信息，他就發送探測報文段。若發送了10個探測報文段，每一個相隔75秒，還沒有響應就認爲客戶端出了故障，因而終止該連接。

SYN洪水攻擊

背景：

• 初始化連接的 SYN 超時問題Client發送SYN包給Server後掛了，Server回給Client的SYN-ACK一直沒收到Client的ACK確認，這個時候這個連接既沒建立起來，也不能算失敗。這就需要一個超時時間讓Server將這個連接斷開，否則這個連接就會一直佔用Server的SYN連接隊列中的一個位置，大量這樣的連接就會將Server的SYN連接隊列耗盡。

讓正常的連接無法得到處理。

• ​ 目前，Linux下默認會進行5次重發SYN-ACK包，重試的間隔時間從1s開始，下次的重試間隔時間是前一次的雙倍，5次的重試時間間隔爲1s, 2s, 4s, 8s, 16s，總共31s，第5次發出後還要等32s都知道第5次也超時了，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s，TCP纔會把斷開這個連接。由於，SYN超時需要63秒，那麼就給攻擊者一個攻擊服務器的機會，攻擊者在短時間內發送大量的SYN包給Server(俗稱SYN flood攻擊)，用於耗盡Server的SYN隊列。

什麼是 SYN 攻擊？

• SYN 攻擊指的是，攻擊客戶端在短時間內僞造大量不存在的IP地址，向服務器不斷地發送SYN包，服務器回覆確認包，並等待客戶的確認。由於源地址是不存在的，服務器需要不斷的重發直至超時，這些僞造的SYN包將長時間佔用未連接隊列，正常的SYN請求被丟棄，導致目標系統運行緩慢，嚴重者會引起網絡堵塞甚至系統癱瘓。SYN 攻擊是一種典型的 DoS攻擊。

如何檢測 SYN 攻擊？

• 檢測 SYN 攻擊非常的方便，當你在服務器上看到大量的半連接狀態時，特別是源IP地址是隨機的，基本上可以斷定這是一次SYN攻擊。在 Linux/Unix 上可以使用系統自帶的netstats 命令來檢測 SYN 攻擊。

如何防禦 SYN 攻擊？

• ​ SYN攻擊不能完全被阻止，除非將TCP協議重新設計。我們所做的是儘可能的減輕SYN攻擊的危害，常見的防禦 SYN 攻擊的方法有如下幾種：
  ①縮短超時（SYN Timeout）
  ②時間增加最大半連接數
  ③過濾網關防護SYN
  ④cookies技術