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