到今天为止，还没有。

HTTP/2, compared to HTTP, allows you to maintain a connection with a server. From there, you can have multiple streams of data at the same time. The intent is that you can push multiple things at the same time even without the client requesting it. For example, when a browser asks for a index.html, the server might want to also push index.css and index.js. The browser didn't ask for it, but the server might provide it without being asked because it can assume you're going to want in a few seconds.

这比HTTP/1获取index.html，解析它，发现它需要index.js和index.css，然后为这些文件构建2个其他请求更快。HTTP/2允许服务器推送客户端甚至没有要求的数据。

在这种情况下，它类似于WebSocket，但在设计上并不是这样。WebSocket应该允许类似于TCP连接或串行连接的双向通信。它是两者相互通信的套接字。此外，主要的区别是，您可以发送任何原始字节的任意数据包，而不是封装在HTTP协议中。头、路径、查询字符串的概念只在握手期间发生，但是WebSocket打开了一个数据流。

The other difference is you get a lot more fine-tuned access to WebSocket in Javascript, whereas with HTTP, it's handled by the browser. All you get with HTTP is whatever you can fit in XHR/fetch(). That also means the browser will get to intercept and modify HTTP headers without you being able to control it (eg: Origin, Cookies, etc). Also, what HTTP/2 is able to push is sent to the browser. That means JS doesn't always (if ever) know things are being pushed. Again, it makes sense for index.css and index.js because the browser will cache it, but not so much for data packets.

一切都在于名字。HTTP代表超文本传输协议。我们围绕着资产转移的概念。WebSocket是关于构建一个套接字连接，其中二进制数据可以双向传递。

我们没有真正讨论的是SSE(服务器发送事件)。将数据推送到应用程序(JS)不是HTTP/2的意图，但它是SSE的目的。SSE在HTTP/2中得到了真正的加强。但当重要的是数据本身，而不是到达的变量端点时，它并不是WebSockets的真正替代品。对于WebSocket中的每个端点，都会创建一个新的数据流，但是对于SSE，它会在已经存在的HTTP/2会话之间共享。

以下是每项目标的总结:

HTTP—用一个资产响应请求 HTTP/2 -用多个资产响应请求 SSE -响应一个单向文本(UTF-8)事件流 创建一个双向二进制数据流

在读完RFC 7540之后，HTTP/2在所有用例中都使用了过时的websocket，除了将二进制数据从服务器推送到JS webclient。HTTP/2完全支持二进制bidi流(请继续阅读)，但浏览器JS没有用于消费二进制数据帧的API，而且AFAIK也没有这样的API计划。

对于bidi流的其他应用，HTTP/2和websockets一样好，甚至更好，因为(1)规范为你做了更多的工作，(2)在许多情况下，它允许较少的TCP连接被打开到一个原点。

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

Websockets在浏览器中的主要用途是支持双向数据流。所以，我认为OP的问题是HTTP/2是否能更好地在浏览器中实现双向流，我认为是的，它是。

首先，它是bi-di。请阅读streams部分的介绍:

一个“流”是一个独立的、双向的帧序列 在HTTP/2连接中客户端和服务器之间交换。 流有几个重要的特征: 一个HTTP/2连接可以包含多个并发打开的连接 流，任一端点交错来自多个帧 流。 流可以单方面建立和使用，也可以由共享 客户端或服务器。 流可以被任意一个端点关闭。

像这样的文章(在另一个答案中有链接)在HTTP/2的这方面是错误的。他们说那不是比迪。看，有一件事是HTTP/2不能发生的:连接打开后，服务器不能启动常规流，只能启动推送流。但是一旦客户端通过发送请求打开了一个流，双方都可以在任何时候通过一个持久套接字发送数据帧- full bidi。

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

最大的不同是，与websockets不同，HTTP/2定义了自己的多路复用语义:流如何获得标识符以及帧如何携带它们所在的流的id。HTTP/2还为流的优先级定义了流控制语义。这在bidi的大多数实际应用中非常重要。

(那篇错误的文章还说Websocket标准有多路复用。不，它没有。这并不难找到，只需打开Websocket RFC 6455并按⌘-F，然后输入“multiplex”。读完之后

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

你会发现2013年Websocket多路复用的扩展草案。但我不知道哪些浏览器支持这个功能。我不会尝试在这个扩展的背后构建我的SPA web应用程序，特别是随着HTTP/2的到来，支持可能永远不会到来)。

多路复用正是你在为bidi打开websocket时通常必须做的事情，比如说，为一个反应性更新的单页应用程序提供动力。我很高兴它在HTTP/2规范中，得到了一次性的解决。

如果你想知道HTTP/2能做什么，看看gRPC就知道了。gRPC是跨HTTP/2实现的。具体看一下gRPC提供的半双工和全双工流选项。(请注意，gRPC目前不能在浏览器中工作，但这实际上是因为浏览器(1)不会向客户端javascript公开HTTP/2框架，(2)通常不支持gRPC规范中使用的预告片。)

websocket在哪里还有一席之地?其中较大的是server->浏览器推送的二进制数据。HTTP/2确实允许server->浏览器推送二进制数据，但它不会在浏览器JS中公开。对于像推送音频和视频帧这样的应用程序，这是使用websockets的一个原因。

编辑时间:2020年1月17日

随着时间的推移，这个答案逐渐上升到顶部(这很好，因为这个答案或多或少是正确的)。然而，偶尔仍有评论说，由于各种原因，这是不正确的，通常与一些关于PUSH_PROMISE或如何实际消费面向消息的服务器->客户端推在一个单页应用程序的困惑。

如果你需要构建一个实时聊天应用程序，比如说，你需要向聊天室中所有打开连接的客户端广播新的聊天消息，你可以(也可能应该)不需要websockets。

You would use Server-Sent Events to push messages down and the Fetch api to send requests up. Server-Sent Events (SSE) is a little-known but well supported API that exposes a message-oriented server-to-client stream. Although it doesn't look like it to the client JavaScript, under the hood your browser (if it supports HTTP/2) will reuse a single TCP connection to multiplex all of those messages. There is no efficiency loss and in fact it's a gain over websockets because all the other requests on your page are also sharing that same TCP connection. Need multiple streams? Open multiple EventSources! They'll be automatically multiplexed for you.

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

下面是一篇很好的文章，它提供了一个实现响应式更新SPA的真实示例。

消息交换和简单的流(不是音频，视频流)可以通过Http/2多路复用和WebSockets来完成。所以有一些重叠，但是WebSockets有很好的协议，很多框架/ api和更少的头开销。 这里有一篇关于这个主题的好文章。

不，WebSockets并没有过时。然而，HTTP/2打破了为HTTP/1.1定义的websocket(主要是通过禁止使用Upgrade报头进行协议更新)。这就是为什么这个rfc:

https://datatracker.ietf.org/doc/html/rfc8441

定义了HTTP/2的websocket引导过程。

引用InfoQ的一篇文章:

好吧，答案显然是否定的，原因很简单:正如我们上面所看到的，HTTP/2引入了Server Push，它使服务器能够主动地向客户端缓存发送资源。但是，它不允许将数据下推到客户机应用程序本身。服务器推送仅由浏览器处理，不会弹出到应用程序代码中，这意味着应用程序没有API来获取这些事件的通知。

所以HTTP2推送实际上是浏览器和服务器之间的东西，而Websockets实际上公开了可以被客户端(javascript，如果它运行在浏览器上)和应用程序代码(运行在服务器上)使用的api来传输实时数据。

根据我的理解，HTTP/2不是websocket的替代品，而是旨在标准化SPDY协议。

在HTTP/2中，服务器推送(server-push)在后台使用，以改善客户端从浏览器加载资源的情况。作为一名开发人员，你在开发过程中并不会真正关心它。然而，使用Websocket，开发者可以使用API，它可以使用唯一的全双工连接来消费和推送消息。

这些不是一回事，它们应该是相辅相成的。