被問懵逼了：TCP 握手沒成功怎么辦？

大家好，我是小林，

之前收到個讀者的問題，對于 TCP 三次握手和四次揮手的一些疑問：

• 第一次握手，如果客戶端發送的SYN一直都傳不到被服務器，那么客戶端是一直重發SYN到永久嗎？客戶端停止重發SYN的時機是什么？

• 第三次握手，如果服務器永遠不會收到ACK，服務器就永遠都留在 Syn-Recv 狀態了嗎？退出此狀態的時機是什么？

• 第三次揮手，如果客戶端永遠收不到 FIN,ACK，客戶端永遠停留在 Fin-Wait-2狀態了嗎？退出此狀態時機是什么時候呢？

• 第四次揮手，如果服務器永遠收不到 ACK，服務器永遠停留在 Last-Ack 狀態了嗎？退出此狀態的時機是什么呢？

• 如果客戶端 在 2SML內依舊沒收到 FIN,ACK，會關閉鏈接嗎？服務器那邊怎么辦呢，是怎么關閉鏈接的呢？

可以看到，這些問題都是關于 TCP 是如何處理這些例外場景的，我們在學 TCP 連接建立和斷開的時候，總是以為這些程序能如期完成，

可惜理想很豐滿，現實很骨感，事實預料呀，

TCP 當然不傻，對以上這些例外場景都是有做處理的，

這次就針對讀者問的這一系列問題，來詳細說說 TCP 是怎么處理這些例外的？

這些例外場景共分為兩大類，第一類是 TCP 三次握手期間的例外，第二類是 TCP 四次揮手期間的例外，

TCP 三次握手期間的例外

我們先來看看 TCP 三次握手的程序，

第一次握手丟失了，會發生什么？

當客戶端想和服務端建立 TCP 連接的時候，首先第一個發的就是 SYN 報文，然后進入到 SYN_SENT 狀態，

在這之后，如果客戶端遲遲收不到服務端的 SYN-ACK 報文（第二次握手），就會觸發超時重傳機制，

不同版本的作業系統可能超時時間不同，有的 1 秒的，也有 3 秒的，這個超時時間是寫死在內核里的，如果想要更改則需要重新編譯內核，比較麻煩，

當客戶端在 1 秒后沒收到服務端的 SYN-ACK 報文后，客戶端就會重發 SYN 報文，那到底重發幾次呢？

在 Linux 里，客戶端的 SYN 報文最大重傳次數由 tcp_syn_retries內核引數控制，這個引數是可以自定義的，默認值一般是 5，

通常，第一次超時重傳是在 1 秒后，第二次超時重傳是在 2 秒，第三次超時重傳是在 4 秒后，第四次超時重傳是在 8 秒后，第五次是在超時重傳 16 秒后，沒錯，每次超時的時間是上一次的 2 倍，

當第五次超時重傳后，會繼續等待 32 秒，如果服務端仍然沒有回應 ACK，客戶端就不再發送 SYN 包，然后斷開 TCP 連接，

所以，總耗時是 1+2+4+8+16+32=63 秒，大約 1 分鐘左右，

第二次握手丟失了，會發生什么？

當服務端收到客戶端的第一次握手后，就會回 SYN-ACK 報文給客戶端，這個就是第二次握手，此時服務端會進入 SYN_RCVD 狀態，

第二次握手的 SYN-ACK 報文其實有兩個目的 ：

• 第二次握手里的 ACK， 是對第一次握手的確認報文；
• 第二次握手里的 SYN，是服務端發起建立 TCP 連接的報文；

所以，如果第二次握手丟了，就會發送比較有意思的事情，具體會怎么樣呢？

因為第二次握手報文里是包含對客戶端的第一次握手的 ACK 確認報文，所以，如果客戶端遲遲沒有收到第二次握手，那么客戶端就覺得可能自己的 SYN 報文（第一次握手）丟失了，于是客戶端就會觸發超時重傳機制，重傳 SYN 報文，

然后，因為第二次握手中包含服務端的 SYN 報文，所以當客戶端收到后，需要給服務端發送 ACK 確認報文（第三次握手），服務端才會認為該 SYN 報文被客戶端收到了，

那么，如果第二次握手丟失了，服務端就收不到第三次握手，于是服務端這邊會觸發超時重傳機制，重傳 SYN-ACK 報文，

在 Linux 下，SYN-ACK 報文的最大重傳次數由 tcp_synack_retries內核引數決定，默認值是 5，

因此，當第二次握手丟失了，客戶端和服務端都會重傳：

• 客戶端會重傳 SYN 報文，也就是第一次握手，最大重傳次數由 tcp_syn_retries內核引數決定，；
• 服務端會重傳 SYN-AKC 報文，也就是第二次握手，最大重傳次數由 tcp_synack_retries 內核引數決定，

第三次握手丟失了，會發生什么？

客戶端收到服務端的 SYN-ACK 報文后，就會給服務端回一個 ACK 報文，也就是第三次握手，此時客戶端狀態進入到 ESTABLISH 狀態，

因為這個第三次握手的 ACK 是對第二次握手的 SYN 的確認報文，所以當第三次握手丟失了，如果服務端那一方遲遲收不到這個確認報文，就會觸發超時重傳機制，重傳 SYN-ACK 報文，直到收到第三次握手，或者達到最大重傳次數，

注意，ACK 報文是不會有重傳的，當 ACK 丟失了，就由對方重傳對應的報文，

TCP 四次揮手期間的例外

我們再來看看 TCP 四次揮手的程序，

第一次揮手丟失了，會發生什么？

當客戶端（主動關閉方）呼叫 close 函式后，就會向服務端發送 FIN 報文，試圖與服務端斷開連接，此時客戶端的連接進入到 FIN_WAIT_1 狀態，

正常情況下，如果能及時收到服務端（被動關閉方）的 ACK，則會很快變為 FIN_WAIT2 狀態，

如果第一次揮手丟失了，那么客戶端遲遲收不到被動方的 ACK 的話，也就會觸發超時重傳機制，重傳 FIN 報文，重發次數由 tcp_orphan_retries 引數控制，

當客戶端重傳 FIN 報文的次數超過 tcp_orphan_retries 后，就不再發送 FIN 報文，直接進入到 close 狀態，

第二次揮手丟失了，會發生什么？

當服務端收到客戶端的第一次揮手后，就會先回一個 ACK 確認報文，此時服務端的連接進入到 CLOSE_WAIT 狀態，

在前面我們也提了，ACK 報文是不會重傳的，所以如果服務端的第二次揮手丟失了，客戶端就會觸發超時重傳機制，重傳 FIN 報文，直到收到服務端的第二次揮手，或者達到最大的重傳次數，

這里提一下，當客戶端收到第二次揮手，也就是收到服務端發送的 ACK 報文后，客戶端就會處于 FIN_WAIT2 狀態，在這個狀態需要等服務端發送第三次揮手，也就是服務端的 FIN 報文，

對于 close 函式關閉的連接，由于無法再發送和接收資料，所以FIN_WAIT2 狀態不可以持續太久，而 tcp_fin_timeout 控制了這個狀態下連接的持續時長，默認值是 60 秒，

這意味著對于呼叫 close 關閉的連接，如果在 60 秒后還沒有收到 FIN 報文，客戶端（主動關閉方）的連接就會直接關閉，

第三次揮手丟失了，會發生什么？

當服務端（被動關閉方）收到客戶端（主動關閉方）的 FIN 報文后，內核會自動回復 ACK，同時連接處于 CLOSE_WAIT 狀態，顧名思義，它表示等待應用行程呼叫 close 函式關閉連接，

此時，內核是沒有權利替代行程關閉連接，必須由行程主動呼叫 close 函式來觸發服務端發送 FIN 報文，

服務端處于 CLOSE_WAIT 狀態時，呼叫了 close 函式，內核就會發出 FIN 報文，同時連接進入 LAST_ACK 狀態，等待客戶端回傳 ACK 來確認連接關閉，

如果遲遲收不到這個 ACK，服務端就會重發 FIN 報文，重發次數仍然由 tcp_orphan_retries 引數控制，這與客戶端重發 FIN 報文的重傳次數控制方式是一樣的，

第四次揮手丟失了，會發生什么？

當客戶端收到服務端的第三次揮手的 FIN 報文后，就會回 ACK 報文，也就是第四次揮手，此時客戶端連接進入 TIME_WAIT 狀態，

在 Linux 系統，TIME_WAIT 狀態會持續 60 秒后才會進入關閉狀態，

然后，服務端（被動關閉方）沒有收到 ACK 報文前，還是處于 LAST_ACK 狀態，

如果第四次揮手的 ACK 報文沒有到達服務端，服務端就會重發 FIN 報文，重發次數仍然由前面介紹過的 tcp_orphan_retries 引數控制，

是吧，TCP 聰明著很！