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环境搭建与开发（二）

 

 

 

能够关注本人的公众号，多年经验的原创文章共享给你们。