我正在学习HTTP / 2协议。它是具有小消息帧的二进制协议。它允许通过单个TCP连接进行流复用。从概念上讲，它似乎与WebSockets非常相似。
是否有计划废弃websockets并用某种无头HTTP / 2请求和服务器启动的推送消息替换它们？或者WebSockets是否会补充HTTP / 2？
答案 0 :(得分：129)
据我所知，HTTP / 2不是websocket的替代品，但旨在标准化SPDY协议。
在HTTP / 2中，在场景后面使用server-push来改善客户端从浏览器加载资源。作为开发人员，您在开发过程中并不十分关心它。但是，使用Websocket，开发人员可以使用能够使用唯一的全双工连接来使用和推送消息的API。
这些不是一回事，它们应该相互补充。
答案 1 :(得分：80)
刚刚读完HTTP/2 spec后，我认为HTTP / 2在大多数用例中都会废弃websockets，但可能不是全部。
PUSH_PROMISE（俗称服务器推送）不是问题所在。这只是一次性能优化。
浏览器中Websockets的主要用例是启用双向数据流。因此，我认为OP的问题在于HTTP / 2是否能更好地在浏览器中启用双向流，我认为是的，确实如此。
首先，是 bi-di。请阅读streams section的简介：
A＆＃34; stream＆＃34;是一个独立的双向帧序列 在HTTP / 2连接中在客户端和服务器之间交换。 流有几个重要特征：
单个HTTP / 2连接可以包含多个并发打开的连接 流，其中任一端点交织来自多个的帧 流。
可以单方面建立和使用流，也可以共享流 客户端或服务器。
Streams可以被任一端点关闭。
像this这样的文章（在另一个答案中链接）在HTTP / 2的这个方面是错误的。他们说这不是比迪。看，HTTP / 2有一件事情不会发生：打开连接后，服务器无法启动常规流，只能推送流。但是一旦客户端通过发送请求打开流，双方都可以随时通过持久套接字发送DATA帧 - 完全双向。
与websockets没什么不同：客户端必须在服务器发送数据之前发起websocket升级请求。
最大的区别在于，与websockets不同，HTTP / 2定义了自己的多路复用语义：流如何获取标识符以及帧如何携带它们所依赖的流的id。 HTTP / 2还定义了用于对流进行优先级排序的流控制语义。这在bidi的大多数实际应用中都很重要。
（那篇错误的文章还说Websocket标准有多路复用。不，它没有。要找到它并不是很难，只需打开Websocket RFC 6455然后按⌘ -F，并键入＆＃34; multiplex＆＃34;。阅读后
该协议旨在可扩展;未来版本可能会引入其他概念，例如多路复用。
你会发现2013 draft extension用于Websocket多路复用。但我不知道哪些浏览器（如果有的话）支持它。我不会尝试在该扩展的背面构建我的SPA webapp，特别是在HTTP / 2即将到来的情况下，支持可能永远不会到达。
多路复用正是您通常需要自己做的事情，例如，当您为bidi打开websocket时，例如，为反应性更新的单页应用程序提供动力。我很高兴它在HTTP / 2规范中，一劳永逸地处理。
如果您想知道HTTP / 2可以做什么，只需看看gRPC。 gRPC跨HTTP / 2实现。请特别注意gRPC提供的半双工和全双工流选项。 （请注意，gRPC当前不在浏览器中工作，但这实际上是因为浏览器（1）不会将HTTP / 2帧暴露给客户端javascript，并且（2）通常不支持预告片，用于gRPC规范。）
websockets哪里可以有位置？如果你不需要任何 HTTP / 2规范的额外位（它是一个巨大的，复杂的规范），那么websockets可能更好。挥手解决实施难度，我相信遵守websocket协议总是比HTTP / 2的计算成本更低 - HTTP / 2只需要你做更多的东西。
框架的大小非常可比。与HTTP / 2固定的9相比，Websocket帧略小，每帧2-14字节的开销。因为websocket选择了可变长度的头，它可以编码更大的帧（最多2 ^ 64-1）每帧的比特数与每帧的HTTP / 2 2 ^ 24-1比特数）。因此，如果你需要一个插座来吸收脂肪而没有很多仪式，比如，我不知道，也许是视频帧，那么websockets可能仍然有意义。对于大多数用例，特别是与网页相关的事情，我认为HTTP / 2看起来就像是前进的方式。
答案 2 :(得分：53)
我说Nay（Websockets没有过时）。
第一个也是最常被忽视的问题是代理，路由器，其他中介甚至浏览器 HTTP / 2推送不可强制执行且可能被忽略。
即。 （来自HTTP2草案）：
中介可以从服务器接收推送，并选择不将它们转发到客户端。换句话说，如何利用推送的信息取决于该中介。同样，中间人可能会选择向客户端进行额外推送，而不会对服务器采取任何操作。
此外，HTTP / 2连接会在一段时间后关闭。
标准确实声明：
HTTP / 2连接是持久的。为了获得最佳性能，在确定不需要与服务器进一步通信（例如，当用户离开特定网页时）或服务器关闭连接之前，客户端不会关闭连接。 / p>
但是...
鼓励服务器尽可能长时间地保持打开的连接，但如果需要，可以终止空闲连接。当任一端点选择关闭传输层TCP连接时，终止端点应首先发送GOAWAY（第6.8节）帧，以便两个端点可以可靠地确定先前发送的帧是否已被处理并正常完成或终止任何必要的剩余任务。
即使相同的连接允许在内容打开时推送内容，即使HTTP / 2解决了HTTP / 1.1的'keep-alive'引入的一些性能问题...... HTTP / 2连接也不是无限期地保持开放。
一旦关闭，网页也不能重新启动HTTP / 2连接（除非我们回到长时间拉动，就是这样）。
编辑（2017年，两年后）
HTTP / 2的实现显示多个浏览器选项卡/窗口共享一个HTTP / 2连接，这意味着push将永远不知道它属于哪个选项卡/窗口，从而无法使用push作为Websockets的替代品。
答案 3 :(得分：35)
答案是否定的。两者之间的目标非常不同。甚至还有一个基于HTTP / 2的WebSocket RFC，允许您通过单个HTTP / 2 TCP管道建立多个WebSocket连接。
WS over HTTP / 2将通过减少打开新连接的时间和允许更多通信通道而不增加更多套接字，软IRQ和缓冲区的费用来节省资源。https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
答案 4 :(得分：9)
嗯，引用this InfoQ文章：
嗯，答案显然是否定的，原因很简单：正如我们上面所见，HTTP / 2引入了服务器推送，使服务器能够主动将资源发送到客户端缓存。但是，它不允许将数据推送到客户端应用程序本身。服务器推送仅由浏览器处理，不会弹出到应用程序代码，这意味着应用程序没有API来获取这些事件的通知。
所以HTTP2推送实际上是浏览器和服务器之间的东西，而Websockets确实暴露了客户端可以使用的API（javascript，如果它在浏览器上运行）和应用程序代码（在服务器上运行）以实时传输数据
答案 5 :(得分：5)
截止到今天，没有。
与HTTP相比， HTTP / 2允许您维护与服务器的连接。从那里，您可以同时拥有多个数据流。目的是即使您没有客户端请求，也可以同时推送多个内容。例如，当浏览器要求输入index.html时，服务器可能还希望同时推送index.css和index.js。浏览器并没有要求它，但是服务器可能会在没有要求的情况下提供它，因为它可以假设您将在几秒钟内想要得到它。
这比获得index.html，对其进行解析，发现它需要index.js和index.css并通过然后建立另外2个请求的HTTP / 1替代方法要快。这些文件。 HTTP / 2使服务器可以推送客户端甚至不需要的数据。
在这种情况下，它与WebSocket相似，但并非完全是设计使然。 WebSocket应该允许类似于TCP连接或串行连接的双向通信。这是一个彼此通信的套接字。而且，主要区别在于您可以发送任何原始数据字节中的任意数据包，而不用HTTP协议封装。标头，路径，查询字符串的概念仅在握手期间发生，但WebSocket会打开数据流。
另一个区别是，您可以使用Javascript对WebSocket进行更精细的访问，而使用HTTP，则由浏览器处理。使用HTTP所能获得的就是XHR / fetch()中适合的内容。这也意味着浏览器将无法拦截和修改HTTP标头（例如：Origin，Cookies等）。同样，HTTP / 2能够推送的内容也会发送到浏览器。这意味着JS并不总是（如果有的话）知道事物被推送。再次，对于index.css和index.js来说是有意义的，因为浏览器将对其进行缓存，但对于数据包则不那么重要。
实际上就是名字。 HTTP代表超文本传输协议。我们致力于转移资产的概念。 WebSocket是关于建立套接字连接的，二进制数据将双向传递。
我们没有真正讨论的是SSE（服务器发送的事件）。将数据推送到应用程序（JS）并不是HTTP / 2的意图，而是用于SSE的。使用HTTP / 2确实增强了SSE。但是，当重要的是数据本身而不是到达变量端点时，这并不是WebSockets的真正替代。对于使用WebSocket的每个终结点，都会创建一个新的数据流，但是使用SSE，它会在已存在的HTTP / 2会话之间共享。
这里总结了每个目标：
答案 6 :(得分：3)
消息交换和简单流式传输（不是音频，视频流）可以通过Http / 2多路复用和WebSockets完成。因此存在一些重叠，但WebSockets具有良好建立的协议，许多框架/ API和较少的头部开销。 Here is nice article about the topic
答案 7 :(得分：2)
将在HTTP / 2中实现WebSocket。 https://tools.ietf.org/html/rfc8441
答案 8 :(得分：2)
在2020年4月之前，HTTP / 2并未使WebSockets过时。与HTTP2相比，WebSockets的最大优势在于
HTTP/2 works only on Browser Level not Application Level
表示HTTP / 2不提供任何JS API（例如WebSockets）来允许通信并将某些JSON或其他数据直接从应用程序（例如网站）传输到服务器。因此，据我所知，HTTP / 2仅在开始提供诸如WebSockets之类的API来与服务器通信时才会使WebSockets过时。直到它只是HTTP 1.1的更新版本和更快的版本。
答案 9 :(得分：0)
不，WebSockets 并没有过时。但是，HTTP/2 破坏了为 HTTP/1.1 定义的 websockets（主要是通过使用 Upgrade 标头禁止协议更新）。这就是为什么这个 rfc:
https://datatracker.ietf.org/doc/html/rfc8441
为 HTTP/2 定义了一个 websocket 引导程序。
答案 10 :(得分：-4)
我不这么认为，如果推/拉和全双工可用作http / 2的一部分，那么我为什么要建议使用WebSocket，这显然是额外的开销。我应该说是的，它肯定会淘汰WebSocket