珠海华仔的开发园地

大家好才是真的好

导航

第一章ASP.NET SignalR简介

Posted on 2015-03-19 10:23  珠海华仔  阅读(768)  评论(7编辑  收藏  举报

第一章ASP.NET SignalR简介

1.1概述:

    ASP.NET SignalR是微软新开发的类库,为的是帮助ASP.NET开发人员很方便地开发实时网络功能。 SignalR允许服务器端和客户端之间进行双向通信。服务器端现在可以连接到客户端并且把内容瞬间推送出去,而不是一个客户端不断请求服务器端从而才能获取新数据(不是通过轮询去拉服务器端数据,而是服务器端主动推送数据到客户端)。SignalR支持Web Sockets套接字,并且当使用旧版浏览器的时候会自动使用相关兼容的技术。 SignalR包括它的API接口,用于连接管理的解耦(例如,连接和断开连接的事件),群组连接接口和授权接口等。

         SignalR可以为您的ASP.NET应用程序添加各种“实时”的Web功能。最常用的例子有聊天室,但当你使用SignalR后,我们可以比这做得更好更多。过去,用户需要通过不断刷新网页才能看到新的数据;或者在页面上通过实现长轮询来检索新数据(并显示),这些功能都会在在使用SignalR后变得更容易实现和使用。比如:仪表板及监视型应用程序、协作性应用程序(如多人同时对文档进行编辑)、作业进度更新及时呈现表单等。

    SignalR也支持现在新类型的,需要从服务器上进行高频率的更新的Web应用程序,例如,实时游戏。对于这方面的一个很好的例子,请参见ShootR game.

    SignalR提供了一个简单的API,用于创建服务器到客户端的远程过程调用(RPC) ,从服务器端的.net代码调用客户端的浏览器(和其他客户端平台)的 JavaScript函数。SignalR还包括用于连接管理API (例如,连接和断开连接诶事件) ,群组连接和授权等。(简单来说,提供了服务器端API调用和客户端的JS事件)

 

    SignalR可以自动对连接进行管理,并让您同时发送广播消息到所有连接的客户端,就像一个聊天室聊天一样。当然,您也可以选择向特定的用户(客户端)发送消息。客户端和服务器之间的连接是持久的,也就是通常我们所说的长连接,而不像一个典型的HTTP连接,每次通信都要重新建立连接。
    SignalR支持“服务器推送”功能,即服务器代码可以通过使用远程过程调用(RPC)来调用浏览器中的客户端代码,而不是在Web网站上常见的【请求-响应模型】的形式去获取数据。
    SignalR的应用通过使用服务总线(Service Bus)、SQL Server或Redis来扩展到数以万计的客户端上。
    SignalR是开源的,通过GitHub.的访问来查看源码。

    SignalR在支持HTML5的浏览器下,通常是使用WebSocket,来实现服务端跟客户端的通信。如果浏览器不支持WebSocket 那么他会自动切换支持该浏览器的其他的技术来实现(如Http长连接)。不管用哪种技术,最后都会实现同样的结果。当然,你也可以直接使用WebStocket来编写你的应用程序,但使用SignalR意味着你将有更多的额外功能而无需自己重新发明轮子(人家都写好接口了,拿来使用不是更好,何必自己重复建轮子)。最重要的是,你可以把时间和注意力放在业务实现上,而无需考虑为旧的客户端(IE9以下等)写兼容性代码。SignalR还能够使你不必担心WebStocket的更新,因为SignalR将会继续更新以及支持变化的底层传输方式,跨不同版本的WebStocket来为应用程序提供一个一致的访问接口。

    当然,你可以创建只使用WebStocket传输的解决方案,SignalR提供了你可能需要自行编写代码的所有功能,比如回退到其他传输方式以及针对更新的WebStocket来实现修改您的应用程序。

 

2.1传输和协商转换(FallBacks):
         SignalR是对客户端及服务器之间实时功能实现所需要的传输技术的抽象。SignalR首先使用HTTP的方式开始连接,并且检查WebSocket连接是否可用,如果可用,则会自动转为Webstocket连接。WebSocket是SignalR最理想的传输方式,因为它可以最有效地利用服务器内存,具有最低的延迟,并拥有最底层的功能(如客户端和服务器之间的全双工通信【双向通信】),但它也有最严格的要求:WebSocket的要求服务器必须使用Windows Server2012或Windows8,和NET框架4.5。如果不符合这些要求,SignalR将尝试使用其他传输方式进行连接。

 

2.1.1 HTML5的传输方式:(推荐使用谷歌浏览器作为主浏览器)
         使用SignalR的任何传输方式都是取决于客户端浏览器是否支持HTML 5,如果客户端的浏览器不支持HTML5,将使用旧的传输方式。
         1)WebSocket(如果服务器和浏览器都支持WebSocket的): WebSocket唯一一种在客户端和服务器端建立真实持久的双向连接的传输方式。然而,WebSocket的也有最严格的要求,它仅在最新版本的Microsoft Internet Explorer、谷歌Chrome和Mozilla Firefox浏览器中支持,其他浏览器如Opera和Safari中都只有部分部分实现(2014最新版本的Opera和Safari就不清楚了,估计会都支持,这是未来发展的方向)。
  2)服务器发送事件:也被称为EventSource(如果浏览器支持服务器发送的事件,这基本上是除了IE外的浏览器都支持该功能。)

 

2.1.2 Comet的传输方式:
    下面的传输类型都是基于Comet Web应用程序模型的,浏览器或客户端将保持HTTP的长连接请求,服务器可以在客户端没有明确请求的情况下,将数据推送到客户端。
  1)Forever Frame(仅适用于IE浏览器) :Forever Frame会创建一个隐藏的IFrame ,然后向服务器发送一个不会完成的请求。然后服务器不断地发送脚本到客户端,并且由客户端立即执行该脚本,即建立一个从服务器到客户端的单向实时连接。而从客户端到服务器的连接则使用不同于该连接的其他连接。像一个标准的HTML请求时一样,会为每次数据的发送都会创建一个新的连接。
  2)Ajax长轮询:长轮询不会创建一个持久的连接,而是通过客户端不断发出对服务器端的请求来进行轮询。在每次连接时,都会等待服务器发出响应后关闭这次连接,然后再立即发出新的请求(自己也可以定义间隔时间后,再发送新的请求)。当然,这种方式会在连接关闭再重新连接之间,造成一定的延迟。

   

关于各种配置所支持的传输方式,请参见支持的平台(Supported Platforms).的详细信息。

 

2.1.3.传输方式选择的过程:
以下列表显示SignalR如何决定使用那种类型的传输方式进行传输:
1.如果浏览器是Internet Explorer 8或更早的版本,则使用长轮询。
2.如果配置了JSONP(即连接时,JSONP参数设置为true) ,则使用长轮询。
3.如果正在使用跨域连接(即SignalR端点和页面不在同一个域中) ,如能满足以下全部条件,则使用WebSocket:

    1)该客户端支持CORS (跨域资源共享) 。具体详细信息请参阅CORS at caniuse.com
    2)该客户端支持的WebSocket
  3)该服务器支持的WebSocket
如果以上三个条件,只要有一条不满足,则使用长轮询。有关跨域连接的详细信息,请参阅如何建立跨域连接
4.如果没有配置使用JSONP和连接不跨域,则使用WebSocket,当然,前提是客户端和服务器端都支持WebStocket

5.如果客户端或服务器不支持WebSocket的,则使用服务器发送事件(EventSource)。
7.如果服务器发送事件不可用,则尝试使用Forever Frame。
8.如果Forever Frame不可用,则使用长轮询。

(即默认使用的优先级:1.WebStocket;2.EventSource;3.Forever Frame; 4.长轮询)

2.1.4监控传输:  

         您可以通过启用Hub日志记录,并在浏览器的控制台中查看您的应用程序使用哪种传输方式;要启用日志记录的话,请您先添加以下命令到客户端应用程序:

$ connection.hub.logging= true;

  • 在IE浏览器中,按F12打开开发者工具, 点击控制台(console)标签.

 

  • 在Chrome浏览器, 按Ctrl+Shift+J.打开控制台(console)

 

通过观察控制台中的日志记录,你就能看到SignalR正在使用的传输方式。

2.1.5指定传输协议和fallback(协商转换)机制:
    协商转换传输方式是需要一定的时间和客户端、服务器的资源。如果客户端的环境(浏览器类型版本等)是已知的,那么您可以在启动连接时,指定传输方式来提高性能。下面的代码片段演示如果已知客户端不支持任何其他传输协议时,直接在连接启动时就使用Ajax的长轮询作为传输方式:

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

 

         如果您想要一个客户端按照特定的顺序进行传输方式的协商转换,你可以指定协商转换的顺序。下面的代码片断演示了优先尝试使用的WebSocket,如果不支持,则使用长轮询。

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

用于指定传输的字符串常量的定义如下

1)  webSockets

2)  forverFrame

3)  serverSentEvent

4)  longPolling

2.1.6.长连接(PersistentConnection)和集线器(Hubs)
    该SignalR API包含两种模式去实现客户端和服务器之间的通信:长连接和集线器。
    1)长连接(PersistentConnection):表示一个简单的从终端向单个、分组,或群发广播消息的简单结点。长连接API (由PersistentConnection类表示。封装在NET中的代码),让开发人员直接访问SignalR的底层通信协议。使用长连接的通信模式,并且对它API的调用,就如熟悉调用WCF(类似WebService)开发的API一样简单。

    2)集线器(Hubs):是基于API但级别更高一级的通信管道,他允许客户端和服务器上互相直接调用方法。 SignalR能很巧妙地处理跨机器的调度,让客户端轻松地调用服务器端上的方法,就如同调用本地方法一样,反之亦然。对于使用过.net Remoting的开发人员来说,使用集线器通信模式去远程调用的服务器或客户端API,都是一件很容易的事情。使用集线器,您还可以在方法中使用强类型参数,并且绑定到你的Model类里。

    3)架构图:下图显示了集线器、长连接与用于传输的底层技术之间的关系。

 

2.1.7.集线器(Hubs)是如何工作的:
    当服务器端的代码调用客户端的方法时,服务器端将发送一个包含要调用(当一个对象被作为方法参数时,将倍序列化为JSON来发送)的方法的名称和参数的数据包,主动推送给客户端。然后,客户端检查接收到该方法名称,并在客户端定义的方法中进行匹配查找,如果匹配成功,则执行方法并且使用反序列化的对象作为方法参数。
    您可以使用Fiddler之类的工具来监控方法的调用执行情况。下图显示了在Fiddler的日志中抓取到的一个从SignalR服务器发送到Web浏览器客户端的方法。该从集线器发起调用的方法为:MoveShapeHub,被调用的方法为:updateShape。

 

    很明显,在这个例子中,这个M:[{xxxxxxxxx}]JSON数字里面,"H"对应的是服务器端的方法名,"M"对应的是客户端的方法名,"A"是我们要传输的参数

 

2.1.8 长连接(PersistentConnection)和集线器(Hubs)的选择(通信模式的选择):

1)大多数应用程序应该使用集线器(Hubs)的API。

2)长连接(PersistentConnection)的         API可以在下列情况下使用:
                  a)需要指定实际发送的消息的格式。(自己定制消息的JSON格式)。
                  b)开发人员更喜欢WCF(Webservice)调用的方式,而不是.net Remoting。
                  c).现有程序已经使用WCF(Webservice)的方法的程序,并且计划移到植SignalR。