自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

拔掉網(wǎng)線后, 原本的 TCP 連接還存在嗎?

網(wǎng)絡(luò) 通信技術(shù)
客戶(hù)端拔掉網(wǎng)線后,并不會(huì)直接影響 TCP 連接狀態(tài)。所以,拔掉網(wǎng)線后,TCP 連接是否還會(huì)存在,關(guān)鍵要看拔掉網(wǎng)線之后,有沒(méi)有進(jìn)行數(shù)據(jù)傳輸。

大家好,我是小林。

今天,聊一個(gè)有趣的問(wèn)題:拔掉網(wǎng)線幾秒,再插回去,原本的 TCP 連接還存在嗎?

可能有的同學(xué)會(huì)說(shuō),網(wǎng)線都被拔掉了,那說(shuō)明物理層被斷開(kāi)了,那在上層的傳輸層理應(yīng)也會(huì)斷開(kāi),所以原本的 TCP 連接就不會(huì)存在的了。就好像, 我們撥打有線電話的時(shí)候,如果某一方的電話線被拔了,那么本次通話就徹底斷了。

真的是這樣嗎?

上面這個(gè)邏輯就有問(wèn)題。問(wèn)題在于,錯(cuò)誤的認(rèn)為拔掉網(wǎng)線這個(gè)動(dòng)作會(huì)影響傳輸層,事實(shí)上并不會(huì)影響。

實(shí)際上,TCP 連接在 Linux 內(nèi)核中是一個(gè)名為 struct socket 的結(jié)構(gòu)體,該結(jié)構(gòu)體的內(nèi)容包含 TCP 連接的狀態(tài)等信息。當(dāng)拔掉網(wǎng)線的時(shí)候,操作系統(tǒng)并不會(huì)變更該結(jié)構(gòu)體的任何內(nèi)容,所以 TCP 連接的狀態(tài)也不會(huì)發(fā)生改變。

我在我的電腦上做了個(gè)小實(shí)驗(yàn),我用 ssh 終端連接了我的云服務(wù)器,然后我通過(guò)斷開(kāi) wifi 的方式來(lái)模擬拔掉網(wǎng)線的場(chǎng)景,此時(shí)查看 TCP 連接的狀態(tài)沒(méi)有發(fā)生變化,還是處于 ESTABLISHED 狀態(tài)。

通過(guò)上面這個(gè)實(shí)驗(yàn)結(jié)果,我們知道了,拔掉網(wǎng)線這個(gè)動(dòng)作并不會(huì)影響 TCP 連接的狀態(tài)。

接下來(lái),要看拔掉網(wǎng)線后,雙方做了什么動(dòng)作。

所以, 針對(duì)這個(gè)問(wèn)題,要分場(chǎng)景來(lái)討論:

  • 拔掉網(wǎng)線后,有數(shù)據(jù)傳輸;
  • 拔掉網(wǎng)線后,沒(méi)有數(shù)據(jù)傳輸;

拔掉網(wǎng)線后,有數(shù)據(jù)傳輸

在客戶(hù)端拔掉網(wǎng)線后,服務(wù)端向客戶(hù)端發(fā)送的數(shù)據(jù)報(bào)文會(huì)得不到任何的響應(yīng),在等待一定時(shí)長(zhǎng)后,服務(wù)端就會(huì)觸發(fā)超時(shí)重傳機(jī)制,重傳未得到響應(yīng)的數(shù)據(jù)報(bào)文。

如果在服務(wù)端重傳報(bào)文的過(guò)程中,客戶(hù)端剛好把網(wǎng)線插回去了,由于拔掉網(wǎng)線并不會(huì)改變客戶(hù)端的 TCP 連接狀態(tài),并且還是處于 ESTABLISHED 狀態(tài),所以這時(shí)客戶(hù)端是可以正常接收服務(wù)端發(fā)來(lái)的數(shù)據(jù)報(bào)文的,然后客戶(hù)端就會(huì)回 ACK 響應(yīng)報(bào)文。

此時(shí),客戶(hù)端和服務(wù)端的 TCP 連接依然存在的,就感覺(jué)什么事情都沒(méi)有發(fā)生。

但是,如果如果在服務(wù)端重傳報(bào)文的過(guò)程中,客戶(hù)端一直沒(méi)有將網(wǎng)線插回去,服務(wù)端超時(shí)重傳報(bào)文的次數(shù)達(dá)到一定閾值后,內(nèi)核就會(huì)判定出該 TCP 有問(wèn)題,然后通過(guò) Socket 接口告訴應(yīng)用程序該 TCP 連接出問(wèn)題了,于是服務(wù)端的 TCP 連接就會(huì)斷開(kāi)。

而等客戶(hù)端插回網(wǎng)線后,如果客戶(hù)端向服務(wù)端發(fā)送了數(shù)據(jù),由于服務(wù)端已經(jīng)沒(méi)有與客戶(hù)端相同四元祖的 TCP 連接了,因此服務(wù)端內(nèi)核就會(huì)回復(fù) RST 報(bào)文,客戶(hù)端收到后就會(huì)釋放該 TCP 連接。

此時(shí),客戶(hù)端和服務(wù)端的 TCP 連接都已經(jīng)斷開(kāi)了。

那 TCP 的數(shù)據(jù)報(bào)文具體重傳幾次呢?

在 Linux 系統(tǒng)中,提供了一個(gè)叫 tcp_retries2 配置項(xiàng),默認(rèn)值是 15,如下圖:

這個(gè)內(nèi)核參數(shù)是控制,在 TCP 連接建立的情況下,超時(shí)重傳的最大次數(shù)。

不過(guò) tcp_retries2 設(shè)置了 15 次,并不代表 TCP 超時(shí)重傳了 15 次才會(huì)通知應(yīng)用程序終止該 TCP 連接,內(nèi)核還會(huì)基于「最大超時(shí)時(shí)間」來(lái)判定。

每一輪的超時(shí)時(shí)間都是倍數(shù)增長(zhǎng)的,比如第一次觸發(fā)超時(shí)重傳是在 2s 后,第二次則是在 4s 后,第三次則是 8s 后,以此類(lèi)推。

內(nèi)核會(huì)根據(jù) tcp_retries2 設(shè)置的值,計(jì)算出一個(gè)最大超時(shí)時(shí)間。

在重傳報(bào)文且一直沒(méi)有收到對(duì)方響應(yīng)的情況時(shí),先達(dá)到「最大重傳次數(shù)」或者「最大超時(shí)時(shí)間」這兩個(gè)的其中一個(gè)條件后,就會(huì)停止重傳,然后就會(huì)斷開(kāi) TCP 連接。

拔掉網(wǎng)線后,沒(méi)有數(shù)據(jù)傳輸

針對(duì)拔掉網(wǎng)線后,沒(méi)有數(shù)據(jù)傳輸?shù)膱?chǎng)景,還得看是否開(kāi)啟了 TCP keepalive 機(jī)制 (TCP 保活機(jī)制)。

如果沒(méi)有開(kāi)啟 TCP keepalive 機(jī)制,在客戶(hù)端拔掉網(wǎng)線后,并且雙方都沒(méi)有進(jìn)行數(shù)據(jù)傳輸,那么客戶(hù)端和服務(wù)端的 TCP 連接將會(huì)一直保持存在。

而如果開(kāi)啟了 TCP keepalive 機(jī)制,在客戶(hù)端拔掉網(wǎng)線后,即使雙方都沒(méi)有進(jìn)行數(shù)據(jù)傳輸,在持續(xù)一段時(shí)間后,TCP 就會(huì)發(fā)送探測(cè)報(bào)文:

  • 如果對(duì)端是正常工作的。當(dāng) TCP ?;畹奶綔y(cè)報(bào)文發(fā)送給對(duì)端, 對(duì)端會(huì)正常響應(yīng),這樣 TCP 保活時(shí)間會(huì)被重置,等待下一個(gè) TCP 保活時(shí)間的到來(lái)。
  • 如果對(duì)端主機(jī)崩潰,或?qū)Χ擞捎谄渌驅(qū)е聢?bào)文不可達(dá)。當(dāng) TCP 保活的探測(cè)報(bào)文發(fā)送給對(duì)端后,石沉大海,沒(méi)有響應(yīng),連續(xù)幾次,達(dá)到?;钐綔y(cè)次數(shù)后,TCP 會(huì)報(bào)告該 TCP 連接已經(jīng)死亡。

所以,TCP ?;顧C(jī)制可以在雙方?jīng)]有數(shù)據(jù)交互的情況,通過(guò)探測(cè)報(bào)文,來(lái)確定對(duì)方的 TCP 連接是否存活。

TCP keepalive 機(jī)制具體是怎么樣的?

這個(gè)機(jī)制的原理是這樣的:

定義一個(gè)時(shí)間段,在這個(gè)時(shí)間段內(nèi),如果沒(méi)有任何連接相關(guān)的活動(dòng),TCP ?;顧C(jī)制會(huì)開(kāi)始作用,每隔一個(gè)時(shí)間間隔,發(fā)送一個(gè)探測(cè)報(bào)文,該探測(cè)報(bào)文包含的數(shù)據(jù)非常少,如果連續(xù)幾個(gè)探測(cè)報(bào)文都沒(méi)有得到響應(yīng),則認(rèn)為當(dāng)前的 TCP 連接已經(jīng)死亡,系統(tǒng)內(nèi)核將錯(cuò)誤信息通知給上層應(yīng)用程序。

在 Linux 內(nèi)核可以有對(duì)應(yīng)的參數(shù)可以設(shè)置保活時(shí)間、保活探測(cè)的次數(shù)、保活探測(cè)的時(shí)間間隔,以下都為默認(rèn)值:

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9
  • tcp_keepalive_time=7200:表示保活時(shí)間是 7200 秒(2小時(shí)),也就 2 小時(shí)內(nèi)如果沒(méi)有任何連接相關(guān)的活動(dòng),則會(huì)啟動(dòng)保活機(jī)制
  • tcp_keepalive_intvl=75:表示每次檢測(cè)間隔 75 秒;
  • tcp_keepalive_probes=9:表示檢測(cè) 9 次無(wú)響應(yīng),認(rèn)為對(duì)方是不可達(dá)的,從而中斷本次的連接。

也就是說(shuō)在 Linux 系統(tǒng)中,最少需要經(jīng)過(guò) 2 小時(shí) 11 分 15 秒才可以發(fā)現(xiàn)一個(gè)「死亡」連接。

圖片

注意,應(yīng)用程序若想使用 TCP ?;顧C(jī)制需要通過(guò) socket 接口設(shè)置 SO_KEEPALIVE 選項(xiàng)才能夠生效,如果沒(méi)有設(shè)置,那么就無(wú)法使用 TCP ?;顧C(jī)制。

TCP keepalive 機(jī)制探測(cè)的時(shí)間也太長(zhǎng)了吧?

對(duì)的,是有點(diǎn)長(zhǎng)。

TCP keepalive 是 TCP 層(內(nèi)核態(tài)) 實(shí)現(xiàn)的,它是給所有基于 TCP 傳輸協(xié)議的程序一個(gè)兜底的方案。

實(shí)際上,我們應(yīng)用層可以自己實(shí)現(xiàn)一套探測(cè)機(jī)制,可以在較短的時(shí)間內(nèi),探測(cè)到對(duì)方是否存活。

比如,web 服務(wù)軟件一般都會(huì)提供 keepalive_timeout 參數(shù),用來(lái)指定 HTTP 長(zhǎng)連接的超時(shí)時(shí)間。如果設(shè)置了 HTTP 長(zhǎng)連接的超時(shí)時(shí)間是 60 秒,web 服務(wù)軟件就會(huì)啟動(dòng)一個(gè)定時(shí)器,如果客戶(hù)端在完后一個(gè) HTTP 請(qǐng)求后,在 60 秒內(nèi)都沒(méi)有再發(fā)起新的請(qǐng)求,定時(shí)器的時(shí)間一到,就會(huì)觸發(fā)回調(diào)函數(shù)來(lái)釋放該連接。

總結(jié)

客戶(hù)端拔掉網(wǎng)線后,并不會(huì)直接影響 TCP 連接狀態(tài)。所以,拔掉網(wǎng)線后,TCP 連接是否還會(huì)存在,關(guān)鍵要看拔掉網(wǎng)線之后,有沒(méi)有進(jìn)行數(shù)據(jù)傳輸。

有數(shù)據(jù)傳輸?shù)那闆r:

  • 在客戶(hù)端拔掉網(wǎng)線后,如果服務(wù)端發(fā)送了數(shù)據(jù)報(bào)文,那么在服務(wù)端重傳次數(shù)沒(méi)有達(dá)到最大值之前,客戶(hù)端就插回了網(wǎng)線,那么雙方原本的 TCP 連接還是能正常存在,就好像什么事情都沒(méi)有發(fā)生。
  • 在客戶(hù)端拔掉網(wǎng)線后,如果服務(wù)端發(fā)送了數(shù)據(jù)報(bào)文,在客戶(hù)端插回網(wǎng)線之前,服務(wù)端重傳次數(shù)達(dá)到了最大值時(shí),服務(wù)端就會(huì)斷開(kāi) TCP 連接。等到客戶(hù)端插回網(wǎng)線后,向服務(wù)端發(fā)送了數(shù)據(jù),因?yàn)榉?wù)端已經(jīng)斷開(kāi)了與客戶(hù)端相同四元組的 TCP 連接,所以就會(huì)回 RST 報(bào)文,客戶(hù)端收到后就會(huì)斷開(kāi) TCP 連接。至此, 雙方的 TCP 連接都斷開(kāi)了。

沒(méi)有數(shù)據(jù)傳輸?shù)那闆r:

  • 如果雙方都沒(méi)有開(kāi)啟 TCP keepalive 機(jī)制,那么在客戶(hù)端拔掉網(wǎng)線后,如果客戶(hù)端一直不插回網(wǎng)線,那么客戶(hù)端和服務(wù)端的 TCP 連接狀態(tài)將會(huì)一直保持存在。
  • 如果雙方都開(kāi)啟了 TCP keepalive 機(jī)制,那么在客戶(hù)端拔掉網(wǎng)線后,如果客戶(hù)端一直不插回網(wǎng)線,TCP keepalive 機(jī)制會(huì)探測(cè)到對(duì)方的 TCP 連接沒(méi)有存活,于是就會(huì)斷開(kāi) TCP 連接。而如果在 TCP 探測(cè)期間,客戶(hù)端插回了網(wǎng)線,那么雙方原本的 TCP 連接還是能正常存在。

除了客戶(hù)端拔掉網(wǎng)線的場(chǎng)景,還有客戶(hù)端「宕機(jī)和殺死進(jìn)程」的兩種場(chǎng)景。

第一個(gè)場(chǎng)景,客戶(hù)端宕機(jī)這件事跟拔掉網(wǎng)線是一樣無(wú)法被服務(wù)端的感知的,所以如果在沒(méi)有數(shù)據(jù)傳輸,并且沒(méi)有開(kāi)啟 TCP keepalive 機(jī)制時(shí),,服務(wù)端的 TCP 連接將會(huì)一直處于 ESTABLISHED 連接狀態(tài),直到服務(wù)端重啟進(jìn)程。

所以,我們可以得知一個(gè)點(diǎn)。在沒(méi)有使用 TCP ?;顧C(jī)制,且雙方不傳輸數(shù)據(jù)的情況下,一方的 TCP 連接處在 ESTABLISHED 狀態(tài)時(shí),并不代表另一方的 TCP 連接還一定是正常的。

第二個(gè)場(chǎng)景,殺死客戶(hù)端的進(jìn)程后,客戶(hù)端的內(nèi)核就會(huì)向服務(wù)端發(fā)送 FIN 報(bào)文,與客戶(hù)端進(jìn)行四次揮手。

所以,即使沒(méi)有開(kāi)啟 TCP keepalive,且雙方也沒(méi)有數(shù)據(jù)交互的情況下,如果其中一方的進(jìn)程發(fā)生了崩潰,這個(gè)過(guò)程操作系統(tǒng)是可以感知的到的,于是就會(huì)發(fā)送 FIN 報(bào)文給對(duì)方,然后與對(duì)方進(jìn)行 TCP 四次揮手。

完!


責(zé)任編輯:武曉燕 來(lái)源: 小林coding
相關(guān)推薦

2024-07-02 12:25:01

2022-08-08 14:31:38

區(qū)塊鏈加密貨幣黑客

2021-12-14 16:06:05

戴爾

2022-09-05 14:36:26

服務(wù)端TCP連接

2015-03-10 11:45:59

2020-10-22 15:44:07

科技機(jī)會(huì)技術(shù)

2018-02-05 15:56:43

程序員軟件行業(yè)青春飯

2018-02-06 10:05:01

程序員開(kāi)發(fā)青春飯

2021-02-23 22:29:22

程序員IT副業(yè)

2022-07-15 16:28:15

人工智能氣候機(jī)器學(xué)習(xí)

2020-07-29 09:44:18

人工智能邊緣計(jì)算技術(shù)

2015-04-23 18:46:38

TCPTCP協(xié)議

2016-11-01 16:41:08

直通網(wǎng)線連接端口傳輸數(shù)據(jù)

2019-07-22 17:59:01

人工智能安防監(jiān)控

2010-07-07 10:45:22

TCP UDP協(xié)議

2021-01-13 11:11:29

TCP連接耗時(shí)網(wǎng)絡(luò)協(xié)議

2017-11-30 15:06:06

求職大數(shù)據(jù)數(shù)據(jù)分析

2014-09-29 09:29:20

TCP

2023-12-01 14:57:22

TCP連接

2009-12-17 16:36:23

無(wú)線路由設(shè)置密碼
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)