不為人知的網(wǎng)絡(luò)編程(十四)：拔掉網(wǎng)線再插上，TCP連接還在嗎？一文即懂！
本文由作者小林coding分享，來自公號(hào)“小林coding”，有修訂和改動(dòng)。
1、引言
說到TCP協(xié)議，對(duì)于從事即時(shí)通訊/IM這方面應(yīng)用的開發(fā)者們來說，再熟悉不過了。隨著對(duì)TCP理解的越來越深入，很多曾今碰到過但沒時(shí)間深入探究的TCP技術(shù)概念或疑問，現(xiàn)在是時(shí)候回頭來惡補(bǔ)一下了。
本篇文章，我們就從系統(tǒng)層面深入地探討一個(gè)有趣的TCP技術(shù)問題：拔掉網(wǎng)線后，再插上，原本的這條TCP連接還在嗎？或者說它還“好”嗎？
可能有的人會(huì)說：網(wǎng)線都被拔掉了，那說明物理層（也叫實(shí)體層）被斷開了（關(guān)于網(wǎng)絡(luò)協(xié)議分層模型請(qǐng)見《快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》），那在物理層之上的傳輸層理應(yīng)也會(huì)斷開，所以原本的 TCP 連接就不會(huì)存在的了。就好像我們撥打有線電話的時(shí)候，如果某一方的電話線被拔了，那么本次通話就徹底斷了。
答案真的是這樣嗎？可能并非你理解的這樣哦，一起跟隨筆者來深入探討一下。
學(xué)習(xí)交流：
- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端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連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》
《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網(wǎng)絡(luò)編程(八)：從數(shù)據(jù)傳輸層深度解密HTTP》
《不為人知的網(wǎng)絡(luò)編程(九)：理論聯(lián)系實(shí)際，全方位深入理解DNS》
《不為人知的網(wǎng)絡(luò)編程(十)：深入操作系統(tǒng)，從內(nèi)核理解網(wǎng)絡(luò)包的接收過程(Linux篇)》
《不為人知的網(wǎng)絡(luò)編程(十一)：從底層入手，深度分析TCP連接耗時(shí)的秘密》
《不為人知的網(wǎng)絡(luò)編程(十二)：徹底搞懂TCP協(xié)議層的KeepAlive?；顧C(jī)制》
《不為人知的網(wǎng)絡(luò)編程(十三)：深入操作系統(tǒng)，徹底搞懂127.0.0.1本機(jī)網(wǎng)絡(luò)通信》
《不為人知的網(wǎng)絡(luò)編程(十四)：拔掉網(wǎng)線再插上，TCP連接還在嗎？一文即懂！》（* 本文）
3、比較籠統(tǒng)的答案
3.1 答案
引言里我們說到：有人認(rèn)為，網(wǎng)線都被拔掉了，那說明物理層被斷開，那么物理層之上的傳輸層肯定也會(huì)斷開，所以原來的 TCP 連接自然也就不存在了。（PS：計(jì)算機(jī)網(wǎng)絡(luò)分層詳解請(qǐng)見《史上最通俗計(jì)算機(jī)網(wǎng)絡(luò)分層詳解》）
上面這個(gè)邏輯是有問題的。
問題在于：錯(cuò)誤的認(rèn)為拔掉網(wǎng)線這個(gè)動(dòng)作會(huì)影響傳輸層，事實(shí)上并不會(huì)影響！
實(shí)際上：TCP 連接在 Linux 內(nèi)核中是一個(gè)名為?struct socket?的結(jié)構(gòu)體，該結(jié)構(gòu)體的內(nèi)容包含 TCP 連接的狀態(tài)等信息。
所以：當(dāng)拔掉網(wǎng)線的時(shí)候，操作系統(tǒng)并不會(huì)變更該結(jié)構(gòu)體的任何內(nèi)容，所以 TCP 連接的狀態(tài)也不會(huì)發(fā)生改變。
3.2 實(shí)驗(yàn)驗(yàn)證一下
我做了個(gè)小實(shí)驗(yàn)：我用 ssh 終端連接了我的云服務(wù)器，然后我通過斷開 wifi 的方式來模擬拔掉網(wǎng)線的場景，此時(shí)查看 TCP 連接的狀態(tài)沒有發(fā)生變化，還是處于?ESTABLISHED?狀態(tài)（如下圖所示）。
通過上面實(shí)驗(yàn)結(jié)果可以驗(yàn)證我的結(jié)論：拔掉網(wǎng)線這個(gè)動(dòng)作并不會(huì)影響 TCP 連接的狀態(tài)。
不過，這個(gè)答案還是有點(diǎn)籠統(tǒng)。實(shí)際上，我們應(yīng)該在更具體的場景中來看待這個(gè)問題，答案才更準(zhǔn)確一些。
這個(gè)具體場景就是：
1）當(dāng)拔掉網(wǎng)線后，有數(shù)據(jù)傳輸時(shí)；
2）當(dāng)拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸時(shí)。
針對(duì)上面這兩種具體的場景，我來更具體地來分析一下。我們繼續(xù)往下閱讀。
4、具體場景1：拔掉網(wǎng)線后，有數(shù)據(jù)傳輸時(shí)
4.1 數(shù)據(jù)傳輸過程中，恰好又把網(wǎng)線插回去了
如果是客戶端被拔掉網(wǎng)線后，服務(wù)端向客戶端發(fā)送的數(shù)據(jù)報(bào)文會(huì)得不到任何的響應(yīng)，在等待一定時(shí)長后，服務(wù)端就會(huì)觸發(fā)TCP協(xié)議的超時(shí)重傳機(jī)制（詳見：《TCP/IP詳解?-?第21章·TCP的超時(shí)與重傳》），然而此時(shí)重傳并不能得到響應(yīng)的數(shù)據(jù)報(bào)文。
如果在服務(wù)端重傳報(bào)文的過程中，客戶端恰好把網(wǎng)線插回去了，由于拔掉網(wǎng)線并不會(huì)改變客戶端的 TCP 連接狀態(tài)，并且還是處于 ESTABLISHED 狀態(tài)，所以這時(shí)客戶端是可以正常接收服務(wù)端發(fā)來的數(shù)據(jù)報(bào)文的，然后客戶端就會(huì)回 ACK 響應(yīng)報(bào)文。
此時(shí)：客戶端和服務(wù)端的 TCP 連接將依然存在且工作狀態(tài)不會(huì)受到影響，給應(yīng)用層的感覺就像什么事情都沒有發(fā)生。。。
4.2 數(shù)據(jù)傳輸過程中，網(wǎng)線一直沒有插回去
上面這種情況下，如果在服務(wù)端TCP協(xié)議重傳報(bào)文的過程中，客戶端一直沒有將網(wǎng)線插回去，那么服務(wù)端超時(shí)重傳報(bào)文的次數(shù)達(dá)到一定閾值后，內(nèi)核就會(huì)判定出該 TCP 有問題。然后就會(huì)通過 Socket 接口告訴應(yīng)用程序該 TCP 連接出問題了，于是服務(wù)端的 TCP 連接就會(huì)斷開。
接下來，如果客戶端再插回網(wǎng)線，如果客戶端向服務(wù)端發(fā)送了數(shù)據(jù)，由于服務(wù)端已經(jīng)沒有與客戶端匹配的 TCP 連接信息了，因此服務(wù)端內(nèi)核就會(huì)回復(fù)?RST?報(bào)文，客戶端收到后就會(huì)釋放該 TCP 連接。
此時(shí)：客戶端和服務(wù)端的 TCP 連接已經(jīng)明確被斷開，原本的這個(gè)連接也就不存在了。
4.3 刨根問底：TCP數(shù)據(jù)報(bào)文到底重傳幾次？
本著知其然更應(yīng)知其所以然的精神，我們來刨根問底一下：TCP 的數(shù)據(jù)報(bào)文到底有重傳幾次呢？
在 Linux 系統(tǒng)中，提供了一個(gè)叫?tcp_retries2?配置項(xiàng)，默認(rèn)值是 15（如下圖所示）。
如上圖所示：這個(gè)內(nèi)核參數(shù)是控制 TCP 連接建立的情況下，超時(shí)重傳的最大次數(shù)。
不過?tcp_retries2?設(shè)置了?15?次，并不代表 TCP 超時(shí)重傳了?15?次才會(huì)通知應(yīng)用程序終止該 TCP 連接，內(nèi)核還會(huì)基于“最大超時(shí)時(shí)間”來判定。
每一輪的超時(shí)時(shí)間都是倍數(shù)增長的，比如第一次觸發(fā)超時(shí)重傳是在?2s?后，第二次則是在?4s?后，第三次則是?8s?后，以此類推。
內(nèi)核會(huì)根據(jù)?tcp_retries2?設(shè)置的值，計(jì)算出一個(gè)最大超時(shí)時(shí)間。
在重傳報(bào)文且一直沒有收到對(duì)方響應(yīng)的情況時(shí)，先達(dá)到“最大重傳次數(shù)”或者“最大超時(shí)時(shí)間”這兩個(gè)的其中一個(gè)條件后，就會(huì)停止重傳，然后就會(huì)斷開 TCP 連接。
PS：有關(guān)TCP超時(shí)重傳機(jī)制的詳細(xì)情況，可以閱讀《淺析TCP協(xié)議中的疑難雜癥(下篇)》。
5、具體場景2：拔掉網(wǎng)線后，有數(shù)據(jù)傳輸時(shí)
5.1 場景分析
針對(duì)拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸?shù)膱鼍埃€得具體看看是否開啟了 TCP KeepAlive 機(jī)制 （詳見《徹底搞懂TCP協(xié)議層的KeepAlive?；顧C(jī)制》）。
1）如果沒有開啟 TCP KeepAlive 機(jī)制：
在客戶端拔掉網(wǎng)線后，并且雙方都沒有進(jìn)行數(shù)據(jù)傳輸，那么客戶端和服務(wù)端的 TCP 連接將會(huì)一直保持存在。
2）如果開啟了 TCP KeepAlive 機(jī)制：
在客戶端拔掉網(wǎng)線后，即使雙方都沒有進(jìn)行數(shù)據(jù)傳輸，在持續(xù)一段時(shí)間后，TCP 就會(huì)發(fā)送KeepAlive探測報(bào)文。
根據(jù)KeepAlive探測報(bào)文響應(yīng)情況，會(huì)有以下兩種可能：
1）如果對(duì)端正常工作：當(dāng)探測報(bào)文被對(duì)端收到并正常響應(yīng)， TCP ?；顣r(shí)間將被重置，等待下一個(gè) TCP ?；顣r(shí)間的到來；
2）如果對(duì)端主機(jī)崩潰或?qū)Χ擞捎谄渌驅(qū)е聢?bào)文不可達(dá)：當(dāng)探測報(bào)文發(fā)送給對(duì)端后，石沉大海、沒有響應(yīng)，連續(xù)幾次，達(dá)到?；钐綔y次數(shù)后，TCP 會(huì)報(bào)告該連接已經(jīng)死亡。
所以：TCP 保活機(jī)制可以在雙方?jīng)]有數(shù)據(jù)交互的情況，通過TCP KeepAlive 機(jī)制的探測報(bào)文，來確定對(duì)方的 TCP 連接是否存活。
5.2 刨根問底：TCP KeepAlive 機(jī)制具體是什么樣的？
TCP KeepAlive 機(jī)制的原理是這樣的：
定義一個(gè)時(shí)間段，在這個(gè)時(shí)間段內(nèi)，如果沒有任何連接相關(guān)的活動(dòng)，TCP 保活機(jī)制會(huì)開始作用，每隔一個(gè)時(shí)間間隔，發(fā)送一個(gè)探測報(bào)文。該探測報(bào)文包含的數(shù)據(jù)非常少，如果連續(xù)幾個(gè)探測報(bào)文都沒有得到響應(yīng)，則認(rèn)為當(dāng)前的 TCP 連接已經(jīng)死亡，系統(tǒng)內(nèi)核將錯(cuò)誤信息通知給上層應(yīng)用程序。
在 Linux 內(nèi)核可以有對(duì)應(yīng)的參數(shù)可以設(shè)置?；顣r(shí)間、?；钐綔y的次數(shù)、?；钐綔y的時(shí)間間隔。
以下是 Linux 中的默認(rèn)值：
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75?
net.ipv4.tcp_keepalive_probes=9
解釋一下：
1）tcp_keepalive_time=7200：表示?；顣r(shí)間是 7200 秒（2小時(shí)），也就 2 小時(shí)內(nèi)如果沒有任何連接相關(guān)的活動(dòng)，則會(huì)啟動(dòng)?；顧C(jī)制；
2）tcp_keepalive_intvl=75：表示每次檢測間隔 75 秒；
3）tcp_keepalive_probes=9：表示檢測 9 次無響應(yīng)，認(rèn)為對(duì)方是不可達(dá)的，從而中斷本次的連接。
也就是說在 Linux 系統(tǒng)中，最少需要經(jīng)過?2 小時(shí) 11 分 15 秒才可以發(fā)現(xiàn)一個(gè)“死亡”連接。
計(jì)算公式是：
注意：應(yīng)用程序若想使用 TCP 保活機(jī)制需要通過 socket 接口設(shè)置?SO_KEEPALIVE?選項(xiàng)才能夠生效，如果沒有設(shè)置，那么就無法使用 TCP ?；顧C(jī)制。
PS：關(guān)于TCP協(xié)議的KeepAlive 機(jī)制詳見《徹底搞懂TCP協(xié)議層的KeepAlive保活機(jī)制》、《一文讀懂即時(shí)通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實(shí)現(xiàn)思路等》。
5.3 刨根問底：TCP KeepAlive 機(jī)制的探測時(shí)間也太長了吧？
沒錯(cuò)，確實(shí)有點(diǎn)長。
TCP KeepAlive??機(jī)制是 TCP 層（內(nèi)核態(tài)） 實(shí)現(xiàn)的，它是給所有基于 TCP 傳輸協(xié)議的程序一個(gè)兜底的方案。
實(shí)際上：我們通常在應(yīng)用層自己實(shí)現(xiàn)一套探測機(jī)制，可以在較短的時(shí)間內(nèi)，探測到對(duì)方是否存活。
比如：一般Web 服務(wù)器都會(huì)提供?keepalive_timeout?參數(shù)，用來指定 HTTP 長連接的超時(shí)時(shí)間。如果設(shè)置了 HTTP 長連接的超時(shí)時(shí)間是?60?秒，Web 服務(wù)軟件就會(huì)啟動(dòng)一個(gè)定時(shí)器，如果客戶端在完后一個(gè) HTTP 請(qǐng)求后，在?60?秒內(nèi)都沒有再發(fā)起新的請(qǐng)求，定時(shí)器的時(shí)間一到，就會(huì)觸發(fā)回調(diào)函數(shù)來釋放該連接。
再比如：IM、消息推送系統(tǒng)里的心跳機(jī)制，通過應(yīng)用層的心跳機(jī)制（由客戶端發(fā)出，服務(wù)端回復(fù)響應(yīng)包），來靈活控制和探測長連接的健康度。
《為何基于TCP協(xié)議的移動(dòng)端IM仍然需要心跳?；顧C(jī)制？》這篇文章解釋了IM這類應(yīng)用中應(yīng)用層心跳?；畹谋匾裕信d趣可以讀一讀。
如果對(duì)應(yīng)用層心跳的具體應(yīng)用沒什么概念，可以看看微信的這兩篇文章：
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)?；顚?shí)戰(zhàn)分享(網(wǎng)絡(luò)?；钇?》
《移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》
下面有幾個(gè)針對(duì)im這類應(yīng)用的心跳實(shí)現(xiàn)代碼，可以具體感受學(xué)習(xí)一下：
《正確理解IM長連接的心跳及重連機(jī)制，并動(dòng)手實(shí)現(xiàn)（有完整IM源碼）》
《一種Android端IM智能心跳算法的設(shè)計(jì)與實(shí)現(xiàn)探討（含樣例代碼）》
《自已開發(fā)IM有那么難嗎？手把手教你自擼一個(gè)Andriod版簡易IM (有源碼)》
《手把手教你用Netty實(shí)現(xiàn)網(wǎng)絡(luò)通信程序的心跳機(jī)制、斷線重連機(jī)制》
6、本文小結(jié)
下面簡單總結(jié)一下文中的內(nèi)容，本文開頭的問題并不是簡單一句話能夠準(zhǔn)確說清楚的，需要分情況對(duì)待。
也就是：客戶端拔掉網(wǎng)線后，并不會(huì)直接影響 TCP 的連接狀態(tài)。所以拔掉網(wǎng)線后，TCP 連接是否還會(huì)存在，關(guān)鍵要看拔掉網(wǎng)線之后，有沒有進(jìn)行數(shù)據(jù)傳輸。
1）有數(shù)據(jù)傳輸?shù)那闆r：
在客戶端拔掉網(wǎng)線后：如果服務(wù)端發(fā)送了數(shù)據(jù)報(bào)文，那么在服務(wù)端重傳次數(shù)沒有達(dá)到最大值之前，客戶端恰好插回網(wǎng)線的話，那么雙方原本的 TCP 連接還是能存在并正常工作，就好像什么事情都沒有發(fā)生。
在客戶端拔掉網(wǎng)線后：如果服務(wù)端發(fā)送了數(shù)據(jù)報(bào)文，在客戶端插回網(wǎng)線之前，服務(wù)端重傳次數(shù)達(dá)到了最大值時(shí)，服務(wù)端就會(huì)斷開 TCP 連接。等到客戶端插回網(wǎng)線后，向服務(wù)端發(fā)送了數(shù)據(jù)，因?yàn)榉?wù)端已經(jīng)斷開了與客戶端相同四元組的 TCP 連接，所以就會(huì)回 RST 報(bào)文，客戶端收到后就會(huì)斷開 TCP 連接。至此， 雙方的 TCP 連接都斷開了。
2）沒有數(shù)據(jù)傳輸?shù)那闆r：
a.?如果雙方都沒有開啟 TCP keepalive 機(jī)制，那么在客戶端拔掉網(wǎng)線后，如果客戶端一直不插回網(wǎng)線，那么客戶端和服務(wù)端的 TCP 連接狀態(tài)將會(huì)一直保持存在；
b.?如果雙方都開啟了 TCP keepalive 機(jī)制，那么在客戶端拔掉網(wǎng)線后，如果客戶端一直不插回網(wǎng)線，TCP keepalive 機(jī)制會(huì)探測到對(duì)方的 TCP 連接沒有存活，于是就會(huì)斷開 TCP 連接。而如果在 TCP 探測期間，客戶端插回了網(wǎng)線，那么雙方原本的 TCP 連接還是能正常存在。
除了客戶端拔掉網(wǎng)線的場景，還有客戶端“宕機(jī)和殺死進(jìn)程”的兩種場景。
第一個(gè)場景：客戶端宕機(jī)這件事跟拔掉網(wǎng)線是一樣無法被服務(wù)端的感知的，所以如果在沒有數(shù)據(jù)傳輸，并且沒有開啟 TCP keepalive 機(jī)制時(shí)，，服務(wù)端的 TCP 連接將會(huì)一直處于?ESTABLISHED?連接狀態(tài)，直到服務(wù)端重啟進(jìn)程。
所以：我們可以得知一個(gè)點(diǎn)——在沒有使用 TCP 保活機(jī)制，且雙方不傳輸數(shù)據(jù)的情況下，一方的 TCP 連接處在?ESTABLISHED?狀態(tài)時(shí)，并不代表另一方的 TCP 連接還一定是正常的。
第二個(gè)場景：殺死客戶端的進(jìn)程后，客戶端的內(nèi)核就會(huì)向服務(wù)端發(fā)送 FIN 報(bào)文，與客戶端進(jìn)行四次揮手（見《跟著動(dòng)畫來學(xué)TCP三次握手和四次揮手》）。
所以：即使沒有開啟 TCP KeepAlive，且雙方也沒有數(shù)據(jù)交互的情況下，如果其中一方的進(jìn)程發(fā)生了崩潰，這個(gè)過程操作系統(tǒng)是可以感知的到的，于是就會(huì)發(fā)送 FIN 報(bào)文給對(duì)方，然后與對(duì)方進(jìn)行 TCP 四次揮手。
7、參考資料
[1]?TCP/IP詳解?-?第21章·TCP的超時(shí)與重傳
[2]?通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)
[3]?網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠
[4]?腦殘式網(wǎng)絡(luò)編程入門(一)：跟著動(dòng)畫來學(xué)TCP三次握手和四次揮手
[5]?腦殘式網(wǎng)絡(luò)編程入門(七)：面視必備，史上最通俗計(jì)算機(jī)網(wǎng)絡(luò)分層詳解
[6]?技術(shù)大牛陳碩的分享：由淺入深，網(wǎng)絡(luò)編程學(xué)習(xí)經(jīng)驗(yàn)干貨總結(jié)
[7]?網(wǎng)絡(luò)編程入門從未如此簡單(二)：假如你來設(shè)計(jì)TCP協(xié)議，會(huì)怎么做？
[8]?不為人知的網(wǎng)絡(luò)編程(十)：深入操作系統(tǒng)，從內(nèi)核理解網(wǎng)絡(luò)包的接收過程(Linux篇)
[9]?為何基于TCP協(xié)議的移動(dòng)端IM仍然需要心跳?；顧C(jī)制？
[10]?一文讀懂即時(shí)通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實(shí)現(xiàn)思路等
[11]?Web端即時(shí)通訊實(shí)踐干貨：如何讓你的WebSocket斷網(wǎng)重連更快速？
（本文同步發(fā)布于：http://www.52im.net/thread-3846-1-1.html）
