Кратко

  • RACK признаёт более раннюю передачу потерянной лишь тогда, когда подтверждена доставка отправленного позже сегмента, а ранний остаётся без ACK дольше оценки RTT плюс ограниченного окна переупорядочения.
  • TLP отправляет до RTO не более одного пробного сегмента, чтобы вызвать новую обратную связь. Проба не доказывает потерю: RACK обнаруживает её, а право передавать данные восстановления остаётся у перегрузочного управления.

Случай, где не из чего собрать три ACK

Классическая быстрая повторная передача рассматривает три дубликата ACK как свидетельство раннего пробела. Правило хорошо работает, когда после пробела идёт достаточно пакетов и каждый заставляет получателя ответить. Короткий веб-ответ, ограниченный приложением поток или потеря в самом конце окна может не дать третьего свидетеля. Тогда отправитель ждёт тайм-аут повторной передачи — намеренно осторожный механизм последней надежды.

Выборочное подтверждение добавило подробностей. RFC 2018 позволяет получателю сообщить о диапазонах байтов, доставленных за границей накопительного ACK. RFC 6675 использует эту таблицу SACK для восстановления, но его основная граница потери по-прежнему выражена числом разрозненных последовательностей или байтов выше пробела. Переупорядочение, дублирование и объединение ACK меняют этот счёт. Количество в пространстве последовательностей ничего не говорит о том, как долго спорная передача находится в пути.

Recent ACKnowledgment, или RACK, переносит рассуждение во временную область. RFC 8985 совместно написали Yuchung Cheng, Neal Cardwell, Nandita Dukkipati и Priyaranjan Jha; документ вышел в Standards Track IETF в феврале 2021 года. Официальные профили Cardwell в IETF и Google Research подтверждают его личность, работу в сетевой области и связь с RFC. Они не превращают коллективный стандарт в единоличное изобретение и не доказывают нынешний контроль над каждой реализацией.

Поздняя доставка лишь открывает дело

RACK хранит время самой свежей передачи каждого неподтверждённого сегмента, в том числе после ретрансляции. Если ACK или SACK доказывает доставку данных, отправленных позже всё ещё ожидающего сегмента S, появляется первая предпосылка: путь доставил то, что покинуло отправителя после S.

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

Точность времени становится функциональным требованием. RFC 8985 требует хранить момент последней передачи с дискретностью меньше четверти минимального RTT. Документ оценивает добавочное состояние в четыре или восемь октетов на сегмент в зависимости от представления времени. Это контекстная оценка, а не универсальный расход памяти.

Сам ACK доказывает только получение определённого диапазона TCP. Он не называет причину отсутствия S, не указывает место перегрузки, не удостоверяет путь или сторону и не говорит, обработало ли данные приложение. Радиопотеря, допустимое переупорядочение, смена маршрута и перегрузка могут выглядеть сходно. RACK формирует полезный для транспорта вывод, а не полную причинную картину.

Беспорядок получает ограниченный запас времени

Пакеты могут прийти не по порядку и при этом не потеряться. Поэтому RACK добавляет к порогу RTT окно переупорядочения. При описанных в RFC условиях оно начинается с нуля или небольшой доли минимального RTT. Если Duplicate SACK показывает, что повторная передача была лишней, отправитель получает свидетельство более глубокого переупорядочения и может расширить допуск. Рекомендована адаптация по DSACK, а сглаженный RTT служит верхней границей.

Узкое окно быстро исправляет настоящую потерю, но чаще дублирует всего лишь запоздавший оригинал. Широкое окно терпимее к перестановкам, однако позже ремонтирует реальный пробел. «Основанный на времени» не значит «безошибочный»: неопределённость превращается в явный, измеримый и ограниченный период ожидания.

Проверяемая запись решения должна включать последний момент отправки подозрительного сегмента, время отправки доставленного позднего сегмента, решающий ACK или SACK, оценку RTT, действующее окно и DSACK, который его изменил. Суммарный счётчик RACK сохраняет приговор, но выбрасывает основания.

Один вопрос в молчаливом хвосте

Tail Loss Probe предназначен для места, где заканчиваются последующие данные и иссякает ACK-тактирование. Время пробы обычно строится вокруг двух сглаженных RTT с учётом правил RFC 8985 для отложенного ACK и близости RTO. TLP требует свежего измерения RTT и не допускает более одной незавершённой пробы.

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

Сам факт пробы не доказывает потерю оригинала. Ответ может дать RACK нужное свидетельство более поздней доставки или показать, что исходные данные дошли, а молчал только канал ACK. Если теряется и проба, RTO остаётся последней защитой. TLP создаёт наблюдение; RACK решает, что оно означает.

Обнаружение не выдаёт разрешение на передачу

Даже после вердикта RACK сегмент нельзя повторять когда угодно. RFC 8985 прямо требует дождаться разрешения алгоритма перегрузочного управления. RFC 5681 задаёт классические обязательства, а RFC 6937 рекомендует Proportional Rate Reduction для дозирования трафика во время восстановления.

Разделение не позволяет быстрому датчику стать агрессивным исполнительным механизмом. RACK говорит, что доказательств хватает для транспортной классификации; контроллер решает, сколько исправляющего трафика выдержит сеть. Даже выход одной TLP-пробы за полное окно — узкое, явно описанное и учитываемое исключение.

RTO из RFC 6298 тоже никуда не исчезает. Он обеспечивает прогресс, когда точные сигналы не складываются в вывод, и применяет осторожный откат. SACK описывает доставленные интервалы, RACK оценивает потери во времени, TLP запрашивает отклик в хвосте, перегрузочное управление ограничивает восстановление, а RTO страхует оставшееся молчание.

Чего не удостоверяет точная отметка времени

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

Раздел безопасности RFC 8985 наследует известные вопросы SACK и отмечает узкое преимущество против ACK splitting: подтверждение ещё одного байта не продвигает отметку последней доставленной передачи, которой пользуется RACK. Это снижает эффективность одной тактики, но не аутентифицирует обратную связь и не гарантирует честность ACK вообще.

RFC 9002 применяет временные пороги к обнаружению потерь QUIC и упоминает RACK-TLP среди идей-предшественников. Но у QUIC собственные пространства номеров пакетов, правила ACK и интерфейс с перегрузочным управлением. Родство замыслов не означает тождества состояния, констант и полномочий.

Исторические числа должны остаться историческими

В работе 2013 года «Reducing Web Latency: the Virtue of Gentle Aggression», среди авторов которой был Cardwell, изучалась выборка трафика фронтендов Google. В этом ограниченном окружении 77 процентов наблюдавшихся потерь исправлялись через RTO, а не Fast Recovery. Испытанная комбинация механизмов снизила среднюю задержку на 23 процента, а задержку 99-го процентиля — на 47 процентов.

Эти результаты объясняют исторический интерес к хвостам коротких транзакций. Они не описывают современный интернет, текущую эксплуатацию Google или гарантированный эффект RFC 8985. Устойчивый вывод скромнее: в коротком потоке пакеты, способные породить доказательства, заканчиваются раньше времени ожидания.

Источники