位元組面試：SYN 包在什麼場景下會被丟棄？

小林coding發表於2021-12-20

大家好，我是小林。

之前有個讀者在秋招面試的時候，被問了這麼一個問題：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 函式時把連線取出來。