ajax - AJAX 与 Websocket REST over HTTP 2.0 的性能？

Question

Websocket 与 AJAX over HTTP 2.0 之间的实际性能差异是什么？

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

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

Answer 1

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

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

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

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

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

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

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

即使轮询用于 websocket 数据， 也只有一个轮询事件。全部 客户端，与 的轮询事件每个客户。

Http/2 推送怎么样？

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

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

正如您从 my answer 中看到的对于链接的问题，我相信 websocket 更可靠，原因如下:

这里的一些信息不在原始答案中，而我原始答案中的其他信息被跳过或总结

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

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

对于浏览器也是如此(如果您查看“设置”框架文档)。例如，当我在玩 Iodine's Http/2 server 时(我是作者)，我注意到 Safari 将推送通知设置为“关闭”......我不确定是否仍然如此，但是当我认为 websockets 与 Http/2.

另外，Http/2 连接 可以终止在浏览器仍在访问页面时由客户端(或服务器或两者之间的任何人)发送，有效地禁用 Http/2 推送通知。

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

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

编辑 (关于评论)

上证所 (服务器发送事件)

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

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

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

它的服务器端实现大多很糟糕。

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

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

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

上证所是单向并且不能用于客户端到服务器发送的消息。

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

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

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

SSE 并没有得到社区的大力支持。

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

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

Http/2 中的 Websocket 隧道

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

我认为这是有原因的 the suggestion从 2014 年 2 月 14 日开始，在 2014 年 8 月 18 日到期后(据我所知)没有续订。

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

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

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

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

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

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

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

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

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

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