HTTP2 上的 websockets 也会在流中多路复用吗？
Will websockets over HTTP2 also be multiplexed in streams?
我正在尝试 clarify/understand websockets over HTTP/2 是否也将使用流通过 TCP 连接进行多路复用。 Section 5 of RFC8441 似乎建议它
After successfully processing the opening handshake, the peers should proceed with the WebSocket Protocol [RFC6455] using the HTTP/2 stream from the CONNECT transaction as if it were the TCP connection referred to in [RFC6455]. The state of the WebSocket connection at this point is OPEN, as defined by [RFC6455], Section 4.1.
The HTTP/2 stream closure is also analogous to the TCP connection closure of [RFC6455]. Orderly TCP-level closures are represented as END_STREAM flags ([RFC7540], Section 6.1). RST exceptions are represented with the RST_STREAM frame ([RFC7540], Section 6.4) with the CANCEL error code ([RFC7540], Section 7).
但我的困惑源于这样一个事实，即即使使用 HTTP/1.1，浏览器中的选项卡也会共享到同一主机的底层 TCP 连接（例如 chrome 建立 6 个 TCP 连接），在不同的选项卡中创建到同一主机的 websocket 会导致每个选项卡中的不同 TCP 连接。
我不确定为什么两者之间的差异以及 websockets 和 HTTP/2 是否可能相同。
有哪位专家可以解释一下。谢谢。
creating a websocket to the same host in different tabs leads to distinct TCP connection in each tab
WebSocket 连接始终是新的 TCP 连接，因为它必须执行 HTTP/S 请求 升级 到 WebSocket 连接，因此不再是 HTTP/S连接成功。 WebSocket 连接是不同的，不能共享或重用，不像 HTTP/S 连接（假设使用了保持活动）。
But my confusion arises from the fact that even with HTTP/1.1, while tabs in a browser share the underlying TCP connections (e.g. chrome makes 6 TCP connections) to the same host, creating a websocket to the same host in different tabs leads to distinct TCP connection in each tab.
不幸的是，对于 HTTP/1.1.
，这就是目前的状况，这是对的
正如您所指出的，RFC 8441 已被指定用于解决此问题并在 HTTP/2 流上搭载 WebSocket "connections"，因此可以只打开一个 TCP 连接到一个源服务器并将该连接用于 HTTP/2 通信和 WebSocket 通信。
HTTP/1.1 和 HTTP/2 之间的区别源于 HTTP/1.1 WebSocket 连接不能（有效地）合并。
每个 WebSocket 连接都绑定到一个特定的 URI（例如 ws://host/path1），应用程序为不同的 URI 打开不同的 WebSocket 连接（而不是为同一 URI 打开许多 WebSocket 连接）更为典型。
因为它们不能被合并，浏览器基本上必须允许无限数量的它们，每次你从 JavaScript.
调用 new WebSocket(...) 时一个新的
使用 HTTP/2，您将能够在同一个 HTTP/2 连接中打开一个新的 HTTP/2 stream。
并发流的数量取决于浏览器的实现，但通常在 100 左右甚至更多，这为 HTTP/2 和 WebSocket 留下了大量的并发性（除非客户端应用程序真的滥用 WebSocket）。
幸运的是，无需更改客户端应用程序即可利用此功能。
当浏览器和服务器支持它时，您的应用程序将使用更少的资源（仅一个 TCP 连接）而不是现在使用的许多资源。
[免责声明，我是 Jetty]
中此类功能的实现者
我们已经看到一些浏览器实现了此功能，我们正在 Jetty 10 中完成此功能的实现。0.x 服务器，请参阅 https://github.com/eclipse/jetty.project/issues/3537。
我正在尝试 clarify/understand websockets over HTTP/2 是否也将使用流通过 TCP 连接进行多路复用。 Section 5 of RFC8441 似乎建议它
After successfully processing the opening handshake, the peers should proceed with the WebSocket Protocol [RFC6455] using the HTTP/2 stream from the CONNECT transaction as if it were the TCP connection referred to in [RFC6455]. The state of the WebSocket connection at this point is OPEN, as defined by [RFC6455], Section 4.1.
The HTTP/2 stream closure is also analogous to the TCP connection closure of [RFC6455]. Orderly TCP-level closures are represented as END_STREAM flags ([RFC7540], Section 6.1). RST exceptions are represented with the RST_STREAM frame ([RFC7540], Section 6.4) with the CANCEL error code ([RFC7540], Section 7).
但我的困惑源于这样一个事实，即即使使用 HTTP/1.1，浏览器中的选项卡也会共享到同一主机的底层 TCP 连接（例如 chrome 建立 6 个 TCP 连接），在不同的选项卡中创建到同一主机的 websocket 会导致每个选项卡中的不同 TCP 连接。
我不确定为什么两者之间的差异以及 websockets 和 HTTP/2 是否可能相同。
有哪位专家可以解释一下。谢谢。
creating a websocket to the same host in different tabs leads to distinct TCP connection in each tab
WebSocket 连接始终是新的 TCP 连接，因为它必须执行 HTTP/S 请求 升级 到 WebSocket 连接，因此不再是 HTTP/S连接成功。 WebSocket 连接是不同的，不能共享或重用，不像 HTTP/S 连接（假设使用了保持活动）。
But my confusion arises from the fact that even with HTTP/1.1, while tabs in a browser share the underlying TCP connections (e.g. chrome makes 6 TCP connections) to the same host, creating a websocket to the same host in different tabs leads to distinct TCP connection in each tab.
不幸的是，对于 HTTP/1.1.
，这就是目前的状况，这是对的 正如您所指出的，RFC 8441 已被指定用于解决此问题并在 HTTP/2 流上搭载 WebSocket "connections"，因此可以只打开一个 TCP 连接到一个源服务器并将该连接用于 HTTP/2 通信和 WebSocket 通信。
HTTP/1.1 和 HTTP/2 之间的区别源于 HTTP/1.1 WebSocket 连接不能（有效地）合并。
每个 WebSocket 连接都绑定到一个特定的 URI（例如 ws://host/path1），应用程序为不同的 URI 打开不同的 WebSocket 连接（而不是为同一 URI 打开许多 WebSocket 连接）更为典型。
因为它们不能被合并，浏览器基本上必须允许无限数量的它们，每次你从 JavaScript.
new WebSocket(...) 时一个新的
使用 HTTP/2，您将能够在同一个 HTTP/2 连接中打开一个新的 HTTP/2 stream。 并发流的数量取决于浏览器的实现，但通常在 100 左右甚至更多，这为 HTTP/2 和 WebSocket 留下了大量的并发性（除非客户端应用程序真的滥用 WebSocket）。
幸运的是，无需更改客户端应用程序即可利用此功能。 当浏览器和服务器支持它时，您的应用程序将使用更少的资源（仅一个 TCP 连接）而不是现在使用的许多资源。
[免责声明，我是 Jetty]
中此类功能的实现者我们已经看到一些浏览器实现了此功能，我们正在 Jetty 10 中完成此功能的实现。0.x 服务器，请参阅 https://github.com/eclipse/jetty.project/issues/3537。