Skip to main content

3. 连接建立与管理

翻译进度​

  • API初步翻译
  • RFC 2119关键词校对
  • 技术术语双语标注
  • 代码和ABNF格式检查
  • 最终审核

原文预览:

3.  Connection Setup and Management

3.1.  Discovering an HTTP/3 Endpoint

   HTTP relies on the notion of an authoritative response: a response
   that has been determined to be the most appropriate response for that
   request given the state of the target resource at the time of
   response message origination by (or at the direction of) the origin
   server identified within the target URI.  Locating an authoritative
   server for an HTTP URI is discussed in Section 4.3 of [HTTP].
...

3. Connection Setup and Management (连接建立与管理)

3.1. Discovering an HTTP/3 Endpoint (发现HTTP/3端点)​

HTTP依赖于权威响应 (Authoritative Response) 的概念：一个响应，根据响应消息发起时由目标URI中标识的源服务器（或在其指导下）确定的目标资源状态，被确定为该请求最合适的响应。在 [HTTP] 的第4.3节中讨论了为HTTP URI定位权威服务器。

"https"方案将权威与拥有客户端认为对URI的权威组件 (Authority Component) 标识的主机可信的证书相关联。在TLS握手中收到服务器证书后，客户端必须 (MUST) 使用 [HTTP] 第4.3.4节中描述的过程验证该证书是否与URI的源服务器 (Origin Server) 可接受匹配。如果无法针对URI的源服务器验证证书，则客户端禁止 (MUST NOT) 将该服务器视为该源的权威服务器。

客户端可以 (MAY) 尝试通过以下方式访问具有"https" URI的资源：将主机标识符解析为IP地址，在指定端口上建立到该地址的QUIC连接（包括如上所述验证服务器证书），并通过该安全连接向服务器发送针对该URI的HTTP/3请求消息。除非使用其他机制选择HTTP/3，否则在TLS握手期间在应用层协议协商 (Application-Layer Protocol Negotiation, ALPN; 参见 [RFC7301]) 扩展中使用令牌"h3"。

连接问题（例如，阻止UDP）可能导致无法建立QUIC连接；在这种情况下，客户端应该 (SHOULD) 尝试使用基于TCP的HTTP版本。

服务器可以 (MAY) 在任何UDP端口上提供HTTP/3服务；备用服务通告 (Alternative Service Advertisement) 始终包含显式端口，URI包含显式端口或与方案关联的默认端口。

3.1.1. HTTP Alternative Services (HTTP备用服务)​

HTTP源 (Origin) 可以通过Alt-Svc HTTP响应头字段或HTTP/2 ALTSVC帧 ([ALTSVC]) 使用"h3" ALPN令牌来通告等效HTTP/3端点的可用性。

例如，源可以通过包含以下头字段在HTTP响应中指示HTTP/3在同一主机名的UDP端口50781上可用：

Alt-Svc: h3=":50781"

在收到指示HTTP/3支持的Alt-Svc记录时，客户端可以 (MAY) 尝试建立到指定主机和端口的QUIC连接；如果此连接成功，客户端可以使用本文档中描述的映射发送HTTP请求。

3.1.2. Other Schemes (其他方案)​

尽管HTTP独立于传输协议，但"http"方案将权威与在权威组件中标识的任何主机的指定端口上接收TCP连接的能力相关联。由于HTTP/3不使用TCP，因此HTTP/3不能用于直接访问由"http" URI标识的资源的权威服务器。但是，诸如 [ALTSVC] 之类的协议扩展允许权威服务器识别其他也是权威的服务，这些服务可能可以通过HTTP/3访问。

在为方案不是"https"的源发出请求之前，客户端必须 (MUST) 确保服务器愿意为该方案提供服务。对于方案为"http"的源，[RFC8164] 中描述了完成此操作的实验性方法。将来可能会为各种方案定义其他机制。

3.2. Connection Establishment (连接建立)​

HTTP/3依赖QUIC版本1作为底层传输。未来的规范可以 (MAY) 定义将其他QUIC传输版本与HTTP/3一起使用。

QUIC版本1使用TLS版本1.3或更高版本作为其握手协议 (Handshake Protocol)。HTTP/3客户端必须 (MUST) 支持在TLS握手期间向服务器指示目标主机的机制。如果服务器由域名 ([DNS-TERMS]) 标识，则客户端必须 (MUST) 发送服务器名称指示 (Server Name Indication, SNI; [RFC6066]) TLS扩展，除非使用了指示目标主机的替代机制。

QUIC连接按 [QUIC-TRANSPORT] 中所述建立。在连接建立期间，通过在TLS握手中选择ALPN令牌"h3"来指示HTTP/3支持。可以 (MAY) 在同一握手中提供对其他应用层协议的支持。

虽然与核心QUIC协议相关的连接级选项在初始加密握手中设置，但特定于HTTP/3的设置在SETTINGS帧中传送。在建立QUIC连接后，每个端点必须 (MUST) 发送SETTINGS帧作为其各自HTTP控制流 (HTTP Control Stream) 的初始帧。

3.3. Connection Reuse (连接复用)​

HTTP/3连接在多个请求之间持久存在。为了获得最佳性能，预计客户端在确定不再需要与服务器进行进一步通信（例如，当用户离开特定网页时）或直到服务器关闭连接之前，不会关闭连接。

一旦与服务器端点的连接存在，此连接可以 (MAY) 被复用于具有多个不同URI权威组件的请求。要为新源使用现有连接，客户端必须 (MUST) 使用 [HTTP] 第4.3.4节中描述的过程验证服务器为新源服务器提供的证书。这意味着客户端需要保留服务器证书和验证该证书所需的任何其他信息；不这样做的客户端将无法为其他源复用连接。

如果证书因任何原因对于新源不可接受，则禁止 (MUST NOT) 复用连接，并且应该 (SHOULD) 为新源建立新连接。如果无法验证证书的原因可能适用于已与连接关联的其他源，则客户端应该 (SHOULD) 为这些源重新验证服务器证书。例如，如果证书验证失败是因为证书已过期或被吊销，这可能用于使该证书用于建立权威的所有其他源无效。

客户端不应该 (SHOULD NOT) 打开多个到给定IP地址和UDP端口的HTTP/3连接，其中IP地址和端口可能派生自URI、选定的备用服务 ([ALTSVC])、配置的代理或任何这些的名称解析。客户端可以 (MAY) 使用不同的传输或TLS配置打开到相同IP地址和UDP端口的多个HTTP/3连接，但应该 (SHOULD) 避免创建具有相同配置的多个连接。

鼓励服务器尽可能长时间地维护打开的HTTP/3连接，但如有必要，允许终止空闲连接 (Idle Connections)。当任一端点选择关闭HTTP/3连接时，终止端点应该 (SHOULD) 首先发送GOAWAY帧（第5.2节），以便两个端点都可以可靠地确定先前发送的帧是否已被处理，并优雅地完成或终止任何必要的剩余任务。

不希望客户端为特定源复用HTTP/3连接的服务器可以通过响应请求发送421（Misdirected Request，错误定向的请求）状态码来指示它对该请求不具有权威性；参见 [HTTP] 的第7.4节。

Last updated on