今天，聊一個(gè)有趣的問題：拔掉網(wǎng)線幾秒，再插回去，原本的 TCP 連接還存在嗎？
可能有的同學(xué)會(huì)說，網(wǎng)線都被拔掉了，那說明物理層被斷開了，那在上層的傳輸層理應(yīng)也會(huì)斷開，所以原本的 TCP 連接就不會(huì)存在的了。就好像， 我們撥打有線電話的時(shí)候，如果某一方的電話線被拔了，那么本次通話就徹底斷了。
真的是這樣嗎？
上面這個(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ā)生改變。
我在我的電腦上做了個(gè)小實(shí)驗(yàn)，我用 ssh 終端連接了我的云服務(wù)器，然后我通過斷開 wifi 的方式來模擬拔掉網(wǎng)線的場景，此時(shí)查看 TCP 連接的狀態(tài)沒有發(fā)生變化，還是處于 ESTABLISHED 狀態(tài)。
通過上面這個(gè)實(shí)驗(yàn)結(jié)果，我們知道了，拔掉網(wǎng)線這個(gè)動(dòng)作并不會(huì)影響 TCP 連接的狀態(tài)。
接下來，要看拔掉網(wǎng)線后，雙方做了什么動(dòng)作。
所以， 針對這個(gè)問題，要分場景來討論：
拔掉網(wǎng)線后，有數(shù)據(jù)傳輸；
拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸；
拔掉網(wǎng)線后，有數(shù)據(jù)傳輸
在客戶端拔掉網(wǎng)線后，服務(wù)端向客戶端發(fā)送的數(shù)據(jù)報(bào)文會(huì)得不到任何的響應(yīng)，在等待一定時(shí)長后，服務(wù)端就會(huì)觸發(fā)超時(shí)重傳機(jī)制，重傳未得到響應(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 連接依然存在的，就感覺什么事情都沒有發(fā)生。
但是，如果如果在服務(wù)端重傳報(bào)文的過程中，客戶端一直沒有將網(wǎng)線插回去，服務(wù)端超時(shí)重傳報(bào)文的次數(shù)達(dá)到一定閾值后，內(nèi)核就會(huì)判定出該 TCP 有問題，然后通過 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)斷開了。
那 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)文且一直沒有收到對方響應(yīng)的情況時(shí)，先達(dá)到「最大重傳次數(shù)」或者「最大超時(shí)時(shí)間」這兩個(gè)的其中一個(gè)條件后，就會(huì)停止重傳，然后就會(huì)斷開 TCP 連接。
拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸
針對拔掉網(wǎng)線后，沒有數(shù)據(jù)傳輸?shù)膱鼍?，還得看是否開啟了 TCP keepalive 機(jī)制 （TCP ?；顧C(jī)制）。
如果沒有開啟?TCP keepalive 機(jī)制，在客戶端拔掉網(wǎng)線后，并且雙方都沒有進(jìn)行數(shù)據(jù)傳輸，那么客戶端和服務(wù)端的 TCP 連接將會(huì)一直保持存在。
而如果開啟了 TCP keepalive 機(jī)制，在客戶端拔掉網(wǎng)線后，即使雙方都沒有進(jìn)行數(shù)據(jù)傳輸，在持續(xù)一段時(shí)間后，TCP 就會(huì)發(fā)送探測報(bào)文：
如果對端是正常工作的。當(dāng) TCP ?；畹奶綔y報(bào)文發(fā)送給對端, 對端會(huì)正常響應(yīng)，這樣?TCP ?；顣r(shí)間會(huì)被重置，等待下一個(gè) TCP ?；顣r(shí)間的到來。
如果對端主機(jī)崩潰，或?qū)Χ擞捎谄渌驅(qū)е聢?bào)文不可達(dá)。當(dāng) TCP ?；畹奶綔y報(bào)文發(fā)送給對端后，石沉大海，沒有響應(yīng)，連續(xù)幾次，達(dá)到?；钐綔y次數(shù)后，TCP 會(huì)報(bào)告該 TCP 連接已經(jīng)死亡。
所以，TCP 保活機(jī)制可以在雙方?jīng)]有數(shù)據(jù)交互的情況，通過探測報(bào)文，來確定對方的 TCP 連接是否存活。
TCP keepalive 機(jī)制具體是怎么樣的？
這個(gè)機(jī)制的原理是這樣的：
定義一個(gè)時(shí)間段，在這個(gè)時(shí)間段內(nèi)，如果沒有任何連接相關(guān)的活動(dòng)，TCP ?；顧C(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)核可以有對應(yīng)的參數(shù)可以設(shè)置?；顣r(shí)間、?；钐綔y的次數(shù)、?；钐綔y的時(shí)間間隔，以下都為默認(rèn)值：
??
? ? ? ?tcp_keepalive_time=7200：表示?；顣r(shí)間是 7200 秒（2小時(shí)），也就 2 小時(shí)內(nèi)如果沒有任何連接相關(guān)的活動(dòng)，則會(huì)啟動(dòng)?；顧C(jī)制
? ? ? ? tcp_keepalive_intvl=75：表示每次檢測間隔 75 秒；
? ? ? ? tcp_keepalive_probes=9：表示檢測 9 次無響應(yīng)，認(rèn)為對方是不可達(dá)的，從而中斷本次的連接。
也就是說在 Linux 系統(tǒng)中，最少需要經(jīng)過 2 小時(shí) 11 分 15 秒才可以發(fā)現(xiàn)一個(gè)「死亡」連接。
注意，應(yīng)用程序若想使用 TCP 保活機(jī)制需要通過 socket 接口設(shè)置?SO_KEEPALIVE?選項(xiàng)才能夠生效，如果沒有設(shè)置，那么就無法使用 TCP 保活機(jī)制。
TCP keepalive 機(jī)制探測的時(shí)間也太長了吧？
對的，是有點(diǎn)長。
TCP keepalive 是?TCP 層（內(nèi)核態(tài)）?實(shí)現(xiàn)的，它是給所有基于 TCP 傳輸協(xié)議的程序一個(gè)兜底的方案。
實(shí)際上，我們應(yīng)用層可以自己實(shí)現(xiàn)一套探測機(jī)制，可以在較短的時(shí)間內(nèi)，探測到對方是否存活。
比如，web 服務(wù)軟件一般都會(huì)提供?keepalive_timeout?參數(shù)，用來指定 HTTP 長連接的超時(shí)時(shí)間。如果設(shè)置了 HTTP 長連接的超時(shí)時(shí)間是 60 秒，web 服務(wù)軟件就會(huì)啟動(dòng)一個(gè)定時(shí)器，如果客戶端在完后一個(gè) HTTP 請求后，在 60 秒內(nèi)都沒有再發(fā)起新的請求，定時(shí)器的時(shí)間一到，就會(huì)觸發(fā)回調(diào)函數(shù)來釋放該連接。
總結(jié)
客戶端拔掉網(wǎng)線后，并不會(huì)直接影響 TCP 連接狀態(tài)。所以，拔掉網(wǎng)線后，TCP 連接是否還會(huì)存在，關(guān)鍵要看拔掉網(wǎng)線之后，有沒有進(jìn)行數(shù)據(jù)傳輸。
有數(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 連接都斷開了。
沒有數(shù)據(jù)傳輸?shù)那闆r：
如果雙方都沒有開啟 TCP keepalive 機(jī)制，那么在客戶端拔掉網(wǎng)線后，如果客戶端一直不插回網(wǎng)線，那么客戶端和服務(wù)端的 TCP 連接狀態(tài)將會(huì)一直保持存在。
如果雙方都開啟了 TCP keepalive 機(jī)制，那么在客戶端拔掉網(wǎng)線后，如果客戶端一直不插回網(wǎng)線，TCP keepalive 機(jī)制會(huì)探測到對方的 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)行四次揮手。
所以，即使沒有開啟 TCP keepalive，且雙方也沒有數(shù)據(jù)交互的情況下，如果其中一方的進(jìn)程發(fā)生了崩潰，這個(gè)過程操作系統(tǒng)是可以感知的到的，于是就會(huì)發(fā)送 FIN 報(bào)文給對方，然后與對方進(jìn)行 TCP 四次揮手。
