心跳信號是每隔一段時間向互聯的另一方傳送一個很小的數據包,通過對方回復情況判斷互聯的雙方之間的通訊鏈路是否已經斷開的方法。
基本介紹
- 別稱:心跳
- 中醫病名:心跳
- 英文名稱:心跳
- 英文別名:心跳
- 就診科室:心跳
- 多發群體:心跳
- 常見發病部位:心跳
- 常見病因:心跳
- 常見症狀:心跳
- 傳染性:心跳
- 傳播途徑:心跳
介紹
作用
有些防火牆或者電腦管理軟體會把超過一定時間沒有通訊的連線當作死連線,這些軟體會自動將死連線斷開或者請求用戶將死連線斷開。當有心跳時,不會被這類軟體當做死連線。看起來心跳信號像是保持了連線,這是只是心跳信號偶然間具有的作用。
長連線和短連線是套用層的概念。長連線表示當與某個目標創建套用層的連線後,目標不會因為沒有數據通訊而去斷開這個連線。短連線表示當需要與目標通信時創建連線通訊一結束立刻斷開,否則目標有可能也會因為長時間不通訊而將連線斷開,ftp伺服器就會。
當ftp伺服器允許長連線屬性開啟後,ftp伺服器不會因為連線著的客戶端沒有長時間沒有上傳或者下載檔案而關閉這個連線,對於ftp客戶端來說就是不需要採用短連線的方式上傳或者下載檔案。
何時需要
不管採用是基於連線的協定(如TCP),還是基於流的協定(如UDP),當在套用層採用了長連線方式時,都可能需要心跳信號。首先讓我們來看看這兩類協定的區別。
基於流的協定不需要建立連線,也不需要斷開,傳送方向某個地址(IP加連線埠)傳送數據,收取方從某個地址讀取數據。對於基於流的協定來說,傳送方是否成功傳送數據或者傳送的數據是否被成功收取,傳送方是不知道的;收取方沒有收到數據到底說明傳送方沒有傳送還是傳送了但是丟失了,也是不知道的。其實串口通訊協定也算作是一種基於流的協定,雖然有一個打開串口的過程,其實這只是相當於請求獨占一個連線埠,這也是串口不能重複被打開的原因。
基於連線的協定,在通訊前首先要建立連線,建立連線的過程包括一定步驟的雙向通訊;下線也是一樣的,有心情的可以看一下TCP的通訊過程。基於連線的通訊協定每一次傳送數據都是一個雙向的通訊過程,傳送方傳送數據,接收放收到數據後回復,如果沒收到回復重新發,重發0次或多次後會認為連線無故斷開了,報告傳送失敗。顯然基於連線的協定能夠保證傳送的數據被目標接收到了。數據包中對與套用來說有意義的部分數據是否正確是需要根據具體協定而定的,但是指明目的地址的包頭部分有錯誤肯定會導致重發或者傳送失敗。
採用基於連線的協定通訊的雙方中的一方由於停電、當機、崩潰等原因沒有進行或者完成下線的過程那么另一方就不知道連線是否斷開了。對於基於連線的協定,一旦在套用層採用了長連線絕大多少情況下都需要心跳信號,除非程式不用長時間運行,不在乎死連線的性能損失。
對於基於流的協定,採用了長連線並且有一方需要確認和區分數據的來源地址(ip連線埠或者其它標識)且需要知道來源方或傳送方是否還線上時才需要採用心跳信號。歸納起來就是如果一方需要知道另一方是否線上那么一定需要心跳信號;如果一方需要知道另一方是否線上但是又不需要知道收到的數據來自何處,那么程式肯定設計的有問題。僅僅區分數據來源是沒有必要為每一個來源都創建一個獨立的連線(其實不應該叫做連線,可以看做tcp、udp通訊採用的socket),更沒有必要採用心跳信號。收到數據之後就可以知道連線埠、IP,其它標識也可以添加到數據包里。
怎么建立
這種情況下心跳信號可以採用計時器每隔一段時間傳送一次,而不用理會是否有其它類型的數據傳送。接收方應該在至少經過2到3倍的約定時間沒有收到心跳信號時才認為連線斷開了。當然也可以有其它類型數據傳送時,不傳送心跳信號。這樣一來雙方的處理邏輯都複雜一些。不管採用何種方式,在的通訊協定都應該進行說明。
傳送視頻流和其它類型的數據流時一般採用基於流的協定。因為網路環境不至於差到每一幀數據中都有丟包。傳送視頻流時,丟了一包,帶來的影響也就是解碼出來的圖像花屏或者不能解碼;花屏沒什麼大不了,不能解碼直接丟棄也沒什麼影響。
傳送其它的數據流,比如從感測器不斷發回來的溫度、濕度等,從GPS接收機不斷發回來的定位信息。這些數據損壞了一幀,還有下一幀可以使用。所以也不在乎丟包。
對於這種流式數據不允許中間插入心跳數據。所以心跳數據的格式必須單獨設計。心跳的傳送也有兩種方式。第一種,不管數據流是否在傳送都每隔固定的時間將心跳數據發往不同於發數據流的連線埠。第二種,當傳送數據流時不傳送心跳信號。