在3x Windows Server 2012 R2群集上看到WebSocket连接没有被处置/关闭的一些问题。
最终服务器不再允许连接，并且也开始在serverSentEvents上失败。
当查看SignalR性能计数器时，似乎WebSocket计数器不会因“连接电流”下降而下降。
现在我在三台服务器中的两台服务器上看到这个，不久之后服务器重新启动，所以数字不是那么高：
Server #1:
Connections Current: 8
Connections Current WebSockets: 131
Connections Disconnected: 202
Server #2:
Connections Current: 6
Connections Current WebSockets: 5
Connections Current ServerSentEvents: 1
Server #3:
Connections Current: 3
Connections Current WebSockets: 101
Connections Disconnected: 101
目前有少量（少数）用户，因此数量不会增长，但是当流量增加时，它最终会停止接受WebSocket连接。
SignalR（v2.2.1）使用OWIN托管，并且该进程在Azure Service Fabric上运行。
尝试搜索故障排除和其他具有相同问题但未找到任何解决方案或潜在问题的原因。根据我从穿孔计数中可以理解的情况，似乎触发并正确注册了断开连接事件，但保留了实际连接。
编辑＃1（2017-03-24）：
使用来自Sysinternals的TCPView进行一些监视，它确实报告与当前连接完全相同的WebSockets连接，因此问题可能不会耗尽系统资源。
正如我所提到的，我们在perf计数器中获得断开连接的事件，但“Connections Current WebSockets”的数量比实际连接高很多。当用户连接或断开时，它有时会丢一两个，所以它不仅仅是增长和增长，而是不会下降太多，现在当前的websockets连接数与今天的最大数量，状态相同： / p>
Server #1:
Current: 9
WebSockets: 151
Server #2:
Current: 6
WebSockets: 9
Server #3:
Current: 4
WebSockets: 120
编辑＃2（2017-03-24）：
将Azure Service Fabric从5.4.145升级到5.4.164到5.5.216，最后一次更新重新启动了所有VM。经过几个小时的运行后，似乎“Connections Current”和“Connections Current WebSockets”报告了所有3个VM的完全相同的数字。最新版本中至少有一个WCF套接字泄漏错误修复。
在我们获得更多用户和用户之后，我将在周末更新这篇文章。
编辑＃3（2017-03-28）：
将群集项目升级部署到Service Fabric VM后，“Connections Current WebSockets”再次报告高于“Connections Current”数字。
Server #1:
Connections Current: 8
Connections Current WebSockets: 31
其他两个报告两个指标的数字相同。
编辑＃4（2017-04-18）
删除了Redis作为SignalR的背板，并更改了代码以调用SignalR的每个单独实例，而不是依赖Backplane逻辑。这似乎消除了我们的稳定性问题，但我仍然看到活动连接和Web套接字连接的差异。现在从一台服务器，我看到6个当前连接，但Web套接字当前返回8。
在预览中发布SignalR 2.2.2时，可能会尝试重新引入Redis：“使Redis Scaleout更可靠的一系列工作”。
https://blogs.msdn.microsoft.com/webdev/2017/04/13/announcing-signalr-2-2-2-preview-1/