TCP 三次握手和四次揮手過程中，途中某一步的報文丟失了，會發(fā)生什么？

今天就和大家一起來詳細了解下，TCP三次握手和四次揮手過程中每一步的異常情況。

發(fā)車！

TCP 三次握手丟包情況

第一次握手丟失了，會發(fā)生什么？

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

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

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

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

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

#cat/proc/sys/net/ipv4/tcp_syn_retries
5

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

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

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

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

具體過程：

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

第二次握手丟失了，會發(fā)生什么？

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

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

第二次握手里的 ACK， 是對第一次握手的確認報文；

第二次握手里的 SYN，是服務端發(fā)起建立 TCP 連接的報文。

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

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

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

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

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

#cat/proc/sys/net/ipv4/tcp_synack_retries
5

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

客戶端會重傳 SYN 報文，也就是第一次握手，最大重傳次數由 tcp_syn_retries內核參數決定；

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

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

具體過程：

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

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

第三次握手丟失了，會發(fā)生什么？

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

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

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

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

具體過程：

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

TCP 四次揮手丟包情況

第一次揮手丟失了，會發(fā)生什么？

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

正常情況下，如果能及時收到服務端（被動關閉方）的 ACK，則會很快變?yōu)?FIN_WAIT2狀態(tài)。

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

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

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

具體過程：

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

第二次揮手丟失了，會發(fā)生什么？

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

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

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

具體過程：

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

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

對于 close 函數關閉的連接，由于無法再發(fā)送和接收數據，所以FIN_WAIT2 狀態(tài)不可以持續(xù)太久，而 tcp_fin_timeout 控制了這個狀態(tài)下連接的持續(xù)時長，默認值是 60 秒。

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

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

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

第三次揮手丟失了，會發(fā)生什么？

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

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

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

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

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

具體過程：

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

客戶端因為是通過 close 函數關閉連接的，處于 FIN_WAIT_2 狀態(tài)是有時長限制的，如果 tcp_fin_timeout 時間內還是沒能收到服務端的第三次揮手（FIN 報文），那么客戶端就會斷開連接。

第四次揮手丟失了，會發(fā)生什么？

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

在 Linux 系統(tǒng)，TIME_WAIT 狀態(tài)會持續(xù) 2MSL 后才會進入關閉狀態(tài)。

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

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

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

具體過程：

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

客戶端在收到第三次揮手后，就會進入 TIME_WAIT 狀態(tài)，開啟時長為 2MSL 的定時器，如果途中再次收到第三次揮手（FIN 報文）后，就會重置定時器，當等待 2MSL 時長后，客戶端就會斷開連接。