我很好奇是否有人有关于HTML WebSockets可伸缩性的任何信息.对于我所阅读的一切,似乎每个客户都将与服务器保持开放的通信线路.我只是想知道如何扩展以及服务器可以处理多少个打开的WebSocket连接.也许将这些连接保持开放并不是现实中的问题,但感觉就像是这样.
kan*_*aka 199
在大多数情况下,WebSockets可能比AJAX/HTML请求更好地扩展.但是,这并不意味着WebSockets可以替代AJAX/HTML的所有用途.
每个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 /长轮询的当前开销和延迟.
一旦WebSockets标准变得更加完善并得到更广泛的支持,将它用于需要经常与服务器通信的大多数新的交互式Web应用程序是有意义的.对于现有的交互式Web应用程序,它实际上取决于当前AJAX/long-poll模型的工作情况.转换的努力将是非平凡的,因此在许多情况下,成本不值得获益.
更新:
有用链接:使用Node.js在AWS上进行600k并发websocket连接
小智 35
只是澄清一下:服务器可以支持的客户端连接数与此方案中的端口无关,因为服务器[通常]只在一个端口上侦听WS/WSS连接.我认为其他评论者的意思是文件描述符.您可以将文件描述符的最大数量设置得相当高,但是您必须注意每个打开的TCP/IP套接字的套接字缓冲区大小.这里有一些额外的信息:https://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system
至于通过WS与HTTP减少延迟,这是正确的,因为除了初始WS握手之外不再解析HTTP头.此外,随着越来越多的数据包被成功发送,TCP拥塞窗口变宽,有效地降低了RTT.
Arn*_*hez 13
任何现代的单一服务器都能够同时为数千个客户端提供服务.它的HTTP服务器软件就是面向事件驱动(IOCP)(我们不再是旧的Apache一个连接=一个线程/进程方程式).甚至Windows内置的HTTP服务器(http.sys)也是面向IOCP的,并且非常高效(在内核模式下运行).从这个角度来看,WebSockets和常规HTTP连接之间的扩展不会有很大差异.一个TCP/IP连接使用少量资源(远远少于一个线程),并且现代操作系统针对处理大量并发连接进行了优化:WebSockets和HTTP只是OSI 7应用层协议,继承自此TCP/IP规范.
但是,从实验中,我看到了WebSockets的两个主要问题:
对于任何项目,我都会推荐以下内容:
- 仅使用WebSockets进行客户端通知(使用回溯机制进行长轮询 - 周围有很多库);
- 对所有其他数据使用RESTful/JSON,使用CDN或代理进行缓存.
实际上,完整的WebSockets应用程序不能很好地扩展.只需将WebSockets用于它们的设计目的:将通知从服务器推送到客户端.
关于使用WebSockets的潜在问题:
1.考虑使用CDN
今天(差不多4年后),Web扩展涉及使用内容交付网络(CDN)前端,不仅适用于静态内容(html,css,js),还适用于您的(JSON)应用程序数据.
当然,您不会将所有数据都放在CDN缓存中,但实际上,许多常见内容不会经常更改.我怀疑80%的REST资源可能会被缓存...即使是一分钟(或30秒)的CDN到期超时也足以让您的中央服务器重新上线,并且可以大大增强应用程序响应能力,因为CDN可以在地理上调整...
据我所知,CDN中还没有WebSockets支持,我怀疑它永远不会.WebSockets是有状态的,而HTTP是无状态的,因此很容易被缓存.实际上,为了使WebSockets对CDN友好,您可能需要切换到无状态RESTful方法......这不再是WebSockets.
2.安全问题
WebSockets存在潜在的安全问题,特别是关于DOS攻击.有关新安全漏洞的说明,请参阅此幻灯片组和此webkit票证.
WebSockets避免了OSI 7应用程序层级的任何数据包检查机会,这在任何业务安全性中都是非常标准的.实际上,WebSockets使传输变得模糊,因此可能是安全漏洞的主要漏洞.
可以这样考虑:什么是更便宜,保持开放连接,或为每个请求打开一个新连接(这样做的协商开销,记住它是TCP.)
当然这取决于应用程序,但对于长期实时连接(例如AJAX聊天),保持连接打开要好得多.
最大连接数将受套接字的最大空闲端口数限制.
| 归档时间： |
|
| 查看次数： |
39483 次 |
| 最近记录： |