IPv6 주소가 있지만 해당 경로가 느려 HTTPS 접속이 지연됩니다. Happy Eyeballs는 무엇을 병렬화하나요?

IPv6와 IPv4 같은 후보 연결을 적절한 지연을 두고 경쟁시켜 한 경로의 긴 실패 대기가 전체 연결을 막는 일을 줄입니다. 주소를 무조건 하나씩 끝까지 기다리는 방식과 다릅니다.

동작 원리와 전제

DNS 응답과 주소 정렬, 연결 시도 간격, 성공한 후보 선택을 클라이언트 구현에 맞춰 확인합니다. 모든 주소에 동시에 무제한 연결하면 자원·서버 부하가 커질 수 있어 제한된 경쟁이 필요합니다. 승자 선택 뒤 남은 소켓도 정리해야 합니다.

선택과 실패 처리

TCP 연결 성공과 TLS 인증서·애플리케이션 준비 완료는 다른 단계입니다. 실패 후보가 남은 작업을 누수시키지 않게 하고, 경로 선호를 영구 고정해 네트워크 변화에 적응하지 못하는지도 봅니다.

구체적인 사례와 검증

후보 연결 중 먼저 TCP 연결이 성공해도 TLS 검증에서 실패할 수 있으므로 라이브러리의 승자 확정 시점과 fallback을 확인해야 합니다. 느린 후보를 취소한 뒤 소켓·타이머가 실제 정리되는지도 봅니다. 연결 경쟁이 요청 body의 중복 전송으로 이어지지 않도록 전송 단계와 분리합니다. 인증 실패를 단순 경로 지연으로 보고 다른 서버에서 무조건 우회하는 정책은 별도 보안 검토가 필요합니다. 브라우저·OS·HTTP 클라이언트가 이미 구현한 기능을 앱에서 중복 추가하면 과도한 연결 시도를 만들 수 있으므로 기존 스택의 동작을 먼저 관찰하겠습니다.

IPv6 blackhole·느린 DNS·빠른 IPv4·네트워크 이동을 시험해 연결 p99와 소켓 생성량을 측정합니다. 한 경로를 꺼서 증상을 가릴 수 있어도 원인과 사용자 네트워크 다양성을 확인합니다. 병렬 연결은 초기 경로 선택 문제의 해법이지 서버 처리 지연의 해법은 아닙니다.