第一章ASP.NET SignalR简介

第一章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的也有最严格的要求，它仅在最新版本的MicrosoftInternet Explorer、谷歌Chrome和MozillaFirefox浏览器中支持，其余浏览器如Opera和Safari中都只有部分部分实现（2014最新版本的Opera和Safari就不清楚了，估计会都支持，这是将来发展的方向）。
  2）服务器发送事件：也被称为EventSource（若是浏览器支持服务器发送的事件，这基本上是除了IE外的浏览器都支持该功能。）

 

2.1.2Comet的传输方式：
    下面的传输类型都是基于CometWeb应用程序模型的，浏览器或客户端将保持HTTP的长链接请求，服务器能够在客户端没有明确请求的状况下，将数据推送到客户端。
  1）Forever Frame（仅适用于IE浏览器） ：Forever Frame会建立一个隐藏的IFrame ，而后向服务器发送一个不会完成的请求。而后服务器不断地发送脚本到客户端，而且由客户端当即执行该脚本，即创建一个从服务器到客户端的单向实时链接。而从客户端到服务器的链接则使用不一样于该链接的其余链接。像一个标准的HTML请求时同样，会为每次数据的发送都会建立一个新的链接。
  2）Ajax长轮询：长轮询不会建立一个持久的链接，而是经过客户端不断发出对服务器端的请求来进行轮询。在每次链接时，都会等待服务器发出响应后关闭此次链接，而后再当即发出新的请求（本身也能够定义间隔时间后，再发送新的请求）。固然，这种方式会在链接关闭再从新链接之间，形成必定的延迟。

   

关于各类配置所支持的传输方式，请参见支持的平台（SupportedPlatforms）.的详细信息。

 

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

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

5.若是客户端或服务器不支持WebSocket的，则使用服务器发送事件（EventSource）。
7.若是服务器发送事件不可用，则尝试使用ForeverFrame。
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）调用的方式，而不是.netRemoting。
                  c）.现有程序已经使用WCF（Webservice）的方法的程序，而且计划移到植SignalR。