摘要

  • RFC 6455 通过 HTTP/1.1 的 GET、Upgrade 和 101 响应启动 WebSocket。RFC 7540 的 HTTP/2 同时承载多条流，因而取消连接范围的 101 切换。
  • RFC 8441 让客户端在收到服务器的 SETTINGS_ENABLE_CONNECT_PROTOCOL = 1 后，用 :protocol = websocket、:scheme 和 :path 发起扩展 CONNECT。IANA 将该设置登记为 0x8，初始值为 0。
  • 成功建立后，WebSocket 数据只走被选中的 HTTP/2 流，同一连接上的其他流继续运行。旧式 Connection、Upgrade 与 Sec-WebSocket-Key/Accept 处理不再用于这次启动。

一把开关管不了整条走廊

2011 年的 WebSocket 标准 从 HTTP/1.1 请求起步。客户端发 GET，带上 Upgrade: websocket 和 Connection: Upgrade；服务器可以用 101 Switching Protocols 回答。此后那条 TCP 连接成为双向的 WebSocket 通道。一条连接服务一个请求时，把整条管道交给会话是说得通的安排。

HTTP/2 把管道分成了多条可同时运行的流。页面可能仍在收图片，另一个组件却想维持长时间对话。RFC 7540 因此不在 HTTP/2 内使用 101：Upgrade 和 Connection 以整条连接为单位，一条流不能替旁边的流宣布改朝换代。旧 WebSocket 的开门方式，碰上了新的共享走廊。

这种冲突并非接口装饰。应用已经拥有可复用的 HTTP/2 连接，却不能照搬 HTTP/1.1 的握手把实时会话塞进去。若让聊天夺走整条连接，页面的其他流就失去所属的传输；若坚持旧仪式，客户端便另找通道。RFC 8441 要解决的是谁可以占用多大范围，而不只是把 101 改写成另一个数字。

服务器先开小门

服务器用 SETTINGS_ENABLE_CONNECT_PROTOCOL = 1 明确允许扩展。它在 IANA 的 HTTP/2 设置登记表中编号 0x8，初始值 0。客户端收到值 1 后，才可在新流上使用扩展 CONNECT。若在对端尚未同意时发送新增伪标头，不支持扩展的服务器会把请求视为格式错误。设置不是展示功能的徽章，而是改变请求语义的开锁动作。

获准后，客户端以 :method = CONNECT 新建 HTTP/2 流，写明 :protocol = websocket，并给出目标 URI 的 :scheme、:path 和 :authority。这里最容易出错的是 :authority。传统 CONNECT 把它当成要开隧道的目标主机；扩展 CONNECT 则按目标 URI 的权威部分理解，RFC 8441 明确禁止服务器仅因 CONNECT 出现就向该主机再开一条传统隧道。新增的 :protocol 才说明这条流要承载什么协议。

安全的 WebSocket URI 使用 https 作为目标方案，不加密的 URI 使用 http；其余目标位置仍来自 WebSocket URI。经 HTTP/2 正向代理连接时，RFC 8441 要客户端先使用传统 CONNECT 穿过代理，之后由隧道内实际使用的 HTTP 版本决定如何启动 WebSocket。把源站扩展 CONNECT 当成所有代理的万能通行证，会再次把不同层级的隧道混成一条。

新流从旧切换停下的地方开始

扩展 CONNECT 代替的是旧式 GET 启动。请求不发送 Connection 与 Upgrade，也不执行 HTTP/1.1 的 Sec-WebSocket-Key、Sec-WebSocket-Accept 配对处理；在此路径中，:protocol 承担了相应识别工作。Origin、WebSocket 版本、子协议和扩展字段仍按 WebSocket 规则使用。被改的是开门仪式，门后的帧协议继续存在。

RFC 8441 的例子先显示服务器开设置、客户端发扩展 CONNECT，随后服务器回 :status = 200。接下来，HTTP/2 的 DATA 帧双向承载 WebSocket 数据。被选中的流相当于 RFC 6455 原来所说的 TCP 连接；旁边的 HTTP/2 流仍可正常发送网页请求或另一个隧道。优先级、取消和流量控制仍由 HTTP/2 管理，END_STREAM 与 RST_STREAM 表达该流的正常与异常结束。

这让权力回到恰当的大小。聊天可保持长连接，却不劫持图片和样式请求；服务器可通过不发送设置拒绝新形式；客户端可在尝试前看见这一选择。改变在设置和请求中明明白白地出现，不需要中间设备猜测一个旧 101 在多路复用连接上会牵连谁。

整条连接保住了其他住户

RFC 8441 选择了克制的改法。标准承认可以更彻底重做 WebSocket 与 HTTP/2 的结合，但扩展 CONNECT 已解决两者并行的核心难题。2018 年改变的是准入程序；通道打开后，WebSocket 帧继续运行，RFC 6455 的多数安全要求也仍适用。旧文章讨论帧掩码，本篇关心的是哪一条流取得承载这些帧的许可。

四份官方记录说明机制和登记。要证明某家服务实际启用，还需要有日期的客户端、服务器与代理版本记录，以及 SETTINGS 和 HEADERS 的原始交换。历史结论已经具体：HTTP/2 不会为一个会话交出共享连接，WebSocket 获得了一间须由对端先开门的单流房间。