savearoundtrip: publish an HTTPS DNS record, skip a round trip

查看原文 / View Original 编辑 / Edit

savearoundtrip: 发布 HTTPS DNS 记录，省去一次往返

Advertise HTTP/3 support in an HTTPS DNS record, not just an Alt-Svc header, and browsers use HTTP/3 (QUIC) on the first connection. A browser can discover a site’s HTTP/3 support two ways: either by first connecting over HTTP/1 or HTTP/2 and reading its Alt-Svc HTTP header, or right away from an HTTPS DNS record lookup. Only with the HTTPS DNS record can the browser use HTTP/3 on the first connection, saving a round trip using QUIC.

在 HTTPS DNS 记录中声明 HTTP/3 支持，而不仅仅是使用 Alt-Svc 响应头，这样浏览器就能在首次连接时直接使用 HTTP/3 (QUIC)。浏览器有两种方式发现网站对 HTTP/3 的支持：要么通过 HTTP/1 或 HTTP/2 连接并读取其 Alt-Svc HTTP 响应头，要么直接通过 HTTPS DNS 记录查询获取。只有通过 HTTPS DNS 记录，浏览器才能在首次连接时使用 HTTP/3，从而利用 QUIC 省去一次往返。

… of connections in Firefox Nightly reach HTTP/3 only on a later connection: the site advertised HTTP/3 only in an Alt-Svc HTTP header, not in DNS, though it could have published both. A published HTTPS record would have saved each one a round trip on the first connection.

……在 Firefox Nightly 中，部分连接直到后续请求才切换到 HTTP/3：这是因为网站仅在 Alt-Svc HTTP 响应头中声明了 HTTP/3，而未在 DNS 中发布，尽管它本可以两者兼顾。如果发布了 HTTPS 记录，这些连接在首次建立时就能各省去一次往返。

This site eats its own dog food: savearoundtrip.com publishes an HTTPS record with h3, IP hints, and ECH. The HTTPS record is looked up in your browser via Cloudflare’s DNS-over-HTTPS endpoint. The Alt-Svc header and a live HTTP/3 handshake can’t be checked from a browser (CORS hides cross-origin headers, and a browser can’t force a cold QUIC connection), so the domain you enter is sent to a small open-source backend that runs only those two checks. Nothing is stored. The live HTTP/3 handshake is performed with quic-go.

本网站践行了“吃自己的狗粮”原则：savearoundtrip.com 发布了包含 h3、IP 提示和 ECH 的 HTTPS 记录。该 HTTPS 记录通过您浏览器中的 Cloudflare DNS-over-HTTPS 端点进行查询。由于浏览器无法直接检查 Alt-Svc 响应头和实时 HTTP/3 握手（CORS 会隐藏跨域响应头，且浏览器无法强制发起冷启动的 QUIC 连接），因此您输入的域名会被发送到一个小型开源后端，仅用于执行这两项检查。所有数据均不存储。实时 HTTP/3 握手通过 quic-go 完成。

what a round trip costs

一次往返的代价

A round trip is one message to the server and back, bounded by the speed of light: roughly 5 to 20 ms within a city, 40 to 80 ms across a country, and 150 ms or more across an ocean or a mobile network (Cloudflare Radar has live numbers). It is paid where people notice: under about 100 ms an interaction feels instantaneous; past that it feels like waiting (Nielsen Norman Group).

一次往返是指消息发送至服务器并返回的过程，受光速限制：在城市内约为 5 到 20 毫秒，跨国约为 40 到 80 毫秒，跨洋或在移动网络下则需 150 毫秒或更久（Cloudflare Radar 提供实时数据）。这种延迟在用户感知最明显的地方产生影响：交互时间在 100 毫秒以内时感觉是瞬时的；超过这个时间就会产生等待感（尼尔森诺曼集团研究）。

the wasted round trip

被浪费的往返

Alt-Svc (RFC 7838) is an HTTP response header. To read it, the client must finish a request, which means it has already opened a TCP connection, done a TLS handshake, and spoken HTTP/1.1 or HTTP/2. Only then does it learn “by the way, I also speak HTTP/3”. The HTTP/3 upgrade lands on the next connection.

Alt-Svc (RFC 7838) 是一个 HTTP 响应头。客户端必须完成一次请求才能读取它，这意味着客户端已经打开了 TCP 连接、完成了 TLS 握手，并使用了 HTTP/1.1 或 HTTP/2 协议。只有在那之后，客户端才会得知“顺便说一下，我也支持 HTTP/3”。而 HTTP/3 的升级要等到下一次连接才会生效。

An HTTPS record (RFC 9460) carries the same “I speak HTTP/3” signal, but in the DNS. The client reads it during the name resolution it was going to do anyway, before it opens any connection. So it can make its very first connection over QUIC/HTTP/3, with no earlier HTTP/1 or HTTP/2 connection spent just to find out.

HTTPS 记录 (RFC 9460) 携带了同样的“我支持 HTTP/3”信号，但它是存在于 DNS 中的。客户端在进行域名解析时（无论如何都要进行这一步）就会读取到它，甚至在建立任何连接之前。因此，它可以直接通过 QUIC/HTTP/3 建立首次连接，无需为了获取该信息而先进行一次 HTTP/1 或 HTTP/2 连接。

why the HTTPS record is strictly better

为什么 HTTPS 记录绝对更优

The HTTPS resource record (RFC 9460, Nov 2023) folds everything a client needs to open the optimal connection into the DNS answer it was already fetching. Concretely:

HTTPS 资源记录 (RFC 9460, 2023 年 11 月) 将客户端建立最优连接所需的一切信息，整合进了它本就需要获取的 DNS 响应中。具体表现为：

  1. HTTP/3 discovery before the first byte: The alpn SvcParam lists the ALPN protocol IDs the endpoint speaks, e.g. h3 (HTTP/3) and h2. Because it arrives during name resolution, the client can pick QUIC for its very first connection instead of discovering h3 only after a previous HTTP/1 or HTTP/2 connection.

  2. 在首字节传输前的 HTTP/3 发现：alpn SvcParam 列出了端点支持的 ALPN 协议 ID，例如 h3 (HTTP/3) 和 h2。由于它在域名解析阶段就已送达，客户端可以在首次连接时直接选择 QUIC，而无需在之前的 HTTP/1 或 HTTP/2 连接之后才发现 h3 的存在。

  3. ECH: Encrypted Client Hello (only the DNS can deliver it): The ech SvcParam carries the endpoint’s ECHConfigList public keys (RFC 9849). ECH encrypts the TLS ClientHello, including the SNI server name, so a network observer can’t see which site you’re visiting. This is a chicken-and-egg problem an HTTP header can’t solve: you need the public key before you send the first ClientHello, which is exactly when no connection exists yet. Only an out-of-band channel, the DNS (the HTTPS record), can bootstrap ECH. No HTTPS RR, no ECH.

  4. ECH：加密客户端问候（仅 DNS 可实现）：ech SvcParam 携带了端点的 ECHConfigList 公钥 (RFC 9849)。ECH 会加密 TLS ClientHello（包括 SNI 服务器名称），因此网络观察者无法看到您正在访问哪个网站。这是一个 HTTP 响应头无法解决的“先有鸡还是先有蛋”的问题：您需要在发送第一个 ClientHello 之前就获得公钥，而此时连接尚未建立。只有带外通道——即 DNS（HTTPS 记录）——才能引导 ECH。没有 HTTPS 记录，就没有 ECH。

  5. IP hints: start connecting sooner: Happy Eyeballs v3 already issues the A, AAAA, and HTTPS queries in parallel. The ipv4hint and ipv6hint inside that HTTPS answer give it candidate addresses to start connecting from when the answer arrives before the A/AAAA records, instead of waiting on them. The A/AAAA records still come and supersede the hints; the hints just keep the first connection attempt from stalling on a lookup that has not returned yet. Alt-Svc has no equivalent.

  6. IP 提示：更快开始连接：Happy Eyeballs v3 已经可以并行发起 A、AAAA 和 HTTPS 查询。HTTPS 响应中的 ipv4hint 和 ipv6hint 提供了候选地址，当这些信息比 A/AAAA 记录更早到达时，客户端可以立即开始连接，而无需等待 A/AAAA 记录。A/AAAA 记录随后会到达并覆盖这些提示；提示的作用仅仅是防止首次连接尝试因查询尚未返回而停滞。Alt-Svc 没有类似功能。

  7. One authoritative source, sane caching: Reachability lives in the DNS with a normal TTL, instead of being smeared across per-origin HTTP-header caches with their max-age dilemma: too long and clients use stale alternatives, too short and they fall back to older protocols more often than they should. The browser was going to do a DNS lookup anyway; this just makes that lookup carry the answer.

  8. 单一权威来源，合理的缓存机制：可达性信息存在于具有正常 TTL 的 DNS 中，而不是分散在各个源站的 HTTP 响应头缓存中，从而避免了 max-age 的困境：设置过长会导致客户端使用过期的替代方案，设置过短则会导致客户端过于频繁地回退到旧协议。浏览器无论如何都要进行 DNS 查询，这只是让查询结果携带了更多信息。

CapabilityAlt-Svc HTTP header (RFC 7838)HTTPS RR (RFC 9460)
learned when?after a full connectionduring DNS resolution
h3 on first connectionnoyes
IP hintsn/aipv4hint / ipv6hint
ECH keysimpossibleech param
source of truthHTTP header + fragile cachethe DNS, with a TTL
功能Alt-Svc HTTP 响应头 (RFC 7838)HTTPS RR (RFC 9460)
获取时间完整连接建立后DNS 解析期间
首次连接使用 h3否是
IP 提示不适用ipv4hint / ipv6hint
ECH 密钥不可能ech 参数
事实来源HTTP 响应头 + 脆弱的缓存DNS（带 TTL）
← 返回新闻列表 / Back to news list