Кратко

  • RFC 9621–9623 позволяют приложению задать жёсткие требования и мягкие предпочтения, а реализация объединяет их с политикой системы, сохранённой историей и доступными сейчас кандидатами.
  • Ready означает, что допустимый стек установлен. Событие не раскрывает исключённые варианты, вклад кэша, проигравшие предпочтения, обработку на другой стороне или результат для пользователя.

RFC 9621 описывает архитектуру Transport Services, где приложение задаёт свойства нужной услуги, а не закрепляет один адрес, интерфейс и протокол. RFC 9622 определяет абстрактный API. RFC 9623 объясняет, как реализация собирает пути, стеки и варианты удалённой точки, строит ветви и запускает попытки.

Это позволяет внедрять новые транспорты и использовать несколько сетей без переписывания каждого приложения. Одновременно решение уходит под границу API. Для оператора стабильный вызов не означает стабильный выбор: меняются политика, история, сеть и набор доступных протоколов.

Пять уровней намерения

Для большинства Selection Properties RFC 9622 задаёт Require, Prefer, No Preference, Avoid и Prohibit. Require оставляет только кандидатов с нужным свойством, иначе установление завершается ошибкой. Prohibit исключает кандидатов с запрещённым свойством. Prefer и Avoid меняют порядок, но разрешают другой вариант.

Все требования и запреты обязательны. Мягкие предпочтения могут дать разные результаты в разных системах и условиях. Поэтому «предпочитать неметрированную сеть» не означает «никогда не платить за трафик». Если стоимость, приватность или режим безопасности являются границей, их нужно задать жёстко либо проверить отдельным результатом.

Нельзя подменять свойство названием интерфейса. Wi-Fi не гарантирует бесплатность, малую задержку или закрытый контур. Сотовая сеть не всегда дорога. RFC 9622 прямо предостерегает от такой подмены.

У одного кандидата три источника полномочий

RFC 9623 различает предпочтения приложения, динамическую System Policy и политику реализации по умолчанию. Администратор может запретить интерфейс, система — ограничить процесс, а реализация — заполнить то, что приложение не указало. Выбранный путь должен удовлетворять ограничениям всех уровней.

При этом RFC 9621 не стандартизирует переносимый способ чтения и записи System Policy: детали зависят от платформы. Намерение приложения переносимо, а объяснение решения — не обязательно.

Ошибка PolicyProhibited может показать, что действие запрещено. Успешный Ready не обязан содержать версию политики, список кандидатов и веса. Две корректные платформы способны выбрать разные стеки.

Выход не в единой глобальной политике. Нужны два контура: минимальный общий контракт для жёстких свойств и локальная квитанция, объясняющая конкретный выбор.

Сначала строится дерево, затем начинается гонка

RFC 9623 рекомендует ветвить сначала по сетевым путям, потом по протокольным вариантам и лишь затем по производным адресам назначения. Эта последовательность не только устраняет несовместимые комбинации, но и задаёт приоритет.

В примере приложение предпочитает Wi-Fi и SCTP. Если кэш считает SCTP недоступным через Wi-Fi, ветвь Wi-Fi содержит TCP, а ветвь LTE — SCTP и TCP. Поскольку путь стоит выше протокола, Wi-Fi/TCP может стартовать раньше LTE/SCTP.

Оба предпочтения учтены, но не сведены в единую нейтральную оценку. Решение зависит от структуры дерева. Запись одного победителя не отвечает, почему другой вариант был удалён или даже не запущен.

Кандидаты зависят и от сети. DNS через разные интерфейсы может вернуть разные ответы. Прокси меняет фактический адрес и порт. Протокол доступен на одном пути и отсутствует на другом. Список без времени и контекста не воспроизводит решение.

Быстрее — не значит выше политики

RFC 9623 описывает одновременную, ступенчатую гонку и переключение после отказа. Одновременный старт уменьшает ожидание, но расходует ресурсы и создаёт ненужное состояние; его не советуют использовать по умолчанию. Ступенчатый режим запускает следующий вариант после задержки. Failover ждёт отказа предпочтительного варианта.

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

RFC 8305 даёт модель Happy Eyeballs для семейств адресов. TAPS расширяет идею на пути и стеки. Первый успех имеет смысл лишь среди правильно допущенных вариантов.

RFC 8922 связывает параметры безопасности с транспортной услугой. RFC 9623 предупреждает: атакующий может блокировать первую попытку, вынуждая вторую. Если запасной вариант слабее, гонка становится каналом понижения защиты. Все участники должны сохранять жёсткие требования и признанную эквивалентность безопасности.

Кэш создаёт петлю обратной связи

Реализация может хранить DNS, состояние возобновления TLS, сведения TCP Fast Open, RTT, время установления и долю успехов. RFC 9040 даёт контекст совместного использования информации TCP. История способна поднять, отложить или удалить кандидата.

Экономия времени очевидна. Но старый отказ может продолжать наказывать уже исправленный путь. Частый победитель получает больше новых измерений и подтверждает собственное преимущество. Поэтому RFC 9621 требует явно задавать необходимые свойства, а не рассчитывать на неизменное поведение кэша.

Есть и риск связывания. Раздельные Connection Contexts могут изолировать TLS-состояние и мультиплексирование, чтобы разные действия не получили общий признак. Для аудита достаточно хранить область кэша, тип наблюдения, возраст и основание истечения — без билетов, ключей и идентификаторов пользователя.

Что именно закрывает Ready

RFC 9623 считает установление завершённым, когда хотя бы один стек способен передавать и принимать данные приложения. RFC 9622 сообщает переход событием Ready. Это точная локальная квитанция: допустимый стек готов и должен соблюдать жёсткие ограничения.

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

RFC 9623 называет Apple Network.framework, NEAT, NEATPy и PyTAPS реализациями, в разной степени следующими подходу. Документация Apple Network показывает практический API с протоколами и ограничениями пути. Это не сертификат полной совместимости и одинаковой наблюдаемости.

Источники