Summary

  • Patrick Sattler의 RIPE 92 시험에서 대상 Chrome과 Firefox는 DNS A와 AAAA 응답을 모두 기다렸다. A가 늦으면 쓸 수 있는 IPv6 주소가 이미 도착해도 페이지가 늦어졌고, Firefox는 일부 조건에서 실패했다.
  • 연구팀이 시험한 브라우저 가운데 Safari만 DNS 해석 대기 시간을 포함한 Happy Eyeballs v2의 기능을 모두 구현했다. 다른 대상 클라이언트에서는 리졸버의 시간 제한이 이용자의 대기 시간을 좌우할 수 있다.

웹 서버는 IPv6로 받을 준비가 됐다. 브라우저는 그 주소도 받았다. 그런데 화면은 열리지 않는다. Patrick Sattler는 RIPE 92에서 브라우저가 IPv4용 A 레코드까지 기다릴 때 생기는 이 시간을 보여 줬다. 경로의 장애보다 선택 절차의 지연이 앞에 서 있었다.

Happy Eyeballs는 IPv6를 먼저 시도하고 늦으면 IPv4를 뒤따르게 한다. 연결 경주 이전에는 DNS가 주소를 건네야 한다. Sattler의 팀은 A와 AAAA 응답을 각각 늦출 수 있는 이름 서버와 웹 시험 도구를 만들고 브라우저를 외부에서 관찰했다. 공식 발표 페이지도 이 구현 차이를 기록한다.

2026년 5월의 시험 환경에서 Chrome과 Firefox는 A와 AAAA를 모두 물었고 두 답을 기다렸다. 시험한 버전에는 v2의 DNS 해석 대기 한도가 없었다. A 응답이 지체되면 페이지도 멈췄으며, Firefox는 AAAA가 이미 돌아온 경우에도 일부 시험에서 오류가 났다. Safari는 AAAA가 곧바로 도착하고 A가 늦을 때 IPv6로 진행했다. AAAA가 늦는 경우 보여 준 시험에서는 약 50밀리초를 기다린 뒤 IPv4로 넘어갔다.

연결 시도 자체에는 별도의 시계가 있다. Sattler가 측정한 Chrome은 약 300밀리초, Firefox는 약 250밀리초를 기준으로 주소 계열을 바꿨고 Safari는 동적으로 조정했다. 운영체제, 프록시, 네트워크 조건도 결과를 바꾼다. 공개 시험 서버는 당시 뮌헨에만 있었고 그는 다른 지역의 측정 지점을 원했다. 오늘의 모든 버전을 그때 숫자로 판단할 수는 없다.

책임도 세 곳에 나뉜다. 사이트는 IPv6 서비스를 운영한다. 브라우저는 받은 주소를 언제 쓸지 정한다. 리졸버는 오지 않은 A 답을 얼마 동안 기다릴지 정한다. Sattler는 DNS 운영자에게 시간 제한을 점검하라고 했다. 클라이언트 개발자는 정상 AAAA가 쓸데없는 줄을 서지 않게 할 권한을 갖고 있다.

느린 페이지를 설명하려면 A와 AAAA의 응답 시간, 브라우저 버전, 리졸버, 프록시, 첫 연결 시도를 따로 기록해야 한다. IPv6 핑이 성공했다는 보고만으로는 움직이지 않는 탭을 고칠 수 없다. Sattler는 잃어버린 시간을 DNS와 클라이언트 사이에서 찾았다.

자료: RIPE 92 공식 속기록 · 공식 발표 페이지 · RACI 인물 소개.