web的推送的話，最優方案是用websocket，其次長輪詢，再其次ajax定時向後臺請求資料。如果是. net平臺開發的程式，可以用SignalR，它包含了以上三種方案並優先使用webSocket進行通訊

看到各位的回答沒有抓住題主問題，WEB實時推送，不是WEB實時互動。

WEB實時推送指的是伺服器端向客戶端使用者推送。

以下是我的回答，每個答案和各個場景有關。

1、ajax輪詢 -簡單開發成本小

ajax輪詢是客戶端發起的，可以根據自己的需要，指定一個合理的時間。這種方法非常簡單，幾乎不需要什麼改動。

2、服務端推送SSE-簡單可靠效能好SSE是Server-sent Events的簡稱，它是HTML5中的一種規範。目前為止那些老舊的瀏覽器是不直接支援SSE規範的，比如IE核心的瀏覽器。

SSE這個東西是可以實現服務端主動向客戶端進行通訊的，但是它僅僅是單向的。如果客戶端與伺服器端的資料互動不是特別頻繁，那麼我們是可以使用SSE技術來實現的。

服務端程式碼和前端程式碼稍加改動即可。

3、WebSocket 雙工實時互動WebSocket 是 HTML5 開始提供的一種在單個 TCP 連線上進行全雙工通訊的協議。

WebSocket 使得客戶端和伺服器之間的資料交換變得更加簡單，允許服務端主動向客戶端推送資料。在 WebSocket API 中，瀏覽器和伺服器只需要完成一次握手，兩者之間就直接可以建立永續性的連線，並進行雙向資料傳輸。

在 WebSocket API 中，瀏覽器和伺服器只需要做一個握手的動作，然後，瀏覽器和伺服器之間就形成了一條快速通道。兩者之間就直接可以資料互相傳送。

這個是服務端推送sse的升級版本。

4、web音影片推送 webrtc

這是一個新興的領域，以後所有的音影片直播大部分都是使用這個來實現。使用web來實現音影片直播。

隨著 Web 的發展，使用者對於 Web 的實時推送要求也越來越高 ，比如，工業執行監控、Web 線上通訊、即時報價系統、線上遊戲等，都需要將後臺發生的變化主動地、實時地傳送到瀏覽器端，而不需要使用者手動地重新整理頁面。本文對過去和現在流行的 Web 實時推送技術進行了比較與總結。

本文完整的原始碼請猛戳Github部落格，紙上得來終覺淺，建議大家動手敲敲程式碼。

一、雙向通訊

HTTP 協議有一個缺陷：通訊只能由客戶端發起。舉例來說，我們想了解今天的天氣，只能是客戶端向伺服器發出請求，伺服器返回查詢結果。HTTP 協議做不到伺服器主動向客戶端推送資訊。這種單向請求的特點，註定瞭如果伺服器有連續的狀態變化，客戶端要獲知就非常麻煩。在WebSocket協議之前，有三種實現雙向通訊的方式：輪詢（polling）、長輪詢（long-polling）和iframe流（streaming）。

1.輪詢（polling）

輪詢是客戶端和伺服器之間會一直進行連線，每隔一段時間就詢問一次。其缺點也很明顯：連線數會很多，一個接受，一個傳送。而且每次傳送請求都會有Http的Header，會很耗流量，也會消耗CPU的利用率。

優點：實現簡單，無需做過多的更改缺點：輪詢的間隔過長，會導致使用者不能及時接收到更新的資料；輪詢的間隔過短，會導致查詢請求過多，增加伺服器端的負擔

啟動本地服務，開啟,得到如下結果：

2.長輪詢（long-polling）

長輪詢是對輪詢的改進版，客戶端傳送HTTP給伺服器之後，看有沒有新訊息，如果沒有新訊息，就一直等待。當有新訊息的時候，才會返回給客戶端。在某種程度上減小了網路頻寬和CPU利用率等問題。由於http資料包的頭部資料量往往很大（通常有400多個位元組），但是真正被伺服器需要的資料卻很少（有時只有10個位元組左右），這樣的資料包在網路上週期性的傳輸，難免對網路頻寬是一種浪費。

優點：比 Polling 做了最佳化，有較好的時效性缺點：保持連線會消耗資源; 伺服器沒有返回有效資料，程式超時。3.iframe流（streaming）

iframe流方式是在頁面中插入一個隱藏的iframe，利用其src屬性在伺服器和客戶端之間建立一條長連線，伺服器向iframe傳輸資料（通常是HTML，內有負責插入資訊的javascript），來實時更新頁面。

優點：訊息能夠實時到達；瀏覽器相容好缺點：伺服器維護一個長連線會增加開銷；IE、chrome、Firefox會顯示載入沒有完成，圖示會不停旋轉。

啟動本地服務，開啟,得到如下結果：

上述程式碼中，客戶端只請求一次，然而服務端卻是源源不斷向客戶端傳送資料，這樣伺服器維護一個長連線會增加開銷。

以上我們介紹了三種實時推送技術，然而各自的缺點很明顯，使用起來並不理想，接下來我們著重介紹另一種技術--websocket,它是比較理想的雙向通訊技術。

二、WebSocket1.什麼是websocket

WebSocket是一種全新的協議，隨著HTML5草案的不斷完善，越來越多的現代瀏覽器開始全面支援WebSocket技術了，它將TCP的Socket（套接字）應用在了webpage上，從而使通訊雙方建立起一個保持在活動狀態連線通道。

一旦Web伺服器與客戶端之間建立起WebSocket協議的通訊連線，之後所有的通訊都依靠這個專用協議進行。通訊過程中可互相傳送JSON、XML、HTML或圖片等任意格式的資料。由於是建立在HTTP基礎上的協議，因此連線的發起方仍是客戶端，而一旦確立WebSocket通訊連線，不論伺服器還是客戶端，任意一方都可直接向對方傳送報文。

初次接觸 WebSocket 的人，都會問同樣的問題：我們已經有了 HTTP 協議，為什麼還需要另一個協議？

2.HTTP的侷限性HTTP是半雙工協議，也就是說，在同一時刻資料只能單向流動，客戶端向伺服器傳送請求(單向的)，然後伺服器響應請求(單向的)。伺服器不能主動推送資料給瀏覽器。這就會導致一些高階功能難以實現，諸如聊天室場景就沒法實現。3.WebSocket的特點支援雙向通訊，實時性更強可以傳送文字，也可以傳送二進位制資料減少通訊量：只要建立起WebSocket連線，就希望一直保持連線狀態。和HTTP相比，不但每次連線時的總開銷減少，而且由於WebSocket的首部資訊很小，通訊量也相應減少了

相對於傳統的HTTP每次請求-應答都需要客戶端與服務端建立連線的模式，WebSocket是類似Socket的TCP長連線的通訊模式，一旦WebSocket連線建立後，後續資料都以幀序列的形式傳輸。在客戶端斷開WebSocket連線或Server端斷掉連線前，不需要客戶端和服務端重新發起連線請求。在海量併發和客戶端與伺服器互動負載流量大的情況下，極大的節省了網路頻寬資源的消耗，有明顯的效能優勢，且客戶端傳送和接受訊息是在同一個持久連線上發起，實時性優勢明顯。

接下來我看下websocket如何實現客戶端與服務端雙向通訊：

啟動本地服務，開啟,得到如下結果：

三、Web 實時推送技術的比較

綜上所述：Websocket協議不僅解決了HTTP協議中服務端的被動性，即通訊只能由客戶端發起，也解決了資料同步有延遲的問題，同時還帶來了明顯的效能優勢，所以websocket 是Web 實時推送技術的比較理想的方案，但如果要相容低版本瀏覽器，可以考慮用輪詢來實現。

首先，我覺得這是一個非常好的問題，也是很多小白使用者困惑之處，下面我將根據自己的經驗認真回答這個問題。

當前，資訊科技正在蓬勃發展，實時網站聊天應用程式（例如股票價格控制系統）和其他Web應用程式具有新的實時需求。解決與傳統實時Web應用程式相關的問題已成為實時Web應用程式的關鍵問題之一。隨著HTML5技術的引入，WebSocket協議允許瀏覽器以完全雙重通訊模式與伺服器一起工作，從而可以更好地節省伺服器資源和頻寬並提供實時通訊。Web實時推送方案總體架構圖如下：

微服務架構是一種用於在雲中部署應用程式和服務的新技術，它可以透過將應用程式和服務轉換為較小的元件來有效地加速應用程式的開發和維護，從而促進其現代化和擴充套件。我的回答旨在使用WebSocket技術提供基本的實時Web通訊服務，在此基礎上，結合微服務的模組化結構的思想，提出了一套擴充套件實時Web廣播的通用解決方案。

實現伺服器推送技術的方式

1、Ajax聽證程式

基於Ajax的查詢系統本質上是一種在伺服器上接收資料的方式，該方法透過Ajax向伺服器傳送非同步請求，並提供與第一個呼叫有關的實時資料實時準同步。但是，此方法取決於活動的瀏覽器請求，並且無法預測訊息何時將出現在伺服器上，這通常滿足實時要求，從而增加了傳送訊息的頻率。它的缺點很明顯：較高的訪問頻率給伺服器增加了負擔，增加了大量無意義的網路流量，而較低的請求頻率並不能確保實時滿足要求，並且失去了訊息傳輸的重要性。儘管基於Ajax的調查方法很簡單，但是民意調查的頻率會產生巨大的影響，並且在時效性要求較高的情況下不太適合。

2、基於HTTTP的高階請求

如圖1所示，圖1顯示了一個長HTTP輪詢方案。與基於Ajax的請求不同，伺服器將在接收到客戶端請求後連線到伺服器，並且將返回直到有時間接收資料或連線為止。客戶端收到請求後再次訪問伺服器。

顯然，長時間的聽證程式無疑比簡短的聽證程式要好，它使您可以透過減少建立和關閉通訊的過程，減少網路通訊的成本並確保其實時平穩執行來避免不必要的請求。

3、WebSocket

Web套接字技術是在HTML5標準中定義的，其主要目的是解決瀏覽器和伺服器之間的實時通訊問題。WebSocket進行了基於TCP的雙向通訊，協議分兩個階段達成。在第一步中，客戶端將更新請求傳送到Web伺服器，以繼續進行第二步。在第二階段，雙方都可以在此良好通道上進行雙向資料傳輸。

WEB的實時推送有著其很廣的應用範疇，包括網頁即時聊天、工業行業監控、線上遊戲、線上動態資訊獲取等方面。可以說在WebSocket還沒有出來之前，網頁端的即時通訊主要靠定期輪訓服務端的方式來獲取最新的訊息，這個主要是因為HTTP的不持續連線造成的。

HTTP

HTTP協議是一個不持續的連線，也就是說通訊的請求只能是由客戶端發起，比如我們的網頁你點選一個連線，客戶端發出了申請，伺服器端才能給你按照連線所攜帶的資料查詢到結果返回給客戶端，伺服器不能夠向客戶端主動的推送資訊。

這種單向的請求會服特點就註定了伺服器和客戶端不是保持著永久連線。如果伺服器端的狀態發生改變，客戶端無法知道，只有單向請求才能夠知道。客戶端如果想要即使獲取資訊，只能透過輪詢、長輪詢和iframe流

但是這種方式有個最大的缺點就是伺服器的壓力是分大，不論伺服器狀態是否發生改變，客戶端都要不停的輪訓向伺服器端傳送請求，如果大批次的這樣搞的話，伺服器50%以上的資源都在處理這些應答，這無疑是一種非常糟糕的解決方案。

長輪詢機制的出現

後來為了降低這種過多的無用輪詢模式，出現了一種長輪詢方式，就是在客戶端傳送給請求頭報文給伺服器之後，看有沒有新的訊息，如果沒有訊息就一直等待，當有新的訊息才返回給客戶端。這種方式的確是在某種程度上緩解了對伺服器的訪問壓力。

但是這種長輪詢的請求頭報文過長數量比較大，會給網路的傳輸又帶來了不小的浪費。

iframe流方式

這種方式就是在頁面當中嵌入一個隱藏的iframe，利用SRC的屬性在伺服器和客戶端之間建立一條長連線，伺服器向iframe傳輸資料，這種方式的最大優點是瀏覽器相容好，大家都支援，包括比較老舊的IE瀏覽器。

但是同時缺點和長輪詢機制有著同樣的槽點就是常連線會增加開銷，瀏覽器狀態列總是有個轉圈的圖示，標識等待伺服器狀態當中。

websocket

直到HTML5的誕生，WebSocket的出現，並且市面上主流的瀏覽器都開始了支援WebSocket技術，它將TCP的套接字應用在了網頁頁面上，從而使通訊雙方建立起了一個保持狀態的連線通道。

一旦Web伺服器與客戶端之間建立起WebSocket協議的通訊連線，之後所有的通訊都依靠這個專用協議進行。

並且通訊之間可以支援JSON等各種資料格式的傳送。但是這個連線的發起端還是客戶端，但是一旦建立之後不論是伺服器端還是客戶端，任意一方都可以直接仿宋報文給對方。

WebSocket的特點

支援雙向通訊，實時性更強可以傳送文字，也可以傳送二進位制資料減少通訊量：只要建立起WebSocket連線，就希望一直保持連線狀態。和HTTP相比，不但每次連線時的總開銷減少，而且由於WebSocket的首部資訊很小，通訊量也相應減少了在海量併發和客戶端與伺服器互動負載流量大的情況下，極大的節省了網路頻寬資源的消耗，有明顯的效能優勢，且客戶端傳送和接受訊息是在同一個持久連線上發起，實時性優勢明顯。綜上各種技術，websocket 是Web 實時推送技術的比較理想的方案，但如果要相容低版本瀏覽器，可以考慮用輪詢來實現。

我知道的有兩種：

1， ajax定時重新整理。單方通訊。

2，websocket實時雙方通訊。

現在確實有不少這樣的場景，當後臺資料發生變化，需要主動“通知”前臺進行頁面重新整理，實現方案有這麼幾種：

輪詢

很容易理解，實現起來也非常簡單的一種方法：客戶端每隔一段時間向後臺傳送一次請求，把最新的資料取回來。

當然缺點也比較明顯，如果定時任務的時間設定比較長，那麼資料更新和展示會不及時；如果定時任務的時間設定的比較短，那麼頻繁地訪問後臺，也會增加後臺伺服器的壓力。

長輪詢

如果是輪詢的話，客戶端每次向後臺請求資料的時候，都會建立一次連線；而長輪詢，客戶端傳送請求給伺服器之後，如果有最新資料的話，就直接返回，如果沒有最新資料的話，就等待，當有新資料的時候再返回。

缺點也顯而易見，因為保持連線也是會消耗資源的，並且如果長時間沒有新資料的話，也會發生超時。

Iframe

這個方式的本質是基於Iframe的HTTP長連線實現；在HTML頁面裡嵌入一個隱蔵的Iframe，然後把src屬性設為一個長連線請求，伺服器就可以向Iframe傳輸資料了。

維護長連結就需要增加開銷，而且需要考慮連線中斷、重連等問題。

WebSocket

HTTP協議的不足，在於HTTP協議只能由客戶端發起請求，並且一個Request要對應一個Response（長連結也是如此）。

WebSocket，是要在客戶端和伺服器之間，建立一個通道，建立一個【真的長連結】；一旦確立WebSocket通訊連線，不論伺服器還是客戶端，任意一方都可直接向對方傳送資料，這個是真正意義的雙向通訊；並且資料格式可以是文字，也可以是二進位制資料。