通过HTTP 2.0实现AJAX与Websocket REST的性能？

Question

通过HTTP 2.0，Websocket与AJAX之间的真实性能差异是什么？

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

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

Answer 1

性能应该始终进行测试而不是理论化...说完了，我会快速指出为什么我认为Websockets更高性能和更可靠 ：

websockets over polling的优点是两个：

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，你现在无能为力。

出于这些原因（以及其他一些原因），我认为Websockets可以提供更好的性能和更好的可靠性。

编辑 （与评论有关）

SSE （服务器发送事件）

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

SSE是基于长轮询，预网页时代的开发。

它可能对服务器到客户端消息很有用，除了一些事情：

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相关，以设置连接的超时设置。 相应的设置不太可能适用于今天用于websockets的超时设置。

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

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

   另一方面，Websockets是为所有Web客户端设计的，以帮助浏览诸如ISP，防火墙，代理，NAT路由器等中介。 （即这个包 ）

   这意味着当您决定编写本机应用程序并将Web服务器用作后端时，该本机应用程序应使用websockets以实现更好的连接（它的连接统计信息优于原始TCP / IP）。

   您的本机应用程序不会说Http / 2，但它确实具有建立websockets连接所需的剥离Http / 1。

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

Answer 2

我肯定会使用websockets，更不用说这种甜蜜的语法，但永远不要忘记使用socket.io，因为它们是websockets不进行NAT遍历，并且有一些阻塞，这可能会削弱你的项目。

另外一个事实是，如果你想使用cordova ios和websockets去WKWebView，那么你会因为它们在ios的默认浏览器中的工作方式而感到非常惊讶。

关于websockets的最后一件事是尽量不使用它们来发送数据从客户端到服务器只有服务器 - >客户端，因为在一天结束时，AJAX是一个比websockets更可靠的解决方案。