SignalR简介

什么是SignalR？

ASP.NET SignalR是ASP.NET开发人员的库，它简化了向应用程序添加实时Web功能的过程。实时Web功能是指服务器代码在连接的客户端可用时立即将内容推送到连接的客户端，而不是让服务器等待客户端请求新数据。

SignalR可用于向ASP.NET应用程序添加任何类型的“实时”Web功能。虽然聊天经常被用作示例，但您可以做更多的事情。每当用户刷新网页以查看新数据，或者页面实现长轮询以检索新数据时，它都是使用SignalR的候选者。示例包括仪表板和监视应用程序，协作应用程序（如同时编辑文档），作业进度更新和实时表单。

SignalR还支持全新类型的Web应用程序，这些应用程序需要来自服务器的高频更新，例如实时游戏。

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

SignalR自动处理连接管理，并允许您同时向所有连接的客户端广播消息，如聊天室。您还可以向特定客户端发送消息。客户端和服务器之间的连接是持久的，不像传统的HTTP连接，它是为每次通信重新建立的。

SignalR支持“服务器推送”功能，其中服务器代码可以使用远程过程调用（RPC）调用浏览器中的客户端代码，而不是当今Web上常见的请求 - 响应模型。

SignalR应用程序可以使用Service Bus，SQL Server或Redis扩展到数千个客户端。

SignalR是开源的，可通过GitHub访问。

SignalR和WebSocket

SignalR在可用的情况下使用新的WebSocket传输，并在必要时回退到旧的传输。虽然您当然可以直接使用WebSocket编写应用程序，但使用SignalR意味着您需要实现许多额外的功能。最重要的是，这意味着您可以编写应用程序代码以利用WebSocket，而无需担心为旧客户端创建单独的代码路径。SignalR还使您不必担心WebSocket的更新，因为SignalR已更新以支持底层传输的更改，从而为您的应用程序提供跨WebSocket版本的一致界面。

传输和回退

SignalR 是一种抽象，通过某些要求进行客户端和服务器之间的实时工作的传输。 SignalR 连接作为 HTTP，启动，然后升级到 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 请求请求它。
永久帧（适用于 Internet Explorer)。 永久帧创建隐藏的 IFrame 的未完成的服务器上的终结点向发出请求。 服务器然后不断会脚本发送到客户端立即执行，提供从服务器到客户端的单向实时连接。 从客户端与服务器的连接使用单独的连接从服务器到客户端连接和像标准的 HTTP 请求，为每个条需要发送的数据创建新的连接。
Ajax 长轮询。 长轮询不创建持久性连接，但改为轮询具有保持打开状态直到服务器做出响应，此时将关闭连接，并立即请求新的连接的请求的服务器。 连接重置时，这可能会造成一些延迟。
有关哪些传输受支持的配置下的详细信息，请参阅支持的平台。

传输选择过程

以下列表显示 SignalR 使用来确定使用哪个传输的步骤。

1. 如果浏览器是 Internet Explorer 8 或更早版本，则使用长轮询。
2. 如果配置 JSONP (即jsonp参数设置为true启动连接时)，使用长轮询。
3. 如果操作正在进行的跨域连接，（即，如果 SignalR 终结点不在托管的页面所在的域中），然后 WebSocket 将在满足以下条件：

• 客户端支持 CORS （跨域资源共享）。 在其的客户端支持 CORS 的详细信息，请参阅CORS 在 caniuse.com。
• 客户端支持 WebSocket
• 服务器支持 WebSocket
  如果不满足任何这些条件，则将使用长轮询。 有关跨域连接的详细信息，请参阅如何建立跨域连接。

1. 如果未配置 JSONP 并且连接不跨域，如果客户端和服务器支持它，则将使用 WebSocket。
2. 如果客户端或服务器不支持 WebSocket，如果可用，则使用服务器发送事件。
3. 如果服务器发送事件不可用，请尝试使用永久帧。
4. 如果永久帧失败，则使用长轮询。

监视传输

您可以确定应用程序在中心上的日志记录和在浏览器中打开控制台窗口，从而使用什么传输。
若要启用浏览器中的中心的事件日志记录，客户端应用程序中添加以下命令：

$.connection.hub.logging = true;

• 在 Internet Explorer 中，通过按 F12 打开开发人员工具，并单击控制台选项卡。
• 在Chrome中，按Ctrl + Shift + J打开控制台。
• 打开控制台并启用日志记录后，您将能够看到SignalR正在使用哪种传输。

指定在传输协议

协商传输只占用一定的时间和客户端/服务器的资源。 如果已知的客户端功能，则传输可以指定启动客户端连接时。 下面的代码段演示如何启动使用 Ajax 长轮询传输方式，因为如果它已知客户端不支持任何其他协议将使用的连接：
connection.start({ transport: 'longPolling' });
如果你想要尝试按顺序的特定传输的客户端，可以指定回退的顺序。 下面的代码段演示尝试 WebSocket，并且如果没有问题，，直接转到长轮询。
connection.start({ transport: ['webSockets','longPolling'] });

用于指定传输中的字符串常数定义，如下所示：

• webSockets
• foreverFrame
• serverSentEvents
• longPolling
  

  连接和集线器

  SignalR API 包含客户端和服务器之间进行通信的两个模型： 永久连接和中心。
  连接表示用于发送单个收件人、 分组或广播消息的简单终结点。 开发人员直接访问 SignalR 公开低级别通信协议 （由 PersistentConnection 类的.NET 代码中表示） 的持久性连接 API 提供。 使用连接的通信模型都会熟悉的开发人员已使用基于连接的 Api，如 Windows Communication Foundation。
  中心是基于连接 API，从而使您的客户端和服务器直接相互调用方法的更多高级管道。 SignalR 处理跨计算机界限调度像变魔术一样，是通过允许客户端在服务器上调用方法，以轻松地为本地方法，反之亦然。 使用中心的通信模型都会熟悉的开发人员已使用远程调用 Api，如.NET 远程处理。 使用中心还允许您将强类型化的参数传递给方法，使模型绑定。

体系结构关系图

下图显示了中心、 永久连接和用于传输的基础技术之间的关系。

中心的工作原理

服务器端代码在客户端上调用的方法时发送一个数据包，在活动传输包含名称和要调用的方法的参数 （作为方法参数发送一个对象，它使用 JSON 序列化）。 然后，客户端匹配到客户端代码中定义的方法的方法名称。 如果没有匹配项，将使用反序列化的参数数据执行客户端方法。
可以使用像这样的工具监视方法调用Fiddler。 下图显示了从 SignalR 服务器发送到 web 浏览器客户端在 Fiddler 日志窗格中的方法调用。 方法调用从集线器调用发送MoveShapeHub，并正在调用的方法称为updateShape。

显示SignalR交通的提琴手日志看法

在此示例中，使用H参数标识集线器名称; 使用M参数标识方法名称，并使用参数标识发送到方法的A数据。生成此消息的应用程序是在高频实时教程中创建的。

选择通信模型

大多数应用程序应使用中心 API。 可在以下情况下使用连接 API:

• 需要指定将发送的实际消息的格式。
• 开发人员倾向于使用消息传送与调度模型而不是远程调用模型。
• 使用消息传送模型的现有应用程序移植以使用 SignalR。