SignalR 简介

SignalR 简介

由帕特里克 · 弗莱彻|2013 年 2 月 27 日

英文原文地址：http://www.asp.net/signalr/overview/getting-started/introduction-to-signalr

这篇文章描述 SignalR 是什么，和一些它旨在建立的解决方案。

SignalR 是什么？

ASP.NET SignalR 是为 ASP.NET 开发人员提供的一个库，能够简化开发人员将实时 Web 功能添加到应用程序的过程。实时 Web 功能是指这样一种功能：当所链接的客户端变得可用时服务器代码能够当即向其推送内容，而不是让服务器等待客户端请求新的数据。

SignalR 能够用于将任何种类的“实时”Web 功能添加到您的 ASP.NET 应用程序。虽然咱们常常把聊天应用做为最经常使用的一个例子，但实际上你能够利用它作不少事情。若是用户是经过刷新 web 页面，来查看新的数据，或者是经过页面实现长轮询来检索新的数据，那么就该考虑使用 SignalR 了。示例包括仪表板和监视应用程序、协做应用程序（例如同时编辑文档）、工做进度更新和实时表单等等。

SignalR 还适用于全新类型的 Web 应用程序，特别是须要从服务器高频率更新的应用程序，例如实时游戏。一个好的例子，请参阅ShootR 游戏。

SignalR 提供一个简单的 API 用于建立服务器端到客户端的远程过程调用 (RPC)，以便从服务器端 .NET 代码中调用客户端浏览器（以及其余客户端平台）中的 JavaScript 函数。SignalR 还包括用于管理链接（例如，链接和断开链接事件）和为链接分组的 API。

SignalR 会自动管理链接，并容许您像聊天室那样向全部链接的客户端同时发送消息。你也能够向特定的客户端发送消息。客户端和服务器之间的链接是持久性的，不像传统的 HTTP 链接 —— 每一个通讯都须要从新创建一个链接。

SignalR 支持“服务器推送”功能，即服务器代码可使用远程过程调用 (PRC) 来调用浏览器中的客户端代码，而不使用目前在 Web 上经常使用的请求-响应模型。

SignalR 应用程序能够经过使用服务总线、SQL Server 或 Redis 扩展到数以千计的客户端.

SignalR 是开源的，能够经过 GitHub 访问。

SignalR 和 WebSocket

SignalR 会在可能的状况下使用新的 WebSocket 传输方式，而且在须要时回退到旧的传输方式。虽然您仍然能够直接使用 WebSocket 来编写应用程序，可是使用 SignalR 意味着您有许多现成的额外功能可用，而无需本身实现这些功能。最重要的是，这意味着您可使用 SignalR 编写应用程序以利用 WebSocket，而无需担忧为旧的客户端单首创建代码。SignalR 还可以使你没必要担忧 WebSocket 的更新，由于 SignalR 会持续更新以支持基础传输方式的更改，为您的应用程序提供一致的接口以使用不一样的 WebSocket 版本。

固然，您能够建立只使用 WebSocket 的解决方案，SignalR 为您提供了可能须要自行编写代码的全部功能，例如回退到其余的传输方式以及修订您的应用程序以更新到 WebSocket 实现。

传输和回退

SignalR 是对一组在构建客户端和服务器之间的real-time功能所须要使用的传输技术的抽象。SignalR 链接首先以 HTTP 发起请求，而后若是 WebSocket 可用的话，则升级到 WebSocket 链接。WebSocket 是 SignalR 的理想传输方式，由于它可以最高效地使用服务器的内存、 有最低的延迟，并且有的最主要的功能（如客户端和服务器之间的全双工通讯），但它也有最严格的环境需求： WebSocket 要求服务器是 Windows Server 2012 或 Windows 8 以及.NET Framework 4.5。若是不知足这些要求，SignalR 将尝试使用其余传输方式来创建链接。

HTML 5 传输

传输方式取决因而否支持 HTML 5。若是客户端浏览器不支持 HTML 5 标准，将使用较旧的传输方式。

• WebSocket（若是服务器和浏览器都指明它们支持 Websocket）。WebSocket 是惟一一个在客户端和服务器之间创建真正的持久双向链接的传输方式。然而，WebSocket 也有最严格的要求 ；只有最新版本的 Microsoft Internet Explorer、Google Chrome 和 Mozilla Firefox 彻底支持，其余浏览器如 Opera 和 Safari 只有部分实现。

• 服务器发送事件，也称为 EventSource （若是浏览器支持服务器发送事件，基本上除了 Internet Explorer 以外其余的浏览器都支持此功能）。

Comet 传输

下列传输基于 Comet Web 应用程序模型，在该模型中有一个浏览器或其余客户端维护着一个长时间的 HTTP 请求，服务器能够在客户端没有明确请求的状况下使用此请求将数据推送到客户端。

• Forever Frame（仅限 Internet Explorer）。Forever Frame 会建立一个隐藏的 IFrame，对服务器上的终结点发送一个不完整的请求。而后服务器不断地发送脚本到客户端，而且当即执行这些脚本，从而创建一个从服务器到客户端的单向实时链接。从客户端到服务器的链接使用的是不一样于服务器到客户端的链接，就像一个标准的 HTML 请求，对于每一个须要发送的数据都会建立一个新链接。

• Ajax 的长轮询。长轮询不会建立一个持久性链接，而是经过一个请求来轮询服务器，使链接保持打开状态直到服务器发出响应，这时候再关闭该链接，而后当即请求一个新的链接。这可能会在链接重置时产生一些延迟。

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

传输方式选择过程

下面的列表显示 SignalR 决定使用的传输方式的步骤。

1. 若是浏览器是 Internet Explorer 8 或更早版本，则使用长轮询。

2. 若是配置了 JSONP (即链接启动时jsonp参数设置为true ），则使用长轮询。

3. 若是正在使用跨域的链接 （即 SignalR 终结点和宿主页不在相同的域中），而且符合如下的条件将使用 WebSocket ：

   • 客户端支持 CORS （Cross-Origin Resource Sharing）。哪一种客户端支持 CORS 的详细信息，请参阅在 caniuse.com CORS.

   • 客户端支持 WebSocket

   • 服务器支持 WebSocket

   若是这些标准中的任何一条不知足，将使用长轮询。跨域链接的详细信息，请参阅如何创建跨域的链接.

4. 若是不配置为使用 JSONP 、链接不跨域而且客户端和服务器都支持，将使用 WebSocket 。

5. 若是客户端或服务器不支持 WebSocket，则尽可能使用服务器发送事件。

6. 若是服务器发送事件不可用，则将尝试使用 Forever Frame。

7. 若是 Forever Frame 不可用，则使用长轮询。

Monitoring 传输方式

您能够经过在您的应用程序hub启用日志记录，并在您的浏览器的控制台窗口中查看您的应用程序使用哪一种传输协议。

将下面的命令添加到您的客户端应用程序，以在浏览器中启用hub事件的日志记录：

$.connection.myHub.logging = true;

• 在IE中，经过按 f12 键，能够打开开发人员工具，而后单击控制台选项卡。

• 在 Chrome，按下 Ctrl + Shift + J 打开控制台。

经过控制台的日志记录，你就可以看到 SignalR 正在使用的传输协议。

指定传输协议

使用固定的传输协议须要必定的时间和客户端以及服务器的资源。若是客户端环境已知，那么当启动客户端链接时就能够指定传输协议。下面的代码段演示如何在已知客户端不支持任何其余协议时，直接在链接开始时就使用 Ajax 的长轮询：

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

若是你想要一个客户端按照特定顺序尝试传输方式，您能够指定尝试的顺序。下面的代码段演示如未尝试使用 WebSocket 而且在失败的时间去直接使用长轮询。

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

用于指定传输方式的字符串常量的定义以下：

• webSockets

• forverFrame

• serverSentEvents

• longPolling

链接和Hubs

SignalR API 包含两种客户端和服务器之间进行通讯的模型： 永久链接和Hubs。

链接表示为一个发送单个、 编组或广播消息的简单终结点。开发人员可使用持久性链接 API（在.NET 代码中由 PersistentConnection 类表示）直接访问 SignalR 公开的底层通讯协议的 。使用过基于链接 Api 好比wcf的开发人员会更加熟悉链接通讯模型。

Hub是基于链接 API的可是更高级别的通讯管线，它容许客户端和服务器上彼此直接调用方法。SignalR 可以很神奇地处理跨机器的调度，使得客户端可以调用在服务器上的方法就像轻松地调用本地方法，反之亦然。使用过基于远程调用的 Api好比 .NET Remoting的开发人员会更加熟悉 Hubs通讯模型。使用Hub还容许您将强类型的参数传递给方法而且绑定模型。

体系结构关系图

下面的关系图显示了Hub、 持续链接和用于传输的基础技术之间的关系。

Hub的工做原理

当服务器端代码调用客户端上的方法时，服务器发送一个数据包其中包含的要调用的方法的名称与参数（当被发送的方法参数包含对象时，它将被序列化为 JSON）。而后，客户端经过方法的名称在客户端代码中定义的方法中尝试匹配。若是匹配成功，则将执行客户端方法而且使用通过反序列化的参数数据。

可使用Fiddler之类的工具监视方法的调用。下图显示了Fiddler的日志窗格中从 SignalR 的服务器发送到 web 浏览器客户端的方法调用。从Hub发起调用的方法称为MoveShapeHub，被调用的方法是updateShape.

在此示例中，集线器名称使用参数H 标识；方法名称使用参数M标识，同时正在发送给该方法的数据使用参数A标识。生成此消息的应用程序是在High-Frequency Realtime教程中建立的。

选择通讯模型

大多数应用程序应使用Hub的 API。链接 API 可用于如下状况：

• 发送的实际消息须要指定的格式。

• 开发人员更喜欢使用消息传递和调度模型，而不是一个远程调用模型。

• 使用 SignalR移植的现有的应用程序正在使用消息传递模型。