-
推送
鎖定
網頁推送，是指將經過整理的信息資源以網頁的形式迅速轉發至用户的界面，實現用户的多層次需求，使得用户能夠自己設定所需要的信息頻道，並直接在用户端接收定製信息的實現方式。
- 中文名
- 推送
- 外文名
- push
- 技術定義
- 服務器和客户機間的通信連接方式
- 定 義
- 將整理的信息資源迅速轉發至用户
推送服務器推送
Server push——嶄新的“推”技術，它是一種先進的服務器和客户機之間的通信連接方式，利用在服務器端的CGI腳本程序把數據源源不斷地推向客户機，從而使客户機和服務器之間的交互性能大大提高。在中國計算機報電腦工作室中有介紹Serverpush，我們也蒐集整理一些關於Server push的資料，供大家參考。
首先也來看看傳統Client pull的工作方式，Client pull以 這樣的HTML文檔頭來自動刷新頁面，使用户的瀏覽器能不斷地刷新以接受服務器傳回的內容，那麼用户就不得不忍受等待“time”值的痛苦，相信在中國電信的網速之下，大家對這個深有體會。
採用了Serverpush技術的服務器在客户機做出一個請求後，和客户機建立一個永久的連接，然後服務器會根據客户機的請求不斷把數據包推向客户，這個推的過程是不間斷的。由服務器推向客户機的數據在客户機的瀏覽器上會不斷產生新的內容，而且不會產生Client pull那樣的HTML文檔頭，從而大大減少了延遲的時間，向（服務器響應——客户機請求）同步邁進了一步。
實現Serverpush技術非常簡單。Server push在服務器的CGI腳本聲明HTML文檔類型時，把傳統的content-type:text/html改為content-type:multipart/x-mixed-replace;boundary=BOUNDARY這樣的文檔類型，就會反饋給用户一個Server push類型的連接。這是Serverpush和Client pull的根本區別。如果CGI腳本中提供了這樣的HTML文檔頭，服務器在處理客户機請求調用CGI腳本程序時，就會把CGI腳本中指定的數據強行推給客户機。
Serverpush在生成頁面時會採用很多的技巧來處理用户端瀏覽器頁面的生成。主程序和傳統方式沒有本質的區別，但記得在腳本中加入print“Content-Type:multipart/x-mixed-replace;boundary=BOUNDARY”這樣的文檔頭。應用在PERL寫的CGI聊天室中有立竿見影之效，其速度和刷新方式和傳統聊天室不是一個檔次的
[1]
。
常用的服務器推送技術實現方式有以下三種。
- 服務端代碼編程：最簡單的方法是通過服務端代碼編程實現，響應代碼中使用死循環。當Web服務器接收到客户請求後開啓一個線程執行服務端代碼，而該方法由遲遲不肯結束，使線程無法釋放。這種方法的缺點是當客户端數量增加時，服務器依然會承受很大的負擔。
- 使用特定的Web服務器：目前的趨勢是從Web服務器內部入手，用NIO（JDK1.4提出的java.nio包）改寫Request/Response的實現，再利用線程池增強服務器的資源利用率，從而解決這個問題。JDK1.4版本最顯著的新特性就是增加了NIO，能夠以非阻塞的方式處理網絡的請求，這就使得在Java中只需要少量的線程就能處理大量的併發請求了。目前支持這一非J2EE官方技術的服務器有Glassfish和Jetty。Jetty6設計來處理大量併發連接，它使用Java語言的不堵塞I/O(java.nio)庫並且使用優化的輸出緩衝架構。Jetty也有一個處理長連接的殺手鐧:一個稱為Continuations的特性。Grizzly作為GlassFish中非常重要的一個項目，就是用NIO的技術來實現應用服務器中的高性能純Java的HTTP引擎。Grizzly還是一個獨立於GlassFish的框架結構，可以單獨用來擴展和構建自己的服務器軟件。使用NIO不是一件簡單的技術，它的一些特點使得編程的模型比原來阻塞的方式更為複雜。
- 使用框架：基於Java的成熟的服務器推送框架有DWR（DirectWebRemoting）。DWR是開源的基於Apache許可協議的解決方案，它通過將服務器端的Java代碼映射稱瀏覽器端可使用的JavaScript來實現遠程調用，本質上還是Ajax實現。DWR從2.0開始增加了服務器推送功能[5]。Java平台上Ajax-RPC還有Dojo、Comet4J、Pushlet等框架，但DWR相對成熟且功能完善[6]。DWR可以將Java對象中需要遠程調用的public方法自動轉換成瀏覽器端可直接調用的JavaScript代碼，這些代碼發出的請求由指定的DWRServlet處理後自動直接調用相應的Java方法。這樣整個過程開發者不需要直接處理XMLHttpRequest也不需要處理方法參數或轉化返回值，都由DWR自動實現。這種實現方式技術成熟，配置簡單，DWR與Spring、Struts2、ExtJS都能整合 [1] 。
推送手機推送
推送內容
手機推送服務是指服務器定向將信息實時送達手機的服務。與常見的輪詢方式（偽推送）相比區別主要在於兩點，一是否長聯網，二是到達實時性。推送服務是長聯網的，一般到達手機的延遲在0.1-0.5秒左右，而輪詢方式（偽推送）不是長聯網的，達到延遲時間則根據輪詢時間的不同為1-10分鐘，也有延遲1小時或一天的情況。一般來説，自黑莓，蘋果和安卓採用標準長連接推送方式後，手機推送服務就特指能夠實時到達的形式。
手機推送服務的原理很簡單，就是通過建立一條手機與服務器的連接鏈路，當有消息需要發送到手機時，通過此鏈路發送即可。
推送服務的使用流程雖然略有差別但是大致都和 iOS的APNs 相似：
1、首先是應用程序註冊消息推送。
2、 iOS 向 APNs Server 取得deviceToken。應用程序接受deviceToken。
3、應用程序將deviceToken發送給PUSH服務端程序。
4、 服務端程序向APNs服務發送消息。
5、APNs服務將消息發送給iPhone應用程序。
推送實現方式
1、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、使用第三方推送服務
優點：穩定，成熟，節省開發和探索時間，相對自己開發成本低，推送管理界面及統計程序完善。
2、IOS推送
3、Win-Phone推送
使用MPNS（Microsoft 推送通知服務），相應速度不錯，但推送不帶狀態，很多功能無法實現。
推送評價標準
推送方案的公認評價採取4s標準：
1.Safe (安全)
推送方案應支持透傳及各種加密方案，保障信息傳遞安全。
推送方案的ID系統應該獨立於已有的網站或服務的ID系統，這樣保障用户在不同手機上登錄後的信息投遞準確 性，避免因為取消綁定事件失敗因網絡傳輸而造成的信息誤投送。
2. Stable（穩定）
穩定包括兩個部分一個是服務器端的穩定性，一個是手機端的穩定性。
服務端穩定性，因為使用長連接方案，對服務器的開銷和要求很大，推送方案對服務器開發要求很高，海量線程連接下的服務器穩定性是非常具有挑戰性的。一般的評判標準包括：
- 同時在線時峯值 （一般按照百萬併發連接時服務器穩定性評測）
- 高併發時消息平均延遲時間（一般按照1分鐘處理1百萬條信息評測）
- 服務穩定性 （一般要求全年99.9%以上可用，有備份，有負載均衡等）
手機端的穩定性，主要是因為中國的複雜網絡狀況及手機型號適配情況造成手機長時間穩定聯網較困難，所以穩定性非常重要，一般的評判標準包括：
- 每日聯網23.5小時以上用户比例 （表徵聯網穩定性）
- 消息發送後9小時內收到率 （表徵到達率）
一般來説，推送方案要做網絡的分運營商，分省，分機型適配，自己開發工作量較大。
3.Save（節省）
省電應注意CPU休眠，一般用服務縮短待機時間百分比評判。
省流量應注意協議的修改和冗餘數據包的處理，一般用空載待機月流量評判。
4.Slim（體積小）
客户端推送服務SDK應該體積儘量小，不影響主程序的大小和複雜度，一般以小於或等於300K為宜。
- 參考資料
-
- 1. 服務器推送技術研究 ．中國知網[引用日期2016-12-13]
- 2. Android實現推送方式解決方案 ．博客園．2012-03-04[引用日期2012-08-28]
- 3. 極光推送——要做“消息推送界的順豐” ．雷鋒網[引用日期2016-08-29]
