大家好，我是周末不休息的小林哥。上周有位讀者找我說，他在面試鵝廠的時候，遇到了這么個問題：

這個屬于?TCP 異常斷開連接的場景，這部分內(nèi)容在我的「圖解網(wǎng)絡(luò)」還沒有詳細介紹過，這次就乘著這次機會補一補。

這個問題有幾個關(guān)鍵詞：

• 沒有開啟 keepalive；

• 一直沒有數(shù)據(jù)交互；

• 進程崩潰；

• 主機崩潰；

我們先來認識認識什么是 TCP keepalive 呢？

這東西其實就是?TCP 的保活機制，它的工作原理我之前的文章寫過，這里就直接貼下以前的內(nèi)容。

如果兩端的 TCP 連接一直沒有數(shù)據(jù)交互，達到了觸發(fā) TCP ?；顧C制的條件，那么內(nèi)核里的 TCP 協(xié)議棧就會發(fā)送探測報文。

• 如果對端程序是正常工作的。當(dāng) TCP 保活的探測報文發(fā)送給對端, 對端會正常響應(yīng)，這樣?TCP ?；顣r間會被重置，等待下一個 TCP 保活時間的到來。

• 如果對端主機崩潰，或?qū)Χ擞捎谄渌驅(qū)е聢笪牟豢蛇_。當(dāng) TCP ?；畹奶綔y報文發(fā)送給對端后，石沉大海，沒有響應(yīng)，連續(xù)幾次，達到?；钐綔y次數(shù)后，TCP 會報告該 TCP 連接已經(jīng)死亡。

所以，TCP ?；顧C制可以在雙方?jīng)]有數(shù)據(jù)交互的情況，通過探測報文，來確定對方的 TCP 連接是否存活。

注意，應(yīng)用程序若想使用 TCP ?；顧C制需要通過 socket 接口設(shè)置?SO_KEEPALIVE?選項才能夠生效，如果沒有設(shè)置，那么就無法使用 TCP 保活機制。

知道了 TCP keepalive 作用，我們再回過頭看題目中的「主機崩潰」這種情況。

在沒有開啟 TCP keepalive，且雙方一直沒有數(shù)據(jù)交互的情況下，如果客戶端的「主機崩潰」了，會發(fā)生什么。

如果客戶端主機崩潰了，服務(wù)端是無法感知到的，在加上服務(wù)端沒有開啟 TCP keepalive，又沒有數(shù)據(jù)交互的情況下，服務(wù)端的 TCP 連接將會一直處于 ESTABLISHED 連接狀態(tài)，直到服務(wù)端重啟進程。

所以，我們可以得知一個點。

在沒有使用 TCP 保活機制，且雙方不傳輸數(shù)據(jù)的情況下，一方的 TCP 連接處在 ESTABLISHED 狀態(tài)時，并不代表另一方的 TCP 連接還一定是正常的。

那題目中的「進程崩潰」的情況呢？

我自己做了個實驗，使用 kill -9 來模擬進程崩潰的情況，發(fā)現(xiàn)在 kill 掉進程后，服務(wù)端會發(fā)送 FIN 報文，與客戶端進行四次揮手。

所以，即使沒有開啟 TCP keepalive，且雙方也沒有數(shù)據(jù)交互的情況下，如果其中一方的進程發(fā)生了崩潰，這個過程操作系統(tǒng)是可以感知的到的，于是就會發(fā)送 FIN 報文給對方，然后與對方進行 TCP 四次揮手。

以上就是對這個面試題的回答。

這面試題其實在變相考察 TCP ?；顧C制的作用。

接下來我們看看在「有數(shù)據(jù)傳輸」的場景下的一些異常情況：

• 第一種，客戶端主機宕機，又迅速重啟，會發(fā)生什么？

• 第二種，客戶端主機宕機，一直沒有重啟，會發(fā)生什么？

客戶端主機宕機，又迅速重啟

在客戶端主機宕機后，服務(wù)端向客戶端發(fā)送的報文會得不到任何的響應(yīng)，在一定時長后，服務(wù)端就會觸發(fā)超時重傳機制，重傳未得到響應(yīng)的報文。

服務(wù)端重傳報文的過程中，剛好客戶端主機重啟完成，這時客戶端的內(nèi)核就會接收重傳的報文，：

• 如果客戶端主機上沒有進程監(jiān)聽該 TCP 報文的目標(biāo)端口號，由于找不到目標(biāo)端口，客戶端內(nèi)核就會回復(fù) RST 報文，重置該 TCP 連接；

• 如果客戶端主機上有進程監(jiān)聽該 TCP 報文的目標(biāo)端口號，由于客戶端主機重啟后，之前的?TCP?連接的數(shù)據(jù)結(jié)構(gòu)已經(jīng)丟失了，客戶端內(nèi)核里協(xié)議棧會發(fā)現(xiàn)找不到該 TCP 連接的 socket 結(jié)構(gòu)體，于是就會回復(fù) RST 報文，重置該 TCP 連接。

所以，只要有一方重啟完成后，收到之前 TCP 連接的報文，都會回復(fù) RST 報文，以斷開連接。

客戶端主機宕機，一直沒有重啟

這種情況，服務(wù)端超時重傳報文的次數(shù)達到一定閾值后，內(nèi)核就會判定出該 TCP 有問題，然后通過 Socket 接口告訴應(yīng)用程序該 TCP 連接出問題了。

那具體重傳幾次呢？

在 Linux 系統(tǒng)中，提供了一個叫 tcp_retries2 配置項，默認值是 15，如下圖：

這個內(nèi)核參數(shù)是控制，在 TCP 連接建立的情況下，超時重傳的最大次數(shù)。

不過 tcp_retries2 設(shè)置了 15 次，并不代表 TCP 超時重傳了 15 次才會通知應(yīng)用程序終止該 TCP 連接，內(nèi)核還會基于「最大超時時間」來判定。

每一輪的超時時間都是倍數(shù)增長的，比如第一次觸發(fā)超時重傳是在 2s 后，第二次則是在 4s 后，第三次則是 8s 后，以此類推。

內(nèi)核會根據(jù) tcp_retries2 設(shè)置的值，計算出一個最大超時時間。

在重傳報文且一直沒有收到對方響應(yīng)的情況時，先達到「最大重傳次數(shù)」或者「最大超時時間」這兩個的其中一個條件后，就會停止重傳。

最后說句。

TCP 牛逼，啥異常都考慮到了