很多人認為，TCP協議有KeepAlive機制，為何基於它的通訊鏈接仍然需要在應用層實現額外的心跳保活呢？本文將從移動端IM的角度告訴妳，即使使用的是TCP協議，應用層的心跳保活仍舊必不可少。
在使用TCP長連接的IM服務設計中，往往都會涉及到心跳。心跳壹般是指客戶端每隔壹定時間向服務端發送自定義指令，以判斷雙方是否存活，因其按照壹定間隔發送，類似於心跳，故稱為心跳指令。
TCP是壹個基於連接的協議，其連接狀態是由壹個狀態機進行維護，連接完畢（三次握手）後，雙方都會處於established狀態，這之後的狀態並不會主動進行變化。也就是說，即使上層不進行任何調用，壹直使TCP連接空閑，那麽它仍然是保持連接的狀態。這個時候就需要壹種機制來檢測TCP連接的狀態，KeepAlive就是背負這個使命出現的。
那麽問題來了，KeepAlive是用來檢測TCP連接狀態的，那為什麽還需要心跳呢？這裏就需要考慮壹種情況了，假如某臺服務器因為某些原因導致負載超高，CPU100%，無法響應任何業務需求，但是使用TCP探針仍舊能夠確定連接狀態，這就是典型的連接活著但業務提供方已死的狀態，對客戶端而言，這時最好的選擇就是斷線後重新連接其他服務器，而不是壹直認為當前服務器是可用狀態，壹直向當前服務器發送些必然後失敗的請求。
從上面我們可以知道，KeepAlive並不適合檢測雙方存活的場景，這種場景還得依賴於應用層的心跳。應用層的心跳有著更大的靈活性，可以控制檢測時機、間隔和處理流程，甚至可以在心跳包上附帶額外信息。從這個角度而言，應用層的心跳的確是最佳實踐。
TCP KeepAlive用於檢測連接的死活，而心跳機制則附帶壹個額外的功能：檢測通訊雙方的存活狀態。
從上面我們可以得出結論，目前而言，應用層心跳的確是檢測連接有效性，雙方是否存活的最佳實踐，那麽剩下的問題就是怎麽實現。
最簡單粗暴的方法是定時心跳，如每隔30秒心跳壹次，15秒內沒有收到心跳包則認為當前連接已失效，斷開連接並進行重連。這種做法最直接，實現也簡單。唯壹的問題就是耗電和耗流量。以壹個協議包 5 個字節計算，壹天收發 2880 個心跳包，壹個月就是 5 x 2 x 2880 x 30 = 0.8 M 的流量，如果手機上多裝幾個 IM 軟件，每個月光心跳就好幾兆流量沒了，更不用說頻繁的心跳帶來的電量損耗。
既然頻繁心跳會帶來耗電和耗流量的弊端，改進的方向自然就是減少心跳頻率，但也不能過於影響連接檢測的實時性。基於這個需求，壹般可以將心跳間隔根據程序狀態進行調整，當程序在後臺時（這裏主要指安卓），盡量拉長心跳間隔，5分鐘、甚至10分鐘都可以。
而當App在前臺時則按照原來規則操作。連接可靠性的判斷也可以放寬，避免壹次心跳超時就認為連接無效的情況，使用錯誤積累，只在心跳超時n次後才判定當前連接不可用。