1. 当前是否可在不使用粘性会话的情况下，通过WebSocket使用Core SignalR？ #

默认情况下，直接用WebSocket传输的ASP.NET Core SignalR 确实需要粘性会话——这是WebSocket协议的特性决定的：它是持久化的双向长连接，客户端和服务器建立连接后，所有后续的WebSocket帧必须发送到同一个服务器实例，否则连接会直接中断。

不过有两种成熟方案可以绕开应用层的粘性会话限制：

• 使用Azure SignalR Service：这个服务作为中间代理层，客户端直接连接到Azure的SignalR节点，你的应用服务器只需要处理业务逻辑、收发消息，不需要维护持久连接。这种情况下负载均衡器可以自由分发请求到任意应用服务器，完全不用配置粘性会话。
• 自建分布式消息背板（如Redis、SQL Server）+ 负载均衡连接级亲和性：WebSocket连接仍绑定单台服务器，但服务器间通过背板同步状态和消息。此时可以用负载均衡器的连接级亲和性（比如基于源IP或WebSocket连接ID）替代传统Cookie粘性，这也算脱离了应用层粘性会话的限制。

2. 若当前无法实现，该功能预计何时可投入生产环境？目前是否有简易临时解决方案？ #

首先得明确：官方目前没有计划让原生WebSocket传输脱离对会话亲和性的依赖——这是WebSocket协议本身的设计限制，并非SignalR的功能缺陷。

如果暂时没法用上述方案，给你几个简易临时解决办法：

• 配置负载均衡器的连接级粘性：大部分现代负载均衡器（Nginx、AWS ALB、Kubernetes Ingress等）都支持基于WebSocket连接的会话亲和性，不用在应用层设置Cookie，只需要在负载均衡器层面配置即可，成本很低。
• 临时切换传输方式：比如用Server-Sent Events（SSE）或Long Polling，这两种传输不需要粘性会话，但性能和实时性不如WebSocket，适合对实时性要求不高的场景过渡。
• 单服务器部署：如果业务规模不大，暂时用单台服务器部署SignalR服务，自然就不用考虑粘性会话问题，这是最直接的临时方案。

内容的提问来源于stack exchange，提问作者Jawahar