推送技術是指通過客戶端與伺服器端建立長連結，客戶端可以接收由伺服器端不定時傳送的訊息。
基本介紹
- 中文名：推送技術
- 外文名：push technology
概述,一般套用,典型實現,伺服器,Java pushlet,Long polling,Flash XMLSocket relays,其它,手機推送,評價標準,Safe (安全),Stable（穩定）,陷阱,
概述
在客戶機/伺服器的應用程式中，推送技術能夠向客戶機傳送數據而無需其發出請求，例如傳送電子郵件。相比較而言，全球資訊網卻是基於拉技術(Pull Technology)，因此客戶機瀏覽器必須事先向網頁發出請求，所需信息才能被傳送過來。傳播媒介都屬於推技術的套用範疇，因為不管是否有人接收，他們的信息都照發不誤。
一般套用
推送服務通常是在事先表達喜好的信息。這就是所謂的發布/訂閱模型。一個客戶端可能“訂閱”的各種信息“通道”。每當新的內容可以在這些渠道之一，伺服器會推出的信息給用戶。
同步會議和即時訊息是推動服務的典型例子。郵件和聊天，有時檔案推到了只要他們是由信息服務受到了用戶。同行都分散的對等程式（如廢物），並集中程式（如IRC或XMPP協定）允許推送檔案，這意味著傳送者發起數據傳輸,而不是接受者。
電郵也是一個推動系統：SMTP協定的基礎上，它是一個推動協定（見PushMail）。不過，最後一步，從郵件伺服器到桌面計算機通常使用的POP3或IMAP像拉協定。現代電子郵件客戶端走這一步似乎瞬間通過反覆投票的郵件伺服器，經常檢查新郵件了。 IMAP協定包括IDLE命令，它允許伺服器告訴客戶端新郵件到達時。原來的黑莓是第一推技術流行的例子了在無線方面的電子郵件。
另一種普及型網際網路推送技術為pointcast公司網路，該網路在1990年代獲得了知名度。它傳遞新聞和股市數據。 Netscape和微軟自己的軟體集成到它在瀏覽器大戰的高度，但後來逐漸消失，並在與RSS（一拉技術）2000年代取代。
其他用途的Web套用，包括推動市場數據發布（股票行情），線上聊天/訊息系統（網上聊天），拍賣，網上博彩和遊戲，運動的結果，監測主機和感測器網路監控。
典型實現
伺服器
HTTP伺服器推送（也稱為HTTP streaming）是一個從Web伺服器傳送數據到Web瀏覽器的機制。 HTTP伺服器推送可以通過幾種機制來實現。
一般來說，Web伺服器在回響後，就終止了到客戶端的數據連線。推送則是指該網站的伺服器連線是一直保持打開的，這樣如果接收到事件時，可以立即將回響傳送到一個或多個客戶端。或者將數據放入佇列，直到客戶端的下一個請求來到時，回響就被客戶端接收。大多數Web伺服器通過CGI提供這一功能（例如非解析頭在Apache腳本）。
另一種機制是與一種特殊的MIME類型，稱為多重/的X -混合取代，這是由Netscape在1995年。 Web瀏覽器將其解釋為改變每當伺服器就像推一個新版本的檔案到客戶端感受到這一點。它仍然支持由Firefox，Opera和Safari的今天，但傳統上由微軟忽略。可以套用到HTML檔案，也為串流影像的攝像頭套用。
1.0 Web應用程式的WHATWG建議包括一種機制來推送內容給客戶端。 9月1日，2006年，Opera網路瀏覽器執行了這項新的實驗技術的功能稱為“伺服器傳送的事件。”人們現在正作為HTML5的一部分規範化。另一個HTML5的相關部分是WebSockets API，它允許Web伺服器和客戶端通信通過一個全雙工TCP連線。
Java pushlet
原本是一個pushlet開發Java Web應用程式，雖然同樣的技術可以在其他web框架，以及聘請的技術。在這種技術中，伺服器需要持久HTTP連線回響的優勢，永遠離開了“開放”（即它永遠不會終止反應），將有效地愚弄“裝入”模式繼續瀏覽器的初始頁面載入後，通常是完整的。然後，伺服器傳送的JavaScript片段定期更新網頁內容，從而實現推動能力。通過使用這一技術並不需要在客戶端的Java小應用程式或其他外掛程式保持開放的連線到伺服器。該客戶端將自動通知由伺服器推向新的事件。一個嚴重的缺點，這種方法，然而，缺乏控制在瀏覽器中的伺服器逾時。一個頁面刷新總是必要的，如果在瀏覽器上逾時結束時發生。
Long polling
Long polling是一種傳統的輪詢技術的變化，並允許一個信息推送仿真從伺服器到客戶端。隨著Long polling，客戶端請求從一個類似的方式到正常的投票伺服器的信息。但是，如果伺服器沒有傳送一空，而不是任何反應為客戶提供的信息，伺服器保存請求，並等待一些信息可用。一旦信息變得可用（或之後一個合適的逾時），一個完整的回響被傳送到客戶端。然後，客戶端通常會立即重新從伺服器請求信息，因此伺服器將幾乎總是有一個可用的等待請求，它可以使用，以期在回響事件的數據。在web / AJAX的背景下，Long polling也被稱為Comet programming。
Long polling本身並不是一種推送技術，但可以根據實際情況推動使用。
Flash XMLSocket relays
這種技術是由Cbox等聊天套用，使得XMLSocket對象使用一個單像素的Adobe Flash電影。在JavaScript的控制，客戶端建立一個伺服器上的一個單向傳遞TCP連線。中繼伺服器不讀取這個插座什麼，而是立即向客戶機傳送一個唯一的標識符。接下來，客戶端發出一個HTTP請求到Web伺服器，包括它這個標識符。 Web應用程式可以然後推給了繼電器的伺服器，它在閃光燈插座繼電器他們的本地接口的客戶端的訊息。這種方法的優點是它讚賞自然讀寫不對稱，是許多Web應用程式，包括聊天典型，因此它提供了高效率。由於它不接受即將離任的插座上的數據，中繼伺服器不需要輪詢都傳出TCP連線，從而能夠容納數千的並發連線打開數萬。在此模型中，規模限制是TCP協定棧底層的伺服器作業系統。
其它
XMPP是通常用於推送應用程式以及，特別是PubSub的擴展。蘋果公司使用其移動我推支持這項技術。
波什是一項長期的HTTP技術在XMPP使用，但可以在網路上使用。該規範（XEP - 0124：雙向，在同步的HTTP（波什）流）條規定：本規範定義了一個傳輸協定，它模仿了一個長壽命，雙向兩個實體之間的TCP（如客戶端和伺服器）連線的語義通過有效地使用，而不需要頻繁輪詢或使用多個分塊同步回響HTTP請求/回響對。
手機推送
手機推送服務的原理很簡單，就是通過建立一條手機與伺服器的連線鏈路，當有訊息需要傳送到手機時，通過此鏈路傳送即可。 推送服務的使用流程雖然略有差別但是大致都和IOS的APNS相似
1、首先是應用程式註冊訊息推送。
2、 IOS跟APNS Server要deviceToken。應用程式接受deviceToken。
3、應用程式將deviceToken傳送給PUSH服務端程式。
4、 服務端程式向APNS服務傳送訊息。
5、APNS服務將訊息傳送給iPhone應用程式Push sevrice方案評價標
評價標準
推送方案的公認評價採取4s標準：1.Safe(安全) 2. Stable（穩定） 3.Save（省電省流量省成本） 4.Slim（體積小）
Safe (安全)
推送方案應支持透傳及各種加密方案，保障信息傳遞安全。
推送方案的ID系統應該獨立於已有的網站或服務的ID系統，這樣保障用戶在不同手機上登錄後的信息投遞準確性，避免因為取消綁定事件失敗因網路傳輸而造成的信息誤投送。
Stable（穩定）
穩定包括兩個部分一個是伺服器端的穩定性，一個是手機端的穩定性。
服務端穩定性，因為使用長連線方案，對伺服器的開銷和要求很大，推送方案對伺服器開發要求很高，海量執行緒連線下的伺服器穩定性是非常具有挑戰性的。一般的評判標準包括：
- 同時線上時峰值 （一般按照百萬並發連線時伺服器穩定性評測）
- 高並發時訊息平均延遲時間（一般按照1分鐘處理1百萬條信息評測）
- 服務穩定性 （一般要求全年99.9%以上可用，有備份，有負載均衡等）
鑒於伺服器穩定的開發難度很大，小團隊不建議自己開發，建議使用穩定的第三方推送方案，如個推，蝴蝶等。
手機端的穩定性，主要是因為中國的複雜網路狀況及手機型號適配情況造成手機長時間穩定聯網較困難，所以穩定性非常重要，一般的評判標準包括：
- 每日聯網23.5小時以上用戶比例 （表征聯網穩定性）
- 訊息傳送後9小時內收到率 （表徵到達率）
一般來說，推送方案要做網路的分運營商，分省，分機型適配，自己開發工作量較大
3.Save（節省）
省電應注意CPU休眠，一般用服務縮短待機時間百分比評判
省流量應注意協定的修改和冗餘數據包的處理，一般用空載待機月流量評判
省成本應考慮單伺服器承載同時連線數，可承載同時連線數越多成本越低，業內 頂尖水平為個推的單伺服器50萬連線
4.Slim（體積小）
推送服務應該體積儘量小，不影響主程式的大小和複雜度，一般以小於300K為宜。
陷阱
初步看來，實現一個推送系統並不是特別複雜，然後實際上，尤其是針對Android移動終端來說，仍然有相當多的技術問題需要克服。
電源管理
Android系統為了最大程度降低手機功耗、延長待機時間，在電源管理方面做了非常大量的底層工作，對電池的使用到了精打細算的地步。然而Android系統在電源管理方面做出的這些努力，很輕易地就能被不守規矩的應用程式消耗殆盡。個推SDK服務作為需要長期後台穩定運行的程式，在電源管理方面能夠做到取之有度，日均耗電量能夠控制在40mAh左右，對用戶日常手機使用幾乎沒有影響。
網路穩定性
在國內移動運營商網路條件下，地區差異、時間段差異、運營商差異都比較明顯，使得手機上實現穩定的聯網困難重重。為了在各種網路條件下，都能實現穩定聯網和流量消耗的兼顧平衡，個推研發了能夠根據網路狀況動態調整心跳間隔的自適應算法，以最小的網路代價實現最穩定的聯網質量。目前個推SDK空載流量消耗每月僅有0.8M-1.2M，不會對用戶的錢袋造成損失。
性能問題
為了實現千萬SDK同時連線到服務端，同時又能控制系統運營成本，推送平台需要具備平行可擴展能力，以及較高的接入伺服器性能。目前個推系統通過核心調優、代碼最佳化、層級架構設計等技術手段，已經實現單擊200w穩定線上，理論上支持無限平行擴展，並且經得起實踐考驗，正在線上上為超過千萬的用戶提供穩定的推送服務。
