伺服器如何推送sse

❶ java Web 伺服器的消息推送 幾種方案

Java Web 伺服器的消息推送有以下幾種方案：
1. 輪詢:前端使用ajax不停的發起請求獲取想要的數據（最簡單也是最容易耗盡伺服器資源）。
2. 長連接:HTTP長連接,客戶端向服務端發起請求，服務端等有數據了才response，否則一直持有該連接Cometgithub: comet4j 項目,可以直接下載配置jar到tomcat下使用。
3、使用xmpp協議的一種技術，能夠做到js中調用伺服器的Java方法。
消息推送建議用專業的推送平台，例如：極光。深圳市和訊華谷信息技術有限公司創立於2011年，其團隊核心成員來自騰訊、摩根士丹利、豆瓣、Teradata和中國移動等公司。公司總部位於深圳，在北京、上海、廣州、成都均設有辦公室。

❷ Uber實時推送平台是如何打造的

原文：Uber』s Real-Time Push Platform

譯者：LZM

Uber 建立的出行平台每天在處理全球數以百萬計的打車訂單。

實時打車市場是一個十分活躍的市場。一次行程包括多個參與者（乘客、司機），他們需要能在 APP 上實時查看、修改當前旅程的狀態。因此，Uber 需要保證每個參與者和他們的 APP 實時同步相關信息，無論是接車時間、達到時間還是行駛路線和附近的司機。

今天，手機端呈現的功能日益豐富，而這些功能對實時信息同步的需求也逐漸增多。本文將介紹 Uber 工程團隊如何把 Uber 平台信息同步機制從輪詢轉為基於 gRPC 的雙向消息流協議。

在 Uber 後台，一個行程連接了現實世界中的乘客和司機。在行程過程中，這兩個實體需要實時更新後台系統的信息。

我們思考一個場景：乘客發出打車請求，而司機在系統上等待接單。Uber 配對系統在後台自動匹配二者，向司機發送訂單。到此為止，每一方（乘客、司機、後台）應該彼此同步他們的內容。

如果一個新訂單帶來，司機 APP 會每隔幾秒輪詢一次信息以及時更新訂單狀態。與此同時，乘客 APP 也會每隔幾秒輪詢一個信息來查看司機時候接單。

輪詢的頻率由數據改變的速率決定。對於一個大型 APP（例如 Uber APP），這個變化速率從幾秒到幾個小時不等，變化范圍十分寬泛。

80% 的後台 API 請求都是來自客戶端的輪詢請求。激進的輪詢策略能讓 APP 的消息保持最新，但也會導致伺服器資源耗盡。任何輪詢過程中的 bug 都可能頻繁導致後台負載顯著加劇，甚至崩潰。隨著需要動態實時數據的功能的增加，這個方法變得不再可行。

輪詢會導致更快的電池消耗、應用程序延遲和網路級擁塞。這在城市中使用 2G/3G 網路或網路不穩定的地方尤其明顯。在這些地方，應用程序每次嘗試拉取信息時，都會重試多次。

隨著功能增加，開發者們嘗試重載輪詢 API 或重建一個新的 API。在高峰期，APP 同時向多個 API 發送輪詢請求。每個 API 負載數個功能。這些輪詢 API 本質上成為一組分片負載 API。但是，在 API 級別上保持一致性和邏輯分離仍然是一個越來越大的挑戰。

冷啟動問題是其中最具挑戰性的問題之一。每當 APP 啟動，所有功能都希望從後台獲取最新狀態，以渲染用戶界面。這導致多個 API 並發競爭，APP 不能成功渲染出正常界面，直到關鍵組件的消息被返回。在沒有優先順序的情況下，因為所有的 API 都有一些關鍵信息，所以應用載入時間會持續增加。糟糕的網路條件會進一步惡化冷啟動問題。

很明顯，我們需要一個徹頭徹尾的、對消息同步機制的改變。我們開啟了建立一個全新的實時推送平台的旅程。在這個平台上，伺服器可以根據需要向應用程序發送數據。當我們採用這種新架構時，我們發現效率有顯著的改進，同時也解決了不同的問題和挑戰。

接下來，來看看我們對推送平台的幾代改進以及該平台是如何演變的。

雖然使用消息推送是取代輪詢的自然選擇，但在如何構建推送機制上有很多需要考慮的問題。四個主要設計原則如下：

1）從輪詢到推送的簡單遷移

目前存在大量端設備在進行輪詢。新系統必須利用現有的、分配給輪詢 API 的負載和邏輯，而不是完全推倒重來。

2）簡易開發

與開發輪詢 API 相比，開發人員在推送數據方面不應該做截然不同的事情。

3）可靠性

所有消息應該通過網路可靠地發送到客戶的 APP 上，並在發送失敗時重試。

4）高效率

隨著 Uber 在發展中國家的迅速發展，數據使用成本對我們的用戶來說是一個挑戰，對於每天要在 Uber 平台上呆上幾個小時的司機來說尤其如此。新協議必須最小化伺服器和移動應用程序之間的數據傳輸量。

我們將這個消息推送系統命名為 RAMEN (Realtime Asynchronous MEssaging Network，實時非同步消息網路)。

任何時候，實時信息都在變化。消息的生命周期開始於決定生成一條信息的那一刻。微服務 Fireball 用於決定何時推送消息。很大部分決策都由配置文件決定。Fireball 在系統間監聽多種類型的事件，並決定是否推送給該消息涉及的客戶。

例如，當一個司機加單，司機和行程的狀態都會改變，並觸發 Fireball。之後，根據配置文件的內容，Fireball 決定何類消息應該推送給客戶。通常，一個觸發器會向多個用戶發送多個消息。

任何事件都可能被觸發器捕獲，例如一些客戶行為（如發出打車請求、打開 APP）、定時器到期、消息匯流排上的後端業務事件或是地理上的駛出 / 駛入事件。所有這些觸發器都被過濾並轉換為對各種後台 API 的調用。這些 API 需要客戶的上下文信息，如設備定位、設備的操作系統以及 APP 的版本號，來生成一個響應。Fireball 獲取設備上下文 RAMEN 伺服器，並在調用 API 時將它們添加到頭部。

所有來自 Uber APP 的伺服器調用都由我們的 API 網關提供。推送有效負載以同樣的方式生成。一旦 Fireball 決定了推送消息的對象和時間，API 網關就負責決定推送什麼。網關會調用各類域服務來生成正確的推送負載。

網關中的所有 API 在如何生成有效負載方面是相似的。這些 API 分為拉取式和推送式兩種。。拉取式 API 由移動設備調用來執行任何 HTTP 操作。推送 API 由 Fireball 調用，它有一個額外的 「推送」 中間件，可以攔截拉取式 API 的響應，並將其轉發給推送消息系統。

將 API 網關介乎於二者之間有以下好處：

l  拉式和推式 API 共享端設備上的大部分業務邏輯。一個給定的負載可以從拉式 API 無縫切換到推式 API。例如，無論你的 APP 是通過拉式 API 調用拉出一個客戶對象，還是 Fireball 通過推式 API 調用發送一個客戶對象，他們都使用相同的邏輯。

l  網關負責處理大量業務邏輯，如推送消息的速率、路由和消息驗證。

在適當的時候，Fireball 和網關一起生成發送給客戶的推送消息。負責將這些信息傳遞到移動設備的是 「推送消息傳遞系統」。

每條消息推送會根據不同的配置執行，這些配置項包括：

1）優先順序

由於為不同的用例生成了數百個不同的消息負載，因此需要對發送到 APP 的內容進行優先排序。我們將在下一節中看到，我們採用的協議限制在單個連接上發送多個並發負載。此外，接收設備的帶寬是有限的。為了給人一種相對優先順序的感覺，我們將信息大致分為三個不同的優先順序：

l  高優先順序：核心功能數據

l  中優先順序：其他有助於提升客戶體驗的功能數據

l  低優先順序：需要發送的數據規模大且使用頻率不高

優先順序配置用於管理平台的多種行為。例如，連接建立後，消息按照優先順序降序排列在套接字（socket）中。在 RPC 失敗的情況下，通過伺服器端重試，高優先順序消息變得更加可靠，並且支持跨區域復制。

2）存活時間

推送消息是為了改善實時體驗。因此，每個消息都有一個預先定義的生存時間，從幾秒到半個小時不等。消息傳遞系統將消息持久化並在發生錯誤時重試傳遞消息，直到有效值過期為止。

3）去重復

當通過觸發器機制或重傳機制多次生成相同的消息時，此配置項確定是否應該刪除重復的消息推送。對於我們的大多數用例，發送給定類型的最新推送消息足以滿足用戶體驗，這允許我們降低總體數據傳輸速率。

消息推送系統的最後一個組件是實際的有效負載交付服務。該服務維持著與世界各地數百萬 APP 程序的活躍連接，並在它們到達時將有效信息同步。世界各地的移動網路提供了不同級別的可靠性，因此傳輸系統需要足夠魯棒以適應故障。我們的系統保證 「至少一次」 交貨。

為了保證可靠傳輸，我們必須基於 TCP 協議，建立從應用程序到數據中心的持久連接。對於 2015 年的一個應用協議，我們的選擇是使用帶有長輪詢、網路套接字或最終伺服器發送事件 (SSE) 的 HTTP/1.1。

基於各種考慮，如安全性、移動 SDK 的支持和數據大小的影響，我們決定使用 SSE。Uber 已經支持了 HTTP + JSON API 棧，它的簡單性和可操作性使它成為我們當時的選擇。

然而，SSE 是一種單向協議，即數據只能從伺服器發送到應用程序。為了提供之前提到的 「至少一次」 的保障，需要確認和重傳機制以構建到應用程序協議之上的交付協議中。在 SSE 的基礎上，我們定義了一個非常優雅和簡單的協議方案。

客戶端開始接收第一個 HTTP 請求的消息 /ramen/receive?seq=0，在任何新會話開始時序列號為 0。伺服器以 HTTP 200 和 「Content-Type: text/event-stream」 響應客戶端以維護 SSE 連接。接下來，伺服器將按照優先順序降序發送所有掛起的消息並依次遞增序列號。由於底層傳輸協議是 TCP 協議，如果沒有交付帶有 seq#3 的消息，那麼該連接應該已斷開、超時或失敗。

客戶端期望在下一個看到的帶有最大序列號重新連接 (在本例中 seq=2)。這就告訴了伺服器，即使編號 3 寫到了套接字上，它也沒有被正常傳遞。然後伺服器將重新發送相同的消息或以 seq=3 開始的任何更高優先順序的消息。該協議構建了流連接所需的可恢復性，伺服器負責大部分的存儲工作，在客戶端實現起來非常簡單。

為了獲知鏈接是否存活，伺服器每 4 秒會發送一個心跳包，這類數據包大小隻有一個比特。如果超過 7 秒沒有收到來自伺服器的消息或心跳，客戶端會認定服務終端並重新發起鏈接。

在上面的協議中，每當客戶端重新以一個更高的序列號發起連接時，它就充當伺服器刷新舊消息的確認機制。在一個環境良好的網路中，用戶可能會保持連接數分鍾，從而導致伺服器不斷積累舊消息。為了緩解這個問題，應用程序會每 30 秒一次調用 /ramen/ack?seq=N，不管連接質量如何。協議的簡單性允許用許多不同的語言和平台非常快速地編寫客戶端。

在設備上下文存儲上，RAMEN 伺服器在每次建立連接時存儲設備上下文，並將此上下文暴露給 Fireball。每個設備上下文的 id 是用戶及其設備參數對應的唯一哈希值。這允許隔離推送消息，即使用戶在不同的設置下同時使用多個設備或應用程序。

第一代 RAMEN 伺服器使用 Node.js 編寫，並使用 Uber 內部的一致性哈西 / 分片框架 Ringpop。Ringpop 是一個去中心化的分片系統。所有連接都使用用戶的 UUID 進行分片，並使用 Redis 作為持久性數據存儲。

在接下來的一年半時間里，消息推送平台在整個公司得到了廣泛的應用。高峰期時，RAMEN 系統通過維持高達 60 萬個並發數據流連接，每秒向三種不同類型的應用程序推送超過 70000 個 QPS 消息。該系統很快成為伺服器 - 客戶端 API 基礎結構中最重要的部分。

隨著通信量和持久連接的快速增加，我們的技術選擇也需要擴展。基於 Ringpop 的分布式分片是一個非常簡單的架構，不會隨著 ring 中的節點數量的增加而動態擴展。Ringpop 庫使用一種 gossip 協議來評估成員資格。gossip 協議的收斂時間也隨著環的大小增加而增加。

此外，Node.js 是單線程的，並且會有更高級別的事件循環延遲，從而進一步延遲成員信息的收斂。這些問題可能引發拓撲信息不一致，進而導致消息丟失、超時和錯誤。

2017 年初，我們決定重新啟動 RAMEN 協議的伺服器實現，以繼續擴大應用規模。在這次迭代中，我們使用了以下技術：Netty、Apache Zookeeper、Apache Helix、Redis 和 Apache Cassandra。

1）Netty： Netty 是一個用於構建網路伺服器和客戶端的高性能庫。Netty 的 bytebuf 允許零拷貝緩沖區，這使得系統非常高效。

2）Apache ZooKeeper： Apache ZooKeeper 對網路連接進行一致性哈希，可以直接傳輸數據，不需要任何存儲層。但是與分散的拓撲管理不同，我們選擇了 ZooKeeper 的集中共享。ZooKeeper 是一個非常強大的分布式同步和配置管理系統，可以快速檢測連接節點的故障。

3）Apache Helix： Helix 是一個健壯的集群管理框架，運行在 ZooKeeper 之上，允許定義自定義拓撲和重新平衡演算法。它還很好地從核心業務邏輯中抽象出拓撲邏輯。它使用 ZooKeeper 來監控已連接的工作者，並傳播分片狀態信息的變化。它還允許我們編寫一個自定義的 Leader-Follower 拓撲和自定義的漸進再平衡演算法。

4）Redis 和 Apache Cassandra： 當我們為多區域雲架構做准備時，有必要對消息進行正確的復制和存儲。Cassandra 是一個持久的跨區域復制存儲。Redis 被用作 Cassandra 之上的容量緩存，以避免分片系統在部署或故障轉移事件中常見的群發問題。

5）Streamgate： 這個服務在 Netty 上實現了 RAMEN 協議，並擁有所有與處理連接、消息和存儲相關的邏輯。該服務還實現了一個 Apache Helix 參與者來建立與 ZooKeeper 的連接並維護心跳。

6）StreamgateFE (Streamgate Front End)： 該服務充當 Apache Helix 的旁觀者，從 ZooKeeper 上偵聽拓撲變化。它實現了反向代理。來自客戶機 (火球、網關或移動應用程序) 的每個請求都使用拓撲信息進行分片，並路由到正確的 Streamgate 工作程序。

7）Helix Controllers： 顧名思義，這是一個 5 節點的獨立服務，單獨負責運行 Apache Helix Controller 進程，是拓撲管理的大腦。無論何時任何 Streamgate 節點啟動或停止，它都會檢測到更改並重新分配分片分區。

在過去的幾年中，我們一直在使用這種架構，並且實現了 99.99% 的伺服器端可靠性。我們推動基礎設施的使用持續增長，支持 iOS、android 和 Web 平台上的十多種不同類型的應用程序。我們已經使用超過 1.5M 的並發連接來操作這個系統，並且每秒推送超過 250,000 條消息。

伺服器端基礎設施一直保持穩定運行。隨著我們為更多新城市提供各種各樣的網路服務和應用程序，我們的重點將是繼續提高向移動設備消息推送機制的長尾可靠性。我們一直在試驗新協議、開發新方法，以彌合和現實需求的差距。在檢查以往的不足時，我們發現以下方面是導致可靠性下降的原因。

1）缺乏認證

RAMEN 協議在減少數據傳輸進行了優化，僅在每 30 秒或客戶端重新連接時才發送確認消息。這將導致延遲確認，在某些情況下無法確認消息達到，因此很難區分是真正的消息丟失還是確認失敗。

2）連接不穩定

維持客戶端和伺服器的正常連接至關重要。跨不同平台的客戶端實現方式在處理錯誤、超時、後退或應用生命周期事件 (打開或關閉)、網路狀態更改、主機名和數據中心故障轉移等方面有許多細微差別。這導致了不同版本間的性能差異。

3）傳輸限制

由於該協議在 SSE 協議基礎上實現，因此數據傳輸是單向的。但是，許多新的應用程序要求我們啟用雙向消息傳輸機制。沒有實時的往返行程時間測量，確定網路狀況、傳輸速度、緩解線路阻塞都是不可能的。SSE 也是一個基於文本的協議，它限制了我們傳輸二進制有效負載的能力，不需要使用像 base64 這樣的文本編碼，從而獲得更大的有效負載。

2019 年底，我們開始開發下一代 RAMEN 協議以解決上述缺點。經過大量考量，我們選擇在 gRPC 的基礎上進行構建。gRPC 是一個被廣泛採用的 RPC 棧，具有跨多種語言的客戶端和伺服器的標准化實現，對許多不同的 RPC 方法提供了一流的支持，並具有與 QUIC 傳輸層協議的互操作性。

新的、基於 gRPC 的 RAMEN 協議擴展了以前基於 SSE 的協議，有幾個關鍵的區別：

l  確認消息立即通過反向流發送，提高了確認的可靠性，而數據傳輸量幾乎沒有增加。

l  實時確認機制允許我們測量 RTT，了解實時的網路狀況。我們可以區分真正的消息損失和網路損失。

l  在協議之上提供了抽象層，以支持流多路傳輸等功能。它還允許我們試驗應用級網路優先順序和流控制演算法，從而在數據使用和通信延遲方面帶來更高的效率。

l  協議對消息有效負載進行抽象，以支持不同類型的序列化。將來，我們會探索其他序列化方法，但要將 gRPC 保留在傳輸層。

l  不同語言的客戶端實現也讓我們能夠快速支持不同類型的應用程序和設備。

目前，這項開發工作處於 beta 版階段，很快就能上線。

消息推送平台是 Uber 出行體驗的組成部分之一。今天有數百種功能建立在該平台的基礎服務之上。我們總結了消息推送平台在 Uber 出行生態中取得巨大成功的幾個關鍵原因。

1）職能分離

消息觸發、創建和傳遞系統之間明確的職責分離允許我們在業務需求發生變化時將注意力轉移到平台的不同部分。通過將交付組件分離到 Apache Helix 中，數據流的拓撲邏輯和核心業務邏輯被很好的區分開，這允許在完全相同的架構上使用不同的有線協議支持 gRPC。

2）行業標准技術

構建在行業標准技術之上使我們的實現更加魯棒且低成本。上述系統的維護開銷非常小。我們能夠以一個非常高效的團隊規模來傳遞平台的價值。根據我們的經驗，Helix 和 Zookeeper 非常穩定。

我們可以在不同的網路條件下擴展到數百萬用戶的規模，支持數百個功能和幾十個應用程序。該協議的簡單性使其易於擴展和快速迭代。

原文:

https://eng.uber.com/real-time-push-platform/

❸ 如何實現消息推送功能

?可以用第三方軟體極光推送來實現。對於定製化需求較強的，或者想擁有自己推送平台的開發者，極光提供全功能的私有雲方案。
極光推送快速開始步驟: 1、到極光推送官方網站注冊開發者帳號；
2、登錄進入管理控制台，創建應用程序，得到 Appkey（SDK 與伺服器端通過 Appkey 互相識別）；
3、在推送設置中給 Android 設置包名、給 iOS 上傳證書、啟用 WinPhone，根據你的需求進行選擇；
4、下載 SDK 集成到 App 里。
客戶端初始化 JPush 成功後，JPush 服務端會分配一個 Registration ID，作為此設備的標識（同一個手機不同 App 的 Registration ID 是不同的）。開發者可以通過指定具體的 Registration ID 來進行對單一設備的推送。

❹ SSE(Server-Send Events)實踐

HTTP 是客戶端-伺服器計算模型中的請求-響應協議。要開始交換，客戶端向伺服器提交請求。為了完成交換，伺服器向客戶端返回響應。伺服器只能向一個客戶端發送響應 （發出請求的那個） 。在 HTTP 協議中，客戶端是消息交換的發起者。

伺服器發送事件 (SSE) 是一種簡單的技術，用於為特定的 Web 應用程序實現伺服器到客戶端的非同步通信。

有多種技術允許客戶端從伺服器接收有關非同步更新的消息。它們可以分為兩類： 客戶端拉取 和 伺服器推送 。

在客戶端拉取技術中，客戶端會定期向伺服器請求更新。伺服器可以使用更新或尚未更新的特殊響應進行響應。有兩種類型的客戶端拉取：短輪詢和長輪詢。

客戶端定期向伺服器發送請求。如果伺服器有更新，它會向客戶端發送響應並關閉連接。如果伺服器沒有更新，它也會向客戶端發送一個響應並關閉連接。

客戶端向伺服器發送請求。如果伺服器有更新，它會向客戶端發送響應並關閉連接。如果伺服器沒有更新，它會保持連接直到更新可用。當更新可用時，伺服器向客戶端發送響應並關閉連接。如果更新在某個超時時間內不可用，伺服器會向客戶端發送響應並關閉連接。

在伺服器推送技術中，伺服器在消息可用後立即主動向客戶端發送消息。其中，有兩種類型的伺服器推送：SSE和 WebSocket。

SSE 是一種在基於瀏覽器的 Web 應用程序中僅從伺服器向客戶端發送文本消息的技術。SSE基於 HTTP 協議中的持久連接， 具有由 W3C 標准化的網路協議和 EventSource 客戶端介面，作為 HTML5 標准套件的一部分。

WebSocket 是一種在 Web 應用程序中實現同時、雙向、實時通信的技術。WebSocket 基於 HTTP 以外的協議（TCP），因此可能需要額外設置網路基礎設施（代理伺服器、NAT、防火牆等）。

客戶端通過Http協議請求，在握手階段升級為WebSocket協議。

在數據欄位中，伺服器可以發送事件數據

伺服器可以發送唯一的事件標識符（id欄位）。如果連接中斷，客戶端會 自動重新連接 並發送最後接收到的帶有header的 Last-Event-ID 的事件 ID。

在重試欄位中，伺服器可以發送超時（以毫秒為單位），之後客戶端應在連接中斷時自動重新連接。如果未指定此欄位，則標准應為 3000 毫秒。

如果一行以冒號字元 : 開頭，客戶端應該忽略它。這可用於從伺服器發送評論或防止某些代理伺服器因超時關閉連接。

要打開連接，應創建一個 EventSource 對象。

盡管 SSE 旨在將事件從伺服器發送到客戶端，但可以使用 GET 查詢參數將數據從客戶端傳遞到伺服器。

要關閉連接，應調用方法 close()。

有表示連接狀態的 readyState 屬性：

客戶端接收消息並處理他們，可以使用onmessage方法

SSE可被大多數瀏覽器支持：

Spring Web MVC 框架 5.2.0 是基於 Servlet 3.1 API 且用線程池實現非同步應用程序. 所以應用能夠被使用在 Servlet 3.1+ 的容器，比如：Tomcat 8.5 和 Jetty 9.3.

使用Spring MVC來發送事件:

示例：

在這個例子中，伺服器每秒發送一個持續時間短的周期性事件流 - 一個有限的詞流，直到詞完成。

示例：

運行效果：

客戶端示例（words.html）：

運行效果：

在此示例中，伺服器發送持久的周期性事件流 - 每秒可能無限的伺服器性能信息流：

效果預覽（每秒輸出一次）：

非周期性是指沒有固定的時間周期，可能由其他因素在任意時刻都可能觸發，下面示例通過spring event來模擬觸發因子。

效果:

模擬觸發動作：調用 http://localhost:8080/sse/mvc/trigger?eventType=customer

客戶端收到數據：

Spring Web Flux 框架 5.2.0 是基於 Reactive Streams API 且使用 event-loop 計算模型來實現非同步java應用程序。 此類應用程序可以在非阻塞 Web 伺服器（例如 Netty 4.1 和 Undertow 1.4）和 Servlet 3.1+ 容器（例如 Tomcat 8.5 和 Jetty 9.3）上運行。

使用 Spring Web Flux 框架實現發送事件：

簡單示例：

和上面spring mvc的示例一樣，也是每秒輸出數據，實現如下：

效果：

對比spring mvc的實現，我們改為flux實現，如下：

效果和上面是一樣的，可以看出，reactive api是非常的簡潔。

❺ java中使用websocket推送消息伺服器端怎麼才能主動推送

目前要實現消息實時推送，有兩種方法，一種是ajax輪詢，由客戶端不停地請求伺服器端，查詢有沒有新消息，然後再由伺服器返回結果；另外一種就是long poll,通過一次請求，詢問伺服器有沒有新消息更新，如果沒有新消息時，會保持長連接，就一直不返回Response給客戶端。直到有消息才返回，返回完之後，客戶端再次建立連接，周而復始。這兩種都是單向鏈接，需要被動的請求伺服器，而不是由伺服器自動發給客戶端。
從上面可以看出其實這兩種方式，都是在不斷地建立HTTP連接，然後等待服務端處理，可以體現HTTP協議的另外一個特點，被動性。

❻ 一對一直播源碼開發，即時通訊技術實現有哪幾種選擇

在一對一直播交友源碼的開發過程中，即時通訊是最關鍵的功能之一。那一對一直播源碼系統是如何實現即時通訊的呢？
即時通訊就是實時語音文字視頻等交流，實現即時通訊目前有四種方式：短輪詢、長輪詢、SSE、websocket，接下來我們來按順序簡單了解一下。
（1）短輪詢
即每隔一小段時間就發送一個請求到伺服器，伺服器返回最新數據然後客戶端根據獲得的數據來更新界面，這樣就間接地實現了即時通信。這一方式的優點是簡單，缺點是對伺服器的壓力較大，浪費帶寬的流量，但通常情況下數據都是沒有發生改變的。
（2）長輪詢
即客戶端發送一個請求到伺服器，然後伺服器查看客戶端請求的數據（就是伺服器中的數據）是否發生變化，如果發生變化，就會立即響應返回，否則保持這個鏈接並定期檢查最新數據，直到發生了數據更新或者連接超時。因此，客戶端連接一旦斷開，就會再次發出請求，這樣一來，在相同的時間內大大減少了客戶端請求伺服器的次數。這一方式有一個弊端：伺服器長時間的連接會消耗資源，返回數據的順序無法保證，管理和維護困難。
（3）SSE
即伺服器推送事件，為了解決瀏覽器只能夠單向傳輸數據到服務端，HTML5提供了一種新的技術叫做伺服器推送事件SSE。SSE技術提供的是從伺服器單向推送數據給瀏覽器的功能，但是配合瀏覽器主動請求，實際上就是實現客戶端與伺服器之間的雙向通信。
（4）Websocket
在HTML5中，為了加強web的功能，提供了websocket技術，它不僅是一種web通信方式，也是一種應用層協議。它提供了瀏覽器和伺服器之間原生的全雙工跨域通信。通過瀏覽器和伺服器之間所建立的websocket連接，在同一時刻能夠實現客戶端到伺服器和伺服器到客戶端的數據發送。

❼ 消息推送是如何實現的

消息推送（Push）就是通過伺服器把內容主動發送到客戶端的過程。運營人員通過自己的產品或第三方工具對用戶移動設備進行主動消息推送。完成推送後，消息通知會展示在移動設備的鎖定屏幕及通知欄上，用戶點擊通知即可去往相應頁面。

現在流行的消息推送實現方式，主要為長鏈接方式實現。其原理是客戶端主動和伺服器建立TCP長鏈接，長鏈接建立之後，客戶端定期向伺服器發送心跳包用於保持鏈接，當有消息要發送的時候，伺服器可以直接通過這個已經建立好的長鏈接，將消息發送到客戶端。

個推作為國內移動推送領域的早期進入者，於2010年推出個推消息推送SDK產品，十餘年來持續為移動開發者提供穩定、高效、智能的消息推送服務，成功服務了人民日報、新華社、CCTV、新浪微博等在內的數十萬APP客戶。個推消息推送，也是運用的長鏈接方式實現消息推送的，其長鏈接穩定性高、存活好，消息送達率高。開發者通過集成個推消息推送SDK，即可簡單、快捷地實現Android和iOS平台的消息推送功能，有效提高產品活躍度、增加用戶留存。

如果您對個推消息推送感興趣，歡迎點擊前往了解詳情。

個推消息推送工作原理

❽ 怎麼實現伺服器給android客戶端主動推送消息

採用MQTT協議實現Android推送功能是一種解決方案。MQTT是一個輕量級的消息發布/訂閱協議，是實現基於手機客戶端的消息推送伺服器的理想解決方案。

常見的解決方案實現原理：

1、輪詢(Pull)方式：客戶端定時向伺服器發送詢問消息，一旦伺服器有變化則立即同步消息。

2、SMS(Push)方式：通過攔截SMS消息並且解析消息內容來了解伺服器的命令，但這種方式一般用戶在經濟上很難承受。

3、持久連接(Push)方式：客戶端和伺服器之間建立長久連接，這樣就可以實現消息的及時行和實時性。

(8)伺服器如何推送sse擴展閱讀：

推送消息注意事項：

1、支持第三方推送內容，是要客戶端和伺服器都支持的，客戶端和伺服器都導入推送SDK。

2、伺服器推送內容，可以精確指定推送時間，推送的具體接收人，用戶群，位置。

3、即推送的維度可以使時間，位置，人群。

4、極光使用了兩種不同的通知方式，一種是推送通知，一種是推送消息。

5、如果要使用androidpn，則還需要做大量的工作，需要理解XMPP協議、理解Androidpn的實現機制，需要調試內部存在的BUG。

參考資料來源：網路-伺服器

參考資料來源：網路-Android客戶端

參考資料來源：網路-信息推送

❾ 如何實現Netty框架中伺服器端的消息推送

netty框架是用在伺服器端，客戶端是嵌入式編程，通過自定義的tcp通信協議進行連接的，現在需求是這樣的，伺服器端只是用來和客戶端進行通信，現在有第三方如微信端進行支付成功後在資料庫里生成了一條數據，表示要往某個客戶端發送指令，以下兩種方式可供參考：
1、微信端生成通訊指令後調用TCP端的介面（負責通訊程序和資料庫交互的），在介面程序中通過定義Socket連到通訊程序伺服器端，根據通道編號去發送，但是這種會導致伺服器端的tcp客戶端連接變得更多。

2、直接在netty框架中定義了scheleAtF。
當然也可藉助第三方工具來完成推送。例如極光推送，極光推送具有以下功能：
1、多種消息類型
開發者可以輕松地通過極光發送各個移動平台的系統通知，還可以在控制台編輯多種富文本展示模板； 極光還提供自定義消息的透傳，客戶端接到消息內容後根據自己的邏輯自由處理。
2、用戶和推送統計
完整的消息生命周期查詢，並且可以形成「推送報表」與「用戶統計報表」呈現給開發者，用來觀察推送的效果和應用發展趨勢。
3、簡訊補充
通過極光後台推送APP通知消息，對於一些重要又不能遺漏的信息可以調用極光簡訊的後台對未收到的客戶端發送簡訊通知，保證消息的可靠性。
4、A/B 測試
合理的推送能夠激活用戶，提高用戶粘性，使用A/B分組測試的科學方法，根據測試反饋的結果，幫助開發者選擇最優化的推送方案。
5、極光推送安全包
為金融、新聞、政務及其他對推送安全要求極高的客戶提供安全嚴謹、穩定可靠的信息推送解決方案
6、可定製的私有雲
對於安全性要求更高，希望推送數據和系統存儲在自己伺服器的客戶，及個性化需求需要定製開發的，性能更高要求的，或者想擁有自己推送平台的甚至要求源碼授權二次開發的開發者，極光提供全功能的私有雲解決方案。
深圳市和訊華谷信息技術有限公司（極光 Aurora Mobile，納斯達克股票代碼：JG）成立於2011年，是中國領先的開發者服務提供商，專注於為開發者提供穩定高效的消息推送、一鍵認證以及流量變現等服務，助力開發者的運營、增長與變現。同時，極光的行業應用已經拓展至市場洞察、金融風控與商業地理服務，助力各行各業優化決策、提升效率。

❿ java有什麼框架可以實現服務端向客戶端推送消息

1. 你可以用 mima 通訊服務框架。

2. 當然我是不建議你伺服器端向客戶端推送消息的。最好是客戶端去伺服器端獲取消息。因為你不清楚你的客戶端現在是否在線。可以先推送服務的的消息先存起來，等客戶端向你發起連接請求時，獲取該要推送的消息。