HTTP/3를 켜두었는데도 첫 방문이 여전히 HTTP/2로 시작할 수 있습니다. 서버가 HTTP 응답 헤더로만 “나 HTTP/3도 할 수 있어요”라고 알려주면, 브라우저는 이미 한 번 접속한 뒤에야 그 사실을 알기 때문입니다.
savearoundtrip ↗은 이 낭비를 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 같은 정보를 암호화해 네트워크 관찰자가 방문 사이트를 덜 알 수 있게 만드는 흐름입니다.
여기에는 순서 문제가 있습니다. ClientHello를 암호화하려면 공개키가 필요하지만, 공개키를 HTTP 응답 헤더로 받으려면 이미 ClientHello를 보낸 뒤입니다. 그래서 ECH 설정은 연결 전에 볼 수 있는 채널, 즉 DNS의 HTTPS 레코드와 잘 맞습니다.
alpn이 먼저 보이지만, 장기적으로는 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/2로 먼저 접속한 뒤 Alt-Svc 헤더를 읽고 다음 방문에서야 HTTP/3로 전환되는 느린 경로를 보여줍니다.
오른쪽은 DNS 조회 단계에서 HTTPS 레코드의 alpn="h3,h2", ipv4hint, ech 정보를 받아 첫 연결부터 QUIC/HTTP/3를 선택하는 빠른 경로를 보여줍니다. 중앙에는 “Save one round trip”이라는 문구와 함께 DNS, TLS, QUIC, HTTP/3 흐름이 선으로 연결된 개발자 블로그용 네트워크 다이어그램 스타일이 좋습니다.
마무리
웹 성능 개선은 번들 크기나 이미지 최적화에서 끝나지 않습니다. 사용자의 첫 요청이 서버에 닿기 전에도 줄일 수 있는 비용이 있습니다.
이미 HTTP/3를 지원하고 있다면 다음 질문은 간단합니다. 내 도메인은 그 사실을 첫 연결 전에 알려주고 있는가?
HTTPS DNS 레코드는 이 질문에 답하는 작지만 실용적인 장치입니다. 첫 연결부터 HTTP/3로 가는 길을 열어두고, Alt-Svc는 뒤처진 환경을 위한 fallback으로 남겨두면 됩니다.