HTTP/2 世界中的 WebSockets 替代品是什么？

Question

新的 HTTP/2 协议带有一些很有前途的特性。他们中的一些：

• 多路复用 - 单个 TCP 连接可用于发出多个 HTTP/2 请求并接收多个响应（对单个源）
• HTTP/2 Server Push - 向客户端发送服务器响应而不接收请求，即由服务器发起
• 双向连接 - HTTP/2 规范 - 流和多路复用：

“流”是在 HTTP/2 连接内在客户端和服务器之间交换的独立的双向帧序列。

HTTP/2 背后的动机在这里解释了HTTP/2 FAQ：

HTTP/1.1 已经为 Web 服务了超过 15 年，但它的年龄开始显现出来。

和

工作组的目标是 HTTP/1.x 的典型用途可以使用 HTTP/2 并看到一些好处。

所以 HTTP/2 很好，并开始取代 HTTP/1.x。不幸的是，HTTP/2 不支持 WebSockets。在这个问题中，HTTP/2 是否会使 websockets 过时？很明显 HTTP/2 Server Push 不是替代方案，Server-Sent Events也不是。

现在的问题是：如果我们想要通过 HTTP/2 实现 WebSockts 功能，我们应该使用什么？

Answer 1

嗯，你的时机相当恰当！

新版本的互联网标准草案刚刚发布：

使用 HTTP/2 引导 WebSockets

附加信息在这里：

https://github.com/mcmanus/draft-h2ws/blob/master/README.md

您可以在此处关注其中的讨论：

https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0032.html

在这得到批准，然后由浏览器和服务器实施之前，我想说您在问题中包含的 Daniel Haxx 的帖子代表了对当前状态的非常好的总结。

Answer 2

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

HTTP/2 连接以三种方式之一开始：

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

2. 在明文中，使用 HTTP/1.1Upgrade标头（与 Websockets 相同）。大多数浏览器都需要针对 HTTP/2 的 TLS/SSL，因此它的支持是有限的。

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

协商 Websocket 协议，现在时：

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

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

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

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

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

在 HTTP/2（仅）世界中，可能会有一段时间，Websocket 协议协商可能有多种可能的方法：基于 ALPN 的方法和 HTTP/2“隧道”（或“流”）方法。

ALPN 方法以预升级 (HTTP) 阶段为代价保持协议独立性，而“流”方法Connect以高耦合和复杂性为代价提供 HTTP 预“升级”（或）阶段。

ALPN 方法：

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

目前，ALPN 用于选择（或默认为）“http/1.1”协议，Upgrade请求由 HTTP/1.1 服务器处理。这意味着 Websocket 在协议协商期间仍然为我们提供 HTTP 头数据（同时使用它自己的 TCP/IP 连接）

将来，ALPN 可能会简单地添加“wss”作为可用选项。

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

这将使 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 协商的一部分提供），但它并非没有缺点。

更高的复杂性和更紧密的协议耦合只是两个例子，两者都是非常严重的失败。

结论：

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

未来尚未确定，目前的升级过程（使用 HTTP/1.1）可能需要很长时间才能淘汰