字節面試：SYN 包在什麼場景下會被丟棄？

大家好，我是小林。

之前有個讀者在秋招面試的時候，被問了這麼一個問題：SYN 報文什麼時候情況下會被丟棄？

好傢伙，現在面試都問那麼細節了嗎？

不過話說回來，這個問題跟工作上也是有關係的，因爲我就在工作中碰到這麼奇怪的時候，客戶端向服務端發起了連接，但是連接並沒有建立起來，通過抓包分析發現，服務端是收到 SYN 報文了，但是並沒有回覆 SYN+ACK（TCP 第二次握手），說明 SYN 報文被服務端忽略了，然後客戶端就一直在超時重傳 SYN 報文，直到達到最大的重傳次數。

接下來，我就給出我遇到過 SYN 報文被丟棄的兩種場景：

開啓 tcp_tw_recycle 參數，並且在 NAT 環境下，造成 SYN 報文被丟棄
TCP 兩個隊列滿了（半連接隊列和全連接隊列），造成 SYN 報文被丟棄

坑爹的 tcp_tw_recycle

TCP 四次揮手過程中，主動斷開連接方會有一個 TIME_WAIT 的狀態，這個狀態會持續 2 MSL 後纔會轉變爲 CLOSED 狀態。

在 Linux 操作系統下，TIME_WAIT 狀態的持續時間是 60 秒，這意味着這 60 秒內，客戶端一直會佔用着這個端口。要知道，端口資源也是有限的，一般可以開啓的端口爲 32768~61000 ，也可以通過如下參數設置指定範圍：

 net.ipv4.ip_local_port_range

那麼，如果如果主動斷開連接方的 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 版本後，直接取消了這一參數。

accpet 隊列滿了

在 TCP 三次握手的時候，Linux 內核會維護兩個隊列，分別是：

半連接隊列，也稱 SYN 隊列；
全連接隊列，也稱 accepet 隊列；

服務端收到客戶端發起的 SYN 請求後，內核會把該連接存儲到半連接隊列，並向客戶端響應 SYN+ACK，接着客戶端會返回 ACK，服務端收到第三次握手的 ACK 後，內核會把連接從半連接隊列移除，然後創建新的完全的連接，並將其添加到 accept 隊列，等待進程調用 accept 函數時把連接取出來。