大家好，我是小林。
之前有個讀者在秋招面試的時候，被問了這麼一個問題：SYN 封包什麼時候情況下會被丢棄？
好家夥，現在面試都問那麼細節了嗎？
不過話說回來，這個問題跟工作上也是有關系的，因為我就在工作中碰到這麼奇怪的時候，用戶端向服務端發起了連接配接，但是連接配接并沒有建立起來，通過抓包分析發現，服務端是收到 SYN 封包了，但是并沒有回複 SYN+ACK（TCP 第二次握手），說明 SYN 封包被服務端忽略了，然後用戶端就一直在逾時重傳 SYN 封包，直到達到最大的重傳次數。
接下來，我就給出我遇到過 SYN 封包被丢棄的兩種場景：
開啟 tcp_tw_recycle 參數，并且在 NAT 環境下，造成 SYN 封包被丢棄
TCP 兩個隊列滿了（半連接配接隊列和全連接配接隊列），造成 SYN 封包被丢棄
TCP 四次揮手過程中，主動斷開連接配接方會有一個 TIME_WAIT 的狀态，這個狀态會持續 2 MSL 後才會轉變為 CLOSED 狀态。
在 Linux 作業系統下，TIME_WAIT 狀态的持續時間是 60 秒，這意味着這 60 秒内，用戶端一直會占用着這個端口。要知道，端口資源也是有限的，一般可以開啟的端口為 32768~61000 ，也可以通過如下參數設定指定範圍：
那麼，如果如果主動斷開連接配接方的 TIME_WAIT 狀态過多，占滿了所有端口資源，則會導緻無法建立新連接配接。
但是 TIME_WAIT 狀态也不是擺設作用，它的作用有兩個：
防止具有相同四元組的舊資料包被收到，也就是防止曆史連接配接中的資料，被後面的連接配接接受，否則就會導緻後面的連接配接收到一個無效的資料，
保證「被動關閉連接配接」的一方能被正确的關閉，即保證最後的 ACK 能讓被動關閉方接收，進而幫助其正常關閉;
不過，Linux 作業系統提供了兩個可以系統參數來快速回收處于 TIME_WAIT 狀态的連接配接，這兩個參數都是預設關閉的：
net.ipv4.tcp_tw_reuse，如果開啟該選項的話，用戶端（連接配接發起方） 在調用 connect() 函數時，核心會随機找一個 time_wait 狀态超過 1 秒的連接配接給新的連接配接複用，是以該選項隻适用于連接配接發起方。
net.ipv4.tcp_tw_recycle，如果開啟該選項的話，允許處于 TIME_WAIT 狀态的連接配接被快速回收；
要使得這兩個選項生效，有一個前提條件，就是要打開 TCP 時間戳，即 net.ipv4.tcp_timestamps=1（預設即為 1)）。
tcp_tw_recycle 在使用了 NAT 的網絡下是不安全的！
對于伺服器來說，如果同時開啟了recycle 和 timestamps 選項，則會開啟一種稱之為「 per-host 的 PAWS 機制」。
首先給大家說說什麼是 PAWS 機制？
tcp_timestamps 選項開啟之後， PAWS 機制會自動開啟，它的作用是防止 TCP 包中的序列号發生繞回。
正常來說每個 TCP 包都會有自己唯一的 SEQ，出現 TCP 資料包重傳的時候會複用 SEQ 号，這樣接收方能通過 SEQ 号來判斷資料包的唯一性，也能在重複收到某個資料包的時候判斷資料是不是重傳的。但是 TCP 這個 SEQ 号是有限的，一共 32 bit，SEQ 開始是遞增，溢出之後從 0 開始再次依次遞增。
是以當 SEQ 号出現溢出後單純通過 SEQ 号無法辨別資料包的唯一性，某個資料包延遲或因重發而延遲時可能導緻連接配接傳遞的資料被破壞，比如：
上圖 A 資料包出現了重傳，并在 SEQ 号耗盡再次從 A 遞增時，第一次發的 A 資料包延遲到達了 Server，這種情況下如果沒有别的機制來保證，Server 會認為延遲到達的 A 資料包是正确的而接收，反而是将正常的第三次發的 SEQ 為 A 的資料包丢棄，造成資料傳輸錯誤。
PAWS 就是為了避免這個問題而産生的，在開啟 tcp_timestamps 選項情況下，一台機器發的所有 TCP 包都會帶上發送時的時間戳，PAWS 要求連接配接雙方維護最近一次收到的資料包的時間戳（Recent TSval），每收到一個新資料包都會讀取資料包中的時間戳值跟 Recent TSval 值做比較，如果發現收到的資料包中時間戳不是遞增的，則表示該資料包是過期的，就會直接丢棄這個資料包。
對于上面圖中的例子有了 PAWS 機制就能做到在收到 Delay 到達的 A 号資料包時，識别出它是個過期的資料包而将其丢掉。
那什麼是 per-host 的 PAWS 機制呢？
前面我提到，開啟了 recycle 和 timestamps 選項，就會開啟一種叫 per-host 的 PAWS 機制。per-host 是對「對端 IP 做 PAWS 檢查」，而非對「IP + 端口」四元組做 PAWS 檢查。
但是如果用戶端網絡環境是用了 NAT 網關，那麼用戶端環境的每一台機器通過 NAT 網關後，都會是相同的 IP 位址，在服務端看來，就好像隻是在跟一個用戶端打交道一樣，無法區分出來。
Per-host PAWS 機制利用TCP option裡的 timestamp 字段的增長來判斷串擾資料，而 timestamp 是根據用戶端各自的 CPU tick 得出的值。
當用戶端 A 通過 NAT 網關和伺服器建立 TCP 連接配接，然後伺服器主動關閉并且快速回收 TIME-WAIT 狀态的連接配接後，用戶端 B 也通過 NAT 網關和伺服器建立 TCP 連接配接，注意用戶端 A 和 用戶端 B 因為經過相同的 NAT 網關，是以是用相同的 IP 位址與服務端建立 TCP 連接配接，如果用戶端 B 的 timestamp 比 用戶端 A 的 timestamp 小，那麼由于服務端的 per-host 的 PAWS 機制的作用，服務端就會丢棄用戶端主機 B 發來的 SYN 包。
是以，tcp_tw_recycle 在使用了 NAT 的網絡下是存在問題的，如果它是對 TCP 四元組做 PAWS 檢查，而不是對「相同的 IP 做 PAWS 檢查」，那麼就不會存在這個問題了。
網上很多部落格都說開啟 tcp_tw_recycle 參數來優化 TCP，我信你個鬼，糟老頭壞的很！
tcp_tw_recycle 在 Linux 4.12 版本後，直接取消了這一參數。
在 TCP 三次握手的時候，Linux 核心會維護兩個隊列，分别是：
半連接配接隊列，也稱 SYN 隊列；
全連接配接隊列，也稱 accepet 隊列；
服務端收到用戶端發起的 SYN 請求後，核心會把該連接配接存儲到半連接配接隊列，并向用戶端響應 SYN+ACK，接着用戶端會傳回 ACK，服務端收到第三次握手的 ACK 後，核心會把連接配接從半連接配接隊列移除，然後建立新的完全的連接配接，并将其添加到 accept 隊列，等待程序調用 accept 函數時把連接配接取出來。
當伺服器造成syn攻擊，就有可能導緻 TCP 半連接配接隊列滿了，這時後面來的 syn 包都會被丢棄。
但是，如果開啟了syncookies 功能，即使半連接配接隊列滿了，也不會丢棄syn 包。
syncookies 是這麼做的：伺服器根據目前狀态計算出一個值，放在己方發出的 SYN+ACK 封包中發出，當用戶端傳回 ACK 封包時，取出該值驗證，如果合法，就認為連接配接建立成功，如下圖所示。
開啟 syncookies 功能
syncookies 參數主要有以下三個值：
0 值，表示關閉該功能；
1 值，表示僅當 SYN 半連接配接隊列放不下時，再啟用它；
2 值，表示無條件開啟功能；
那麼在應對 SYN 攻擊時，隻需要設定為 1 即可：
這裡給出幾種防禦 SYN 攻擊的方法：
增大半連接配接隊列；
開啟 tcp_syncookies 功能
減少 SYN+ACK 重傳次數
方式一：增大半連接配接隊列
要想增大半連接配接隊列，我們得知不能隻單純增大 tcp_max_syn_backlog 的值，還需一同增大 somaxconn 和 backlog，也就是增大全連接配接隊列。否則，隻單純增大 tcp_max_syn_backlog 是無效的。
增大 tcp_max_syn_backlog 和 somaxconn 的方法是修改 Linux 核心參數：
增大 backlog 的方式，每個 Web 服務都不同，比如 Nginx 增大 backlog 的方法如下：
最後，改變了如上這些參數後，要重新開機 Nginx 服務，因為半連接配接隊列和全連接配接隊列都是在 listen() 初始化的。
方式二：開啟 tcp_syncookies 功能
開啟 tcp_syncookies 功能的方式也很簡單，修改 Linux 核心參數：
方式三：減少 SYN+ACK 重傳次數
當服務端受到 SYN 攻擊時，就會有大量處于 SYN_REVC 狀态的 TCP 連接配接，處于這個狀态的 TCP 會重傳 SYN+ACK ，當重傳超過次數達到上限後，就會斷開連接配接。
那麼針對 SYN 攻擊的場景，我們可以減少 SYN+ACK 的重傳次數，以加快處于 SYN_REVC 狀态的 TCP 連接配接斷開。
在服務端并發處理大量請求時，如果 TCP accpet 隊列過小，或者應用程式調用 accept() 不及時，就會造成 accpet 隊列滿了 ，這時後續的連接配接就會被丢棄，這樣就會出現服務端請求數量上不去的現象。
我們可以通過 ss 指令來看 accpet 隊列大小，在「LISTEN 狀态」時，<code>Recv-Q/Send-Q</code> 表示的含義如下：
Recv-Q：目前 accpet 隊列的大小，也就是目前已完成三次握手并等待服務端 <code>accept()</code> 的 TCP 連接配接個數；
Send-Q：目前 accpet 最大隊列長度，上面的輸出結果說明監聽 8088 端口的 TCP 服務程序，accpet 隊列的最大長度為 128；
如果 Recv-Q 的大小超過 Send-Q，就說明發生了 accpet 隊列滿的情況。
要解決這個問題，我們可以：
調大 accpet 隊列的最大長度，調大的方式是通過調大 backlog 以及 somaxconn 參數。
檢查系統或者代碼為什麼調用 accept() 不及時；
關于 SYN 隊列和 accpet 隊列，我之前寫過一篇很詳細的文章：TCP 半連接配接隊列和全連接配接隊列滿了會發生什麼？又該如何應對？
好了，今天就分享到這裡啦。
如果有大佬還知道其他場景，歡迎評論區分享一下，讓我也增加下知識哈哈。
關注公衆号：「小林coding」 ，回複「我要學習」即可免費獲得「伺服器 Linux C/C++ 」成長路程（書籍資料 + 思維導圖）