Кратко

  • Happy Eyeballs сокращает видимую задержку перекрывающимися попытками; победитель подтверждает лишь собственную достижимость.
  • Время DNS, порядок кандидатов, запуск, ошибки и отмены нужно хранить отдельно по семействам.
  • Успех приложения и исправная работа IPv4 и IPv6 — разные операционные утверждения.

Рассмотрим один показательный случай: ответы AAAA и A получены, IPv6 стартует первым, затем IPv4 завершает соединение раньше, и страница открывается нормально. Пользователь не видит сбоя, как и панель, учитывающая только состоявшиеся сеансы. Однако IPv6 мог столкнуться с проблемой пути или сервиса либо быть отменённым до ответа. Установленное соединение не различает эти варианты.

RFC 8305 задаёт поведение гонки, из которого может возникнуть эта неоднозначность: A и AAAA разрешаются асинхронно, адреса сортируются по RFC 6724, семейства чередуются, а попытки запускаются с контролируемым сдвигом. После первого успеха остальные отменяются. По редакционной оценке этой статьи, механизм может защищать доступность, поскольку неисправный кандидат не заставляет пользователя ждать полный тайм-аут.

Но статус IPv6 «отменено» после победы IPv4 — не успех и не обязательно ошибка. Это наблюдение, оборванное гонкой. Победа IPv4 также не доказывает предпочтение IPv4: влияют порядок DNS, правила RFC 6724 и исторические RTT.

Часто упоминаемые 250 миллисекунд — не универсальная цель. RFC 8305 предлагает их как одно рекомендуемое значение задержки между попытками, допускает адаптацию и задаёт границы. Эта задержка отличается от ожидания разрешения, когда A приходит раньше AAAA. Полезная квитанция хранит реальные параметры и время, а не только отметку «включено».

Сам стандарт называет сокрытие операционных проблем ограничением. Гонку не следует отключать; нужно измерять проигравшие пути, не задерживая пользователя. Для эпизода следует сохранить сетевой контекст, путь DNS-резолвера, время A/AAAA, список кандидатов, семейство, настроенный Resolution Delay, настроенный или адаптированный Connection Attempt Delay, фактический сдвиг старта, этап рукопожатия, результат каждой попытки, результат приложения, причину отмены, победителя, а также сетевую область действия и срок жизни использованной истории соединений в кэше.

В качестве редакционной операционной рекомендации эти данные следует агрегировать лишь в течение ограниченного срока, чтобы уменьшить риски для приватности.

RFC 6555 появился как ответ на задержки из-за неисправного IPv6. RFC 8305 улучшил средство, но не превратил спасённый сеанс в сертификат проигравшего семейства. RFC 6724 задаёт политику выбора, а не результат проверки достижимости.