本文是关于HTTP数据报与Capsule协议的网络规范文档译文，尚未完成翻译，欢迎指正。

本文描述了HTTP数据报（HTTP Datagrams），一种在HTTP连接中传输多路复用且可能不可靠的数据报的约定。

在HTTP/3中，HTTP数据报可以使用QUIC DATAGRAM扩展以不可靠方式发送。当QUIC DATAGRAM帧不可用或不适用时，HTTP数据报可以使用Capsule协议发送，该协议作为一种更通用的在HTTP连接中传输数据的约定。

HTTP数据报和Capsule协议旨在供HTTP扩展使用，而非应用程序。

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

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

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

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

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

HTTP扩展（定义见[HTTP]第16章）有时需要访问底层传输协议的功能——例如不可靠传递（如[QUIC-DGRAM]提供的那样）——以实现所需的特性。例如,这可以用于引入CONNECT方法的不可靠版本，以及为WebSocket [WEBSOCKET]增加不可靠传递能力。

在第2章中，本文描述了HTTP数据报（HTTP Datagrams），一种在HTTP连接中传输双向且可能不可靠的数据报的约定，在可能的情况下支持多路复用。虽然HTTP数据报与HTTP请求相关联，但它们并非消息内容的一部分。相反，它们旨在供HTTP扩展（例如CONNECT方法）使用，并且与所有版本的HTTP兼容。

当HTTP运行在支持不可靠传递的传输协议之上时（例如，当QUIC DATAGRAM扩展[QUIC-DGRAM]可用于HTTP/3 [HTTP/3]时），HTTP数据报可以利用该能力。

在第3章中，本文描述了HTTP Capsule协议，该协议允许使用可靠传递方式来传输HTTP数据报。这解决了那些QUIC DATAGRAM帧不可用或不适用的情况，以及传输协议仅提供可靠传递的情况，例如基于TCP [TCP]的HTTP/1.1 [HTTP/1.1]或HTTP/2 [HTTP/2]。

本文中的关键词“必须（MUST）”、“必须不（MUST NOT）”、“需要（REQUIRED）”、“强烈要求（SHALL）”、“强烈要求不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“不推荐（NOT RECOMMENDED）”、“可以（MAY）”以及“可选（OPTIONAL）”应理解为BCP 14 [RFC2119] [RFC8174]所描述的，当且仅当它们像本段一样以全大写形式出现时。

本文使用来自[QUIC]的术语。

在本文定义协议类型的地方，定义的格式使用[QUIC]第1.3章的记法。当类型中的字段是整数时，它们使用[QUIC]第16章的可变长度整数编码进行编码。整数值不需要编码在最少的必需字节数上。

在本文中，术语“中介（intermediary）”指的是[HTTP]第3.7章中定义的HTTP中介。

HTTP数据报（HTTP Datagrams）是一种在HTTP连接内传输双向且可能不可靠的数据报的约定，在可能的情况下支持多路复用。所有HTTP数据报都与一个HTTP请求相关联。

当HTTP数据报在HTTP/3连接上传输时，QUIC DATAGRAM帧可用于提供解复用和不可靠传递；详见第2.1章。协商QUIC DATAGRAM帧是否用于HTTP数据报是通过交换HTTP/3设置实现的；详见第2.1.1章。

当运行在HTTP/2之上时，解复用以HTTP/2帧层提供，但不可靠传递是不可用的。HTTP数据报通过Capsule协议协商和传输；详见第3.5章。

当运行在HTTP/1.x之上时，请求在连接中严格串行化；因此，解复用不可用。同样地，不可靠传递也不可用。HTTP数据报通过Capsule协议协商和传输；详见第3.5章。

HTTP数据报必须只能在明确支持它们的HTTP请求关联下发送。例如，现有的HTTP方法GET和POST不定义关联HTTP数据报的语义；因此，与GET或POST请求流关联的HTTP数据报不能发送。

如果收到一个HTTP数据报，且它与一个对HTTP数据报没有已知语义的请求关联，接收方必须终止该请求。如果使用的是HTTP/3，请求流必须以H3_DATAGRAM_ERROR（0x33）中止。HTTP扩展可以通过定义HTTP数据报的协商机制和语义来覆盖这些要求。

当与HTTP/3一起使用时，QUIC DATAGRAM帧的Datagram Data字段使用以下格式：

HTTP/3 Datagram {
  Quarter Stream ID (i),
  HTTP Datagram Payload (..),
}

图1：HTTP/3数据报格式

Quarter Stream ID（四分之一流ID）：

一个变长整数，包含与此数据报关联的客户端发起的双向流的流ID除以四的值（除以四是因为HTTP请求是在客户端发起的双向流上发送的，这些流的流ID可以被四整除）。最大的合法QUIC流ID值为2^62-1，因此Quarter Stream ID字段的最大合法值为2^60-1。收到包含更大值的HTTP/3数据报必须被视为类型为H3_DATAGRAM_ERROR（0x33）的HTTP/3连接错误。

HTTP Datagram Payload（HTTP数据报载荷）：

数据报的有效载荷，其语义由使用HTTP数据报的扩展定义。注意，此字段可以为空。

收到一个QUIC DATAGRAM帧且其载荷太短以至于无法解析Quarter Stream ID字段时，必须被视为类型为H3_DATAGRAM_ERROR（0x33）的HTTP/3连接错误。

除非对应流的发送端是打开的，否则必须不发送HTTP/3数据报。如果数据报在对应流的接收端关闭后收到，收到的数据报必须被静默丢弃。

如果收到一个HTTP/3数据报，且其Quarter Stream ID字段映射到一个尚未创建的流，那么接收方强烈要求要么静默丢弃该数据报，要么在等待对应流创建期间临时缓存它（大约一个往返时间）。

如果收到一个HTTP/3数据报，且其Quarter Stream ID字段映射到一个由于客户端发起的双向流限制而无法创建的流，那么它应该被视为类型为H3_ID_ERROR的HTTP/3连接错误。生成错误不是强制性的，因为QUIC流限制可能不为HTTP/3层所知。

HTTP/3数据报的优先级在本文中未定义。未来的扩展可以定义如何对数据报进行优先级排序，并且可以定义信令以允许传达优先级偏好。

终端可以通过发送值为1的SETTINGS_H3_DATAGRAM（0x33）设置来向其对端表明愿意接收HTTP/3数据报。

SETTINGS_H3_DATAGRAM设置的值必须为0或1。值为0表示该实现不愿意接收HTTP数据报。如果收到的SETTINGS_H3_DATAGRAM设置的值既不是0也不是1，接收方必须以H3_SETTINGS_ERROR错误终止连接。

只有在SETTINGS_H3_DATAGRAM设置以值1被双向发送和接收后，才能发送QUIC DATAGRAM帧。

当客户端使用0-RTT时，它可以存储服务器的SETTINGS_H3_DATAGRAM设置的值。这样做允许客户端在0-RTT数据包中发送QUIC DATAGRAM帧。当服务器决定接受0-RTT数据时，它必须发送一个SETTINGS_H3_DATAGRAM设置，其值大于等于它在向客户端发送NewSessionTicket消息的连接中发送的值。如果客户端将SETTINGS_H3_DATAGRAM设置的值与其0-RTT状态一起存储，它必须验证服务器在握手中发送的SETTINGS_H3_DATAGRAM设置的新值大于等于存储的值；如果不满足，客户端必须以H3_SETTINGS_ERROR错误终止连接。在所有情况下，SETTINGS_H3_DATAGRAM设置参数的最大允许值为1。

推荐支持接收HTTP/3数据报的实现始终发送值为1的SETTINGS_H3_DATAGRAM设置，即使应用程序不打算使用HTTP/3数据报。这有助于避免“特征外显（sticking out）”；详见第4章。

当HTTP/3数据报不可用或不适用时，HTTP数据报可以使用Capsule协议发送；详见第3.5章。

扩展HTTP的一种机制是引入新的HTTP升级令牌；参见[HTTP]第16.7章。在HTTP/1.x中，这些令牌通过升级（Upgrade）机制使用；参见[HTTP]第7.8章。在HTTP/2和HTTP/3中，这些令牌通过Extended CONNECT机制使用；参见[EXT-CONNECT2]和[EXT-CONNECT3]。

本规范引入了Capsule协议。Capsule协议是一个类型—长度—值（type-length-value）元组的序列，新HTTP升级令牌的定义可以选择使用它。它允许终端在HTTP请求流上端到端地可靠传达与请求相关的信息，即使存在HTTP中介。Capsule协议可用于交换HTTP数据报，这在HTTP运行在不支持QUIC DATAGRAM帧的传输层之上时是必需的。即使在HTTP/3数据报正在使用的情况下，Capsule协议也可以用于传达与基于数据报的协议关联的可靠双向控制消息。

本规范将HTTP请求的“数据流（data stream）”定义为紧跟在请求消息头部段和最终响应消息之后的双向字节流，其中最终响应消息要么是成功的（即2xx），要么是已升级的（即101）。

在HTTP/1.x中，数据流由连接上紧跟在结束请求头部段或最终响应头部段的空行之后的所有字节组成。因此，只有HTTP/1.x连接上的最后一个HTTP请求才能启动Capsule协议。

在HTTP/2和HTTP/3中，给定HTTP请求的数据流由所有以相应流ID在DATA帧中发送的字节组成。

数据流的概念对于像CONNECT这样的方法特别相关，因为在这些方法中，头部之后没有HTTP消息内容。

数据流可以使用任何适合流或请求优先级排序的方式进行优先级排序。例如，参见[PRIORITY]的第11章。

数据流受底层层的流量控制机制的约束；示例包括HTTP/2流流量控制、HTTP/2连接流量控制和TCP流量控制。

新HTTP升级令牌的定义可以声明其关联请求的数据流使用Capsule协议。如果这样做，关联请求的数据流内容使用以下格式：

Capsule Protocol {
  Capsule (..) ...,
}

Capsule {
  Capsule Type (i),
  Capsule Length (i),
  Capsule Value (..),
}

Capsule Type（Capsule类型）：

一个变长整数，指示Capsule的类型。IANA注册表用于管理Capsule类型的分配；详见第5.4章。

Capsule Length（Capsule长度）：

Capsule Value字段的长度（以字节为单位），紧随此字段之后，编码为变长整数。注意，此字段的值可以为零。

Capsule Value（Capsule值）：

此Capsule的载荷。其语义由Capsule Type字段的值决定。

中介可以通过Capsule-Protocol头部字段（第3.4章）的存在或通过理解所选的HTTP升级令牌来识别Capsule协议的使用。

由于新协议或扩展可能定义新的Capsule类型，希望允许未来扩展性的中介应该在不做修改的情况下转发Capsule，除非所用Capsule类型的定义指定了额外的中介处理。DATAGRAM Capsule（详见第3.5章）就是这样一种Capsule类型。特别地，中介应该在不做修改的情况下转发Capsule类型未知的Capsule。

收到Capsule类型未知的Capsule的终端必须静默丢弃该Capsule，并跳过它以解析下一个Capsule。

依据数据流的定义：

• 除非响应包含2xx（成功）或101（协议切换）状态码，否则不使用Capsule协议。
• 当使用Capsule协议时，关联的HTTP请求和响应不携带HTTP内容。 未来的扩展可以可以定义一种新的Capsule类型来携带HTTP内容。

Capsule协议仅适用于新HTTP升级令牌的定义；因此，在HTTP/2和HTTP/3中，它只能与CONNECT方法一起使用。因此，一旦双方同意使用Capsule协议，流的帧使用要求将按照[HTTP/2]第8.5章和[HTTP/3]第4.4章的规定发生变化。

Capsule协议必须不用于包含Content-Length、Content-Type或Transfer-Encoding头部字段的消息。此外，HTTP状态码204（No Content）、205（Reset Content）和206（Partial Content）必须不在使用Capsule协议的响应上发送。观察到违反这些要求的接收方必须将该HTTP消息视为格式错误。

处理Capsule时，接收方可能会倾向于在处理之前先累积数据流中Capsule Value字段的完整长度。应该避免这种做法，因为它会消耗底层层的流量控制，且如果Capsule数据耗尽流量控制窗口，可能导致死锁。

当接收方在处理Capsule协议时遇到错误，接收方必须将其视为收到了格式错误或不完整的HTTP消息。对于HTTP/3，格式错误消息的处理描述在[HTTP/3]的第4.1.2章。对于HTTP/2，格式错误消息的处理描述在[HTTP/2]的第8.1.1章。对于HTTP/1.x，不完整消息的处理描述在[HTTP/1.1]的第8章。

每个Capsule的载荷必须恰好包含其描述中标识的字段。Capsule载荷在标识字段之后包含额外字节，或Capsule载荷在标识字段结束之前终止的，必须被视为格式错误或不完整的消息。特别地，冗余长度编码必须被验证为自洽的。

如果承载Capsule的流的接收端被干净地终止（例如，在HTTP/3中，这定义为接收到一个FIN位被设置的QUIC STREAM帧），且流上的最后一个Capsule被截断了，那么必须将其视为格式错误或不完整的消息。

“Capsule-Protocol"头部字段是一个Item结构化字段（Structured Field）；参见[STRUCTURED-FIELDS]的第3.3章。其值必须为一个布尔值（Boolean）；接收方对其他类型的值必须视为该字段不存在（例如，如果该字段被包含多次，其类型将变为列表（List），该字段将被忽略）。本文未为Capsule-Protocol头部字段值定义任何参数，但未来的文档可能定义参数。接收方必须忽略未知参数。

终端通过发送值为true的Capsule-Protocol头部字段来表明数据流上正在使用Capsule协议。值为false的Capsule-Protocol头部字段具有与头部不存在时相同的语义。

中介可以使用此头部字段来允许对未知HTTP升级令牌的HTTP数据报进行处理。注意，这仅适用于HTTP Upgrade或Extended CONNECT。

Capsule-Protocol头部字段必须不用于状态码既不同于101（协议切换）也不在2xx（成功）范围内的HTTP响应上。

当使用Capsule协议时，HTTP终端应该发送Capsule-Protocol头部字段以简化中介处理。使用Capsule协议的新HTTP升级令牌的定义可以修改此建议。

本文定义了DATAGRAM（0x00）Capsule类型。此Capsule允许HTTP数据报使用Capsule协议在流上发送。这在HTTP运行在不支持QUIC DATAGRAM帧的传输层之上时特别有用。

Datagram Capsule {
  Type (i) = 0x00,
  Length (i),
  HTTP Datagram Payload (..),
}

HTTP Datagram Payload（HTTP数据报载荷）：

数据报的有效载荷，其语义由使用HTTP数据报的扩展定义。注意，此字段可以为空。

使用DATAGRAM Capsule发送的HTTP数据报具有与在QUIC DATAGRAM帧中发送的那些相同的语义。特别地，关于何时允许发送HTTP数据报以及如何处理它们的限制（来自第2.1章）同样适用于使用DATAGRAM Capsule发送和接收的HTTP数据报。

中介可以在转发HTTP数据报时重新编码它们。换句话说，中介可以发送DATAGRAM Capsule来转发在QUIC DATAGRAM帧中接收到的HTTP数据报，反之亦然。除非中介已经在相应请求流上识别出Capsule协议的使用，否则必须不执行此重新编码；详见第3.2章。

注意，虽然DATAGRAM Capsule（在流上发送）是可靠有序传递的，但中介在转发消息时可以将DATAGRAM Capsule重新编码为QUIC DATAGRAM帧，这可能导致丢包或乱序。

如果中介在QUIC DATAGRAM帧中收到HTTP数据报，并将其转发到支持QUIC DATAGRAM帧的连接上，中介不应该将该HTTP数据报转换为DATAGRAM Capsule。如果HTTP数据报太大而无法放入DATAGRAM帧（例如，因为该QUIC连接的路径MTU（PMTU）太低，或者在该连接上宣告的最大UDP载荷大小太低），中介应该丢弃该HTTP数据报，而不是将其转换为DATAGRAM Capsule。这保留了诸如数据报分组层PMTU发现（DPLPMTUD）等方法所依赖的端到端不可靠特性[DPLPMTUD]。将QUIC DATAGRAM帧转换为DATAGRAM Capsule的中介允许HTTP数据报变得任意大而不遭受任何丢失。这会歪曲真实的路径属性，从而挫败诸如DPLPMTUD之类的方法。

虽然DATAGRAM Capsule理论上可以携带长度为2^62-1的载荷，但大多数使用HTTP数据报的HTTP扩展都会对何种数据报载荷大小是可行的有自己的限制。实现应该在解析DATAGRAM Capsule时考虑这些限制。如果收到的DATAGRAM Capsule的长度已知过大而无法使用，那么实现应该丢弃该Capsule，而不是将其内容缓存到内存中。

由于QUIC DATAGRAM帧必须装入一个QUIC数据包，重新编码DATAGRAM Capsule为QUIC DATAGRAM帧的实现可能会倾向于在重新编码之前在流中累积完整的Capsule。应该避免这种做法，因为它可能导致流量控制问题；详见第3.2章。

注意，HTTP扩展可以不使用Capsule协议而使用HTTP数据报。例如，如果使用HTTP数据报的HTTP扩展仅定义在支持QUIC DATAGRAM帧的传输层之上，那么它可能不需要流编码。此外，HTTP扩展可以使用HTTP数据报及其自己的数据流协议。然而，希望使用HTTP数据报的新HTTP扩展应该使用Capsule协议，因为不这样做会使HTTP扩展更难支持除HTTP/3以外的HTTP版本，并阻碍与仅支持Capsule协议的中介的互操作性。

由于使用QUIC DATAGRAM帧传输HTTP数据报需要发送HTTP/3 SETTINGS_H3_DATAGRAM设置，它会“特征外显（stick out）”。换句话说，探测客户端可以得知服务器是否支持基于QUIC DATAGRAM帧的HTTP数据报。由于某些服务器可能希望模糊其提供使用HTTP数据报的应用服务这一事实，支持此功能的所有实现最好始终发送此设置；详见第2.1.1章。

由于Capsule协议的使用仅限于新的HTTP升级令牌，它不能从Web平台API（例如在Web浏览器中通常通过JavaScript访问的那些API）直接访问。

使用Capsule协议的新HTTP升级令牌的定义需要包含安全分析，在其协议上下文中考虑HTTP数据报和Capsule的影响。

5.1. HTTP/3设置

IANA已在https://www.iana.org/assignments/http3-parameters维护的"HTTP/3 Settings"注册表中注册了以下条目：

• 值： 0x33
• 设置名称： SETTINGS_H3_DATAGRAM
• 默认值： 0
• 状态： permanent（永久）
• 参考： RFC 9297
• 变更控制者： IETF
• 联系方式： HTTP_WG; HTTP working group; ietf-http-wg@w3.org
• 备注： 无

5.2. HTTP/3错误码

IANA已在https://www.iana.org/assignments/http3-parameters维护的"HTTP/3 Error Codes"注册表中注册了以下条目：

• 值： 0x33
• 名称： H3_DATAGRAM_ERROR
• 描述： 数据报或Capsule协议解析错误
• 状态： permanent（永久）
• 参考： RFC 9297
• 变更控制者： IETF
• 联系方式： HTTP_WG; HTTP working group; ietf-http-wg@w3.org
• 备注： 无

5.3. HTTP头部字段名称

IANA已在https://www.iana.org/assignments/http-fields维护的"Hypertext Transfer Protocol (HTTP) Field Name Registry"中注册了以下条目：

• 字段名称： Capsule-Protocol
• 模板： 无
• 状态： permanent（永久）
• 参考： RFC 9297
• 注释： 无

5.4. Capsule类型

本文档为HTTP Capsule类型码建立了一个注册表。“HTTP Capsule Types"注册表管理一个62位的空间，并遵循[QUIC]第22.1章中记录的QUIC注册策略。这个新注册表包含了[QUIC]第22.1.1章中列出的通用字段集合。除了这些通用字段外，此注册表中的所有注册条目必须包含一个"Capsule Type"字段，该字段包含Capsule类型的简短名称或标签。

此注册表中的永久注册条目使用"Specification Required"策略（[IANA-POLICY]第4.6章）分配，但值在0x00到0x3f（十六进制，含）之间的情况除外，这些值使用[IANA-POLICY]第4.9和4.10章中定义的"Standards Action"或"IESG Approval"来分配。

具有形如0x29 * N + 0x17（N为整数）的值的Capsule类型被保留使用，用于实践未知Capsule类型必须被忽略的要求。这些Capsule没有语义，可以携带任意值。这些值必须不由IANA分配，并且必须不出现在已分配值的列表中。

此注册表初始包含以下条目：

• 值： 0x00
• Capsule类型： DATAGRAM
• 状态： permanent（永久）
• 参考： RFC 9297
• 变更控制者： IETF
• 联系方式： MASQUE Working Group masque@ietf.org (mailto:masque@ietf.org)
• 备注： 无

IANA已在https://www.iana.org/assignments/http3-parameters维护的"HTTP/3 Settings"注册表中注册了以下条目：

• 值： 0x33
• 设置名称： SETTINGS_H3_DATAGRAM
• 默认值： 0
• 状态： permanent（永久）
• 参考： RFC 9297
• 变更控制者： IETF
• 联系方式： HTTP_WG; HTTP working group; ietf-http-wg@w3.org
• 备注： 无

IANA已在https://www.iana.org/assignments/http3-parameters维护的"HTTP/3 Error Codes"注册表中注册了以下条目：

• 值： 0x33
• 名称： H3_DATAGRAM_ERROR
• 描述： 数据报或Capsule协议解析错误
• 状态： permanent（永久）
• 参考： RFC 9297
• 变更控制者： IETF
• 联系方式： HTTP_WG; HTTP working group; ietf-http-wg@w3.org
• 备注： 无

IANA已在https://www.iana.org/assignments/http-fields维护的"Hypertext Transfer Protocol (HTTP) Field Name Registry"中注册了以下条目：

• 字段名称： Capsule-Protocol
• 模板： 无
• 状态： permanent（永久）
• 参考： RFC 9297
• 注释： 无

本文档为HTTP Capsule类型码建立了一个注册表。“HTTP Capsule Types"注册表管理一个62位的空间，并遵循[QUIC]第22.1章中记录的QUIC注册策略。这个新注册表包含了[QUIC]第22.1.1章中列出的通用字段集合。除了这些通用字段外，此注册表中的所有注册条目必须包含一个"Capsule Type"字段，该字段包含Capsule类型的简短名称或标签。

此注册表中的永久注册条目使用"Specification Required"策略（[IANA-POLICY]第4.6章）分配，但值在0x00到0x3f（十六进制，含）之间的情况除外，这些值使用[IANA-POLICY]第4.9和4.10章中定义的"Standards Action"或"IESG Approval"来分配。

具有形如0x29 * N + 0x17（N为整数）的值的Capsule类型被保留使用，用于实践未知Capsule类型必须被忽略的要求。这些Capsule没有语义，可以携带任意值。这些值必须不由IANA分配，并且必须不出现在已分配值的列表中。

此注册表初始包含以下条目：

• 值： 0x00
• Capsule类型： DATAGRAM
• 状态： permanent（永久）
• 参考： RFC 9297
• 变更控制者： IETF
• 联系方式： MASQUE Working Group masque@ietf.org (mailto:masque@ietf.org)
• 备注： 无

本文档的部分内容此前是QUIC DATAGRAM帧定义本身的一部分；作者希望感谢该文档的作者以及IETF MASQUE工作组成员提出的建议。此外，作者希望感谢Martin Thomson建议使用HTTP/3设置。另外，作者希望感谢Ben Schwartz的实质性贡献。本文档的最终设计出自HTTP数据报设计团队（HTTP Datagrams Design Team），其成员包括Alan Frindell、Alex Chernyakhovsky、Ben Schwartz、Eric Rescorla、Marcus Ihlar、Martin Thomson、Mike Bishop、Tommy Pauly、Victor Vasiliev以及本文作者。作者感谢Mark Nottingham和Philipp Tiesel提出的有帮助的意见。

David Schinazi

: Google LLC

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States of America

Email: dschinazi.ietf@gmail.com

Lucas Pardue

: Cloudflare

Email: lucaspardue.24.7@gmail.com

译

• 方秋航
  • Email: fangqiuhang@163.com