服务器可扩展性 - HTML 5 websockets 与 Comet

Server Scalability - HTML 5 websockets vs Comet

提问by P.K

Many Comet implementations like Caplin provide server scalable solutions.

许多像 Caplin 这样的 Comet 实现提供了服务器可扩展的解决方案。

Following is one of the statistics from Caplinsite:

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

A single instance of Caplin liberator can support up to 100,000 clients each receiving 1 message per second with an average latency of less than 7ms.

Caplin liberator 的单个实例最多可支持 100,000 个客户端，每个客户端每秒接收 1 条消息，平均延迟小于 7 毫秒。

How does this to compare to HTML5 websockets on any webserver? Can anyone point me to any HTML 5 websockets statistics?

这与任何网络服务器上的 HTML5 websockets 相比如何？任何人都可以指出任何 HTML 5 websockets 统计数据吗？

回答by Martin Tyler

Disclosure - I work for Caplin.

披露 - 我为 Caplin 工作。

There is a bit of misinformation on this page so I'd like to try and make it clearer..

此页面上有一些错误信息，因此我想尝试使其更清楚。

I think we could split up the methods we are talking about into three camps..

我认为我们可以将我们正在谈论的方法分成三个阵营。

1. Comet HTTP polling - including long polling
2. Comet HTTP streaming - server to client messages use a single persistent socket with no HTTP header overhead after initial setup
3. Comet WebSocket - single bidirectional socket

1. Comet HTTP 轮询——包括长轮询
2. Comet HTTP 流 - 服务器到客户端的消息使用单个持久套接字，初始设置后没有 HTTP 标头开销
3. Comet WebSocket - 单双向套接字

I see them all as Comet, since Comet is just a paradigm, but since WebSocket came along some people want to treat it like it is different or replaces Comet - but it is just another technique - and unless you are happy only supporting the latest browsers then you can't just rely on WebSocket.

我将它们都视为 Comet，因为 Comet 只是一种范式，但是自从 WebSocket 出现以来，有些人希望将其视为不同或取代 Comet——但这只是另一种技术——除非你很高兴只支持最新的浏览器那么你不能仅仅依靠 WebSocket。

As far as performance is concerned, most benchmarks concentrate on server to client messages - numbers of users, numbers of messages per second, and the latency of those messages. For this scenario there is no fundamental difference between HTTP Streaming and WebSocket - both are writing messages down an open socket with little or no header or overhead.

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

Long polling can give good latency if the frequency of messages is low. However, if you have two messages (server to client) in quick succession then the second one will not arrive at the client until a new request is made after the first message is received.

如果消息频率较低，长轮询可以提供良好的延迟。但是，如果您快速连续收到两条消息（服务器到客户端），那么在收到第一条消息后发出新请求之前，第二条消息不会到达客户端。

I think someone touched on HTTP KeepAlive. This can obviously improve Long polling - you still have the overhead of the roundtrip and headers, but not always the socket creation.

我认为有人触及了 HTTP KeepAlive。这显然可以改善长轮询 - 您仍然有往返和标头的开销，但并不总是套接字创建。

Where WebSocket should improve upon HTTP Streaming in scenarios where there are more client to server messages. Relating these scenarios to the real world creates slightly more arbitrary setups, compared to the simple to understand 'send lots of messages to lots of clients' which everyone can understand. For example, in a trading application, creating a scenario where you include users executing trades (ie client to server messages) is easy, but the results a bit less meaningful than the basic server to client scenarios. Traders are not trying to do 100 trades/sec - so you end up with results like '10000 users receiving 100 messages/sec while also sending a client message once every 5 minutes'. The more interesting part for the client to server message is the latency, since the number of messages required is usually insignificant compared to the server to client messages.

在有更多客户端到服务器消息的场景中，WebSocket 应该改进 HTTP Streaming 的地方。与每个人都可以理解的简单易懂的“向许多客户端发送大量消息”相比，将这些场景与现实世界相关联会创建更随意的设置。例如，在交易应用程序中，创建一个包括用户执行交易（即客户端到服务器消息）的场景很容易，但结果的意义比基本的服务器到客户端场景要少一些。交易者不会尝试每秒进行 100 次交易 - 因此您最终会得到类似“10000 个用户每秒接收 100 条消息，同时每 5 分钟发送一次客户端消息”这样的结果。客户端到服务器消息更有趣的部分是延迟，

Another point someone made above, about 64k clients, You do not need to do anything clever to support more than 64k sockets on a server - other than configuring the number file descriptors etc. If you were trying to do 64k connection from a single client machine, that is totally different as they need a port number for each one - on the server end it is fine though, that is the listen end, and you can go above 64k sockets fine.

上面有人提出的另一点，关于 64k 客户端，您不需要做任何聪明的事情来支持服务器上超过 64k 的套接字 - 除了配置数字文件描述符等。如果您尝试从单个客户端机器进行 64k 连接，这是完全不同的，因为他们每个人都需要一个端口号 - 在服务器端它很好，那是监听端，你可以很好地超过 64k 套接字。

回答by kanaka

In theory, WebSockets can scale much better than HTTP but there are some caveats and some ways to address those caveats too.

理论上，WebSockets 可以比 HTTP 更好地扩展，但也有一些警告和解决这些警告的一些方法。

The complexity of the handshake header processing of HTTP vs WebSockets is about the same. The HTTP (and initial WebSocket) handshake can easily be over 1K of data (due to cookies, etc). The important difference is that the HTTP handshake happens again everymessage. Once a WebSocket connection is established, the overhead per message is only 2-14 bytes.

HTTP 与 WebSockets 的握手标头处理的复杂性大致相同。HTTP（和初始 WebSocket）握手很容易超过 1K 的数据（由于 cookie 等）。重要的区别在于，每条消息都会再次发生 HTTP 握手。一旦建立了 WebSocket 连接，每条消息的开销只有 2-14 个字节。

The excellent Jetty benchmark links posted in @David Titarenco's answer (1, 2) show that WebSockets can easily achieve more than an order of magnitude better latencywhen compared to Comet.

@David Titarenco 的回答 ( 1, 2) 中发布的优秀 Jetty 基准链接表明，与 Comet 相比，WebSockets 可以轻松实现超过一个数量级的延迟。

See this answerfor more information on scaling of WebSockets vs HTTP.

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

Caveats:

注意事项：

• WebSocket connections are long-lived unlike HTTP connections which are short-lived. This significantly reduces the overhead (no socket creation and management for every request/response), but it does mean that to scale a server above 64k separate simultaneous client hosts you will need to use tricks like multiple IP addresses on the same server.

• Due to security concerns with web intermediaries, browser to server WebSocket messages have all payload data XOR masked. This adds some CPU utilization to the server to decode the messages. However, XOR is one of the most efficient operations in most CPU architectures and there is often hardware assist available. Server to browser messages are not masked and since many uses of WebSockets don't require large amounts of data sent from browser to server, this isn't a big issue.

• 与短暂的 HTTP 连接不同，WebSocket 连接是长期存在的。这显着降低了开销（无需为每个请求/响应创建和管理套接字），但这确实意味着要将服务器扩展到 64k 以上的独立并发客户端主机，您需要在同一服务器上使用多个 IP 地址等技巧。

• 由于 Web 中介的安全问题，浏览器到服务器的 WebSocket 消息将所有负载数据 XOR 屏蔽。这会向服务器增加一些 CPU 利用率以对消息进行解码。然而，XOR 是大多数 CPU 架构中最有效的操作之一，并且通常有硬件辅助可用。服务器到浏览器的消息没有被屏蔽，而且由于 WebSockets 的许多用途不需要从浏览器向服务器发送大量数据，所以这不是一个大问题。

回答by David Titarenco

It's hard to know how that compares to anything because we don't know how big the (average) payload size is. Under the hood (as in how the server is implemented), HTTP streaming and websockets are virtually identical - apart from the initial handshake which is more complicated when done with HTTP obviously.

很难知道它与任何东西相比如何，因为我们不知道（平均）有效载荷大小有多大。在引擎盖下（如服务器的实现方式），HTTP 流和 websockets 实际上是相同的 - 除了初始握手之外，显然使用 HTTP 完成时更复杂。

If you wrote your own websocket server in C (ala Caplin), you could probably reach those numbers without too much difficulty. Most websocket implementations are done through existing server packages (like Jetty) so the comparison wouldn't really be fair.

如果您用 C 语言（ala Caplin）编写自己的 websocket 服务器，您可能会毫不费力地达到这些数字。大多数 websocket 实现是通过现有的服务器包（如 Jetty）完成的，因此比较并不公平。

Some benchmarks:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
http://webtide.intalio.com/2011/08/prelim-cometd-websocket-benchmarks/

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

However, if you look at C event lib benchmarks, like libev and libevent, the numbers look significantly sexier:
http://libev.schmorp.de/bench.html

但是，如果您查看 C 事件库基准测试，例如 libev 和 libevent，这些数字看起来更加性感：http:
//libev.schmorp.de/bench.html

回答by eddie mcdaid

Ignoring any form of polling, which as explained elsewhere, can introduce latency when the update rate is high, the three most common techniques for JavaScript streaming are:

忽略任何形式的轮询，正如其他地方所解释的，当更新率很高时会引入延迟，JavaScript 流的三种最常见技术是：

1. WebSocket
2. Comet XHR/XDR streaming
3. Comet Forever IFrame

1. 网络套接字
2. Comet XHR/XDR 流媒体
3. 永远的彗星 IFrame

WebSocket is by far the cleanest solution, but there are still issues in terms of browser and network infrastructure not supporting it. The sooner it can be relied upon the better.

WebSocket 是迄今为止最干净的解决方案，但仍然存在浏览器和网络基础设施不支持它的问题。越早依赖越好。

XHR/XDR & Forever IFrame are both fine for pushing data to clients from the server, but require various hacks to be made to work consistently across all browsers. In my experience these Comet approaches are always slightly slower than WebSockets not least because there is a lot more client side JavaScript code required to make it work - from the server's perspective, however, sending data over the wire happens at the same speed.

XHR/XDR 和 Forever IFrame 都适用于将数据从服务器推送到客户端，但需要进行各种 hack 以在所有浏览器上一致地工作。根据我的经验，这些 Comet 方法总是比 WebSockets 稍慢，尤其是因为需要更多的客户端 JavaScript 代码才能使其工作 - 然而，从服务器的角度来看，通过线路发送数据的速度相同。

Here are some more WebSocket benchmark graphs, this time for our product my-Channels Nirvana.

这里有一些更多的WebSocket 基准图表，这次是我们的产品my-Channels Nirvana。

Skip past the multicast and binary data graphs down to the last graph on the page (JavaScript High Update Rate)

跳过多播和二进制数据图直到页面上的最后一个图（JavaScript 高更新率）

In summary - The results show Nirvana WebSocket delivering 50 events/sec to 2,500k users with 800 microsecond latency. At 5,000 users (total of 250k events/sec streamed) the latency is 2 milliseconds.

总结 - 结果显示 Nirvana WebSocket 以 800 微秒的延迟向 2,500k 用户提供 50 个事件/秒。在 5,000 个用户（总共 250k 事件/秒流式传输）时，延迟为 2 毫秒。