類型
網頁推送
推送網頁推送是指將經過整理的信息資源以網頁的形式迅速轉發至用戶的界面,實現用戶的多層次需求,使得用戶能夠自己設定所需要的信息頻道,並直接在用戶端接收定製信息的實現方式。
伺服器推送
Server push——嶄新的“推”技術，它是一種先進的伺服器和客戶機之間的通信連線方式，利用在伺服器端的CGI腳本程式把數據源源不斷地推向客戶機，從而使客戶機和伺服器之間的互動性能大大提高。在中國計算機報電腦工作室中有介紹Server push，我們也蒐集整理一些關於Server push的資料，供大家參考。
首先也來看看傳統Client pull的工作方式，Client pull以 這樣的HTML文檔頭來自動刷新頁面，使用戶的瀏覽器能不斷地刷新以接受伺服器傳回的內容，那么用戶就不得不忍受等待“time”值的痛苦，相信在中國電信的網速之下，大家對這個深有體會。
採用了Server push技術的伺服器在客戶機做出一個請求後，和客戶機建立一個永久的連線，然後伺服器會根據客戶機的請求不斷把數據包推向客戶，這個推的過程是不間斷的。由伺服器推向客戶機的數據在客戶機的瀏覽器上會不斷產生新的內容，而且不會產生Client pull那樣的HTML文檔頭，從而大大減少了延遲的時間，向（伺服器回響——客戶機請求）同步邁進了一步。
實現Server push技術非常簡單。Server push在伺服器的CGI腳本聲明HTML文檔類型時，把傳統的content-type:text/html改為content-type:multipart/x-mixed-replace;boundary=BOUNDARY這樣的文檔類型，就會反饋給用戶一個Server push類型的連線。這是Server push和Client pull的根本區別。如果CGI腳本中提供了這樣的HTML文檔頭，伺服器在處理客戶機請求調用CGI腳本程式時，就會把CGI腳本中指定的數據強行推給客戶機。
Server push在生成頁面時會採用很多的技巧來處理用戶端瀏覽器頁面的生成。主程式和傳統方式沒有本質的區別，但記得在腳本中加入print“Content-Type:multipart/x-mixed-replace;boundary=BOUNDARY”這樣的文檔頭。套用在PERL寫的CGI聊天室中有立竿見影之效，其速度和刷新方式和傳統聊天室不是一個檔次的。
手機服務
主要內容
手機推送服務是指伺服器定向將信息實時送達手機的服務。與常見的輪詢方式（偽推送）相比區別主要在於兩點，一是否長聯網，二是到達實時性。
推送服務是長聯網的，一般到達手機的延遲在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服務（Google Cloud Messaging）
簡介：Google推出的雲訊息服務，即第二代的G2DM。
優點：Google提供的服務、原生、簡單，無需實現和部署服務端。
缺點：Android版本限制（必須大於2.2版本），該服務在國內不夠穩定、需要用戶綁定Google帳號，受限於Google。
方案2、使用XMPP協定（Openfire + Spark + Smack）
簡介：基於XML協定的通訊協定，前身是Jabber，已由IETF國際標準化組織完成了標準化工作。
優點：協定成熟、強大、可擴展性強、主要套用於許多聊天系統中，且已有開源的Java版的開發實例androidpn。
缺點：協定較複雜、冗餘（基於XML）、費流量、費電，部署硬體成本高。
方案3、使用MQTT協定
簡介：輕量級的、基於代理的“發布/訂閱”模式的訊息傳輸協定。
優點：協定簡潔、小巧、可擴展性強、省流量、省電，套用到企業領域，且已有C++版的服務端組件rsmb。
缺點：不夠成熟、實現較複雜、服務端組件 rsmb 不開源，部署硬體成本較高。
方案4、使用第三方推送服務
簡介：通過嵌入SDK使用第三方提供的推送服務，主流的有百度雲推送，極光推送，智游推送，Urban Airship，個推，PUBNUB，蝴蝶等。
優點：穩定，成熟，節省開發和探索時間，相對自己開發成本低，推送管理界面及統計程式完善。
缺點：有程式嵌入顧慮
IOS推送實現方式
推薦使用APNS服務，穩定，方便，美中不足是沒有推送到達的回執和統計，不方便產品運營。如對此方面有需求可以使用個推蝴蝶等第三方推送服務解決。
Win-Phone推送實現方式
使用MPNS（Microsoft 推送通知服務），相應速度不錯，但推送不帶狀態，很多功能無法實現。
評價標準
推送方案的公認評價採取4s標準：
1.Safe(安全) 2. Stable（穩定） 3.Save（省電省流量省成本） 4.Slim（體積小）
1.Safe (安全)
推送方案應支持透傳及各種加密方案，保障信息傳遞安全。
推送方案的ID系統應該獨立於已有的網站或服務的ID系統，這樣保障用戶在不同手機上登錄後的信息投遞準確 性，避免因為取消綁定事件失敗因網路傳輸而造成的信息誤投送。
2. Stable（穩定）
穩定包括兩個部分一個是伺服器端的穩定性，一個是手機端的穩定性。
服務端穩定性，因為使用長連線方案，對伺服器的開銷和要求很大，推送方案對伺服器開發要求很高，海量執行緒連線下的伺服器穩定性是非常具有挑戰性的。一般的評判標準包括：
- 同時線上時峰值 （一般按照百萬並發連線時伺服器穩定性評測）
- 高並發時訊息平均延遲時間（一般按照1分鐘處理1百萬條信息評測）
- 服務穩定性 （一般要求全年99.9%以上可用，有備份，有負載均衡等）
鑒於伺服器穩定的開發難度很大，小團隊不建議自己開發，建議使用穩定的第三方推送方案，如個推，蝴蝶等。
手機端的穩定性，主要是因為中國的複雜網路狀況及手機型號適配情況造成手機長時間穩定聯網較困難，所以穩定性非常重要，一般的評判標準包括：
- 每日聯網23.5小時以上用戶比例 （表征聯網穩定性）
- 訊息傳送後9小時內收到率 （表徵到達率）
一般來說，推送方案要做網路的分運營商，分省，分機型適配，自己開發工作量較大。
3.Save（節省）
省電應注意CPU休眠，一般用服務縮短待機時間百分比評判。
省流量應注意協定的修改和冗餘數據包的處理，一般用空載待機月流量評判。
省成本應考慮單伺服器承載同時連線數，可承載同時連線數越多成本越低，業內頂尖水平為個推的單伺服器300萬連線。
4.Slim（體積小）
客戶端推送服務SDK應該體積儘量小，不影響主程式的大小和複雜度，一般以小於或等於300K為宜。
