什麼是心跳包（心跳機制） 先看一下wiki上的說法： 心跳包（英語：Heartbeat）在電腦科學中指一種周期性的信號，通過硬體或軟體的形式來檢測行為的正常與否，或者與電腦系統是否一致。[1] 通常，機器間會每隔幾秒鐘發送一次心跳包。 如果接收終端沒有在指定時間內（通常是幾個心跳包發送的時間間隔 ...
先看一下
心跳包（英語：Heartbeat）在
簡而言之心跳機制是用於檢測對端存活的一種常用方式。
有點類似icu裡面的心跳檢測機（服務端），你的心臟（客戶端）跳一下，他就更新一下狀態，認為你還活著，你要太長時間沒跳，他就認為你已經不行了，然後發出bi 的警告。
在網路中，心跳的作用是，在一種需要對端保持連接的狀態中，並且存在無法通過上一次的請求判斷當前的狀態（雖然心跳也不能保證下一次發送成功，但是現實是，我上一次請求是12h前發的，所以你現在還在不在），心跳包可以單獨檢測對端的存活狀態，從而防止發送無用的數據包，另外在分散式系統中，可以避免將數據發送到不可用的節點上（這是比較麻煩的，我成功地把包發到一個不可用的節點上，它給我反錯誤了，我怎麼辦，發給其它節點嗎，會造成雙花嗎？）
當然心跳機制不會完美地解決上面的這些問題（畢竟我也不能保證這一秒你的心還在跳，下一秒你就一定還活著），在高可用的系統中還是需要設計另外的機制來防止雙花。
另外值得說的一點是：我們不能在網路中發送過多的心跳包，因為在很多時候，網路也是一直有限的資源（心跳雖好，可不要貪杯o），當然也有設計感覺網路情況動態調整的心跳機制，不過那就涉及一些網路底層的東西了。
常見的心跳包
keepalive
說到常見的心跳包，就不得不說tcp keepalive機制了
依然是wiki：
存活時長（英語：Keepalive time）即空閑時，兩次傳輸存活包的持續時間。TCP存活包時長可手動配置，預設不少於2個小時。
存活間隔（英語：Keepalive interval）即未收到上個存活包時，兩次連續傳輸存活包的時間間隔。
存活重試次數（英語：Keepalive retry）即在判斷遠程主機不可用前的發送存活包次數。當兩個主機透過TCP/IP協議相連時，TCP存活包可用於判斷連接是否可用，並按需中斷。
多數支持TCP協議的主機也同時支持TCP存活包。每個主機按一定周期向其他主機發送TCP包來請求回應。若發送主機未收到特定主機的回應（ACK），則將從發送主機一側中斷連接。 若其他主機在連接關閉後發送TCP存活包，關閉連接的一方將發送RST包來表明舊連接已不可用。其他主機將關閉它一側的連接以新建連接。
空閑的TCP連接通常會每隔45秒或60秒發送一次存活包。在未連續收到三次ACK包時，連接將中斷。此行為因主機而異，如預設情況下的Windows主機將在7200000ms（2小時）後發送首個存活包，隨後再以1000ms的間隔發送5個存活包。若任意存活包未收到回應，連接將被中斷。
keepalive作為最基礎的心跳機制，其設計已經融入tcp協議中了。
-
wireshark keepalive捉包分析
TLS的心跳機制與心臟出血漏洞
TLS心跳原理
簡單來講TLS心跳拓展主要解決的是在tls鏈路中，判斷對方存活需要進行一次tls協商（這是比較費時），這個心跳拓展的主要目的是通過一個簡單的心跳過程來保留tls鏈路的存活，在之前是使用tcp的keepalive來做的，但tcp的keepalive只能保證tcp鏈路的可用性。
看完這篇rfc，有兩個比較有意思的點
對於每個心跳包，我們需要給他一個payload,而服務端返回的時候需要原封不動的返回這個payload。這麼做我猜測是外來解決網路超時的問題，防止我受到之前的包
不需要時時刻刻的發送心跳包，感覺rfc的定義，我們只需要在網路空閑的時候發送心跳包，而在鏈路中有請求的情況下則不需要發送請求包。
IM系統中的心跳機制
IM系統（通訊系統）中的心跳機制主要是獲取用戶線上狀態，以及向用戶推送數據用
與前面兩種心跳類似，不過IM系統需要面對一個麻煩的東西 -- NAT（當然TLS的心跳也有考慮NAT的因素）。對於IM系統，本質是是一個C/S架構的系統，而大部分的C都是沒有獨立IP的，與server通訊，全靠NAT分配的臨時IP與埠，而NAT的反配權又不是C端掌控的，實際上是運營商在控制NAT的分配與釋放。同時IM系統中一般C的數量會是S數量的幾千-幾萬倍，維護心跳狀態將會耗費大量的資源，不過值得慶幸的是，IM實際上是一種弱可用的系統，服務端不需要對客戶端的心跳做出反應，也不需要向客戶端發送心跳包，有點類似於UDP,客服端發出去就不管了。當然IM的心跳機制還是頗為複雜的，而他的複雜也不是我想要瞭解的信息，所以這裡只給出一片作者認為還可以的
應用層上的心跳包
上面談到的心跳機制基本上都是網路層面的心跳機制，更多的是確認一個鏈路是否還可用。當然我們可以把這個鏈路再抽象一下，比如在一個對等網路中，你連接了某個資料庫的資源，我連接了另一個資料庫的資源，而我們需要保證相互之間 到資料庫的鏈路是連通的。那麼這就不是簡單的tcp keepalive這種模式能解決的問題了。我們沒法在網路傳輸模塊完成整個心跳過程，網路層甚至不知道資料庫是什麼，所以這個請求必須上拋到應用層，而應用層在根據自身情況，去找資料庫拿狀態（這裡有個情況，為什麼不讓資料庫也跳起來，主要是浪費資源，心跳是檢測活性，如果沒有client,實際上也用不到資料庫的活性，對於心跳包中複雜的請求，應該被動的等待需要的時候再去操作，而不是在主動地推送自己的狀態）。
當然這還會有一些問題我們包心跳的邏輯全部放在應用層，是不是對心跳是不很友好，這會導致應用層的邏輯與網路層的邏輯耦合在一起，本來應該網路層做的心跳，可所有的邏輯都在應用層，網路層就像完全沒有心跳這回事。
心跳方案的設計
說這麼多，最後我們還是回到現實，最近我的一開發任務，為我們的分散式系統添加一個心跳檢測機制。
簡單描述一下我們的系統：
一個分散式的系統，每個peer會連接一個或多個資源，一個資源會被多個peer連接，當peer受到請求後會隨即的把請求發送到他知道能處理這個請求的peer中。peer之間使用json_rpc通行（用rpc協議是因為我們這個過程實際上就是一個遠程調用）。
比如我是a,我知道b,c,d能處理 x的請求，我會隨即的把請求發到b,c,d某個peer中（或者發送到第一個peer）。
現在遇到的一個問題是，如果b,c,d中間有人掛機了，a是不知道的，而a還會隨即的把請求發到一個節點裡面。
我現在的設計方案是，在rpc模塊實現心跳的邏輯，包括自動發送心跳包，判斷返回結果是否正常，對於多次心跳異常的節點進行處理，（對方節點死了也要周期性的那，用於複活），也就是心跳的主要邏輯在rpc中實現（網路模塊），它用於控制心跳的評論等等，然後在rpc中抽象出兩個介面，HeartbeatHandler,HeartbeatClient
-
HeartbeatHandler 介面表示心跳服務端處理的介面
-
HeartbeatClient 介面表示心跳客戶端的介面： 客戶端介面只需要提供兩個方法，一個屬如果構造心跳請求的介面，一個屬如何處理心跳結果的介面
在server 啟動時，將一個HeartbeatHandler的介面註冊到server中，在client實例化的時候設置HeartbeatClient 並開啟心跳，而心跳的流程式控制制還在網路模塊中。
