我正在学习HTTP / 2协议 . 这是一个带有小消息帧的二进制协议 . 它允许通过单个TCP连接进行流复用 . 从概念上讲，它似乎与WebSockets非常相似 .
是否有计划废弃websockets并用某种无头HTTP / 2请求和服务器启动的推送消息替换它们？或者WebSockets是否会补充HTTP / 2？
据我所知，HTTP / 2不是websocket的替代品，但旨在标准化SPDY协议 .
在HTTP / 2中，在场景后面使用server-push来改善客户端从浏览器加载资源 . 作为开发人员，您在开发过程中并不真正关心它 . 但是，使用Websocket，开发人员可以使用API，该API能够使用唯一的全双工连接来使用和推送消息 .
这些不是一回事，它们应该相互补充 .
我说Nay（Websockets没有过时） .
第一个也是最常被忽视的问题是代理，路由器，其他中介甚至是浏览器的 HTTP/2 push isn't enforceable and might be ignored .
即（来自HTTP2草案）：
中介可以从服务器接收推送，并选择不将它们转发到客户端 . 换句话说，如何利用推送的信息取决于该中介 . 同样，中间人可能会选择向客户端进行额外推送，而不会对服务器采取任何操作 .
此外，HTTP / 2连接会在一段时间后关闭 .
确实，该标准规定：
HTTP / 2连接是持久的 . 为了获得最佳性能，在确定不需要与服务器进一步通信（例如，当用户离开特定网页时）或直到服务器关闭连接之前，预计客户端不会关闭连接 .
但...
鼓励服务器尽可能长时间地保持打开的连接，但如果需要，可以允许终止空闲连接 . 当任一 endpoints 选择关闭传输层TCP连接时，终止 endpoints 应首先发送GOAWAY（第6.8节）帧，以便两个 endpoints 可以可靠地确定先前发送的帧是否已被处理并正常完成或终止任何必要的剩余任务 .
即使相同的连接允许在打开内容时推送内容，即使HTTP / 2解决了HTTP / 1.1的'keep-alive'引入的一些性能问题...... HTTP / 2连接也无法无限期保持打开状态 .
一旦关闭，网页也不能重新启动HTTP / 2连接（除非我们回到长拉，即） .
EDIT (2017, two years later)
HTTP / 2的实现显示多个浏览器选项卡/窗口共享一个HTTP / 2连接，这意味着 push 永远不会知道它属于哪个选项卡/窗口，从而无需使用 push 替代Websockets .
push
刚刚读完HTTP/2 spec后，我认为HTTP / 2在大多数用例中都会废弃websockets，但可能并非全部 .
PUSH_PROMISE （俗称服务器推送）不是这里的问题 . 这只是一次性能优化 .
PUSH_PROMISE
浏览器中Websockets的主要用例是启用双向数据流 . 所以，我认为OP的问题在于HTTP / 2是否能更好地在浏览器中启用双向流，我认为是的，确实如此 .
首先，它是bi-di . 只需阅读streams section的介绍：
“流”是在HTTP / 2连接中在客户端和服务器之间交换的独立的双向帧序列 . 流有几个重要特征：单个HTTP / 2连接可以包含多个并发打开的流，其中任一 endpoints 交叉来自多个流的帧 . 流可以单方面 Build 和使用，也可以由客户端或服务器共享 . 任何 endpoints 都可以关闭流 .
像this（在另一个答案中链接）这样的文章在HTTP / 2的这个方面是错误的 . 他们说HTTP / 2会发生这种情况：连接打开后，服务器可能与websockets差别不大：客户端必须在服务器发送数据之前发起websocket升级请求 . 在HTTP / 2和Websocket中，一旦客户端通过请求数据来填充泵，双方都可以随时在持久套接字上发送帧 - 完全双向 . HTTP / 2的这种可能性只是一种退化的基本情况，你想要使用HTTP / 2实现的一些额外功能，比如流多路复用 .
多路复用很重要 . 与websockets不同，HTTP / 2定义了自己的多路复用语义：流如何获取标识符以及帧如何携带它们所在的流的id . HTTP / 2还定义了用于对流进行优先级排序的流控制语义 .
（哦，是的，那篇错误的文章也说Websocket标准有多路复用 . 不，它并不是很难找到它，只是打开Websocket RFC 6455并按⌘-F，然后键入"multiplex" . 你读完以后
该协议旨在可扩展;未来的版本可能会引入其他概念，如多路复用 .
您会发现有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位vs每帧HTTP / 2 2 ^ 24-1比特） . 因此，如果你需要一个插座来吸收脂肪而没有很多仪式，比如，我不知道，也许是视频帧，那么websockets可能仍然有意义 . 对于大多数用例，特别是与网页相关的事情，我认为HTTP / 2看起来像是前进的方向 .
答案是不 . 两者之间的目标非常不同 . 甚至还有一个基于HTTP / 2的WebSocket RFC，它允许您通过单个HTTP / 2 TCP管道 Build 多个WebSocket连接 .
WS over HTTP / 2将通过减少打开新连接的时间和允许更多通信信道而不增加更多套接字，软IRQ和缓冲器的费用来节省资源 .
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
那么，引用this InfoQ文章：
嗯，答案显然是否定的，原因很简单：正如我们上面所见，HTTP / 2引入了服务器推送，使服务器能够主动将资源发送到客户端缓存 . 但是，它不允许将数据推送到客户端应用程序本身 . 服务器推送仅由浏览器处理，不会弹出到应用程序代码，这意味着应用程序没有API来获取这些事件的通知 .
因此，HTTP2推送实际上是浏览器和服务器之间的东西，而Websockets实际上暴露了客户端（javascript，如果它在浏览器上运行）和应用程序代码（在服务器上运行）可用于传输实时数据的API .
消息交换和简单流（不是音频，视频流）可以通过Http / 2多路复用和WebSockets完成 . 因此存在一些重叠，但WebSockets具有良好 Build 的协议，许多框架/ API和较少的头部开销 . Here is nice article about the topic .
我不这么认为，如果推/拉和全双工可用作http / 2的一部分，那么我为什么要建议使用WebSocket，这显然是一个额外的开销 . 我应该说是的，它肯定会淘汰WebSocket
7 回答
据我所知，HTTP / 2不是websocket的替代品，但旨在标准化SPDY协议 .
在HTTP / 2中，在场景后面使用server-push来改善客户端从浏览器加载资源 . 作为开发人员，您在开发过程中并不真正关心它 . 但是，使用Websocket，开发人员可以使用API，该API能够使用唯一的全双工连接来使用和推送消息 .
这些不是一回事，它们应该相互补充 .
我说Nay（Websockets没有过时） .
第一个也是最常被忽视的问题是代理，路由器，其他中介甚至是浏览器的 HTTP/2 push isn't enforceable and might be ignored .
即（来自HTTP2草案）：
此外，HTTP / 2连接会在一段时间后关闭 .
确实，该标准规定：
但...
即使相同的连接允许在打开内容时推送内容，即使HTTP / 2解决了HTTP / 1.1的'keep-alive'引入的一些性能问题...... HTTP / 2连接也无法无限期保持打开状态 .
一旦关闭，网页也不能重新启动HTTP / 2连接（除非我们回到长拉，即） .
EDIT (2017, two years later)
HTTP / 2的实现显示多个浏览器选项卡/窗口共享一个HTTP / 2连接，这意味着
push永远不会知道它属于哪个选项卡/窗口，从而无需使用push替代Websockets .刚刚读完HTTP/2 spec后，我认为HTTP / 2在大多数用例中都会废弃websockets，但可能并非全部 .
PUSH_PROMISE（俗称服务器推送）不是这里的问题 . 这只是一次性能优化 .浏览器中Websockets的主要用例是启用双向数据流 . 所以，我认为OP的问题在于HTTP / 2是否能更好地在浏览器中启用双向流，我认为是的，确实如此 .
首先，它是bi-di . 只需阅读streams section的介绍：
像this（在另一个答案中链接）这样的文章在HTTP / 2的这个方面是错误的 . 他们说HTTP / 2会发生这种情况：连接打开后，服务器可能与websockets差别不大：客户端必须在服务器发送数据之前发起websocket升级请求 . 在HTTP / 2和Websocket中，一旦客户端通过请求数据来填充泵，双方都可以随时在持久套接字上发送帧 - 完全双向 . HTTP / 2的这种可能性只是一种退化的基本情况，你想要使用HTTP / 2实现的一些额外功能，比如流多路复用 .
多路复用很重要 . 与websockets不同，HTTP / 2定义了自己的多路复用语义：流如何获取标识符以及帧如何携带它们所在的流的id . HTTP / 2还定义了用于对流进行优先级排序的流控制语义 .
（哦，是的，那篇错误的文章也说Websocket标准有多路复用 . 不，它并不是很难找到它，只是打开Websocket RFC 6455并按⌘-F，然后键入"multiplex" . 你读完以后
您会发现有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位vs每帧HTTP / 2 2 ^ 24-1比特） . 因此，如果你需要一个插座来吸收脂肪而没有很多仪式，比如，我不知道，也许是视频帧，那么websockets可能仍然有意义 . 对于大多数用例，特别是与网页相关的事情，我认为HTTP / 2看起来像是前进的方向 .
答案是不 . 两者之间的目标非常不同 . 甚至还有一个基于HTTP / 2的WebSocket RFC，它允许您通过单个HTTP / 2 TCP管道 Build 多个WebSocket连接 .
WS over HTTP / 2将通过减少打开新连接的时间和允许更多通信信道而不增加更多套接字，软IRQ和缓冲器的费用来节省资源 .
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
那么，引用this InfoQ文章：
因此，HTTP2推送实际上是浏览器和服务器之间的东西，而Websockets实际上暴露了客户端（javascript，如果它在浏览器上运行）和应用程序代码（在服务器上运行）可用于传输实时数据的API .
消息交换和简单流（不是音频，视频流）可以通过Http / 2多路复用和WebSockets完成 . 因此存在一些重叠，但WebSockets具有良好 Build 的协议，许多框架/ API和较少的头部开销 . Here is nice article about the topic .
我不这么认为，如果推/拉和全双工可用作http / 2的一部分，那么我为什么要建议使用WebSocket，这显然是一个额外的开销 . 我应该说是的，它肯定会淘汰WebSocket