在线乱码卡一卡二卡新HD,最近韩国免费观看视频,国产色无码精品视频国产,亚洲男人的天堂久久香蕉

大家好，我是小林。

收到一位讀者的私信，說字節(jié)面試有這么一個問題：服務(wù)端掛了，客戶端的 TCP 連接會發(fā)生什么？

如果「服務(wù)端掛掉」指的是「

【資料圖】

但是，如果「服務(wù)端掛掉」指的是「

如果客戶端會發(fā)送數(shù)據(jù)，由于服務(wù)端已經(jīng)不存在，客戶端的數(shù)據(jù)報文會超時重傳，當重傳次數(shù)達到一定閾值后，會斷開 TCP 連接；如果客戶端一直不會發(fā)送數(shù)據(jù)，再看客戶端有沒有開啟 TCP keepalive 機制？

如果有開啟，客戶端在一段時間后，檢測到服務(wù)端的 TCP 連接已經(jīng)不存在，則會斷開自身的 TCP 連接；

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

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

服務(wù)端進程崩潰，客戶端會發(fā)生什么？

TCP 的連接信息是由內(nèi)核維護的，所以當服務(wù)端的進程崩潰后，內(nèi)核需要回收該進程的所有 TCP 連接資源，于是內(nèi)核會發(fā)送第一次揮手 FIN 報文，后續(xù)的揮手過程也都是在內(nèi)核完成，并不需要進程的參與，所以即使服務(wù)端的進程退出了，還是能與客戶端完成 TCP四次揮手的過程。

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

服務(wù)端主機宕機后，客戶端會發(fā)生什么？

當服務(wù)端的主機突然斷電了，這種情況就是屬于服務(wù)端主機宕機了。

當服務(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ù)報文。

當重傳次數(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))

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 ?；顧C制）。

如果沒有開啟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ù)端是否存活：

如果對端是正常工作的。當 TCP ?；畹奶綔y報文發(fā)送給對端, 對端會正常響應(yīng)，這樣TCP ?；顣r間會被重置，等待下一個 TCP ?；顣r間的到來。如果對端主機崩潰，或?qū)Χ擞捎谄渌驅(qū)е聢笪牟豢蛇_。當 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)，則認為當前的 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=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)，認為對方是不可達的，從而中斷本次的連接。

也就是說在 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ù)報文會超時重傳，當重傳總間隔時長達到一定閾值（內(nèi)核會根據(jù) tcp_retries2 設(shè)置的值計算出一個閾值）后，會斷開 TCP 連接；如果客戶端一直不會發(fā)送數(shù)據(jù)，再看客戶端有沒有開啟 TCP keepalive 機制？

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

如果沒有開啟，客戶端的 TCP 連接會一直存在，并且一直保持在 ESTABLISHED 狀態(tài)。

關(guān)鍵詞： 發(fā)送數(shù)據(jù) 應(yīng)用程序 一段時間 達到一定 已經(jīng)不存在