Кратко

  • Накопительное ACK доказывает, что граница принятых байтов продвинулась, но после повторной отправки того же диапазона не указывает доставивший его экземпляр.
  • Karn запрещает брать из такого эпизода выборку RTT; экспоненциальный откат сохраняет консервативный RTO до новой передачи с однозначной историей.
  • TCP Timestamps может различить экземпляры в ограниченных условиях, но не делает каждый отклик пригодным для оценки и не доказывает завершение работы приложения.

Один ответ и два возможных старта

Отправитель передаёт байты с 12000 по 12999 и включает таймер. Подтверждение не приходит до истечения RTO, поэтому те же номера уходят снова. Затем ACK объявляет следующим ожидаемым байтом 13000.

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

Все три отметки времени могут быть точными. Неизвестна причинная пара: какой старт относится к возвращению? Накопительное ACK описывает положение в потоке байтов, а не личность физического датаграммного экземпляра.

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

Адаптивному таймеру потребовался контроль входа

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

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

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

RFC 1122 назвал расчёт RFC 793 недостаточным и потребовал алгоритмы Jacobson и Karn. Первый учитывает вариацию RTT. Второй решает, допустима ли сама выборка. Хорошая формула не исправляет неизвестное происхождение входа.

Karn сделал незнание исполнимым состоянием

Правило узкое: не брать RTT у повторно переданного сегмента. Когда один диапазон имеет несколько экземпляров, обычное ACK их не различает. Выбор удобной временной отметки не восстанавливает отсутствующий идентификатор.

TCP при этом не отбрасывает подтверждение. Состояние приёма продвигается, байты освобождаются из очереди, следующие данные могут отправляться. Запрещено лишь менять SRTT и RTTVAR на основании эпизода так, будто его причина установлена.

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

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

Откат сохранил неопределённость в поведении

RFC 1122 также обязал использовать экспоненциальный откат для последовательных RTO. RFC 2988, а затем сменивший его RFC 6298 кодифицировали SRTT, RTTVAR и RTO. При истечении таймера повторяется самый ранний неподтверждённый сегмент, а RTO удваивается.

Откат уменьшает давление на путь, который не дал обратной связи вовремя. Вместе с Karn он несёт более точный смысл: неоднозначное подтверждение не может немедленно обрушить увеличенный таймер до оптимистичного значения.

RTO возвращается к обычному расчёту после новой допустимой выборки. Как правило, нужны новые данные, отправленные и подтверждённые без повтора. Оценку очищает не пауза сама по себе, а новая пара событий с известным началом.

RFC 6298 разрешает более консервативную реализацию, но запрещает более агрессивную. Долгое ожидание задерживает одну связь. Слишком ранний повтор добавляет копии на общий путь именно тогда, когда отсутствие ответа требует осторожности.

Документ 2011 года также снизил общий начальный RTO с трёх секунд до одной, сохранив особое возвращение к трём секундам после потери SYN или его ACK. Числовые параметры меняются с данными; запрет выдумывать причинную пару не зависит от конкретной секунды.

ACK ведёт счёт байтам, а не биографиям пакетов

Неоднозначность следует из абстракции TCP. Номера последовательности обозначают места в потоке октетов. Повтор может покрыть те же номера с иными границами сегментов. Получатель может задержать ACK, объединить несколько поступлений и удалить дубликаты.

Накопительное подтверждение называет следующий ожидаемый байт. Оно не возвращает неизменный ID каждого виденного датаграммного объекта. Полный журнал причин у получателя увеличил бы состояние и общий контракт.

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

Эту границу легко потерять в трассировке. ACK, показанное сразу после повтора, могло быть вызвано задержавшимся оригиналом. Временная близость предлагает гипотезу, но не является доказательством протокола. Без правильно согласованной дополнительной метки остаются несколько историй.

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

Timestamp добавил ограниченную метку экземпляра

RFC 6298 допускает исключение, если TCP Timestamp устраняет неоднозначность экземпляра. RFC 7323 описывает TSval в отправляемых сегментах и TSecr в возвращаемом трафике.

Когда ACK возвращает значение принятого экземпляра, отправитель может связать отклик с конкретной отметкой своей передачи. Недостающая идентичность появляется благодаря опции, а не расширению смысла накопительного номера.

Само присутствие Timestamp ещё не разрешает любое вычитание. RFC 7323 отделяет перенос значения от использования для RTO. Обновление среднего должно сопровождать продвижение левого края окна. Задержанные ACK, дыры, переупорядочение и выбор TSval для эха влияют на допустимость.

Избыток выборок требует отдельной политики. Коэффициенты RFC 6298 предполагали примерно одно измерение за RTT. Обновление на каждом пакете с теми же весами может слишком быстро забыть историю пути и увеличить ложные повторы при изменениях на масштабе нескольких оборотов.

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

Современный TCP сохранил отрицательное требование

RFC 9293, нынешняя базовая спецификация TCP, продолжает требовать расчёт по RFC 6298, включая Karn. Экспоненциальный откат остаётся частью основного поведения ради устойчивости.

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

Современные механизмы могут добавить сигналы и сократить время без измерений. Они не превращают по-прежнему неизвестный старт в истинный RTT. Желание интерфейса показать свежее число не служит доказательством его существования.

Структура стандартов также сохраняет границы. Базовый TCP отсылает расчёт таймера специальному RFC. RTO взаимодействует с управлением перегрузкой, но не является окном перегрузки. Timestamp добавляет происхождение экземпляра, не присваивая вывод приложения.

Пробел может быть самым честным измерением

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

Karn оставляет более точное состояние: в этом эпизоде обычный RTT неизмерим. Пробел сообщает качество доказательства. Заполнив его числом, оператор уничтожает сведения о двух возможных причинах.

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

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

Источники и пределы доказательства

RFC 793 даёт ранний адаптивный таймер. RFC 1122 фиксирует недостаточность и требует Karn, Jacobson и откат. RFC 2988 и RFC 6298 кодифицируют RTO и исключение выборок. RFC 7323 ограничивает устранение неоднозначности через Timestamp. RFC 9293 сохраняет правило в современном TCP.

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