HTTP/3를 켜두어도 첫 방문은 HTTP/2로 시작할 수 있습니다. 서버가 HTTP 응답 헤더로만 HTTP/3 지원을 알리면, 브라우저는 한 번 접속한 뒤에야 그 사실을 알기 때문입니다.
savearoundtrip ↗은 HTTP/3 지원 정보를 DNS 단계에서 알리자고 제안합니다. Alt-Svc 헤더만 쓰지 말고 HTTPS DNS 레코드에도 HTTP/3 지원 정보를 게시하면, 브라우저는 첫 연결부터 QUIC/HTTP/3를 선택할 수 있습니다.
이 글은 작성 시점 2026-06-17 · savearoundtrip ↗, RFC 9460 ↗, MDN Alt-Svc 문서 ↗ 스냅숏 기준으로 정리했습니다.
HTTPS DNS 레코드는 브라우저가 지원 여부를 아는 시점을 첫 연결 전으로 앞당깁니다.
왜 한 번 늦어지는가
기존 HTTP/3 광고는 흔히 Alt-Svc 헤더로 이뤄집니다. MDN의 Alt-Svc 문서 ↗에 따르면 이 헤더는 같은 origin을 처리할 수 있는 alternative service를 응답으로 알려줍니다.
Alt-Svc는 HTTP 응답 헤더입니다. 브라우저가 이 헤더를 읽으려면 이미 DNS를 조회하고, TCP 연결을 열고, TLS 핸드셰이크를 마치고, HTTP/1.1 또는 HTTP/2 요청을 보낸 뒤여야 합니다.
sequenceDiagram
participant C as Browser
participant D as DNS
participant S as Server
Note over C,S: 첫 연결
C->>D: A / AAAA 조회
D-->>C: IP 주소
C->>S: TCP + TLS + HTTP/2
S-->>C: 응답 + Alt-Svc: h3
Note over C,S: 이제야 HTTP/3 지원을 알게 됨
Note over C,S: 다음 연결
C->>S: QUIC + HTTP/3이 방식은 두 번째 연결부터 효과가 있고, 첫 연결에는 도움이 되지 않습니다. savearoundtrip은 이 첫 연결의 낭비를 “HTTP/3를 알기 위한 round trip”으로 봅니다.
HTTPS 레코드는 무엇을 바꾸나
RFC 9460 ↗은 SVCB와 HTTPS 리소스 레코드를 정의합니다. 이 레코드는 HTTP origin에 연결할 때 필요한 서비스 바인딩 정보와 파라미터를 DNS 응답에 싣습니다. 클라이언트는 이 정보로 연결을 열기 전에 프로토콜과 주소를 고를 수 있습니다.
HTTP/3 지원을 알리는 값은 alpn입니다. alpn="h3,h2"처럼 게시하면 클라이언트는 이 endpoint가 HTTP/3와 HTTP/2를 지원한다는 사실을 DNS 조회 단계에서 알 수 있습니다.
sequenceDiagram
participant C as Browser
participant D as DNS
participant S as Server
Note over C,S: 첫 연결
C->>D: HTTPS 레코드 조회
D-->>C: alpn=h3 + IP hints (+ ECH)
C->>S: QUIC + HTTP/3 핸드셰이크
S-->>C: HTTP/3 응답Alt-Svc는 “접속해보니 다음부터 HTTP/3 가능”이고, HTTPS 레코드는 “접속하기 전에 이미 HTTP/3 가능”입니다.
한 줄 설정의 의미
savearoundtrip에서 제시한 BIND 스타일 예시는 다음과 같습니다.
; zone file (BIND-style)
example.com. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10각 항목의 역할은 다음과 같습니다.
| 항목 | 의미 |
|---|---|
HTTPS | RFC 9460의 HTTPS 리소스 레코드 타입 |
1 | ServiceMode priority. 파라미터를 직접 담는 모드 |
. | target host. 현재 owner name 자체를 가리킴 |
alpn="h3,h2" | 지원하는 애플리케이션 프로토콜 |
ipv4hint, ipv6hint | A/AAAA 응답 전에 연결 후보 주소로 쓸 수 있는 힌트 |
ipv4hint와 ipv6hint는 정답 주소의 대체물이 아니라 연결 시작을 앞당기기 위한 힌트입니다. 최종 A/AAAA 응답이 오면 그 값이 우선합니다.
ECH까지 생각하면 DNS가 더 중요해진다
HTTPS 레코드는 HTTP/3 광고만을 위한 장치가 아닙니다. savearoundtrip은 ech 파라미터도 함께 설명합니다. ECH(Encrypted ClientHello)는 TLS ClientHello 안의 SNI 같은 정보를 암호화합니다. 그래서 네트워크 관찰자가 방문 사이트를 알아내기 어려워집니다.
ECH에는 순서 문제가 있습니다. ClientHello를 암호화하려면 공개키가 필요하지만, 공개키를 HTTP 응답 헤더로 받으려면 이미 ClientHello를 보낸 뒤입니다. 그래서 ECH 설정은 연결 전에 볼 수 있는 채널, 즉 DNS의 HTTPS 레코드와 잘 맞습니다.
alpn만 설정하면 됩니다. HTTPS 레코드를 설계할 때는 ech와 IP hints까지 담는 "연결 전 메타데이터"로 봅니다.
Alt-Svc는 버려도 될까
아직은 아닙니다. savearoundtrip FAQ도 Alt-Svc를 fallback으로 계속 보내라고 권합니다. HTTPS 레코드를 이해하지 못하는 클라이언트, 레코드를 제대로 전달하지 않는 resolver나 네트워크가 여전히 있을 수 있기 때문입니다.
다음 순서로 적용합니다.
- 서버 또는 CDN에서 HTTP/3가 실제로 동작하는지 확인합니다.
- DNS provider가
HTTPS레코드를 지원하는지 확인합니다. alpn="h3,h2"를 게시합니다.dig +short HTTPS example.com같은 명령으로 응답을 확인합니다.- 기존
Alt-Svc헤더는 fallback으로 유지합니다.
Cloudflare는 공식 블로그 ↗에서, 프록시된 zone은 HTTP/3 설정에 따라 HTTPS 레코드를 자동 생성한다고 설명했습니다. 다른 DNS provider나 CDN에서는 직접 설정해야 할 수 있습니다.
마무리
웹 성능 개선은 번들 크기나 이미지 최적화에서 끝나지 않습니다. 사용자의 첫 요청이 서버에 닿기 전에도 줄일 수 있는 비용이 있습니다.
이미 HTTP/3를 지원한다면, 도메인이 그 사실을 첫 연결 전에 알리는지 dig +short HTTPS example.com으로 확인합니다.
HTTPS DNS 레코드를 게시하면 첫 연결부터 HTTP/3를 쓸 수 있습니다. Alt-Svc는 HTTPS 레코드를 지원하지 않는 환경을 위한 fallback으로 남겨둡니다.