SignalR用于大用户群的聊天

您可以相当容易地禁用windows服务器上的所有DoS攻击保护。然而，这并不一定能解决你的问题。10万个连接需要多个服务器才能完成这样的工作。

你的第一个限制是，每个IP地址，你只有大约65,000个可能的tcp端口服务连接(65,535，但较少保留端口等四舍五入)。所以你要么需要一个有多个IP地址的大型服务器(可能不可靠，并且在你的系统/应用程序中存在单点故障)，要么需要多个服务器在某种负载均衡器后面。

同样使用长轮询，当每个长轮询连接结束并开始一个新的连接时，您会看到连接的一致"翻转"。TCP端口不会立即被重用，而最快的可配置TCP定时等待延迟是30秒。所以即使是65,000个连接也是不现实的，我将其减半只是为了端口重用。然后，您需要考虑到达该服务器的任何其他http请求，以获取网页、rest api或其他静态资源。然后考虑处理器/内存为保存/格式化数据必须进行的任何其他处理。所以我想再减少一半。我认为每个服务器15000个客户机是一个现实的最大值。因此，对于100,000个用户，您可能需要在负载均衡的集群中最少使用7台服务器。

最后我检查了SignalR在这样的多服务器环境中不工作。同样，AJAX或任何其他"频繁刷新"方法在可用tcp端口/套接字数量等方面也会受到类似的物理限制。你不可能在一台服务器上为10万个客户端提供这样高频率的http请求。

我已经在Amazon EC2的多个服务器上使用WebSync for ASP.net进行了大量的大规模负载测试。我在FrozenMountain工作，去年我的一项工作是在Amazon EC2 Cloud上做一些多服务器负载平衡测试。Amazon云服务提供了一个很好的粘性负载平衡器和简单的服务器复制以供测试。在"实验室条件"(专用服务器不做其他事情)下，我们可以在Amazon的"大型实例"上超过20,000个客户端，这是一个拥有7.5gb ram的四核服务器。

值得指出的是，最新的Server/IIS/Websync支持WebSockets，这将有助于减少端口周转和重用，因为每个客户端都可以维护一个持久的套接字连接到web服务器。这可能会增加每台服务器的客户机数量。因此，根据websocket兼容浏览器/客户端的采用率，你可能可以从7台服务器集群减少到4-5台服务器。(基于Web浏览器的JavaScript客户端不会有很高的采用率，iphone或Android设备等本地设备都支持websocket，所以你马上就能看到它的全部好处)。如果客户端不支持web套接字，WebSync将从WebSockets返回到长轮询失败。