SignalR：协议协商

1.推送方式

SignalR其实并不只是对WebSocket的封装，它支持多种服务器推送的实现方式，包括WebSocket、服务器发送事件（server-sent events）和长轮询。

SignalR的JavaScript客户端会先尝试用WebSocket连接服务器；如果失败了，它再用服务器发送事件方式连接服务器；如果又失败了，它再用长轮询方式连接服务器。因此SignalR会自适应复杂的客户端、网络、服务器环境来支持服务器端推送的实现。

2.协商的过程

我们来看一下这个协商的过程，打开浏览器的【开发人员工具】，单击【网络】标签页，然后刷新聊天室页面，可以看到列表中有如图所示的网络请求记录。

可以看到，浏览器首先向服务器发出了一个negotiate请求，用于询问服务器“你支持什么协议”。单击这个请求，查看详细的协商响应报文体。协商的服务器响应如下代码所示。

---

{"negotiateVersion":1,"connectionId":"3xujrhX_X8_hiMXS04357A","connectionToken":"795fo3xSungpuvZmyeDUEg",``"availableTransports":[{"transport":"WebSockets","transferFormats":["Text","Binary"]},{"transport":"ServerSentEvents","transferFormats":["Text"]},{"transport":"LongPolling","transferFormats":["Text","Binary"]}]}

协商响应报文体中的connectionId表示服务器端为连接分配的ID，这个ID与我们在服务器中通过Context.ConnectionId取到的值是一致的；协商响应报文体中的availableTransports代表服务器端支持的网络协议，我们可以看到WebSocket、ServerSentEvents、LongPolling这3种协议都被服务器端支持，由于Chrome浏览器也支持WebSocket，因此JavaScript客户端发出ChatRoomHub请求，单击查看详细信息。

从图可以看出：

• 浏览器发送的是以wss://开头的请求，这是WebSocket协议请求。WebSocket和HTTP是不同的协议，但是这里我们发出的HTTP请求和WebSocket请求都使用了相同的网络端口，这是因为ASP.NET Core内部会判断请求的类型，然后根据请求报文的特点来把不同的请求分别转发给HTTP处理程序或者WebSocket处理程序。
• WebSocket请求报文头中的“Upgrade:websocket”表示客户端向服务器发起建议“我们把通信请求切换为WebSocket通信吧”，服务器发送回来的响应报文头中的“Upgrade:websocket”以及状态码101表示“切换到WebSocket通信”成功。之后，SignalR客户端和服务器之间的通信就使用WebSocket协议了。

我们在聊天界面中发送和接收WebSocket消息的通信过程在【开发人员工具】的【网络】标签页中是看不到的。我们需要单击ChatRoomHub请求，也就是wss://的请求，然后在请求的详情页中的【消息】标签页中，就能看到WebSocket的消息收发情况。

3.多服务下器面临的问题

SignalR的JavaScript客户端和服务器之间会首先进行一次“协商”，确定采用什么协议进行通信，这个协商过程我们有时候也称之为“握手”。协商完成后，客户端和服务器之间再建立WebSocket通信。

在协商的时候，服务器端就会为这个客户端后面的连接创建一些上下文信息，在建立WebSocket连接的时候就会使用服务器端创建的那些上下文信息，也就是说服务器端会在协商请求和WebSocket请求之间保持状态。
在单台服务器下，这样处理没问题，但是如果在多台服务器组成的集群中，这样处理就会带来问题。比如，协商请求被服务器A处理，而接下来的WebSocket请求却被服务器B处理，由于服务器A中没有这个客户端在协商阶段的上下文信息，因此WebSocket请求处理失败了。

4.如何解决

解决SignalR在多台服务器组成的集群中的这个问题，有两个方法：黏性会话和禁用协商。

黏性会话（sticky session）指的是，我们对负载均衡服务器进行配置，以便把来自同一个客户端的请求都转发给同一台服务器。
这样就避免了协商请求和WebSocket请求由不同服务器处理的问题。不过，由于网络协议的特点，负载均衡服务器只能根据网络请求的客户端IP地址来判断客户端的同一性，也就是只要网络请求的客户端IP地址一样，我们就认为是同一个客户端。但在很多网络中，很多的联网设备共享同一个公网IP地址，因此来自这些网络中的请求都会被认为来自同一个客户端而被转发到同一台服务器。这样就会导致来自客户端的请求无法被平均分配到服务器集群中。

禁用协商的解决策略很简单，就是SignalR客户端不和服务器端进行网络协议的协商，而直接向服务器发出WebSocket请求。
由于没有协商过程，因此也就没有两次请求状态保持的问题，而且WebSocket连接一旦建立后，在客户端和服务器端直接就建立了持续的网络连接通道，在WebSocket连接中的后续往返WebSocket通信都由同一台服务器来处理。这种方法的缺点就是对于不支持WebSocket的浏览器无法降级到服务器发送事件或长轮询的实现方式，不过这不是什么大问题，因为现在主流浏览器都支持WebSocket。

5.跳过协商，直接发送WebSocket请求

禁用协商的使用方式很简单，我们只要在SignalR的JavaScript客户端的withUrl函数中设置选项即可。

const options = {
  skipNegotiation: true,
  transport: signalR.HttpTransportType.WebSockets,
};
connection = new signalR.HubConnectionBuilder() // 创建从客户端到服务器端的连接
  .withUrl("https://localhost:7002/Hubs/ChatRoomHub",options) // 设置服务器端集线器的地址
  .withAutomaticReconnect() // 设置自动重连机制
  .build(); // 构建完成

设置的skipNegotiation:true选项表示“跳过协商”，而transport选项表示强制采用的通信方式，我们这里把通信方式强制设置为WebSocket。

修改前端页面后，刷新浏览器，我们再查看【开发人员工具】中的【网络】，会发现，网络通信中已经看不到协商的请求了，浏览器直接发出的就是WebSocket请求。

本文学习参考自：ASP.NET Core技术内幕与项目实战