字節(jié)一面：服務(wù)端掛了，客戶端的 TCP 連接還在嗎？
收到一位讀者的私信，說字節(jié)面試有這么一個問題：服務(wù)端掛了，客戶端的 TCP 連接會發(fā)生什么？
如果「服務(wù)端掛掉」指的是「服務(wù)端進程崩潰」，那么這個讀者猜的想法是對的，服務(wù)端的進程在發(fā)生崩潰的時候，內(nèi)核會發(fā)送 FIN 報文，與客戶端進行四次揮手。
但是，如果「服務(wù)端掛掉」指的是「服務(wù)端主機宕機」，那么是不會發(fā)生四次揮手的，具體后續(xù)會發(fā)生什么？還要看客戶端會不會發(fā)送數(shù)據(jù)？
- 如果客戶端會發(fā)送數(shù)據(jù)，由于服務(wù)端已經(jīng)不存在，客戶端的數(shù)據(jù)報文會超時重傳，當(dāng)重傳次數(shù)達到一定閾值后，會斷開 TCP 連接；
- 如果客戶端一直不會發(fā)送數(shù)據(jù)，再看客戶端有沒有開啟 TCP keepalive 機制？
- 如果有開啟，客戶端在一段時間后，檢測到服務(wù)端的 TCP 連接已經(jīng)不存在，則會斷開自身的 TCP 連接；
- 如果沒有開啟，客戶端的 TCP 連接會一直存在，并不會斷開。
上面屬于精簡回答了，下面我們詳細(xì)聊聊。
服務(wù)端進程崩潰，客戶端會發(fā)生什么？
TCP 的連接信息是由內(nèi)核維護的，所以當(dāng)服務(wù)端的進程崩潰后，內(nèi)核需要回收該進程的所有 TCP 連接資源，于是內(nèi)核會發(fā)送第一次揮手 FIN 報文，后續(xù)的揮手過程也都是在內(nèi)核完成，并不需要進程的參與，所以即使服務(wù)端的進程退出了，還是能與客戶端完成 TCP四次揮手的過程。
我自己也做了實驗，使用 kill -9 命令來模擬進程崩潰的情況，發(fā)現(xiàn)在 kill 掉進程后，服務(wù)端會發(fā)送 FIN 報文，與客戶端進行四次揮手。
服務(wù)端主機宕機后，客戶端會發(fā)生什么？
當(dāng)服務(wù)端的主機突然斷電了，這種情況就是屬于服務(wù)端主機宕機了。
當(dāng)服務(wù)端的主機發(fā)生了宕機，是沒辦法和客戶端進行四次揮手的，所以在服務(wù)端主機發(fā)生宕機的那一時刻，客戶端是沒辦法立刻感知到服務(wù)端主機宕機了，只能在后續(xù)的數(shù)據(jù)交互中來感知服務(wù)端的連接已經(jīng)不存在了。
因此，我們要分兩種情況來討論：
- 服務(wù)端主機宕機后，客戶端會發(fā)送數(shù)據(jù)；
- 服務(wù)端主機宕機后，客戶端一直不會發(fā)送數(shù)據(jù)；
服務(wù)端主機宕機后，如果客戶端會發(fā)送數(shù)據(jù)
在服務(wù)端主機宕機后，客戶端發(fā)送了數(shù)據(jù)報文，由于得不到響應(yīng)，在等待一定時長后，客戶端就會觸發(fā)超時重傳機制，重傳未得到響應(yīng)的數(shù)據(jù)報文。
當(dāng)重傳次數(shù)達到達到一定閾值后，內(nèi)核就會判定出該 TCP 連接有問題，然后通過 Socket 接口告訴應(yīng)用程序該 TCP 連接出問題了，于是客戶端的 TCP 連接就會斷開。
那 TCP 的數(shù)據(jù)報文具體重傳幾次呢？
在 Linux 系統(tǒng)中，提供了一個叫 tcp_retries2 配置項，默認(rèn)值是 15，如下圖：
這個內(nèi)核參數(shù)是控制，在 TCP 連接建立的情況下，超時重傳的最大次數(shù)。
不過 tcp_retries2 設(shè)置了 15 次，并不代表 TCP 超時重傳了 15 次才會通知應(yīng)用程序終止該 TCP 連接，內(nèi)核會根據(jù) tcp_retries2 設(shè)置的值，計算出一個 timeout（如果 tcp_retries2 =15，那么計算得到的 timeout = 924600 ms），如果重傳間隔超過這個 timeout，則認(rèn)為超過了閾值，就會停止重傳，然后就會斷開 TCP 連接。
在發(fā)生超時重傳的過程中，每一輪的超時時間（RTO）都是倍數(shù)增長的，比如如果第一輪 RTO 是 200 毫秒，那么第二輪 RTO 是 400 毫秒，第三輪 RTO 是 800 毫秒，以此類推。
而 RTO 是基于 RTT（一個包的往返時間） 來計算的，如果 RTT 較大，那么計算出來的 RTO 就越大，那么經(jīng)過幾輪重傳后，很快就達到了上面的 timeout 值了。
舉個例子，如果 tcp_retries2 =15，那么計算得到的 timeout = 924600 ms，如果重傳總間隔時長達到了 timeout 就會停止重傳，然后就會斷開 TCP 連接：
- 如果 RTT 比較小，那么 RTO 初始值就約等于下限 200ms，也就是第一輪的超時時間是 200 毫秒，由于 timeout 總時長是 924600 ms，表現(xiàn)出來的現(xiàn)象剛好就是重傳了 15 次，超過了 timeout 值，從而斷開 TCP 連接
- 如果 RTT 比較大，假設(shè) RTO 初始值計算得到的是 1000 ms，也就是第一輪的超時時間是 1 秒，那么根本不需要重傳 15 次，重傳總間隔就會超過 924600 ms。
最小 RTO 和最大 RTO 是在 Linux 內(nèi)核中定義好了：
#define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5))
Linux 2.6+ 使用 1000 毫秒的 HZ，因此TCP_RTO_MIN約為 200 毫秒，TCP_RTO_MAX約為 120 秒。
如果tcp_retries設(shè)置為15，且 RTT 比較小，那么 RTO 初始值就約等于下限 200ms，這意味著它需要 924.6 秒才能將斷開的 TCP 連接通知給上層（即應(yīng)用程序），每一輪的 RTO 增長關(guān)系如下表格：
服務(wù)端主機宕機后，如果客戶端一直不發(fā)數(shù)據(jù)
服務(wù)端主機宕機后，如果客戶端一直不發(fā)數(shù)據(jù)
在服務(wù)端主機發(fā)送宕機后，如果客戶端一直不發(fā)送數(shù)據(jù)，那么還得看是否開啟了 TCP keepalive 機制 （TCP ?；顧C制）。
如果沒有開啟 TCP keepalive 機制，在服務(wù)端主機發(fā)送宕機后，如果客戶端一直不發(fā)送數(shù)據(jù)，那么客戶端的 TCP 連接將一直保持存在，所以我們可以得知一個點，在沒有使用 TCP 保活機制，且雙方不傳輸數(shù)據(jù)的情況下，一方的 TCP 連接處在 ESTABLISHED 狀態(tài)時，并不代表另一方的 TCP 連接還一定是正常的。
而如果開啟了 TCP keepalive 機制，在服務(wù)端主機發(fā)送宕機后，即使客戶端一直不發(fā)送數(shù)據(jù)，在持續(xù)一段時間后，TCP 就會發(fā)送探測報文，探測服務(wù)端是否存活：
-
如果對端是正常工作的。當(dāng) TCP ?；畹奶綔y報文發(fā)送給對端, 對端會正常響應(yīng)，這樣 TCP 保活時間會被重置，等待下一個 TCP ?；顣r間的到來。 -
如果對端主機崩潰，或?qū)Χ擞捎谄渌驅(qū)е聢笪牟豢蛇_。當(dāng) TCP ?；畹奶綔y報文發(fā)送給對端后，石沉大海，沒有響應(yīng)，連續(xù)幾次，達到?；钐綔y次數(shù)后，TCP 會報告該 TCP 連接已經(jīng)死亡。
所以，TCP keepalive 機制可以在雙方?jīng)]有數(shù)據(jù)交互的情況，通過探測報文，來確定對方的 TCP 連接是否存活。
TCP keepalive 機制具體是怎么樣的？
TCP keepalive 機制機制的原理是這樣的：
定義一個時間段，在這個時間段內(nèi)，如果沒有任何連接相關(guān)的活動，TCP ?；顧C制會開始作用，每隔一個時間間隔，發(fā)送一個探測報文，該探測報文包含的數(shù)據(jù)非常少，如果連續(xù)幾個探測報文都沒有得到響應(yīng)，則認(rèn)為當(dāng)前的 TCP 連接已經(jīng)死亡，系統(tǒng)內(nèi)核將錯誤信息通知給上層應(yīng)用程序。
在 Linux 內(nèi)核可以有對應(yīng)的參數(shù)可以設(shè)置?；顣r間、?；钐綔y的次數(shù)、保活探測的時間間隔，以下都為默認(rèn)值：
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9
每個參數(shù)的意思，具體如下：
-
tcp_keepalive_time=7200：表示?；顣r間是 7200 秒（2小時），也就 2 小時內(nèi)如果沒有任何連接相關(guān)的活動，則會啟動?；顧C制
-
tcp_keepalive_intvl=75：表示每次檢測間隔 75 秒；
-
tcp_keepalive_probes=9：表示檢測 9 次無響應(yīng)，認(rèn)為對方是不可達的，從而中斷本次的連接。
也就是說在 Linux 系統(tǒng)中，最少需要經(jīng)過 2 小時 11 分 15 秒才可以發(fā)現(xiàn)一個「死亡」連接。
注意，應(yīng)用程序如果想使用 TCP 保活機制，需要通過 socket 接口設(shè)置 SO_KEEPALIVE選項才能夠生效，如果沒有設(shè)置，那么就無法使用 TCP ?；顧C制。
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ù)來釋放該連接。
總結(jié)
如果「服務(wù)端掛掉」指的是「服務(wù)端進程崩潰」，服務(wù)端的進程在發(fā)生崩潰的時候，內(nèi)核會發(fā)送 FIN 報文，與客戶端進行四次揮手。
但是，如果「服務(wù)端掛掉」指的是「服務(wù)端主機宕機」，那么是不會發(fā)生四次揮手的，具體后續(xù)會發(fā)生什么？還要看客戶端會不會發(fā)送數(shù)據(jù)？
-
如果客戶端會發(fā)送數(shù)據(jù)，由于服務(wù)端已經(jīng)不存在，客戶端的數(shù)據(jù)報文會超時重傳，當(dāng)重傳總間隔時長達到一定閾值（內(nèi)核會根據(jù) tcp_retries2 設(shè)置的值計算出一個閾值）后，會斷開 TCP 連接；
-
如果客戶端一直不會發(fā)送數(shù)據(jù)，再看客戶端有沒有開啟 TCP keepalive 機制？
-
如果有開啟，客戶端在一段時間沒有進行數(shù)據(jù)交互時，會觸發(fā) TCP keepalive 機制，探測對方是否存在，如果探測到對方已經(jīng)消亡，則會斷開自身的 TCP 連接；
-
如果沒有開啟，客戶端的 TCP 連接會一直存在，并且一直保持在 ESTABLISHED 狀態(tài)。
還有另外一個很有意思的問題：「拔掉網(wǎng)線幾秒，再插回去，原本的 TCP 連接還存在嗎？」，之前我也寫過，可以參考這篇：拔掉網(wǎng)線幾秒，原本的 TCP 連接還存在嗎？
完！
下載文檔
