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

• 웹사이트가 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-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 핸드셰이크는 브라우저에서 직접 확인할 수 없음
  • 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 발견

  • alpn SvcParam은 엔드포인트가 지원하는 ALPN 프로토콜 ID를 나열함
  • 예시는 h3인 HTTP/3와 h2임
  • 이 정보는 이름 확인 중 도착하므로, 클라이언트는 이전 HTTP/1 또는 HTTP/2 연결 뒤에 h3를 발견하지 않고 첫 연결부터 QUIC를 선택할 수 있음

• ECH: 암호화된 Client Hello

  • ech SvcParam은 엔드포인트의 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 레코드는 그 조회가 최적 연결 정보를 함께 전달하게 함

• 기능 비교

  • | 기능 | 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%임 {b:60,31,3,6}
• 네 그룹은 전체 연결을 모두 포괄하므로 합계가 100%임
• HTTPS record only와 Both는 사용 가능한 HTTPS 레코드가 있었고, Alt-Svc only는 레코드가 있었으면 줄일 수 있었던 간격임
• 수치는 Firefox Nightly의 GLAM 히스토그램에서 재구성한 연결별 추정치이며 최근 빌드 평균이라 근사값임

HTTPS 레코드 게시

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

• 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%였음 {b:80,53,49,13}
• 이 수치는 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 레코드를 쓰는지

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

• Alt-Svc 헤더를 제거해야 하는지

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