• 웹사이트가 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회는 서버로 메시지를 보내고 다시 받는 과정이며, 빛의 속도에 의해 제한됨
• 대략적인 왕복 시간은 도시 안에서 520ms, 국가 간 4080ms, 대양 건너편 또는 모바일 네트워크에서 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 레코드는 그 조회가 최적 연결 정보를 함께 전달하게 함

기능 비교

실제 브라우저 측정

• 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

헤더를 제거해야 하는지

Alt-Svc

헤더는 제거하지 않아야 함

• 오래된 클라이언트와 HTTPS 레코드를 전달하지 않는 리졸버 또는 네트워크를 위한 폴백 (fallback)으로 계속 보내야 함
• HTTPS 레코드를 읽는 브라우저는 DNS에서 HTTP/3를 알게 되며, HTTP/3 발견을 위해 왕복 (round-trip) 1회를 쓰지 않게 됨