通常情況下，無論是web瀏覽器還是移動app，我們與伺服器之間的互動都是主動的，客戶端向伺服器端發出請求，然後伺服器端返回資料給客戶端，客戶端瀏覽器再將資訊呈現，客戶端與服務端對應的模式是: 客戶端請求--服務端響應，這種機制對於資訊變化不是特別頻繁的應用尚可，但對於實時要求高、海量併發的應用來說顯得捉襟見肘，尤其在當前業界移動網際網路蓬勃發展的趨勢下，高併發與使用者實時響應是 Web 應用經常面臨的問題，比如金融證券的實時資訊，Web 導航應用中的地理位置獲取，社交網路的實時訊息推送，新聞的訂閱,天氣的提醒等。這些情況下，需要伺服器主動推送訊息給客戶端。

那麼在這樣的模式下,會有幾個問題需要我們思考下:

1.應用伺服器如何確定每一個應用所在的裝置

2.伺服器端是如何將訊息推送到客戶端的，客戶端又不像伺服器有一個固定的地址

帶著這些疑問我們來研究一下目前有哪些技術可以解決該問題：

一、Ajax輪詢

所謂的Ajax輪詢，其實就是定時的通過Ajax查詢服務端，客戶端按規定時間定時像服務端傳送ajax請求，伺服器接到請求後馬上返回響應資訊並關閉連線。

這種技術方式實現起來非常簡單，但是這種方式會有非常嚴重的問題，就是需要不斷的向伺服器傳送訊息詢問，這種方式會對伺服器造成極大的效能浪費。

還有一個類似的輪詢是使用JSONP跨域請求的方式輪詢，在實現起來有差別，但基本原理都是相同的，都是客戶端不斷的向伺服器發起請求。

優點

實現簡單。

缺點

這是通過模擬伺服器發起的通訊，不是實時通訊，不顧及應用的狀態改變而盲目檢查更新，導致伺服器資源的浪費，且會加重網路負載，拖累伺服器。

二、Comet

Comet，基於 HTTP 長連線的 "伺服器推" 技術，能使伺服器端主動以非同步的方式向客戶端程式推送資料，而不需要客戶端顯式的發出請求，目前有兩種實現方式：

1. 基於 AJAX 的長輪詢（long-polling）方式

Ajax 的出現使得 JavaScript 可以呼叫 XMLHttpRequest 物件發出 HTTP 請求，JavaScript 響應處理函式根據伺服器返回的資訊對 HTML 頁面的顯示進行更新。使用 AJAX 實現 "伺服器推" 與傳統的 AJAX 應用不同之處在於：

1. 伺服器端會阻塞請求直到有資料傳遞或超時才返回。
2. 客戶端 JavaScript 響應處理函式會在處理完伺服器返回的資訊後，再次發出請求，重新建立連線。
3. 當客戶端處理接收的資料、重新建立連線時，伺服器端可能有新的資料到達；這些資訊會被伺服器端儲存直到客戶端重新建立連線，客戶端會一次把當前伺服器端所有的資訊取回。

基於長輪詢的伺服器推模型

相對於"輪詢"（poll），這種長輪詢方式也可以稱為"拉"（pull）。因為這種方案基於 AJAX，具有以下一些優點：請求非同步發出；無須安裝外掛；IE、Mozilla FireFox 都支援 AJAX。

長輪詢 (long polling) 是在開啟一條連線以後保持並等待伺服器推送來資料再關閉，可以採用HTTP長輪詢和XHR長輪詢兩種方式:

(1). HTTP 和JSONP方式的長輪詢

把 script 標籤附加到頁面上以讓指令碼執行。伺服器會掛起連線直到有事件發生，接著把指令碼內容傳送回瀏覽器，然後重新開啟另一個 script 標籤來獲取下一個事件，從而實現長輪詢的模型。

(2).XHR長輪詢

這種方式是使用比較多的長輪詢模式。

客戶端開啟一個到伺服器端的 AJAX 請求然後等待響應；伺服器端需要一些特定的功能來允許請求被掛起，只要一有事件發生，伺服器端就會在掛起的請求中送回響應並關閉該請求。客戶端 JavaScript 響應處理函式會在處理完伺服器返回的資訊後，再次發出請求，重新建立連線；如此迴圈。

現在瀏覽器已經支援CROS的跨域方式請求，因此HTTP和JSONP的長輪詢方式是慢慢被淘汰的一種技術，建議採用XHR長輪詢。

優點

客戶端很容易實現良好的錯誤處理系統和超時管理，實現成本與Ajax輪詢的方式類似。

缺點

需要伺服器端有特殊的功能來臨時掛起連線。當客戶端發起的連線較多時，伺服器端會長期保持多個連線，具有一定的風險。

1. >>在這裡簡單的說明下長輪詢，長連線的概念
2. 輪詢：客戶端定時向伺服器傳送Ajax請求，伺服器接到請求後馬上返回響應資訊並關閉連線。優點：後端程式編寫比較容易。
3. 缺點：請求中有大半是無用，浪費頻寬和伺服器資源。
4. 例項：適於小型應用。
5. 長輪詢：客戶端向伺服器傳送Ajax請求，伺服器接到請求後hold住連線，直到有新訊息才返回響應資訊並關閉連線，客戶端處理完響應資訊後再向伺服器傳送新的請求。
6. 優點：在無訊息的情況下不會頻繁的請求。
7. 缺點：伺服器hold連線會消耗資源。
8. 例項：WebQQ、Hi網頁版、Facebook IM。
9. 另外，對於長連線和socket連線也有區分：
10. 長連線：在頁面裡嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設為對一個長連線的請求，伺服器端就能源源不斷地往客戶端輸入資料。
11. 優點：訊息即時到達，不發無用請求。
12. 缺點：伺服器維護一個長連線會增加開銷。
13. 例項：Gmail聊天
14. FlashSocket：在頁面中內嵌入一個使用了Socket類的Flash程式JavaScript通過呼叫此Flash程式提供的Socket介面與伺服器端的Socket介面進行通訊，JavaScript在收到伺服器端傳送的資訊後控制頁面的顯示。
15. 優點：實現真正的即時通訊，而不是偽即時。
16. 缺點：客戶端必須安裝Flash外掛；非HTTP協議，無法自動穿越防火牆。
17. 例項：網路互動遊戲。

2. 基於 Iframe 及 htmlfile 的流（streaming）方式

iframe 是很早就存在的一種 HTML 標記， 通過在 HTML 頁面裡嵌入一個隱蔵幀，然後將這個隱蔵幀的 SRC 屬性設為對一個長連線的請求，伺服器端就能源源不斷地往客戶端輸入資料。

基於流方式的伺服器推模型

Comet的優缺點

Comet實現要點

不要在同一客戶端同時使用超過兩個的 HTTP 長連線

我們使用 IE 下載檔案時會有這樣的體驗，從同一個 Web 伺服器下載檔案，最多隻能有兩個檔案同時被下載。第三個檔案的下載會被阻塞，直到前面下載的檔案下載完畢。這是因為 HTTP 1.1 規範中規定，客戶端不應該與伺服器端建立超過兩個的 HTTP 連線， 新的連線會被阻塞。而 IE 在實現中嚴格遵守了這種規定。

HTTP 1.1 對兩個長連線的限制，會對使用了長連線的 Web 應用帶來如下現象：在客戶端如果開啟超過兩個的 IE 視窗去訪問同一個使用了長連線的 Web 伺服器，第三個 IE 視窗的 HTTP 請求被前兩個視窗的長連線阻塞。

所以在開發長連線的應用時， 必須注意在使用了多個 frame 的頁面中，不要為每個 frame 的頁面都建立一個 HTTP 長連線，這樣會阻塞其它的 HTTP 請求，在設計上考慮讓多個 frame 的更新共用一個長連線。

伺服器端的效能和可擴充套件性

一般 Web 伺服器會為每個連線建立一個執行緒，如果在大型的商業應用中使用 Comet，伺服器端需要維護大量併發的長連線。在這種應用背景下，伺服器端需要考慮負載均衡和叢集技術；或是在伺服器端為長連線作一些改進。

應用和技術的發展總是帶來新的需求，從而推動新技術的發展。HTTP 1.1 與 1.0 規範有一個很大的不同：1.0 規範下伺服器在處理完每個 Get/Post 請求後會關閉套介面連線； 而 1.1 規範下伺服器會保持這個連線，在處理兩個請求的間隔時間裡，這個連線處於空閒狀態。 Java 1.4 引入了支援非同步 IO 的 java.nio 包。當連線處於空閒時，為這個連線分配的執行緒資源會返還到執行緒池，可以供新的連線使用；當原來處於空閒的連線的客戶發出新的請求，會從執行緒池裡分配一個執行緒資源處理這個請求。 這種技術在連線處於空閒的機率較高、併發連線數目很多的場景下對於降低伺服器的資源負載非常有效。

但是 AJAX 的應用使請求的出現變得頻繁，而 Comet 則會長時間佔用一個連線，上述的伺服器模型在新的應用背景下會變得非常低效，執行緒池裡有限的執行緒數甚至可能會阻塞新的連線。Jetty 6 Web 伺服器針對 AJAX、Comet 應用的特點進行了很多創新的改進。

控制資訊與資料資訊使用不同的 HTTP 連線

使用長連線時，存在一個很常見的場景：客戶端網頁需要關閉，而伺服器端還處在讀取資料的堵塞狀態，客戶端需要及時通知伺服器端關閉資料連線。伺服器在收到關閉請求後首先要從讀取資料的阻塞狀態喚醒，然後釋放為這個客戶端分配的資源，再關閉連線。

所以在設計上，我們需要使客戶端的控制請求和資料請求使用不同的 HTTP 連線，才能使控制請求不會被阻塞。

在實現上，如果是基於 iframe 流方式的長連線，客戶端頁面需要使用兩個 iframe，一個是控制幀，用於往伺服器端傳送控制請求，控制請求能很快收到響應，不會被堵塞；一個是顯示幀，用於往伺服器端傳送長連線請求。如果是基於 AJAX 的長輪詢方式，客戶端可以非同步地發出一個 XMLHttpRequest 請求，通知伺服器端關閉資料連線。

在客戶和伺服器之間保持“心跳”資訊

在瀏覽器與伺服器之間維持一個長連線會為通訊帶來一些不確定性：因為資料傳輸是隨機的，客戶端不知道何時伺服器才有資料傳送。伺服器端需要確保當客戶端不再工作時，釋放為這個客戶端分配的資源，防止記憶體洩漏。因此需要一種機制使雙方知道大家都在正常執行。在實現上：

1. 伺服器端在阻塞讀時會設定一個時限，超時後阻塞讀呼叫會返回，同時發給客戶端沒有新資料到達的心跳資訊。此時如果客戶端已經關閉，伺服器往通道寫資料會出現異常，伺服器端就會及時釋放為這個客戶端分配的資源。
2. 如果客戶端使用的是基於 AJAX 的長輪詢方式；伺服器端返回資料、關閉連線後，經過某個時限沒有收到客戶端的再次請求，會認為客戶端不能正常工作，會釋放為這個客戶端分配、維護的資源。
3. 當伺服器處理資訊出現異常情況，需要傳送錯誤資訊通知客戶端，同時釋放資源、關閉連線。

三，websocket方式

 WebSocket是HTML5開始提供的一種在單個 TCP 連線上進行全雙工通訊的協議。WebSocket通訊協議於2011年被IETF定為標準RFC 6455，WebSocketAPI被W3C定為標準。在WebSocket API中，瀏覽器和伺服器只需要做一個握手的動作，然後，瀏覽器和伺服器之間就形成了一條快速通道。兩者之間就直接可以資料互相傳送。

 由於websocket技術要說明白的話所需要的篇幅不小，所以會在之後的單獨文章中介紹下websocket的使用方式，這裡就不做詳細的說明了。

總結

根據以上技術的優缺點和具體業務需要，可以選擇合適的技術進行應用。