如果沒有特意的設置某些選項或者實現應用層心跳包，TCP空閒的時候是不會發送任何數據包。也就是說，當一個TCP的socket，客戶端與服務端誰也不發送數據，會一直保持着連接。這其中如果有一方異常掉線（例如死機、路由被破壞、防火牆切斷連接等），另一端如果沒有發送數據，永遠也不可能知道。這對於一些服務型的程序來說，是災難性的後果，將會導致服務端socket資源耗盡。
所以爲了保證連接的有效性、及時有效地檢測到一方的非正常斷開，保證連接的資源被有效的利用，我們就會需要一種保活的機制，通常改機制兩種處理方式：1、利用TCP協議層實現的Keepalive；2、自己在應用層實現心跳包。
兩種方式的對比如下：
1、TCP協議自帶的保活功能, 使用起來簡單, 減少了應用層代碼的複雜度. 更節省流量, 因爲一般來說應用層的數據傳輸到協議層時都會被加上額外的包頭包尾. 由TCP協議提供的檢活, 其發的ACK包比應用層的心跳包耗費更少的流量。
2、應用層心跳包相對與Keepalive更靈活，因爲協議層的心跳只能提供最純粹的檢活功能, 但是應用層自己可以隨意控制，甚至加入一些額外邏輯。
3、應用層心跳包相對與Keepalive更靈活，應用層心跳包不依賴於協議，如若有一天不用TCP要改爲UDP了，只需做少量改動甚至不用改動即可實現轉換。
網絡上有說：存活（keepalive）並不是TCP規範的一部分。在Host Requirements RFC羅列有不使用它的三個理由：（1）在短暫的故障期間，它們可能引起一個良好連接（good connection）被釋放（dropped），（2）它們消費了不必要的寬帶，（3）在以數據包計費的互聯網上它們（額外）花費金錢。
實際上，自己實現心跳包也會面臨同樣的問題，而第一點，在我測試過程中，只要設置參數合理短時間內並不會引起連接主動斷開。
參考鏈接：