保活、心跳機制

英文： Heartbeat Mechanism

中文： 保活機制、心跳機制

介紹： 雙方建立互動的連接配接，但是并不是一直存在資料互動，有些連接配接會在資料互動完畢後，主動釋放連接配接，而有些不會，那麼在長時間無資料互動的時間段内，互動雙方都有可能出現掉電、當機、異常重新開機等各種意外，當這些意外發生之後，這些TCP連接配接并未來得及正常釋放，那麼，連接配接的另一方并不知道對端的情況，它會一直維護這個連接配接，長時間的積累會導緻非常多的半打開連接配接，造成端系統資源的消耗和浪費，為了解決這個問題，在傳輸層可以利用TCP的保活封包來實作。

網絡中的接收和發送資料都是使用作業系統中的SOCKET進行實作。但是如果此套接字已經斷開，那發送資料和接收資料的時候就一定會有問題。可是如何判斷這個套接字是否還可以使用呢？這個就需要在系統中建立心跳機制。其實TCP中已經為我們實作了一個叫做心跳的機制。如果你設定了心跳，那TCP就會在一定的時間（比如你設定的是3秒鐘）内發送你設定的次數的心跳（比如說2次），并且此資訊不會影響你自己定義的協定。所謂“心跳”就是定時發送一個自定義的結構體（心跳包或心跳幀），讓對方知道自己“線上”，==以確定連結的有效性。==

所謂的心跳包就是用戶端定時發送簡單的資訊給伺服器端告訴它我還在而已。代碼就是每隔幾分鐘發送一個固定資訊給服務端，服務端收到後回複一個固定資訊如果服務端幾分鐘内沒有收到用戶端資訊則視用戶端斷開。比如有些通信軟體長時間不使用，要想知道它的狀态是線上還是離線就需要心跳包，定時發包收包。發包方：可以是客戶也可以是服務端，看哪邊實作友善合理。一般是用戶端。伺服器也可以定時輪詢發心跳下去。心跳包之是以叫心跳包是因為：它像心跳一樣每隔固定時間發一次，以此來告訴伺服器，這個用戶端還活着。事實上這是為了保持長連接配接，至于這個包的内容，是沒有什麼特别規定的，不過一般都是很小的包，或者隻包含標頭的一個空包。

在TCP的機制裡面，本身是存在有心跳包的機制的，也就是TCP的選項。系統預設是設定的是2小時的心跳頻率。但是它檢查不到機器斷電、網線拔出、防火牆這些斷線。而且邏輯層處理斷線可能也不是那麼好處理。一般，如果隻是用于保活還是可以的。心跳包一般來說都是在邏輯層發送空的包來實作的。下一個定時器，在一定時間間隔下發送一個空包給用戶端，然後用戶端回報一個同樣的空包回來，伺服器如果在一定時間内收不到用戶端發送過來的回報包，那就隻有認定說掉線了。隻需要send或者recv一下，如果結果為零，則為掉線。

但是，在長連接配接下，有可能很長一段時間都沒有資料往來。理論上說，這個連接配接是一直保持連接配接的，但是實際情況中，如果中間節點出現什麼故障是難以知道的。更要命的是，有的節點（防火牆）會自動把一定時間之内沒有資料互動的連接配接給斷掉。在這個時候，就需要我們的心跳包了，用于維持長連接配接，保活。在獲知了斷線之後，伺服器邏輯可能需要做一些事情，比如斷線後的資料清理呀，重新連接配接呀當然，這個自然是要由邏輯層根據需求去做了。總的來說，心跳包主要也就是用于長連接配接的保活和斷線處理。一般的應用下，判定時間在 30 - 40秒 比較不錯。如果實在要求高，那就在 6 - 9秒。