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

 

 

 

可以关注本人的公众号，多年经验的原创文章共享给大家。