MSDN文档似乎没有很好地涵盖ASP.net 4.5对HTML5 WebSockets协议的支持！
这就是我正在寻找的：
更新：
来自Flash RTMP套接字的请求（WebSocket的替代方法）可以在Adobe Media Server应用程序服务器上进行良好的配置。在应用程序或IIS 8配置中，ASP.net是否有任何请求数、理想时间、块大小等方面的配置？
致关注此事者：
WebSocket connections are initiated by a HTTP
handshake, hence some of the IIS throttles that apply to HTTP requests
will also apply to WebSockets.
appConcurrentRequestLimit in the IIS Configuration can be used to set the maximum concurrent requests per application:
<serverRuntime appConcurrentRequestLimit="250000" />
Maximum concurrent connections to an ASP.net 4 Web Application can be set with ApplicationPool's maxConcurrentRequestsPerCPU property:
<system.web> <applicationPool maxConcurrentRequestsPerCPU="20000" /> </system.web>
When the total amount of connections exceed the
maxConcurrentRequestsPerCPU setting, ASP.NET will start throttling requests using a queue. To control the size of the queue, you can
tweak the machine.config requestQueueLimit:
<processModel autoConfig="false" requestQueueLimit="250000" />
The following performance counters should be considered while conducting concurrency testing and adjusting the optimum settings detailed above:
编辑：此答案与 .Net 4.0 或更早版本相关，其中 WebSockets 必须由您自己实现（.Net 4.5 + IIS 为您提供解决方案）。因此，它仅涉及在 TCP 层之上实现 WebSockets 的自己的实现。
.Net 可处理的套接字数量基于系统和您提供套接字的方式。请阅读此文档：http://msdn.microsoft.com/en-us/library/windows/desktop/ms739169%28v=vs.85%29.aspx
WebSockets 实现使用异步方式服务数据的接收和发送。这使它们非常可扩展，并且不需要每个连接大量的内存。因此，连接的套接字数量基于应用程序逻辑与每个连接和硬件的复杂性。在大多数情况下，您将面临处理应用程序逻辑的性能问题，然后才会面临仅基于连接的套接字的性能问题。
如果您正在使用基于原始 TCP 套接字的自己的实现，则此信息将适用：
在单个网络设备上，您可以绑定少于65k个套接字。这是接受连接的侦听套接字。在通常的服务器实现中，您几乎永远不会使用超过几个或者几十个套接字来接受连接。
客户端套接字可以达到您的实现和内存所能处理的数量。
有许多方法可以服务套接字，使您能够处理更多的套接字。以下是一些亮点：
阻塞式服务套接字将延迟为每个套接字提供服务。同时，客户端套接字的非阻塞读取将仅用于检查是否有任何可用数据。对于大量的套接字，这可能非常昂贵。
每个客户端套接字一个线程将使用大量内存（每个线程超过1MB），这将允许您在物理系统上拥有少量套接字。
我认为最好的选择之一是使用异步套接字。这允许您拥有数千个套接字，并且通过良好的实现，甚至可以在单个服务器系统上拥有数万个套接字。