使用 ASP.NET (4.8) 的负载平衡环境中的 SignalR 连接问题
- Dotnet Framework：4.8
- SignalR nuget 包：2.4.0
- 使用 Signalr 的 Angular 客户端：“^2.4.2”，
- 负载均衡器后面的两个节点应用程序服务器。
- 在 IIS 上配置的 Web 套接字支持。 （Windows Server 2016 上的 IIS 最新版本）
- Web 套接字是客户端代码中存在的唯一传输协议
- IIS
- SQL Server-2016 上托管的 ASP.NET Web API 应用程序作为代理传递数据更改通知
- 使用 ConnectionId
系统 将通知传递给请求客户端适用于单节点环境。 Chrome 的网络选项卡显示客户端具有以下端点通信
- /signalr/negotiate?clientProtocol=2.1&connectionData=d&_=xtz -[200-OK]
- /signalr/start?transport=webSockets&clientProtocol=2.1&connectionToken=t& _=abc [200-OK]
但是，当我们尝试连接到负载均衡器下的 appServer 时， 我们面临客户端连接到应用程序服务器的问题，
当通过 Fiddler 拦截负载平衡环境的请求时，系统显示以下日志。
- /signalr/negotiate?clientProtocol=2.1&connectionData=d&_=xtz -[200-OK]
- /signalr/start?transport=transport=serverSentEvents&clientProtocol=2.1&connectionToken=t&_=abc -[404-未找到]
- /signalr/start?transport=transport=longPolling&clientProtocol=2.1&connectionToken=t&_=abc -[404-NOTFOUND]
- /signalr/abort?transport=longPolling&clientProtocol=2.11&connectionToken=t&_=abc -[200]
我感觉 LoadBalancer 导致了这个问题。不赞成使用坚持会话 有人可以告诉我需要做什么来解决这个问题吗？
问候
- Dotnet Framework: 4.8
- SignalR nuget package: 2.4.0
- Angular client using Signalr: "^2.4.2",
- Two nodes application server behind load balancer.
- Web socket support configured on IIS. (IIS latest version on Windows Server 2016)
- Web socket is the only transport protocol present in the client side code
- ASP.NET Web API application hosted on IIS
- SQL Server-2016 as broker to pass notification on Datachange
- Passing notification to requesting client using connectionId
System works well for a single node environment.
Chrome's network tab shows client has following endpoint communication
- /signalr/negotiate?clientProtocol=2.1&connectionData=d&_=xtz -[200-OK]
- /signalr/start?transport=webSockets&clientProtocol=2.1&connectionToken=t&_=abc [200-OK]
However, when we try to connect to appServer under a Load Balancer,
We are facing an issue of client connection to the app server
System shows the below logs when requests are intercept via Fiddler for Load Balanced environment.
- /signalr/negotiate?clientProtocol=2.1&connectionData=d&_=xtz -[200-OK]
- /signalr/start?transport=transport=serverSentEvents&clientProtocol=2.1&connectionToken=t&_=abc -[404-NOTFOUND]
- /signalr/start?transport=transport=longPolling&clientProtocol=2.1&connectionToken=t&_=abc -[404-NOTFOUND]
- /signalr/abort?transport=longPolling&clientProtocol=2.11&connectionToken=t&_=abc -[200]
I've a feeling of LoadBalancer causing this issue.Not in favour of using stick session
Can someone please tell what needs to be done to address this issue.
Regards
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于 Web 套接字本质上是粘性的（负载平衡集中的一个特定客户端和一台特定服务器之间有一个开放通道），因此您必须在负载平衡器中使用粘性会话。
至少如果您希望开始调用与所使用的协商调用到达相同的服务器节点。
其他任何事情都就像询问随机虚假错误一样。
Since web-socket in its nature is sticky (you have an open channel between one specific client and one specific server in the load-balanced-set) you MUST use sticky session in Load-balancer.
At least if you want the start call to reach the same server-node as negotiate calls used.
Anything else is like asking for random spurious errors.