savearoundtrip: HTTPS DNS 레코드를 게시하고 왕복 1회를 건너뛰기
(savearoundtrip.com)- 웹사이트가 HTTPS DNS 레코드에 HTTP/3 지원을 게시하면 브라우저가 첫 연결부터 QUIC/HTTP/3를 사용할 수 있어 연결 왕복 1회를 줄일 수 있음
- 브라우저는 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는 레코드를 받지 못한 클라이언트를 위한 폴백으로 유지해야 함
핵심 개념
- 브라우저는 사이트의 HTTP/3 지원을 두 가지 방식으로 발견함
- HTTP/1 또는 HTTP/2로 먼저 연결한 뒤
Alt-SvcHTTP 헤더를 읽는 방식이 있음 - 연결을 열기 전 HTTPS DNS 레코드 조회에서 바로 확인하는 방식이 있음
- HTTP/1 또는 HTTP/2로 먼저 연결한 뒤
- 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 핸드셰이크는 브라우저에서 직접 확인할 수 없음- CORS가 교차 출처 헤더를 숨김
- 브라우저가 차가운 QUIC 연결을 강제로 만들 수 없음
- 입력한 도메인은 작은 오픈소스 백엔드로 전송되며, 해당 백엔드는
Alt-Svc확인과 실제 HTTP/3 핸드셰이크 확인만 수행함 - 데이터는 저장되지 않으며, 실제 HTTP/3 핸드셰이크는 quic-go로 수행됨
왕복 1회의 비용
- 왕복 1회는 서버로 메시지를 보내고 다시 받는 과정이며, 빛의 속도에 의해 제한됨
- 대략적인 왕복 시간은 도시 안에서 5~20ms, 국가 간 40~80ms, 대양 건너편 또는 모바일 네트워크에서 150ms 이상임
- Cloudflare Radar는 실시간 수치를 제공함
- 약 100ms 미만의 상호작용은 즉각적으로 느껴지고, 그 이상은 기다리는 느낌이 듦
- 이 페이지는 연결 시작부터 첫 페인트까지 약 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 레코드는 같은 HTTP/3 지원 신호를 DNS에 담음
- 클라이언트는 원래 수행하던 이름 확인 중 이 레코드를 읽기 때문에, 연결을 열기 전에 HTTP/3 지원을 알 수 있음
- HTTPS DNS 레코드를 쓰면 첫 연결부터 QUIC/HTTP/3를 사용할 수 있고, HTTP/1 또는 HTTP/2 연결을 먼저 소비하지 않아도 됨
HTTPS 레코드가 더 나은 이유
-
첫 바이트 이전 HTTP/3 발견
-
ECH: 암호화된 Client Hello
echSvcParam은 엔드포인트의ECHConfigList공개키를 담음- ECH는 SNI 서버 이름을 포함한 TLS ClientHello를 암호화해 네트워크 관찰자가 방문 사이트를 볼 수 없게 함
- 이 문제는 첫 ClientHello를 보내기 전에 공개키가 필요하기 때문에 HTTP 헤더로 해결할 수 없음
- 아직 연결이 존재하지 않는 시점에 키가 필요하므로, DNS의 HTTPS 레코드 같은 대역 외 채널만 ECH를 부트스트랩할 수 있음
- HTTPS RR이 없으면 ECH도 사용할 수 없음
-
IP 힌트로 더 빨리 연결 시작
- Happy Eyeballs v3는 A, AAAA, HTTPS 질의를 병렬로 수행함
- HTTPS 응답 안의
ipv4hint와ipv6hint는 A/AAAA 레코드보다 먼저 도착할 때 연결 후보 주소를 제공함 - 클라이언트는 A/AAAA 응답을 기다리는 대신 힌트 주소로 연결을 시작할 수 있음
- A/AAAA 레코드는 계속 도착하며, 도착 후 힌트를 대체함
Alt-Svc에는 이에 해당하는 기능이 없음
-
단일 권위 소스와 캐싱
- 도달 가능성 정보는 일반 TTL이 있는 DNS 안에 머물 수 있음
Alt-Svc방식은 출처별 HTTP 헤더 캐시에 정보가 흩어지고max-age딜레마가 생김max-age가 너무 길면 클라이언트가 오래된 대안을 사용하고, 너무 짧으면 더 자주 이전 프로토콜로 돌아감- 브라우저는 어차피 DNS 조회를 수행하므로, HTTPS 레코드는 그 조회가 최적 연결 정보를 함께 전달하게 함
-
기능 비교
실제 브라우저 측정
- Firefox Nightly 측정에서 브라우저는 HTTP/3 지원을
Alt-SvcHTTP 응답 헤더 또는 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임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는 프록시된 존에 대해
alpn="h3"가 있는 HTTPS 레코드를 자동으로 제공함 - 다른 CDN은 사용자가 직접 설정해야 함
- 가장 빠른 확인 방법은 위의 도메인 확인을 사용하는 것임
-
HTTPS 레코드가 오래된 클라이언트를 깨뜨리는지
- HTTPS 레코드를 이해하지 못하는 클라이언트는 해당 레코드를 무시하고 일반 A/AAAA 조회로 돌아감
- 여전히
Alt-Svc헤더를 보내고 있다면 그런 클라이언트는 해당 헤더도 사용할 수 있음 - HTTPS 레코드 게시 방식은 기존 동작에 추가되는 방식임
-
재방문에서는 어떻게 되는지
- 클라이언트가 한 번 HTTP/3로 통신한 뒤에는 재방문에서 QUIC 연결을 0-RTT로 재개할 수 있음
- 0-RTT에서는 핸드셰이크 왕복 없이 첫 요청을 바로 전송할 수 있음
- HTTPS 레코드 자체도 다른 DNS 응답처럼 TTL 동안 캐시되므로, 재방문에서는 대개 조회도 건너뜀
-
어떤 브라우저가 HTTPS 레코드를 쓰는지
-
Alt-Svc헤더를 제거해야 하는지Alt-Svc헤더는 제거하지 않아야 함- 오래된 클라이언트와 HTTPS 레코드를 전달하지 않는 리졸버 또는 네트워크를 위한 폴백으로 계속 보내야 함
- HTTPS 레코드를 읽는 브라우저는 DNS에서 HTTP/3를 알게 되며, HTTP/3 발견을 위해 왕복 1회를 쓰지 않게 됨
댓글과 토론
Lobste.rs 의견들
- 웹 호스팅 업체가 아직 H3를 지원하지 않지만, 새 서버 버전으로 무료 업그레이드해서 시험해볼 수 있음
끝나면 HTTPS DNS 레코드를 설정할 예정임 - Apple의
dig는 9.10.6이라 이 레코드 유형보다 오래된 버전인 듯함
Apple이 더 최신dig를 제공해야 할 것 같은데, macOS에서 DNS 조회할 때 선호하는 도구가 있는지 궁금함-
여러 플랫폼에서 doggo를 즐겨 씀
완벽하진 않지만 전반적으로 꽤 잘 동작했고, 필요한 기능을 상당히 충족해줌 -
Homebrew로 설치한
ldns의drill을 사용함% drill -Q https savearoundtrip.com 1 . alpn=h3,h2 ipv4hint=104.21.20.43,172.67.191.84 ech=AEX+DQBBzwAgACAdG3AfYFkusczSXA/kky1bgK67QViv5mNKyS3ITnrWbAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3030::ac43:bf54,2606:4700:3037::6815:142b
-
- HTTPS 리소스 레코드가 있으면 이를 읽는 모든 클라이언트가 안전하게 연결하게 됨
QUIC을 지원하지 않아도 마찬가지임 - 왜 이 글에 바이브코딩 태그가 붙었는지 모르겠음
CSS가 LLM에서 나온 것처럼 보일 수도 있다는 정도가 거의 전부임- 최초 커밋은 확실히 LLM을 통해 만들어진 것으로 보임: https://github.com/mxinden-bot/savearoundtrip/…
그리고 글이 장황함. 반복과 쓸모없는 내용, 이상한 시각화가 많아서 약 1700단어에 전체 너비 페이지 길이가 7300px를 넘음
500단어, 다이어그램 2개, 전체 길이 2000px 미만 정도로 줄이면 훨씬 나아질 듯함
- 최초 커밋은 확실히 LLM을 통해 만들어진 것으로 보임: https://github.com/mxinden-bot/savearoundtrip/…