AJAX 与 Websocket REST over HTTP 2.0 的性能? [英] Performance of AJAX vs Websocket REST over HTTP 2.0?

问题描述

Websocket 与基于 HTTP 2.0 的 AJAX 之间的实际性能差异是什么?

特别是，我正在做的一个项目需要双向实时更新，因此，尽管是非标准的，如果请求只在域内进行，通过 Websocket 而不是 AJAX 执行 REST 可能更有效.

但是，我不确定当前关于性能差异的可用信息是否适用于 HTTP 2.0 的上下文.

解决方案

应该始终测试性能而不是理论化...话虽如此，我将快速说明为什么我相信 Websockets更高效、更可靠:

websockets 相对于轮询的优势有两个:

1. 在 Http/2 之前，每个新的轮询请求都需要一个新的连接.Websockets 将为您节省与新连接相关的资源.

   显然，当使用 Http/2 时，情况不再如此，因为 Http/2 旨在利用相同的连接.继续讨论优势 2:

2. 每个新的轮询请求都是一个请求，并且需要与请求相关的所有资源(例如轮询数据库以查看更改等).

   Websockets 可以为您节省与轮询请求相关的资源，因为只有在可用时才会推送数据，从而最大限度地减少临时请求的数量.

   事实上，websockets 仍然为你节省了大量与实际轮询相关的资源.大多数 websocket 更新(如果不是全部)使用数据更新挂钩，因此不涉及轮询(更新后立即启动推送，无需轮询和审查更改).

   即使对 websocket 数据使用轮询，所有客户端也只有一个轮询事件，而每个客户端都有一个轮询事件.

Http/2 Push 怎么样?

这应该可以解决性能问题……但是，有人可能会问——Http/2 推送怎么样?这不是意味着不再需要 websockets 了吗?"

这有点值得商榷，您可以找到有关它的讨论(例如，此处).

正如您从我对链接问题的回答中看到的那样，我相信 websocket 更可靠，这里是为什么:

此处的某些信息不在原始答案中，而我原始答案中的其他信息已被跳过或汇总

正如 Http/2 草案(现在是标准?)所述:

<块引用>

中介可以接收来自服务器的推送并选择不将其转发到客户端...

这也适用于浏览器(如果您查看设置"框架文档).例如，当我在玩 Iodine 的 Http/2 服务器(我是作者)时，我注意到 Safari 将推送通知设置为关闭"......我不确定是否仍然如此，但是当我认为 websockets 与 Http/2 相比时，这对我来说很重要.

此外，当浏览器仍在访问页面时，客户端(或服务器或中间的任何人)可以终止 Http/2 连接，从而有效地禁用 Http/2 推送通知.>

当这种情况发生在 websockets 中时，onclose 回调可用于重新建立连接.使用 Http/2，您目前无能为力.

出于这些原因(以及其他一些原因)，我相信 Websocket 可以提供更好的性能和更好的可靠性.

编辑(关于评论)

SSE(服务器发送的事件)

请允许我说明为什么我认为 websockets 优于 SSE.

SSE 是基于长轮询、pre-websockets 时代的发展.

服务器到客户端的消息本来可以很棒，除了一些事情:

1. 它的服务器端实现很糟糕.

   就 Http/2 而言，我还没有看到任何实现，所以我无法评论可能会发生什么，但是:

   许多 SSE 实现会为每个连接打开一个新线程，或者实现与服务器 IO 反应器一起运行的第二个 IO 反应器，仅用于管理 SSE 连接.

   与 websockets 相比，这会浪费资源(尽管我看到一些 websocket 实现也在做同样的事情 - brrr...).

2. SSE 是单向的，不能用于客户端到服务器发送的消息.

   这意味着您仍然使用 Http+AJAX 来处理从客户端发送到服务器的数据.

   与 Websockets 不同，SSE 和 Http+AJAX 都是无状态的，因此您需要对每个新消息周期进行身份验证，解码 Http/2 标头，编码 Http/2 标头并使用与新请求相关的所有资源...

   Websockets 允许您通过有状态跳过所有这些.这意味着 Http 标头和身份验证仅在连接打开时执行一次，并且所有消息都在此持久上下文中发送，该上下文持续连接的生命周期.

3. SSE 没有得到社区的充分支持.

   与 Websockets 相比，很难找到与 SSE 相关的好的库或信息......即使 SSE 早于 websockets！

   我认为这很好地证明了 webwebsocket 在实际生产中的优越性.

Http/2 中的 Websocket 隧道

我认为这个概念和想法是错误的，不应使用隧道.

我认为有一个原因 来自 2014 年 2 月 14 日的建议在 2014 年 8 月 18 日到期后没有更新(据我所知).

以下是我能想到的几个原因:

1. Websockets 和 Http/2 被设计为具有不同的生命周期和连接超时.

   虽然与 Http/1.1 相比，Http/2 的生命周期更长，但浏览器(或服务器)可能会随时断开它们的连接(无论是否实现了 websocket 断开连接模式).

   路由器、代理和负载平衡器与 Http/2 相关，以设置它们的连接超时设置.相同的设置不太可能适用于今天用于 websocket 的超时设置.

2. Websockets 和 Http/2 是为不同的客户端设计的.

   Http/2 是为 Http 客户端设计的——主要是浏览器.

   另一方面，Websockets 是为所有 Web 客户端设计的，以帮助通过中间商(如 ISP、防火墙、代理、NAT 路由器等)导航.(即，这个包)

   这意味着当您决定编写本机应用程序并使用您的网络服务器作为后端时，本机应用程序应该使用 websockets 以获得更好的连接性(它的连接性统计数据比原始数据要好)TCP/IP).

   您的本机应用程序不使用 Http/2，但它确实具有建立 websockets 连接所需的精简 Http/1.

   如果您决定使用隧道，您可能无法将当前代码用于本机应用程序.

What is the real-world performance difference between Websocket vs AJAX over HTTP 2.0?

In particular, a project I'm working on requires bidirectional real-time updates, therefore, although nonstandard, if requests are only to be made within the domain, it may be more efficient to conduct REST over Websocket rather than AJAX.

However, I'm not sure if currently available information regarding the performance differences hold true in the context of HTTP 2.0.

解决方案

Performance should always be tested rather than theorized... having said that, I'll make a quick point to show why I believe that Websockets are both more performant and more reliable:

The advantages of websockets over polling are two:

1. Before Http/2, each new polling request required a new connection. Websockets would save you the resources related to the new connection.

   Obviously, when using Http/2 this is no longer the case, as Http/2 is designed to leverage the same connection. Moving on to advantage number 2:

2. Each new polling request is a request and requires all the resources related to the request (such as polling the database to review changes etc').

   Websockets would save you the resources related to polling requests, as data will be pushed only when available, minimizing the number of interim requests.

   In fact, websockets still save you a lot of resources related to the actual polling. Most websocket updates (if not all) use data update hooks, so that no polling is involved (push is initiated right after the update, without a need to poll and review for changes).

   Even when polling is used for websocket data, there is only a single polling event for all the clients, vs. a polling event for each client.

What about Http/2 Push?

This should put to rest the question of performance... but, one might inquire - "what about Http/2 push? doesn't it mean websockets are no longer necessary?"

This is somewhat debatable and you can find discussions about it (for example, here).

As you can see from my answer to the linked question, I believe that the websocket are more reliable, and here's why:

some of the info here isn't in the original answer and other info from my original answer was skipped or summarized

As stated by the Http/2 draft (standard by now?):

An intermediary can receive pushes from the server and choose not to forward them on to the client...

This is also true for the browsers (if you look into the "settings" frames documentation). For instance, while I was playing around with Iodine's Http/2 server (I'm the author), I noticed that Safari was setting push notifications to "off"... I'm not sure if this is still the case, but it's a big deal for me when I think websockets vs. Http/2.

Also, Http/2 connections can be terminated by the client (or the server or anyone in between) while the browser is still visiting the page, effectively disabling Http/2 push notifications.

When this happens in websockets, the onclose callback can be used to re-establish a connection. With Http/2 there's nothing you can currently do.

For these reasons (and a few others), I believe that Websockets allow for both better performance and better reliability.

EDIT (relating to comments)

SSE (Server Sent Events)

Allow me to state why I believe that websockets are superior to SSE.

SSE is a development based on long-polling, pre-websockets era.

It could have been great for server to client messages, except for a few things:

1. It's server-side implementation mostly sucks.

   As far as Http/2 goes, I hadn't seen any implementations, so I can't comment on what might happen, but:

   Many SSE implementations will open a new thread for each connection or implement a second IO reactor running along side the server's IO reactor, just for managing the SSE connections.

   This will waste resources when compared to websockets (although I saw some websocket implementations doing the same - brrr...).

2. SSE is uni-directional and cannot be used for client to server sent messages.

   This means you still use Http+AJAX for data sent from the client to the server.

   Unlike Websockets, both SSE and Http+AJAX are stateless, so you need to go through authentication for every new message cycle, decoding the Http/2 headers, encoding the Http/2 headers and using all the resources related to a fresh request...

   Websockets allow you to skip all that by being stateful. This means that Http headers and authentication are performed only once when the connection is opened and all the messages are sent within this persistent context that lasts for the lifetime of the connection.

3. SSE isn't as well supported by the community.

   It's harder to find good libraries or information pertaining to SSE when compared to Websockets... Even though SSE pre-dates websockets!

   I think this is a good proof for webwebsocket's superiority in actual production.

Websocket tunneling within Http/2

I believe this concept and idea to be a mistake and that tunneling shouldn't be used.

I think there's a reason that the suggestion from February 14, 2014 wasn't renewed after it expired on August 18, 2014 (to the best of my knowledge).

Here are a few reasons I can think of:

1. Websockets and Http/2 are designed to have different lifetimes and connection timeouts.

   While Http/2 are long lived when compared to Http/1.1, the browser (or server) might disconnect them at any time (with or without implementing a websocket disconnection pattern).

   Routers, proxies and load-balancers relate to Http/2 to set their timeout settings for the connection. It is unlikely that the same settings will apply to the timeout settings used today for websockets.

2. Websockets and Http/2 are designed for different clients.

   Http/2 is designed for Http clients - primarily browsers.

   Websockets, on the other hand, are designed for all web clients to help navigate through intermediaries such a ISPs, Firewalls, Proxies, NAT routers etc'. (i.e., this package)

   This means that when you decide to write a native application and use your web-server as a back-end, that native application should use websockets for better connectivity (it's connectivity statistics are better than raw TCP/IP).

   Your native application doesn't speak Http/2, but it does have the stripped down Http/1 needed to establish a websockets connection.

   If you decide to use tunneling, you probably wouldn't be able to leverage your current code for a native application.

这篇关于AJAX 与 Websocket REST over HTTP 2.0 的性能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！