天天看點

長連接配接和端連接配接 心跳包機制

TCP連接配接簡介

當網絡通信時采用TCP協定時,在真正的讀寫操作之前,server與client之間必須建立一個連接配接,

當讀寫操作完成後,雙方不再需要這個連接配接時它們可以釋放這個連接配接,

連接配接的建立是需要三次握手的,而釋放則需要4次握手,

是以說每個連接配接的建立都是需要資源消耗和時間消耗的

​經典的三次握手示意圖:​

長連接配接和端連接配接 心跳包機制

經典的四次握手關閉圖:

長連接配接和端連接配接 心跳包機制

一、長連接配接與短連接配接

長連接配接: 指在一個TCP連接配接上可以連續發送多個資料包,

        在TCP連接配接保持期間,如果沒有資料包發送,需要雙方發檢測包以維持此連接配接;

        一般需要自己做線上維持。 

短連接配接: 指通信雙方有資料互動時,就建立一個TCP連接配接,資料發送完成後,則斷開此TCP連接配接;

        一般銀行都使用短連接配接。 

        它的優點是:管理起來比較簡單,存在的連接配接都是有用的連接配接,不需要額外的控制手段 

比如http的,隻是連接配接、請求、關閉,過程時間較短,伺服器若是一段時間内沒有收到請求即可關閉連接配接。 

其實長連接配接是相對于通常的短連接配接而說的,也就是長時間保持用戶端與服務端的連接配接狀态。

長連接配接與短連接配接的操作過程 

通常的短連接配接操作步驟是: 

  連接配接→資料傳輸→關閉連接配接;

而長連接配接通常就是: 

  連接配接→資料傳輸→保持連接配接(心跳)→資料傳輸→保持連接配接(心跳)→……→關閉連接配接; 

這就要求長連接配接在沒有資料通信時,定時發送資料包(心跳),以維持連接配接狀态,

短連接配接在沒有資料傳輸時直接關閉就行了

什麼時候用長連接配接,短連接配接?

長連接配接多用于操作頻繁,點對點的通訊,而且連接配接數不能太多情況。

每個TCP連接配接都需要三步握手,這需要時間,如果每個操作都是先連接配接,再操作的話那麼處理速度會降低很多,

是以每個操作完後都不斷開,下次次處理時直接發送資料包就OK了,不用建立TCP連接配接。

例如:資料庫的連接配接用長連接配接, 

如果用短連接配接頻繁的通信會造成socket錯誤,而且頻繁的socket 建立也是對資源的浪費。

二、發送接收方式

1、異步 

封包發送和接收是分開的,互相獨立的,互不影響。這種方式又分兩種情況: 

(1)異步雙工:接收和發送在同一個程式中,由兩個不同的子程序分别負責發送和接收 

(2)異步單工:接收和發送是用兩個不同的程式來完成。 

2、同步 

封包發送和接收是同步進行,既封包發送後等待接收傳回封包。 

同步方式一般需要考慮逾時問題,即封包發出去後不能無限等待,需要設定逾時時間,

超過該時間發送方不再等待讀傳回封包,直接通知逾時傳回。

在長連接配接中一般是沒有條件能夠判斷讀寫什麼時候結束,是以必須要加長度封包頭。

讀函數先是讀取封包頭的長度,再根據這個長度去讀相應長度的封包。

三. 單工、半雙工和全雙工

根據通信雙方的分工和信号傳輸方向可将通信分為三種方式:

單工、

半雙工、

全雙工。

在計算機網絡中主要采用雙工方式,其中:

區域網路采用半雙工方式,

城域網和廣域網采用全雙年方式。   

1. 單工(Simplex)方式:

通信雙方裝置中發送器與接收器分工明确,隻能在由發送器向接收器的單一固定方向上傳送資料。

采用單工通信的典型發送裝置如早期計算機的讀卡器,典型的接收裝置如列印機。   

2. 半雙工(Half Duplex)方式:

通信雙方裝置既是發送器,也是接收器,兩台裝置可以互相傳送資料,但某一時刻則隻能向一個方向傳送資料。

例如,步話機是半雙工裝置,因為在一個時刻隻能有一方說話。   

3. 全雙工(Full Duplex)方式:

通信雙方裝置既是發送器,也是接收器,兩台裝置可以同時在兩個方向上傳送資料。

例如,電話是全雙工裝置,因為雙方可同時說話。

而像WEB網站的http服務一般都用短連結,因為長連接配接對于服務端來說會耗費一定的資源,

而像WEB網站這麼頻繁的成千上萬甚至上億用戶端的連接配接用短連接配接會更省一些資源,

如果用長連接配接,而且同時有成千上萬的使用者,如果每個使用者都占用一個連接配接的話,那可想而知吧。

是以并發量大,但每個使用者無需頻繁操作情況下需用短連好。

總之,長連接配接和短連接配接的選擇要視情況而定。

心跳包機制

   跳包之是以叫心跳包是因為:它像心跳一樣每隔固定時間發一次,以此來告訴伺服器,這個用戶端還活着。事實上這是為了保持長連接配接,至于這個包的内容,是沒有什麼特别規定的,不過一般都是很小的包,或者隻包含標頭的一個空包。

    在TCP的機制裡面,本身是存在有心跳包的機制的,也就是TCP的選項:SO_KEEPALIVE。系統預設是設定的2小時的心跳頻率。但是它檢查不到機器斷電、網線拔出、防火牆這些斷線。而且邏輯層處理斷線可能也不是那麼好處理。一般,如果隻是用于保活還是可以的。

    心跳包一般來說都是在邏輯層發送空的echo包來實作的。下一個定時器,在一定時間間隔下發送一個空包給用戶端,然後用戶端回報一個同樣的空包回來,伺服器如果在一定時間内收不到用戶端發送過來的回報包,那就隻有認定說掉線了。

    其實,要判定掉線,隻需要send或者recv一下,如果結果為零,則為掉線。但是,在長連接配接下,有可能很長一段時間都沒有資料往來。理論上說,這個連接配接是一直保持連接配接的,但是實際情況中,如果中間節點出現什麼故障是難以知道的。更要命的是,有的節點(防火牆)會自動把一定時間之内沒有資料互動的連接配接給斷掉。在這個時候,就需要我們的心跳包了,用于維持長連接配接,保活。

    在獲知了斷線之後,伺服器邏輯可能需要做一些事情,比如斷線後的資料清理呀,重新連接配接呀……當然,這個自然是要由邏輯層根據需求去做了。

    總的來說,心跳包主要也就是用于長連接配接的保活和斷線處理。一般的應用下,判定時間在30-40秒比較不錯。如果實在要求高,那就在6-9秒。

心跳檢測步驟:

1 用戶端每隔一個時間間隔發生一個探測包給伺服器

2 用戶端發包時啟動一個逾時定時器

3 伺服器端接收到檢測包,應該回應一個包

4 如果客戶機收到伺服器的應答包,則說明伺服器正常,删除逾時定時器

5 如果用戶端的逾時定時器逾時,依然沒有收到應答包,則說明伺服器挂了