HTTP/2是否使WebSocket过时？

Question

我正在学习HTTP/2协议。这是一个带有小消息帧的二进制协议。它允许通过单个TCP连接进行流多路复用。从概念上讲，它似乎与WebSocket非常相似。

是否有计划淘汰WebSocket，并用某种无头HTTP/2请求和服务器启动的推送消息取代它们？或者WebSocket会补充HTTP/2吗？

Answer 1

我说不（网络插座没有过时）。

第一个也是最常被忽视的问题是HTTP/2推送是不可执行的，可能会被代理、路由器、其他中介甚至浏览器忽略。

即（来自HTTP2草案）：

中介可以接收来自服务器的推送，并选择不将其转发给客户端。换句话说，如何使用推送的信息取决于该中介。同样，中介可以选择向客户端进行额外的推送，而不需要服务器采取任何行动。

因此，HTTP/2推送无法取代WebSocket。

此外，HTTP/2连接也会在一段时间后关闭。

诚然，该标准规定：

HTTP/2连接是持久的。为了获得最佳性能，在确定不需要与服务器进行进一步通信（例如，当用户离开特定网页时）或在服务器关闭连接之前，客户机不会关闭连接。

但是

鼓励服务器尽可能长时间地保持开放连接，但允许在必要时终止空闲连接。当任一endpoint选择关闭传输层TCP连接时，终止endpoint应首先发送GOAWAY（第6.8节）帧，以便两个endpoint都能可靠地确定之前发送的帧是否已被处理，并正常完成或终止任何必要的剩余任务。

即使相同的连接允许在打开时推送内容，即使HTTP/2解决了HTTP/1.1的“保持活力”引入的一些性能问题... HTTP/2连接不会无限期保持打开。

一旦关闭，网页也不能重新启动HTTP/2连接（除非我们重新开始长拉）。

编辑（2017年，两年后）

HTTP/2的实现表明，多个浏览器选项卡/窗口共享一个HTTP/2连接，这意味着push永远不会知道它属于哪个选项卡/窗口，从而消除了使用push替代WebSocket的情况。

编辑（2020年）

我不知道为什么人们开始对答案投反对票。如果说有什么区别的话，那就是自答案最初发布以来的几年证明，HTTP/2不能取代WebSocket，也不是为取代WebSocket而设计的。

诚然，HTTP/2可以用于隧道WebSocket连接，但这些隧道连接仍然需要WebSocket协议，它们将影响HTTP/2容器的行为方式。

Answer 2

据我所知，HTTP/2不是WebSocket的替代品，而是旨在标准化SPDY协议。

在HTTP/2中，服务器推送在后台使用，以改进客户端从浏览器加载的资源。作为一名开发人员，在开发过程中你并不真正关心它。然而，有了Websocket，开发人员可以使用API，该API能够使用独特的全双工连接来消费和推送消息。

这些不是同一件事，它们应该相互补充。

Answer 3

在刚刚读完RFC 7540后，HTTP/2在所有用例中都淘汰了网络套接字，除了将二进制数据从服务器推送到JS网络客户端。HTTP/2完全支持二进制比迪流（读取），但是浏览器JS没有消耗二进制数据帧的应用编程接口，AFAIK也没有这样的应用编程接口。

对于bidi流媒体的所有其他应用程序，HTTP/2都和websockets一样好或更好，因为（1）该规范为您做了更多的工作，（2）在许多情况下，它允许较少的TCP连接打开到源。

PUSH_PROMISE（通俗地称为服务器推送）不是这里的问题。这只是性能优化。

浏览器中WebSocket的主要用例是启用双向数据流。因此，我认为OP的问题变成了HTTP/2是否能更好地在浏览器中启用双向数据流，我认为是的。

首先是比迪。只需阅读streams部分的介绍：

“流”是在HTTP/2连接中客户端和服务器之间交换的独立的双向帧序列。流有几个重要特征：

一个HTTP/2连接可以包含多个并发打开的流，其中任一endpoint都可以交错来自多个流的帧。

流可以单方面建立和使用，也可以由客户端或服务器共享。

流可以由任一终结点关闭。

像这样的文章（在另一个答案中链接）在HTTP/2的这方面是错误的。他们说这不是Bidi。听着，有一件事是HTTP/2不能发生的：连接打开后，服务器不能启动常规流，只能启动推送流。但是一旦客户端通过发送请求打开流，双方都可以随时通过持久套接字发送数据帧——完整的Bidi。

这与webSocket没有太大区别：客户端必须在服务器发送数据之前发起webSocket升级请求。

最大的区别是，与webocket不同，HTTP/2定义了自己的多路复用语义学：流如何获得标识符，帧如何携带它们所在流的id。HTTP/2还定义了流控制语义学，用于优先排序流。这在大多数实际应用中非常重要。

（那篇错误的文章还说Websocket标准有多路复用功能。不，它没有。要找到它并不难，只要打开Websocket RFC 6455并按⌘-F、 然后输入“多路复用”。读过之后

该协议旨在可扩展；未来的版本可能会引入更多的概念，如多路复用。

您会发现Websocket多路复用有2013年的草案扩展。但我不知道哪种浏览器（如果有的话）支持这一点。我不会尝试在该扩展的基础上构建我的SPA webapp，尤其是在HTTP/2即将到来的情况下，支持可能永远不会到来）。

多路复用正是每当你为bidi打开websocket时，你通常必须自己做的事情，比如说，为一个反应式更新的单页应用提供动力。我很高兴它在HTTP/2规范中，一劳永逸地解决了这个问题。

如果你想知道HTTP/2能做什么，只需看看gRPC。gRPC是通过HTTP/2实现的。请特别关注gRPC提供的半双工和全双工流媒体选项。（请注意，gRPC目前在浏览器中不起作用，但这实际上是因为浏览器（1）不向客户端javascript公开HTTP/2框架，以及（2）通常不支持gRPC规范中使用的预告片。）

websockets在哪里还有一席之地？最大的一个是服务器-

编辑：2020年1月17日

随着时间的推移，这个答案逐渐上升到顶部（这是好的，因为这个答案或多或少是正确的）。然而，仍然偶尔有评论说，由于各种原因，它是不正确的，通常与一些关于PUSH_PROMISE或如何实际使用面向消息的服务器的困惑有关-

如果你需要构建一个实时聊天应用程序，比如说，你需要向聊天室中所有有开放连接的客户端广播新的聊天信息，你可以（而且可能应该）在没有WebSocket的情况下实现这一点。

您可以使用服务器发送的事件向下推送消息，使用Fetch api向上发送请求。Server Sent Events（SSE）是一种鲜为人知但受广泛支持的API，它将面向消息的服务器公开给客户端流。虽然在客户端JavaScript看来不是这样，但在后台，浏览器（如果它支持HTTP/2）将重用单个TCP连接来多路传输所有这些消息。没有效率损失，事实上，这是对WebSocket的好处，因为页面上的所有其他请求也共享同一个TCP连接。需要多条流吗？打开多个事件源！它们将自动为您多路传输。

与websocket握手相比，服务器发送的事件除了资源效率更高、初始延迟更少之外，还有一个很好的特性，即它们会自动回退，并在HTTP/1.1上工作。但是当你有一个HTTP/2连接时，它们工作得非常好。

下面是一篇很好的文章，其中有一个实现反应式更新SPA的真实示例。