每个TCP连接本身在服务器资源方面消耗非常少。通常设置连接可能很昂贵，但是保持空闲连接几乎是免费的。通常遇到的第一个限制是可以同时打开的文件描述符(套接字消耗文件描述符)的最大数量。这通常默认为1024，但可以很容易地配置更高。

曾经尝试过配置一个Web服务器来支持数万个同时发生的AJAX客户端？将这些客户端更改为WebSockets客户端，这可能是可行的。

HTTP连接，虽然他们不创建打开的文件或消耗端口号很长一段时间，是更昂贵的几乎所有其他方式：

>每个HTTP连接都带有很多行李，大多数时间没有使用：Cookie，内容类型，用户名长度，用户代理，服务器ID，日期，最后修改等等。一旦建立了WebSockets连接，应用程序所需的数据需要来回发送。
>通常，HTTP服务器配置为记录占用磁盘和cpu时间的每个HTTP请求的开始和完成。它将成为记录WebSockets数据的开始和完成的标准，但是当WebSockets连接进行双工传输时，将不会有任何额外的日志开销(除非应用程序/服务，如果它被设计为这样做)。
>通常，使用AJAX的交互式应用程序连续轮询或使用某种长轮询机制。 WebSockets是一个更清洁(和更低的资源)的方式做一个更多的事件的模型，当服务器和客户端有通知时，通过现有的连接报告。
>生产中大多数流行的Web服务器都有一个用于处理HTTP请求的进程(或线程)池。随着压力的增加，池的大小将增加，因为每个进程/线程一次处理一个HTTP请求。每个额外的进程/线程使用更多的内存，并且创建新的进程/线程比创建新的套接字连接(这些进程/线程仍然需要做的)昂贵得多。大多数流行的WebSockets服务器框架是事件的路线，往往规模和表现更好。

WebSockets的主要优点是交互式Web应用程序的延迟连接更低。它将比HTTP AJAX / long-poll(假设应用程序/服务器设计正确)更好地扩展和消耗更少的服务器资源，但IMO较低的延迟是WebSockets的主要优点，因为它将启用不可能的新类Web应用程序与当前的开销和AJAX / long-poll的延迟。

一旦WebSockets标准变得更加完善，并且有更广泛的支持，将它用于大多数需要与服务器频繁通信的新交互式Web应用程序将是有意义的。对于现有的交互式Web应用程序，它将真正取决于当前的AJAX / long-poll模式是如何工作。转换的努力将是不平凡的，所以在许多情况下成本只是不值得的好处。

更新：

有用的链接：600k concurrent websocket connections on AWS using Node.js