本篇內(nèi)容介紹了“ASP.NET SignalR是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)擁有一支富有激情的企業(yè)網(wǎng)站制作團隊，在互聯(lián)網(wǎng)網(wǎng)站建設(shè)行業(yè)深耕10余年，專業(yè)且經(jīng)驗豐富。10余年網(wǎng)站優(yōu)化營銷經(jīng)驗，我們已為上1000家中小企業(yè)提供了成都網(wǎng)站建設(shè)、成都網(wǎng)站制作解決方案，按需設(shè)計，設(shè)計滿意，售后服務(wù)無憂。所有客戶皆提供一年免費網(wǎng)站維護!

介紹SignalR

ASP.NET SignalR 是一個為 ASP.NET 開發(fā)人員的庫，簡化了將實時 web 功能添加到應(yīng)用程序的過程。實時Web功能使服務(wù)端代碼推送內(nèi)容到鏈接可客服端并立即應(yīng)用成為可能，而不需要服務(wù)端等待客戶端去請求數(shù)據(jù)。

SignalR可用于任何你想添加實時Web功能到ASP.NET應(yīng)用程序的情形，聊天室是一個常用的例子，用戶可以刷新Web頁面來獲得新的數(shù)據(jù)，或者頁面使用一個長輪詢來取回數(shù)據(jù)，這都是SignalR可以應(yīng)用的場景。比如說儀表盤和監(jiān)視系統(tǒng)，實時游戲等。

SignalR支持以一種簡單的API來創(chuàng)建服務(wù)器到客戶端的遠程調(diào)用客戶端的Javascript方法，SignalR還包括用于用于連接管理的API和分組連接。

SignalR自動的處理連接管理，并允許你像一個聊天室那樣同時向所有連接的客戶端廣播消息，你也可以向特定的客戶端發(fā)送消息，在客戶端和服務(wù)器之間的連接是持久的，不需要像傳統(tǒng)的HTTP連接那樣重建每一個連接。

SignalR支持服務(wù)器推送功能，在服務(wù)器中可以調(diào)用在瀏覽器中的客戶端代碼，而不是像當今的“請求-響應(yīng)”模式。

SignalR可以通過服務(wù)總線擴展到數(shù)以千計的客戶端，同時SignalR是開源的，可以用過Github訪問到。

SignalR和WebSocket

SignalR當WebSocket可用時優(yōu)先使用新式的WebSocket傳輸，同時也兼容老式的傳輸。雖然你可以立刻使用WebSocket編寫你的應(yīng)用程序，但是使用SignalR意味著你可以獲得本來需要你自己去實現(xiàn)的很多擴展方法，最重要的是，你可以直接使用SignalR編寫利用WebSocket的代碼，而不必擔心還要為舊的客戶端提供支持。同時你也不必擔心WebSocket的更新，因為SignalR會持續(xù)的更新來支持基礎(chǔ)的傳輸協(xié)議，提供對不同版本的WebSocket的統(tǒng)一接口支持。

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

傳輸和回滾

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

HTML5 傳輸協(xié)議

這些傳輸依賴于對HTML5的支持，假如客戶端不支持HTML5標準，講使用老式的傳輸協(xié)議：

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

服務(wù)器發(fā)送事件：也稱為事件源。基本上除了IE以外都支持事件源。

Comet transports

以下的傳輸協(xié)議是基于Comet web應(yīng)用程序模型的，在客戶端瀏覽器或者其他客戶端維持一個長期持久的HTTP請求，服務(wù)器端使用它推送數(shù)據(jù)而無需客戶端單獨請求。

持久型框架(Forever Frame)：（僅限于IE）持久型框架創(chuàng)建一個隱藏的IFrame，用它來創(chuàng)建一個在服務(wù)器終結(jié)點不結(jié)束的請求，服務(wù)器端可以持續(xù)不斷的發(fā)送到客戶端執(zhí)行腳本，一次來支持一個單向的從服務(wù)器端到客戶端的實時連接。這個鏈接使用了與客戶端請求服務(wù)器端不同的連接，像一個標準的HTTP請求，為每個需要發(fā)送的數(shù)據(jù)創(chuàng)建新的連接。

AJAX長輪詢（Ajax long polling)，長輪詢不創(chuàng)建持久的連接，取而代之的是

直到服務(wù)器另一端有反饋，在向開放的服務(wù)器發(fā)送請求，此時需要馬上建立新的鏈接

傳輸協(xié)議選擇過程

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

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

2.如果配置了JSONP（當連接開始的時候設(shè)置jsonp參數(shù)為true），使用長輪詢；

3.如果正在創(chuàng)建跨域的連接（如果SignalR終結(jié)點不和頁面上的地址相同),如果以下條件符合將使用WebSocket：

• 客戶端支持CORS（了解詳細情況，請點擊這里）

• 客戶端支持WebSocket

• 服務(wù)器端支持WebSocket

4。如果JSONP沒有被配置并且連接不是跨域的，如果客戶端和服務(wù)器端都支持WebSocket，將使用WebSocket；

5.假如客戶端和服務(wù)器端都不支持WebSocket，盡量使用事件源；

6.如果服務(wù)器端不支持事件源，使用持久型框架；

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

監(jiān)測傳輸

你可以決定是否在總線上打開日志記錄，打開瀏覽器的控制臺窗口。

要啟動你在瀏覽器的總線事件，請將以下命令添加到客戶端應(yīng)用程序中：

在IE中，按F12打開開發(fā)人員工具，點擊“控制臺”標簽頁。

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

指定傳輸協(xié)議

協(xié)商傳輸協(xié)議需要一定的時間和服務(wù)器客戶端資源，如果客戶端可以預(yù)知到，那么傳輸協(xié)議可以在連接開始的時候指定，以下代碼通過一個簡短的示例開啟一個使用AJAX長輪詢的連接，如果它已知客戶端不支持其他任何的協(xié)議：

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

你也可以指定一個回調(diào)順序讓客戶端去嘗試指定傳輸協(xié)議：

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

以下是定義的用于指定傳輸協(xié)議的字符串：

• webSockets

• foreverFrame

• serverSentEvents

• longPolling

連接和Backplane

SignalR API包含兩種服務(wù)器端和客戶端的通信模型：持久連接和總線.

一個連接表示單個收件人、編組或者廣播消息發(fā)送一個簡單的終結(jié)點。持久化連接API賦予程序員直接訪問SignalR提供的底層通信協(xié)議的能力，使用連接通信模型類似于程序員使用像WCF那樣基于連接的API。

總線是更高級別的管道，他是建立在基于連接的API上，允許客戶端和服務(wù)器彼此直接調(diào)用方法。SignalR神奇的處理在跨越機器的調(diào)度，讓客戶端調(diào)用服務(wù)器端代碼像調(diào)用本地方法那樣簡單，反之亦然。使用總線通信模型類似于使用.NET Remoting這樣的遠程調(diào)用API，使用Backplane允許你將強類型的參數(shù)傳給方法，進行模型綁定。

“ASP.NET SignalR是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！