IM即時通訊開發實現心跳保活遇到的問題

Android推送服務的幾種實現方式

現實生活中, 推送服務就像訂雜志一樣, 只要留下你的地址, 雜志就能如期送到你手裏, 可以認為每個人都有唯一的一個地址, 但在目前的網絡上, 這是辦不到的, 因為不是每個人都有一個唯一的地址, 服務器想要給我們推送一條消息, 必須知道我們的地址, 但服務器不知道我們在哪.

輪詢

客戶端定期詢問服務器有沒有新的消息, 這樣服務器不用管客戶端的地址是什麼, 客戶端來問, 直接告訴它就行.

這種方案最簡單, 對於一些不追求實時性的客戶端來說, 很適合, 只需要把時間間隔設定成幾個小時取一次, 就能很方便的解决問題.

但對於即時通訊產品來說, 這種方案完全不能用. 假設即時通訊軟件在網絡暢通的情况下發送的消息要求對方10s內就能收到, 如果用輪詢, 那麼客戶端要每隔5s連一次服務器, 如果在移動端, 手機的電量和流量很快就會被消耗殆盡。

SMS通知

這種方案在移動端是有可能的, 讓客戶端攔截手機短信, 服務器在有新消息時給用戶的手機號發一條特殊的短信, 客戶端攔截短信後發現是正常短信就放行, 如果是特殊短信就連接服務器取消息.

運營商不會配合, 用戶也不會放心, 這方案普通公司玩不起.

長連接

這大概是目前情况下最佳的方案了, 客戶端主動和服務器建立TCP長連接之後, 客戶端定期向服務器發送心跳包, 有消息的時候, 服務器直接通過這個已經建立好的TCP連接通知客戶端.

XMPP、MQTT等不算推送技術

在網上搜索資料的時候, 經常看見XMPP協議實現的Android推送和MQTT協議實現的Android推送, 我個人覺得這兩種說法都怪怪的, XMPP和MQTT二者都是協議, 盡管我不清楚嚴格來講這倆協議工作在哪一層, 但是絕對是在傳輸層之上的, 姑且認為他倆在TCP/IP四層模型的應用層吧, 閉口不提傳輸層的實現, 而是扯應用層, 這種說法真是令我費解, 所以我個人認為XMPP, MQTT等等不算推送技術.

關於為什麼TCP/IP是四層模型, 感謝評論區指出, 對應的是 應用層, 傳輸層, 網絡層, 網絡接口層, 也有說法把網絡接口層分成兩層, 這樣就有了五層, 因為TCP/IP是事實上的模型, 所以說法不一很正常, 主流說法是四層.

關於這個XMPP, 我想很多人都是參考Openfire和Smack那套東西, 我一年前嘗試用aSmack和Openfire做IM, 不過那個時候什麼都不懂, 做的東西很爛, 唯一懂的就是Openfire這東西相當老了, 我看有一些開源的推送解决方案都是在這套東西的基礎上改的, 想想這工作量, 挺可怕的.

細說TCP長連接與心跳

長連接方案乍一聽怪怪的, 什麼是長連接? 定時發送心跳, 這和輪詢有什麼區別? 心跳是幹什麼的? 同樣是定期和服務器溝通, 為什麼長連接就比輪詢更加優秀? 手機休眠了TCP連接不會斷掉嗎?

什麼是長連接

先說短連接, 短連接是通訊雙方有數據交互時就建立一個連接, 數據發送完成後，則斷開此連接。

長連接就是大家建立連接之後, 不主動斷開. 雙方互相發送數據, 發完了也不主動斷開連接, 之後有需要發送的數據就繼續通過這個連接發送.

TCP連接在默認的情况下就是所謂的長連接, 也就是說連接雙方都不主動關閉連接, 這個連接就應該一直存在.

但是網絡中的情况是複雜的, 這個連接可能會被切斷. 比如客戶端到服務器的鏈路因為故障斷了, 或者服務器宕機了, 或者是你家網線被人剪了, 這些都是一些莫名其妙的導致連接被切斷的因素, 還有幾種比較特殊的。

NAT超時

因為IPv4地址不足, 或者我們想通過無線路由器上網, 我們的設備可能會處在一個NAT設備的後面, 生活中最常見的NAT設備是家用路由器.

NAT設備會在IP封包通過設備時修改源/目的IP地址. 對於家用路由器來說, 使用的是網絡地址端口轉換(NAPT), 它不僅改IP, 還修改TCP和UDP協議的端口號, 這樣就能讓內網中的設備共用同一個外網IP. 舉個例子, NAPT維護一個類似下錶的NAT錶：

NAT設備會根據NAT錶對出去和進來的數據做修改, 比如將192.168.0.3:8888發出去的封包改成120.132.92.21:9202, 外部就認為他們是在和120.132.92.21:9202通信. 同時NAT設備會將120.132.92.21:9202收到的封包的IP和端口改成192.168.0.3:8888, 再發給內網的主機, 這樣內部和外部就能雙向通信了, 但如果其中192.168.0.3:8888 == 120.132.92.21:9202這一映射因為某些原因被NAT設備淘汰了, 那麼外部設備就無法直接與192.168.0.3:8888通信了。

我們的設備經常是處在NAT設備的後面, 比如在大學裏的校園網, 查一下自己分配到的IP, 其實是內網IP, 錶明我們在NAT設備後面, 如果我們在寢室再接個路由器, 那麼我們發出的數據包會多經過一次NAT.

國內移動無線網絡運營商在鏈路上一段時間內沒有數據通訊後, 會淘汰NAT錶中的對應項, 造成鏈路中斷。

網絡狀態切換

手機網絡和WIFI網絡切換, 網絡斷開和連上等情况, 也會使長連接斷開. 這裏原因可能比較多, 但結果無非就是IP變了, 或者被系統通知連接斷了.

DHCP的租期

目前測試發現安卓系統對DHCP的處理有Bug, DHCP租期到了不會主動續約並且會繼續使用過期IP, 這個問題會造成TCP長連接偶然的斷連。

心跳包的作用

網上很多文章介紹長連接的時候都說：

因為是長連接, 所以需要定期發送心跳包；

心跳包是用來通知服務器客戶端當前狀態。

提出這些說法的人其實自己也是一知半解. 這些說法其實都對, 但是沒有答到點上. 就好像別人問: "你為什麼要去食堂"? 這人回答: "檢查自己還能不能找到食堂". 這個答案說不上錯了, 但是其實這人是去食堂吃飯的, 證明自己認得路只是個附贈品。

明確一點, TCP長連接本質上不需要心跳包來維持, 大家可以試一試, 讓兩臺電腦連上同一個wifi, 然後讓其中一臺做服務器, 另一臺用一個普通的沒有設置KeepAlive的Socket連上服務器, 只要兩臺電腦別斷網, 路由器也別斷電, DHCP正常續租, 就這麼放著, 過幾個小時再用其中一臺電腦通過之前建立的TCP連接給另一臺發消息, 另一臺肯定能收到。

那為什麼要有心跳包呢? 其實主要是為了防止上面提到的NAT超時, 既然一些NAT設備判斷是否淘汰NAT映射的依據是一定時間沒有數據, 那麼客戶端就主動發一個數據。

當然, 如果僅僅是為了防止NAT超時, 可以讓服務器來發送心跳包給客戶端, 不過這樣做有個弊病就是, 萬一連接斷了, 服務器就再也聯系不上客戶端了. 所以心跳包必須由客戶端發送, 客戶端發現連接斷了, 還可以嘗試重連服務器。

所以心跳包的主要作用是防止NAT超時, 其次是探測連接是否斷開。

鏈路斷開, 沒有寫操作的TCP連接是感知不到的, 除非這個時候發送數據給服務器, 造成寫超時, 否則TCP連接不會知道斷開了. 主動kill掉一方的進程, 另一方會關閉TCP連接, 是系統代進程給服務器發的FIN. TCP連接就是這樣, 只有明確的收到對方發來的關閉連接的消息(收到RST也會關閉, 大家都懂), 或者自己意識到發生了寫超時, 否則它認為連接還存在。

心跳包的時間間隔

既然心跳包的主要作用是防止NAT超時, 那麼這個間隔就大有文章了。

發送心跳包勢必要先喚醒設備, 然後才能發送, 如果喚醒設備過於頻繁, 或者直接導致設備無法休眠, 會大量消耗電量, 而且移動網絡下進行網絡通信, 比在wifi下耗電得多. 所以這個心跳包的時間間隔應該盡量的長, 最理想的情况就是根本沒有NAT超時, 比如剛才我說的兩臺在同一個wifi下的電腦, 完全不需要心跳包. 這也就是網上常說的長連接, 慢心跳。即時通訊聊天軟件app開發可以加蔚可雲的v：weikeyun24諮詢

現實是殘酷的, 根據網上的一些說法, 中移動2/3G下, NAT超時時間為5分鐘, 中國電信3G則大於28分鐘, 理想的情况下, 客戶端應當以略小於NAT超時時間的間隔來發送心跳包。

wifi下, NAT超時時間都會比較長, 據說寬帶的網關一般沒有空閑釋放機制, GCM有些時候在wifi下的心跳比在移動網絡下的心跳要快, 可能是因為wifi下聯網通信耗費的電量比移動網絡下小。

服務器如何處理心跳包

如果客戶端心跳間隔是固定的, 那麼服務器在連接閑置超過這個時間還沒收到心跳時, 可以認為對方掉線, 關閉連接. 如果客戶端心跳會動態改變, 如上節提到的微信心跳方案, 應當設置一個最大值, 超過這個最大值才認為對方掉線. 還有一種情况就是服務器通過TCP連接主動給客戶端發消息出現寫超時, 可以直接認為對方掉線.

這個就需要具體業務具體分析了, 也許還有更優的策略, 這裏就不寫了。

心跳包和輪詢的區別

心跳包和輪詢看起來類似, 都是客戶端主動聯系服務器, 但是區別很大：

輪詢是為了獲取數據, 而心跳是為了保活TCP連接。

輪詢得越頻繁, 獲取數據就越及時, 心跳的頻繁與否和數據是否及時沒有直接關系

輪詢比心跳能耗更高, 因為一次輪詢需要經過TCP三次握手, 四次揮手, 單次心跳不需要建立和拆除TCP連接.

TCP喚醒Android

這部分內容我只知道結論, 不知道具體的知識。

大家有沒有想過, 手機的短信功能和微信的功能差不多, 為什麼微信會比短信耗電這麼多? 當然不是因為短信一條0.1元. 手機短信是通過什麼獲取推送的呢?

下面這段出處不明的話也許可以給大家啟示：

首先Android手機有兩個處理器, 一個叫Application Processor(AP), 一個叫Baseband Processor(BP). AP是ARM架構的處理器，用於運行Android系統; BP用於運行實時操作系統(RTOS), 通訊協議棧運行於BP的RTOS之上. 非通話時間, BP的能耗基本上在5mA左右，而AP只要處於非休眠狀態, 能耗至少在50mA以上, 執行圖形運算時會更高. 另外LCD工作時功耗在100mA左右, WIFI也在100mA左右. 一般手機待機時, AP, LCD, WIFI均進入休眠狀態, 這時Android中應用程序的代碼也會停止執行.

Android為了確保應用程序中關鍵代碼的正確執行, 提供了Wake Lock的API, 使得應用程序有權限通過代碼阻止AP進入休眠狀態. 但如果不領會Android設計者的意圖而濫用Wake Lock API, 為了自身程序在後臺的正常工作而長時間阻止AP進入休眠狀態, 就會成為待機電池殺手.

完全沒必要擔心AP休眠會導致收不到消息推送. 通訊協議棧運行於BP，一旦收到數據包, BP會將AP喚醒, 喚醒的時間足够AP執行代碼完成對收到的數據包的處理過程. 其它的如Connectivity事件觸發時AP同樣會被喚醒. 那麼唯一的問題就是程序如何執行向服務器發送心跳包的邏輯. 你顯然不能靠AP來做心跳計時. Android提供的Alarm Manager就是來解决這個問題的. Alarm應該是BP計時(或其它某個帶石英鐘的芯片，不太確定，但絕對不是AP), 觸發時喚醒AP執行程序代碼. 那麼Wake Lock API有啥用呢? 比如心跳包從請求到應答, 比如斷線重連重新登陸這些關鍵邏輯的執行過程, 就需要Wake Lock來保護. 而一旦一個關鍵邏輯執行成功, 就應該立即釋放掉Wake Lock了. 兩次心跳請求間隔5到10分鐘, 基本不會怎麼耗電. 除非網絡不穩定. 頻繁斷線重連, 那種情况辦法不多.

網上有說使用AlarmManager，因為AlarmManager 是Android 系統封裝的用於管理 RTC 的模塊，RTC (Real Time Clock) 是一個獨立的硬件時鐘，可以在 CPU 休眠時正常運行，在預設的時間到達時，通過中斷喚醒 CPU。