服務(wù)端掛了,客戶端的 TCP 連接還在嗎?
大家好,我是小林。
收到一位讀者的私信,說字節(jié)面試有這么一個問題:服務(wù)端掛了,客戶端的 TCP 連接會發(fā)生什么?
如果「服務(wù)端掛掉」指的是「
但是,如果「服務(wù)端掛掉」指的是「
- 如果客戶端會發(fā)送數(shù)據(jù),由于服務(wù)端已經(jīng)不存在,客戶端的數(shù)據(jù)報文會超時重傳,當(dāng)重傳次數(shù)達到一定閾值后,會斷開 TCP 連接;
- 如果客戶端一直不會發(fā)送數(shù)據(jù),再看客戶端有沒有開啟 TCP keepalive 機制?
如果有開啟,客戶端在一段時間后,檢測到服務(wù)端的 TCP 連接已經(jīng)不存在,則會斷開自身的 TCP 連接;
如果沒有開啟,客戶端的 TCP 連接會一直存在,并不會斷開。
上面屬于精簡回答了,下面我們詳細聊聊。
服務(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 配置項,默認值是 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,則認為超過了閾值,就會停止重傳,然后就會斷開 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))1.2.
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ā)送宕機后,如果客戶端一直不發(fā)送數(shù)據(jù),那么還得看是否開啟了 TCP keepalive 機制 (TCP 保活機制)。
如果沒有開啟 TCP keepalive 機制,在服務(wù)端主機發(fā)送宕機后,如果客戶端一直不發(fā)送數(shù)據(jù),那么客戶端的 TCP 連接將一直保持存在,所以我們可以得知一個點,在沒有使用 TCP ?;顧C制,且雙方不傳輸數(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 ?;顣r間會被重置,等待下一個 TCP ?;顣r間的到來。
- 如果對端主機崩潰,或?qū)Χ擞捎谄渌驅(qū)е聢笪牟豢蛇_。當(dāng) TCP 保活的探測報文發(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),則認為當(dāng)前的 TCP 連接已經(jīng)死亡,系統(tǒng)內(nèi)核將錯誤信息通知給上層應(yīng)用程序。
在 Linux 內(nèi)核可以有對應(yīng)的參數(shù)可以設(shè)置?;顣r間、?;钐綔y的次數(shù)、?;钐綔y的時間間隔,以下都為默認值:
net.ipv4.tcp_keepalive_time=7200net.ipv4.tcp_keepalive_intvl=75 net.ipv4.tcp_keepalive_probes=91.2.3.
每個參數(shù)的意思,具體如下:
- tcp_keepalive_time=7200:表示?;顣r間是 7200 秒(2小時),也就 2 小時內(nèi)如果沒有任何連接相關(guān)的活動,則會啟動保活機制
- tcp_keepalive_intvl=75:表示每次檢測間隔 75 秒;
- tcp_keepalive_probes=9:表示檢測 9 次無響應(yīng),認為對方是不可達的,從而中斷本次的連接。
也就是說在 Linux 系統(tǒng)中,最少需要經(jīng)過 2 小時 11 分 15 秒才可以發(fā)現(xiàn)一個「死亡」連接。
注意,應(yīng)用程序如果想使用 TCP 保活機制,需要通過 socket 接口設(shè)置 SO_KEEPALIVE 選項才能夠生效,如果沒有設(shè)置,那么就無法使用 TCP 保活機制。
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)。