1.基于HTTP協(xié)議的推送機制
基于HTTP協(xié)議的推送機制是一種請求-響應模式,由于HTTP協(xié)議是應用層的單工通信模式,因此它很難實現真正意義上的即時推送。用HTTP協(xié)議實現推送有以下兩種方式.
(1)定期輪詢:
這種方式是使客戶端每隔固定時間向服務器端以post方式發(fā)出HTTP請求。在一次請求的開始,客戶端詢問服務器是否存在需要推送的消息,服務器端收到請求并處理,隨后向客戶端響應處理結果,這樣一次請求就結束了。一段固定時間后,客戶端將再次向服務器端發(fā)出詢問請求并等待服務器端的返回結果。
(2)長輪詢:
這種方式是服務器端在接收到客戶端向其發(fā)出的請求時將請求掛起,直到該連接請求出現異常、超時、或者需要推送消息時再處理該請求,并向客戶端返回響應,客戶端接收到響應后會立即再向服務器端請求連接。這樣就使得服務器與客戶端之間的連接始終未中斷,比客戶端定期輪詢的方式具有更好的實時性。
基于HTTP協(xié)議的推送機制實際上并不是真正的推送,而是依賴客戶端請求-服務器端響應的模式。雖然該機制的實現簡單快速且可控性強,但推送具有延遲性,實時性差。另外,雖然其中長輪詢形式的推送具有一定的實時性,但是服務器端需要管理大量掛起的請求,會造成服務器端資源消耗,同時由于HTTP協(xié)議是無狀態(tài)的,服務器端不能監(jiān)控客戶端的在線離線狀態(tài),因此就不能判斷推送的消息能否達到客戶端。
2.基于C2DM的推送機制
C2DM (Cloud to Device Messaging)服務是Google公司提供的移動終端消息推送服務。開發(fā)者可以將該服務引入自己開發(fā)的應用程序中,服務器端推送給客戶端的消息是經過C2DM服務器推送的,客戶端也可以直接與服務器通信獲取信息。其中C2DM服務器類似與推送消息的中間轉發(fā)者,負責處理用戶權限、消息隊列等事務并向指定客戶端轉發(fā)由服務器推送的消息。具體使用機制如下圖所示。
(1)客戶端首先將應用名和賬號發(fā)送給C2DM服務器進行注冊,注冊成功后客戶端會收到并存儲C2DM返回的注冊標識。
(2)客戶端向自己的服務器發(fā)送該標識和注冊成功的賬號,使得服務器能使用標識和賬號向C2DM請求消息推送。
(3)當服務器需要向客戶端發(fā)送數據時,獲取該客戶端注冊使用C2DM功能的用戶賬號的登陸權限。
(4)服務器把要發(fā)送的消息、客戶端注冊標識、賬號登陸權限一并發(fā)送給C2DM服務器。
(5) C2DM服務器會把收到的消息推送給相應的客戶端。
由于其為Google公司提供的原生服務,因此無需實現和部署服務端。然而,正因為其原生性,使其需要用戶綁定Google帳號,同時由于該推送機制依賴于Google官方提供的C2DM服務器(服務器在國外),使得該服務在國內不夠穩(wěn)定,常常無法提供服務。另外,國內部分手機廠商,例如中興、華為等可能會去掉Google的這種原生服務,樣推送功能將不能使用。
3.基于MQTT協(xié)議的推送機制
MQTT (Message Queuing Telemetry Transport)是由 IBM 在 2001 年發(fā)布的輕量級的消息傳輸協(xié)議,支持可發(fā)布/可訂閱的消息推送模式。協(xié)議的輕量級使它十分適合在用在資源受限的環(huán)境該協(xié)議最初是為物聯(lián)網設計的,現在也可用來實現消息推送。推送機制的實現主要依靠一個實現了MQTT協(xié)議的代理服務器,客戶端首先連接代理服務器,然后進行消息訂閱,同時,客戶端也可向服務器發(fā)布消息,其他客戶端訂閱后也可接收這些消息,因此消息也可在客戶端之間傳輸。該推送機制中代理服務器一般是采用IBM的MQTT服務器RSMB(Really Small Message Broker),客戶端一般是采用 IBM 的提供的 wmqtt.jar 包。
MQTT協(xié)議是基于代理的“發(fā)布/訂閱”模式的消息傳輸協(xié)議。由于該協(xié)議簡潔、小巧、可擴展性強的優(yōu)點,使得基于該協(xié)議的推送機制較省流量和省電,目前已有C++語言編寫的服務端組件RSMB。然而由于基于MQTT協(xié)議的推送機制實現較復雜,目前這種機制還不夠成熟。另外,由于服務器端組件RSMB不開源,也使得在之上的二次開發(fā)很困難。
4.基于第三方的推送機制
第三方推送平臺有百度云推送、極光推送、_蝶推送、個推等。這些平臺是面向個人幵發(fā)者或者企業(yè)幵發(fā)者的,它們一般是按需收費的,能提供多樣化的推送。以百度云推送為例,它支持推送文字和富媒體,支持向單用戶和群組用廣的推送等。開發(fā)者開發(fā)過程中需要在將第三方平臺的SDK集成到客戶端,這樣,服務器端推送消息吋調用第三方服務器的接口,就可以實現推送消息至客戶端。
第三方推送最大的優(yōu)點是支持多種格式數據的推送和超高并發(fā)連接數,然而他們也存在缺陷,例如極光推送使用的自定義的二進制協(xié)議,不支持推送信息的加密和身份認證,百度云的加密推送需要額外付費等。另外,采用第三方企業(yè)的SDK有程序嵌入的顧慮,存在風險。
5.基于XMPP協(xié)議的推送機制
基于XMPP協(xié)議的消息推送機制繼承了 XMPP協(xié)議的優(yōu)點,具備很強的靈活性和可擴展性,并且將復雜性從客戶端轉移到服務器端。H前基于該協(xié)議己有比較成熟的推送框架,最著名的服務器端推送框架是Openfire,其采用Java開發(fā),安裝、配置和使用都十分容易,并利用Web平臺進行管理,基于Openfire能夠輕松進行二次開發(fā)并實現個性化的推送功能。而客戶端框架是Smack包,它完整的實現了 XMPP協(xié)議的幵源API庫,同時,為適應Android運行環(huán)境,該包還存在Android平臺上的構建版本aSmack。另外,H前基于XMPP協(xié)議還存在另一個推送機制 Androidpn。它是一個整合方案,其客戶端基于aSmack,服務器端的實現是基于Openfire,并精簡了 Openfire過于繁復龐大的功能,僅僅分離出了消息推送服務。
以Openfire和Smack包構建的基于XMPP協(xié)議的推送機制為例,如下圖所示,客戶端首先和服務器端進行連接,連接后消息可以在服務器端和客戶端、客戶端和客戶端間雙向傳輸。
基于XMPP協(xié)議的推送機制能夠實現真正意義上的即時推送,不用像C2DM服務需要擔心由于服務器在國外帶來的推送服務的不穩(wěn)定性,也不存在使用第三方的SDK帶來的安全風險。同時該機制繼承了 XML的優(yōu)點,具備很強的可擴展性,可以實現復雜的通信。雖然目前基于XMPP協(xié)議的推送只支持文字格式的推送,但己滿足大部分系統(tǒng)的推送需求,因為一般情況下,推送消息只是告訴客戶端服務器端有變化,而變化的具體內容則由客戶端主動到服務器獲取。目前已有Java語言編寫的服務器端與客戶端開源程序,使開發(fā)者很容易進行二次開發(fā),根據具體需求搭建自己的系統(tǒng)。
