关于http2：HTTP / 2是否会使websocket过时？

Does HTTP/2 make websockets obsolete?

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

是否有计划淘汰Websocket，并用某种无头HTTP / 2请求和服务器启动的推送消息替换它们？还是WebSockets可以补充HTTP / 2？

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

在HTTP / 2中，幕后使用server-push来改善客户端从浏览器的资源加载。作为开发人员，您在开发期间并不十分在意。但是，使用Websocket，允许开发人员使用API??，该API能够通过唯一的全双工连接使用和推送消息。

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

相关讨论

在刚阅读完HTTP / 2规范后，我认为HTTP / 2在大多数用例中确实过时了，因此，并不是全部。

PUSH_PROMISE(俗称服务器推送)在这里不是问题。那只是性能优化。

浏览器中Websocket的主要用例是启用双向数据流。因此，我认为OP的问题在于HTTP / 2是否在启用浏览器中的双向流传输方面做得更好，我认为是的。

首先，它是bi-di。只需阅读流部分的介绍：

A"stream" is an independent, bidirectional sequence of frames
exchanged between the client and server within an HTTP/2 connection.
Streams have several important characteristics:

A single HTTP/2 connection can contain multiple concurrently open
streams, with either endpoint interleaving frames from multiple
streams.

Streams can be established and used unilaterally or shared by
either the client or server.

Streams can be closed by either endpoint.

这样的文章(在另一个答案中链接)关于HTTP / 2的这方面是错误的。他们说这不是比迪烟。看，HTTP / 2不会发生一件事：打开连接后，服务器无法启动常规流，只能启动推送流。但是，一旦客户端通过发送请求打开流，双方就可以随时通过持久套接字发送DATA帧-完整的比迪。

这与websockets没什么不同：客户端也必须发起一个websocket升级请求，服务器才能发送数据。

最大的区别在于，与websocket不同，HTTP / 2定义了自己的多路复用语义：流如何获取标识符以及帧如何携带其所在流的ID。 HTTP / 2还定义了用于对流进行优先级排序的流控制语义。这在比迪的大多数实际应用中都很重要。

(那篇错误的文章还说Websocket标准具有多路复用。不，不是。要发现这一点并不难，只需打开Websocket RFC 6455并按？-F，然后键入" multiplex"即可。

The protocol is intended to be extensible; future versions will likely introduce additional concepts such as multiplexing.

您会发现有用于Websocket复用的2013年扩展草案。但是我不知道哪些浏览器支持该功能。我不会尝试在该扩展程序的后面构建我的SPA webapp，尤其是在HTTP / 2出现的情况下，该支持可能永远无法到达)。

完全是多路复用，通常是每当您打开一个用于bidi的websocket(例如，以响应式更新单页应用程序的方式)时，就必须做的事情。我很高兴它在HTTP / 2规范中，一劳永逸。

如果您想知道HTTP / 2可以做什么，只需看一下gRPC。 gRPC是在HTTP / 2上实现的。请专门看一下gRPC提供的半双工和全双工流选项。 (请注意，gRPC当前在浏览器中不起作用，但这实际上是因为浏览器(1)不会向客户端JavaScript公开HTTP / 2框架，而(2)通常不支持Trailer，后者用于gRPC规范。)

Websocket可能还在哪里？如果您不需要HTTP / 2规范指定的任何额外位(这是一个庞大，复杂的规范)，那么websockets可能会更好。挥舞着实现的难度，我相信遵守websocket协议的计算量总是比HTTP / 2少-HTTP / 2只需要您做更多的事情。

框架的大小非常可比。与HTTP / 2的固定9相比，Websocket帧要小一些，每帧2-14字节的开销。由于Websocket选择了可变长度的报头，因此它可以编码较大的帧(每帧最多2 ^ 64-1位，而每帧HTTP / 2 2 ^ 24-1位)。因此，如果您需要一个插座来吸掉一些脂肪而无需进行很多仪式，例如，我不知道，也许是视频帧，那么网络套接字可能仍然有意义。对于大多数用例，尤其是与网页有关的事情，我认为HTTP / 2看起来像是前进的道路。

相关讨论

我说不(Websocket并不过时)。

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

即(来自HTTP2草案)：

An intermediary can receive pushes from the server and choose not to forward them on to the client. In other words, how to make use of the pushed information is up to that intermediary. Equally, the intermediary might choose to make additional pushes to the client, without any action taken by the server.

同样，HTTP / 2连接会在一段时间后关闭。

标准确实指出：

HTTP/2 connections are persistent. For best performance, it is expected that clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page) or until the server closes the connection.

但...

Servers are encouraged to maintain open connections for as long as possible but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the transport-layer TCP connection, the terminating endpoint SHOULD first send a GOAWAY (Section 6.8) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks.

即使同一连接允许在打开内容时推送内容，即使HTTP / 2解决了HTTP / 1.1的"保持活动"引入的某些性能问题，HTTP / 2连接也不会无限期保持打开状态。

一旦关闭，网页也无法重新启动HTTP / 2连接(除非我们返回到长拉状态)。

编辑(2017年，两年后)

HTTP / 2的实现显示多个浏览器选项卡/窗口共享一个HTTP / 2连接，这意味着push将永远不知道它属于哪个选项卡/窗口，从而无需使用push替代Websockets。

相关讨论

WS套接字也不会永远保持打开状态。区别在于流； HTTP / 2为您提供了多个流流，这意味着服务器上的流控制是非常不同的，并且通常是无锁的。 WS(作为协议)必须具有不受管制的入站处理。流控制在堆栈的更高位置实现。在安全性和服务器完整性方面，HTTP / 2比WS更好。
@bond，我同意HTTP / 2作为传输层具有许多优点(在许多浏览器选项卡中共享一个连接只是一个示例)。但是，它不是设计为通信层。这是一个功能性的问题。两种协议都满足不同的需求。即使用Websockets时在浏览器上实现ssh终端很容易。 HTTP / 2会让您头疼不已，特别是如果打开了一个以上的选项卡。另外，如果浏览器(或HTTP / 2代理之一)关闭了连接怎么办？客户可以假设没有新数据可用吗？回到投票。
浏览器可以轻松关闭WS连接。任何形式的网络连接就是生命。老实说，HTTP / 2中的多路复用是过大的。该协议真的不需要它。通过打开多个流，您开始遇到TCP缓冲区限制吞吐量的问题。我同意您的观点，WS比HTTP / 2做得更好。从根本上讲，WS是需要很多高级控制才能防止用户做坏事的东西。
引用本叔叔(蜘蛛侠)的话："记住，权力越大，责任就越大"。是的，@ bond，您非常正确。 Websocket是一种非常"原始"的协议，需要更负责任的服务器设计。是的，WS可以像HTTP / 2一样容易地关闭，但是WS支持onclose回调，因此不需要轮询。至于多路复用，我认为这是必要的，而不是选择。 keep-alive失败了，避免"第一线"性能下降的唯一方法是冒险多路复用。时间会证明:)
从服务器设计的角度来看，出站复用是一个复杂且昂贵的问题。这就需要IO机械师在内部进行轮询，这真是太贵了。除非您正在流式传输大型文档，否则多路复用甚至无法起作用，因为在第二个偶数变为可用且多路复用无法运行之前，请求可能已经在内部进行了响应和完全缓冲。 RTMP具有出站多路复用，但是只有Adobes服务器可以执行。令人惊讶的是，HTTP / 2与RTMP如此接近。

答案是不。两者之间的目标有很大的不同。甚至还有一个用于HTTP / 2上的WebSocket的RFC，它允许您通过单个HTTP / 2 TCP管道建立多个WebSocket连接。

通过减少打开新连接的时间并允许更多的通信通道，而不会增加更多的套接字，软IRQ和缓冲区的开销，HTTP over WS上的WS将成为一种资源节约型游戏。

https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01

相关讨论

太棒了！是否有实现此功能的Javascript客户端有任何公开示例？我找不到任何例子。我该怎么办？这是好资源吗？ undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html
有谁知道上述要求的来源：1)查找标头的长度； 2)下划线的字段名称？
@PimHeijden要检测HTTP / 1.x中的标头长度，需要循环遍历所有字节以查找4个字节的结束标记。那是非常昂贵的。字段名称不区分大小写也意味着必须对字符的大写和小写版本都进行任何字段匹配。这要求了解整个字符集的大小写，以便进行检查。在2.x中，您可以假定它们是小写字母。
@RaisinBranCrunch您无法通过Javascript控制任何此类操作。浏览器为您完成所有操作。
@bond Im当前将HTTP / 2与Nginx一起使用，并使用proxy_pass将Websocket连接发送到套接字服务器，但是当我有一个用户在网站中打开多个选项卡时，套接字服务器会将其视为多个连接。我假设如果HTTP / 2通过一个TCP管道多路复用连接，则服务器会将其视为一个连接。错了吗有什么方法可以验证服务器没有进行不必要的额外连接吗？
@RaisinBranCrunch WebSockets使用升级命令在HTTP / 1.1上运行，但尚不兼容HTTP / 2。参见blog.sessionstack.com/
@RaisinBranCrunch对不起，我登录了错误的帐户。那令人困惑。
@bond您可以支持上一次编辑中提出的主张吗？尽管与主要问题的关系尚不清楚，但是与1)长度和2)标头的小写框有关的那些性能提升非常有趣。很难找到好的却简单的文章。
@PimHeijden-我没有关于它或任何东西的论文。我已经编写了三台HTTP服务器-都具有不同级别的复杂性和用途，以便针对特定用例获得最佳性能。遍历字节流中的所有字节以查找四个字节的标记非常昂贵，除非您用C编写服务器，否则您必须真正发挥作用。如果您尝试每秒消耗1+百万条HTTP / 1.1消息，循环会消耗很多周期。
@bond所以答案是否定的？在某个地方阅读您的结果会很酷。
@PimHeijden Id很高兴与您进一步讨论此问题，但这确实不是一个好地方。

好吧，引用此InfoQ文章：

Well, the answer is clearly no, for a simple reason: As we have seen above, HTTP/2 introduces Server Push which enables the server to proactively send resources to the client cache. It does not, however, allow for pushing data down to the client application itself. Server pushes are only processed by the browser and do not pop up to the application code, meaning there is no API for the application to get notifications for those events.

因此，HTTP2推送确实是您的浏览器和服务器之间的东西，而Websockets确实公开了可供客户端(javascript(如果其在浏览器上运行))和应用程序代码(在服务器上运行)都可以用来传输实时数据的API。

可以通过Http / 2复用和WebSockets进行消息交换和简单的流传输(不是音频，视频流传输)。因此存在一些重叠，但是WebSocket具有完善的协议，大量的框架/ API和较少的标头开销。
这是有关该主题的不错的文章。

HTTP / 2中将有WebSocket实现。
https://tools.ietf.org/html/rfc8441