1. 程式人生 > 其它 >不為人知的網路程式設計(十四):拔掉網線再插上,TCP連線還在嗎?一文即懂!

不為人知的網路程式設計(十四):拔掉網線再插上,TCP連線還在嗎?一文即懂!

從系統層面深入地探討一個有趣的TCP技術問題:拔掉網線後,再插上,原本的這條TCP連線還在嗎?或者說它還“好”嗎?

本文由作者小林coding分享,來自公號“小林coding”,有修訂和改動。

1、引言

說到TCP協議,對於從事即時通訊/IM這方面應用的開發者們來說,再熟悉不過了。隨著對TCP理解的越來越深入,很多曾今碰到過但沒時間深入探究的TCP技術概念或疑問,現在是時候回頭來惡補一下了。

本篇文章,我們就從系統層面深入地探討一個有趣的TCP技術問題:拔掉網線後,再插上,原本的這條TCP連線還在嗎?或者說它還“好”嗎?

可能有的人會說:網線都被拔掉了,那說明物理層(也叫實體層)被斷開了(關於網路協議分層模型請見《快速理解網路通訊協議(上篇)》),那在物理層之上的傳輸層理應也會斷開,所以原本的 TCP 連線就不會存在的了。就好像我們撥打有線電話的時候,如果某一方的電話線被拔了,那麼本次通話就徹底斷了。

答案真的是這樣嗎?可能並非你理解的這樣哦,一起跟隨筆者來深入探討一下。

學習交流:

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM

- 開源IM框架原始碼:https://github.com/JackJiang2011/MobileIMSDK

本文同步釋出於:http://www.52im.net/thread-3846-1-1.html

2、系列文章

本文是系列文章中的第14篇,本系列文章的大綱如下:

3、比較籠統的答案

3.1 答案

引言裡我們說到:有人認為,網線都被拔掉了,那說明物理層被斷開,那麼物理層之上的傳輸層肯定也會斷開,所以原來的 TCP 連線自然也就不存在了。(PS:計算機網路分層詳解請見《史上最通俗計算機網路分層詳解

上面這個邏輯是有問題的。

問題在於:錯誤的認為拔掉網線這個動作會影響傳輸層,事實上並不會影響!

實際上:TCP 連線在 Linux 核心中是一個名為struct socket的結構體,該結構體的內容包含 TCP 連線的狀態等資訊。

所以:當拔掉網線的時候,作業系統並不會變更該結構體的任何內容,所以 TCP 連線的狀態也不會發生改變。

3.2 實驗驗證一下

我做了個小實驗:我用 ssh 終端連線了我的雲伺服器,然後我通過斷開 wifi 的方式來模擬拔掉網線的場景,此時檢視 TCP 連線的狀態沒有發生變化,還是處於ESTABLISHED狀態(如下圖所示)。

通過上面實驗結果可以驗證我的結論:拔掉網線這個動作並不會影響 TCP 連線的狀態。

不過,這個答案還是有點籠統。實際上,我們應該在更具體的場景中來看待這個問題,答案才更準確一些。

這個具體場景就是:

  • 1)當拔掉網線後,有資料傳輸時;
  • 2)當拔掉網線後,沒有資料傳輸時。

針對上面這兩種具體的場景,我來更具體地來分析一下。我們繼續往下閱讀。

4、具體場景1:拔掉網線後,有資料傳輸時

4.1 資料傳輸過程中,恰好又把網線插回去了

如果是客戶端被拔掉網線後,服務端向客戶端傳送的資料報文會得不到任何的響應,在等待一定時長後,服務端就會觸發TCP協議的超時重傳機制(詳見:《TCP/IP詳解-第21章·TCP的超時與重傳),然而此時重傳並不能得到響應的資料報文。

如果在服務端重傳報文的過程中,客戶端恰好把網線插回去了,由於拔掉網線並不會改變客戶端的 TCP 連線狀態,並且還是處於 ESTABLISHED 狀態,所以這時客戶端是可以正常接收服務端發來的資料報文的,然後客戶端就會回 ACK 響應報文。

此時:客戶端和服務端的 TCP 連線將依然存在且工作狀態不會受到影響,給應用層的感覺就像什麼事情都沒有發生。。。

4.2 資料傳輸過程中,網線一直沒有插回去

上面這種情況下,如果在服務端TCP協議重傳報文的過程中,客戶端一直沒有將網線插回去,那麼服務端超時重傳報文的次數達到一定閾值後,核心就會判定出該 TCP 有問題。然後就會通過 Socket 介面告訴應用程式該 TCP 連接出問題了,於是服務端的 TCP 連線就會斷開。

接下來,如果客戶端再插回網線,如果客戶端向服務端傳送了資料,由於服務端已經沒有與客戶端匹配的 TCP 連線資訊了,因此服務端核心就會回覆RST報文,客戶端收到後就會釋放該 TCP 連線。

此時:客戶端和服務端的 TCP 連線已經明確被斷開,原本的這個連線也就不存在了。

4.3 刨根問底:TCP資料報文到底重傳幾次?

本著知其然更應知其所以然的精神,我們來刨根問底一下:TCP 的資料報文到底有重傳幾次呢?

在 Linux 系統中,提供了一個叫tcp_retries2配置項,預設值是 15(如下圖所示)。

如上圖所示:這個核心引數是控制 TCP 連線建立的情況下,超時重傳的最大次數。

不過tcp_retries2設定了15次,並不代表 TCP 超時重傳了15次才會通知應用程式終止該 TCP 連線,核心還會基於“最大超時時間”來判定。

每一輪的超時時間都是倍數增長的,比如第一次觸發超時重傳是在2s後,第二次則是在4s後,第三次則是8s後,以此類推。

核心會根據tcp_retries2設定的值,計算出一個最大超時時間。

在重傳報文且一直沒有收到對方響應的情況時,先達到“最大重傳次數”或者“最大超時時間”這兩個的其中一個條件後,就會停止重傳,然後就會斷開 TCP 連線。

PS:有關TCP超時重傳機制的詳細情況,可以閱讀淺析TCP協議中的疑難雜症(下篇)》。

5、具體場景2:拔掉網線後,有資料傳輸時

5.1 場景分析

針對拔掉網線後,沒有資料傳輸的場景,還得具體看看是否開啟了 TCP KeepAlive 機制 (詳見《徹底搞懂TCP協議層的KeepAlive保活機制》)。

1)如果沒有開啟 TCP KeepAlive 機制:

在客戶端拔掉網線後,並且雙方都沒有進行資料傳輸,那麼客戶端和服務端的 TCP 連線將會一直保持存在。

2)如果開啟了 TCP KeepAlive 機制:

在客戶端拔掉網線後,即使雙方都沒有進行資料傳輸,在持續一段時間後,TCP 就會發送KeepAlive探測報文。

根據KeepAlive探測報文響應情況,會有以下兩種可能:

  • 1)如果對端正常工作:當探測報文被對端收到並正常響應, TCP 保活時間將被重置,等待下一個 TCP 保活時間的到來;
  • 2)如果對端主機崩潰或對端由於其他原因導致報文不可達:當探測報文傳送給對端後,石沉大海、沒有響應,連續幾次,達到保活探測次數後,TCP 會報告該連線已經死亡。

所以:TCP 保活機制可以在雙方沒有資料互動的情況,通過TCP KeepAlive 機制的探測報文,來確定對方的 TCP 連線是否存活。

5.2 刨根問底:TCP KeepAlive 機制具體是什麼樣的?

TCP KeepAlive 機制的原理是這樣的:

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

在 Linux 核心可以有對應的引數可以設定保活時間、保活探測的次數、保活探測的時間間隔。

以下是 Linux 中的預設值:

net.ipv4.tcp_keepalive_time=7200

net.ipv4.tcp_keepalive_intvl=75

net.ipv4.tcp_keepalive_probes=9

解釋一下:

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

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

計算公式是:

注意:應用程式若想使用 TCP 保活機制需要通過 socket 介面設定SO_KEEPALIVE選項才能夠生效,如果沒有設定,那麼就無法使用 TCP 保活機制。

PS:關於TCP協議的KeepAlive 機制詳見《徹底搞懂TCP協議層的KeepAlive保活機制》、《一文讀懂即時通訊應用中的網路心跳包機制:作用、原理、實現思路等》。

5.3 刨根問底:TCP KeepAlive 機制的探測時間也太長了吧?

沒錯,確實有點長。

TCP KeepAlive機制是 TCP 層(核心態) 實現的,它是給所有基於 TCP 傳輸協議的程式一個兜底的方案。

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

比如:一般Web 伺服器都會提供keepalive_timeout引數,用來指定 HTTP 長連線的超時時間。如果設定了 HTTP 長連線的超時時間是60秒,Web 服務軟體就會啟動一個定時器,如果客戶端在完後一個 HTTP 請求後,在60秒內都沒有再發起新的請求,定時器的時間一到,就會觸發回撥函式來釋放該連線。

再比如:IM、訊息推送系統裡的心跳機制,通過應用層的心跳機制(由客戶端發出,服務端回覆響應包),來靈活控制和探測長連線的健康度。

為何基於TCP協議的移動端IM仍然需要心跳保活機制?》這篇文章解釋了IM這類應用中應用層心跳保活的必要性,有興趣可以讀一讀。

如果對應用層心跳的具體應用沒什麼概念,可以看看微信的這兩篇文章:

  1. 微信團隊原創分享:Android版微信後臺保活實戰分享(網路保活篇)
  2. 移動端IM實踐:實現Android版微信的智慧心跳機制

下面有幾個針對im這類應用的心跳實現程式碼,可以具體感受學習一下:

  1. 正確理解IM長連線的心跳及重連機制,並動手實現(有完整IM原始碼)
  2. 一種Android端IM智慧心跳演算法的設計與實現探討(含樣例程式碼)
  3. 自已開發IM有那麼難嗎?手把手教你自擼一個Andriod版簡易IM (有原始碼)
  4. 手把手教你用Netty實現網路通訊程式的心跳機制、斷線重連機制

6、本文小結

下面簡單總結一下文中的內容,本文開頭的問題並不是簡單一句話能夠準確說清楚的,需要分情況對待。

也就是:客戶端拔掉網線後,並不會直接影響 TCP 的連線狀態。所以拔掉網線後,TCP 連線是否還會存在,關鍵要看拔掉網線之後,有沒有進行資料傳輸。

1)有資料傳輸的情況:

在客戶端拔掉網線後:如果服務端傳送了資料報文,那麼在服務端重傳次數沒有達到最大值之前,客戶端恰好插回網線的話,那麼雙方原本的 TCP 連線還是能存在並正常工作,就好像什麼事情都沒有發生。

在客戶端拔掉網線後:如果服務端傳送了資料報文,在客戶端插回網線之前,服務端重傳次數達到了最大值時,服務端就會斷開 TCP 連線。等到客戶端插回網線後,向服務端傳送了資料,因為服務端已經斷開了與客戶端相同四元組的 TCP 連線,所以就會回 RST 報文,客戶端收到後就會斷開 TCP 連線。至此, 雙方的 TCP 連線都斷開了。

2)沒有資料傳輸的情況:

  • a.如果雙方都沒有開啟 TCP keepalive 機制,那麼在客戶端拔掉網線後,如果客戶端一直不插回網線,那麼客戶端和服務端的 TCP 連線狀態將會一直保持存在;
  • b.如果雙方都開啟了 TCP keepalive 機制,那麼在客戶端拔掉網線後,如果客戶端一直不插回網線,TCP keepalive 機制會探測到對方的 TCP 連線沒有存活,於是就會斷開 TCP 連線。而如果在 TCP 探測期間,客戶端插回了網線,那麼雙方原本的 TCP 連線還是能正常存在。

除了客戶端拔掉網線的場景,還有客戶端“宕機和殺死程序”的兩種場景。

第一個場景:客戶端宕機這件事跟拔掉網線是一樣無法被服務端的感知的,所以如果在沒有資料傳輸,並且沒有開啟 TCP keepalive 機制時,,服務端的 TCP 連線將會一直處於ESTABLISHED連線狀態,直到服務端重啟程序。

所以:我們可以得知一個點——在沒有使用 TCP 保活機制,且雙方不傳輸資料的情況下,一方的 TCP 連線處在ESTABLISHED狀態時,並不代表另一方的 TCP 連線還一定是正常的。

第二個場景:殺死客戶端的程序後,客戶端的核心就會向服務端傳送 FIN 報文,與客戶端進行四次揮手(見《跟著動畫來學TCP三次握手和四次揮手》)。

所以:即使沒有開啟 TCP KeepAlive,且雙方也沒有資料互動的情況下,如果其中一方的程序發生了崩潰,這個過程作業系統是可以感知的到的,於是就會發送 FIN 報文給對方,然後與對方進行 TCP 四次揮手。

7、參考資料

[1]TCP/IP詳解-第21章·TCP的超時與重傳

[2]通俗易懂-深入理解TCP協議(上):理論基礎

[3]網路程式設計懶人入門(三):快速理解TCP協議一篇就夠

[4]腦殘式網路程式設計入門(一):跟著動畫來學TCP三次握手和四次揮手

[5]腦殘式網路程式設計入門(七):面視必備,史上最通俗計算機網路分層詳解

[6]技術大牛陳碩的分享:由淺入深,網路程式設計學習經驗乾貨總結

[7]網路程式設計入門從未如此簡單(二):假如你來設計TCP協議,會怎麼做?

[8]不為人知的網路程式設計(十):深入作業系統,從核心理解網路包的接收過程(Linux篇)

[9]為何基於TCP協議的移動端IM仍然需要心跳保活機制?

[10]一文讀懂即時通訊應用中的網路心跳包機制:作用、原理、實現思路等

[11]Web端即時通訊實踐乾貨:如何讓你的WebSocket斷網重連更快速?

本文同步釋出於:http://www.52im.net/thread-3846-1-1.html

作者:Jack Jiang (點選作者姓名進入Github)
出處:http://www.52im.net/space-uid-1.html
交流:歡迎加入即時通訊開發交流群 215477170
討論:http://www.52im.net/
Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】【輕量級開源移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
本博文 歡迎轉載,轉載請註明出處(也可前往 我的52im.net 找到我)。