C# BS消息推送 SignalR介紹（一）

1. 前言

本文是根據網上前人的總結得出的。

環境： SignalR2.x，VS2015，Win10

 

介紹

1）SignalR能用來持久客戶端與服務端的鏈接，讓咱們便於開發一些實時的應用，例如聊天室在線預訂系統，股票交易等實時應用。

2）SignalR是開源的項目，是 ASP.NET 團隊正在開發的一個 Microsoft .NET Framework 庫和 jQuery 插件。

3）SignalR 是一個集成的客戶端與服務器庫，基於瀏覽器的客戶端和基於 ASP.NET 的服務器組件能夠藉助它來進行雙向多步對話。 換句話說，該對話可不受限制地進行單個無狀態請求/響應數據交換；它將繼續，直到明確關閉。 對話經過永久鏈接進行，容許客戶端向服務器發送多個消息，並容許服務器作出相應答覆，值得注意的是，還容許服務器向客戶端發送異步消息。

4）SignalR會使用Javascript的長輪詢（ long polling），實現客戶端和服務端通訊。在WebSockets出現之後，SignalR也支持WebSockets通訊。固然SignalR也使用了服務端的任務並行處理技術以提升服務器的擴展性。

聊天室要解決最大的問題就是 消息的推送。當N個在線用戶 同時加入一個聊天室時，1個用戶發送消息，服務端就要把這個消息轉發給特定的人。

以前的技術都是經過Javascript來不停地發送請求來輪詢服務端的新的消息。這種按期發送Ajax請求給服務器的方式，在用戶很大的狀況下給服務器帶來很大的壓力。

WebSockets這個技術的出現，很好地解決了這個問題，偏偏支持能夠主動推送消息，SignalR 支持WebSockets。咱們能夠看到將來網絡應用中會大量出現本身吃WebSockets的程序，而SignalR應該也會普遍在ASP.NET 網站中出現。

5）項目官網：http://signalr.net/

GitHub：https://github.com/SignalR/SignalR

 

2. 技術發展

1）之前的技術：

應用技術	說明	優缺點
輪詢（polling）	這應該是最多見的一種實現數據交互的方式，開發人員控制客戶端以必定時間間隔中向服務器發送Ajax查詢請求大，可是也所以，當服務器端內容並無顯著變化時，這種鏈接方式將帶來不少無效的請求，形成服務器資源損耗。適合併發量小，實時性要求低的應用模型，更像是定時任務。	優勢：實現最爲簡單，配置簡單，出錯概率小 缺點：每次都是一次完整的http請求，易延遲，有效請求命中率少，併發較大時，服務器資源損耗大
長輪詢（long polling）	長輪詢是對輪詢的改進，客戶端經過請求鏈接到服務器，並保持一段時間的鏈接狀態，直到消息更新或超時才返回Response並停止鏈接，能夠有效減小無效請求的次數。屬於Comet實現	優勢：有效減小無效鏈接，實時性較高 缺點：客戶端和服務器端保持鏈接形成資源浪費，服務器端信息更新頻繁時，long polling並不比polling高效，而且當數據量很大時，會形成連續的polls不斷產生，性能上反而更糟糕
iframe流	iframe流方式是在頁面中插入一個隱藏的iframe，利用其src屬性在服務器和客戶端之間建立一條長連接，服務器向iframe傳輸數據（一般是HTML，內有負責插入信息的javascript），來實時更新頁面。屬於Comet實現	優勢：實時性高，瀏覽器兼容度好 缺點：客戶端和服務器端保持長鏈接形成資源浪費
WebSocket	WebSocket是HTML5提供的一種在單個 TCP 鏈接上進行全雙工通信的協議，目前chrome、Firefox、Opera、Safari等主流版本均支持，Internet Explorer從10開始支持。另外由於WebSocket 提供瀏覽器一個原生的 socket實現，因此直接解決了 Comet 架構很容易出錯的問題，而在整個架構的複雜度上也比傳統的實現簡單得多。	優勢：服務器與客戶端之間交換的數據包檔頭很小，節約帶寬。全雙工通訊，服務器能夠主動傳送數據給客戶端。 缺點：舊版瀏覽器不支持

2）SignalR：

當環境條件合適時，SignalR將WebSocket做爲底層傳輸方式的優先實現，固然，它也能很高效地回退到其餘技術。同時，SignalR提供了很是良好的Api以供遠程調用(RPC) 瀏覽器中的js代碼。

傳輸方式	選擇條件
long polling	1.IE8或更早版本 2.鏈接啓動時JSONP參數設置爲TRUE 3.Forever Frame不可用
WebSocket	1.正在使用跨域鏈接，而且符合如下條件（如下不知足任一條則使用長輪詢） （1）.客戶端支持CORS （2）.客戶端支持WebSocket （3）.服務器端支持WebSocket 2.不配置使用JSONP，鏈接不跨域而且客戶端和服務器端都支持WebSocket （1）.客戶端支持CORS （2）.客戶端支持WebSocket （3）.服務器端支持WebSocket
ServerSendEvent	客戶端或服務器端不支持Websocket
Forever Frame	EventSource不可用（基本上除了IE外都支持）

 

3. SignalR普通設置&介紹

1） 前端設置打印log

$.connection.chatHub.logging = true

2）SignalR有兩種鏈接，分爲Persistent Connection(永久鏈接) 與 Hubs

有經典的介紹他們的區別：（這裏不翻譯，以避免引發歧義）

From what I see in the Connection and Hubs section it seems that Hubs provide a topic system overlaying the lower-level persistent connections.

The example used in the documentation uses a chat room metaphor, where users can join a specific room and then only get messages from other users in the same room. More generically your code subscribes to a topic and then get just messages published to that topic. With the persistent connections you'd get all messages.

You could easily build your own topic system on top of the persistent connections, but in this case the SignalR team did the work for you already.

You can get topics or groups in persistent connections as well. The big difference is dispatching different types of messages. For example you have different kinds of messages and you want to send different kinds of payloads. With persistent connections you have to embed the message type in the payload (see Raw sample) but hubs gives you the ability to do RPC over a connection (lets you call methods on on the client from the server and from the server to the client). Another big thing is model binding. Hubs allow you to pass strongly typed parameters to methods.

通訊模型	說明
Persistent Connections	Persistent Connections表示一個發送單個，編組，廣播信息的簡單終結點。開發人員經過使用持久性鏈接Api，直接訪問SignalR公開的底層通訊協議。
Hubs	Hubs是基於鏈接Api的更高級別的通訊管道，它容許客戶端和服務器上彼此直接調用方法，SignalR可以很神奇地處理跨機器的調度，使得客戶端和服務器端可以輕鬆調用在對方端上的方法。使用Hub還容許開發人員將強類型的參數傳遞給方法而且綁定模型

 

 

請繼續前往下一篇文章

C# BS消息推送 SignalR Hubs環境搭建與開發（二）

 

 

 

能夠關注本人的公衆號，多年經驗的原創文章共享給你們。