Кратко

  • Записи A и AAAA дают адреса-кандидаты, но не доказывают доступность соответствующего пути для данного клиента в данный момент.
  • RFC 6555 превратил предпочтение IPv6 в ограниченную фору; RFC 8305 уточнил процедуру через асинхронные запросы DNS, сортировку RFC 6724, чередование семейств и перекрывающиеся попытки с паузами.
  • Первый завершённый сеанс выигрывает только этот выбор. Незаметный резерв повышает удобство, но способен скрыть от оператора семейство, которое систематически не работает.

Адрес существовал, а прохода не было

RFC 1671 сформулировал проблему ещё в 1994 году. DNS мог вернуть IPv4 и IPv6, не зная, что промежуточный маршрутизатор отбрасывает новый протокол, туннель сломан, пиринг недоступен или служба на AAAA-адресе временно молчит.

Запись не обязательно была ложной. Она называла кандидата, но не содержала наблюдения с конкретной точки сети. Последовательное приложение превращало эту недостающую часть в задержку: отправляло IPv6 SYN, ждало повторных передач и только потом пробовало исправный IPv4. Более новый двухстековый клиент казался хуже старого. Отключение IPv6 убирало симптом, а переход сам создавал стимул отказаться от перехода.

Отдельный IPv6-hostname расколол бы общее имя. Ручные белые списки не отслеживали бы временные поломки каждого пути. Недостающее свидетельство следовало получать во время реального соединения.

Приоритет стал форой, а не правом вето

RFC 6555 стандартизировал Happy Eyeballs в 2012 году. Он не уравнял IPv4 и IPv6 в слепом одновременном старте. Политика выбора адресов сохранялась и обычно ставила IPv6 первым. Однако, если предпочтительная попытка не завершалась быстро, клиент начинал вторую через другое семейство, не обязательно прекращая первую.

Политика выбирает первый опыт; наблюдаемая работа выбирает канал этой сессии. Предпочтение больше не получает монополию на ожидание пользователя.

Параллельность расходует состояние сервера, межсетевого экрана и NAT, а также порты и трафик. Поэтому попытки нужно разносить во времени, а проигравшие — закрывать. Совершенно нейтральная гонка поддерживала бы лишнюю нагрузку на общий IPv4; абсолютное правило IPv6 перекладывало бы чужую неисправность на пользователя.

Память о провале тоже временна. Клиент может учитывать неработавшее семейство, но обязан периодически вновь проверять предпочтительное; RFC 6555 указывает порядок десяти минут. При подключении к другой сети состояние сбрасывается. Поломка в гостинице не описывает домашнюю сеть.

Вторая версия начала гонку с DNS

RFC 8305 заменил первоначальное описание в 2017 году. Алгоритм разделён на асинхронный запуск DNS-запросов, сортировку адресов, асинхронные подключения и сохранение одного соединения с отменой остальных.

AAAA и A отправляются почти подряд, сначала AAAA. Если A приходит раньше, клиент ненадолго ждёт IPv6-ответ; рекомендуемая задержка разрешения равна 50 миллисекундам. Так IPv6 получает небольшую фору, а уже известный IPv4 не блокируется надолго из-за позднего DNS.

Доступные адреса сначала сортируются по RFC 6724. Подходящий адрес источника, область действия, метки и политика узла формируют порядок, но первая позиция остаётся рекомендацией, а не сертификатом доступности.

Затем семейства чередуются. Если список начинается с IPv6, лучший IPv4-кандидат обычно поднимается на второе место. Несколько неработающих AAAA не должны исчерпать несколько таймеров до первой попытки A.

Подключения запускаются по одному, но остаются одновременно в работе. RFC 8305 рекомендует стандартный интервал 250 миллисекунд, запрещает менее 10 миллисекунд, предлагает 100 миллисекунд как минимум и две секунды как максимум. Это настраиваемые эмпирические величины, которым разрешено меняться вместе с сетью.

История RTT или ранее использованный адрес могут уточнять очередь. Такие сведения нельзя переносить между сетевыми интерфейсами, а при смене сети их следует удалять. Когда одно соединение устанавливается, остальные отменяются. Поздние ответы DNS ещё могут заполнить кэш, но не пересматривают уже принятый выбор.

Победа в начале не подтверждает остальное

Happy Eyeballs проверяет начальное транспортное соединение. Успешный TCP handshake не гарантирует TLS, исправность HTTP или прохождение крупных пакетов. RFC 8305 отдельно отмечает, что проблема Path MTU может проявиться после установления связи.

Победивший IP-адрес не удостоверяет личность службы. DNS меняется, и последовательные обращения к одному имени могут выбрать разные адреса. Идентичность должна проверять тот уровень, который знает ожидаемую сторону.

Операционный парадокс состоит в том, что успешный резерв прячет неисправность. Если IPv6 постоянно молчит, а IPv4 подхватывает через четверть секунды, пользователь почти ничего не замечает. Клиент восстановил опыт, но не сеть. Поэтому RFC 8305 рекомендует независимый контроль каждого семейства.

Источники и границы

Закрытый набор включает RFC 1671, RFC 6555, RFC 6724 и RFC 8305. Он не устанавливает нынешнюю долю реализаций, универсально лучший интервал или глобальное превосходство одного семейства.