Кратко

  • RFC 6555 в 2012 году описал короткую гонку семейств адресов; RFC 8305 в 2017 году заменил её полноценным планировщиком DNS, сортировки назначений, отложенных попыток и отмены.
  • Рекомендуемые 250 мс распределяют стоимость между ожиданием пользователя и нагрузкой от спекулятивных соединений; уменьшение интервала не бывает бесплатным.
  • Механизм обходит начальный сбой TCP/IP, но не исправляет проигравший путь или приложение и способен продлить зависимость от дефицитного IPv4.

Happy Eyeballs появился из противоречия перехода на двойной стек. Узел получает назначения IPv6 и IPv4, по правилам предпочитает IPv6 и всё же заставляет пользователя ждать, если этот путь медленный или неисправный. Рабочий IPv4 уже известен, но стоит вторым. RFC 6555, опубликованный как Proposed Standard в апреле 2012 года, перенёс цену ожидания внутрь клиента.

Пример сохранял порядок предпочтений узла. Клиент запускал первое соединение, выдерживал короткий интервал и начинал попытку с первым адресом другого семейства. Firefox и Chrome тогда использовали 300 мс. Первое установленное соединение сохранялось, второе отбрасывалось. При отсутствии истории предпочтение оставалось за IPv6; спецификация одновременно предостерегала от ненужной нагрузки IPv4 в ходе долгого перехода.

Таймер тем самым распределял ресурс. Слишком большой интервал перекладывал сбой предпочтительного пути на пользователя. Слишком маленький превращал даже нормальные соединения в массовые гонки, расходуя пакеты, сокеты и работу серверов. Сокращение хвостовой задержки покупалось избыточной активностью.

Масштабное внедрение и измерения показали, что реальность не сводится к двум адресам и одному таймеру. RFC 8305 был опубликован как Proposed Standard в декабре 2017 года и отменил RFC 6555. Он связал четыре этапа: асинхронные DNS-запросы, сортировку всех найденных назначений, асинхронные попытки с временным разносом и сохранение одного успеха с отменой остальных.

Гонка начинается в DNS. RFC 8305 рекомендует сначала отправить AAAA, а сразу за ним A, не дожидаясь первой реакции. Если A приходит раньше, рекомендуемый Resolution Delay в 50 мс даёт AAAA короткое окно. Это не обязательное ожидание двух ответов и не безусловная победа самого быстрого DNS-ответа. Новые результаты могут пополнять список уже во время установки соединений.

Затем управляет порядок назначений. Базу задаёт выбор адреса назначения; реализация может учитывать исторический RTT или прошлое использование в той же сети. Семейства чередуются, чтобы несколько неработающих адресов одного типа не заняли всю очередь до попытки с пригодной альтернативой. История должна быть привязана к сети: победитель в одной среде не становится универсальным фаворитом.

RFC 8305 рекомендует Connection Attempt Delay по умолчанию 250 мс. Рекомендуемый минимум — 100 мс, значение никогда не должно быть ниже 10 мс, рекомендуемый максимум — две секунды. Для First Address Family Count рекомендуется единица. Это эмпирические и изменяемые параметры. Меньший интервал снижает видимую задержку отказа, но увеличивает параллельную работу; больший бережёт сеть, но дольше показывает пользователю ошибочный приоритет.

Планировщик охватывает множество адресов, меняющиеся в ходе установки DNS-ответы, исторические данные и сети IPv6-only с NAT64/DNS64. Граница остаётся жёсткой: речь идёт о начальном соединении TCP/IP. Успех транспорта не гарантирует исправность приложения, а проигранный путь от самой гонки лучше не становится.

Отсюда возникает дефицит наблюдаемости. Ещё RFC 6555 признавал, что гонка усложняет диагностику по семействам адресов. RFC 8305 сохраняет предупреждение: операционные неполадки, включая проблемы Path MTU, могут скрываться за удачным альтернативным путём. Пользователь получает сервис, а оператор, ответственный за сбой, может не получить жалобу, которая запустила бы расследование.

Happy Eyeballs — контракт совместимости. Клиент тратит немного лишней работы, чтобы совместить предпочтение IPv6 с приемлемым опытом. IPv4 остаётся страховкой вместе с дефицитными адресами и затратами. Хорошая страховка меняет стимулы: быстрый fallback снижает давление на ремонт IPv6 и закрепляет причины сохранять IPv4. Алгоритм управляет каждой попыткой, но не способен назначить конец перехода.