大家好，我是小林。

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

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

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

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

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

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

當(dāng)時文章給出的結(jié)論是：

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

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

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

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

分析一波內(nèi)核源碼

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

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

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

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

首先，內(nèi)核是這樣判斷的：

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

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

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

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

after 這個函數(shù)實(shí)現(xiàn)很短，我貼出來給大家看：

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

然后，我寫了個代碼來驗(yàn)證 after 函數(shù)返回的值是什么：

可以發(fā)現(xiàn)，after 函數(shù)返回的是 0 ，說明抓包圖中 SYN 報文的序列號是不合法的，所以根本就沒有進(jìn)入到 TIME_WAIT 狀態(tài)重建連接的邏輯。

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

因?yàn)楫?dāng) TIME_WAIT 狀態(tài)允許重建連接時，服務(wù)端第二次握手的初始序列號是這樣計(jì)算的 tcptw->tw_snd_nxt + 65535 + 2，其中 tw_snd_nxt 表示服務(wù)端 TIME_WAIT 狀態(tài)下最后一個發(fā)出報文的序列號。

根據(jù)抓包圖，可以得出 tw_snd_nxt 是 1082535342。

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

當(dāng)時，我也在群里說了這個結(jié)論。

被我分析出來

了經(jīng)過上面的分析，如果服務(wù)端還是處于 TIME_WAIT 狀態(tài)的話，那么收到不合法的 SYN 報文，肯定是回 RST 的，這一點(diǎn)不用懷疑。

所以，我開始考慮是不是因?yàn)榉?wù)端開啟了某些 TCP 內(nèi)核參數(shù)，導(dǎo)致 TIME_WAIT 狀態(tài)的連接被快速回收了，從而使得客戶端后面發(fā)起的 SYN 報文，可以正常建立連接。

這里先跟大家說下，有哪些 TCP 內(nèi)核參數(shù)會導(dǎo)致 TIME_WAIT 狀態(tài)被快速回收：

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

從抓包圖可以看出，服務(wù)端主動發(fā)起的 FIN 報文，所以是服務(wù)端處于 TIME_WAIT 狀態(tài)，所以 tcp_tw_reuse 這個參數(shù)不會是導(dǎo)致 TIME_WAIT 狀態(tài)被快速回收的原因，因?yàn)檫@個參數(shù)是用于連接發(fā)起方，也就是客戶端處于 TIME_WAIT 狀態(tài)，在發(fā)起連接的時候，可以復(fù)用 TIME_WAIT 狀態(tài)。

所以，排除參數(shù)一的可能性。

我當(dāng)時就懷疑是因?yàn)榉?wù)端開啟了 tcp_tw_recycle 參數(shù)，導(dǎo)致服務(wù)端的 TIME_WAIT 狀態(tài)被快速回收了，并沒有經(jīng)過完整的 2MSL (60秒)時長的 TIME_WAIT 狀態(tài)。

所以， 我就讓讀者去確認(rèn)下，服務(wù)端是否開啟了 tcp_tw_recycle 參數(shù)。

好家伙，經(jīng)過讀者的確認(rèn)后，發(fā)現(xiàn)服務(wù)端真的開啟了 tcp_tw_recycle 參數(shù)。

那么抓包圖的現(xiàn)象就可以很好解釋了，就是因?yàn)榉?wù)端開啟了 tcp_tw_recycle 這個參數(shù)，導(dǎo)致服務(wù)端的 TIME_WAIT 狀態(tài)被快速回收了，可能經(jīng)過不到幾秒，服務(wù)端就進(jìn)入到 CLOSED 狀態(tài)了。然后，17 秒后客戶端發(fā)起的相同四元組的 SYN 報文，就正常建立連接了，因?yàn)榉?wù)端并沒有處于 TIME_WAIT 狀態(tài)。

總結(jié)

最后總結(jié)下，我的分析思路。

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

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

于是，就讓讀者確認(rèn)是否開啟了 tcp_tw_recycle 參數(shù)，因?yàn)殚_啟了這個參數(shù)后，不管是服務(wù)端還是客戶端，處于 TIME_WAIT 狀態(tài)的連接，都會被快速回收，然后 TCP 連接就會進(jìn)入到 CLOSE 狀態(tài)。

最終，經(jīng)過讀者確認(rèn)后，發(fā)現(xiàn)服務(wù)端確實(shí)開啟 tcp_tw_recycle 參數(shù)。

不過，tcp_tw_recycle 狀態(tài)還是不建議大家開啟的，因?yàn)樵?NAT 的網(wǎng)絡(luò)下是不安全的，在 Linux 4.12 版本后，直接取消了這一參數(shù)。

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

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