SYN 攻擊方式最直接的表現(xiàn)就會把 TCP 半連接隊(duì)列打滿，這樣當(dāng) TCP 半連接隊(duì)列滿了，后續(xù)再在收到 SYN 報(bào)文就會丟棄，導(dǎo)致客戶端無法和服務(wù)端建立連接。

避免 SYN 攻擊方式，可以有以下四種方法：

• 調(diào)大 netdev_max_backlog；
• 增大 TCP 半連接隊(duì)列；
• 開啟 tcp_syncookies；
• 減少 SYN+ACK 重傳次數(shù)

?方式一：調(diào)大 netdev_max_backlog

當(dāng)網(wǎng)卡接收數(shù)據(jù)包的速度大于內(nèi)核處理的速度時(shí)，會有一個(gè)隊(duì)列保存這些數(shù)據(jù)包?？刂圃撽?duì)列的最大值如下參數(shù)，默認(rèn)值是 1000，我們要適當(dāng)調(diào)大該參數(shù)的值，比如設(shè)置為 10000?

方式二：增大 TCP 半連接隊(duì)列

增大 TCP 半連接隊(duì)列，要同時(shí)增大下面這三個(gè)參數(shù)：

• 增大 net.ipv4.tcp_max_syn_backlog
• 增大 listen() 函數(shù)中的 backlog
• 增大 net.core.somaxconn

具體為什么是三個(gè)參數(shù)決定 TCP 半連接隊(duì)列的大小，可以看這篇：可以看這篇：TCP 半連接隊(duì)列和全連接隊(duì)列滿了會發(fā)生什么？又該如何應(yīng)對？

方式三：開啟 net.ipv4.tcp_syncookies

開啟 syncookies 功能就可以在不使用 SYN 半連接隊(duì)列的情況下成功建立連接，相當(dāng)于繞過了 SYN 半連接來建立連接。

具體過程：

• 當(dāng) 「 SYN 隊(duì)列」?jié)M之后，后續(xù)服務(wù)端收到 SYN 包，不會丟棄，而是根據(jù)算法，計(jì)算出一個(gè)?cookie?值；
• 將 cookie 值放到第二次握手報(bào)文的「序列號」里，然后服務(wù)端回第二次握手給客戶端；
• 服務(wù)端接收到客戶端的應(yīng)答報(bào)文時(shí)，服務(wù)端會檢查這個(gè) ACK 包的合法性。如果合法，將該連接對象放入到「 Accept 隊(duì)列」。
• 最后應(yīng)用程序通過調(diào)用?accpet()?接口，從「 Accept 隊(duì)列」取出的連接。

可以看到，當(dāng)開啟了 tcp_syncookies 了，即使受到 SYN 攻擊而導(dǎo)致 SYN 隊(duì)列滿時(shí)，也能保證正常的連接成功建立。

net.ipv4.tcp_syncookies 參數(shù)主要有以下三個(gè)值：

• 0 值，表示關(guān)閉該功能；
• 1 值，表示僅當(dāng) SYN 半連接隊(duì)列放不下時(shí)，再啟用它；
• 2 值，表示無條件開啟功能；

那么在應(yīng)對 SYN 攻擊時(shí)，只需要設(shè)置為 1 即可。

?

?

方式四：減少 SYN+ACK 重傳次數(shù)

當(dāng)服務(wù)端受到 SYN 攻擊時(shí)，就會有大量處于 SYN_REVC 狀態(tài)的 TCP 連接，處于這個(gè)狀態(tài)的 TCP 會重傳 SYN+ACK ，當(dāng)重傳超過次數(shù)達(dá)到上限后，就會斷開連接。

那么針對 SYN 攻擊的場景，我們可以減少 SYN-ACK 的重傳次數(shù)，以加快處于 SYN_REVC 狀態(tài)的 TCP 連接斷開。

SYN-ACK 報(bào)文的最大重傳次數(shù)由?tcp_synack_retries內(nèi)核參數(shù)決定（默認(rèn)值是 5 次），比如將 tcp_synack_retries 減少到 2 次：

?

為什么揮手需要四次？

再來回顧下四次揮手雙方發(fā)?FIN?包的過程，就能理解為什么需要四次了。

• 關(guān)閉連接時(shí)，客戶端向服務(wù)端發(fā)送?FIN?時(shí)，僅僅表示客戶端不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)。
• 服務(wù)端收到客戶端的?FIN?報(bào)文時(shí)，先回一個(gè)?ACK?應(yīng)答報(bào)文，而服務(wù)端可能還有數(shù)據(jù)需要處理和發(fā)送，等服務(wù)端不再發(fā)送數(shù)據(jù)時(shí)，才發(fā)送?FIN?報(bào)文給客戶端來表示同意現(xiàn)在關(guān)閉連接。
• 從上面過程可知，服務(wù)端通常需要等待完成數(shù)據(jù)的發(fā)送和處理，所以服務(wù)端的?ACK?和?FIN?一般都會分開發(fā)送，因此是需要四次揮手。
• 4.1 TCP 三次握手與四次揮手面試題 | 小林coding

#第二次揮手丟失了，會發(fā)生什么？

當(dāng)服務(wù)端收到客戶端的第一次揮手后，就會先回一個(gè) ACK 確認(rèn)報(bào)文，此時(shí)服務(wù)端的連接進(jìn)入到?CLOSE_WAIT?狀態(tài)。

在前面我們也提了，ACK 報(bào)文是不會重傳的，所以如果服務(wù)端的第二次揮手丟失了，客戶端就會觸發(fā)超時(shí)重傳機(jī)制，重傳 FIN 報(bào)文，直到收到服務(wù)端的第二次揮手，或者達(dá)到最大的重傳次數(shù)。

舉個(gè)例子，假設(shè) tcp_orphan_retries 參數(shù)值為 2，當(dāng)?shù)诙螕]手一直丟失時(shí)，發(fā)生的過程如下圖：

?

對于 close 函數(shù)關(guān)閉的連接，由于無法再發(fā)送和接收數(shù)據(jù)，所以FIN_WAIT2?狀態(tài)不可以持續(xù)太久，而?tcp_fin_timeout?控制了這個(gè)狀態(tài)下連接的持續(xù)時(shí)長，默認(rèn)值是 60 秒。?

但是注意，如果主動(dòng)關(guān)閉方使用 shutdown 函數(shù)關(guān)閉連接，指定了只關(guān)閉發(fā)送方向，而接收方向并沒有關(guān)閉，那么意味著主動(dòng)關(guān)閉方還是可以接收數(shù)據(jù)的。

如果主動(dòng)關(guān)閉方一直沒收到第三次揮手，那么主動(dòng)關(guān)閉方的連接將會一直處于?FIN_WAIT2?狀態(tài)（tcp_fin_timeout?無法控制 shutdown 關(guān)閉的連接）。如下圖：

?