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

> Clean Markdown view of GeekNews topic #30544. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30544](https://news.hada.io/topic?id=30544)
- GeekNews Markdown: [https://news.hada.io/topic/30544.md](https://news.hada.io/topic/30544.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-17T00:01:49+09:00
- Updated: 2026-06-17T00:01:49+09:00
- Original source: [savearoundtrip.com](https://savearoundtrip.com/)
- Points: 1
- Comments: 1

## Topic Body

- 웹사이트가 **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 연결을 강제로 만들 수 없음
- 입력한 도메인은 작은 [오픈소스 백엔드](https://github.com/mxinden-bot/savearoundtrip/tree/main/check-service)로 전송되며, 해당 백엔드는 `Alt-Svc` 확인과 실제 HTTP/3 핸드셰이크 확인만 수행함
- 데이터는 저장되지 않으며, 실제 HTTP/3 핸드셰이크는 [quic-go](https://github.com/quic-go/quic-go)로 수행됨

### 왕복 1회의 비용
- 왕복 1회는 서버로 메시지를 보내고 다시 받는 과정이며, 빛의 속도에 의해 제한됨
- 대략적인 왕복 시간은 도시 안에서 5~20ms, 국가 간 40~80ms, 대양 건너편 또는 모바일 네트워크에서 150ms 이상임
- [Cloudflare Radar](https://radar.cloudflare.com/quality)는 실시간 수치를 제공함
- 약 100ms 미만의 상호작용은 즉각적으로 느껴지고, 그 이상은 기다리는 느낌이 듦
- 이 페이지는 연결 시작부터 첫 페인트까지 약 **41ms**가 걸렸고, 이 서버까지의 실시간 왕복 1회는 약 **28ms**임
- 게시된 HTTPS 레코드는 브라우저가 첫 연결에서 TCP 대신 QUIC를 사용하게 해 해당 왕복 시간을 줄일 수 있음
- 이 페이지는 정적이고 작아 전체 시간 예산이 작지만, 실제 앱에서도 왕복 1회는 앞단에서 지불되는 고정 비용이며 여러 출처에 반복될 수 있음

### 낭비되는 왕복
- `Alt-Svc`는 [RFC 7838](https://www.rfc-editor.org/rfc/rfc7838)의 HTTP 응답 헤더임
- 클라이언트가 `Alt-Svc`를 읽으려면 이미 TCP 연결을 열고 TLS 핸드셰이크를 마친 뒤 HTTP/1.1 또는 HTTP/2로 요청을 끝내야 함
- 이 방식에서는 서버가 HTTP/3도 지원한다는 사실을 이전 연결 이후에야 알게 되어, HTTP/3 업그레이드는 다음 연결에서 이뤄짐
- [RFC 9460](https://www.rfc-editor.org/rfc/rfc9460)의 **HTTPS 레코드**는 같은 HTTP/3 지원 신호를 DNS에 담음
- 클라이언트는 원래 수행하던 이름 확인 중 이 레코드를 읽기 때문에, 연결을 열기 전에 HTTP/3 지원을 알 수 있음
- HTTPS DNS 레코드를 쓰면 첫 연결부터 QUIC/HTTP/3를 사용할 수 있고, HTTP/1 또는 HTTP/2 연결을 먼저 소비하지 않아도 됨

### HTTPS 레코드가 더 나은 이유
- ## 첫 바이트 이전 HTTP/3 발견
  - `alpn` SvcParam은 엔드포인트가 지원하는 [ALPN](https://www.rfc-editor.org/rfc/rfc7301) 프로토콜 ID를 나열함
  - 예시는 `h3`인 [HTTP/3](https://www.rfc-editor.org/rfc/rfc9114)와 `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](https://datatracker.ietf.org/doc/draft-ietf-happy-happyeyeballs-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://www.rfc-editor.org/rfc/rfc7838)) | HTTPS RR ([RFC 9460](https://www.rfc-editor.org/rfc/rfc9460)) |
  - | --- | --- | --- |
  - | 학습 시점 | 전체 연결 이후 | 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 레코드는 한 줄로 게시할 수 있음

```dns
; 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://savearoundtrip.com/#check)로 확인할 수 있음

### 실제 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://savearoundtrip.com/#check)을 사용하는 것임
- ## HTTPS 레코드가 오래된 클라이언트를 깨뜨리는지
  - HTTPS 레코드를 이해하지 못하는 클라이언트는 해당 레코드를 무시하고 일반 A/AAAA 조회로 돌아감
  - 여전히 `Alt-Svc` 헤더를 보내고 있다면 그런 클라이언트는 해당 헤더도 사용할 수 있음
  - HTTPS 레코드 게시 방식은 기존 동작에 추가되는 방식임
- ## 재방문에서는 어떻게 되는지
  - 클라이언트가 한 번 HTTP/3로 통신한 뒤에는 재방문에서 QUIC 연결을 **0-RTT**로 재개할 수 있음
  - 0-RTT에서는 핸드셰이크 왕복 없이 첫 요청을 바로 전송할 수 있음
  - HTTPS 레코드 자체도 다른 DNS 응답처럼 TTL 동안 캐시되므로, 재방문에서는 대개 조회도 건너뜀
- ## 어떤 브라우저가 HTTPS 레코드를 쓰는지
  - 주요 엔진은 HTTPS 레코드를 기본 활성화 상태로 지원함
  - 방문자가 DNS-over-HTTPS를 켰는지와 관계없이 레코드를 읽음
  - [Safari](https://mailarchive.ietf.org/arch/msg/dnsop/ldaCto09yaOuSXM92HgJhGqmPJw/)는 운영체제 리졸버를 사용함
  - [Chrome](https://chromestatus.com/feature/5154357283651584)은 자체 내장 리졸버를 사용하며, DoH 또는 일반 DNS를 통해 동작함
  - [Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1721132)는 두 방식 모두 사용할 수 있음
- ## `Alt-Svc` 헤더를 제거해야 하는지
  - `Alt-Svc` 헤더는 제거하지 않아야 함
  - 오래된 클라이언트와 HTTPS 레코드를 전달하지 않는 리졸버 또는 네트워크를 위한 폴백으로 계속 보내야 함
  - HTTPS 레코드를 읽는 브라우저는 DNS에서 HTTP/3를 알게 되며, HTTP/3 발견을 위해 왕복 1회를 쓰지 않게 됨

## Comments



### Comment 59749

- Author: neo
- Created: 2026-06-17T00:01:50+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/wlm6dv/savearoundtrip_publish_https_dns_record) 
- 웹 호스팅 업체가 아직 **H3**를 지원하지 않지만, 새 서버 버전으로 무료 업그레이드해서 시험해볼 수 있음  
  끝나면 **HTTPS DNS 레코드**를 설정할 예정임
- Apple의 `dig`는 **9.10.6**이라 이 레코드 유형보다 오래된 버전인 듯함  
  Apple이 더 최신 `dig`를 제공해야 할 것 같은데, macOS에서 DNS 조회할 때 선호하는 도구가 있는지 궁금함
  - 여러 플랫폼에서 [doggo](https://github.com/mr-karan/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/commit/dece57c340aa3b8fda3d7bab68e5e5ddbcc10291  
    그리고 글이 장황함. 반복과 쓸모없는 내용, 이상한 시각화가 많아서 약 1700단어에 전체 너비 페이지 길이가 7300px를 넘음  
    **500단어**, 다이어그램 2개, 전체 길이 2000px 미만 정도로 줄이면 훨씬 나아질 듯함