一、序
當我們聊到 TCP 協議的時候，聊的最多的就是三次握手與四次揮手，但是你有沒有想過，三次握手或者四次揮手時，如果發生異常了，是如何處理的？又是由誰處理的？
前兩天的文章聊到了 TCP 的三次握手的異常情況，今天繼續聊聊四次揮手。
TCP 作爲一個靠譜的協議，在傳輸數據的前後，需要在雙端之間建立連接，並在雙端各自維護連接的狀態。TCP 並沒有多麼神奇，在面對着多變的網絡情況，也只能通過不斷的重傳和各種算法來保證可靠性。
當數據傳輸完成，需要斷開連接的時候，TCP 會通過四次握手來完成雙端的斷連，並回收各自的資源。那麼今天就來繼續聊聊，TCP 四次揮手過程中，如果出現異常，單端跑路等問題，是如何處理的。
二、TCP 四次揮手
2.1 簡單理解四次揮手
雖然是在說四次揮手的異常情況，在此之前，我們還是先來簡單瞭解一下 TCP 的四次揮手。
當數據傳輸完成，需要斷開連接的時候，TCP 會採取四次揮手的方式，來安全的斷開連接。
爲什麼握手需要三次，而揮手需要四次呢？
本質上來說，雙端都需要經過一次「分手」的過程，來保證自己和對端的狀態正確。本着友好協商的態度，你先提出的分手，也要把最大的善意給對方，不能打了對方一個措手不及。你說不玩了就不玩了，那以後誰還敢和你玩。
下面這張圖，是比較經典的 TCP 四次揮手的消息和雙端狀態的變化。
我們解釋一下這張圖：
1. 初始時雙端還都處於 ESTABLISHED 狀態並傳輸數據，某端可以主動發起「FIN」包準備斷開連接，在這裏的場景下，是客戶端發起「FIN」請求。在發出「FIN」後，客戶端進入 FIN-WAIT-1 狀態。
2. 服務端收到「FIN」消息後，回覆「ACK」表示知道了，並從 ESTABLISHED 狀態進入 CLOSED-WAIT 狀態，開始做一些斷開連接前的準備工作。
3. 客戶端收到之前「FIN」的回覆「ACK」消息後，進入 FIN-WAIT-2 狀態。而當服務端做好斷開前的準備工作後，也會發送一個「FIN,ACK」的消息給客戶端，表示我也好了，請求斷開連接，並在發送消息後，服務端進入 LAST-ACK 狀態。
4. 客戶端在收到「FIN,ACK」消息後，會立即回覆「ACK」表示知道了，並進入 TIME_WAIT 狀態，爲了穩定和安全考慮，客戶端會在 TIME-WAIT 狀態等待 2MSL 的時長，最終進入 CLOSED 狀態。
5. 服務端收到客戶端回覆的「ACK」消息後，直接從 LAST-ACK 狀態進入 CLOSED 狀態。
正常的經過四次揮手之後，雙端都進入 CLOSED 狀態，在此之後，雙端正式斷開了連接。
2.2 TCP 揮手的異常情況
四次揮手的正常發包和應答過程，我們已經簡單瞭解了，接下來就繼續看看，四次揮手過程中，出現的異常情況。
三次握手的正常發包和應答，以及雙端的狀態扭轉我們已經講了，接下來就來看看在這三次握手的過程中，出現的異常情況。
1. 斷開連接的 FIN 包丟了。
我們前面一直強調過，如果一個包發出去，在一定時間內，只要沒有收到對端的「ACK」回覆，均認爲這個包丟了，會觸發超時重傳機制。而不會關心到底是自己發的包丟了，還是對方的「ACK」丟了。
所以在這裏，如果客戶端率先發的「FIN」包丟了，或者沒有收到對端的「ACK」回覆，則會觸發超時重傳，直到觸發重傳的次數，直接關閉連接。
對於服務端而言，如果客戶端發來的「FIN」沒有收到，就沒有任何感知。會在一段時間後，也關閉連接。
2. 服務端第一次回覆的 ACK 丟了。
此時因爲客戶端沒有收到「ACK」應答，會嘗試重傳之前的「FIN」請求，服務端收到後，又會再重傳「ACK」。
而此時服務端已經進入 CLOSED-WAIT 狀態，開始做斷開連接前的準備工作。當準備好之後，會回覆「FIN,ACK」，注意這個消息是攜帶了之前「ACK」的響應序號的。
只要這個消息沒丟，客戶端可以憑藉「FIN,ACK」包中的響應序號，直接從 FIN-WAIT-1 狀態，進入 TIME-WAIT 狀態，開始長達 2MSL 的等待。
3. 服務端發送的 FIN,ACK 丟了。
服務端在超時後會重傳，此時客戶端有兩種情況，要麼處於 FIN-WAIT-2 狀態（之前的 ACK 也丟了），會一直等待；要麼處於 TIME-WAIT 狀態，會等待 2MSL 時間。
也就是說，在之後的一小段時間內客戶端還在，客戶端在收到服務端發來的「FIN,ACK」包後，也會回覆一個「ACK」應答，並做自己的狀態切換。
4. 客戶端最後回覆的 ACK 丟了。
客戶端在回覆「ACK」後，會進入 TIME-WAIT 狀態，並開始長達 2MSL 的等待，服務端因爲沒有收到「ACK」的回覆，會重試一段時間，直到服務端重試超時後主動斷開。
或者等待新的客戶端接入後，收到服務端重試的「FIN」消息後，回覆「RST」消息，在收到「RST」消息後，復位服務端的狀態。
5. 客戶端收到 ACK 後，服務端跑路了。
客戶端在收到「ACK」後，進入了 FIN-WAIT-2 狀態，等待服務端發來的「FIN」包，而如果服務端跑路了，這個包永遠都等不到。
在 TCP 協議中，是沒有對這個狀態的處理機制的。但是協議不管，系統來湊，操作系統會接管這個狀態，例如在 Linux 下，就可以通過 tcp_fin_timeout 參數，來對這個狀態設定一個超時時間。
需要注意的是，當超過 tcp_fin_timeout 的限制後，狀態並不是切換到 TIME_WAIT，而是直接進入 CLOSED 狀態。
參考：https://blog.huoding.com/2016/09/05/542
6. 客戶端收到 ACK 後，客戶端自己跑路了。
客戶端收到「ACK」後直接跑路，服務端後續在發送的「FIN,ACK」就沒有接收端，也就不會得到回覆，會不斷的走 TCP 的超時重試的機制，此時服務端處於 LAST-ACK 狀態。
那就要分 2 種情況分析：
在超過一定時間後，服務端主動斷開。
收到「RST」後，主動斷開連接。
「RST」消息是一種重置消息，表示當前錯誤了，應該回到初始的狀態。如果客戶端跑路後有新的客戶端接入，會在此發送「SYN」以期望建立連接，此時這個「SYN」將被忽略，並直接回復「FIN,ACK」消息，新客戶端在收到「FIN」消息後是不會認的，並且會回覆一個「RST」消息。
參考：https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
三、小結時刻
今天我們聊了 TCP 在四次揮手階段出現錯誤時的一些處理策略。
大多數情況下，TCP 協議本身已經保證了可靠性，例如超時重傳，而有些時候，又需要操作系統來接管一些狀態，例如 tcp_fin_timeout 等。
關於 TCP 三次握手的異常情況，在之前的文章中所有講解，有需要可以點擊藍字閱讀。
有任何問題歡迎留言討論，有所幫助也別忘了轉發和點好看支持一下，謝謝！
公衆號後臺回覆成長『成長』，將會得到我準備的學習資料。
