SignalR简介（實時通信）

最新推荐文章于 2023-02-28 15:00:14 发布

tulasgao

最新推荐文章于 2023-02-28 15:00:14 发布

阅读量1.2k

点赞数

分类专栏： .net 文章标签： SignalR

.net 专栏收录该内容

33 篇文章 0 订阅

订阅专栏

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启用日志记录，并在您的浏览器的控制台窗口中查看您的应用程序使用哪种传输协议。

连接和Hubs

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

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

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