Ⅰ Java Web 伺服器的消息推送 幾種方案
Java Web 伺服器的消息推送有以下幾種方案：1. 輪詢:前端使用ajax不停的發起請求獲取想要的數據（最簡單也是最容易耗盡伺服器資源）。
2. 長連接:HTTP長連接,客戶端向服務端發起請求，服務端等有數據了才response，否則一直持有該連接Cometgithub: comet4j 項目,可以直接下載配置jar到tomcat下使用。
3、使用xmpp協議的一種技術，能夠做到js中調用伺服器的Java方法。
消息推送建議用專業的推送平台，例如：極光。深圳市和訊華谷信息技術有限公司創立於2011年，其團隊核心成員來自騰訊、摩根士丹利、豆瓣、Teradata和中國移動等公司。公司總部位於深圳，在北京、上海、廣州、成都均設有辦公室。
Ⅱ 如何實現消息推送功能
?可以用第三方軟體極光推送來實現。對於定製化需求較強的，或者想擁有自己推送平台的開發者，極光提供全功能的私有雲方案。極光推送快速開始步驟: 1、到極光推送官方網站注冊開發者帳號；
2、登錄進入管理控制台，創建應用程序，得到 Appkey（SDK 與伺服器端通過 Appkey 互相識別）；
3、在推送設置中給 Android 設置包名、給 iOS 上傳證書、啟用 WinPhone，根據你的需求進行選擇；
4、下載 SDK 集成到 App 里。
客戶端初始化 JPush 成功後，JPush 服務端會分配一個 Registration ID，作為此設備的標識（同一個手機不同 App 的 Registration ID 是不同的）。開發者可以通過指定具體的 Registration ID 來進行對單一設備的推送。
Ⅲ html5消息推送功能怎麼做
前台可以設置一個setinterval，定期發送ajax監聽後台，也可以用HTML5的websocket，html5的方式比較新，消息比較短，適合做聊天系統。在WebSocket API中，瀏覽器和伺服器只需要要做一個握手的動作，然後，瀏覽器和伺服器之間就形成了一條快速通道。
webSocket是html5新引入的技術，允許後台隨時向前端發送文本或者二進制消息，WebSocket是一種全新的協議，不屬於http無狀態協議，協議名為「ws」，這意味著一個websocket連接地址會是這樣的寫法
WebSocket是為解決客戶端與服務端實時通信而產生的技術。其本質是先通過HTTP/HTTPS協議進行握手後創建一個用於交換數據的TCP連接，此後服務端與客戶端通過此TCP連接進行實時通信。
消息推送選擇極光。JPush 是經過考驗的大規模 App 推送平台，每天推送消息量級為數百億條。 開發者集成 SDK 後，可以通過調用 API 推送消息。同時，JPush 提供可視化的 web 端控制台發送通知，統計分析推送效果。 JPush 全面支持 Android, iOS, Winphone 三大手機平台。
Ⅳ HTTP和Websockets：了解現在的Web通信技術
API有很多分類。但是當涉及到網路通信時，我們可以確定兩種重要的API類型 Web Service APIs （例如SOAP，JSON-RPC，XML-RPC，REST）和 Websocket API 。但是，這些到底是什麼意思？讓我們深入了解Web通信協議的世界，並在最後討論如何選擇最佳的API機制。
HTTP是互聯網的基礎通信協議。 HTTP在客戶端-伺服器計算模型中充當請求-響應協議。 HTTP / 1.1是現代Web瀏覽器和伺服器中使用的最常見的HTTP版本。與HTTP的早期版本相比，此版本可以實現關鍵的性能優化和功能增強，例如持久性和流水線連接，分塊傳輸，請求/響應主體中的新標頭欄位等。其中，以下兩個標頭非常值得注意，因為HTTP的大多數現代改進都依賴於這兩個標頭。
到目前為止，REST（REpresentational State Transfer）的體系結構樣式是構造用於請求的Web API的最標准化的方式。REST純粹是一種基於多種原則的建築風格。遵循REST原理的API稱為RESTful API。REST API使用請求/響應模型，其中來自伺服器的每個消息都是對來自客戶端的消息的響應。通常，RESTful API使用HTTP作為其傳輸協議。在這種情況下， 查找 應使用 GET 請求。 PUT ， POST 和 DELETE 的要求應當用於 修改 ， 插入 ，和 刪除 分別（避免 GET 用於更新信息的請求）。
在HTTP輪詢中，客戶端通過遵循以下機制之一來輪詢請求新信息的伺服器。如今，大多數應用程序都使用輪詢，並且大多數情況下輪詢是通過RESTful實踐進行的。實際上，很少使用HTTP短輪詢，並且始終選擇HTTP長輪詢或定期輪詢。
HTTP流傳輸—提供長期連接，可進行即時和連續的數據推送
客戶端發出一個HTTP請求，伺服器發送一個不確定長度的響應（就像無限輪詢一樣）。HTTP流是高性能，易於使用的，並且可以替代WebSockets。
HTTP / 2是基於復用的流的有效傳輸層 -根據IETF，「流」是一個HTTP / 2連接內的客戶機和伺服器之間交換的幀的獨立的，雙向序列。它的主要特徵之一是單個HTTP / 2連接可以包含多個並發打開的流，其中任一端點都可以從多個流中插入幀。
WebSocket允許伺服器和客戶端在任何時間推送消息，而與先前的請求沒有任何關系。使用WebSockets的一個顯著優勢是， 幾乎每個瀏覽器都支持WebSockets 。
WebSocket解決了HTTP的一些問題：
示例應用程序：IM / Chat應用程序，游戲，管理前端
盡管據說每個瀏覽器都支持WebSockets，但中介程序中也可能有例外：
如果對REST和Websockets進行性能測試，則可能會發現存在高負載時Websockets的性能更好。這並不一定意味著REST效率低下。我個人的看法是，將REST與Websockets進行比較就像將蘋果與橙子進行比較。這兩個功能解決了兩個不同的問題，無法與像這樣的簡單性能測試進行比較：
但是，您現在應該了解，WebSockets是以近乎實時的方式處理長期存在的雙向數據流的絕佳選擇，而REST非常適合偶爾進行的通信。使用WebSockets本身佔用資源比較多，因此對於偶爾的連接來說是過大的選擇。
如果要在數據更改時從API獲取數據，則必須首先考慮使用輪詢。但是，當涉及伺服器之間的通信時，低效率的輪詢使我們付出了很多代價（平均而言，浪費了98.5％的輪詢）。
Webhooks —在沒有長期輪詢連接的伺服器之間發送數據的簡單方法
Webhooks是此問題的救星。在此請記住，通信通常發生在伺服器之間。首先，發送方節點預先在接收方節點中注冊一個回調URL。當發送方發生事件時，Webhook會被觸發，並使用在每個接收方中注冊的回調URL，將帶有新數據的事件對象作為HTTP POST請求發送到接收方節點。
很酷的事情是，可以通過webhooks大大減少發送方和接收方節點的伺服器負載。它可以確保更好的用戶體驗，同時開發人員可以將服務端點用於有意義的事情，而不會浪費輪詢。
Webhooks通常用於在事件發生時在伺服器之間發送通知和狀態更改。例如，當用戶通過單擊電子郵件中的按鈕取消訂閱時，它到達伺服器，並且發生用戶取消訂閱事件，此事件觸發相應的Webhooks，並且他們通知所有伺服器/服務該用戶現在已經從其訂閱伺服器中取消訂閱。服務
使用哪種技術取決於在您的應用程序上下文中什麼才更有意義。當然，您可以使用一些技巧來模擬一種技術與另一種技術的行為，但是通常更可取的是使用一種更適合您的通訊模型的技術（當被本書使用時）。
HTTP and Websockets: Understanding the capabilities of today』s web communication technologies