HTTP/2世界中的WebSockets替代方案是什么?

问题描述

新的HTTP/2协议具有一些有希望的功能.其中一些:

• 多路复用-单个TCP连接可用于发出多个HTTP/2请求并接收多个响应(针对单个来源)
• HTTP/2服务器推送-在不接收请求(即由服务器发起的请求)的情况下向客户端发送服务器响应
• 双向连接- HTTP/2规范-流和多路复用:

此处解释了HTTP/2的动机 HTTP/2常见问题解答:

和

所以HTTP/2很不错，可以代替HTTP/1.x.不幸的是， HTTP/2不支持WebSockets .在这个问题中 HTTP/2是否使websocket过时了?很明显， HTTP/2服务器推送不是替代方法，服务器发送的事件.

现在要提出的问题是:如果我们希望通过HTTP/2实现WebSockts功能，我们应该使用什么?

解决方案

HTTP/2协议协商的当前形式:

HTTP/2连接以以下三种方式之一启动:

1. 在使用ALPN(应用程序层协议协商)的加密连接(TLS/SSL)中.大多数浏览器要求HTTP/2使用TLS/SSL，并使用此方法建立HTTP/2连接.

2. 使用HTTP/1.1 Upgrade标头(与Websockets相同)以明文形式显示.大多数浏览器要求HTTP/2使用TLS/SSL，因此它的支持受到限制.

3. 以明文形式，在HTTP/1.1连接的开头使用特殊字符串(这可能允许HTTP/2服务器以明文形式禁用HTTP/1.1支持).有限的客户支持.

协商Websocket协议，现在时:

目前，协商Websocket连接需要HTTP/1.1支持并使用HTTP/1.1 Upgrade标头.

通常由侦听HTTP/1.1和HTTP/2连接的同一应用程序服务器执行.支持并发(无论是事件的还是基于线程的)的Web应用程序通常是协议无关的(只要保留HTTP语义)，并且在两种协议上都能很好地工作.

这允许在连接建立期间使用HTTP数据(并可能影响Websocket连接状态/身份验证过程).

一旦建立了Websocket连接，它便完全独立于HTTP语义/层.

在HTTP/2世界中协商Websocket协议:

在一个HTTP/2(唯一的)世界中，可能还有一段时日，Websocket协议协商可能有多种可能的方法:一种基于ALPN的方法和一个HTTP/2隧道"(或流")方法.

ALPN方法以牺牲预升级(HTTP)阶段为代价来保持协议独立性，而流"方法以牺牲前的高耦合和高代价为代价，提供HTTP的升级前"(或Connect)阶段.复杂性.

ALPN方法:

一种可能的未来方法是将Websocket协议简单地添加到 ALPN协商表.

目前，ALPN用于选择(或默认使用)"http/1.1"协议，并且Upgrade请求由HTTP/1.1服务器处理.这意味着Websocket仍在协议协商期间(使用其自己的TCP/IP连接时)为我们提供HTTP标头数据

将来，ALPN可能会简单地添加"wss"作为可用选择.

使用这种方法，可以使用TLS/SSL层的ALPN扩展轻松协商Websocket(当前使用HTTP/1.1 Upgrade标头以加密和明文形式建立).

这将使Websocket协议与HTTP/2协议保持独立，即使在不支持HTTP的情况下也可以使用它.

但是，这带来了一个缺点，即cookie和其他HTTP标头可能不再是协议协商的一部分. (好的和坏的)另一个区别是，这种方法将需要一个单独的TCP/IP连接.

HTTP/2隧道"/流"方法

另一种可能的未来方法，体现在中该拟议草案将处理Websocket协议的HTTP/1.1变体，而采用HTTP/2流"方法.

HTTP/2流"是HTTP/2实现多路复用并允许同时处理多个请求的方式.每个请求都会收到一个流号ID，并使用相同的数字流ID来标识与此请求有关的任何数据(标头，响应等).

在这种方法下，"Websocket"数据将包含在HTTP/2包装器中，并且流ID将用于标识"Websocket"流.

尽管这样做可能会带来一些好处(HTTP头和cookie可以作为Websocket协商的一部分提供)，但并非没有失败.

更高的复杂度和更严格的协议耦合只是两个例子，两者都是非常严重的失败.

结论:

在撰写本文时，使用明文(ws)和加密(wss)连接时，Websocket连接都需要HTTP/1.1 Upgrade语义.

到目前为止，未来还不确定，可能要花很长时间才能淘汰当前的升级过程(使用HTTP/1.1)

The new HTTP/2 protocol comes with some promising features. Some of them:

• Multiplexing - a single TCP connection can be used to make multiple HTTP/2 requests and receive multiple responses (to a single origin)
• HTTP/2 Server Push - sending server responses to the client without receiving requests, i.e. initiated by the server
• Bidirectional connection - HTTP/2 spec - Streams and Multiplexing:

The motivation behind HTTP/2 is explained here HTTP/2 FAQ:

and

So HTTP/2 is nice and comes to replace HTTP/1.x. Unfortunately, HTTP/2 does not support WebSockets. In this question Does HTTP/2 make websockets obsolete? it is made clear that the HTTP/2 Server Push is not an alternative, neither are Server-Sent Events.

Now to the question: What do we use if we want WebSockts functionality over HTTP/2?

解决方案

Current forms of HTTP/2 Protocol Negotiation:

HTTP/2 connections start in one of three ways:

1. In an encrypted connection (TLS/SSL) using ALPN (Application Layer Protocol Negotiation). Most browsers require TLS/SSL for HTTP/2 and use this method for HTTP/2 connection establishment.

2. In clear text, using the HTTP/1.1 Upgrade header (same as Websockets). Most browsers require TLS/SSL for HTTP/2, so this is limited in it's support.

3. In clear text, using a special string at the beginning of an HTTP/1.1 connection (which could allow HTTP/2 servers in clear text to disable HTTP/1.1 support). Limited client support.

Negotiating the Websocket Protocol, present tense:

Negotiating Websocket connections, at the moment, requires HTTP/1.1 support and makes use of the HTTP/1.1 Upgrade header.

This is often performed by the same application server that listens to the HTTP/1.1 and HTTP/2 connections. Web applications that support concurrency (whether evented or thread based) are usually protocol agnostic (as long as HTTP semantics are preserved) and work well enough on both protocols.

This allows HTTP data to be used during connection establishment (and perhaps effect the Websocket connection state/authentication procedure).

Once the Websocket connection is established, it's totally independent from the HTTP semantics / layer.

Negotiating the Websocket Protocol in an HTTP/2 world:

In an HTTP/2 (only) world, which might be a while into the future, there could be a number of possible approaches to Websocket protocol negotiation: an ALPN based approach and an HTTP/2 "tunnel" (or "stream") approach.

The ALPN approach preserves protocol independence at the expense of the pre-upgrade (HTTP) stage, while the "stream" approach provides the HTTP pre-"upgrade" (or Connect) stage at the expense of high coupling and complexity.

The ALPN Approach:

One possible future approach will simply add the Websocket protocol to the ALPN negotiation table.

At the moment, ALPN is used to select (or default to) the "http/1.1" protocol and the Upgrade request is handled by the HTTP/1.1 server. Which means that Websocket still provides us with the HTTP header data during protocol negotiation (while using it's own TCP/IP connection)

In the future, ALPN might simply add "wss" as an available choice.

Using this approach, the Websocket (which is currently established using the HTTP/1.1 Upgrade header, both in encrypted and clear text forms) could easily be negotiated using the ALPN extension to the TLS/SSL layer.

This will keep the Websocket protocol independent from the HTTP/2 protocol and allow it's use even when HTTP isn't supported.

However, this will come with the downside that cookies and other HTTP headers might be no longer available as part of the protocol negotiation. Another difference (both good and bad) is that this approach will require a separate TCP/IP connection.

The HTTP/2 "tunnel" / "stream" approach

Another possible future approach, which is reflected in this proposed draft, will dispose of the HTTP/1.1 variation of the Websocket protocol in favor of an HTTP/2 "stream" approach.

HTTP/2 "streams" are the way HTTP/2 implements multiplexing and allows multiple requests to be handled concurrently. Each request receives a stream number ID and any data pertaining to this request (headers, responses etc') is identified using the same numerical stream ID.

Under this approach, "Websocket" data will be contain within the HTTP/2 wrapper and the stream ID will be used to identify the "Websocket" stream.

Although this might provide some benefits (HTTP headers and cookies could be provided as part of the Websocket negotiation), it's not without its downfalls.

Higher complexity and tighter protocol coupling are just two examples, both of which are very serious downfalls.

Conclusion:

At the time of this writing, HTTP/1.1 Upgrade semantics are required for Websocket connections, both when using clear text (ws) and encrypted (wss) connections.

The future is, as of yet, undecided and it will probably take a long time before the current Upgrade process (using HTTP/1.1) is phased out

这篇关于HTTP/2世界中的WebSockets替代方案是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！