第一章ASP.NET SignalR簡介

第一章ASP.NET SignalR簡介

1.1概述：

    ASP.NET SignalR是微軟新開發的類庫，爲的是幫助ASP.NET開發人員很方便地開發實時網絡功能。 SignalR容許服務器端和客戶端之間進行雙向通訊。服務器端如今能夠鏈接到客戶端而且把內容瞬間推送出去，而不是一個客戶端不斷請求服務器端從而才能獲取新數據（不是經過輪詢去拉服務器端數據，而是服務器端主動推送數據到客戶端）。SignalR支持Web Sockets套接字，而且當使用舊版瀏覽器的時候會自動使用相關兼容的技術。SignalR包括它的API接口，用於鏈接管理的解耦（例如，鏈接和斷開鏈接的事件），羣組鏈接接口和受權接口等。

         SignalR能夠爲您的ASP.NET應用程序添加各類「實時」的Web功能。最經常使用的例子有聊天室，但當你使用SignalR後，咱們能夠比這作得更好更多。過去，用戶須要經過不斷刷新網頁才能看到新的數據；或者在頁面上經過實現長輪詢來檢索新數據（並顯示），這些功能都會在在使用SignalR後變得更容易實現和使用。好比：儀表板及監視型應用程序、協做性應用程序（如多人同時對文檔進行編輯）、做業進度更新及時呈現表單等。

    SignalR也支持如今新類型的，須要從服務器上進行高頻率的更新的Web應用程序，例如，實時遊戲。對於這方面的一個很好的例子，請參見ShootR game.。

    SignalR提供了一個簡單的API，用於建立服務器到客戶端的遠程過程調用（RPC） ，從服務器端的.net代碼調用客戶端的瀏覽器（和其餘客戶端平臺）的 JavaScript函數。SignalR還包括用於鏈接管理API （例如，鏈接和斷開鏈接誒事件） ，羣組鏈接和受權等。（簡單來講，提供了服務器端API調用和客戶端的JS事件）

                               

    SignalR能夠自動對鏈接進行管理，並讓您同時發送廣播消息到全部鏈接的客戶端，就像一個聊天室聊天同樣。固然，您也能夠選擇向特定的用戶（客戶端）發送消息。客戶端和服務器之間的鏈接是持久的，也就是一般咱們所說的長鏈接，而不像一個典型的HTTP鏈接，每次通訊都要從新創建鏈接。
    SignalR支持「服務器推送」功能，即服務器代碼能夠經過使用遠程過程調用（RPC）來調用瀏覽器中的客戶端代碼，而不是在Web網站上常見的【請求-響應模型】的形式去獲取數據。
    SignalR的應用經過使用服務總線（Service Bus）、SQL Server或Redis來擴展到數以萬計的客戶端上。
    SignalR是開源的，經過GitHub.的訪問來查看源碼。

    SignalR在支持HTML5的瀏覽器下，一般是使用WebSocket，來實現服務端跟客戶端的通訊。若是瀏覽器不支持WebSocket 那麼他會自動切換支持該瀏覽器的其餘的技術來實現（如Http長鏈接）。無論用哪一種技術，最後都會實現一樣的結果。固然，你也能夠直接使用WebStocket來編寫你的應用程序，但使用SignalR意味着你將有更多的額外功能而無需本身從新發明輪子（人家都寫好接口了，拿來使用不是更好，何須本身重複建輪子）。最重要的是，你能夠把時間和注意力放在業務實現上，而無需考慮爲舊的客戶端（IE9如下等）寫兼容性代碼。SignalR還可以使你沒必要擔憂WebStocket的更新，由於SignalR將會繼續更新以及支持變化的底層傳輸方式，跨不一樣版本的WebStocket來爲應用程序提供一個一致的訪問接口。

    固然，你能夠建立只使用WebStocket傳輸的解決方案，SignalR提供了你可能須要自行編寫代碼的全部功能，好比回退到其餘傳輸方式以及針對更新的WebStocket來實現修改您的應用程序。

 

2.1傳輸和協商轉換（FallBacks）：
         SignalR是對客戶端及服務器之間實時功能實現所須要的傳輸技術的抽象。SignalR首先使用HTTP的方式開始鏈接，而且檢查WebSocket鏈接是否可用，若是可用，則會自動轉爲Webstocket鏈接。WebSocket是SignalR最理想的傳輸方式，由於它能夠最有效地利用服務器內存，具備最低的延遲，並擁有最底層的功能（如客戶端和服務器之間的全雙工通訊【雙向通訊】），但它也有最嚴格的要求：WebSocket的要求服務器必須使用Windows Server2012或Windows8，和NET框架4.5。若是不符合這些要求，SignalR將嘗試使用其餘傳輸方式進行鏈接。

 

2.1.1 HTML5的傳輸方式：（推薦使用谷歌瀏覽器做爲主瀏覽器）
         使用SignalR的任何傳輸方式都是取決於客戶端瀏覽器是否支持HTML 5，若是客戶端的瀏覽器不支持HTML5，將使用舊的傳輸方式。
         1）WebSocket（若是服務器和瀏覽器都支持WebSocket的）：WebSocket惟一一種在客戶端和服務器端創建真實持久的雙向鏈接的傳輸方式。然而，WebSocket的也有最嚴格的要求，它僅在最新版本的MicrosoftInternet Explorer、谷歌Chrome和MozillaFirefox瀏覽器中支持，其餘瀏覽器如Opera和Safari中都只有部分部分實現（2014最新版本的Opera和Safari就不清楚了，估計會都支持，這是將來發展的方向）。
  2）服務器發送事件：也被稱爲EventSource（若是瀏覽器支持服務器發送的事件，這基本上是除了IE外的瀏覽器都支持該功能。）

 

2.1.2Comet的傳輸方式：
    下面的傳輸類型都是基於CometWeb應用程序模型的，瀏覽器或客戶端將保持HTTP的長鏈接請求，服務器能夠在客戶端沒有明確請求的狀況下，將數據推送到客戶端。
  1）Forever Frame（僅適用於IE瀏覽器） ：Forever Frame會建立一個隱藏的IFrame ，而後向服務器發送一個不會完成的請求。而後服務器不斷地發送腳本到客戶端，而且由客戶端當即執行該腳本，即創建一個從服務器到客戶端的單向實時鏈接。而從客戶端到服務器的鏈接則使用不一樣於該鏈接的其餘鏈接。像一個標準的HTML請求時同樣，會爲每次數據的發送都會建立一個新的鏈接。
  2）Ajax長輪詢：長輪詢不會建立一個持久的鏈接，而是經過客戶端不斷髮出對服務器端的請求來進行輪詢。在每次鏈接時，都會等待服務器發出響應後關閉此次鏈接，而後再當即發出新的請求（本身也能夠定義間隔時間後，再發送新的請求）。固然，這種方式會在鏈接關閉再從新鏈接之間，形成必定的延遲。

   

關於各類配置所支持的傳輸方式，請參見支持的平臺（SupportedPlatforms）.的詳細信息。

 

2.1.3.傳輸方式選擇的過程：
如下列表顯示SignalR如何決定使用那種類型的傳輸方式進行傳輸：
1.若是瀏覽器是Internet Explorer 8或更早的版本，則使用長輪詢。
2.若是配置了JSONP（即鏈接時，JSONP參數設置爲true） ，則使用長輪詢。
3.若是正在使用跨域鏈接（即SignalR端點和頁面不在同一個域中） ，如能知足如下所有條件，則使用WebSocket：

    1)該客戶端支持CORS （跨域資源共享） 。具體詳細信息請參閱CORSat caniuse.com。
    2)該客戶端支持的WebSocket
    3)該服務器支持的WebSocket
若是以上三個條件，只要有一條不知足，則使用長輪詢。有關跨域鏈接的詳細信息，請參閱如何創建跨域鏈接。
4.若是沒有配置使用JSONP和鏈接不跨域，則使用WebSocket，固然，前提是客戶端和服務器端都支持WebStocket

5.若是客戶端或服務器不支持WebSocket的，則使用服務器發送事件（EventSource）。
7.若是服務器發送事件不可用，則嘗試使用ForeverFrame。
8.若是Forever Frame不可用，則使用長輪詢。

（即默認使用的優先級：1.WebStocket；2.EventSource；3.Forever Frame； 4.長輪詢）

2.1.4監控傳輸：  

         您能夠經過啓用Hub日誌記錄，並在瀏覽器的控制檯中查看您的應用程序使用哪一種傳輸方式；要啓用日誌記錄的話，請您先添加如下命令到客戶端應用程序：

$ connection.hub.logging= true;

·       在IE瀏覽器中,按F12打開開發者工具, 點擊控制檯（console）標籤.

·       在Chrome瀏覽器, 按Ctrl+Shift+J.打開控制檯（console)

經過觀察控制檯中的日誌記錄，你就能看到SignalR正在使用的傳輸方式。

2.1.5指定傳輸協議和fallback（協商轉換）機制：
    協商轉換傳輸方式是須要必定的時間和客戶端、服務器的資源。若是客戶端的環境（瀏覽器類型版本等）是已知的，那麼您能夠在啓動鏈接時，指定傳輸方式來提升性能。下面的代碼片斷演示若是已知客戶端不支持任何其餘傳輸協議時，直接在鏈接啓動時就使用Ajax的長輪詢做爲傳輸方式：

connection.start({  transport: 'longPolling' });

 

         若是您想要一個客戶端按照特定的順序進行傳輸方式的協商轉換，你能夠指定協商轉換的順序。下面的代碼片段演示了優先嚐試使用的WebSocket，若是不支持，則使用長輪詢。

connection.start({ transport:  ['webSockets','longPolling'] });

用於指定傳輸的字符串常量的定義以下

1)  webSockets

2)  forverFrame

3)  serverSentEvent

4)  longPolling

2.1.6.長鏈接（PersistentConnection）和集線器（Hubs）
    該SignalR API包含兩種模式去實現客戶端和服務器之間的通訊：長鏈接和集線器。
    1）長鏈接（PersistentConnection）：表示一個簡單的從終端向單個、分組，或羣發廣播消息的簡單結點。長鏈接API （由PersistentConnection類表示。封裝在NET中的代碼），讓開發人員直接訪問SignalR的底層通訊協議。使用長鏈接的通訊模式，而且對它API的調用，就如熟悉調用WCF（相似WebService）開發的API同樣簡單。

    2）集線器（Hubs）：是基於API但級別更高一級的通訊管道，他容許客戶端和服務器上互相直接調用方法。 SignalR能很巧妙地處理跨機器的調度，讓客戶端輕鬆地調用服務器端上的方法，就如同調用本地方法同樣，反之亦然。對於使用過.net Remoting的開發人員來講，使用集線器通訊模式去遠程調用的服務器或客戶端API，都是一件很容易的事情。使用集線器，您還能夠在方法中使用強類型參數，而且綁定到你的Model類裏。

    3）架構圖：下圖顯示了集線器、長鏈接與用於傳輸的底層技術之間的關係。

2.1.7.集線器（Hubs）是如何工做的：
    當服務器端的代碼調用客戶端的方法時，服務器端將發送一個包含要調用（當一個對象被做爲方法參數時，將倍序列化爲JSON來發送）的方法的名稱和參數的數據包，主動推送給客戶端。而後，客戶端檢查接收到該方法名稱，並在客戶端定義的方法中進行匹配查找，若是匹配成功，則執行方法而且使用反序列化的對象做爲方法參數。
    您可使用Fiddler之類的工具來監控方法的調用執行狀況。下圖顯示了在Fiddler的日誌中抓取到的一個從SignalR服務器發送到Web瀏覽器客戶端的方法。該從集線器發起調用的方法爲：MoveShapeHub，被調用的方法爲：updateShape。

    很明顯，在這個例子中，這個M:[{xxxxxxxxx}]JSON數字裏面，"H"對應的是服務器端的方法名，"M"對應的是客戶端的方法名，"A"是咱們要傳輸的參數

 

2.1.8長鏈接（PersistentConnection）和集線器（Hubs）的選擇(通訊模式的選擇)：

1）大多數應用程序應該使用集線器（Hubs）的API。

2）長鏈接（PersistentConnection）的         API能夠在下列狀況下使用：
                  a）須要指定實際發送的消息的格式。（本身定製消息的JSON格式）。
                  b）開發人員更喜歡WCF（Webservice）調用的方式，而不是.netRemoting。
                  c）.現有程序已經使用WCF（Webservice）的方法的程序，而且計劃移到植SignalR。