大家好，我是小林，
收到個讀者的問題，他在面試鵝廠的時候，被搞懵了，因為面試官問了他這么一個網路問題：
不得不說，鵝廠真的很喜歡問網路問題，而且愛問例外情況下的網路問題，之前也有篇另外一個讀者面試鵝廠的網路問題：「被鵝廠面怕了！」，
不過這道鵝廠的網路題可能是提問的讀者表述有問題，因為如果 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 原始碼其實有助于我們分析一些例外問題，就比如今天這道網路題目，在網上其實是搜索不出答案的，而且我們也很難用實驗的方式來模擬，
所以要想知道答案，只能去看原始碼，
這次就說到這啦，我們下次見！
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/298089.html
標籤：其他