ASP.NET SignalR 2.0 入門指南

介紹SignalR

ASP.NET SignalR 是一個為 ASP.NET 開發人員的庫，簡化了將實時 web 功能新增到應用程式的過程。實時Web功能使服務端程式碼推送內容到連結可客服端並立即應用成為可能，而不需要服務端等待客戶端去請求資料。

SignalR可用於任何你想新增實時Web功能到ASP.NET應用程式的情形，聊天室是一個常用的例子，使用者可以重新整理Web頁面來獲得新的資料，或者頁面使用一個長輪詢來取回資料，這都是SignalR可以應用的場景。比如說儀表盤和監視系統，實時遊戲等。

SignalR支援以一種簡單的API來建立伺服器到客戶端的遠端呼叫客戶端的Javascript方法，SignalR還包括用於用於連線管理的API和分組連線。

SignalR自動的處理連線管理，並允許你像一個聊天室那樣同時向所有連線的客戶端廣播訊息，你也可以向特定的客戶端傳送訊息，在客戶端和伺服器之間的連線是持久的，不需要像傳統的HTTP連線那樣重建每一個連線。

SignalR支援伺服器推送功能，在伺服器中可以呼叫在瀏覽器中的客戶端程式碼，而不是像當今的“請求-響應”模式。

SignalR可以通過服務匯流排擴充套件到數以千計的客戶端，同時SignalR是開源的，可以用過Github訪問到。

SignalR和WebSocket

SignalR當WebSocket可用時優先使用新式的WebSocket傳輸，同時也相容老式的傳輸。雖然你可以立刻使用WebSocket編寫你的應用程式，但是使用SignalR意味著你可以獲得本來需要你自己去實現的很多擴充套件方法，最重要的是，你可以直接使用SignalR編寫利用WebSocket的程式碼，而不必擔心還要為舊的客戶端提供支援。同時你也不必擔心WebSocket的更新，因為SignalR會持續的更新來支援基礎的傳輸協議，提供對不同版本的WebSocket的統一介面支援。

雖然你可以單獨使用WebSocket建立你的解決方案，但是SignalR支援所有你需要自己去編寫的方法，比如支援其他修訂版的功能。

傳輸和回滾

SignalR是對一些伺服器和客戶端之間實時協作傳輸的抽象化，一個SignalR連線作為一個HTTP開始，但是如果WebSocket是可用的將得到利用。WebSocket是SignalR理想的傳輸方法，它能高效的利用服務端儲存，擁有最少的延遲，而且擁有最基礎的功能(比如全雙工通訊)，但是它也同時又嚴格的要求：WebSocket必須要求伺服器使用Windows Server 2012或者windows 8，使用.NET Framework 4.5框架，如果沒有達到這些條件，SignalR將試圖使用其他的傳輸來建立連線。

HTML5 傳輸協議

這些傳輸依賴於對HTML5的支援，假如客戶端不支援HTML5標準，講使用老式的傳輸協議：

WebSocket：（如果客戶端可伺服器端都支援WebSocket）。WebSocket是唯一一個建立客戶端和伺服器端在真正的持久的雙工的傳輸協議，但是同時WebSocket也擁有嚴格的要求，它只在最新版本的IE、chrome和FireFox得到支援，在像Opera和Safari這些瀏覽器中得到的一部分的實現。

伺服器傳送事件：也稱為事件源。基本上除了IE以外都支援事件源。

comet transports

以下的傳輸協議是基於Comet web應用程式模型的，在客戶端瀏覽器或者其他客戶端維持一個長期持久的HTTP請求，伺服器端使用它推送資料而無需客戶端單獨請求。

持久型框架(Forever Frame)：（僅限於IE）持久型框架建立一個隱藏的IFrame，用它來建立一個在伺服器終結點不結束的請求，伺服器端可以持續不斷的傳送到客戶端執行指令碼，一次來支援一個單向的從伺服器端到客戶端的實時連線。這個連結使用了與客戶端請求伺服器端不同的連線，像一個標準的HTTP請求，為每個需要傳送的資料建立新的連線。

AJAX長輪詢（Ajax long polling)，長輪詢不建立持久的連線，取而代之的是。直到伺服器另一端有反饋，在向開放的伺服器傳送請求，此時需要馬上建立新的連結

傳輸協議選擇過程

下面列表顯示了SignalR選擇傳輸協議的過程：

1.如果瀏覽器是IE8或者更老的版本，使用長輪詢；

2.如果配置了JSONP（當連線開始的時候設定jsonp引數為true），使用長輪詢；

3.如果正在建立跨域的連線（如果SignalR終結點不和頁面上的地址相同),如果以下條件符合將使用WebSocket：

• 客戶端支援CORS（瞭解詳細情況，請點選這裡）
• 客戶端支援WebSocket
• 伺服器端支援WebSocket

4.如果JSONP沒有被配置並且連線不是跨域的，如果客戶端和伺服器端都支援WebSocket，將使用WebSocket；

5.假如客戶端和伺服器端都不支援WebSocket，儘量使用事件源；

6.如果伺服器端不支援事件源，使用持久型框架；

7.如果持久型框架也失敗，使用長輪詢。

監測傳輸

你可以決定是否在匯流排上開啟日誌記錄，開啟瀏覽器的控制檯視窗。

要啟動你在瀏覽器的匯流排事件，請將以下命令新增到客戶端應用程式中：

在IE中，按F12開啟開發人員工具，點選“控制檯”標籤頁。

在Chrome中，使用組合鍵Ctrl+Shift+J開啟控制檯

指定傳輸協議

協商傳輸協議需要一定的時間和伺服器客戶端資源，如果客戶端可以預知到，那麼傳輸協議可以在連線開始的時候指定，以下程式碼通過一個簡短的示例開啟一個使用AJAX長輪詢的連線，如果它已知客戶端不支援其他任何的協議：

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

你也可以指定一個回撥順序讓客戶端去嘗試指定傳輸協議：

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

以下是定義的用於指定傳輸協議的字串：

• webSockets
• foreverFrame
• serverSentEvents
• longPolling

連線和匯流排

SignalR API包含兩種伺服器端和客戶端的通訊模型：持久連線和匯流排.

一個連線表示單個收件人、編組或者廣播訊息傳送一個簡單的終結點。持久化連線API賦予程式設計師直接訪問SignalR提供的底層通訊協議的能力，使用連線通訊模型類似於程式設計師使用像WCF那樣基於連線的API。

匯流排是更高階別的管道，他是建立在基於連線的API上，允許客戶端和伺服器彼此直接呼叫方法。SignalR神奇的處理在跨越機器的排程，讓客戶端呼叫伺服器端程式碼像呼叫本地方法那樣簡單，反之亦然。使用匯流排通訊模型類似於使用.NET Remoting這樣的遠端呼叫API，使用匯流排模型允許你將強型別的引數傳給方法，進行模型繫結。

體系結構關係圖

以下關係圖表示了匯流排、持久化連線和用於傳輸的基本技術間的關係：