21-ahttpclient 與TIME_WAIT 客戶端close與服務端close 中提到了一個tcp_syncookies ，我們展開一下
1 3次握手，2個隊列
在三次握手協議中，服務器維護一個半連接隊列，該隊列為每個客戶端的SYN包開設一個條目(服務端在接收到SYN包的時候，就已經創建了request_sock結構，存儲在半連接隊列中)，該條目表明服務器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包（會進行第二次握手發送SYN＋ACK 的包加以確認）。這些條目所標識的連接在服務器處於Syn_RECV狀態，當服務器收到客戶的確認包時，刪除該條目，服務器進入ESTABLISHED狀態。
該隊列為SYN 隊列，長度為 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog) ，在機器的tcp_max_syn_backlog值在 /proc/sys/net/ipv4/tcp_max_syn_backlog下配置。
該隊列為SYN 隊列，長度為 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog) ，在機器的tcp_max_syn_backlog值在 /proc/sys/net/ipv4/tcp_max_syn_backlog下配置。
鏈接：https://www.jianshu.com/p/ff26312e67a9
2 syn flood
Client發送SYN包給Server后掛了，
3 syncookie
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 過多的問題，linux提供了幾個TCP參數：tcp_syncookies、tcp_synack_retries、tcp_max_syn_backlog、tcp_abort_on_overflow 來調整應對。
3 syncookie
Linux實現了一種稱為SYNcookie的機制，通過net.ipv4.tcp_syncookies控制，設置為1表示開啟。
簡單說SYNcookie就是將連接信息編碼在ISN(initialsequencenumber)中返回給客戶端，這時server不需要將半連接保存在隊列中，而是利用客戶端隨后發來的ACK帶回的ISN還原連接信息，以完成連接的建立，避免了半連接隊列被攻擊SYN包填滿。
對於SYN半連接隊列的大小是由（/proc/sys/net/ipv4/tcp_max_syn_backlog）這個內核參數控制的，有些內核似乎也受listen的backlog參數影響，取得是兩個值的最小值。
當這個隊列滿了，不開啟syncookies的時候，Server會丟棄新來的SYN包，而Client端在多次重發SYN包得不到響應而返回（
connection time out）錯誤。但是，當Server端開啟了syncookies=1，那么SYN半連接隊列就沒有邏輯上的最大值了，並且/proc/sys/net/ipv4/tcp_max_syn_backlog設置的值也會被忽略。
4 其他方式
1）增大SYN隊列
2）減少 服務隊Syn+ack重傳次數limit
3）syn cookie