可惡，又被小林裝到了！
大家好，我是小林。
前幾天群里有個讀者問了一個很有意思的問題。
他抓到一個抓包圖，客戶端和服務端四次揮手后，客戶端在 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 版本后，直接取消了這一參數。
通過這次的分析案例，大家是不是體驗到了「八股文」 的力量，就從一個抓包圖的現象，就能分析出是什么導致的。
怎么樣，這一波被我裝到了！
