麻了，被字節(jié)問懵逼了！

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

好家伙，現(xiàn)在面試都問那么細節(jié)了嗎？

不過話說回來，這個問題跟工作上也是有關(guān)系的，因為我就在工作中碰到這么奇怪的問題。

客戶端向服務(wù)端發(fā)起了連接，但是連接并沒有建立起來，通過抓包分析發(fā)現(xiàn)，服務(wù)端是收到 SYN 報文了，但是并沒有回復(fù) SYN+ACK（TCP 第二次握手），說明 SYN 報文被服務(wù)端忽略了，然后客戶端就一直在超時重傳 SYN 報文，直到達到最大的重傳次數(shù)。

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

• 開啟 tcp_tw_recycle 參數(shù)，并且在 NAT 環(huán)境下，造成 SYN 報文被丟棄

• accpet 隊列滿了，造成 SYN 報文被丟棄

坑爹的 tcp_tw_recycle

TCP 四次揮手過程中，主動斷開連接方會有一個 TIME_WAIT 的狀態(tài)，這個狀態(tài)會持續(xù) 2 MSL 后才會轉(zhuǎn)變?yōu)?CLOSED 狀態(tài)。

在 Linux ?操作系統(tǒng)下，TIME_WAIT 狀態(tài)的持續(xù)時間是 60 秒，這意味著這 60 秒內(nèi)，客戶端一直會占用著這個端口。要知道，端口資源也是有限的，一般可以開啟的端口為 32768~61000 ，也可以通過如下參數(shù)設(shè)置指定范圍：

?net.ipv4.ip_local_port_range

那么，如果如果主動斷開連接方的 TIME_WAIT 狀態(tài)過多，占滿了所有端口資源，則會導(dǎo)致無法創(chuàng)建新連接。

但是 TIME_WAIT 狀態(tài)也不是擺設(shè)作用，它的作用有兩個：

• 防止具有相同四元組的舊數(shù)據(jù)包被收到，也就是防止歷史連接中的數(shù)據(jù)，被后面的連接接受，否則就會導(dǎo)致后面的連接收到一個無效的數(shù)據(jù)，

• 保證「被動關(guān)閉連接」的一方能被正確的關(guān)閉，即保證最后的 ACK 能讓被動關(guān)閉方接收，從而幫助其正常關(guān)閉;

不過，Linux 操作系統(tǒng)提供了兩個可以系統(tǒng)參數(shù)來快速回收處于 TIME_WAIT 狀態(tài)的連接，這兩個參數(shù)都是默認關(guān)閉的：

• net.ipv4.tcp_tw_reuse，如果開啟該選項的話，客戶端（連接發(fā)起方） 在調(diào)用 connect() 函數(shù)時，內(nèi)核會隨機找一個 time_wait 狀態(tài)超過 1 秒的連接給新的連接復(fù)用，所以該選項只適用于連接發(fā)起方。

• net.ipv4.tcp_tw_recycle，如果開啟該選項的話，允許處于 TIME_WAIT 狀態(tài)的連接被快速回收；

要使得這兩個選項生效，有一個前提條件，就是要打開 TCP 時間戳，即 net.ipv4.tcp_timestamps=1（默認即為 1）。

但是，tcp_tw_recycle 在使用了 NAT 的網(wǎng)絡(luò)下是不安全的！

對于服務(wù)器來說，如果同時開啟了 recycle 和 timestamps 選項，則會開啟一種稱之為「 per-host 的 PAWS 機制」。

首先給大家說說什么是 ?PAWS 機制？

tcp_timestamps 選項開啟之后， PAWS 機制會自動開啟，它的作用是防止 TCP 包中的序列號發(fā)生繞回。

正常來說每個 TCP 包都會有自己唯一的 SEQ，出現(xiàn) TCP 數(shù)據(jù)包重傳的時候會復(fù)用 SEQ 號，這樣接收方能通過 SEQ 號來判斷數(shù)據(jù)包的唯一性，也能在重復(fù)收到某個數(shù)據(jù)包的時候判斷數(shù)據(jù)是不是重傳的。但是 TCP 這個 SEQ 號是有限的，一共 32 bit，SEQ 開始是遞增，溢出之后從 0 開始再次依次遞增。

所以當(dāng) SEQ 號出現(xiàn)溢出后單純通過 SEQ 號無法標(biāo)識數(shù)據(jù)包的唯一性，某個數(shù)據(jù)包延遲或因重發(fā)而延遲時可能導(dǎo)致連接傳遞的數(shù)據(jù)被破壞，比如：

上圖 A 數(shù)據(jù)包出現(xiàn)了重傳，并在 SEQ 號耗盡再次從 A 遞增時，第一次發(fā)的 A 數(shù)據(jù)包延遲到達了 Server，這種情況下如果沒有別的機制來保證，Server 會認為延遲到達的 A 數(shù)據(jù)包是正確的而接收，反而是將正常的第三次發(fā)的 SEQ 為 A 的數(shù)據(jù)包丟棄，造成數(shù)據(jù)傳輸錯誤。

PAWS 就是為了避免這個問題而產(chǎn)生的，在開啟 tcp_timestamps 選項情況下，一臺機器發(fā)的所有 TCP 包都會帶上發(fā)送時的時間戳，PAWS 要求連接雙方維護最近一次收到的數(shù)據(jù)包的時間戳（Recent TSval），每收到一個新數(shù)據(jù)包都會讀取數(shù)據(jù)包中的時間戳值跟 Recent TSval 值做比較，如果發(fā)現(xiàn)收到的數(shù)據(jù)包中時間戳不是遞增的，則表示該數(shù)據(jù)包是過期的，就會直接丟棄這個數(shù)據(jù)包。

對于上面圖中的例子有了 PAWS 機制就能做到在收到 Delay 到達的 A 號數(shù)據(jù)包時，識別出它是個過期的數(shù)據(jù)包而將其丟掉。

那什么是 per-host 的 PAWS 機制呢？

前面我提到，開啟了 recycle 和 timestamps 選項，就會開啟一種叫 per-host 的 PAWS 機制。

per-host 是對「對端 IP 做 PAWS 檢查」，而非對「IP + 端口」四元組做 PAWS 檢查。

但是如果客戶端網(wǎng)絡(luò)環(huán)境是用了 NAT 網(wǎng)關(guān)，那么客戶端環(huán)境的每一臺機器通過 NAT 網(wǎng)關(guān)后，都會是相同的 IP 地址，在服務(wù)端看來，就好像只是在跟一個客戶端打交道一樣，無法區(qū)分出來。

Per-host PAWS 機制利用TCP option里的 timestamp 字段的增長來判斷串?dāng)_數(shù)據(jù)，而 timestamp 是根據(jù)客戶端各自的 CPU tick 得出的值。

當(dāng)客戶端 A 通過 NAT 網(wǎng)關(guān)和服務(wù)器建立 TCP 連接，然后服務(wù)器主動關(guān)閉并且快速回收 TIME-WAIT 狀態(tài)的連接后，客戶端 B 也通過 NAT 網(wǎng)關(guān)和服務(wù)器建立 TCP 連接，注意客戶端 A ?和 客戶端 B 因為經(jīng)過相同的 NAT 網(wǎng)關(guān)，所以是用相同的 IP 地址與服務(wù)端建立 TCP 連接，如果客戶端 B 的 timestamp 比 客戶端 A 的 timestamp 小，那么由于服務(wù)端的 per-host 的 PAWS 機制的作用，服務(wù)端就會丟棄客戶端主機 B 發(fā)來的 SYN 包。

因此，tcp_tw_recycle 在使用了 NAT 的網(wǎng)絡(luò)下是存在問題的，如果它是對 TCP 四元組做 PAWS 檢查，而不是對「相同的 IP 做 PAWS 檢查」，那么就不會存在這個問題了。

網(wǎng)上很多博客都說開啟 tcp_tw_recycle 參數(shù)來優(yōu)化 TCP，我信你個鬼，糟老頭壞的很！

tcp_tw_recycle 在 Linux 4.12 版本后，直接取消了這一參數(shù)。

accpet 隊列滿了

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

• 半連接隊列，也稱 SYN 隊列；

• 全連接隊列，也稱 accepet 隊列；

服務(wù)端收到客戶端發(fā)起的 SYN 請求后，內(nèi)核會把該連接存儲到半連接隊列，并向客戶端響應(yīng) SYN+ACK，接著客戶端會返回 ACK，服務(wù)端收到第三次握手的 ACK 后，內(nèi)核會把連接從半連接隊列移除，然后創(chuàng)建新的完全的連接，并將其添加到 accept 隊列，等待進程調(diào)用 accept 函數(shù)時把連接取出來。

在服務(wù)端并發(fā)處理大量請求時，如果 TCP accpet 隊列過小，或者應(yīng)用程序調(diào)用 accept() 不及時，就會造成 accpet 隊列滿了 ，這時后續(xù)的連接就會被丟棄，這樣就會出現(xiàn)服務(wù)端請求數(shù)量上不去的現(xiàn)象。

我們可以通過 ss 命令來看 accpet 隊列大小，在「LISTEN 狀態(tài)」時，Recv-Q/Send-Q 表示的含義如下：

• Recv-Q：當(dāng)前 accpet 隊列的大小，也就是當(dāng)前已完成三次握手并等待服務(wù)端 accept() 的 TCP 連接個數(shù)；

• Send-Q：當(dāng)前 accpet 最大隊列長度，上面的輸出結(jié)果說明監(jiān)聽 8088 端口的 TCP 服務(wù)進程，accpet 隊列的最大長度為 128；

如果 Recv-Q 的大小超過 Send-Q，就說明發(fā)生了 accpet 隊列滿的情況。

要解決這個問題，我們可以：

• 調(diào)大 accpet 隊列的最大長度，調(diào)大的方式是通過調(diào)大 backlog 以及 somaxconn 參數(shù)。

• 檢查系統(tǒng)或者代碼為什么調(diào)用 accept() ?不及時；

關(guān)于 SYN 隊列和 accpet 隊列，我之前寫過一篇很詳細的文章：TCP 半連接隊列和全連接隊列滿了會發(fā)生什么？又該如何應(yīng)對？

好了，今天就分享到這里啦。

如果有大佬還知道其他場景，歡迎評論區(qū)分享一下，讓我也增加下知識哈哈。