我要求在我的 Web 应用程序中对客户端到服务器的消息具有非常低的延迟。
我在stackoverflow上看到过几篇帖子，说最好使用websockets而不是HTTP来满足这个要求，但那是很久以前的事了。
今天，在 2018 年，随着 HTTP/2 的进步，在这个用例中使用 websocket 仍然值得吗？
HTTP/2 具有多路复用功能，这意味着不应该有等待时间 - 就像 HTTP/1 下一样，因为每个域有 6 个连接限制。因此，这意味着它可以用于您所说的低延迟连接。
但是，HTTP仍有其他开销，例如 HTTP 标头，这可能会为小请求添加大量不必要的额外数据，而这些请求不会使用 Web 套接字。
此外，HTTP/2不是完整的双工协议，因此只能响应请求(尽管由于服务器推送，可能有多个响应(。您说您只需要客户端-服务器消息传递，因此这可能对您来说不那么重要。
支撑 HTTP/2的二进制成帧层是一个全双工协议，因此理论上可能类似于 websockets，但 HTTP/2 不允许这样做 - 除非你只是拖延发送请求和响应体来伪造这个(长轮询或服务器发送的事件(。事实上，基于 HTTP/2 的 Websockets 已被批准，这将允许通过将 websockets 消息包装在 HTTP/2 数据帧中来将 HTTP/2 二进制格式用于 websocket。这还具有允许在同一连接上添加常规 HTTP 消息的额外优势。在撰写本文时，它尚未在任何浏览器中可用(尽管在FireFox和Chrome的65版本中已经开始实现(。在此之前，Websockets 会恢复到 HTTP/1.1。
另请参阅此问题和答案：HTTP/2是否使Websocket过时？
我的 Web 应用程序中客户端到服务器消息的延迟非常低。
我读到这是您想要"连接"，然后在客户端和服务器之间发送低延迟消息。
HTTP/2 和 Websocket 都可以是二进制的，并且消息传输的帧具有类似的开销(几个字节(，但 Websocket 必须遍历完整的消息以掩盖有效负载，然后接收方必须反转这一点。请参阅 WebSocket 框架中的掩码是什么？
此外，Websocket 原语是更底层的，例如，要有多个消息流，您必须自己执行此操作，但使用 HTTP/2 很容易完成。关于HTTP/2的参考播客。此外，当在同一应用程序中同时使用 Websocket 和 HTTP 时，服务器代码会变得更加复杂。
使用 HTTP/1.1 Websocket 时，流量控制可能是个问题，但它是 HTTP/2 中的内置协议功能。
服务器到客户端
这可以通过使用 HTTP/2 有效地完成，通过使用fetch和response.body.getReader();来获取 ReadableStream。一篇关于浏览器 JavaScript 中的流的好文章：2016 - Web 流之年。
客户端到服务器
目前在 HTTP 中将消息从客户端发送到服务器的唯一方法是发送完整请求。流式处理的请求正文已计划，但浏览器尚未实现。请参阅使用可读流作为请求正文提取有关流请求正文的信息。
这将取决于您的客户和您的要求。如果您确定客户端不会关闭 HTTP/2 的基础 TLS 连接(即使一段时间未使用(，则发送消息/请求的延迟可能类似于持久化的 websocket 连接。如果客户端在一段时间后关闭连接，并且需要建立新的 TLS 连接，情况会更糟。
在浏览器作为客户端的情况下，您知道 Web 套接字连接将是持久的，并且对 HTTP 连接一无所知。也许您可以通过向同一服务器上的 SSE 端点发出虚拟请求来强制浏览器保持连接并保持这种状态，但这是一种解决方法。
除了建立连接之外，两种协议都有不同类型的开销(流控制和流标头与屏蔽(，并且影响很可能只能根据实际应用程序需求来估计。