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