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

有没有计划淘汰websockets,代之以某种无头HTTP/2请求和服务器发起的推送消息?或者WebSockets将补充HTTP/2?


当前回答

引用InfoQ的一篇文章:

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

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

其他回答

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

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

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

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

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

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

到2020年4月为止,HTTP/2还没有淘汰WebSockets。WebSockets相对于HTTP2的最大优势是

HTTP/2 works only on Browser Level not Application Level

意味着HTTP/2不提供任何像WebSockets那样的JS API来允许通信和直接从应用程序(例如网站)向服务器传输某种JSON或其他数据。所以,就我所相信的,只有当HTTP/2开始提供类似WebSockets的API来与服务器通信时,WebSockets才会被淘汰。在此之前,它只是更新和更快的HTTP 1.1版本。

答案是否定的。两者之间的目标是非常不同的。甚至有一个基于HTTP/2的WebSocket的RFC,它允许你在一个单一的HTTP/2 TCP管道上建立多个WebSocket连接。

通过减少打开新连接的时间,允许更多的通信通道,而不增加更多套接字、软irq和缓冲区的开销,HTTP/2上的WS将是一个资源节约的游戏。

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

到今天为止,还没有。

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)事件流 创建一个双向二进制数据流