NO IMAGE

通常情況下,無論是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.  
  6. 長輪詢:客戶端向伺服器傳送Ajax請求,伺服器接到請求後hold住連線,直到有新訊息才返回響應資訊並關閉連線,客戶端處理完響應資訊後再向伺服器傳送新的請求。
  7. 優點:在無訊息的情況下不會頻繁的請求。
  8. 缺點:伺服器hold連線會消耗資源。
  9. 例項:WebQQ、Hi網頁版、Facebook IM。
  10.  
  11. 另外,對於長連線和socket連線也有區分:
  12.  
  13. 長連線:在頁面裡嵌入一個隱蔵iframe,將這個隱蔵iframe的src屬性設為對一個長連線的請求,伺服器端就能源源不斷地往客戶端輸入資料。
  14. 優點:訊息即時到達,不發無用請求。
  15. 缺點:伺服器維護一個長連線會增加開銷。
  16. 例項:Gmail聊天
  17.  
  18. Flash Socket:在頁面中內嵌入一個使用了Socket類的 Flash 程式JavaScript通過呼叫此Flash程式提供的Socket介面與伺服器端的Socket介面進行通訊,JavaScript在收到伺服器端傳送的資訊後控制頁面的顯示。
  19. 優點:實現真正的即時通訊,而不是偽即時。
  20. 缺點:客戶端必須安裝Flash外掛;非HTTP協議,無法自動穿越防火牆。
  21. 例項:網路互動遊戲。

2. 基於 Iframe 及 htmlfile 的流(streaming)方式

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

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

 

 

Comet的優缺點

優點: 實時性好(訊息延時小);效能好(能支援大量使用者)
缺點: 長期佔用連線,喪失了無狀態高併發的特點。

Comet實現框架

1. Dojo CometD —— http://cometdproject.dojotoolkit.org/

2. DWR —— http://directwebremoting.org/dwr/index.html

3. ICEfaces —— http://www.icefaces.org/main/home/

4. GlassFish Grizzly —— https://grizzly.dev.java.net/

CometD 目前實現 Comet 比較成熟, DWR 弱一些。 ICEfaces 更商業化,實現得很成熟。 Grizzly 是基於GlassFish ,也很成熟。CometD, DWR 開源性好。

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的使用方式,這裡就不做詳細的說明了。

總結

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