SigalR简介

ASP.NET Core SignalR 是一个开放源代码库，可用于简化向应用添加实时 Web 功能。 实时 Web 功能使服务器端代码能够将内容推送到客户端。

适合 SignalR 的候选项：

• 需要从服务器进行高频率更新的应用。 示例包括游戏、社交网络、投票、拍卖、地图和 GPS 应用。
• 仪表板和监视应用。 示例包括公司仪表板、即时销售更新或旅行警报。
• 协作应用。 协作应用的示例包括白板应用和团队会议软件。
• 需要通知的应用。 社交网络、电子邮件、聊天、游戏、旅行警报和很多其他应用都需使用通知。

SignalR 提供用于创建服务器到客户​端远程过程调用 (RPC) 的 API。 RPC 从服务器端 .NET Core 代码调用客户端上的函数。提供多个受支持的平台​，其中每个平台都有各自的客户端 SDK。 因此，RPC 调用所调用的编程语言有所不同。

以下是 ASP.NET Core SignalR 的一些功能：

• 自动处理连接管理。
• 同时向所有连接的客户端发送消息。 例如聊天室。
• 向特定客户端或客户端组发送消息。
• 对其进行缩放，以处理不断增加的流量。

（SignalR 架图）

SignalR并不只是对WebSocket的封装，它支持多种服务器推送的实现方式，包括WebSocket、服务器发送事件（server-sent events）和长轮询。SignalR的JavaScript客户端会先尝试用WebSocket连接服务器；如果失败了，它再用服务器发送事件方式连接服务器；如果又失败了，它再用长轮询方式连接服务器。因此SignalR会自适应复杂的客户端、网络、服务器环境来支持服务器端推送的实现。

SignalR的JavaScript客户端和服务器之间会首先进行一次“协商”，确定采用什么协议进行通信，这个协商过程我们有时候也称之为“握手”。协商完成后，客户端和服务器之间再建立WebSocket通信。在协商的时候，服务器端就会为这个客户端后面的连接创建一些上下文信息，在建立WebSocket连接的时候就会使用服务器端创建的那些上下文信息，也就是说服务器端会在协商请求和WebSocket请求之间保持状态。在单台服务器下，这样处理没问题，但是如果在多台服务器组成的集群中，这样处理就会带来问题。比如，协商请求被服务器A处理，而接下来的WebSocket请求却被服务器B处理，由于服务器A中没有这个客户端在协商阶段的上下文信息，因此WebSocket请求处理失败了。

SignalR集群在环境中的问题

解决SignalR在多台服务器组成的集群中的这个问题，有两个方法：黏性会话和禁用协商。黏性会话（sticky session）指的是，我们对负载均衡服务器进行配置，以便把来自同一个客户端的请求都转发给同一台服务器。这样就避免了协商请求和WebSocket请求由不同服务器处理的问题。不过，由于网络协议的特点，负载均衡服务器只能根据网络请求的客户端IP地址来判断客户端的同一性，也就是只要网络请求的客户端IP地址一样，我们就认为是同一个客户端。我们知道，在很多网络中，很多的联网设备共享同一个公网IP地址，因此来自这些网络中的请求都会被认为来自同一个客户端而被转发到同一台服务器，特别是有的CDN环境会丢弃原始客户端的IP地址信息。这样就会导致来自客户端的请求无法被平均分配到服务器集群中。而且，在网站面对持续增长的、长时间连接的客户端请求（比如网络直播中的公屏聊天界面）时，也会造成请求无法均匀分布在集群服务器中的问题。

禁用协商的解决策略很简单，就是SignalR客户端不和服务器端进行网络协议的协商，而直接向服务器发出WebSocket请求。由于没有协商过程，因此也就没有两次请求状态保持的问题，而且WebSocket连接一旦建立后，在客户端和服务器端直接就建立了持续的网络连接通道，在WebSocket连接中的后续往返WebSocket通信都由同一台服务器来处理。这种方法的缺点就是对于不支持WebSocket的浏览器无法降级到服务器发送事件或长轮询的实现方式，不过这不是什么大问题，因为现在主流浏览器都支持WebSocket。在移动端，只有Android 4.0以下内置浏览器才不支持WebSocket，而这样老版本的设备在市场上已经很难见到了。在桌面端，只有IE9及以下浏览器才不支持WebSocket，不过SignalR的JavaScript客户端已经不支持IE全线产品了，因此如果读者的网站需要兼容IE，请不要使用SignalR。

在分布式环境中，还有其他问题需要解决。假设聊天室程序被部署在两台服务器上，客户端1、2连接到了服务器A上的ChatRoomHub，而客户端3、4连接到了服务器B上的ChatRoomHub，那么在客户端1发送群聊消息的时候，只有客户端1、2能够收到，而客户端3、4收不到；在客户端3发送群聊消息的时候，只有客户端3、4能够收到，而客户端1、2收不到。因为这两台服务器之间的ChatRoomHub没有通信。为了解决这个问题，我们可以让多台服务器上的集线器连接到一个消息队列中，通过这个消息队列完成跨服务器的消息投递。微软官方提供了用Redis服务器来解决SignalR部署在分布式环境中数据同步的方案—Redis backplane，其使用方法如下。

SignalR实践指南

Hub类的生命周期是瞬态的，也就是每次调用集线器的时候都会创建一个新的Hub类实例，因此我们不要在Hub类中通过属性、成员变量等方式保存状态。如果服务器的压力比较大，建议把ASP.NET Core程序和SignalR服务器端部署到不同的服务器上，以免它们互相干扰。如果需要在客户端连接到集线器或者在集线器断开的时候执行代码，我们可以覆盖Hub类中的OnConnectedAsync和OnDisconnectedAsync方法。

SignalR除了提供了供浏览器使用的JavaScript客户端，官方还提供了.NET、Java客户端，开源社区还提供了C++、Swift等语言的客户端，因此我们也可以编写WPF、WinForm、Android、iOS等程序来连接服务器端。SignalR的JavaScript客户端不支持IE，因此如果读者的项目需要兼容IE，请不要使用SignalR。ASP.NET Core把SignalR底层的WebSocket封装为了单独的组件，我们可以使用这个组件来编写原生的WebSocket程序，这样我们就可以在IE10、IE11等不被SignalR支持的浏览器中进行服务器消息推送的开发。因为Windows 10、Windows 11等是桌面操作系统，这些桌面操作系统上的IIS有10个并发连接的限制，如果我们使用这些操作系统测试SignalR，就会发现SignalR的服务器端并发能力非常差，所以这些桌面操作系统只能作为开发机使用。在生产环境中，请使用Windows Server系列操作系统或者使用Linux。