位元組面試：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 函式時把連接取出來，