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