概述

心跳包之所以叫心跳包是因為：它像心跳一樣每隔固定時間發一次，以此來告訴服務器，這個客戶端還活著。長連接斷開后一直占用系統資源，可以通過心跳包判斷連接是否斷開；使用心跳包檢測到連接已經死了，就斷開連接。事實上這是為了保持長連接，至于這個包的內容，是沒有什么特別規定的，不過一般都是很小的包，或者只包含包頭的一個空包。
在TCP的機制里面，本身是存在有心跳包的機制的，也就是TCP的選項：SO_KEEPALIVE。系統默認是設置的2小時的心跳頻率。但是它檢查不到機器斷電、網線拔出、防火墻這些斷線。而且邏輯層處理斷線可能也不是那么好處理。一般，如果只是用于保活還是可以的。
總的來說，心跳包主要也就是用于長連接的保活和斷線處理。一般的應用下，判定時間在30-40秒比較不錯。如果實在要求高，那就在6-9秒。

心跳包

應用程序在邏輯層發送心跳包（空的echo包）來判斷與服務器的鏈接是否正常，一般方法如下：首先是服務器在一個Timer事件中定時向客戶端發送一個短小精悍的數據包，然后啟動一個低級別的線程，在該線程中不斷檢測客戶端的回應， 如果在一定時間內沒有收到客戶端的回應，則可認為客戶端已經掉線；同樣，如果客戶端在一定時間內沒有收到服務器的心跳包，則可認為連接不可用。
心跳檢測步驟：
1 客戶端每隔一個時間間隔發生一個探測包給服務器
2 客戶端發包時啟動一個超時定時器
3 服務器端接收到檢測包，應該回應一個包
4 如果客戶機收到服務器的應答包，則說明服務器正常，刪除超時定時器
5 如果客戶端的超時定時器超時，依然沒有收到應答包，則說明服務器掛了

乒乓包

乒乓包大致的意思可總結為在心跳包發送的基礎上，附加了少量簡單的數據信息。
如面試題：朋友圈有人點贊評論的顯示原理簡單介紹，客服端如果知道有人點贊評論，服務器如何將相應的點贊評論的數據發送至客戶端？
1.微信客戶端每隔一段時間就向服務器詢問，是否有人評論？
2.當服務器檢查到有人給評論時，服務器發送一個乒乓包給客戶端，該乒乓包中攜帶的數據是[有 人評論的標志位]
注：步驟1和2，服務器和客戶端不需要建立連接，只是發送簡單的乒乓包。
3.當客戶端接收到服務器回復的帶有評論標志位的乒乓包后，才真正的去和服務器通過三次握手建立連接；建立連接后，服務器將評論的數據發送給客戶端。

SO_KEEPLIVE

1.因為要考慮到一個服務器通常會連接多個客戶端，因此由用戶在應用層自己實現心跳包，代碼較多 且稍顯復雜，而利用TCP／IP協議層為內置的KeepAlive功能來實現心跳功能則簡單得多。
2.不論是服務端還是客戶端，一方開啟KeepAlive功能后，就會自動在規定時間內向對方發送心跳包， 而另一方在收到心跳包后就會自動回復，以告訴對方我仍然在線。
3.因為開啟KeepAlive功能需要消耗額外的寬帶和流量，所以TCP協議層默認并不開啟KeepAlive功 能，盡管這微不足道，但在按流量計費的環境下增加了費用，另一方面，KeepAlive設置不合理時可能會 因為短暫的網絡波動而斷開健康的TCP連接。并且，默認的KeepAlive超時需要7,200，000 MilliSeconds， 即2小時，探測次數為5次。對于很多服務端應用程序來說，2小時的空閑時間太長。
其實有些說法認為SO_KEEPLIVE的意義不大，就是如果服務器端沒有心跳機制，那么客戶端連接上來以后，客戶端突然斷線，那么服務器端不知道對方已掉線，依然會保持連接，但是目前絕大多數軟件都自帶心跳機制。所以它并沒有什么用。

總結

以上是生活随笔為你收集整理的心跳包、乒乓包、SO_KEEPLIVE的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。