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

pau*_*kon 8 ajax websocket http2

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

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

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

Mys*_*yst 15

性能应该始终进行测试而不是理论化...说完了,我会快速指出为什么我认为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.

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