TCP 三次握手丟包情況

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

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

在這之後，如果客戶端遲遲收不到服務端的SYN-ACK 報文（第二次握手），就會觸發「超時重傳」機制，重傳SYN 報文，而且重傳的SYN 報文的序列號都是一樣的。

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

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

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

# cat /proc/sys/net/ipv4/tcp_syn_retries
5
1.
2.

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

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

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

舉個例子，假設tcp_syn_retries 參數值為3，那麼當客戶端的SYN 報文一直在網絡中丟失時，會發生下圖的過程：

具體過程：

• 當客戶端超時重傳3 次SYN 報文後，由於 tcp_syn_retries 為3，已達到最大重傳次數，於是再等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到服務端的第二次握手（SYN-ACK 報文），那麼客戶端就會斷開連接。

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

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

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

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

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

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

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

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

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

# cat /proc/sys/net/ipv4/tcp_synack_retries
5
1.
2.

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

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

舉個例子，假設tcp_syn_retries 參數值為1，tcp_synack_retries 參數值為2，那麼當第二次握手一直丟失時，發生的過程如下圖：

具體過程：

• 當客戶端超時重傳1 次SYN 報文後，由於 tcp_syn_retries 為1，已達到最大重傳次數，於是再等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到服務端的第二次握手（SYN-ACK 報文），那麼客戶端就會斷開連接。
• 當服務端超時重傳2 次SYN-ACK 報文後，由於tcp_synack_retries 為2，已達到最大重傳次數，於是再等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到客戶端的第三次握手（ACK 報文），那麼服務端就會斷開連接。

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

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

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

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

舉個例子，假設tcp_synack_retries 參數值為2，那麼當第三次握手一直丟失時，發生的過程如下圖：

具體過程：

• 當服務端超時重傳2 次SYN-ACK 報文後，由於tcp_synack_retries 為2，已達到最大重傳次數，於是再等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到客戶端的第三次握手（ACK 報文），那麼服務端就會斷開連接。

TCP 四次揮手丟包情況

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

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

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

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

當客戶端重傳FIN 報文的次數超過 tcp_orphan_retries​ 後，就不再發送FIN 報文，則會在等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到第二次揮手，那麼直接進入到 close 狀態。

舉個例子，假設tcp_orphan_retries 參數值為3，當第一次揮手一直丟失時，發生的過程如下圖：

具體過程：

當客戶端超時重傳3 次FIN 報文後，由於tcp_orphan_retries 為3，已達到最大重傳次數，於是再等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到服務端的第二次揮手（ACK報文），那麼客戶端就會斷開連接。

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

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

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

舉個例子，假設tcp_orphan_retries 參數值為2，當第二次揮手一直丟失時，發生的過程如下圖：

具體過程：

• 當客戶端超時重傳2 次FIN 報文後，由於tcp_orphan_retries 為2，已達到最大重傳次數，於是再等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到服務端的第二次揮手（ACK 報文），那麼客戶端就會斷開連接。

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

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

這意味著對於調用close 關閉的連接，如果在60 秒後還沒有收到FIN 報文，客戶端（主動關閉方）的連接就會直接關閉，如下圖：

但是注意，如果主動關閉方使用shutdown 函數關閉連接，指定了只關閉發送方向，而接收方向並沒有關閉，那麼意味著主動關閉方還是可以接收數據的。

此時，如果主動關閉方一直沒收到第三次揮手，那麼主動關閉方的連接將會一直處於 FIN_WAIT2​ 狀態（tcp_fin_timeout 無法控制shutdown 關閉的連接）。如下圖：

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

當服務端（被動關閉方）收到客戶端（主動關閉方）的FIN 報文後，內核會自動回复ACK，同時連接處於 CLOSE_WAIT 狀態，顧名思義，它表示等待應用進程調用close 函數關閉連接。

此時，內核是沒有權利替代進程關閉連接，必須由進程主動調用close 函數來觸發服務端發送FIN 報文。

服務端處於CLOSE_WAIT 狀態時，調用了close 函數，內核就會發出FIN 報文，同時連接進入LAST_ACK 狀態，等待客戶端返回ACK 來確認連接關閉。

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

舉個例子，假設 tcp_orphan_retries = 3，當第三次揮手一直丟失時，發生的過程如下圖：

具體過程：

• 當服務端重傳第三次揮手報文的次數達到了3 次後，由於tcp_orphan_retries 為3，達到了重傳最大次數，於是再等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到客戶端的第四次揮手（ACK報文），那麼服務端就會斷開連接。
• 客戶端因為是通過close 函數關閉連接的，處於FIN_WAIT_2 狀態是有時長限制的，如果tcp_fin_timeout 時間內還是沒能收到服務端的第三次揮手（FIN 報文），那麼客戶端就會斷開連接。

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

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

在Linux 系統，TIME_WAIT 狀態會持續2MSL 後才會進入關閉狀態。

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

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

舉個例子，假設tcp_orphan_retries 為2，當第四次揮手一直丟失時，發生的過程如下：

具體過程：

• 當服務端重傳第三次揮手報文達到2 時，由於tcp_orphan_retries 為2， 達到了最大重傳次數，於是再等待一段時間（時間為上一次超時時間的2 倍），如果還是沒能收到客戶端的第四次揮手（ACK 報文），那麼服務端就會斷開連接。
• 客戶端在收到第三次揮手後，就會進入TIME_WAIT 狀態，開啟時長為2MSL 的定時器，如果途中再次收到第三次揮手（FIN 報文）後，就會重置定時器，當等待2MSL 時長後，客戶端就會斷開連接。