大家好，我是小林。
之前收到個讀者的問題，對於 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 三次握手的過程。
image.png
第一次握手丟失了，會發生什麼？
當客戶端想和服務端建立 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 四次揮手的過程。
image.png
第一次揮手丟失了，會發生什麼？
當客戶端（主動關閉方）調用 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 聰明着很！