Кратко

  • Алгоритм Eifel из RFC 3522 сохраняет временную метку первой повторной передачи, начавшей восстановление, и проверяет первый допустимый ACK. Более раннее эхо доказывает, что подтверждение было вызвано исходной передачей и восстановление не требовалось.
  • Этот вывод сам по себе не возвращает cwnd, ssthresh, RTO или качество приложения. Надёжная квитанция отдельно фиксирует триггер, доказательство, выходы из-за неоднозначности, прежнее состояние, ответное действие и наблюдаемый результат.

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

RFC 3522 опубликован в апреле 2003 года со статусом Experimental, а не Internet Standard. Он решает задачу retransmission ambiguity с помощью TCP Timestamps. Номер ACK показывает подтверждённый диапазон байтов, но не говорит, исходный сегмент или его копия вызвали подтверждение. Эхо метки различает эти истории.

Название документа точно задаёт границу: это алгоритм обнаружения. На шаге (RESP) предписано ничего не делать. Изменить мнение о событии и изменить работающую систему — два самостоятельных полномочия.

Первый допустимый ACK свидетельствует постфактум

В начале эпизода отправитель сбрасывает SpuriousRecovery в false и записывает в RetransmitTS Timestamp Value той timeout retransmit или fast retransmit, которая начала восстановление. Последующие копии не должны затирать этот якорь.

Затем нужен первый допустимый ACK, подтверждающий прежде неподтверждённые данные. Если его Timestamp Echo Reply строго меньше RetransmitTS, эхо относится к исходной передаче, сделанной раньше копии. После дополнительных консервативных проверок восстановление можно признать ложным.

Слово «первый» влияет на ущерб. После ложного тайм-аута запоздавшие подтверждения оригиналов способны запустить цепочку go-back-N. Раннее обнаружение позволяет остановить часть лишних копий, пока процесс ещё продолжается.

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

Одинаковый след не означает одинаковую причину

Внезапный рост задержки позволяет RTO истечь до прихода ACK. Перестановка пакетов создаёт достаточно дубликатов ACK для fast retransmit. Дублирование данных или самих подтверждений может дать тот же внешний рисунок.

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

Различаются и последствия. Ложная fast retransmit обычно создаёт одну ненужную копию и делит окно пополам. Ложный timeout может включить slow start и вызвать дополнительные передачи, когда начнут прибывать задержанные ACK оригиналов.

RFC также выделяет fast timeout. Если сегмент действительно потерян, но таймер лишь опередил путь дублированных ACK, восстановление оправдано. Победа одного триггера в гонке не превращает реальную потерю в ложную.

Равенство не даёт положительного вывода

Базовый алгоритм проверяет строгое «меньше», а не «меньше либо равно». При грубых часах или коротком интервале оригинал и копия могут получить одинаковую метку. Тогда RFC консервативно не объявляет восстановление ложным.

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

В квитанции нужны обе исходные величины, разрешение часов, операция сравнения и выбранная ветвь. Фраза «Eifel проверен» не отличает подтверждение от опровержения или неопределённости.

Потеря всех ACK создаёт опасную копию картины

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

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

Шаг 5 учитывает поддержку DSACK и проверяет, охватывает ли ACK все открытые данные. В опасном случае алгоритм завершает процедуру без обратного действия. Поэтому его нельзя свести к echo < retransmit: отказ вынести положительный вердикт тоже является результатом.

Один итоговый флаг не объяснит, почему восстановление состояния было разрешено или запрещено.

Недобросовестный приёмник способен изготовить доказательство

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

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

Безопасность не возникает из надписи «timestamps включены». Она определяется сохранённым секретом, гранулярностью, знаниями второй стороны и поведением при отсутствии доказательства.

Диагноз не восстановит состояние, которое не было сохранено

Шаг (RESP) в RFC 3522 ничего не делает. Документ перечисляет возможные цели — вернуть состояние управления перегрузкой, остановить лишние go-back-N передачи, изменить порог дублированных ACK или оценку RTT — и оставляет их за пределами обнаружения.

Позднее RFC 4015 описывает алгоритм ответа Eifel. Отдельная спецификация нужна потому, что ответ требует подготовки. Если предполагается вернуть окно или порог slow start, прежние значения надо сохранить заранее. Факт ложного восстановления не раскрывает перезаписанное число.

Нужна и граница отката. Конкретная копия могла оказаться ненужной, а другой сегмент того же окна — действительно потеряться. Обсуждение DSACK в RFC 3708 прямо рассматривает смешанный случай. Оправдание одной передачи не отменяет все сигналы перегрузки.

Детектор вправе классифицировать наблюдаемое событие. Он не получает автоматически право переписывать все переменные более широкого эпизода.

Последующий успех не стирает вмешательство

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

Сети всё ещё предстоит доставить поток. Расширенное окно не доказывает прекращение перестановки, стабильную ёмкость или завершение пользовательской операции. Поздние документы — дорожная карта TCP, RACK-TLP, CUBIC — также различают обнаружение ложного сигнала потери и безопасное действие в меняющейся сети.

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

Составьте квитанцию обратимой обработки потери

Зафиксируйте согласование timestamps и разрешение часов. Сохраните диапазон и метку исходной передачи, триггер потери, число дублированных ACK или состояние таймера и все параметры управления перегрузкой до вмешательства.

Свяжите первую копию с неизменяемым RetransmitTS. Сохраните первый допустимый ACK, его диапазон, Timestamp Echo Reply, блоки DSACK и точное решение шага 5. Отметьте базовый или безопасный вариант.

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

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

Граница доказательств

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

RFC 3522 рассматривается как Experimental-документ апреля 2003 года, а не Internet Standard. RFC 4015, RFC 5681, RFC 5682, RFC 6298 и RFC 7323 сохраняют собственные статусы и рамки. RFC 9438, RFC 8985 и RFC 9002 служат поздними сравнениями, а не доказательством реализации RFC 3522.

Тексты Heng Lu о полномочиях и работающем коде указаны как редакционные линзы. Они помогают разделить формальный сигнал, рабочее состояние и наблюдаемый итог, но не являются источниками намерений IETF.

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

Источники