大家好，我是小林。

前幾天群里有個讀者問了一個很有意思的問題。

他抓到一個抓包圖，客戶端和服務端四次揮手后，客戶端在 17 秒內又復用了與上一次連接相同的端口，向服務端發起了 SYN 報文， 并成功建立了連接。

他覺得服務端應該還是處于 TIME_WAIT 狀態(因為 Linux 操作系統中，2MSL 的時間是 60 秒，也就是 TIME_WAIT 狀態的持續時間)，為什么收到客戶端的 SYN 報文后可以正常建立連接？

抓包圖手機端不好看，為了方便大家看，我畫了一個圖：

簡單來說，這個問題就是，為什么處于 TIME_WAIT 狀態的 TCP 連接，收到相同四元組的 SYN 報文后，可以正常建立連接。

可能有人問，這個問題小林不是寫過嗎？對的，我之前是寫過一篇：??處于 TIME_WAIT 狀態的連接，收到相同四元組的 SYN 后會發生什么？??

當時文章給出的結論是：

• 如果 SYN 報文的「序列號+時間戳」都是合法的話，就會重新建立連接;
• 如果 SYN 報文的「序列號+時間戳」其中一個不合法的話，就會回 RST。

這位讀者也看了這篇文章的，他覺得他抓包圖中客戶端的 SYN 報文的序列號是不合法的，所以應該是回 RST 才對，但是現象卻是是可以正常建立連接。

到這，我開始慌了，難道，我之前的文章寫錯了?難道處于 TIME_WAIT 狀態的連接，只要收到 SYN 報文，不管合不合法，都會重新建立連接?

我先不著急說結論，我先帶大家分析一波，從這個抓包圖的信息，分析內核有沒有走 TIME_WAIT 狀態收到 SYN 報文后，重新建立連接的邏輯。

分析一波內核源碼

在 Linux 內核中，處于 TIME_WAIT 狀態的連接，收到 SYN 報文后，有這么一個邏輯：

大概就是，如果報文是 SYN 包，時間戳+序列號都是合法的，那么就會允許在 TIME_WAIT 狀態下重新建立連接。

抓包圖中的客戶端是在 17 秒后重用端口發起 SYN 報文的，所以時間戳肯定相比于歷史連接是遞增的，所以時間戳是合法的。

接下來，我們重點分析 SYN 報文中的序列號是否合法的。

首先，內核是這樣判斷的：

//如果after函數返回 1， 則說明合法，否則不合法
after(TCP_SKB_CB(skb)->seq, tcptw->tw_rcv_nxt)

如果after函數返回 1， 則說明收到報文的序列號是合法的，否則不合法。after 函數的參數分別表示：

• TCP_SKB_CB(skb)->seq，這個是 SYN 報文的序列號；
• tcptw->tw_rcv_nxt，這個是 TIME_WAIT 狀態期望下一次收到的序列號，其實也就是第四次揮手中 ACK 報文中的 ack num 值。

根據抓包圖，我們可以得出，seq = 3145977016，tw_rcv_nxt = 40088018880。

after 這個函數實現很短，我貼出來給大家看：

static inline bool before(unsigned int  seq1, unsigned int seq2)
{
        return (int)(seq1-seq2) < 0;
 }
#define after(seq2, seq1)   before(seq1, seq2)

然后，我寫了個代碼來驗證 after 函數返回的值是什么：

可以發現，after 函數返回的是 0 ，說明抓包圖中 SYN 報文的序列號是不合法的，所以根本就沒有進入到 TIME_WAIT 狀態重建連接的邏輯。

還有一個角度可以證明，此抓包圖沒有中 TIME_WAIT 狀態重建連接的邏輯。

因為當 TIME_WAIT 狀態允許重建連接時，服務端第二次握手的初始序列號是這樣計算的 tcptw->tw_snd_nxt + 65535 + 2，其中 tw_snd_nxt 表示服務端 TIME_WAIT 狀態下最后一個發出報文的序列號。

根據抓包圖，可以得出 tw_snd_nxt 是 1082535342。

如果走了TIME_WAIT 狀態重建連接的邏輯，那么服務端的第二次握手中的序列號應該是 1082535342+ 65535 + 2，而抓包圖中顯示的服務端第二次握手的序列號為 2175872083，這兩個值并不相同，所以從這個角度，也可以證明，此抓包圖沒有中 TIME_WAIT 狀態重建連接的邏輯。

當時，我也在群里說了這個結論。

被我分析出來

了經過上面的分析，如果服務端還是處于 TIME_WAIT 狀態的話，那么收到不合法的 SYN 報文，肯定是回 RST 的，這一點不用懷疑。

所以，我開始考慮是不是因為服務端開啟了某些 TCP 內核參數，導致 TIME_WAIT 狀態的連接被快速回收了，從而使得客戶端后面發起的 SYN 報文，可以正常建立連接。

這里先跟大家說下，有哪些 TCP 內核參數會導致 TIME_WAIT 狀態被快速回收：

• 參數一：net.ipv4.tcp_tw_reuse，如果開啟該選項的話，客戶端(連接發起方) 在調用 connect() 函數時，內核會隨機找一個 TIME_WAIT 狀態超過 1 秒的連接給新的連接復用，所以該選項只適用于連接發起方。
• 參數二：net.ipv4.tcp_tw_recycle，如果開啟該選項的話，允許處于 TIME_WAIT 狀態的連接被快速回收。

從抓包圖可以看出，服務端主動發起的 FIN 報文，所以是服務端處于 TIME_WAIT 狀態，所以 tcp_tw_reuse 這個參數不會是導致 TIME_WAIT 狀態被快速回收的原因，因為這個參數是用于連接發起方，也就是客戶端處于 TIME_WAIT 狀態，在發起連接的時候，可以復用 TIME_WAIT 狀態。

所以，排除參數一的可能性。

我當時就懷疑是因為服務端開啟了 tcp_tw_recycle 參數，導致服務端的 TIME_WAIT 狀態被快速回收了，并沒有經過完整的 2MSL (60秒)時長的 TIME_WAIT 狀態。

所以， 我就讓讀者去確認下，服務端是否開啟了 tcp_tw_recycle 參數。

好家伙，經過讀者的確認后，發現服務端真的開啟了 tcp_tw_recycle 參數。

那么抓包圖的現象就可以很好解釋了，就是因為服務端開啟了 tcp_tw_recycle 這個參數，導致服務端的 TIME_WAIT 狀態被快速回收了，可能經過不到幾秒，服務端就進入到 CLOSED 狀態了。然后，17 秒后客戶端發起的相同四元組的 SYN 報文，就正常建立連接了，因為服務端并沒有處于 TIME_WAIT 狀態。

總結

最后總結下，我的分析思路。

通過抓包圖的序列號信息，確認客戶端發起的 SYN 報文的序列號是不合法的，所以如果服務端還是處于 TIME_WAIT 狀態的話， 收到這個不合法的 SYN 報文，應該是回 RST 的，而抓包圖的現象卻是正常建立了連接。所以從這個分析中，我確認了服務端的 TIME_WAIT 狀態可能是被快速回收了。

然后，想到了 Linux 兩個快速回收 TIME_WAIT 狀態的參數 tcp_tw_reuse 和 tcp_tw_recycle，其中 tcp_tw_reuse 參數是用于連接放起方，而本次的案例 TIME_WAIT 狀態是在服務端，而不是客戶端，所以可以排除這個參數的可能性。

于是，就讓讀者確認是否開啟了 tcp_tw_recycle 參數，因為開啟了這個參數后，不管是服務端還是客戶端，處于 TIME_WAIT 狀態的連接，都會被快速回收，然后 TCP 連接就會進入到 CLOSE 狀態。

最終，經過讀者確認后，發現服務端確實開啟 tcp_tw_recycle 參數。

不過，tcp_tw_recycle 狀態還是不建議大家開啟的，因為在 NAT 的網絡下是不安全的，在 Linux 4.12 版本后，直接取消了這一參數。

通過這次的分析案例，大家是不是體驗到了「八股文」 的力量，就從一個抓包圖的現象，就能分析出是什么導致的。

怎么樣，這一波被我裝到了！