本文是关于HTTP中UDP代理的网络规范文档译文，尚未完成翻译，欢迎指正。

本文描述了如何在HTTP中代理UDP，类似于HTTP CONNECT方法允许在HTTP中代理TCP的方式。更具体地说，本文定义了一种协议，允许HTTP客户端通过充当代理的HTTP服务器为UDP通信创建隧道。

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

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

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

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

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

尽管HTTP提供了CONNECT方法（参见[HTTP]第9.3.6节）用于创建到代理的TCP [TCP]隧道，但在本规范之前，它缺少为UDP [UDP]流量执行此操作的方法。

本文档描述了一种协议，用于将UDP隧道传输到充当基于HTTP的UDP特定代理的服务器。UDP隧道通常用于创建端到端虚拟连接，然后可以使用QUIC [QUIC]或运行在UDP上的其他协议对其进行安全保护。与HTTP CONNECT方法不同，UDP代理本身通过包含流量目标地址的绝对URL来标识。客户端使用URI模板[TEMPLATE]生成这些URL，具体描述见第2节。

本协议通过使用HTTP数据报[HTTP-DGRAM]支持所有现有版本的HTTP。当使用HTTP/2 [HTTP/2]或HTTP/3 [HTTP/3]时，它使用[EXT-CONNECT2]和[EXT-CONNECT3]中描述的HTTP扩展CONNECT。当使用HTTP/1.x [HTTP/1.1]时，它使用[HTTP]第7.8节中定义的HTTP升级机制。

本文档中的关键词"必须"，“必须”，“需要”，“强烈要求”，“强烈要求”，“应该”，“应该”，“推荐”，“错误的关键字”，“可以"和"可选"的解释应遵循BCP 14 [RFC2119] [RFC8174]所述，且仅当它们全部以大写字母出现时（如上所示）才具有相应含义。

在本文档中，我们使用术语"UDP代理"指代这样的HTTP服务器：它响应客户端的UDP隧道请求，向目标服务器打开UDP套接字，并生成对此请求的响应。如果客户端和UDP代理之间存在HTTP中间人（定义见[HTTP]第3.7节），则本文档将其称为"中间人”。

注意，当使用的HTTP版本不支持多路复用流（例如HTTP/1.1）时，本文档中对"流"的任何引用均表示整个连接。

HTTP客户端通过带有变量target_host和target_port的URI模板[TEMPLATE]配置使用UDP代理。示例如下：

https://example.org/.well-known/masque/udp/{target_host}/{target_port}/
https://proxy.example.org:4443/masque?h={target_host}&p={target_port}
https://proxy.example.org:4443/masque{?target_host,target_port}

图1：URI模板示例

以下要求适用于该URI模板：

• 该URI模板必须是第3级或更低级别的模板。

• 该URI模板必须采用绝对形式，并且必须包含非空的scheme、authority和path组件。

• 该URI模板的path组件必须以斜杠（"/"）开头。

• 所有模板变量必须位于URI的path或query组件内。

• 该URI模板必须包含target_host和target_port这两个变量，并且可以包含其他变量。

• 该URI模板必须包含任何非ASCII Unicode字符，并且必须仅包含范围为0x21-0x7E（含）的ASCII字符（注意允许百分比编码；参见[URI]第2.1节）。

• 该URI模板必须使用保留扩展（"+“操作符）、片段扩展（”#“操作符）、带点前缀的标签扩展、带斜杠前缀的路径段扩展，也不得使用带分号前缀的路径样式参数扩展。

客户端应该验证上述要求；但是，客户端可以使用缺少此特定验证的通用URI模板实现。如果客户端检测到URI模板未满足上述任何要求，则客户端必须拒绝其配置并中止请求，而不将其发送到UDP代理。

原始的HTTP CONNECT方法允许传递目标主机和端口，但不允许传递scheme、代理authority、path或query。因此，存在仅允许用户配置代理主机和代理端口的代理配置界面的客户端。受此类限制约束的本规范客户端实现可以尝试使用默认模板来访问UDP代理功能，该默认模板定义为https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_port}/，其中$PROXY_HOST和$PROXY_PORT分别是UDP代理的配置主机和端口。如果UDP代理部署需要与此类客户端互操作，则应该在该位置提供服务。

为了允许在HTTP上协商UDP隧道，本文档定义了"connect-udp" HTTP升级令牌。生成的UDP隧道使用胶囊协议（参见[HTTP-DGRAM]第3.2节）以及第5节中定义的HTTP数据报格式。

为了启动与单个HTTP流关联的UDP隧道，客户端发起包含"connect-udp"升级令牌的请求。客户端通过URI模板的target_host和target_port变量向UDP代理指示隧道目标；参见第2节。

target_host支持使用DNS名称、IPv6字面量和IPv4字面量。注意，不支持IPv6作用域地址区域标识符。使用[URI]中的术语IPv6address、IPv4address、reg-name和port，target_host和target_port变量必须遵循图2中的格式，使用[ABNF]的表示法。此外：

• target_host和target_port变量均必须为空。

• 如果target_host包含IPv6字面量，则冒号（":"）必须进行百分比编码。例如，如果目标主机是"2001:db8::42"，则将在URI中编码为"2001%3Adb8%3A%3A42"。

• target_port 必须表示一个介于1到65535（含）之间的整数。

target_host = IPv6address / IPv4address / reg-name
target_port = port

在发送其UDP代理请求时，客户端强烈要求执行URI模板扩展以确定其请求的path和query。

如果请求成功，UDP代理承诺将接收到的HTTP数据报转换为UDP数据包，反之亦然，直到隧道关闭。

根据胶囊协议的定义（参见[HTTP-DGRAM]第3.2节），UDP代理请求不携带任何消息内容。同样，成功的UDP代理响应也不携带任何消息内容。

在收到UDP代理请求时：

• 如果接收方被配置为使用另一个HTTP代理，则它将充当中问人，将请求转发到另一个HTTP服务器。注意，如果此类中间人使用不同于接收时所用HTTP版本来转发请求，则可能需要重新编码请求，因为请求编码因版本而异（见下文）。

• 否则，接收方将充当UDP代理。它从根据请求头重建的URI中提取target_host和target_port变量，解码其百分比编码，并通过直接打开到所请求目标的UDP套接字来建立隧道。

与TCP不同，UDP是无连接的。打开UDP套接字的UDP代理无法知道目标是否可达。因此，它需要在不等待来自目标的数据包的情况下响应请求。但是，如果target_host是DNS名称，则UDP代理必须在回复HTTP请求之前执行DNS解析。如果在此过程中发生错误，UDP代理必须拒绝请求，并且应该使用适当的Proxy-Status头字段[PROXY-STATUS]发送详细信息。例如，如果DNS解析返回错误，则代理可以使用[PROXY-STATUS]第2.3.2节中的dns_error代理错误类型。

如果操作系统支持，UDP代理可以使用已连接的UDP套接字，因为这样UDP代理可以依赖内核仅向其发送匹配正确五元组的UDP数据包。如果UDP代理使用非连接套接字，则它必须验证接收数据包的IP源地址和UDP源端口，以确保它们与客户端的请求匹配。不匹配的数据包必须由UDP代理丢弃。

套接字的生命周期与请求流绑定。UDP代理必须在请求流打开期间保持套接字打开。如果UDP代理被其操作系统通知其套接字不再可用，则它必须关闭请求流。例如，收到ICMP目标不可达消息时可能发生这种情况；参见[ICMP6]第3.1节。UDP代理可以选择由于一段不活动期而关闭套接字，但它们必须在关闭套接字时关闭请求流。在不活动期后关闭套接字的UDP代理应该使用低于两分钟的时间段；参见[BEHAVE]第4.3节。

成功响应（定义见第3.3节和第3.5节）表示UDP代理已打开到所请求目标的套接字，并愿意代理UDP载荷。除成功响应外的任何响应均表示请求已失败；因此，客户端必须中止请求。

UDP代理必须在将HTTP数据报转发到UDP套接字时在IP层引入分片；过大的数据报将被静默丢弃。在IPv4中，如果可能，必须设置不分片（DF）位，以防止路径上的分片。未来的扩展可以移除这些要求。

UDP代理的实现者将从阅读[UDP-USAGE]中的指导中受益。

当使用HTTP/1.1 [HTTP/1.1]时，UDP代理请求应满足以下要求：

• 方法强烈要求为"GET"。

• 请求强烈要求包含一个单独的Host头字段，其中包含UDP代理的源站。

• 请求强烈要求包含一个Connection头字段，其值为"Upgrade"（注意，根据[HTTP]第7.6.1节，此要求不区分大小写）。

• 请求强烈要求包含一个Upgrade头字段，其值为"connect-udp"。

不符合这些限制的UDP代理请求是畸形的。此类畸形请求的接收方必须以错误响应，并且应该使用400（Bad Request）状态码。

例如，如果客户端配置了URI模板https://example.org/.well-known/masque/udp/{target_host}/{target_port}/并希望打开到目标192.0.2.6:443的UDP代理隧道，则可以发送以下请求：

GET https://example.org/.well-known/masque/udp/192.0.2.6/443/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1

在HTTP/1.1中，本协议使用GET方法来模仿WebSocket协议[WEBSOCKET]的设计。

UDP代理强烈要求通过回复满足以下要求来指示成功响应：

• 响应中的HTTP状态码强烈要求为101（Switching Protocols）。

• 响应强烈要求包含一个Connection头字段，其值为"Upgrade"（注意，根据[HTTP]第7.6.1节，此要求不区分大小写）。

• 响应强烈要求包含一个单独的Upgrade头字段，其值为"connect-udp"。

• 响应强烈要求满足启动胶囊协议的HTTP响应要求；参见[HTTP-DGRAM]第3.2节。

如果这些要求中的任何一项未满足，则客户端必须将此代理尝试视为失败并中止连接。

例如，UDP代理可以响应如下：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1

当使用HTTP/2 [HTTP/2]或HTTP/3 [HTTP/3]时，UDP代理请求使用HTTP扩展CONNECT。这要求服务器发送[EXT-CONNECT2]和[EXT-CONNECT3]中指定的HTTP Setting，并且请求使用HTTP伪头字段，满足以下要求：

• :method伪头字段强烈要求为"CONNECT"。

• :protocol伪头字段强烈要求为"connect-udp"。

• :authority伪头字段强烈要求包含UDP代理的authority。

• :path和:scheme伪头字段强烈要求为空。它们的值强烈要求包含URI模板扩展过程完成后的scheme和path。

不符合这些限制的UDP代理请求是畸形的（参见[HTTP/2]第8.1.1节和[HTTP/3]第4.1.2节）。

例如，如果客户端配置了URI模板https://example.org/.well-known/masque/udp/{target_host}/{target_port}/并希望打开到目标192.0.2.6:443的UDP代理隧道，则可以发送以下请求：

HEADERS
:method = CONNECT
:protocol = connect-udp
:scheme = https
:path = /.well-known/masque/udp/192.0.2.6/443/
:authority = example.org
capsule-protocol = ?1

UDP代理强烈要求通过回复满足以下要求来指示成功响应：

• 响应中的HTTP状态码强烈要求位于2xx（成功）范围内。

• 响应强烈要求满足启动胶囊协议的HTTP响应要求；参见[HTTP-DGRAM]第3.2节。

如果这些要求中的任何一项未满足，则客户端必须将此代理尝试视为失败并中止请求。

例如，UDP代理可以响应如下：

HEADERS
:status = 200
capsule-protocol = ?1

本文档中定义的基于HTTP代理UDP的机制允许未来的扩展交换携带与UDP载荷不同语义的HTTP数据报。其中一些扩展可以用额外数据增强UDP载荷，而其他扩展则可以交换与UDP载荷完全分离的数据。为了实现这一点，与UDP代理请求流关联的所有HTTP数据报都以上下文ID字段开头；参见第5节。

上下文ID是62位整数（0到2^62-1）。上下文ID编码为变长整数；参见[QUIC]第16节。上下文ID值0保留用于UDP载荷，而非零值是动态分配的。非零偶数上下文ID由客户端分配，奇数上下文ID由代理分配。上下文ID命名空间与给定的HTTP请求绑定；具有相同数值的上下文ID可能同时在不同的请求中分配，并可能具有不同的语义。上下文ID必须在给定的HTTP命名空间内重新分配，但可以以任何顺序分配。偶数编号和奇数编号上下文ID使用限制的存在是为了避免端点之间同步的需要。但是，一旦上下文ID已被分配，这些限制不适用于该上下文ID的使用；它可以由任何客户端或UDP代理使用，与最初分配它的端点无关。

注册是指端点告知其对等端给定上下文ID的语义和格式的操作。本文档未定义注册如何发生。未来的扩展可以使用HTTP头字段或胶囊来注册上下文ID。根据所使用的方法，可能会在收到尚未注册的上下文ID的数据报。例如，这可能是由于包含数据报的数据包和包含注册消息的数据包在传输过程中的重排序所致。

当HTTP数据报（参见[HTTP-DGRAM]第2节）与UDP代理请求流关联时，HTTP数据报载荷字段具有图7中定义的格式，使用[QUIC]第1.3节的表示法。注意，当HTTP数据报使用QUIC DATAGRAM帧[QUIC-DGRAM]编码时，下面定义的上下文ID字段直接紧跟在四分之一流ID字段之后，该字段位于QUIC DATAGRAM帧载荷的开头；参见[HTTP-DGRAM]第2.1节。

UDP Proxying HTTP Datagram Payload {
  Context ID (i),
  UDP Proxying Payload (..),
}

上下文ID（Context ID）：

一个变长整数（参见[QUIC]第16节），包含上下文ID的值。如果收到携带未知上下文ID的HTTP/3数据报，则接收方强烈要求要么静默丢弃该数据报，要么在等待相应上下文ID注册的同时临时缓冲它（大约一个往返时间）。

UDP代理载荷（UDP Proxying Payload）：

数据报的载荷，其语义取决于前一个字段的值。注意，此字段可以为空。

UDP数据包使用上下文ID字段设置为零的HTTP数据报进行编码。当上下文ID字段设置为零时，UDP代理载荷字段包含UDP数据包的未修改载荷（在[UDP]中称为数据八位字节）。

根据UDP头[UDP]的定义，不可能对长度超过65527字节的UDP载荷进行编码。因此，端点必须使用上下文ID零发送UDP代理载荷字段长度超过65527的HTTP数据报。收到使用上下文ID零且其UDP代理载荷字段长度超过65527的HTTP数据报的端点必须中止相应流。如果UDP代理知道由于其底层链路MTU的限制，它只能发送特定长度的UDP数据包，则它别无选择，只能丢弃使用上下文ID零且其UDP代理载荷字段长度超过该限制的传入HTTP数据报。如果被丢弃的HTTP数据报是由DATAGRAM胶囊传输的，接收方应该丢弃该胶囊而不缓冲胶囊内容。

如果UDP代理在收到相应请求之前收到HTTP数据报，则它强烈要求要么静默丢弃该HTTP数据报，要么在等待相应请求的同时临时缓冲它（大约一个往返时间）。

注意，缓冲数据报（因为请求尚未收到或上下文ID尚未知）会消耗资源。缓冲数据报的接收方应该应用缓冲限制，以减少资源耗尽的风险。例如，接收方可以在每个流、每个上下文或每个连接的基础上限制缓冲数据报的总数或缓冲数据报的累计大小。

客户端可以在收到对其UDP代理请求的响应之前乐观地开始在HTTP数据报中发送UDP数据包。但是，实现者应注意，如果UDP代理以失败响应请求，或者代理数据包在UDP代理收到请求之前到达且UDP代理选择不缓冲它们，则此类代理数据包可能不会被UDP代理处理。

突发流量常常会导致时间相关的数据包丢失（temporally correlated packet losses）；进而，这可能导致运行在UDP之上的协议中的拥塞控制器产生次优的响应。为了避免这种情况，UDP代理应该努力避免增加UDP流量的突发性（burstiness）；代理应该 NOT为了增加批处理（batching）而对数据包进行排队。

当被代理运行在UDP之上的协议使用了拥塞控制（例如，错误的关键字），被代理的流量将至少经历两层嵌套的拥塞控制器。底层的HTTP连接必须 NOT禁用拥塞控制，除非其能够通过带外方式（out-of-band）确切地知道内部流量已经进行了拥塞控制。

如果客户端或UDP代理在一个包含UDP代理请求流的连接上禁用了拥塞控制，则其必须 NOT在该连接上发送显式拥塞通知（Explicit Congestion Notification，ECN）错误的关键字支持信号。也就是说，其必须将所有IP头部标记为Not-ECT码点。其可以继续通过QUIC ACK_ECN帧或TCP ECE位报告ECN反馈，因为对端可能并未禁用拥塞控制。

当被代理运行在UDP之上的协议使用了丢包恢复（loss recovery）（例如，错误的关键字），并且底层HTTP连接运行在TCP之上时，被代理的流量将至少经历两层嵌套的丢包恢复机制。这会降低性能，因为两者有时可能独立地重传相同的数据。为了避免这种情况，UDP代理应该在HTTP/3上执行，以便能够利用QUIC DATAGRAM帧。

当使用HTTP/3配合QUIC Datagram扩展错误的关键字时，UDP负载通过QUIC DATAGRAM帧进行传输。由于这些帧不可分片，它们只能承载不超过由QUIC连接配置和路径MTU（Path MTU，PMTU）决定的某个长度的负载。如果UDP代理正在使用QUIC DATAGRAM帧，并且从目标接收到一个无法装入QUIC DATAGRAM帧的UDP负载，则UDP代理应该 NOT在DATAGRAM胶囊中发送该UDP负载，因为这会破坏诸如数据包化层PMTU发现（Datagram Packetization Layer PMTU Discovery，DPLPMTUD）等方法所依赖的端到端不可靠性特性错误的关键字。在此场景下，UDP代理应该丢弃该UDP负载，并向目标发送一条ICMP Packet Too Big消息；参见错误的关键字第3.2节。

UDP代理不会创建IP-in-IP隧道，因此错误的关键字中关于在内外层IP头部之间传递ECN标记的指导并不适用。UDP代理隧道中不存在内层IP头部。

在本规范中，需要注意的是，UDP代理客户端无法控制UDP代理向目标发送的UDP数据包上的ECN码点，UDP代理也无法将每个UDP数据包从目标到UDP代理的标记情况传达给客户端。

UDP代理必须忽略从目标接收到的UDP数据包IP头部中的ECN位，并且其必须将发送给目标的UDP数据包上的ECN位设置为Not-ECT。这些与客户端和UDP代理之间发送的数据包的ECN标记没有任何关系。

允许任意客户端建立到任意目标的隧道存在重大风险，因为这可能使恶意行为者发送流量并使其归属到UDP代理名下。支持UDP代理的HTTP服务器应当（ought to）将其使用限制在经过认证的用户范围内。

存在一些基于传入请求的源IP地址执行访问控制检查的软件和网络部署。例如，某些软件允许来自127.0.0.1的未经认证的配置更改。此类软件可能与UDP代理运行在同一主机上或同一广播域中。代理后的UDP流量将以属于UDP代理的源IP地址被接收。如果该源地址被用于访问控制，则UDP代理客户端可以利用UDP代理将其访问权限提升到其原本可能不具备的水平。这可能导致UDP代理客户端的未授权访问，除非UDP代理禁止对易受攻击的目标（例如UDP代理自身的地址以及本地回环地址（localhost）、链路本地（link-local）地址、多播（multicast）地址和广播（broadcast）地址）的UDP代理请求。UDP代理在拒绝此类请求时可以使用错误的关键字第2.3.5节中的destination_ip_prohibited代理错误类型。

在将UDP代理和TCP CONNECT代理视为实施拒绝服务（Denial-of-Service，DoS）攻击的滥用基础设施时，二者有许多相似之处。两者都能隐藏攻击者的源地址，使其不被攻击目标察觉。在无状态大流量攻击（例如TCP SYN洪泛或UDP洪泛）的情况下，两种类型的代理都会将流量传递给目标主机。对于通过TCP CONNECT代理发送的有状态大流量攻击（例如HTTP洪泛），代理只有在目标通过TCP SYN-ACK响应表明愿意接受数据时才会发送数据。一旦通向目标的路径被淹没，TCP CONNECT代理将不再从目标收到回复，并将停止发送数据。由于UDP在UDP代理和目标之间不建立共享状态，UDP代理在此情况下可能会继续向目标发送数据。虽然UDP代理可以在观察到目标的响应之前限制其愿意转发的UDP数据包数量，但这只能在攻击针对开放UDP端口且运行在UDP之上的协议会做出响应（并且该响应会被UDP代理解释为愿意接受UDP）时才提供有限的DoS攻击防护。这样的数据包限制也可能对合法流量造成问题。

错误的关键字第4节中描述的安全性考量同样适用于此处。由于可以通过UDP隧道传输IP数据包，错误的关键字中的指导也可能适用。

IANA已在由<https://www.iana.org/assignments/http-upgrade-tokens>维护的"HTTP Upgrade Tokens"注册表中注册了"connect-udp"。

IANA已在由<https://www.iana.org/assignments/well-known-uris>维护的"Well-Known URIs"注册表中注册了"masque"。

本文档是MASQUE工作组的产物，作者感谢所有MASQUE爱好者们做出的贡献。本提案直接或间接地受到了许多人先前工作的启发，特别是Ben Schwartz的错误的关键字、Lucas Pardue的错误的关键字，以及由本文档作者编写的原始MASQUE协议错误的关键字。

作者要感谢Eric Rescorla建议使用HTTP方法来代理UDP。作者深深感谢Mark Nottingham和Lucas Pardue对本文档贡献的诸多改进。本文档的扩展性设计源自HTTP Datagrams设计团队（HTTP Datagrams Design Team），其成员包括Alan Frindell、Alex Chernyakhovsky、Ben Schwartz、Eric Rescorla、Lucas Pardue、Marcus Ihlar、Martin Thomson、Mike Bishop、Tommy Pauly、Victor Vasiliev以及本文档作者。

David SchinaziGoogle LLC1600 Amphitheatre ParkwayMountain View, CA 94043United States of AmericaEmail: dschinazi.ietf@gmail.com