Кратко

  • ACK Delay описывает намеренное ожидание между приёмом самого большого подтверждённого пакета и отправкой ACK.
  • latest_rtt сначала формируется по локальному наблюдению, до вычитания ACK Delay.
  • Для корректной трактовки нужны ack_delay_exponent, фаза handshake, max_ack_delay и нижняя граница min_rtt.

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

Объём поля ограничен. Получатель сообщает интервал от приёма пакета с наибольшим подтверждённым номером до отправки ACK. Это не отдельная задержка для каждого пакета из ACK ranges и не утверждение о том, что все они ожидали одинаково. Время, которым конечная точка не управляет, например ожидание пакета в пути операционной системы до обработки QUIC, не следует автоматически включать в ACK Delay. Ожидание из-за недоступности ключей учитывается по правилам протокола, но не превращает поле в универсальный таймер хоста или приложения.

Отправитель сначала получает latest_rtt как разницу между локальным временем отправки самого большого нового подтверждённого пакета, вызвавшего ACK, и локальным временем получения ACK. Сырая выборка сохраняет весь наблюдавшийся интервал подтверждения. ACK Delay используется позднее при расчёте smoothed_rtt и rttvar. Закодированное значение нельзя использовать без ack_delay_exponent и соответствующих транспортных параметров. Экспонента по умолчанию равна 3; max_ack_delay задаётся в миллисекундах, а значение по умолчанию равно 25 ms. Однако значения по умолчанию не заменяют контекст конкретного соединения.

min_rtt рассчитывается только по локальным наблюдениям и не уменьшается из-за ACK Delay, сообщённого другой стороной. Это нижняя граница, защищающая от чрезмерного занижения при ошибочном отчёте, но не измерение чистой сетевой или однонаправленной задержки. После подтверждения handshake отправитель использует меньшее из декодированного ACK Delay и max_ack_delay другой стороны и не должен опускать скорректированную выборку ниже min_rtt. До подтверждения max_ack_delay не применяется как предел: более длинное ожидание может быть связано, например, с доступностью ключей.

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

Оператору нужен журнал, а не одно число: идентификаторы соединения и пути, пространство номеров, самый большой новый подтверждённый пакет и время отправки, получение и обработка ACK, сырой latest_rtt, исходное и декодированное ACK Delay, ack_delay_exponent, max_ack_delay другой стороны, состояние handshake, min_rtt, применённые предел и нижняя граница, скорректированная выборка, smoothed_rtt, rttvar и PTO. Отдельно храните ACK ranges, доступность ключей, локальную обработку, свидетельства потери ACK и прикладные сроки.