前言
很多人認(rèn)為秆剪，TCP協(xié)議自身先天就有KeepAlive機(jī)制赊淑，為何基于它的通訊鏈接，仍然需要在應(yīng)用層實現(xiàn)額外的心跳苯龇恚活陶缺？本文將從移動端IM實踐的角度告訴你，即使使用的是TCP協(xié)議洁灵，應(yīng)用層的心跳北グ叮活仍舊必不可少。
什么是心跳被涨В活苫费？
在使用 TCP 長連接的 IM 服務(wù)設(shè)計中，往往都會涉及到心跳双抽。心跳一般是指某端(絕大多數(shù)情況下是客戶端)每隔一定時間向?qū)Χ税l(fā)送自定義指令百框，以判斷雙方是否存活，因其按照一定間隔發(fā)送荠诬，類似于心跳琅翻，故被稱為心跳指令。
TCP協(xié)議不是自帶KeepAlive的嗎柑贞？
那么問題就隨之而來了：為什么需要在應(yīng)用層做心跳方椎，難道 TCP 不是個可靠連接嗎？我們不能夠依賴 TCP 做斷線檢測嗎钧嘶？比如使用 TCP 的 KeepAlive 機(jī)制來實現(xiàn)棠众。應(yīng)用層心跳是目前的最佳實踐嗎？怎么樣的心跳才是最佳實踐有决。
IM中保持有效長連接的重要性
對于客戶端而言闸拿，使用 TCP 長連接來實現(xiàn)業(yè)務(wù)的最大驅(qū)動力在于：在當(dāng)前連接可用的情況下，每一次請求都只是簡單的數(shù)據(jù)發(fā)送和接受书幕，免去了 DNS 解析新荤，連接建立等時間，大大加快了請求的速度台汇，同時也有利于接受服務(wù)器的實時消息苛骨。但前提是連接可用。
如果連接無法很好地保持苟呐，每次請求就會變成撞大運(yùn)：運(yùn)氣好痒芝，通過長連接發(fā)送請求并收到反饋。運(yùn)氣差牵素，當(dāng)前連接已失效严衬，請求遲遲沒有收到反饋直到超時，又需要一次連接建立的過程笆呆，其效率甚至還不如 HTTP请琳。而連接保持的前提必然是檢測連接的可用性粱挡，并在連接不可用時主動放棄當(dāng)前連接并建立新的連接。
基于這個前提单起，必須要有一種機(jī)制用于檢測連接可用性抱怔。同時移動網(wǎng)絡(luò)的特殊性也要求客戶端需要在空余時間發(fā)送一定的信令，避免連接被回收嘀倒。
而對于服務(wù)器而言屈留，能夠及時獲悉連接可用性也非常重要：一方面服務(wù)器需要及時清理無效連接以減輕負(fù)載，另一方面也是業(yè)務(wù)的需求测蘑，如游戲副本中服務(wù)器需要及時處理玩家掉線帶來的問題灌危。
TCP的KeepAlive無法?替代應(yīng)用層心跳保活機(jī)制的原因
上面說了保持連接的重要性碳胳，那么現(xiàn)在回到具體實現(xiàn)上勇蝙。為什么我們需要使用應(yīng)用層心跳來做檢測，而不是直接使用 TCP 的特性呢挨约？
我們知道 TCP 是一個基于連接的協(xié)議味混，其連接狀態(tài)是由一個狀態(tài)機(jī)進(jìn)行維護(hù)，連接完畢后诫惭，雙方都會處于 established 狀態(tài)翁锡，這之后的狀態(tài)并不會主動進(jìn)行變化。這意味著如果上層不進(jìn)行任何調(diào)用夕土，一直使 TCP 連接空閑馆衔，那么這個連接雖然沒有任何數(shù)據(jù)，但仍是保持連接狀態(tài)怨绣，一天角溃、一星期、甚至一個月篮撑，即使在這期間中間路由崩潰重啟無數(shù)次减细。舉個現(xiàn)實中經(jīng)常遇到的栗子：當(dāng)我們 ssh 到自己的 VPS 上，然后不小心踢掉網(wǎng)線赢笨，此時的網(wǎng)絡(luò)變化并不會被 TCP 檢測出未蝌，當(dāng)我們重新插回網(wǎng)線，仍舊可以正常使用 ssh质欲，同時此時并沒有發(fā)生任何 TCP 的重連。
有人會說 TCP 不是有 KeepAlive 機(jī)制么糠馆，通過這個機(jī)制來實現(xiàn)不就可以了嗎嘶伟？但是事實上，TCP KeepAlive 的機(jī)制其實并不適用于此又碌。Keep Alive 機(jī)制開啟后九昧，TCP 層將在定時時間到后發(fā)送相應(yīng)的 KeepAlive 探針以確定連接可用性绊袋。一般時間為 7200 s（詳情請參見《TCP/IP詳解》中第23章），失敗后重試 10 次铸鹰，每次超時時間 75 s癌别。顯然默認(rèn)值無法滿足我們的需求，而修改過設(shè)置后就可以滿足了嗎蹋笼？答案仍舊是否定的展姐。
因為 TCP KeepAlive 是用于檢測連接的死活，而心跳機(jī)制則附帶一個額外的功能：檢測通訊雙方的存活狀態(tài)剖毯。兩者聽起來似乎是一個意思圾笨，但實際上卻大相徑庭。
考慮一種情況逊谋，某臺服務(wù)器因為某些原因?qū)е仑?fù)載超高擂达，CPU 100%，無法響應(yīng)任何業(yè)務(wù)請求胶滋，但是使用 TCP 探針則仍舊能夠確定連接狀態(tài)板鬓，這就是典型的連接活著但業(yè)務(wù)提供方已死的狀態(tài)，對客戶端而言究恤，這時的最好選擇就是斷線后重新連接其他服務(wù)器俭令，而不是一直認(rèn)為當(dāng)前服務(wù)器是可用狀態(tài)，一直向當(dāng)前服務(wù)器發(fā)送些必然會失敗的請求丁溅。
從上面我們可以知道唤蔗，KeepAlive 并不適用于檢測雙方存活的場景，這種場景還得依賴于應(yīng)用層的心跳窟赏。應(yīng)用層心跳有著更大的靈活性妓柜，可以控制檢測時機(jī)，間隔和處理流程涯穷，甚至可以在心跳包上附帶額外信息棍掐。從這個角度而言，應(yīng)用層的心跳的確是最佳實踐拷况。
心跳弊骰停活機(jī)制的實現(xiàn)方案參考
從上面我們可以得出結(jié)論，目前而言赚瘦，應(yīng)用層心跳的確是檢測連接有效性粟誓，雙方是否存活的最佳實踐，那么剩下的問題就是怎么實現(xiàn)起意。
最簡單粗暴做法當(dāng)然是定時心跳鹰服，如每隔 30 秒心跳一次，15 秒內(nèi)沒有收到心跳回包則認(rèn)為當(dāng)前連接已失效，斷開連接并進(jìn)行重連悲酷。這種做法最直接套菜，實現(xiàn)也簡單。唯一的問題是比較耗電和耗流量设易。以一個協(xié)議包 5 個字節(jié)計算逗柴，一天收發(fā) 2880 個心跳包，一個月就是 5 * 2 * 2880 * 30 = 0.8 M 的流量顿肺，如果手機(jī)上多裝幾個 IM 軟件戏溺，每個月光心跳就好幾兆流量沒了，更不用說頻繁的心跳帶來的電量損耗挟冠。
既然頻繁心跳會帶來耗電和耗流量的弊端于购，改進(jìn)的方向自然是減少心跳頻率，但也不能過于影響連接檢測的實時性知染±呱基于這個需求，一般可以將心跳間隔根據(jù)程序狀態(tài)進(jìn)行調(diào)整控淡，當(dāng)程序在后臺時(這里主要考慮安卓)嫌吠，盡量拉長心跳間隔，5 分鐘掺炭、甚至 10 分鐘都可以辫诅。
而當(dāng) App 在前臺時則按照原來規(guī)則操作。連接可靠性的判斷也可以放寬涧狮，避免一次心跳超時就認(rèn)為連接無效的情況炕矮，使用錯誤積累，只在心跳超時 n 次后才判定當(dāng)前連接不可用者冤。當(dāng)然還有一些小 trick 比如從收到的最后一個指令包進(jìn)行心跳包周期計時而不是固定時間肤视，這樣也能夠一定程度減少心跳次數(shù)。
