HTTP / 2或Websocket用于低延迟的客户端到服务器消息

Question

我要求Web应用程序中客户端到服务器消息的等待时间非常短。

我在stackoverflow上看到了几篇文章，说满足此要求最好使用websockets而不是HTTP，但这已经有一段时间了。

今天，在2018年，随着HTTP / 2的发展，在此用例中仍然值得使用websockets吗？

Answer 1

HTTP / 2具有multiplexing，这意味着应该没有等待时间-就像HTTP / 1下那样，由于每个域有6个连接限制。因此，这意味着您可以将其用于低延迟的连接。

但是，HTTP仍然有其他开销，例如HTTP标头，这可能会为Web套接字不具备的小请求添加大量不必要的额外数据。

另外，HTTP / 2不是全双工协议，因此只能响应请求（尽管由于服务器推送，响应可能不止一个）。您说您只需要在客户端-服务器消息传递中使用它，这样您就不必担心了。

支持HTTP / 2的二进制框架层是全双工协议，因此理论上可以类似于websockets，但是HTTP / 2不允许这样做-除非您只是拖出发送请求和响应主体以进行伪造（{ {3}}或long polling）。实际上，Server-Sent Events已被批准，通过将websockets消息包装在HTTP / 2数据帧中，将允许HTTP / 2二进制格式用于websocket。这样做还有一个好处，就是还可以在同一连接上允许常规HTTP消息。在撰写本文时，它尚未在任何浏览器中可用（尽管在Websockets over HTTP/2和version 65 of FireFox中提供）。在此之前，Websockets会还原为HTTP / 1.1。

另请参阅以下问题和答案：Chrome has started an implementation

Answer 2

我的Web应用程序中的客户端到服务器消息的等待时间非常短。

我读此邮件是因为您要“连接”，然后在 client 和 server 之间发送低延迟消息。

HTTP / 2和Websocket都可以是二进制的，并且消息在其中传输的帧具有类似的开销（几个字节），但是Websocket必须遍历整个消息以掩盖有效载荷 然后接收者必须扭转这种情况。参见What is the mask in a WebSocket frame?

此外，Websocket原语是更底层的，例如要拥有多个消息流，您必须自己完成操作，但是使用HTTP / 2可以轻松完成。参考Podcast about HTTP/2。在同一应用程序中同时使用Websocket和HTTP时，服务器代码也会变得更加复杂。

使用HTTP / 1.1 Websocket可能会出现流控制问题，但HTTP / 2中内置了协议功能。

服务器到客户端

通过使用fetch和response.body.getReader();获得ReadableStream的HTTP / 2，可以有效地完成此操作。一篇关于浏览器JavaScript中的流的好文章：2016 - the year of web streams。

客户端到服务器

当前以HTTP方式从客户端向服务器发送消息的唯一方法是发送完整请求。流请求主体是经过计划的，但浏览器尚未实现。有关流式请求正文，请参见Fetch with ReadableStream as Request Body。

Answer 3

这取决于您的客户和您的要求。如果您确定客户端不会关闭HTTP / 2的基础TLS连接（即使一段时间未使用），则发送消息/请求的延迟可能类似于持久化的Websocket连接。如果客户端在空闲时间后关闭连接，并且需要建立新的TLS连接，情况将会更糟。

对于以浏览器作为客户端的情况，您知道Web套接字连接将是持久的，并且对HTTP连接一无所知。也许您可以通过向同一服务器上的SSE终结点发出虚拟请求来强制浏览器保持连接，并保持连接状态，但这是一种解决方法。

除了建立连接外，这两种协议的开销（流控制和流头与屏蔽）都有不同的种类，其影响很可能只能根据实际的应用需求来估算。