大家好，我是小林。
收到一位讀者的私信，說字節面試有這么一個問題：服務端掛了，客戶端的 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 狀態。
