推送服務

推送服務

推送服務中 推送技術的基礎思想是將流覽器主動查詢信息改為伺服器主動傳送信息。

  • 中文名稱
    推送服務
  • 目    的
    給最終使用者方便的提供最新信息
  • 服    務
    手機推送
  • 原    理
    建立一條手機與伺服器的連線鏈路

定義

推送技術的基礎思想是將流覽器主動查詢信息改為伺服器主動傳送信息。 伺服器傳送一批資料,流覽器顯示這些資料,同時保證與伺服器的連線。當伺服器需要再次傳送一批資料時,流覽器顯示資料並保持連線。以後,伺服器仍然可以傳送批量資料,流覽器繼續顯示資料,依次類推。

優勢

push 和 pull 這兩種技術手段非常不同,但目的幾乎一致,都是為了給最終使用者方便的提供最新信息。

客戶端拖曳技術中,伺服器傳送一批資料,在HTTP回響或文檔頭標記中插入指令,讓流覽器"在5秒內再次裝入這些資料"或"10秒內前往某URL裝入資料"。當指定的時間達到時,客戶端就按照伺服器的指示去做,或者重新整理當前資料,或者調入新的資料。

在伺服器推送技術中,HTTP 連線一直保持著,直到伺服器知道自己已結束傳送資料並傳送一個結束信號,或者客戶端中斷連線。而在客戶端拖曳技術中,並不保持HTTP連線,相反,客戶端被告知何時建立新連線,以及建立連線是獲取什麽資料。

伺服器推送中,奇妙之處在于"multipart/mixed"格式的 MIME,它能夠使一個報文(或HTTP回響)包含許多資料項、在客戶端拖曳中,奇妙之處在于HTTP回響頭標(或等效的HTML元素),它能告知客戶端在指定的延時時間後執行何種動作。

伺服器推送通常效率要比客戶端拖曳效率高,因為它不必為後續資料建立新的連線。由于始終保持連線,即使沒有資料傳輸時也是這樣,因此伺服器必須願意分配這些TCP/IP連線埠,對于TCP/IP連線埠數有限的伺服器這將是一個嚴重的問題。客戶端拖曳效率低,因為這必須每次為傳送資料建立新的連線。但是它不必始終保持連線。

在實際情況中,建立HTTP連線通常需要花費相當多的時間,多達一秒甚至更多。因此從性能上考慮,伺服器推送對于最終使用者更有吸引力,特別是對于需要經常更新信息的情況下。

伺服器推送相對客戶端拖曳的另一點優勢是,伺服器推送相對比較容易控製。而客戶端拖曳要與伺服器建立連線,伺服器為了處理將客戶端拖曳請求與特定的最終使用者匹配等情況,需要使用相當麻煩的演算法。

伺服器推送中,多個回響中連線始終保持,使伺服器可在任何時間傳送更多的資料。一個明顯的好處是伺服器完全能夠控製更新資料的時間和頻率。另外,這種方法效率高,因為始終保持連線。缺點是保持連線狀態會浪費伺服器端的資源。伺服器推送還比較容易中斷。

手機推送

服務簡介

手機推送服務是指伺服器定向將信息即時送達手機的服務。與常見的輪詢方式(偽推送)相比區別主要在于兩點,一是否長聯網,二是到達即時性。

推送服務是長聯網的一般到達手機的延遲在0.1-0.5秒左右,而輪詢方式(偽推送)不是長聯網的,達到延遲時間則根據輪詢時間的不同為1-10分鍾,也有延遲1小時或一天的情況。如右圖所示

一般來說,自黑莓,蘋果和安卓採用標準長聯網推送方式後,手機推送服務就特指能夠即時到達的形式。

服務原理

手機推送服務的原理很簡單,就是通過建立一條手機與伺服器的連線鏈路,當有訊息需要傳送到手機時,通過此鏈路傳送即可。

推送服務的使用流程雖然略有差別但是大致都和IOS的APNS相似

1、首先是應用程式註冊訊息推送。

2、 IOS跟APNS Server要deviceToken。應用程式接受deviceToken。

3、應用程式將deviceToken傳送給PUSH服務端程式。

4、 服務端程式向APNS服務傳送訊息。

5、APNS服務將訊息傳送給iPhone應用程式。

推送實現方式

Android 推送服務實現方式

方案1

使用C2DM服務

簡介:使用C2DM服務(Google Cloud Messaging)Google推出的雲訊息服務,即第二代的G2DM。

優點:Google提供的服務、原生、簡單,無需實現和部署服務端。

缺點:Android版本限製(必須大于2.2版本),該服務在國內不夠穩定、需要使用者綁定Google帳號,受限于Google。

方案2

使用XMPP協定

簡介:使用XMPP協定(Openfire + Spark + Smack)基于XML協定的通訊協定,前身是Jabber,目前已由IETF國際標準化組織完成了標準化工作。

優點:協定成熟、強大、可擴展性強、目前主要套用于許多聊天系統中,且已有開源的Java版的開發實例androidpn。

缺點:協定較復雜、冗餘(基于XML)、費流量、費電,部署硬體成本高。

方案3

使用MQTT協定

簡介:輕量級的、基于代理的"發布/訂閱"模式的訊息傳輸協定。

優點:協定簡潔、小巧、可擴展性強、省流量、省電,目前已經套用到企業領域(),且已有C++版的服務端組件rsmb。

缺點:不夠成熟、實現較復雜、服務端組件rsmb不開源,部署硬體成本較高。

方案4

使用第三方推送服務

簡介:通過嵌入SDK使用第三方提供的推送服務,目前主流的有 個推,PUBNUB,蝴蝶等

優點:穩定,成熟,節省開發和探索時間,相對自己開發成本低,推送管理介面及統計程式完善。

缺點:有程式嵌入顧慮

IOS推送實現方式

推薦使用APNS服務,穩定,方便,美中不足是沒有推送到達的回執和統計,不方便產品運營。如對此方面有需求可以使用 個推 等第三方推送服務解決

Win-Phone

使用MPNS(Microsoft 推送通知服務),相應速度不錯,但推送不帶狀態,很多功能無法實現。

推送方案評價標準

推送方案的公認評價採取4s標準:1.Safe(安全) 2. Stable(穩定) 3.Save(省電省流量省成本) 4.Slim(體積小)

Safe (安全)

推送方案應支持透傳及各種加密方案,保障信息傳遞安全。

推送方案的ID系統應該獨立于已有的網站或服務的ID系統,這樣保障使用者在不同手機上登錄後的信息投遞準確性,避免因為取消綁定事件失敗因網路傳輸而造成的信息誤投送。

Stable(穩定)

穩定包括兩個部分一個是伺服器端的穩定性,一個是手機端的穩定性。

服務端穩定性,因為使用長連線方案,對伺服器的開銷和要求很大,推送方案對伺服器開發要求很高,海量執行緒連線下的伺服器穩定性是非常具有挑戰性的。一般的評判標準包括:

- 同時線上時峰值 (一般按照百萬並發連線時伺服器穩定性評測)

- 高並發時訊息平均延遲時間(一般按照1分鍾處理1百萬條信息評測)

- 服務穩定性 (一般要求全年99.9%以上可用,有備份,有負載均衡等)

鑒于伺服器穩定的開發難度很大,小團隊不建議自己開發,建議使用穩定的第三方推送方案,如個推,蝴蝶等。

手機端的穩定性,主要是因為中國的復雜網路狀況及手機型號適配情況造成手機長時間穩定聯網較困難,所以穩定性非常重要,一般的評判標準包括:

- 每日聯網23.5小時以上使用者比例 (表征聯網穩定性)

- 訊息傳送後9小時內收到率 (表征到達率)

一般來說,推送方案要做網路的分運營商,分省,分機型適配,自己開發工作量較大

Save

省電應註意CPU休眠,一般用服務縮短待機時間百分比評判

省流量應註意協定的修改和冗餘封包的處理,一般用空載待機月流量評判

省成本應考慮單伺服器承載同時連線數,可承載同時連線數越多成本越低,業內 頂尖水準為個推的單伺服器50萬連線

Slim(體積小)

推送服務應該體積盡量小,不影響主程式的大小和復雜度,一般以小于300K為宜。

其它詞條