我正在学习HTTP/2协议.它是一个带有小消息帧的二进制协议.它允许通过单个TCP连接进行流复用.从概念上讲,它似乎与WebSockets非常相似.
是否有计划废弃websockets并用某种无头HTTP/2请求和服务器启动的推送消息替换它们？或者WebSockets是否会补充HTTP/2？
1> Guillaume D...：
据我所知,HTTP/2不是websocket的替代品,但旨在标准化SPDY协议.
在HTTP/2中,在场景后面使用server-push来改善客户端从浏览器加载资源.作为开发人员,您在开发过程中并不真正关心它.但是,使用Websocket,开发人员可以使用API,该API能够使用唯一的全双工连接来使用和推送消息.
这些不是一回事,它们应该相互补充.
HTTP/2确实是双向的但不是对称的,这意味着只有客户端才能发送正确的请求,服务器可以发送响应并请求promises(推送).这使得websockets在双方在允许发送/接收的方面更"平等"的意义上是不同的.
不确定HTTP/2规范是否提供有关HTTP/2起源及其与websocket的不同之处的详细信息.但是,您可以很容易地看到,使用HTTP/2,我们正在使用双向通信:http://goo.gl/IJVxWS(第6页和第13页)
谢谢Guillaume的回答.但是我想知道你(或某人)是否可以从HTTP/2规范中添加一些引用.我从博客中读到的内容等等 - 使用HTTP/2进行真正的双向通信？
IEEE的软件工程广播中有一个关于HTTP2起源的优秀播客.我想是这样的:http://www.se-radio.net/2015/07/episode-232-mark-nottingham-on-http2/
类似的答案与完整的理由可以在这篇InfoQ文章中找到:https://www.infoq.com/articles/websocket-and-http2-coexist
2> masonk..：
在完成阅读HTTP/2规范之后,我认为HTTP/2确实在大多数用例中废弃了websockets,但可能并非全部.
PUSH_PROMISE(通俗地称为服务器推送)不是这里的问题.这只是性能优化.
浏览器中Websockets的主要用例是启用双向数据流.因此,我认为OP的问题在于HTTP/2是否能更好地在浏览器中启用双向流,我认为是的,确实如此.
首先,它是 bi-di.只需阅读流部分的介绍:
"流"是在HTTP/2连接内在客户端和服务器之间交换的独立的双向帧序列.流有几个重要特征:
单个HTTP/2连接可以包含多个并发打开的流,其中任一端点交叉来自多个流的帧.
流可以单方面建立和使用,也可以由客户端或服务器共享.
任何端点都可以关闭流.
文章像这样(在另一个答案链接)只是错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".你读完以后
该协议旨在可扩展; 未来的版本可能会引入其他概念,如多路复用.
您会发现有Websocket多路复用的2013 草案扩展.但我不知道哪些浏览器(如果有的话)支持它.我不会尝试在该扩展的背面构建我的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是基于流的双向。
3> Myst..：
我说Nay(Websockets没有过时).
第一个也是最常被忽视的问题是HTTP/2推送不可强制执行,代理,路由器,其他中介甚至浏览器都可能会忽略它.
即(来自HTTP2草案):
中介可以从服务器接收推送,并选择不将它们转发到客户端.换句话说,如何利用推送的信息取决于该中介.同样,中间人可能会选择向客户端进行额外的推送,而不会对服务器采取任何操作.
此外,HTTP/2连接会在一段时间后关闭.
确实,该标准规定:
HTTP/2连接是持久的.为了获得最佳性能,在确定不需要与服务器进行进一步通信(例如,当用户离开特定网页时)或服务器关闭连接之前,预计客户端不会关闭连接.
但...
鼓励服务器尽可能长时间地保持打开的连接,但如果需要,允许服务器终止空闲连接.当任一端点选择关闭传输层TCP连接时,终止端点应首先发送GOAWAY(第6.8节)帧,以便两个端点可以可靠地确定先前发送的帧是否已被处理并正常完成或终止任何必要的剩余任务.
即使相同的连接允许在打开内容时推送内容,即使HTTP/2解决了HTTP/1.1的'keep-alive'引入的一些性能问题...... 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代理)关闭连接怎么办？客户可以假设没有新数据可用吗？我们回到民意调查.
4> bond..：
答案是不.两者之间的目标非常不同.甚至还有一个基于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
5> Jeet Prakash..：
好吧,引用这篇InfoQ文章:
好吧,答案显然是否定的,原因很简单:正如我们上面所见,HTTP/2引入了服务器推送,使服务器能够主动将资源发送到客户端缓存.但是,它不允许将数据推送到客户端应用程序本身.服务器推送仅由浏览器处理,不会弹出到应用程序代码,这意味着应用程序没有API来获取这些事件的通知.
因此,HTTP2推送实际上是浏览器和服务器之间的东西,而Websockets实际上暴露了客户端(Javascript,如果它在浏览器上运行)和应用程序代码(在服务器上运行)可用于传输实时数据的API.
6> 小智..：
可以通过Http / 2复用和WebSockets进行消息交换和简单的流传输（不是音频，视频流传输）。因此存在一些重叠，但是WebSocket具有完善的协议，大量的框架/ API和较少的标头开销。
这是有关该主题的不错的文章。
京公网安备 11010802041100号