傳統web請求,是顯式的向服務器發送http Request,拿到Response後顯示在瀏覽器頁面上。這種被動的交互方式不能知足對信息實時性要求高的應用,譬如聊天室、股票交易行情、在線遊戲等。Ajax輪詢雖然能夠解決這個問題,可是會帶來增長服務器負擔、帶寬浪費,而且這種實現方式不夠優雅。而Comet技術就是爲此而生的。javascript
本文只探討基於瀏覽器的web端服務器推技術。服務器推技術在現實應用中有一些解決方案,主要分兩類:一類是須要瀏覽器額外安裝插件,基於套接口傳送信息或者是基於RMI、CORBA進行遠程調用,另外一類則無需瀏覽器安裝任何插件,就是本文着重講的HTTP長鏈接技術:Coment。Alex Russell(Dojo Toolkit 的項目 Lead)稱這種基於 HTTP 長鏈接、無須在瀏覽器端安裝插件的「服務器推」技術爲「Comet」。html
2、Comet實現模型java
1.HTTP Long Polling:基於 AJAX 的長輪詢方式
衆所周知,AJAX能夠異步調用XMLHttpRequest對象發送HttpRequest,Javascript響應處理函數根據服務端返回的信息對HTML頁面顯示進行更新。而使用AJAX實現服務器推與傳統AJAX應用的不一樣之處在於:jquery
a.服務器端會阻塞請求直到有數據返回或者超時;git
b.客戶端JS響應函數在處理完服務端返回的信息後會再次發出請求,從新創建鏈接;github
如圖1所示,由於這種方案基於 AJAX,具備如下一些優勢:請求異步發出;無須安裝插件;IE、Mozilla FireFox 都支持 AJAX。
web
圖1:基於 AJAX 的長輪詢方式
ajax
2.HTTP Streaming:基於 Iframe 及 htmlfile 的流方式
經過在 HTML 頁面裏嵌入一個隱蔵幀,而後將這個隱蔵幀的 SRC 屬性設爲對一個長鏈接的請求,服務器端就能源源不斷地往客戶端輸入數據。如圖2所示。
圖2. 基於流方式的服務器推模型
瀏覽器
兩種方案對比:服務器
a.在對返回的數據處理方面:方案2(IFrame)返回的是對客戶端javascript調用,,如「<script type="text/javascript">js_func(「data from server 」)</script>
」。服務器端將返回的數據做爲客戶端 JavaScript 函數的參數傳遞;客戶端瀏覽器的 Javascript 引擎在收到服務器返回的 JavaScript 調用時就會去執行代碼。而方案1(AJAX)返回的是數據,經過JS能夠很方便的操做DOM。
b.使用IFrame還有一個明顯不足:IE、Morzilla Firefox 下端的進度欄都會顯示加載沒有完成,並且 IE 上方的圖標會不停的轉動,表示加載正在進行。不過這個問題已經被Google技術人員解決,並應用到Gtalk中,解決方案是:ActiveX 控件解決 iframe 請求長鏈接時 IE 的加載顯示問題,原文地址:「What else is burried down in the depth’s of Google’s amazing JavaScript?」。
3、實際開發時應該注意的問題
對於一個實際的應用而言,系統的穩定性和性能是很是重要的。將 HTTP 長鏈接用於實際應用,不少細節須要考慮。
這個是因爲HTTP 1.1 規範中規定:客戶端不該該與服務器端創建超過兩個的 HTTP 鏈接,新的鏈接會被阻塞。因此,在設計上考慮讓多個 frame(AJAX)共用一個長鏈接。
2.服務器端的性能和可擴展性
通常的WEB服務器是爲每一個鏈接建立一個線程,因此在使用Comet時,服務器要維護大量併發,長期存在的長鏈接。在這種背景下,就須要服務器負載均衡和集羣技術,或者在服務端作一些優化。這篇文章:http://rdc.taobao.com/blog/cs/?p=1062的測試代表:200萬個Http長鏈接佔用率19G服務器內存,一個大約9kb;因此,你能夠算一下你的服務器最多能夠維護多少個長鏈接。
用長鏈接時,存在一個很常見的場景:客戶端網頁須要關閉,而服務器端還處在讀取數據的堵塞狀態,客戶端須要及時通知服務器端關閉數據鏈接。服務器在收到關閉請求後首先要從讀取數據的阻塞狀態喚醒,而後釋放爲這個客戶端分配的資源,再關閉鏈接。
因此在設計上,咱們須要使客戶端的控制請求和數據請求使用不一樣的 HTTP 鏈接,才能使控制請求不會被阻塞。
在實現上,若是是基於 iframe 流方式的長鏈接,客戶端頁面須要使用兩個 iframe,一個是控制幀,用於往服務器端發送控制請求,控制請求能很快收到響應,不會被堵塞;一個是顯示幀,用於往服務器端發送長鏈接請求。若是是基於 AJAX 的長輪詢方式,客戶端能夠異步地發出一個 XMLHttpRequest 請求,通知服務器端關閉數據鏈接。
客戶端不知道什麼時候服務器纔有數據傳送。服務器端須要確保當客戶端不在狀態(工做)時,釋放爲這個客戶端分配的資源,防止內存泄漏。所以須要一種機制使雙方知道你們都在正常運行。
4、Comet框架介紹
因爲Comet早在2006.2月就提出來了,因此並非什麼新鮮玩意,框架仍是不少的,譬如:Dojox.cometd, Pushlet,SingalR。
Dojox.cometd:Comet概念的的提出者Alex Russel主導的Dojo項目分支,Dojo 基金會提出了 Bayeux 協議用來標準化 Comet 應用中客戶端和服務器端之間的通訊。Dojox.cometd 實現了 Bayeux 協議的客戶端部分,使用 HTTP 長輪詢來做爲數據的傳輸通道。
Pushlet:基於HTTP流,而不是AJAX長輪詢。一個開源的 Comet 框架,Pushlet 使用了觀察者模型:客戶端發送請求,訂閱感興趣的事件;服務器端爲每一個客戶端分配一個會話 ID 做爲標記,事件源會把新產生的事件以多播的方式發送到訂閱者的事件隊列裏。貌似只支持Java。
SingalR:基於AJAX長輪詢。ASP.NET團隊開發的一個開源的.net framework庫和Jquery插件。集成的客戶端與服務器庫,基於瀏覽器的客戶端和基於 ASP.NET 的服務器組件能夠藉助它來進行雙向多步對話。
5、SingalR的MVC4實踐
1.安裝與運行環境:(Nuget) install-package Microsoft.AspNet.SignalR ,注意:PM>後面不要有空格。
或者到GitHub上下載源碼:https://github.com/SignalR/SignalR
這裏順便提一下,SingalR服務端須要支持的OS:
.net framework4,4.5。WebSocket必須是4.5.
IIS7,7.5 ,integrated Mode,而不是classic Mode, WebSockets必須IIS8。更加詳盡的說明,請自行參考:http://www.asp.net/signalr/overview/getting-started/supported-platforms
2.核心實現:
首先,咱們須要引用SignalR,用Nuget不須要本身手工添加,應爲你的asp.net mvc項目自動添加好一切。
服務端Library:
Microsoft.AspNet.SignalR.Core
Microsoft.AspNet.SignalR.Owin
Microsoft.AspNet.SignalR.SystemWeb
Owin
Newtonsoft.Json
using
System;
using
System.Collections.Generic;
using
System.Linq;
using
System.Web;
using
Microsoft.AspNet.SignalR;
namespace
DeepleoComet
{
public
class
ChatHub : Hub
{
public
void
Send(
string
name,
string
message)
{
// Call the addNewMessageToPage method to update clients.
Clients.All.addNewMessageToPage(name, message);
}
}
}
|
客戶端的Jquery插件:
jquery.signalR-1.1.3.min.js.
@{ ViewBag.Title = "Chat"; } <h2>Chat</h2> <div class="container"> <input type="text" id="message" /> <input type="button" id="sendmessage" value="Send" /> <input type="hidden" id="displayname" /> <ul id="discussion"> </ul> </div> @section scripts { <script src="~/Scripts/jquery.signalR-1.1.3.js"></script> <script src="~/signalr/hubs"></script> <script> $(function () { var chat = $.connection.chatHub; chat.client.addNewMessageToPage = function (name, message) { $('#discussion').append('<li><strong>' + htmlEncode(name) + '</strong>: ' + htmlEncode(message) + '</li>'); }; $('#displayname').val(prompt('Enter your name:', '')); $('#message').focus(); $.connection.hub.start().done(function () { $('#sendmessage').click(function () { chat.server.send($('#displayname').val(), $('#message').val()); $('#message').val('').focus(); }); }); }); function htmlEncode(value) { var encodedValue = $('<div />').text(value).html(); return encodedValue; } </script> }
實現效果:
開兩個頁面:http://localhost:11968/ ,分別鍵入name,就能夠實現一個簡單的聊天室功能了。
6、題外話:Comet的替代品:Html5的WebSocket
在瀏覽器中經過http僅能實現單向的通訊,comet能夠必定程度上模擬雙向通訊,但效率較低,並須要服務器有較好的支持; flash中的socket和xmlsocket能夠實現真正的雙向通訊,經過 flex ajax bridge,能夠在javascript中使用這兩項功能. 能夠預見,若是websocket一旦在瀏覽器中獲得實現,將會替代上面兩項技術,獲得普遍的使用.面對這種情況,HTML5定義了WebSocket協議,能更好的節省服務器資源和帶寬並達到實時通信。
真是相見恨晚啊,才知道還有這麼個東西,竟然Web端也有了全雙工的Socket,貌似有個socket.io還支持IE6,我和個人小夥伴們都驚呆了。
比較好的關於WebSocket文章:http://www.cnblogs.com/wei2yi/archive/2011/03/23/1992830.html
參考資料
1.原理:http://www.ibm.com/developerworks/cn/web/wa-lo-comet/
2.DOJO原理與實踐:http://www.ibm.com/developerworks/cn/web/wa-lo-w2fpak-comet/
3.淘寶200W長連接測試與優化:http://rdc.taobao.com/blog/cs/?p=1062
4.長鏈接百科:http://baike.baidu.com/view/2831907.htm
5.博客園Comet專題:http://kb.cnblogs.com/page/112185/
6. Jetty+Dojo+Tomcat:http://blog.csdn.net/garfier/article/details/5942826
7.SingalR官網:http://signalr.net/
8.Singal輔導:http://www.asp.net/signalr