本文是关于HTTP/3支持网络套接字的网络规范文档译文，尚未完成翻译，欢迎指正。

在HTTP/2连接上运行网络套接字（WebSocket）协议的机制同样兼容HTTP/3，但是HTTP版本特性细节需要指定。本文描述该机制是如何适用于HTTP/3的。

本文是互联网标准追踪文档。

本文产自互联网工程任务组（IETF），已接受公开审查，并由互联网互联网工程指导委员会（IESG）批准出版。更多互联网标准相关信息详见RFC 7841第2章。

关于本文当前状态、勘误及反馈方式等相关信息请移步https://www.rfc-editor.org/info/rfc9220。

版权所有（c）2022 IETF信托及确认为文档作者的个人。保留所有权利。

本文遵守BCP 78及在本文发布之日起生效的IETF信托涉及IETF文档的法律条文（https://trustee.ietf.org/license-info）。请仔细阅读相关条文，因为其描述了你对本文所有的权利及限制。从本文中摘录的代码组件必须包含信托法律条文第4.e章的简版BSD License文件，并且不附带任何该文件所描述的保证。

《HTTP/2引导网络套接字》定义了一个针对HTTP/2的扩展，其在HTTP/3中也是有用的。该扩展利用了HTTP/2的设置。在将其从HTTP/2移植到HTTP/3中过程中，《HTTP/3》的附录A.3提供了合适的的引导（如果有的话）。

本文中的关键字“必须（MUST）”、“必须不（MUST NOT）”、“需要（REQUIRED）”、“强烈要求（SHALL）”、“强烈要求不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“不推荐（NOT RECOMMENDED）”、“可以（MAY）”，以及“可选（OPTIONAL）”应理解为BCP 14 《RFC2119》《RFC8174》所描述的，当且仅当它们像本段一样以斜体加粗方式出现的时候。

《RFC8441》定义了在HTTP/2连接一条单独流上执行网络套接字协议（WebSocket Protocol）^{《RFC6455》}的机制。其定义了一个扩展的CONNECT方法，通过给:path及:authority伪头部字段（pseudo-header）指定一个新的:protocol伪头部字段值及语义。其同时定义了一个新的通过服务端发送的HTTP/2设置，以告知客户端是否可以使用扩展的CONNECT方法。

伪头部字段及设置与HTTP/2在《RFC8441》中的定义完全一致。《HTTP/3》的附录A.3要求HTTP/3分别注册设置。SETTINGS_ENABLE_CONNECT_PROTOCOL值是0x08（十进制值为8），就像在HTTP/2中那样。

如果服务端圣母支持扩展的CONNECT方法，但是却收到了一个不识别或不支持的:protocol值，服务端应该给请求回复501（未实现）状态码（详见《HTTP》第15.6.2章）。服务端可以通过“问题细节（problem details）”回复提供更多信息^{《RFC7807》}。

HTTP/3流的关闭也类似于TCP连接在《RFC6455》中所述的方式关闭。有序的TCP层级关闭通过流的FIN位表示（详见《HTTP/3》第4.4章）。RST异常通过H3_REQUEST_CANCELLED（HTTP/3请求取消，详见《HTTP/3》第8.1章）类型的流错误（详见《HTTP/3》第8章）表示。

本文没有在《RFC8441》讨论的基础上引入新的安全问题。

本文在“HTTP/3设置”登记（详见《HTTP/3》第11.2.2章）中注册了一个新的设置项。

值：

0x08

设置名称：

SETTINGS_ENABLE_CONNECT_PROTOCOL

默认值：

0

状态：

永久

规范：

本文

更改责任人：

IETF

联系方式：

HTTP工作组（Email: ietf-http-wg@w3.org）

本文收到了来自IETF HTTP及QUIC工作组众多贡献者的提交与评审，大量实质性提交来自David Schinazi、Martin Thomson、Lucas Pardue、Mike Bishop、Dragana Damjanovic、Mark Nottingham，以及Julian Reschke。

Ryan Hamilton

Google

Email: rch@google.com

译

• 方秋航

  • Email: fangqiuhang@163.com

• YunzheZJU

  • Email: yunzhe@zju.edu.cn