TCP keepalive機制具體是怎么樣的

大家好，我是小林。

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

可能有的同學(xué)會說，網(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)核就會回復(fù) 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 ?；顧C制）。如果沒有開啟 TCP keepalive 機制，在客戶端拔掉網(wǎng)線后，并且雙方都沒有進行數(shù)據(jù)傳輸，那么客戶端和服務(wù)端的 TCP 連接將會一直保持存在。而如果開啟了 TCP keepalive 機制，在客戶端拔掉網(wǎng)線后，即使雙方都沒有進行數(shù)據(jù)傳輸，在持續(xù)一段時間后，TCP 就會發(fā)送探測報文：

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

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

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

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

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

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)的活動，則會啟動?；顧C制；

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 ?；顧C制需要通過 socket 接口設(shè)置 SO_KEEPALIVE選項才能夠生效，如果沒有設(shè)置，那么就無法使用 TCP ?；顧C制。

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 ?；顧C制，且雙方不傳輸數(shù)據(jù)的情況下，一方的 TCP 連接處在 ESTABLISHED 狀態(tài)時，并不代表另一方的 TCP 連接還一定是正常的。第二個場景，殺死客戶端的進程后，客戶端的內(nèi)核就會向服務(wù)端發(fā)送 FIN 報文，與客戶端進行四次揮手。所以，即使沒有開啟 TCP keepalive，且雙方也沒有數(shù)據(jù)交互的情況下，如果其中一方的進程發(fā)生了崩潰，這個過程操作系統(tǒng)是可以感知的到的，于是就會發(fā)送 FIN 報文給對方，然后與對方進行 TCP 四次揮手。

原文標題：拔掉網(wǎng)線后， 原本的 TCP 連接還存在嗎？

文章出處：【微信公眾號：程序人生】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。