大家好，我是小林。

今天，聊一個有趣的問題：拔掉網(wǎng)線幾秒，再插回去，原本的 TCP 連接還存在嗎?

可能有的同學會說，網(wǎng)線都被拔掉了，那說明物理層被斷開了，那在上層的傳輸層理應(yīng)也會斷開，所以原本的 TCP 連接就不會存在的了。就好像， 我們撥打有線電話的時候，如果某一方的電話線被拔了，那么本次通話就徹底斷了。

真的是這樣嗎?

上面這個邏輯就有問題。問題在于，錯誤的認為拔掉網(wǎng)線這個動作會影響傳輸層，事實上并不會影響。

實際上，TCP 連接在 Linux 內(nèi)核中是一個名為 struct socket 的結(jié)構(gòu)體，該結(jié)構(gòu)體的內(nèi)容包含 TCP 連接的狀態(tài)等信息。當拔掉網(wǎng)線的時候，操作系統(tǒng)并不會變更該結(jié)構(gòu)體的任何內(nèi)容，所以 TCP 連接的狀態(tài)也不會發(fā)生改變。

我在我的電腦上做了個小實驗，我用 ssh 終端連接了我的云服務(wù)器，然后我通過斷開 wifi 的方式來模擬拔掉網(wǎng)線的場景，此時查看 TCP 連接的狀態(tài)沒有發(fā)生變化，還是處于 ESTABLISHED 狀態(tài)。

通過上面這個實驗結(jié)果，我們知道了，拔掉網(wǎng)線這個動作并不會影響 TCP 連接的狀態(tài)。

接下來，要看拔掉網(wǎng)線后，雙方做了什么動作。

所以， 針對這個問題，要分場景來討論：

• 拔掉網(wǎng)線后，有數(shù)據(jù)傳輸;
• 拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸;

拔掉網(wǎng)線后，有數(shù)據(jù)傳輸

在客戶端拔掉網(wǎng)線后，服務(wù)端向客戶端發(fā)送的數(shù)據(jù)報文會得不到任何的響應(yīng)，在等待一定時長后，服務(wù)端就會觸發(fā)超時重傳機制，重傳未得到響應(yīng)的數(shù)據(jù)報文。

如果在服務(wù)端重傳報文的過程中，客戶端剛好把網(wǎng)線插回去了，由于拔掉網(wǎng)線并不會改變客戶端的 TCP 連接狀態(tài)，并且還是處于 ESTABLISHED 狀態(tài)，所以這時客戶端是可以正常接收服務(wù)端發(fā)來的數(shù)據(jù)報文的，然后客戶端就會回 ACK 響應(yīng)報文。

此時，客戶端和服務(wù)端的 TCP 連接依然存在的，就感覺什么事情都沒有發(fā)生。

但是，如果如果在服務(wù)端重傳報文的過程中，客戶端一直沒有將網(wǎng)線插回去，服務(wù)端超時重傳報文的次數(shù)達到一定閾值后，內(nèi)核就會判定出該 TCP 有問題，然后通過 Socket 接口告訴應(yīng)用程序該 TCP 連接出問題了，于是服務(wù)端的 TCP 連接就會斷開。

而等客戶端插回網(wǎng)線后，如果客戶端向服務(wù)端發(fā)送了數(shù)據(jù)，由于服務(wù)端已經(jīng)沒有與客戶端相同四元祖的 TCP 連接了，因此服務(wù)端內(nèi)核就會回復 RST 報文，客戶端收到后就會釋放該 TCP 連接。

此時，客戶端和服務(wù)端的 TCP 連接都已經(jīng)斷開了。

那 TCP 的數(shù)據(jù)報文具體重傳幾次呢?

在 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 連接。

拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸

針對拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸?shù)膱鼍埃€得看是否開啟了 TCP keepalive 機制 (TCP 保活機制)。

如果沒有開啟 TCP keepalive 機制，在客戶端拔掉網(wǎng)線后，并且雙方都沒有進行數(shù)據(jù)傳輸，那么客戶端和服務(wù)端的 TCP 連接將會一直保持存在。

而如果開啟了 TCP keepalive 機制，在客戶端拔掉網(wǎng)線后，即使雙方都沒有進行數(shù)據(jù)傳輸，在持續(xù)一段時間后，TCP 就會發(fā)送探測報文：

• 如果對端是正常工作的。當 TCP 保活的探測報文發(fā)送給對端, 對端會正常響應(yīng)，這樣 TCP 保活時間會被重置，等待下一個 TCP 保活時間的到來。
• 如果對端主機崩潰，或?qū)Χ擞捎谄渌驅(qū)е聢笪牟豢蛇_。當 TCP 保活的探測報文發(fā)送給對端后，石沉大海，沒有響應(yīng)，連續(xù)幾次，達到保活探測次數(shù)后，TCP 會報告該 TCP 連接已經(jīng)死亡。

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

TCP keepalive 機制具體是怎么樣的?

這個機制的原理是這樣的：

定義一個時間段，在這個時間段內(nèi)，如果沒有任何連接相關(guān)的活動，TCP 保活機制會開始作用，每隔一個時間間隔，發(fā)送一個探測報文，該探測報文包含的數(shù)據(jù)非常少，如果連續(xù)幾個探測報文都沒有得到響應(yīng)，則認為當前的 TCP 連接已經(jīng)死亡，系統(tǒng)內(nèi)核將錯誤信息通知給上層應(yīng)用程序。

在 Linux 內(nèi)核可以有對應(yīng)的參數(shù)可以設(shè)置保活時間、保活探測的次數(shù)、保活探測的時間間隔，以下都為默認值：

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9

• tcp_keepalive_time=7200：表示保活時間是 7200 秒(2小時)，也就 2 小時內(nèi)如果沒有任何連接相關(guān)的活動，則會啟動保活機制
• tcp_keepalive_intvl=75：表示每次檢測間隔 75 秒;
• tcp_keepalive_probes=9：表示檢測 9 次無響應(yīng)，認為對方是不可達的，從而中斷本次的連接。

也就是說在 Linux 系統(tǒng)中，最少需要經(jīng)過 2 小時 11 分 15 秒才可以發(fā)現(xiàn)一個「死亡」連接。

圖片

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

TCP keepalive 機制探測的時間也太長了吧?

對的，是有點長。

TCP keepalive 是 TCP 層(內(nèi)核態(tài)) 實現(xiàn)的，它是給所有基于 TCP 傳輸協(xié)議的程序一個兜底的方案。

實際上，我們應(yīng)用層可以自己實現(xiàn)一套探測機制，可以在較短的時間內(nèi)，探測到對方是否存活。

比如，web 服務(wù)軟件一般都會提供 keepalive_timeout 參數(shù)，用來指定 HTTP 長連接的超時時間。如果設(shè)置了 HTTP 長連接的超時時間是 60 秒，web 服務(wù)軟件就會啟動一個定時器，如果客戶端在完后一個 HTTP 請求后，在 60 秒內(nèi)都沒有再發(fā)起新的請求，定時器的時間一到，就會觸發(fā)回調(diào)函數(shù)來釋放該連接。

總結(jié)

客戶端拔掉網(wǎng)線后，并不會直接影響 TCP 連接狀態(tài)。所以，拔掉網(wǎng)線后，TCP 連接是否還會存在，關(guān)鍵要看拔掉網(wǎng)線之后，有沒有進行數(shù)據(jù)傳輸。

有數(shù)據(jù)傳輸?shù)那闆r：

• 在客戶端拔掉網(wǎng)線后，如果服務(wù)端發(fā)送了數(shù)據(jù)報文，那么在服務(wù)端重傳次數(shù)沒有達到最大值之前，客戶端就插回了網(wǎng)線，那么雙方原本的 TCP 連接還是能正常存在，就好像什么事情都沒有發(fā)生。
• 在客戶端拔掉網(wǎng)線后，如果服務(wù)端發(fā)送了數(shù)據(jù)報文，在客戶端插回網(wǎng)線之前，服務(wù)端重傳次數(shù)達到了最大值時，服務(wù)端就會斷開 TCP 連接。等到客戶端插回網(wǎng)線后，向服務(wù)端發(fā)送了數(shù)據(jù)，因為服務(wù)端已經(jīng)斷開了與客戶端相同四元組的 TCP 連接，所以就會回 RST 報文，客戶端收到后就會斷開 TCP 連接。至此， 雙方的 TCP 連接都斷開了。

沒有數(shù)據(jù)傳輸?shù)那闆r：

• 如果雙方都沒有開啟 TCP keepalive 機制，那么在客戶端拔掉網(wǎng)線后，如果客戶端一直不插回網(wǎng)線，那么客戶端和服務(wù)端的 TCP 連接狀態(tài)將會一直保持存在。
• 如果雙方都開啟了 TCP keepalive 機制，那么在客戶端拔掉網(wǎng)線后，如果客戶端一直不插回網(wǎng)線，TCP keepalive 機制會探測到對方的 TCP 連接沒有存活，于是就會斷開 TCP 連接。而如果在 TCP 探測期間，客戶端插回了網(wǎng)線，那么雙方原本的 TCP 連接還是能正常存在。

除了客戶端拔掉網(wǎng)線的場景，還有客戶端「宕機和殺死進程」的兩種場景。

第一個場景，客戶端宕機這件事跟拔掉網(wǎng)線是一樣無法被服務(wù)端的感知的，所以如果在沒有數(shù)據(jù)傳輸，并且沒有開啟 TCP keepalive 機制時，，服務(wù)端的 TCP 連接將會一直處于 ESTABLISHED 連接狀態(tài)，直到服務(wù)端重啟進程。

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

第二個場景，殺死客戶端的進程后，客戶端的內(nèi)核就會向服務(wù)端發(fā)送 FIN 報文，與客戶端進行四次揮手。

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

完!