savearoundtrip: HTTPS DNS 레코드를 게시하고 왕복 1회를 건너뛰기

웹사이트가 HTTPS DNS 레코드에 HTTP/3 지원을 게시하면 브라우저가 첫 연결부터 QUIC/HTTP/3를 사용할 수 있어 연결 왕복 1회(Round Trip)를 줄일 수 있음
브라우저는 HTTP/1 또는 HTTP/2로 먼저 접속해 Alt-Svc 헤더를 읽거나, DNS 조회 단계에서 HTTPS 레코드를 읽어 HTTP/3 지원을 발견함
Firefox Nightly 측정에서 연결의 **31.4%**가 Alt-Svc 헤더만으로 HTTP/3를 알렸으며, 이 경우 HTTP/3는 이후 연결에서만 사용됨 {p:31}
HTTPS 레코드는 alpn, ech, ipv4hint, ipv6hint를 담아 첫 연결의 프로토콜 선택, ECH, 주소 힌트 제공을 DNS 응답 안에서 처리함
HTTPS 레코드는 기존 클라이언트에 추가적으로 동작하며, Alt-Svc는 레코드를 받지 못한 클라이언트를 위한 **폴백 (Fallback)**으로 유지해야 함

핵심 개념

브라우저는 사이트의 HTTP/3 지원을 두 가지 방식으로 발견함
HTTP/1 또는 HTTP/2로 먼저 연결한 뒤 Alt-Svc HTTP 헤더를 읽는 방식이 있음
연결을 열기 전 HTTPS DNS 레코드 조회에서 바로 확인하는 방식이 있음
HTTPS DNS 레코드를 사용할 때만 브라우저가 첫 연결부터 HTTP/3를 사용할 수 있으며, QUIC를 통해 왕복 1회를 줄일 수 있음
Firefox Nightly의 최근 빌드 평균 추정치에서 연결의 31.4%는 DNS가 아니라 Alt-Svc 헤더만으로 HTTP/3를 알렸음
현재 이 서버까지의 왕복 1회는 약 28ms로 측정됨

도메인 확인

savearoundtrip.com은 자체적으로 h3, IP 힌트, ECH가 있는 HTTPS 레코드를 게시함
입력한 도메인의 HTTPS 레코드는 브라우저에서 Cloudflare의 DNS-over-HTTPS 엔드포인트를 통해 조회됨
Alt-Svc 헤더와 실제 HTTP/3 핸드셰이크(Handshake)는 브라우저에서 직접 확인할 수 없음
- CORS가 교차 출처 헤더를 숨김
- 브라우저가 차가운 QUIC 연결을 강제로 만들 수 없음
입력한 도메인은 작은 오픈소스 백엔드로 전송되며, 해당 백엔드는 Alt-Svc 확인과 실제 HTTP/3 핸드셰이크 확인만 수행함
데이터는 저장되지 않으며, 실제 HTTP/3 핸드셰이크는 quic-go로 수행됨

왕복 1회의 비용

왕복 1회는 서버로 메시지를 보내고 다시 받는 과정이며, 빛의 속도에 의해 제한됨
대략적인 왕복 시간은 도시 안에서 5~~20ms, 국가 간 40~~80ms, 대양 건너편 또는 모바일 네트워크에서 150ms 이상임
Cloudflare Radar는 실시간 수치를 제공함
약 100ms 미만의 상호작용은 즉각적으로 느껴지고, 그 이상은 기다리는 느낌이 듦
이 페이지는 연결 시작부터 첫 페인트(First Paint)까지 약 41ms가 걸렸고, 이 서버까지의 실시간 왕복 1회는 약 28ms임
게시된 HTTPS 레코드는 브라우저가 첫 연결에서 TCP 대신 QUIC를 사용하게 해 해당 왕복 시간을 줄일 수 있음
이 페이지는 정적이고 작아 전체 시간 예산이 작지만, 실제 앱에서도 왕복 1회는 앞단에서 지불되는 고정 비용이며 여러 출처에 반복될 수 있음

낭비되는 왕복

Alt-Svc는 RFC 7838의 HTTP 응답 헤더임

클라이언트가 Alt-Svc

를 읽으려면 이미 TCP 연결을 열고 TLS 핸드셰이크를 마친 뒤 HTTP/1.1 또는 HTTP/2로 요청을 끝내야 함

이 방식에서는 서버가 HTTP/3도 지원한다는 사실을 이전 연결 이후에야 알게 되어, HTTP/3 업그레이드는 다음 연결에서 이뤄짐
RFC 9460의 **HTTPS 레코드 (HTTPS Record)**는 같은 HTTP/3 지원 신호를 DNS에 담음
클라이언트는 원래 수행하던 이름 확인 (Name Resolution) 중 이 레코드를 읽기 때문에, 연결을 열기 전에 HTTP/3 지원을 알 수 있음
HTTPS DNS 레코드를 쓰면 첫 연결부터 QUIC/HTTP/3를 사용할 수 있고, HTTP/1 또는 HTTP/2 연결을 먼저 소비하지 않아도 됨

HTTPS 레코드가 더 나은 이유

첫 바이트 이전 HTTP/3 발견

alpn SvcParam은 엔드포인트가 지원하는 ALPN (Application-Layer Protocol Negotiation) 프로토콜 ID를 나열함

예시는 h3인 HTTP/3와 h2임
이 정보는 이름 확인 중 도착하므로, 클라이언트는 이전 HTTP/1 또는 HTTP/2 연결 뒤에 h3를 발견하지 않고 첫 연결부터 QUIC를 선택할 수 있음

ECH: 암호화된 Client Hello

ech SvcParam은 엔드포인트의 ECHConfigList 공개키를 담음

ECH (Encrypted Client Hello)는 SNI (Server Name Indication) 서버 이름을 포함한 TLS ClientHello를 암호화해 네트워크 관찰자가 방문 사이트를 볼 수 없게 함
이 문제는 첫 ClientHello를 보내기 전에 공개키가 필요하기 때문에 HTTP 헤더로 해결할 수 없음
아직 연결이 존재하지 않는 시점에 키가 필요하므로, DNS의 HTTPS 레코드 같은 대역 외 채널 (Out-of-band channel)만 ECH를 부트스트랩 (Bootstrap)할 수 있음
HTTPS RR (Resource Record)이 없으면 ECH도 사용할 수 없음

IP 힌트로 더 빨리 연결 시작

Happy Eyeballs v3는 A, AAAA, HTTPS 질의를 병렬로 수행함
HTTPS 응답 안의 ipv4hint와 ipv6hint는 A/AAAA 레코드보다 먼저 도착할 때 연결 후보 주소를 제공함
클라이언트는 A/AAAA 응답을 기다리는 대신 힌트 주소로 연결을 시작할 수 있음
A/AAAA 레코드는 계속 도착하며, 도착 후 힌트를 대체함
Alt-Svc에는 이에 해당하는 기능이 없음

단일 권위 소스 (Single Source of Truth) 및 캐싱

도달 가능성 정보는 일반 TTL (Time To Live)이 있는 DNS 안에 머물 수 있음
Alt-Svc 방식은 출처별 HTTP 헤더 캐시에 정보가 흩어지고 max-age 딜레마가 생김
max-age가 너무 길면 클라이언트가 오래된 대안을 사용하고, 너무 짧으면 더 자주 이전 프로토콜로 돌아감
브라우저는 어차피 DNS 조회를 수행하므로, HTTPS 레코드는 그 조회가 최적 연결 정보를 함께 전달하게 함

기능 비교

기능	`Alt-Svc` HTTP 헤더 (RFC 7838)	HTTPS RR (RFC 9460)
학습 시점	전체 연결 이후	DNS 확인 중
첫 연결에서 h3	불가	가능
IP 힌트	해당 없음	`ipv4hint` / `ipv6hint`
ECH 키	불가능	`ech` 매개변수
진실 공급원	HTTP 헤더와 취약한 캐시	TTL이 있는 DNS

실제 브라우저 측정

Firefox Nightly 측정에서 브라우저는 HTTP/3 지원을 Alt-Svc HTTP 응답 헤더 또는 HTTPS DNS 레코드로 알 수 있음
Alt-Svc

는 이미 연결한 뒤에만 보이고, HTTPS DNS 레코드는 연결 전에 보임

모든 연결은 네 그룹 중 하나에 속함
Neither는 HTTP/3가 전혀 광고되지 않은 연결임
Alt-Svc only는 헤더로만 광고되어 첫 연결에서 HTTP/3를 사용할 수 없었던 연결임
HTTPS record only는 DNS에 광고되어 첫 연결부터 HTTP/3로 갈 수 있었던 연결임
Both는 DNS와 헤더 모두에서 광고된 연결임
측정 연결 비중은 Neither 59.8%, Alt-Svc only 31.4%, HTTPS record only 2.8%, Both 6%임
네 그룹은 전체 연결을 모두 포괄하므로 합계가 100%임
HTTPS record only와 Both는 사용 가능한 HTTPS 레코드가 있었고, Alt-Svc only는 레코드가 있었으면 줄일 수 있었던 간격임
수치는 Firefox Nightly의 GLAM 히스토그램에서 재구성한 연결별 추정치이며 최근 빌드 평균이라 근사값임

HTTPS 레코드 게시

h3와 주소 힌트를 광고하는 ServiceMode HTTPS 레코드는 한 줄로 게시할 수 있음

; zone file (BIND-style)
example.com. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10

example.com.

은 레코드를 게시하는 이름이며, 끝의 점은 완전한 도메인 이름을 뜻함
3600

은 리졸버가 레코드를 캐시할 수 있는 초 단위 TTL (Time To Live)임
IN

은 모든 웹 레코드와 같은 인터넷 DNS 클래스임
HTTPS

는 RFC 9460의 레코드 유형임
1

은 우선순위이며, 1 이상은 매개변수를 담는 ServiceMode임
0

은 다른 대상으로만 가리키는 AliasMode임
.

은 대상 호스트이며, 소유자 이름 자체인 example.com을 뜻함
alpn="h3,h2"

는 서버가 지원하는 프로토콜을 우선순위대로 나열하며, h3는 HTTP/3이고 h2는 HTTP/2임
ipv4hint와 ipv6hint는 클라이언트가 A/AAAA 조회와 함께 즉시 연결을 시작할 수 있는 주소임

Cloudflare, Route 53 등 대부분의 관리형 DNS 제공자는 HTTPS 레코드 유형을 직접 제공함
도메인 지원 여부는 checker로 확인할 수 있음

실제 HTTPS 레코드가 담는 기능

Firefox Nightly에서 HTTPS 레코드를 본 연결 중 각 기능을 담은 비율이 측정됨
ALPN의 h3는 80.3%였고, IPv4 힌트는 52.9%였음
IPv6 힌트는 49.4%였고, ECH는 12.8%였음
이 수치는 GLAM 히스토그램에서 재구성한 연결별 추정치라 근사값임

FAQ

CDN이 자동으로 게시하는지

일부 CDN은 HTTPS 레코드를 자동으로 게시함
Cloudflare는 프록시된 존(zone)에 대해 alpn="h3"가 있는 HTTPS 레코드를 자동으로 제공함
다른 CDN은 사용자가 직접 설정해야 함
가장 빠른 확인 방법은 위의 도메인 확인을 사용하는 것임

HTTPS 레코드가 오래된 클라이언트를 깨뜨리는지

HTTPS 레코드를 이해하지 못하는 클라이언트는 해당 레코드를 무시하고 일반 A/AAAA 조회로 돌아감
여전히 Alt-Svc 헤더를 보내고 있다면 그런 클라이언트는 해당 헤더도 사용할 수 있음
HTTPS 레코드 게시 방식은 기존 동작에 추가되는 방식임

재방문에서는 어떻게 되는지

클라이언트가 한 번 HTTP/3로 통신한 뒤에는 재방문에서 QUIC 연결을 0-RTT로 재개할 수 있음
0-RTT에서는 핸드셰이크 왕복 없이 첫 요청을 바로 전송할 수 있음
HTTPS 레코드 자체도 다른 DNS 응답처럼 TTL 동안 캐시되므로, 재방문에서는 대개 조회도 건너뜀

어떤 브라우저가 HTTPS 레코드를 사용하는지

주요 엔진은 HTTPS 레코드를 기본 활성화 상태로 지원함
방문자가 DNS-over-HTTPS (DoH)를 켰는지와 관계없이 레코드를 읽음
Safari는 운영체제 리졸버 (OS resolver)를 사용함
Chrome은 자체 내장 리졸버를 사용하며, DoH 또는 일반 DNS를 통해 동작함
Firefox는 두 방식 모두 사용할 수 있음

Alt-Svc

헤더를 제거해야 하는지