不為人知的網(wǎng)絡(luò)編程(十四)：拔掉網(wǎng)線再插上，TCP連接還在嗎？一文即懂！

Posted on 2022-03-07 18:15 Jack Jiang 閱讀(263) 評論(0) 編輯收藏

本文由作者小林coding分享，來自公號“小林coding”，有修訂和改動。

1、引言

說到TCP協(xié)議，對于從事即時通訊/IM這方面應(yīng)用的開發(fā)者們來說，再熟悉不過了。隨著對TCP理解的越來越深入，很多曾今碰到過但沒時間深入探究的TCP技術(shù)概念或疑問，現(xiàn)在是時候回頭來惡補一下了。

本篇文章，我們就從系統(tǒng)層面深入地探討一個有趣的TCP技術(shù)問題：拔掉網(wǎng)線后，再插上，原本的這條TCP連接還在嗎？或者說它還“好”嗎？

可能有的人會說：網(wǎng)線都被拔掉了，那說明物理層（也叫實體層）被斷開了（關(guān)于網(wǎng)絡(luò)協(xié)議分層模型請見《快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》），那在物理層之上的傳輸層理應(yīng)也會斷開，所以原本的 TCP 連接就不會存在的了。就好像我們撥打有線電話的時候，如果某一方的電話線被拔了，那么本次通話就徹底斷了。

答案真的是這樣嗎？可能并非你理解的這樣哦，一起跟隨筆者來深入探討一下。

學(xué)習(xí)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK

（本文同步發(fā)布于：http://www.52im.net/thread-3846-1-1.html）

2、系列文章

本文是系列文章中的第14篇，本系列文章的大綱如下：

《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》
《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》
《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負載均衡》
《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網(wǎng)絡(luò)編程(八)：從數(shù)據(jù)傳輸層深度解密HTTP》
《不為人知的網(wǎng)絡(luò)編程(九)：理論聯(lián)系實際，全方位深入理解DNS》
《不為人知的網(wǎng)絡(luò)編程(十)：深入操作系統(tǒng)，從內(nèi)核理解網(wǎng)絡(luò)包的接收過程(Linux篇)》
《不為人知的網(wǎng)絡(luò)編程(十一)：從底層入手，深度分析TCP連接耗時的秘密》
《不為人知的網(wǎng)絡(luò)編程(十二)：徹底搞懂TCP協(xié)議層的KeepAlive保活機制》
《不為人知的網(wǎng)絡(luò)編程(十三)：深入操作系統(tǒng)，徹底搞懂127.0.0.1本機網(wǎng)絡(luò)通信》
《不為人知的網(wǎng)絡(luò)編程(十四)：拔掉網(wǎng)線再插上，TCP連接還在嗎？一文即懂！》（* 本文）

3、比較籠統(tǒng)的答案

3.1 答案

引言里我們說到：有人認為，網(wǎng)線都被拔掉了，那說明物理層被斷開，那么物理層之上的傳輸層肯定也會斷開，所以原來的 TCP 連接自然也就不存在了。（PS：計算機網(wǎng)絡(luò)分層詳解請見《史上最通俗計算機網(wǎng)絡(luò)分層詳解》）

上面這個邏輯是有問題的。

問題在于：錯誤的認為拔掉網(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ā)生改變。

3.2 實驗驗證一下

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

通過上面實驗結(jié)果可以驗證我的結(jié)論：拔掉網(wǎng)線這個動作并不會影響 TCP 連接的狀態(tài)。

不過，這個答案還是有點籠統(tǒng)。實際上，我們應(yīng)該在更具體的場景中來看待這個問題，答案才更準確一些。

這個具體場景就是：

1）當拔掉網(wǎng)線后，有數(shù)據(jù)傳輸時；
2）當拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸時。

針對上面這兩種具體的場景，我來更具體地來分析一下。我們繼續(xù)往下閱讀。

4、具體場景1：拔掉網(wǎng)線后，有數(shù)據(jù)傳輸時

4.1 數(shù)據(jù)傳輸過程中，恰好又把網(wǎng)線插回去了

如果是客戶端被拔掉網(wǎng)線后，服務(wù)端向客戶端發(fā)送的數(shù)據(jù)報文會得不到任何的響應(yīng)，在等待一定時長后，服務(wù)端就會觸發(fā)TCP協(xié)議的超時重傳機制（詳見：《TCP/IP詳解 - 第21章·TCP的超時與重傳》），然而此時重傳并不能得到響應(yīng)的數(shù)據(jù)報文。

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

此時：客戶端和服務(wù)端的 TCP 連接將依然存在且工作狀態(tài)不會受到影響，給應(yīng)用層的感覺就像什么事情都沒有發(fā)生。。。

4.2 數(shù)據(jù)傳輸過程中，網(wǎng)線一直沒有插回去

上面這種情況下，如果在服務(wù)端TCP協(xié)議重傳報文的過程中，客戶端一直沒有將網(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)明確被斷開，原本的這個連接也就不存在了。

4.3 刨根問底：TCP數(shù)據(jù)報文到底重傳幾次？

本著知其然更應(yī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 連接。

PS：有關(guān)TCP超時重傳機制的詳細情況，可以閱讀《淺析TCP協(xié)議中的疑難雜癥(下篇)》。

5、具體場景2：拔掉網(wǎng)線后，有數(shù)據(jù)傳輸時

5.1 場景分析

針對拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸?shù)膱鼍埃€得具體看看是否開啟了 TCP KeepAlive 機制（詳見《徹底搞懂TCP協(xié)議層的KeepAlive保活機制》）。

1）如果沒有開啟 TCP KeepAlive 機制：

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

2）如果開啟了 TCP KeepAlive 機制：

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

根據(jù)KeepAlive探測報文響應(yīng)情況，會有以下兩種可能：

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

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

5.2 刨根問底：TCP KeepAlive 機制具體是什么樣的？

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ù)、保活探測的時間間隔。

以下是 Linux 中的默認值：

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

解釋一下：

1）tcp_keepalive_time=7200：表示保活時間是 7200 秒（2小時），也就 2 小時內(nèi)如果沒有任何連接相關(guān)的活動，則會啟動保活機制；
2）tcp_keepalive_intvl=75：表示每次檢測間隔 75 秒；
3）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 保活機制。

PS：關(guān)于TCP協(xié)議的KeepAlive 機制詳見《徹底搞懂TCP協(xié)議層的KeepAlive保活機制》、《一文讀懂即時通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機制：作用、原理、實現(xiàn)思路等》。

5.3 刨根問底：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ù)來釋放該連接。

再比如：IM、消息推送系統(tǒng)里的心跳機制，通過應(yīng)用層的心跳機制（由客戶端發(fā)出，服務(wù)端回復(fù)響應(yīng)包），來靈活控制和探測長連接的健康度。

《為何基于TCP協(xié)議的移動端IM仍然需要心跳保活機制？》這篇文章解釋了IM這類應(yīng)用中應(yīng)用層心跳保活的必要性，有興趣可以讀一讀。

如果對應(yīng)用層心跳的具體應(yīng)用沒什么概念，可以看看微信的這兩篇文章：

《微信團隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》
《移動端IM實踐：實現(xiàn)Android版微信的智能心跳機制》

下面有幾個針對im這類應(yīng)用的心跳實現(xiàn)代碼，可以具體感受學(xué)習(xí)一下：

《正確理解IM長連接的心跳及重連機制，并動手實現(xiàn)（有完整IM源碼）》
《一種Android端IM智能心跳算法的設(shè)計與實現(xiàn)探討（含樣例代碼）》
《自已開發(fā)IM有那么難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》
《手把手教你用Netty實現(xiàn)網(wǎng)絡(luò)通信程序的心跳機制、斷線重連機制》

6、本文小結(jié)

下面簡單總結(jié)一下文中的內(nèi)容，本文開頭的問題并不是簡單一句話能夠準確說清楚的，需要分情況對待。

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

1）有數(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 連接都斷開了。

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

a. 如果雙方都沒有開啟 TCP keepalive 機制，那么在客戶端拔掉網(wǎng)線后，如果客戶端一直不插回網(wǎng)線，那么客戶端和服務(wù)端的 TCP 連接狀態(tài)將會一直保持存在；
b. 如果雙方都開啟了 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 報文，與客戶端進行四次揮手（見《跟著動畫來學(xué)TCP三次握手和四次揮手》）。

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