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

Question

我在我的网络应用程序中有一个非常低延迟的客户端到服务器消息传输的要求。

我看过stackoverflow上的一些帖子，说对于这个需求使用websockets比HTTP更优，但那是很久以前的事了。

今天，2018年，随着HTTP/2的进展，是否仍然值得为这种情况使用websockets呢？

- rico

Answer 1

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

但是，仍然存在其他HTTP开销，例如HTTP头，这可能会为您使用Web套接字时不必要地添加重要的额外数据。

此外，HTTP/2不是全双工协议，因此只能响应请求（虽然可能通过服务器推送进行多个响应）。您说您只需要这个用于客户端-服务器消息传递，因此这可能对您来说不太重要。

HTTP/2的二进制封装层是全双工协议，理论上类似于websocket，但HTTP/2不允许这样做——除非您只是延迟发送请求和响应体以模拟此行为（长轮询或服务器推送事件）。实际上，在HTTP/2上使用Websockets已被批准，这将允许使用HTTP/2二进制格式来包装Websockets消息。这样做的另一个优点是还可以在同一连接上使用常规HTTP消息。截至撰写本文时，在任何浏览器中都尚不可用（虽然火狐65版即将推出，Chrome已开始实现）。在那之前，Websockets将回到HTTP/1.1。

另请参见此问题和答案：HTTP/2是否使Websockets过时？

- Barry Pollard

---

关于“http消息大小”部分的快速澄清：是的，HTTP2采用了HPACK进行智能头部压缩，有助于保持头部大小合理低。而且确实，HTTP2确实比WebSocket（也支持压缩）更好地遵循有效载荷压缩趋势。尽管如此，请记住，HTTP2在这种智能复杂性下对您的负担（CPU，RAM）还是相当大的，而且如果您必须处理随机的http头（例如经常更改的跟踪cookie或其他），那么您会很难保持消息大小可预测性和低延迟。仅供参考。 - XDS

Answer 2

我理解您希望在我的网页应用程序中实现客户端到服务器消息的低延迟传输。

HTTP/2和Websocket都可以使用二进制传输，它们传输消息的框架开销相似（仅有几个字节），但Websocket需要迭代整个消息以对有效负载进行遮罩处理，接收者则需反转此操作。参见WebSocket帧中的掩码是什么？

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

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

服务器到客户端

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

客户端到服务器

目前在HTTP中从客户端发送消息的唯一方法是发送完整请求。 流式请求正计划但尚未被浏览器实现。请参见使用ReadableStream作为请求体的Fetch有关流式请求正文的信息。

- Jonas

Answer 3

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

对于浏览器作为客户端的情况，你知道web socket连接将是持久的，并且不知道任何关于HTTP连接的信息。也许你可以通过向同一服务器上的SSE端点发出虚拟请求并保持连接来强制浏览器保持连接，但这有点绕弯子。

除了连接建立外，两种协议都存在不同类型的开销（流量控制和流头与掩码），实际应用程序的影响可能只能根据实际应用程序需求进行估计。

- Matthias247