微軟官方中文SignalR說明文檔
什么是 SignalR？
ASP.NET SignalR 是
ASP.NET 開發人員的庫，可簡化將實時 web 功能添加到應用程序的過程。 實時 web 功能使服務器代碼能夠在可用時立即將內容推送到連接的客戶端，而不是讓服務器等待客戶端請求新的數據。
SignalR 可用於將任何種類的 "實時" web 功能添加到
ASP.NET 應用程序。 盡管聊天通常用作示例，但你可以執行更多操作。 用戶每次刷新網頁以查看新數據，或者頁面實現
長輪詢 來檢索新數據時，都是使用 SignalR 的候選項。 示例包括儀表板和監視應用程序、協作應用程序 (例如同步編輯文檔) 、作業進度更新和實時窗體。
SignalR 還啟用了全新類型的 web 應用程序，這些應用程序需要服務器中的高頻率更新，例如，實時游戲。
SignalR 提供了一個簡單的 API，用於創建 (RPC) 的服務器到客戶端遠程過程調用，該程序調用客戶端瀏覽器中的 JavaScript 函數 (和從服務器端 .NET 代碼) 的其他客戶端平台。 SignalR 還包括用於連接管理的 API (例如，連接和斷開連接事件) ，以及對連接進行分組。
SignalR 自動處理連接管理，讓你可同時向所有連接的客戶端廣播消息，就像聊天室一樣。 也可以向特定客戶端發送消息。 客戶端和服務器之間的連接是持久的，不同於傳統的 HTTP 連接，后者針對每次通信重新建立。
SignalR 支持 "服務器推送" 功能，在該功能中，服務器代碼可以使用遠程過程調用來調用瀏覽器中的客戶端代碼 (RPC) ，而不是目前在 web 上通用的請求-響應模式。
使用內置和第三方橫向擴展提供程序，SignalR 應用程序可以向外擴展到數千個客戶端。
內置提供程序包括：
第三方提供程序包括：
SignalR 是開放源代碼，可通過
GitHub訪問。
SignalR 和 WebSocket
SignalR 使用新的 WebSocket 傳輸（如果可用），並在必要時回退到較舊的傳輸。 雖然當然，你可以直接使用 WebSocket 編寫應用，但使用 SignalR 意味着你需要實現的很多額外功能都已完成。 最重要的是，這意味着您可以對應用程序進行編碼，以便利用 WebSocket，而不必擔心為較舊的客戶端創建單獨的代碼路徑。 SignalR 還會使你不必擔心對 WebSocket 的更新，因為 SignalR 會更新為支持基礎傳輸中的更改，從而為你的應用程序提供跨 WebSocket 版本的一致接口。
傳輸和回退
SignalR 是對在客戶端和服務器之間進行實時工作所需的某些傳輸的抽象。 如果可能，SignalR 將首先嘗試建立 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）中僅有部分實現。
如果瀏覽器支持服務器發送事件（基本上是 Internet Explorer 之外的所有瀏覽器），服務器發送事件（也稱為 EventSource (）。 )
Comet 傳輸
以下傳輸基於
Comet web 應用程序模型，在該模型中，瀏覽器或其他客戶端維護長時間的 HTTP 請求，服務器可以使用該模型將數據推送到客戶端，而客戶端無需專門請求它。
僅) Internet Explorer (的 "永久幀"。 永久幀創建一個隱藏的 IFrame，該 IFrame 向服務器上不能完成的終結點發出請求。 服務器隨后會持續向客戶端發送腳本，該腳本會立即執行，提供從服務器到客戶端的單向實時連接。 從客戶端到服務器的連接使用與服務器之間的單獨連接連接到客戶端連接，與標准 HTTP 請求一樣，為需要發送的每個數據段創建新連接。
Ajax 長輪詢。 長輪詢不會創建持續性連接，而是使用保持打開狀態的請求輪詢服務器，直到服務器響應為止，此時連接將關閉，並立即請求新連接。 在連接重置時，這可能會導致一些延遲。
有關在哪些配置下支持哪些傳輸的詳細信息，請參閱
支持的平台。
傳輸選擇過程
以下列表顯示了 SignalR 用於確定要使用的傳輸的步驟。
-
如果瀏覽器是 Internet Explorer 8 或更早版本，則使用長輪詢。
-
如果 JSONP 配置為 (即，則在 jsonp true 啟動連接) 時，參數設置為，使用長輪詢。
-
如果正在建立跨域連接 (即，如果 SignalR 終結點與托管頁) 不在同一域中，則在滿足以下條件時將使用 WebSocket：客戶端支持 CORS (跨域資源共享) 。 有關哪些客戶端支持 CORS 的詳細信息，請參閱 caniuse.com 上的 cors。客戶端支持 WebSocket服務器支持 WebSocket如果未滿足這些條件中的任何一個，將使用長輪詢。 有關跨域連接的詳細信息，請參閱 如何建立跨域連接。
-
如果未配置 JSONP 並且連接不跨域，則在客戶端和服務器均支持時，將使用 WebSocket。
-
如果客戶端或服務器不支持 WebSocket，則使用服務器發送事件（如果可用）。
-
如果 "服務器發送事件" 不可用，則將嘗試永久幀。
-
如果永久幀失敗，則使用長輪詢。
監視傳輸
可以通過在中心啟用日志記錄，並在瀏覽器中打開控制台窗口，來確定應用程序使用的傳輸方式。
若要在瀏覽器中為中心的事件啟用日志記錄，請將以下命令添加到客戶端應用程序：
$.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 包含兩種用於在客戶端和服務器之間進行通信的模型：持久性連接和中心。
連接表示用於發送單接收方、分組或廣播消息的簡單終結點。 持久性連接 API (在 .NET 代碼中由 PersistentConnection 類表示) 使開發人員能夠直接訪問 SignalR 公開的低級別通信協議。 使用基於連接的 Api （如 Windows Communication Foundation）的開發人員將對使用連接通信模型非常熟悉。
中心是一種基於連接 API 構建的更高級別管道，它允許客戶端和服務器直接調用方法。 SignalR 按魔術處理跨計算機邊界的調度，使客戶端能夠像本地方法一樣輕松地調用服務器上的方法，反之亦然。 如果開發人員已使用遠程調用 Api （如 .NET 遠程處理），則將對使用中心通信模型非常熟悉。 使用集線器還可以將強類型參數傳遞給方法，從而啟用模型綁定。
體系結構關系圖
下圖顯示了集線器、永久性連接和用於傳輸的底層技術之間的關系。
集線器的工作方式
當服務器端代碼在客戶端上調用方法時，會在包含要調用的方法的名稱和參數的活動傳輸中發送一個數據包 (當對象作為方法參數發送時，將使用 JSON) 對該對象進行序列化。 然后，客戶端將方法名稱與在客戶端代碼中定義的方法相匹配。 如果存在匹配項，則將使用反序列化的參數數據執行客戶端方法。
可以使用 Fiddler 等工具監視此方法調用
。 下圖顯示了在 Fiddler 的 "日志" 窗格中從 SignalR 服務器發送到 web 瀏覽器客戶端的方法調用。 正在從名為的中心發送方法調用 MoveShapeHub ，並且調用被調用的方法 updateShape 。
在此示例中，通過參數標識中心名稱 H ; 方法名用 M 參數標識，發送到方法的數據用 A 參數標識。 生成此消息的應用程序將在
高頻實時 教程中創建。
選擇通信模型
大多數應用程序應使用中心 API。 連接 API 可用於以下情況：
需要指定所發送的實際郵件的格式。
開發人員首選使用消息傳遞和調度模型，而不使用遠程調用模型。
使用消息傳送模型的現有應用程序正在移植，以使用 SignalR。