大家好,我是小林。之前收到個(gè)讀者的問題,對于
TCP 三次握手和四次揮手的一些疑問:
- 第一次握手,如果客戶端發(fā)送的SYN一直都傳不到被服務(wù)器,那么客戶端是一直重發(fā)SYN到永久嗎?客戶端停止重發(fā)SYN的時(shí)機(jī)是什么?
- 第三次握手,如果服務(wù)器永遠(yuǎn)不會收到ACK,服務(wù)器就永遠(yuǎn)都留在 Syn-Recv 狀態(tài)了嗎?退出此狀態(tài)的時(shí)機(jī)是什么?
- 第三次揮手,如果客戶端永遠(yuǎn)收不到 FIN,ACK,客戶端永遠(yuǎn)停留在 Fin-Wait-2狀態(tài)了嗎?退出此狀態(tài)時(shí)機(jī)是什么時(shí)候呢?
- 第四次揮手,如果服務(wù)器永遠(yuǎn)收不到 ACK,服務(wù)器永遠(yuǎn)停留在 Last-Ack 狀態(tài)了嗎?退出此狀態(tài)的時(shí)機(jī)是什么呢?
- 如果客戶端 在 2SML內(nèi)依舊沒收到 FIN,ACK,會關(guān)閉鏈接嗎?服務(wù)器那邊怎么辦呢,是怎么關(guān)閉鏈接的呢?
可以看到,這些問題都是關(guān)于
TCP 是如何處理這些異常場景的,我們在學(xué) TCP 連接建立和斷開的時(shí)候,總是以為這些過程能如期完成。
可惜理想很豐滿,現(xiàn)實(shí)很骨感,事實(shí)預(yù)料呀。
TCP 當(dāng)然不傻,對以上這些異常場景都是有做處理的。這些內(nèi)容在我的「圖解網(wǎng)絡(luò) PDF」 也有說過。當(dāng)時(shí)也用做實(shí)驗(yàn)的方式帶大家看 TCP 是如何處理這些異常場景的。
如果新讀者還不知道小林的圖解網(wǎng)絡(luò) PDF,可以到我公眾號后臺回復(fù)「圖解」獲取就行。
不過,當(dāng)時(shí)這些知識分散到了多個(gè)章節(jié),這次就針對讀者問的這一系列問題,來詳細(xì)說說 TCP 是怎么處理這些異常的?這些異常場景共分為兩大類,第一類是 TCP 三次握手期間的異常,第二類是 TCP 四次揮手期間的異常。
TCP 三次握手期間的異常
我們先來看看 TCP 三次握手是怎樣的。
第一次握手丟失了,會發(fā)生什么?
當(dāng)客戶端想和服務(wù)端建立 TCP 連接的時(shí)候,首先第一個(gè)發(fā)的就是 SYN 報(bào)文,然后進(jìn)入到
SYN_SENT
狀態(tài)。在這之后,如果客戶端遲遲收不到服務(wù)端的 SYN-ACK 報(bào)文(第二次握手),就會觸發(fā)超時(shí)重傳機(jī)制。不同版本的操作系統(tǒng)可能超時(shí)時(shí)間不同,有的 1 秒的,也有 3 秒的,這個(gè)超時(shí)時(shí)間是寫死在內(nèi)核里的,如果想要更改則需要重新編譯內(nèi)核,比較麻煩。當(dāng)客戶端在 1 秒后沒收到服務(wù)端的 SYN-ACK 報(bào)文后,客戶端就會重發(fā) SYN 報(bào)文,那到底重發(fā)幾次呢?在 Linux 里,客戶端的 SYN 報(bào)文最大重傳次數(shù)由
tcp_syn_retries
內(nèi)核參數(shù)控制,這個(gè)參數(shù)是可以自定義的,默認(rèn)值一般是 5。通常,第一次超時(shí)重傳是在 1 秒后,第二次超時(shí)重傳是在 2 秒,第三次超時(shí)重傳是在 4 秒后,第四次超時(shí)重傳是在 8 秒后,第五次是在超時(shí)重傳 16 秒后。沒錯(cuò),
每次超時(shí)的時(shí)間是上一次的 2 倍。當(dāng)?shù)谖宕纬瑫r(shí)重傳后,會繼續(xù)等待 32 秒,如果服務(wù)端仍然沒有回應(yīng) ACK,客戶端就不再發(fā)送 SYN 包,然后斷開 TCP 連接。所以,總耗時(shí)是 1 2 4 8 16 32=63 秒,大約 1 分鐘左右。
第二次握手丟失了,會發(fā)生什么?
當(dāng)服務(wù)端收到客戶端的第一次握手后,就會回 SYN-ACK 報(bào)文給客戶端,這個(gè)就是第二次握手,此時(shí)服務(wù)端會進(jìn)入
SYN_RCVD
狀態(tài)。第二次握手的
SYN-ACK
報(bào)文其實(shí)有兩個(gè)目的 :
- 第二次握手里的 ACK, 是對第一次握手的確認(rèn)報(bào)文;
- 第二次握手里的 SYN,是服務(wù)端發(fā)起建立 TCP 連接的報(bào)文;
所以,如果第二次握手丟了,就會發(fā)送比較有意思的事情,具體會怎么樣呢?因?yàn)榈诙挝帐謭?bào)文里是包含對客戶端的第一次握手的 ACK 確認(rèn)報(bào)文,所以,如果客戶端遲遲沒有收到第二次握手,那么客戶端就覺得可能自己的 SYN 報(bào)文(第一次握手)丟失了,于是
客戶端就會觸發(fā)超時(shí)重傳機(jī)制,重傳 SYN 報(bào)文。然后,因?yàn)榈诙挝帐种邪?wù)端的 SYN 報(bào)文,所以當(dāng)客戶端收到后,需要給服務(wù)端發(fā)送 ACK 確認(rèn)報(bào)文(第三次握手),服務(wù)端才會認(rèn)為該 SYN 報(bào)文被客戶端收到了。那么,如果第二次握手丟失了,服務(wù)端就收不到第三次握手,于是
服務(wù)端這邊會觸發(fā)超時(shí)重傳機(jī)制,重傳 SYN-ACK 報(bào)文。在 Linux 下,SYN-ACK 報(bào)文的最大重傳次數(shù)由
tcp_synack_retries
內(nèi)核參數(shù)決定,默認(rèn)值是 5。因此,當(dāng)?shù)诙挝帐謥G失了,客戶端和服務(wù)端都會重傳:
- 客戶端會重傳 SYN 報(bào)文,也就是第一次握手,最大重傳次數(shù)由
tcp_syn_retries
內(nèi)核參數(shù)決定。; - 服務(wù)端會重傳 SYN-AKC 報(bào)文,也就是第二次握手,最大重傳次數(shù)由
tcp_synack_retries
?內(nèi)核參數(shù)決定。
第三次握手丟失了,會發(fā)生什么?
客戶端收到服務(wù)端的 SYN-ACK 報(bào)文后,就會給服務(wù)端回一個(gè) ACK 報(bào)文,也就是第三次握手,此時(shí)客戶端狀態(tài)進(jìn)入到
ESTABLISH
狀態(tài)。因?yàn)檫@個(gè)第三次握手的 ACK 是對第二次握手的 SYN 的確認(rèn)報(bào)文,所以當(dāng)?shù)谌挝帐謥G失了,如果服務(wù)端那一方遲遲收不到這個(gè)確認(rèn)報(bào)文,就會觸發(fā)超時(shí)重傳機(jī)制,重傳 SYN-ACK 報(bào)文,直到收到第三次握手,或者達(dá)到最大重傳次數(shù)。注意,
ACK 報(bào)文是不會有重傳的,當(dāng) ACK 丟失了,就由對方重傳對應(yīng)的報(bào)文。
TCP 四次揮手期間的異常
我們再來看看 TCP 四次揮手的過程。
第一次揮手丟失了,會發(fā)生什么?
當(dāng)客戶端(主動(dòng)關(guān)閉方)調(diào)用 close 函數(shù)后,就會向服務(wù)端發(fā)送 FIN 報(bào)文,試圖與服務(wù)端斷開連接,此時(shí)客戶端的連接進(jìn)入到
FIN_WAIT_1
狀態(tài)。正常情況下,如果能及時(shí)收到服務(wù)端(被動(dòng)關(guān)閉方)的 ACK,則會很快變?yōu)?
FIN_WAIT2
狀態(tài)。如果第一次揮手丟失了,那么客戶端遲遲收不到被動(dòng)方的 ACK 的話,也就會觸發(fā)超時(shí)重傳機(jī)制,重傳 FIN 報(bào)文,重發(fā)次數(shù)由
tcp_orphan_retries
參數(shù)控制。當(dāng)客戶端重傳 FIN 報(bào)文的次數(shù)超過
tcp_orphan_retries
?后,就不再發(fā)送 FIN 報(bào)文,直接進(jìn)入到
close
狀態(tài)。
第二次揮手丟失了,會發(fā)生什么?
當(dāng)服務(wù)端收到客戶端的第一次揮手后,就會先回一個(gè) ACK 確認(rèn)報(bào)文,此時(shí)服務(wù)端的連接進(jìn)入到
CLOSE_WAIT
狀態(tài)。在前面我們也提了,ACK 報(bào)文是不會重傳的,所以如果服務(wù)端的第二次揮手丟失了,客戶端就會觸發(fā)超時(shí)重傳機(jī)制,重傳 FIN 報(bào)文,直到收到服務(wù)端的第二次揮手,或者達(dá)到最大的重傳次數(shù)。這里提一下,當(dāng)客戶端收到第二次揮手,也就是收到服務(wù)端發(fā)送的 ACK 報(bào)文后,客戶端就會處于
FIN_WAIT2
狀態(tài),在這個(gè)狀態(tài)需要等服務(wù)端發(fā)送第三次揮手,也就是服務(wù)端的 FIN 報(bào)文。對于 close 函數(shù)關(guān)閉的連接,由于無法再發(fā)送和接收數(shù)據(jù),所以
FIN_WAIT2
狀態(tài)不可以持續(xù)太久,而 ?
tcp_fin_timeout
控制了這個(gè)狀態(tài)下連接的持續(xù)時(shí)長,默認(rèn)值是 60 秒。這意味著對于調(diào)用 close 關(guān)閉的連接,如果在 60 秒后還沒有收到 FIN 報(bào)文,客戶端(主動(dòng)關(guān)閉方)的連接就會直接關(guān)閉。
第三次揮手丟失了,會發(fā)生什么?
當(dāng)服務(wù)端(被動(dòng)關(guān)閉方)收到客戶端(主動(dòng)關(guān)閉方)的 FIN 報(bào)文后,內(nèi)核會自動(dòng)回復(fù) ACK,同時(shí)連接處于
CLOSE_WAIT
狀態(tài),顧名思義,它表示等待應(yīng)用進(jìn)程調(diào)用 close 函數(shù)關(guān)閉連接。此時(shí),內(nèi)核是沒有權(quán)利替代進(jìn)程關(guān)閉連接,必須由進(jìn)程主動(dòng)調(diào)用 close 函數(shù)來觸發(fā)服務(wù)端發(fā)送 FIN 報(bào)文。服務(wù)端處于 CLOSE_WAIT 狀態(tài)時(shí),調(diào)用了 close 函數(shù),內(nèi)核就會發(fā)出 FIN 報(bào)文,同時(shí)連接進(jìn)入 LAST_ACK 狀態(tài),等待客戶端返回 ACK 來確認(rèn)連接關(guān)閉。如果遲遲收不到這個(gè) ACK,服務(wù)端就會重發(fā) FIN 報(bào)文,重發(fā)次數(shù)仍然由
tcp_orphan_retrie
s 參數(shù)控制,這與客戶端重發(fā) FIN 報(bào)文的重傳次數(shù)控制方式是一樣的。
第四次揮手丟失了,會發(fā)生什么?
當(dāng)客戶端收到服務(wù)端的第三次揮手的 FIN 報(bào)文后,就會回 ACK 報(bào)文,也就是第四次揮手,此時(shí)客戶端連接進(jìn)入
TIME_WAIT
狀態(tài)。在 Linux 系統(tǒng),TIME_WAIT 狀態(tài)會持續(xù) 60 秒后才會進(jìn)入關(guān)閉狀態(tài)。然后,服務(wù)端(被動(dòng)關(guān)閉方)沒有收到 ACK 報(bào)文前,還是處于 LAST_ACK 狀態(tài)。如果第四次揮手的 ACK 報(bào)文沒有到達(dá)服務(wù)端,服務(wù)端就會重發(fā) FIN 報(bào)文,重發(fā)次數(shù)仍然由前面介紹過的
tcp_orphan_retries
參數(shù)控制。是吧,
TCP 聰明著很!