通过HTTP 2.0实现AJAX与Websocket REST的性能？ [英] Performance of AJAX vs Websocket REST over HTTP 2.0?

问题描述

Websocket与AJAX在HTTP 2.0上的实际性能差异是什么？

特别是，我正在从事的项目需要双向实时更新，因此，尽管是非标准的，但如果仅在域内进行请求，则通过Websocket而不是AJAX进行REST可能会更有效。

我不确定当前有关性能差异的当前可用信息是否在HTTP 2.0上下文中成立。

解决方案

应始终测试性能而不是从理论上讲...只是说了一点，我将简单说明为什么我相信Websockets既性能更高，更可靠：

websockets相对于轮询的优势是两个：

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

   
   
   

   很明显，使用Http / 2时不再是这种情况，因为Http / 2是设计来的利用相同的连接。转到优势2：




2. 每个新的轮询请求都是一个请求，并且需要与该请求相关的所有资源（例如

   
   
   

   Websockets可以节省与轮询请求相关的资源，因为只有在可用时才推送数据，从而最大程度地减少了轮询次数。

   
   
   

   事实上，网络套接字仍然可以为您节省大量与实际轮询相关的资源。大多数websocket更新（如果不是全部）都使用数据更新挂钩，因此不涉及轮询（更新后立即启动推送，无需轮询和查看更改）。

   
   
   

   即使将轮询用于Websocket数据，所有客户端也只有一个轮询事件，而每个客户端只有一个轮询事件。 p>

关于Http / 2 Push怎么办？

这应该解决性能问题...但是，
可能会询问-关于Http / 2 push是什么？这是否意味着不再需要websocket？

这有点值得商and，您可以找到有关它的讨论（例如，此处）。

您可以从我对链接问题的回答，我认为网络套接字更加可靠，原因如下：

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

如Http / 2草案所述（现在是标准？）：

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

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

此外，当浏览器仍在访问页面时，客户端（或服务器或介于两者之间的任何人）可以终止Http / 2连接 ，从而有效地禁用了Http / 2

在websocket中发生这种情况时， onclose 回调可用于重新建立连接。有了Http / 2，您目前无法执行任何操作。

由于这些原因（以及其他一些原因），我相信Websocket可以同时提供更好的性能和可靠性。 / p>

编辑（与评论有关）

SSE （服务器发送的事件）

请允许我说明为什么我认为websocket优于SSE。

SSE

对于服务器到客户端消息来说，它可能很棒，除了以下几点：

1. 这是服务器端的实现，很糟糕。

   
   
   

   至于Http / 2过去，我没有看到任何实现，因此无法评论可能发生的情况，但是：

   
   
   

   许多SSE实现都会为每个连接打开一个新线程，或者在服务器的IO反应器旁边实施第二个IO反应器，仅用于管理SSE连接。

   
   
   

   与websocket相比，这将浪费资源（尽管我看到一些websocket实现也是如此-brrr ...）。




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

   
   
   

   这意味着您仍将Http + AJAX用于从客户端发送到服务器的数据。

   
   
   

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

   
   
   

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




3. SSE不受社区的支持。

   
   
   

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

   
   
   

   我认为这是webwebsocket在实际生产中优势的很好证明。

Http / 2内的Websocket隧道

我相信这个概念

我认为有一个原因从2014年2月14日开始的建议在2014年8月18日到期（直到最好）我的知识

以下是我能想到的一些原因：

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

   
   
   

   虽然Http / 2与Http / 1.1相比使用寿命长，但浏览器（或服务器）可以随时断开它们（有无实现websocket断开模式）。

   
   
   

   与Http / 2相关的路由器，代理和负载均衡器可以设置它们连接的超时设置。




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

>



Http / 2是为Http客户端（主要是浏览器）设计的。





Websockets是为所有设计的网络客户端，以帮助您浏览诸如ISP，防火墙，代理，NAT路由器等中介。 （即此程序包）





这意味着，当您决定编写本机应用程序并将Web服务器用作后端时，该本机应用程序应使用websocket以获得更好的连接性（其连接统计信息比原始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.

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