推送服務

推送技術的基礎思想是將瀏覽器主動查詢信息改為服務器主動發送信息。 服務器發送一批數據，瀏覽器顯示這些數據，同時保證與服務器的連接。當服務器需要再次發送一批數據時，瀏覽器顯示數據並保持連接。以後，服務器仍然可以發送批量數據，瀏覽器繼續顯示數據，依次類推。

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應用程序。

使用C2DM服務

簡介：使用C2DM服務（Google Cloud Messaging）Google推出的雲消息服務，即第二代的G2DM。

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

缺點：Android版本限制（必須大於2.2版本），該服務在國內不夠穩定、需要用户綁定Google賬號，受限於Google。

使用XMPP協議

簡介：使用XMPP協議（Openfire + Spark + Smack）基於XML協議的通訊協議，前身是Jabber，目前已由IETF國際標準化組織完成了標準化工作。

優點：協議成熟、強大、可擴展性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發實例androidpn。

缺點：協議較複雜、冗餘（基於XML）、費流量、費電，部署硬件成本高。

使用MQTT協議

簡介：輕量級的、基於代理的“發佈/訂閲”模式的消息傳輸協議。

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

缺點：不夠成熟、實現較複雜、服務端組件rsmb不開源，部署硬件成本較高。

使用第三方推送服務

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

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

缺點：有程序嵌入顧慮

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

Win-Phone

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

推送方案評價標準

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

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

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

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

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

- 同時在線時峯值 （一般按照百萬併發連接時服務器穩定性評測）

- 高併發時消息平均延遲時間（一般按照1分鐘處理1百萬條信息評測）

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

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

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

- 每日聯網23.5小時以上用户比例 （表徵聯網穩定性）

- 消息發送後9小時內收到率 （表徵到達率）

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

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

省流量應注意協議的修改和冗餘數據包的處理，一般用空載待機月流量評判

省成本應考慮單服務器承載同時連接數，可承載同時連接數越多成本越低，業內 頂尖水平為個推的單服務器50萬連接

推送服務應該體積儘量小，不影響主程序的大小和複雜度，一般以小於300K為宜。