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

Question

我要求我的Web应用程序中的客户端到服务器消息的延迟非常低.

我在stackoverflow上看过几篇帖子说最好使用websockets而不是HTTP来满足这个要求,但是很久以前.

今天,在2018年,随着HTTP/2的进展,是否仍然值得使用websockets这个用例？

Answer 1

HTTP/2 具有多路复用，这意味着不应该有等待时间——就像在 HTTP/1 下一样，由于每个域有 6 个连接限制。所以这意味着它可以用于您所说的低延迟连接。

然而，HTTP 仍然存在其他开销，例如 HTTP 标头，这可能会向小型请求添加大量不必要的额外数据，而 Web 套接字不会提供这些数据。

此外，HTTP/2 不是全双工协议，因此只能响应请求（尽管由于服务器推送，可能会有多个响应）。你说你只需要这个用于客户端 - 服务器消息传递，所以这对你来说可能不那么重要。

支持 HTTP/2 的二进制帧层是一个全双工协议，因此理论上可以类似于 websockets 但 HTTP/2 不允许这样做 - 除非你只是拖出请求和响应主体的发送来伪造这个（长轮询或服务器- 发送事件）。事实上，HTTP/2上的Websockets已经被批准，这将允许通过将 websockets 消息包装在 HTTP/2 数据帧中来将 HTTP/2 二进制格式用于 websockets。这还有一个额外的优势，即还允许在同一连接上使用常规 HTTP 消息。在撰写本文时，它尚未在任何浏览器中可用（尽管FireFox 65 版和Chrome 已开始实施）。在此之前，Websockets 将恢复到 HTTP/1.1。

另请参阅此问题和答案：Does HTTP/2 make websockets obsolete?

Answer 2

我的 Web 应用程序中客户端到服务器消息的延迟非常低。

我读到这一点是因为您想要“连接”，然后在客户端和服务器之间发送低延迟消息。

HTTP/2 和 Websocket 都可以是二进制的，并且传输消息的帧具有类似的开销（几个字节），但 Websocket 必须迭代完整的消息以屏蔽有效负载，然后接收者必须反转这一点。请参阅WebSocket 帧中的掩码是什么？

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

使用 HTTP/1.1 Websocket 时流量控制可能是一个问题，但它是 HTTP/2 中的内置协议功能。

服务器到客户端

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

客户端到服务器

目前，在 HTTP 中从客户端向服务器发送消息的唯一方法是发送完整请求。流式请求正文已计划，但浏览器尚未实现。有关流式请求正文，请参阅使用 ReadableStream 作为请求正文进行 Fetch。