什么是心跳包（心跳機制）

先看一下wiki上的說法：

心跳包（英語：Heartbeat）在計算機科學中指一種周期性的信號，通過硬件或軟件的形式來檢測行為的正常與否，或者與計算機系統是否一致。[1] 通常，機器間會每隔幾秒鐘發送一次心跳包。 如果接收終端沒有在指定時間內（通常是幾個心跳包發送的時間間隔內）接收到心跳包，發送終端將會被判定發送失敗。

簡而言之心跳機制是用于檢測對端存活的一種常用方式。

有點類似icu里面的心跳檢測機（服務端），你的心臟（客戶端）跳一下，他就更新一下狀態，認為你還活著，你要太長時間沒跳，他就認為你已經不行了，然后發出bi 的警告。

在網絡中，心跳的作用是，在一種需要對端保持連接的狀態中，并且存在無法通過上一次的請求判斷當前的狀態（雖然心跳也不能保證下一次發送成功，但是現實是，我上一次請求是12h前發的，所以你現在還在不在），心跳包可以單獨檢測對端的存活狀態，從而防止發送無用的數據包，另外在分布式系統中，可以避免將數據發送到不可用的節點上（這是比較麻煩的，我成功地把包發到一個不可用的節點上，它給我反錯誤了，我怎么辦，發給其它節點嗎，會造成雙花嗎？）

當然心跳機制不會完美地解決上面的這些問題（畢竟我也不能保證這一秒你的心還在跳，下一秒你就一定還活著），在高可用的系統中還是需要設計另外的機制來防止雙花。

另外值得說的一點是：我們不能在網絡中發送過多的心跳包，因為在很多時候，網絡也是一直有限的資源（心跳雖好，可不要貪杯o），當然也有設計感覺網絡情況動態調整的心跳機制，不過那就涉及一些網絡底層的東西了。

常見的心跳包

keepalive

說到常見的心跳包，就不得不說tcp keepalive機制了

依然是wiki：

傳輸控制協議（TCP）存活包為可選特性，且默認關閉。[1]存活包內沒有數據。在以太網網絡中，存活包的大小為最小長度的幾幀（64字節[2]）。協議中[3]，還有三個與存活包相關的參數：

存活時長（英語：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心跳原理rfc 6520這里就之間放rfc的原文了，感興趣的可以去讀讀看。

簡單來講TLS心跳拓展主要解決的是在tls鏈路中，判斷對方存活需要進行一次tls協商（這是比較費時），這個心跳拓展的主要目的是通過一個簡單的心跳過程來保留tls鏈路的存活，在之前是使用tcp的keepalive來做的，但tcp的keepalive只能保證tcp鏈路的可用性。

看完這篇rfc，有兩個比較有意思的點

對于每個心跳包，我們需要給他一個payload,而服務端返回的時候需要原封不動的返回這個payload。這么做我猜測是外來解決網絡超時的問題，防止我受到之前的包

不需要時時刻刻的發送心跳包，感覺rfc的定義，我們只需要在網絡空閑的時候發送心跳包，而在鏈路中有請求的情況下則不需要發送請求包。

• 心臟出血漏洞（ok,我還是懶得寫,連接安排上）

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 并開啟心跳，而心跳的流程控制還在網絡模塊中。

在我的這個業務中，HeartbeatHandler接口在收到心跳請求會，回去找當前節點連接的資源獲取狀態，讓后返回資源是否可用的結果給clinet

client根據結果來刷新自己的路由表，確保下次請求發送到一個狀態最健康的節點上。

**WRAN 以上文章只是出自我的初步調研，若有疏漏，還請同好們多多指正**