SignalR簡介

什麼是SignalR？

ASP.NET SignalR是ASP.NET開發人員的庫，它簡化了嚮應用程式添加實時Web功能的過程。實時Web功能是指伺服器代碼在連接的客戶端可用時立即將內容推送到連接的客戶端，而不是讓伺服器等待客戶端請求新數據。

SignalR可用於向ASP.NET應用程式添加任何類型的“實時”Web功能。雖然聊天經常被用作示例，但您可以做更多的事情。每當用戶刷新網頁以查看新數據，或者頁面實現長輪詢以檢索新數據時，它都是使用SignalR的候選者。示例包括儀錶板和監視應用程式，協作應用程式（如同時編輯文檔），作業進度更新和實時表單。

SignalR還支持全新類型的Web應用程式，這些應用程式需要來自伺服器的高頻更新，例如實時游戲。

SignalR提供了一個簡單的API，用於創建從伺服器端.NET代碼調用客戶端瀏覽器（和其他客戶端平臺）中的JavaScript函數的伺服器到客戶端遠程過程調用（RPC）。SignalR還包括用於連接管理的API（例如，連接和斷開事件）以及分組連接。

SignalR自動處理連接管理，並允許您同時向所有連接的客戶端廣播消息，如聊天室。您還可以向特定客戶端發送消息。客戶端和伺服器之間的連接是持久的，不像傳統的HTTP連接，它是為每次通信重新建立的。

SignalR支持“伺服器推送”功能，其中伺服器代碼可以使用遠程過程調用（RPC）調用瀏覽器中的客戶端代碼，而不是當今Web上常見的請求 - 響應模型。

SignalR應用程式可以使用Service Bus，SQL Server或Redis擴展到數千個客戶端。

SignalR是開源的，可通過GitHub訪問。

SignalR和WebSocket

SignalR在可用的情況下使用新的WebSocket傳輸，併在必要時回退到舊的傳輸。雖然您當然可以直接使用WebSocket編寫應用程式，但使用SignalR意味著您需要實現許多額外的功能。最重要的是，這意味著您可以編寫應用程式代碼以利用WebSocket，而無需擔心為舊客戶端創建單獨的代碼路徑。SignalR還使您不必擔心WebSocket的更新，因為SignalR已更新以支持底層傳輸的更改，從而為您的應用程式提供跨WebSocket版本的一致界面。

傳輸和回退

SignalR 是一種抽象，通過某些要求進行客戶端和伺服器之間的實時工作的傳輸。 SignalR 連接作為 HTTP，啟動，然後升級到 WebSocket 連接是否可用。 WebSocket 是 SignalR 的理想之選傳輸，因為它使伺服器記憶體的最有效地使用，具有最低的延遲，並且具有最基本功能 （如完整雙工客戶端和伺服器之間的通信），但它還具有最嚴格要求： WebSocket 要求要使用 Windows Server 2012 或 Windows 8 和.NET Framework 4.5 的伺服器。 如果不滿足這些要求，SignalR 將嘗試使用其他傳輸以其連接。

HTML 5傳輸

這些傳輸依賴於對HTML 5的支持。如果客戶端瀏覽器不支持HTML 5標準，則將使用舊的傳輸。

WebSocket（如果伺服器和瀏覽器都表明它們可以支持Websocket）。WebSocket是唯一一種在客戶端和伺服器之間建立真正持久的雙向連接的傳輸。但是，WebSocket也有最嚴格的要求; 它僅在最新版本的Microsoft Internet Explorer，Google Chrome和Mozilla Firefox中得到完全支持，並且僅在Opera和Safari等其他瀏覽器中部分實現。
伺服器發送事件，也稱為EventSource（如果瀏覽器支持伺服器發送事件，基本上是除Internet Explorer之外的所有瀏覽器。）

Comet 傳輸

基於以下傳輸Comet web 應用程式模型中，瀏覽器或其他客戶端維護伺服器可以用於將數據推送到客戶端不使用客戶端專門的長時間持有 HTTP 請求請求它。
永久幀（適用於 Internet Explorer)。 永久幀創建隱藏的 IFrame 的未完成的伺服器上的終結點向發出請求。 伺服器然後不斷會腳本發送到客戶端立即執行，提供從伺服器到客戶端的單向實時連接。 從客戶端與伺服器的連接使用單獨的連接從伺服器到客戶端連接和像標準的 HTTP 請求，為每個條需要發送的數據創建新的連接。
Ajax 長輪詢。 長輪詢不創建持久性連接，但改為輪詢具有保持打開狀態直到伺服器做出響應，此時將關閉連接，並立即請求新的連接的請求的伺服器。 連接重置時，這可能會造成一些延遲。
有關哪些傳輸受支持的配置下的詳細信息，請參閱支持的平臺。

傳輸選擇過程

以下列表顯示 SignalR 使用來確定使用哪個傳輸的步驟。

1. 如果瀏覽器是 Internet Explorer 8 或更早版本，則使用長輪詢。
2. 如果配置 JSONP (即jsonp參數設置為true啟動連接時)，使用長輪詢。
3. 如果操作正在進行的跨域連接，（即，如果 SignalR 終結點不在托管的頁面所在的域中），然後 WebSocket 將在滿足以下條件：

• 客戶端支持 CORS （跨域資源共用）。 在其的客戶端支持 CORS 的詳細信息，請參閱CORS 在 caniuse.com。
• 客戶端支持 WebSocket
• 伺服器支持 WebSocket
  如果不滿足任何這些條件，則將使用長輪詢。 有關跨域連接的詳細信息，請參閱如何建立跨域連接。

1. 如果未配置 JSONP 並且連接不跨域，如果客戶端和伺服器支持它，則將使用 WebSocket。
2. 如果客戶端或伺服器不支持 WebSocket，如果可用，則使用伺服器發送事件。
3. 如果伺服器發送事件不可用，請嘗試使用永久幀。
4. 如果永久幀失敗，則使用長輪詢。

監視傳輸

您可以確定應用程式在中心上的日誌記錄和在瀏覽器中打開控制台視窗，從而使用什麼傳輸。
若要啟用瀏覽器中的中心的事件日誌記錄，客戶端應用程式中添加以下命令：

$.connection.hub.logging = true;

• 在 Internet Explorer 中，通過按 F12 打開開發人員工具，並單擊控制台選項卡。
• 在Chrome中，按Ctrl + Shift + J打開控制台。
• 打開控制台並啟用日誌記錄後，您將能夠看到SignalR正在使用哪種傳輸。

指定在傳輸協議

協商傳輸只占用一定的時間和客戶端/伺服器的資源。 如果已知的客戶端功能，則傳輸可以指定啟動客戶端連接時。 下麵的代碼段演示如何啟動使用 Ajax 長輪詢傳輸方式，因為如果它已知客戶端不支持任何其他協議將使用的連接：
connection.start({ transport: 'longPolling' });
如果你想要嘗試按順序的特定傳輸的客戶端，可以指定回退的順序。 下麵的代碼段演示嘗試 WebSocket，並且如果沒有問題，，直接轉到長輪詢。
connection.start({ transport: ['webSockets','longPolling'] });

用於指定傳輸中的字元串常數定義，如下所示：

• webSockets
• foreverFrame
• serverSentEvents
• longPolling

  連接和集線器

  SignalR API 包含客戶端和伺服器之間進行通信的兩個模型： 永久連接和中心。
  連接表示用於發送單個收件人、 分組或廣播消息的簡單終結點。 開發人員直接訪問 SignalR 公開低級別通信協議 （由 PersistentConnection 類的.NET 代碼中表示） 的持久性連接 API 提供。 使用連接的通信模型都會熟悉的開發人員已使用基於連接的 Api，如 Windows Communication Foundation。
  中心是基於連接 API，從而使您的客戶端和伺服器直接相互調用方法的更多高級管道。 SignalR 處理跨電腦界限調度像變魔術一樣，是通過允許客戶端在伺服器上調用方法，以輕鬆地為本地方法，反之亦然。 使用中心的通信模型都會熟悉的開發人員已使用遠程調用 Api，如.NET 遠程處理。 使用中心還允許您將強類型化的參數傳遞給方法，使模型綁定。

體繫結構關係圖

下圖顯示了中心、 永久連接和用於傳輸的基礎技術之間的關係。

中心的工作原理

伺服器端代碼在客戶端上調用的方法時發送一個數據包，在活動傳輸包含名稱和要調用的方法的參數 （作為方法參數發送一個對象，它使用 JSON 序列化）。 然後，客戶端匹配到客戶端代碼中定義的方法的方法名稱。 如果沒有匹配項，將使用反序列化的參數數據執行客戶端方法。
可以使用像這樣的工具監視方法調用Fiddler。 下圖顯示了從 SignalR 伺服器發送到 web 瀏覽器客戶端在 Fiddler 日誌窗格中的方法調用。 方法調用從集線器調用發送MoveShapeHub，並正在調用的方法稱為updateShape。

顯示SignalR交通的提琴手日誌看法

在此示例中，使用H參數標識集線器名稱; 使用M參數標識方法名稱，並使用參數標識發送到方法的A數據。生成此消息的應用程式是在高頻實時教程中創建的。

選擇通信模型

大多數應用程式應使用中心 API。 可在以下情況下使用連接 API:

• 需要指定將發送的實際消息的格式。
• 開發人員傾向於使用消息傳送與調度模型而不是遠程調用模型。
• 使用消息傳送模型的現有應用程式移植以使用 SignalR。