我想了解如何最好地设计一个IIS/ASP。基于。NET的websocket应用程序，特别是关于并发限制。
我已经阅读了所有关于IIS/ASP的文献。NET关于"并发Websocket连接"以及如何调整各种值-然而，当谈到Websocket时，"并发"的定义是什么?如果我打开了一个websocket，而它处于空闲状态，这是"使用"连接吗?闲置的websockets是否计入连接使用总数，还是只在发送/接收消息时才计算?
我希望在任何时候都有一个非常高(成千上万)的websockets打开，但是会有很少的消息被发送，也许每分钟几个，并且它们总是服务器->客户端(并且是一个单一的，特定的客户端，而不是广播)。这样的安排是否会引导我走上特定的实施路线?
似乎SignalR集线器可能是过度的，我不需要客户端不支持websockets的回退，我只需要维护每个客户端连接的句柄，这样当我的系统"决定"发送消息到特定的客户端时，它可以适当地路由它。
我引用的文档:
- https://github.com/SignalR/SignalR/wiki/Performance
- http://www.asp.net/signalr/overview/performance/scaleout-in-signalr
谢谢
然而，当谈到websockets时，什么是定义"并发"?如果我打开了一个websocket，而它处于空闲状态，则是"利用"联系?空闲的websockets计数对连接使用总数，或者仅在消息被使用时才计数发送/接收吗?
对，一个空闲的打开连接并不会消耗太多的资源，除了TCP keepalive和可能的协议和/或应用程序级别的ping/pong，如果你的服务器支持它们。更重要的是，由于Websockets是面向连接的，你可能也持有一些与连接相关的状态(用户对象、用户数据等)
我期望有一个非常高(成千上万)的websockets数量在任何时候打开，但是会有很少的消息发送，也许每分钟几个，它们将始终是服务器->客户端(和发送到单个特定客户端，而不是广播)。/应该这安排让我选择了什么具体的实施路线?
是的，到不使用SignalR的路线:SignalR Scale-out(检查限制部分)。直接使用WebSockets，并使用一个允许智能路由的框架来实现你自己的消息传递后端，比如RabbitMQ。您不希望使用基本上对所有节点进行"扇形输出"的背板，特别是如果数据是每个用户的。
SignalR是一个polyfill，一个暂时的框架，直到WebSockets被广泛支持的那一天…这已经发生了。还忘了提一下，WebSockets从Windows server 2012开始可用:)