先看一下
心跳包（英語：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 並開啟心跳，而心跳的流程控制還在網路模組中。