本文由作者小林coding分享，來自公號“小林coding”，有修訂和改動。
1、引言
說到TCP協議，對于從事即時通訊/IM這方面應用的開發者們來說，再熟悉不過了。隨著對TCP理解的越來越深入，很多曾今碰到過但沒時間深入探究的TCP技術概念或疑問，現在是時候回頭來惡補一下了。
本篇文章，我們就從系統層面深入地探討一個有趣的TCP技術問題：拔掉網線后，再插上，原本的這條TCP連接還在嗎？或者說它還“好”嗎？
可能有的人會說：網線都被拔掉了，那說明物理層（也叫實體層）被斷開了（關于網絡協議分層模型請見《快速理解網絡通信協議（上篇）》），那在物理層之上的傳輸層理應也會斷開，所以原本的 TCP 連接就不會存在的了。就好像我們撥打有線電話的時候，如果某一方的電話線被拔了，那么本次通話就徹底斷了。
答案真的是這樣嗎？可能并非你理解的這樣哦，一起跟隨筆者來深入探討一下。
2、系列文章
本文是系列文章中的第14篇，本系列文章的大綱如下：
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-3846-1-1.html）