大家好，我是小林。
之前收到個讀者的問題，對於 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 聰明著很！