TCP 四次揮手，你熟了！那意外情況呢？惡意攻擊呢？單端跑路呢？
一、序
當(dāng)我們聊到 TCP 協(xié)議的時候，聊的最多的就是三次握手與四次揮手，但是你有沒有想過，三次握手或者四次揮手時，如果發(fā)生異常了，是如何處理的?又是由誰處理的?
TCP 作為一個靠譜的協(xié)議，在傳輸數(shù)據(jù)的前后，需要在雙端之間建立連接，并在雙端各自維護(hù)連接的狀態(tài)。TCP 并沒有多么神奇，在面對著多變的網(wǎng)絡(luò)情況，也只能通過不斷的重傳和各種算法來保證可靠性。
當(dāng)數(shù)據(jù)傳輸完成，需要斷開連接的時候，TCP 會通過四次握手來完成雙端的斷連，并回收各自的資源。那么今天就來繼續(xù)聊聊，TCP 四次揮手過程中，如果出現(xiàn)異常，單端跑路等問題，是如何處理的。
二、TCP 四次揮手
2.1 簡單理解四次揮手
雖然是在說四次揮手的異常情況，在此之前，我們還是先來簡單了解一下 TCP 的四次揮手。
當(dāng)數(shù)據(jù)傳輸完成，需要斷開連接的時候，TCP 會采取四次揮手的方式，來安全的斷開連接。
為什么握手需要三次，而揮手需要四次呢?
本質(zhì)上來說，雙端都需要經(jīng)過一次「分手」的過程，來保證自己和對端的狀態(tài)正確。本著友好協(xié)商的態(tài)度，你先提出的分手，也要把最大的善意給對方，不能打了對方一個措手不及。你說不玩了就不玩了，那以后誰還敢和你玩。
下面這張圖，是比較經(jīng)典的 TCP 四次揮手的消息和雙端狀態(tài)的變化。
我們解釋一下這張圖：
1. 初始時雙端還都處于 ESTABLISHED 狀態(tài)并傳輸數(shù)據(jù)，某端可以主動發(fā)起「FIN」包準(zhǔn)備斷開連接，在這里的場景下，是客戶端發(fā)起「FIN」請求。在發(fā)出「FIN」后，客戶端進(jìn)入 FIN-WAIT-1 狀態(tài)。
2. 服務(wù)端收到「FIN」消息后，回復(fù)「ACK」表示知道了，并從 ESTABLISHED 狀態(tài)進(jìn)入 CLOSED-WAIT 狀態(tài)，開始做一些斷開連接前的準(zhǔn)備工作。
3. 客戶端收到之前「FIN」的回復(fù)「ACK」消息后，進(jìn)入 FIN-WAIT-2 狀態(tài)。而當(dāng)服務(wù)端做好斷開前的準(zhǔn)備工作后，也會發(fā)送一個「FIN,ACK」的消息給客戶端，表示我也好了，請求斷開連接，并在發(fā)送消息后，服務(wù)端進(jìn)入 LAST-ACK 狀態(tài)。
4. 客戶端在收到「FIN,ACK」消息后，會立即回復(fù)「ACK」表示知道了，并進(jìn)入 TIME_WAIT 狀態(tài)，為了穩(wěn)定和安全考慮，客戶端會在 TIME-WAIT 狀態(tài)等待 2MSL 的時長，最終進(jìn)入 CLOSED 狀態(tài)。
5. 服務(wù)端收到客戶端回復(fù)的「ACK」消息后，直接從 LAST-ACK 狀態(tài)進(jìn)入 CLOSED 狀態(tài)。
正常的經(jīng)過四次揮手之后，雙端都進(jìn)入 CLOSED 狀態(tài)，在此之后，雙端正式斷開了連接。
2.2 TCP 揮手的異常情況
四次揮手的正常發(fā)包和應(yīng)答過程，我們已經(jīng)簡單了解了，接下來就繼續(xù)看看，四次揮手過程中，出現(xiàn)的異常情況。
三次握手的正常發(fā)包和應(yīng)答，以及雙端的狀態(tài)扭轉(zhuǎn)我們已經(jīng)講了，接下來就來看看在這三次握手的過程中，出現(xiàn)的異常情況。
1. 斷開連接的 FIN 包丟了。
我們前面一直強(qiáng)調(diào)過，如果一個包發(fā)出去，在一定時間內(nèi)，只要沒有收到對端的「ACK」回復(fù)，均認(rèn)為這個包丟了，會觸發(fā)超時重傳機(jī)制。而不會關(guān)心到底是自己發(fā)的包丟了，還是對方的「ACK」丟了。
所以在這里，如果客戶端率先發(fā)的「FIN」包丟了，或者沒有收到對端的「ACK」回復(fù)，則會觸發(fā)超時重傳，直到觸發(fā)重傳的次數(shù)，直接關(guān)閉連接。
對于服務(wù)端而言，如果客戶端發(fā)來的「FIN」沒有收到，就沒有任何感知。會在一段時間后，也關(guān)閉連接。
2. 服務(wù)端第一次回復(fù)的 ACK 丟了。
此時因?yàn)榭蛻舳藳]有收到「ACK」應(yīng)答，會嘗試重傳之前的「FIN」請求，服務(wù)端收到后，又會再重傳「ACK」。
而此時服務(wù)端已經(jīng)進(jìn)入 CLOSED-WAIT 狀態(tài)，開始做斷開連接前的準(zhǔn)備工作。當(dāng)準(zhǔn)備好之后，會回復(fù)「FIN,ACK」，注意這個消息是攜帶了之前「ACK」的響應(yīng)序號的。
只要這個消息沒丟，客戶端可以憑借「FIN,ACK」包中的響應(yīng)序號，直接從 FIN-WAIT-1 狀態(tài)，進(jìn)入 TIME-WAIT 狀態(tài)，開始長達(dá) 2MSL 的等待。
3. 服務(wù)端發(fā)送的 FIN,ACK 丟了。
服務(wù)端在超時后會重傳，此時客戶端有兩種情況，要么處于 FIN-WAIT-2 狀態(tài)(之前的 ACK 也丟了)，會一直等待;要么處于 TIME-WAIT 狀態(tài)，會等待 2MSL 時間。
也就是說，在之后的一小段時間內(nèi)客戶端還在，客戶端在收到服務(wù)端發(fā)來的「FIN,ACK」包后，也會回復(fù)一個「ACK」應(yīng)答，并做自己的狀態(tài)切換。
4. 客戶端最后回復(fù)的 ACK 丟了。
客戶端在回復(fù)「ACK」后，會進(jìn)入 TIME-WAIT 狀態(tài)，并開始長達(dá) 2MSL 的等待，服務(wù)端因?yàn)闆]有收到「ACK」的回復(fù)，會重試一段時間，直到服務(wù)端重試超時后主動斷開。
或者等待新的客戶端接入后，收到服務(wù)端重試的「FIN」消息后，回復(fù)「RST」消息，在收到「RST」消息后，復(fù)位服務(wù)端的狀態(tài)。
5. 客戶端收到 ACK 后，服務(wù)端跑路了。
客戶端在收到「ACK」后，進(jìn)入了 FIN-WAIT-2 狀態(tài)，等待服務(wù)端發(fā)來的「FIN」包，而如果服務(wù)端跑路了，這個包永遠(yuǎn)都等不到。
在 TCP 協(xié)議中，是沒有對這個狀態(tài)的處理機(jī)制的。但是協(xié)議不管，系統(tǒng)來湊，操作系統(tǒng)會接管這個狀態(tài)，例如在 Linux 下，就可以通過 tcp_fin_timeout 參數(shù)，來對這個狀態(tài)設(shè)定一個超時時間。
需要注意的是，當(dāng)超過 tcp_fin_timeout 的限制后，狀態(tài)并不是切換到 TIME_WAIT，而是直接進(jìn)入 CLOSED 狀態(tài)。
參考：https://blog.huoding.com/2016/09/05/542
6. 客戶端收到 ACK 后，客戶端自己跑路了。
客戶端收到「ACK」后直接跑路，服務(wù)端后續(xù)在發(fā)送的「FIN,ACK」就沒有接收端，也就不會得到回復(fù)，會不斷的走 TCP 的超時重試的機(jī)制，此時服務(wù)端處于 LAST-ACK 狀態(tài)。
那就要分 2 種情況分析：
- 在超過一定時間后，服務(wù)端主動斷開。
- 收到「RST」后，主動斷開連接。
「RST」消息是一種重置消息，表示當(dāng)前錯誤了，應(yīng)該回到初始的狀態(tài)。如果客戶端跑路后有新的客戶端接入，會在此發(fā)送「SYN」以期望建立連接，此時這個「SYN」將被忽略，并直接回復(fù)「FIN,ACK」消息，新客戶端在收到「FIN」消息后是不會認(rèn)的，并且會回復(fù)一個「RST」消息。
參考：https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
三、小結(jié)時刻
今天我們聊了 TCP 在四次揮手階段出現(xiàn)錯誤時的一些處理策略。
大多數(shù)情況下，TCP 協(xié)議本身已經(jīng)保證了可靠性，例如超時重傳，而有些時候，又需要操作系統(tǒng)來接管一些狀態(tài)，例如 tcp_fin_timeout 等。
關(guān)于 TCP 三次握手的異常情況，在之前的文章中所有講解，有需要可以點(diǎn)擊藍(lán)字閱讀。
【本文為51CTO專欄作者“張旸”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號聯(lián)系作者獲取授權(quán)】
