服务器可伸缩性 - HTML 5 websockets与Comet

Question

服务器可伸缩性 - HTML 5 websockets与Comet

P.K*_*P.K 28 html5 push comet websocket

Caplin等许多Comet实现都提供了服务器可扩展的解决方案

以下是Caplin网站的统计数据之一:

Caplin解释器的单个实例可以支持多达100,000个客户端,每个客户端每秒接收1条消息,平均延迟小于7毫秒.

如何与任何网络服务器上的HTML5 websockets进行比较？任何人都可以指向任何HTML 5 websockets统计信息？

Answer 1

小智 42

披露 - 我为Caplin工作.

这个页面上有一些错误的信息,所以我想尝试让它更清晰..

我想我们可以把我们谈论的方法分成三个阵营......

Comet HTTP轮询 - 包括长轮询
Comet HTTP流 - 服务器到客户端消息使用单个持久套接字,初始设置后没有HTTP头开销
Comet WebSocket - 单双向插座

我认为它们都是Comet,因为Comet只是一个范例,但是自从WebSocket出现以来,有些人想把它视为不同或者取代Comet - 但它只是另一种技术 - 除非你很高兴只支持最新的浏览器那么你不能只依靠WebSocket.

就性能而言,大多数基准测试都集中在服务器到客户端的消息上 - 用户数量,每秒消息数量以及这些消息的延迟.对于这种情况,HTTP Streaming和WebSocket之间没有根本区别 - 两者都是在开放式套接字上写入消息,只有很少或没有标头或开销.

如果消息的频率很低,则长轮询可以提供良好的延迟.但是,如果您有两个消息(服务器到客户端)快速连续,那么第二个消息将不会到达客户端,直到收到第一个消息后发出新请求.

我想有人触及了HTTP KeepAlive.这显然可以改善Long轮询 - 你仍然有往返和头文件的开销,但并不总是创建套接字.

在有更多客户端到服务器消息的情况下,WebSocket应该在HTTP Streaming上进行改进.将这些场景与现实世界联系起来会产生稍微更加随意的设置,与简单易懂的"向大量客户发送大量消息"相比,每个人都可以理解.例如,在交易应用程序中,创建包含执行交易的用户(即客户端到服务器消息)的场景很容易,但结果与基本服务器到客户端场景的意义不大.交易者不会尝试进行100次交易 - 因此您最终得到的结果是"10000个用户每秒接收100个消息,同时每5分钟发送一次客户端消息".客户端到服务器消息的更有趣的部分是延迟,因为与服务器到客户端消息相比,所需消息的数量通常是微不足道的.

上面提到的另一点,大约64k客户端,您不需要做任何聪明的事情来支持服务器上超过64k的套接字 - 除了配置数字文件描述符等.如果您尝试从单个客户端机器进行64k连接,这是完全不同的,因为他们需要每个端口号 - 在服务器端,它是好的,这是听取端,你可以超过64k套接字罚款.

Answer 2

kan*_*aka 8

从理论上讲,WebSockets可以比HTTP更好地扩展,但也有一些警告和一些方法来解决这些警告.

HTTP与WebSockets的握手头处理的复杂性大致相同.HTTP(和初始WebSocket)握手很容易超过1K的数据(由于cookie等).重要的区别是每次消息都会再次发生HTTP握手.建立WebSocket连接后,每条消息的开销仅为2-14个字节.

张贴在@大卫Titarenco的答案的优良码头基准环节(1,2)表明的WebSockets可以轻松实现比多级更好延迟的订单相比,彗星时.

有关扩展WebSockets与HTTP的更多信息,请参阅此答案.

警告:

与短连接的HTTP连接不同,WebSocket连接是长期存在的.这显着降低了开销(没有套接字创建和管理每个请求/响应),但它确实意味着要将服务器扩展到64k以上的单独的同时客户端主机,您将需要在同一服务器上使用多个IP地址等技巧.
由于Web中介的安全性问题,浏览器到服务器WebSocket消息的所有有效负载数据都被屏蔽了XOR.这会为服务器增加一些CPU利用率来解码消息.但是,XOR是大多数CPU架构中最有效的操作之一,并且通常提供硬件辅助.服务器到浏览器消息没有被屏蔽,因为WebSocket的许多使用不需要从浏览器发送到服务器的大量数据,这不是一个大问题.

在HTTP流媒体中(Caplin使用的),每次消息都不会发生HTTP握手 - 我自己已经实现了很多次.它基本上只是一个开放(单向)套接字连接.HTTP流式传输性能与WebSockets非常相似(但有一些注意事项,其中一个缺点是双工). (3认同)
Caplin现在提供WebSocket支持.HTTP Streaming是一个不错的选择(正如我们已经说明的那样)但是浏览器不支持内容类型的`multipart/x-mixed-replace`(除了Firefox之外的所有内容？)这意味着`XHR.responseText `继续增长,在某些时候必须删除并重新启动流连接,否则浏览器最终会耗尽内存. (3认同)
@leggetter,你有关于Caplin的HTTP流延迟(往返)与Caplin WebSockets的数据吗？好奇的人想知道. (2认同)

Answer 3

Dav*_*nco 6

由于我们不知道(平均)有效载荷大小有多大,因此很难知道它与任何东西相比如何.在引擎盖下(就像服务器的实现方式一样),HTTP流和websockets几乎完全相同 - 除了初始握手之外,当显然使用HTTP时更加复杂.

如果你用C(ala Caplin)编写自己的websocket服务器,你可能会毫不费力地达到这些数字.大多数websocket实现是通过现有的服务器包(如Jetty)完成的,因此比较不太公平.

一些基准:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
http://webtide.intalio.com/2011/08/prelim-cometd-websocket-benchmarks /

但是,如果你看一下C事件lib基准测试,比如libev和libevent,这些数字看起来更加性感:http:
//libev.schmorp.de/bench.html

很棒的链接,谢谢!实际上,HTTP和WebSockets是完全不同的.WebSocket握手旨在与HTTP兼容,以便两个服务可以共享同一个端口.它们通常在同一服务器中实现,但之后它们非常不同.一旦建立了WebSocket连接,它就是一个全双工和双向的原始通道(更类似于常规套接字).在某些方面,WebSocket握手实际上比普通HTTP更复杂,因为它允许CORS验证,并且作为握手的一部分需要SHA1质询 - 响应. (3认同)
在从服务器传递到客户端的消息方面,如果在初始连接之后不相同,则延迟将非常相似.正如@kanaka指出的那样,WebSockets的好处是,在建立连接之后,信道是全双工和双向的.因此,如果您要使用HTTP Streaming对双向消息进行基准测试,其中客户端到服务器通信需要第二个短期HTTP,而对于WebSocket连接,WebSocket选项可能会非常优越.Caplin现在提供WebSocket支持,所以我相信他们可以击败100k连接. (2认同)

归档时间：	13 年，10 月前
查看次数：	26005 次
最近记录：	12 年，11 月前