大家好，我是小林。

收到一位讀者的私信，說字節面試有這麼一個問題：服務端掛了，客戶端的TCP 連接會發生什麼？

如果「服務端掛掉」指的是「

但是，如果「服務端掛掉」指的是「

• 如果客戶端會發送數據，由於服務端已經不存在，客戶端的數據報文會超時重傳，當重傳次數達到一定閾值後，會斷開TCP 連接；
• 如果客戶端一直不會發送數據，再看客戶端有沒有開啟TCP keepalive 機制？

如果有開啟，客戶端在一段時間後，檢測到服務端的TCP 連接已經不存在，則會斷開自身的TCP 連接；

如果沒有開啟，客戶端的TCP 連接會一直存在，並不會斷開。

上面屬於精簡回答了，下面我們詳細聊聊。

服務端進程崩潰，客戶端會發生什麼？

TCP 的連接信息是由內核維護的，所以當服務端的進程崩潰後，內核需要回收該進程的所有TCP 連接資源，於是內核會發送第一次揮手FIN 報文，後續的揮手過程也都是在內核完成，並不需要進程的參與，所以即使服務端的進程退出了，還是能與客戶端完成TCP四次揮手的過程。

我自己也做了實驗，使用kill -9 命令來模擬進程崩潰的情況，發現在kill 掉進程後，服務端會發送FIN 報文，與客戶端進行四次揮手。

服務端主機宕機後，客戶端會發生什麼？

當服務端的主機突然斷電了，這種情況就是屬於服務端主機宕機了。

當服務端的主機發生了宕機，是沒辦法和客戶端進行四次揮手的，所以在服務端主機發生宕機的那一時刻，客戶端是沒辦法立刻感知到服務端主機宕機了，只能在後續的數據交互中來感知服務端的連接已經不存在了。

因此，我們要分兩種情況來討論：

• 服務端主機宕機後，客戶端會發送數據；
• 服務端主機宕機後，客戶端一直不會發送數據；

服務端主機宕機後，如果客戶端會發送數據

在服務端主機宕機後，客戶端發送了數據報文，由於得不到響應，在等待一定時長後，客戶端就會觸發超時重傳機制，重傳未得到響應的數據報文。

當重傳次數達到達到一定閾值後，內核就會判定出該TCP 連接有問題，然後通過Socket 接口告訴應用程序該TCP 連接出問題了，於是客戶端的TCP 連接就會斷開。

那TCP 的數據報文具體重傳幾次呢？

在Linux 系統中，提供了一個叫tcp_retries2 配置項，默認值是15，如下圖：

這個內核參數是控制，在TCP 連接建立的情況下，超時重傳的最大次數。

不過tcp_retries2 設置了15 次，並不代表TCP 超時重傳了15 次才會通知應用程序終止該TCP 連接，內核會根據tcp_retries2 設置的值，計算出一個timeout（如果tcp_retries2 =15，那麼計算得到的timeout = 924600 ms），如果重傳間隔超過這個timeout，則認為超過了閾值，就會停止重傳，然後就會斷開TCP 連接。

在發生超時重傳的過程中，每一輪的超時時間（RTO）都是倍數增長的，比如如果第一輪RTO 是200 毫秒，那麼第二輪RTO 是400 毫秒，第三輪RTO 是800 毫秒，以此類推。

而RTO 是基於RTT（一個包的往返時間） 來計算的，如果RTT 較大，那麼計算出來的RTO 就越大，那麼經過幾輪重傳後，很快就達到了上面的timeout 值了。

舉個例子，如果tcp_retries2 =15，那麼計算得到的timeout = 924600 ms，如果重傳總間隔時長達到了timeout 就會停止重傳，然後就會斷開TCP 連接：

• 如果RTT 比較小，那麼RTO 初始值就約等於下限200ms，也就是第一輪的超時時間是200 毫秒，由於timeout 總時長是924600 ms，表現出來的現像剛好就是重傳了15 次，超過了timeout 值，從而斷開TCP 連接
• 如果RTT 比較大，假設RTO 初始值計算得到的是1000 ms，也就是第一輪的超時時間是1 秒，那麼根本不需要重傳15 次，重傳總間隔就會超過924600 ms。

最小RTO 和最大RTO 是在Linux 內核中定義好了：

#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_RTO_MIN ((unsigned)(HZ/5))
1.
2.

Linux 2.6+ 使用1000 毫秒的HZ，因此TCP_RTO_MIN​約為200 毫秒，TCP_RTO_MAX約為120 秒。

如果tcp_retries​設置為15，且 RTT 比較小，那麼RTO 初始值就約等於下限200ms，這意味著它需要924.6 秒才能將斷開的TCP 連接通知給上層（即應用程序），每一輪的RTO 增長關係如下表格：

服務端主機宕機後，如果客戶端一直不發數據

在服務端主機發送宕機後，如果客戶端一直不發送數據，那麼還得看是否開啟了TCP keepalive 機制（TCP 保活機制）。

如果沒有開啟 TCP keepalive 機制，在服務端主機發送宕機後，如果客戶端一直不發送數據，那麼客戶端的TCP 連接將一直保持存在，所以我們可以得知一個點，在沒有使用TCP 保活機制，且雙方不傳輸數據的情況下，一方的TCP 連接處在ESTABLISHED 狀態時，並不代表另一方的TCP 連接還一定是正常的。

而如果開啟了TCP keepalive 機制，在服務端主機發送宕機後，即使客戶端一直不發送數據，在持續一段時間後，TCP 就會發送探測報文，探測服務端是否存活：

• 如果對端是正常工作的。當TCP 保活的探測報文發送給對端, 對端會正常響應，這樣TCP 保活時間會被重置，等待下一個TCP 保活時間的到來。
• 如果對端主機崩潰，或對端由於其他原因導致報文不可達。當TCP 保活的探測報文發送給對端后，石沉大海，沒有響應，連續幾次，達到保活探測次數後，TCP 會報告該TCP 連接已經死亡。

所以，TCP keepalive 機制可以在雙方沒有數據交互的情況，通過探測報文，來確定對方的TCP 連接是否存活。

TCP keepalive 機制具體是怎麼樣的？

TCP keepalive 機制機制的原理是這樣的：

定義一個時間段，在這個時間段內，如果沒有任何連接相關的活動，TCP 保活機制會開始作用，每隔一個時間間隔，發送一個探測報文，該探測報文包含的數據非常少，如果連續幾個探測報文都沒有得到響應，則認為當前的TCP 連接已經死亡，系統內核將錯誤信息通知給上層應用程序。

在Linux 內核可以有對應的參數可以設置保活時間、保活探測的次數、保活探測的時間間隔，以下都為默認值：

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9
1.
2.
3.

每個參數的意思，具體如下：

• tcp_keepalive_time=7200：表示保活時間是7200 秒（2小時），也就2 小時內如果沒有任何連接相關的活動，則會啟動保活機制
• tcp_keepalive_intvl=75：表示每次檢測間隔75 秒；
• tcp_keepalive_probes=9：表示檢測9 次無響應，認為對方是不可達的，從而中斷本次的連接。

也就是說在Linux 系統中，最少需要經過2 小時11 分15 秒才可以發現一個「死亡」連接。

注意，應用程序如果想使用TCP 保活機制，需要通過socket 接口設置 SO_KEEPALIVE 選項才能夠生效，如果沒有設置，那麼就無法使用TCP 保活機制。

TCP keepalive 機制探測的時間也太長了吧？

對的，是有點長。

TCP keepalive 是 TCP 層（內核態） 實現的，它是給所有基於TCP 傳輸協議的程序一個兜底的方案。

實際上，我們應用層可以自己實現一套探測機制，可以在較短的時間內，探測到對方是否存活。

比如，web 服務軟件一般都會提供 keepalive_timeout 參數，用來指定HTTP 長連接的超時時間。如果設置了HTTP 長連接的超時時間是60 秒，web 服務軟件就會啟動一個定時器，如果客戶端在完後一個HTTP 請求後，在60 秒內都沒有再發起新的請求，定時器的時間一到，就會觸發回調函數來釋放該連接。

總結

如果「服務端掛掉」指的是「服務端進程崩潰」，服務端的進程在發生崩潰的時候，內核會發送FIN 報文，與客戶端進行四次揮手。

但是，如果「服務端掛掉」指的是「服務端主機宕機」，那麼是不會發生四次揮手的，具體後續會發生什麼？還要看客戶端會不會發送數據？

• 如果客戶端會發送數據，由於服務端已經不存在，客戶端的數據報文會超時重傳，當重傳總間隔時長達到一定閾值（內核會根據tcp_retries2 設置的值計算出一個閾值）後，會斷開TCP 連接；
• 如果客戶端一直不會發送數據，再看客戶端有沒有開啟TCP keepalive 機制？

如果有開啟，客戶端在一段時間沒有進行數據交互時，會觸發TCP keepalive 機制，探測對方是否存在，如果探測到對方已經消亡，則會斷開自身的TCP 連接；

如果沒有開啟，客戶端的TCP 連接會一直存在，並且一直保持在ESTABLISHED 狀態。