推播技術

推播技術（英語：Push technology），或者說是是一種基於Internet通訊方式的伺服器推播，其中要求通訊的請求是由發佈者或中央伺服器發起。與 pull/get 形成對比，額外訊息傳輸的相應一般由接收者或客戶端發起。

推播服務通常是基於提前的訊息預設置上。也就是所謂的 publish/subscribe 模型。客戶通過訂閱由伺服器提供各種訊息的頻道，不論何時都可以在其中一個頻道得到新的內容，同樣伺服器通過推播把訊息傳遞給相應的客戶端。

推播技術有時候也會模仿輪詢方式去推播，尤其是在不能真正地去推播地情況下，例如那些命令拒絕HTTP/S請求的安全策略的站點。

常見使用

同步會議和即時通訊是推播服務的典型事例。聊天訊息和臨時檔案一旦被傳送，用戶就會通過推播服務接收到。分離的 peer-to-peer 程式（例如 WASTE ）和集中的程式（例如 IRC 或 XMPP ）都允許推播檔案，這就意味着發件人開始進行數據的傳送，而不是收件人。

Email 可能也是一個推播系統：SMTP 協定是一個推播協定（見 Push e-mail）。然而，從郵件伺服器到桌面電腦的最後一步通常使用的是像 POP3 或 IMAP 這樣的 pull 協定。現代電子郵件客戶端通過反覆輪詢郵件伺服器，使這一步看起來是瞬間的，它經常檢查是否有新郵件。IMAP 協定包括 IDLE command，它允許伺服器當新郵件到達時向客戶端發訊息。初代的黑莓是第一個在無線環境下推播電子郵件的裝置，使得它成為當今的佳話。

其他例子是 PointCast Network （點播式網絡），它在二十世紀九十年代具有非常廣泛的應用。它通過屏保推播新聞和股票行情。在瀏覽器戰爭的巔峰時期，Netscape 和 Microsoft 通過在他們的軟件里整合頻道定義格式（CDF）推播技術，但是那時並沒有多少人關注。 CDF 消失了並移出了瀏覽器的時代，取而代之的是2000年的 RSS （一種下拉式系統）。

例子

網頁推播

這個網絡工程師極力推崇的網頁推播方案是一個簡單的協定，通過使用 HTTP2 版本的去即時的事件。例如來電或留言，能夠被即時的傳達（或者說推播）出去。這個協定將所有即時的事件都合併到一個簡單的對談中，其中這個對談可以確保不管在網絡還是音頻資源上都有很好的使用效率。這一個簡單的服務包含了所有的事件，並在當它到達分發給對應的應用所有的事件。這個請求只需要一個對談，避免了重複傳送這樣高昂的成本。

HTTP伺服器推播

HTTP 伺服器推播（也稱為 HTTP 流）是一種將未經請求的（非同步）數據從Web伺服器傳送到Web瀏覽器的機制。任何一種機制都可以實現 HTTP 服務的推播。

一些 HTML5 的 WebSocket API 允許 Web 伺服器和客戶端，通過 TCP 全雙工通訊進行交流。

一般情況下，當響應完畢一個來自客戶端的請求之後，Web 伺服器不會去終止一個連接。 Web 伺服器使連接打開，以便當發生事件（例如，需要向一個或多個客戶端報告的內部數據的變化）時，可以立即傳送它；否則，該事件必須排隊，直到接收到客戶端的下一個請求為止。大多數 Web 伺服器都通過 CGI 提供這種功能（例如，Apache HTTP 伺服器上未解析的報頭指令碼）。這是一種靠分塊傳輸編碼方法的基本機制。

另一種機制關係到一個特殊的 MIME 類型，稱為 multipart/x-mixed-replace，這是由 Netscape 在1995年引入的。當伺服器想向客戶端推出新版本時，Web 瀏覽器將此理解為一個檔案改變。它如今仍然被 Firefox 、 Opera 和 Safari 支援，但它被 Internet Explorer 忽略了。它可以應用於 HTML 文件，以及用於串流傳輸圖像的相機應用。

網頁超文字應用技術工作小組（WHATWG）Web Applications 1.0 proposal 包括一個機制來推播內容到客戶端。2006年9月1日， Opera Web 瀏覽器在一個名為「伺服器傳送事件」的功能中實現了這個新的實驗系統。現在它作為 HTML5 的一部分被標準化了。

推播技術

在這個技術，伺服器充分利用持久的 HTTP 協定，使得響應永久打開，（即伺服器永不關閉響應），有效地去欺騙瀏覽器保持載入，直到初始頁面被認為完全載入完畢之後。然後伺服器周期的傳送 JavaScript 代碼去更新這網頁的內容。從而實現推播能力，通過使用這個技術，客戶不需要JAVA程式或者其他的外掛程式程式去保持與伺服器的連接。客戶端也會自動地收到新事件，推播給伺服器。這個方法有一個嚴重的不足，就是缺乏一種控制，伺服器已經結束行程使瀏覽器連接逾時；一個頁面如果發生連接逾時必然會導致其重新整理。

長輪詢

長輪詢本身並不是一個真正的推播；長輪詢是傳統輪詢技術的一種變體，但是它允許在一個真正的推播不可能的情況下模擬推播機制，例如安全策略的網站需要阻止的HTTP/S請求。

長輪詢， 客戶端從伺服器請求訊息與正常輪詢完全相同，但正如你預料到的，伺服器可能不會立即回應。當收到輪詢時如果伺服器的客戶端沒有新的訊息，不是傳送一個空的響應，伺服器端公開請求並等待成為有用的響應訊息。一旦它獲得新的訊息，伺服器會立即向客戶端傳送 HTTP/S 的響應，完成開放 HTTP 的請求。收到伺服器響應後，客戶端通常會立即發出另一個伺服器的請求，這樣，通常的反應延遲（訊息第一次可用到下一個客戶端請求的中間時間）與客戶端的消除相關。

例如，當這樣的連接是困難的或不可能直接採用的（例如，在web瀏覽器），作為對連續 TCP 連接的長輪詢的替代，BOSH 是一個流行的、長壽的 HTTP 技術。在 XMPP 是一個潛在的技術，蘋果用於 iCloud 的推播支援。

Flash XMLSocket 傳達

這項技術被 cbox（Cbox is a chat application for online communities and groups. Get a Cbox, and your visitors and users can engage with one another in real-time conversation.）和其他聊天應用程式所使用，並在一個單像素 Adobe Flash 電影中使用 XMLSocket 對象。在 JavaScript 控制下，客戶端建立一個 TCP 連接到伺服器上的單向中繼。中繼伺服器不會從這個通訊端讀取任何內容，相反它會向客戶端傳送一個唯一識別碼。接下來客戶機向 web 伺服器傳送 HTTP 請求，包括這個識別碼。Web 應用程式可以將向客戶機傳送的訊息傳送到中繼伺服器的本地介面，然後中繼伺服器通過 Flash 通訊端傳遞給客戶機。這種方法的優點是，它能鑑別許多 web 應用程式的典型的讀寫不對稱，包括聊天，它還提供了更高的效率。由於它不接受傳出通訊端的數據，所以中繼伺服器根本不需要輪着傳出 TCP 連接，使其保持數萬個並行連接成為可能。在這個模型中擴充的限制是底層伺服器作業系統的 TCP 堆疊。

可靠的組數據傳送 (RGDD)

例如雲端運算的服務，增加數據的可靠性和可用性，這通常被推播（被複製）到多台機器上。例如， Hadoop 分散式檔案系統（資料庫）對所有的儲存對象複製兩個副本。RGDD 重點研究有效的鑄造一個對象從一個位置到多個位置與此同時通過傳送極小的數目的副本來節省寬頻（在最好的情況下只有一個）在任何跨越網絡的對象。例如，數據廣播是一個在數據中心傳遞多個節點，依靠規則和結構化拓撲和 DCCast 是一個類似接近跨過數據中心交付方法的方案

參見

• WebSocket
• Comet
• Ajax
• Push mail