服務器有新消息主動推送給客戶端瀏覽器

前言

一般狀況下，不管是web瀏覽器仍是移動app，咱們與服務器之間的交互都是主動的，客戶端向服務器端發出請求，而後服務器端返回數據給客戶端，客戶端瀏覽器再將信息呈現，客戶端與服務端對應的模式是: 客戶端請求--服務端響應，這種機制對於信息變化不是特別頻繁的應用尚可，但對於實時要求高、海量併發的應用來講顯得捉襟見肘，尤爲在當前業界移動互聯網蓬勃發展的趨勢下，高併發與用戶實時響應是 Web 應用常常面臨的問題，好比金融證券的實時信息，Web 導航應用中的地理位置獲取，社交網絡的實時消息推送，新聞的訂閱,天氣的提醒等。這些狀況下，須要服務器主動推送消息給客戶端。

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

1.應用服務器如何肯定每個應用所在的設備

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

帶着這些疑問咱們來研究一下目前有哪些技術能夠解決該問題：

1、Ajax輪詢

所謂的Ajax輪詢，其實就是定時的經過Ajax查詢服務端，客戶端按規定時間定時像服務端發送ajax請求，服務器接到請求後立刻返回響應信息並關閉鏈接。

這種技術方式實現起來很是簡單，可是這種方式會有很是嚴重的問題，就是須要不斷的向服務器發送消息詢問，這種方式會對服務器形成極大的性能浪費。

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

優勢

實現簡單。

缺點

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

2、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輪詢的方式相似。

缺點

須要服務器端有特殊的功能來臨時掛起鏈接。當客戶端發起的鏈接較多時，服務器端會長期保持多個鏈接，具備必定的風險。

>>在這裏簡單的說明下長輪詢，長鏈接的概念

輪詢：客戶端定時向服務器發送Ajax請求，服務器接到請求後立刻返回響應信息並關閉鏈接。優勢：後端程序編寫比較容易。
缺點：請求中有大半是無用，浪費帶寬和服務器資源。
實例：適於小型應用。

長輪詢：客戶端向服務器發送Ajax請求，服務器接到請求後hold住鏈接，直到有新消息才返回響應信息並關閉鏈接，客戶端處理完響應信息後再向服務器發送新的請求。
優勢：在無消息的狀況下不會頻繁的請求。
缺點：服務器hold鏈接會消耗資源。
實例：WebQQ、Hi網頁版、Facebook IM。

另外，對於長鏈接和socket鏈接也有區分：

長鏈接：在頁面裏嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設爲對一個長鏈接的請求，服務器端就能源源不斷地往客戶端輸入數據。
優勢：消息即時到達，不發無用請求。
缺點：服務器維護一個長鏈接會增長開銷。
實例：Gmail聊天

Flash Socket：在頁面中內嵌入一個使用了Socket類的 Flash 程序JavaScript經過調用此Flash程序提供的Socket接口與服務器端的Socket接口進行通訊，JavaScript在收到服務器端傳送的信息後控制頁面的顯示。
優勢：實現真正的即時通訊，而不是僞即時。
缺點：客戶端必須安裝Flash插件；非HTTP協議，沒法自動穿越防火牆。
實例：網絡互動遊戲。

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的使用方式，這裏就不作詳細的說明了。

總結

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

 

♥ 做者：明志健致遠 
♠ 出處：http://www.cnblogs.com/study-everyday/ ♦ 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。 ♣ 本博客大多爲學習筆記或讀書筆記，本文如對您有幫助，還請多推薦下此文，若有錯誤歡迎指正，相互學習，共同進步。