摘要：收到個讀者的問題，他在面試的時候，被搞懵了，因為面試官問了他這麼一個網絡問題。
本文分享自華為雲社群《TCP 四次揮手收到亂序的 FIN 包會如何處理？》，作者：小林coding 。
收到個讀者的問題，他在面試的時候，被搞懵了，因為面試官問了他這麼一個網絡問題：
不過這道網絡題可能是提問的讀者表述有問題，因為如果 FIN 封包比資料包先抵達用戶端，此時 FIN 封包其實是一個亂序的封包，此時用戶端的 TCP 連接配接并不會從 FIN_WAIT_2 狀态轉換到 TIME_WAIT 狀态。
是以，我們要關注到點是看「在 FIN_WAIT_2 狀态下，是如何處理收到的亂序到 FIN 封包，然後 TCP 連接配接又是什麼時候才進入到 TIME_WAIT 狀态?」。
我這裡先直接說結論：
在 FIN_WAIT_2 狀态時，如果收到亂序的 FIN 封包，那麼就被會加入到「亂序隊列」，并不會進入到 TIME_WAIT 狀态。
等再次收到前面被網絡延遲的資料包時，會判斷亂序隊列有沒有資料，然後會檢測亂序隊列中是否有可用的資料，如果能在亂序隊列中找到與目前封包的序列号保持的順序的封包，就會看該封包是否有 FIN 标志，如果發現有 FIN 标志，這時才會進入 TIME_WAIT 狀态。
我也畫了一張圖，大家可以結合着圖來了解。
TCP 源碼分析
接下來，我帶大家看看源碼，聽到要源碼分析，可能有的同學就慫了。
其實要分析我們今天這個問題，隻要懂 if else 就行了，我也會用中文來表述代碼的邏輯，是以單純看我的文字也是可以的。
這次我們重點分析的是，在 FIN_WAIT_2 狀态下，收到 FIN 封包是如何處理的。
在 Linux 核心裡，當 IP 層處理完消息後，會通過回調 tcp_v4_rcv 函數将消息轉給 TCP 層，是以這個函數就是 TCP 層收到消息的入口。
處于 FIN_WAIT_2 狀态下的用戶端，在收到服務端的封包後，最終會調用 tcp_v4_do_rcv 函數。
接下來，tcp_v4_do_rcv 方法會調用 tcp_rcv_state_process，在這裡會根據 TCP 狀态做對應的處理，這裡我們隻關注 FIN_WAIT_2 狀态。
在上面這個代碼裡，可以看到如果 shutdown 關閉了讀方向，那麼在收到對方發來的資料包，則會回複 RST 封包。
而我們這次的題目裡， shutdown 隻關閉了寫方向，是以會繼續往下調用 tcp_data_queue 函數（因為 case TCP_FIN_WAIT2 代碼塊裡并沒有 break 語句，是以會走到該函數）。
在上面的 tcp_data_queue 函數裡，如果收到的封包的序列号是我們預期的，也就是有序的話：
- 會判斷該封包有沒有 FIN 标志，如果有的話就會調用 tcp_fin 函數，這個函數負責将 FIN_WAIT_2 狀态轉換為 TIME_WAIT。
- 接着還會看亂序隊列有沒有資料，如果有的話會調用 tcp_ofo_queue 函數，這個函數負責檢查亂序隊列中是否有資料包可用，即能不能在亂序隊列找到與目前資料包保持序列号連續的資料包。
而當收到的封包的序列号不是我們預期的，也就是亂序的話，則調用 tcp_data_queue_ofo 函數，将封包加入到亂序隊列，這個隊列的資料結構是紅黑樹。
我們的題目裡，用戶端收到的 FIN 封包實際上是一個亂序的封包，是以此時并不會調用 tcp_fin 函數進行狀态轉換，而是将封包通過 tcp_data_queue_ofo 函數加入到亂序隊列。
然後當用戶端收到被網絡延遲的資料包後，此時因為該資料包的序列号是期望的，然後又因為上一次收到的亂序 FIN 封包被加入到了亂序隊列，表明亂序隊列是有資料的，于是就會調用 tcp_ofo_queue 函數。
我們來看看 tcp_ofo_queue 函數。
在上面的 tcp_ofo_queue 函數裡，在亂序隊列中找到能與目前封包的序列号保持的順序的封包後，會看該封包是否有 FIN 标志，如果有的話，就會調用 tcp_fin() 函數。
最後，我們來看看 tcp_fin 函數的處理。
可以看到，如果目前的 TCP 狀态為 TCP_FIN_WAIT2，就會發送第四次揮手 ack，然後調用 tcp_time_wait 函數，這個函數裡會将 TCP 狀态變更為 TIME_WAIT，并啟動 TIME_WAIT 的定時器。
怎麼看 TCP 源碼？
之前有不少同學問我，我是怎麼看 TCP 源碼的？
其實我看 TCP 源碼，并不是直接打開 Linux 源碼直接看，因為 Linux 源碼實在太龐大了，如果我不知道 TCP 入口函數在哪，那簡直就是大海撈針。
是以，在看 TCP 源碼，我們可以去網上搜尋下别人的源碼分析，網上已經有很多前輩幫我們分析了 TCP 源碼了，而且各個函數的調用鍊路，他們都有寫出來了。
比如，你想了解 TCP 三次握手/四次揮手的源碼實作，你就可以以「TCP 三次握手/四次揮手的源碼分析」這樣關鍵字來搜尋，大部分文章的注釋寫的還是很清晰，我最開始就按這種方式來學習 TCP 源碼的。
網上的文章一般隻會将重點的部分，很多代碼細節沒有貼出來，如果你想完整的看到函數的所有代碼，那就得看核心代碼了。
這裡推薦個看 Linux 核心代碼的線上網站：https://elixir.bootlin.com/linux/latest/source
我覺得還是挺好用的，左側各個版本的代碼都有，右上角也可以搜尋函數。
是以，我看 TCP 源碼的經驗就是，先在網上找找前輩寫的 TCP 源碼分析，然後知道整個函數的調用鍊路後，如果想具體了解某個函數的具體實作，可以在我說的那個看 Linux 核心代碼的線上網站上搜尋該函數，就可以看到完整的函數的實作。如果中途遇到看不懂的代碼，也可以将這個代碼複制到百度或者谷歌搜尋，一般也能找到别人分析的過程。
學會了看 TCP 源碼其實有助于我們分析一些異常問題，就比如今天這道網絡題目，在網上其實是搜尋不出答案的，而且我們也很難用實驗的方式來模拟。
是以要想知道答案，隻能去看源碼。
點選關注，第一時間了解華為雲新鮮技術~