Кратко

  • В проекте QUIC multipath редакции 21 нет отдельного тайм-аута бездействия для каждого пути: соединение может оставаться живым на одном пути, пока состояние неиспользуемого пути в сети устаревает.
  • Прежняя валидация подтверждает достижимость в тот момент, но не гарантирует актуальность NAT, межсетевого экрана, PMTU, пропускной способности или разрешения на использование.
  • Готовность резерва должна подтверждаться свежей пробой и полным результатом приложения, а не наличием Path ID или временем работы соединения.

Резерв существовал во всех отчётах. Его Path ID не был отозван, состояние соединения оставалось активным, а последняя проверка когда-то завершилась успешно. Когда основной доступ пропал, первые пакеты резерва ушли в пустоту. Устройство повторило попытку, приложение пропустило срок, и только затем система начала заново выяснять, существует ли путь.

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

Редакция 21 документа «Managing multiple paths for a QUIC connection» была одобрена IESG 18 марта 2026 года и 19 марта поступила в очередь RFC Editor. На 2 октября она ожидала второго редактора. Документ ещё не является RFC. Его процессный статус не следует ускорять словами, как не следует продлевать срок действия старой сетевой пробы предположением.

Проект задаёт переговоры о multipath, Path ID, отдельные пространства номеров пакетов, привязку connection IDs, валидацию, PATH_ACK, статусы AVAILABLE и BACKUP, отказ от пути, а также состояние восстановления и перегрузки по путям. Клиент инициирует путь, сервер его валидирует.

Однако для путей нет независимых idle timeout. Бездействующий путь не закрывает всё соединение, пока другой путь продолжает работать. Это сохраняет полезную связь, но означает, что общий индикатор uptime не обновляет знания о NAT, фильтрах и доступности каждого резерва.

Валидация имеет дату

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

Если панель хранит только логическое значение validated=true, она стирает главное — когда и при каких адресах это было верно. Для решения о переключении нужны возраст пробы, текущий 4-tuple, connection ID, направление проверки и свежий ответ.

Несколько Path ID могут использовать один и тот же 4-tuple. Поэтому число записей не доказывает число независимых резервов. И наоборот, разные четвёрки адресов и портов могут сходиться в одном физическом узком месте. Отказоустойчивость требует сведений о домене отказа, а не только о протокольной идентичности.

AVAILABLE не обещает готовность через час

Статус AVAILABLE предлагает партнёру распределять трафик по собственной логике. BACKUP просит не использовать путь, пока существует другой пригодный. Конечная точка может не последовать предпочтению. Если все пути BACKUP, проект не устанавливает общий порядок выбора.

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

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

Переключение заканчивается не первым ACK

PATH_ACK может вернуться по пути, отличному от пути подтверждаемого пакета. Наблюдаемое RTT тогда объединяет прямой маршрут, обратный маршрут ACK и решение планировщика. Быстрый ответ не всегда доказывает, что резервный путь сам по себе быстр.

Подробная политика повторной передачи также остаётся вне общего текста. Данные можно отправить повторно по тому же, другому или нескольким путям. PMTU у путей может различаться даже при одинаковом 4-tuple, поэтому смена пути способна изменить разбиение данных.

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

Паспорт готовности резерва

Перед тем как обещать failover, полезно собирать отдельный паспорт каждого пути:

  1. Path ID, connection ID и текущий 4-tuple;
  2. время, направление и результат последней валидации;
  3. статус AVAILABLE/BACKUP обеих сторон;
  4. сведения о NAT, фильтрах и ожидаемом сроке их состояния;
  5. потерю, перегрузку, PMTU и маршрут PATH_ACK;
  6. доказательства общего или независимого домена отказа;
  7. версию планировщика и причину выбора;
  8. ограничения цены, квоты, безопасности и согласия;
  9. решение о повторной передаче и переупорядочивание;
  10. время готовности непрерывного диапазона stream;
  11. результат приложения и доступный откат.

Такой паспорт не делает путь бессмертным. Он делает утверждение о готовности ограниченным по времени и проверяемым. После истечения окна свежести система может провести пробу, понизить доверие или признать, что резерв неизвестен.

История рассмотрения IESG показывает внимание к политике планировщика, числу путей, квотам и согласию. Одобрение проекта не подтверждает интервал keepalive конкретного продукта и не сертифицирует его аварийный сценарий. Общий протокол предоставляет сигналы; оператор определяет, насколько свежими они должны быть для обещанного сервиса.

Корректный отчёт звучит так: соединение было активно по пути A; путь B был подтверждён тогда-то, затем проверен такими пакетами; политика версии X признала его пригодным; переключение привело к такому результату приложения. Фраза «соединение имело два живых пути» требует гораздо больше, чем два Path ID на экране.

Источники