요약

  • RFC 6555는 듀얼스택 폴백을 주소 패밀리 사이의 짧은 경주로 규정했다. RFC 8305는 그 예시를 이름 확인, 목적지 정렬, 연결 시도에 대한 완전한 스케줄링 절차로 대체했다.
  • 권장되는 250ms의 연결 시도 지연은 단순한 성능 상수가 아니다. 이 값은 선호 경로, 폴백 경로, 병렬 작업이 만들어내는 추가 네트워크 부하 사이에 시간을 배분한다.
  • 경주 방식은 사용자를 느리거나 고장 난 초기 TCP/IP 경로로부터 보호하지만, 운영자에게는 고장을 가릴 수 있고 IPv4 의존을 유지하며 애플리케이션 계층의 실패는 그대로 둔다.

2012년 4월, RFC 6555는 새로운 와이어 프로토콜이 아니라 하나의 경험에 이름을 붙였다. 듀얼스택 호스트는 IPv6와 IPv4 목적지를 모두 받을 수 있고, 아키텍처가 의도한 대로 IPv6를 선호하면서도 그 선호 경로가 손상되었을 때는 사용자를 기다리게 만들 수 있었다. 이 RFC의 예시는 호스트의 주소 선호 순서를 유지한 채 첫 번째 연결을 시작하고, 짧은 간격 후에 다른 패밀리의 첫 주소로 연결을 시작했다. 당시 Firefox와 Chrome은 300밀리초를 사용하고 있었다. 어느 연결이 먼저 수립되든 그것을 유지하고 경쟁 연결은 폐기했다.

이 단순한 규칙은 불완전한 전환의 비용을 누가 부담하는지를 바꾸었다. 경주가 없다면, 사용자는 운영자의 고장 난 IPv6 경로 때문에 체감 지연을 치렀다. 경주가 있으면 클라이언트는 약간의 추가 작업을 들여 사용자를 그 실패로부터 보험처럼 보호한다. 따라서 이 메커니즘은 완벽하게 일치하지 않는 세 가지 이해를 하나로 묶었다. 사용자는 처음 사용 가능한 연결을 원하고, 표준 아키텍처는 IPv6 선호를 원하며, 네트워크는 무차별적인 시도 증가를 피하고자 했다.

RFC 6555는 폴백을 영구적인 IPv4 선호로 만드는 것을 명시적으로 거부했다. 유용한 이력이 없을 때는 IPv6가 여전히 선호되었고, 이미 길 것으로 예상되는 전환 기간 내내 불필요한 IPv4 부하를 강요하지 말라고 구현체에 경고했다. 300ms 예시는 보편적인 타임아웃이 아니라 하나의 절충안이었다. 너무 길면 메커니즘이 사용자를 보호하지 못하고, 너무 짧으면 거의 모든 일반 연결이 두 패밀리 간 경주가 되어 첫 경로가 성공했을 경우에도 소켓, 패킷, 서버 작업을 소모한다.

2017년 12월까지 배포와 측정은 이 메커니즘을 두 시도 사이의 하나의 타이머로 서술하는 데 한계가 있음을 드러냈다. RFC 8305는 RFC 6555를 폐기하고 네 단계가 연결된 스케줄러를 규정했다. 클라이언트는 비동기 DNS 쿼리를 보내고, 반환된 모든 목적지 주소를 정렬하고, 계단식 일정에 따라 비동기 연결 시도를 시작하고, 성공한 연결 하나를 유지한 뒤 나머지 작업을 취소한다.

DNS 단계에는 이미 경주가 들어 있다. RFC 8305는 AAAA를 먼저 요청하고 그 직후에 A 쿼리를 발행할 것을 권장하며, 쿼리를 직렬화하지 않는다. A가 먼저 도착하면 권장되는 50ms의 Resolution Delay가 AAAA에 짧게 도착할 기회를 준다. 이렇게 하면 빠른 IPv4 응답이 IPv6를 기계적으로 배제하는 일을 막으면서도, 누락되거나 지연된 응답을 오래 기다리는 일은 피한다. 설정이 진행되는 동안 응답이 바뀔 수도 있으므로, 스케줄러는 첫 응답을 최종으로 취급하지 않고 새로 학습된 목적지를 추가할 수 있어야 한다.

정렬은 다음 제어 지점이다. 목적지 주소 선택이 기본 순서를 제공하지만, 구현체는 과거 왕복 시간(RTT)이나 같은 네트워크에서 어떤 주소가 이전에 동작했다는 증거를 사용할 수 있다. 목록은 주소 패밀리 사이에서 인터리빙된다. 이 세부 사항이 중요하다. 한 패밀리에 사용 불가능한 주소가 여러 개 있더라도, 클라이언트가 다른 패밀리의 사용 가능한 주소를 시도하기 전에 그것들을 모두 소진하도록 강제되어서는 안 된다.

RFC 8305는 기본 Connection Attempt Delay로 250ms를 권장한다. 최소값으로는 100ms를 권장하고, 이 값은 절대 10ms 미만이 되어서는 안 되며, 최대값은 2초를 권장한다. First Address Family Count는 1이 권장된다. 이것들은 네트워크와 구현이 발전함에 따라 의도적으로 조정 가능한 경험적 공학 값이다. 이 값들은 두 가지 피해에 가격을 매긴다. 기다림의 인간 비용과 탐색적 작업의 시스템 비용이다. 지연을 낮추면 더 많은 중복 시도를 대가로 지연 시간을 줄인다. 지연을 높이면 부하는 줄지만, 선호 순서가 틀렸을 때 그것이 더 잘 드러난다.

결과적으로 만들어진 알고리즘은 하나의 IPv6 주소와 하나의 IPv4 주소 사이의 경쟁보다 넓다. 이것은 여러 목적지, 변하는 DNS 응답, 로컬 이력, NAT64/DNS64를 사용하는 IPv6-only 접속을 다룬다. 동시에 확실한 경계를 그린다. Happy Eyeballs는 초기 TCP/IP 연결 실패를 다룬다. 성공한 트랜스포트가 정상 동작하는 애플리케이션을 운반하게 만들지는 않으며, 이후의 애플리케이션 계층 거부나 프로토콜 실패를 치유할 수 없다.

따라서 그 운영상의 역설은 우연이 아니라 핵심이다. 사용자는 페이지가 열리는 것을 보고 네트워크가 정상 동작했다고 결론짓는다. 클라이언트는 선호 경로가 패배했다는 것을 알 수 있지만, 그 정보가 반드시 그 고장을 소유한 운영자에게 보이는 것은 아니다. RFC 6555는 이미 경주 방식이 주소 패밀리 실패의 진단을 더 어렵게 만든다는 것을 인식했고, RFC 8305는 경로-MTU 문제 같이 가려진 채 남을 수 있는 사례를 언급한다. 전체 신뢰성을 개선하는 메커니즘이 경주를 일으킨 구성 요소의 실패에 대한 가시성을 오히려 낮출 수 있다.

따라서 Happy Eyeballs는 호환성 거래로 이해되어야 한다. 이것은 사용자를 IPv6 선호의 강제적인 시험자로 만들지 않으면서 IPv6 선호를 보존하고, IPv4를 보험 자산으로 남겨 둔다. 그러나 보험은 인센티브를 바꾼다. 폴백이 충분히 빠르면 고장 난 IPv6 경로에서 불만이 줄어들 수 있고, IPv4가 항상 이기면 애플리케이션과 운영자는 희소한 IPv4 용량을 계속 유지할 이유를 갖게 된다. 스케줄러는 그 정치경제를 해결할 수 없다. 할 수 있는 것은 지연, 순서, 이력, 텔레메트리 안에서 그 거래를 명시적으로 드러내는 일뿐이다.