Кратко
- Запоздалое подтверждение могло заставить обе стороны повторять текущие пакеты и передавать дублирование дальше по потоку блоков.
- RFC 1123 запретил отправителю DATA повторно посылать текущий блок в ответ на дублированный ACK. Риск касался срыва передачи при перегрузке, а не целостности уже полученного файла.
Один блок и одно подтверждение
В июне 1981 года Karen Sollins опубликовала вторую редакцию Trivial File Transfer Protocol. Протокол оставлял только небольшой обмен: запрос чтения или записи файла, блоки данных размером до 512 байт и подтверждение каждого блока перед отправкой следующего. Отправителю достаточно было хранить один текущий пакет. Это экономило память и упрощало реализацию, что имело значение для компьютеров, которым ещё предстояло загрузить собственную систему.
RFC 1123 в 1989 году называл начальную загрузку узла в локальной сети главным применением TFTP и отмечал, что небольшая реализация помещается в EPROM. BOOTP мог передать конфигурацию, после чего TFTP доставлял образ системы. Эти протоколы решали соседние задачи, но загрузка файла всё равно зависела от своевременных подтверждений.
TFTP работал поверх UDP и сам управлял повторами. Если ожидаемый ответ не приходил до тайм-аута, отправитель мог повторить DATA, который ждал подтверждения. При потере пакета правило выглядело естественно. При задержке без потери возникала другая последовательность.
Старый ACK встречает новое состояние
Пусть узел A отправил DATA 20, а B ответил ACK 20. Первый ACK задержался. Таймер A истёк, и он повторил DATA 20. B уже принял блок, распознал повтор и снова отправил ACK 20. Когда первый ACK наконец пришёл, A перешёл к DATA 21. Затем прибыл второй, уже устаревший ACK 20. По исходному правилу A отвечал повторной отправкой пакета, который теперь был текущим, то есть DATA 21.
Узел B получал DATA 21 дважды и отправлял два ACK 21. Если один из них приходил после перехода A к DATA 22, он мог вызвать следующий повтор. Старый пакет воздействовал не только на прежнее состояние: обе стороны формировали ответы исходя из того, что отправляли сейчас. Так один дубликат порождал новый.
Robert Braden назвал это «Sorcerer’s Apprentice syndrome» в RFC 1123. В описанном примере оставшиеся пакеты могут передаваться вдвойне, пока потеря датаграммы не прервёт цепочку. Содержимое файла при этом не обязательно повреждается: RFC указывает, что завершившаяся передача оставляет правильный файл. Опасность состоит в расходе времени и пропускной способности: передача может закончиться тайм-аутом раньше, чем файл будет получен целиком.
Сеть усиливает повторы
Перегрузка способна запустить и усилить цикл. Задержка на загруженном пути удерживает ACK дольше таймера; лишние DATA и ACK занимают дополнительную ёмкость, повышая вероятность новых задержек. RFC предупреждает о дальнейшем росте перегрузки. Это описание механизма протокола, а не утверждение, что синдром поражал каждую медленную передачу или вызвал конкретный исторический сбой.
RFC 1123 требовал адаптивных таймеров и рекомендовал экспоненциальное увеличение задержки между повторами. Но настройка таймера не отменяет реакцию на старый ACK. Обязательное исправление было конкретным: отправитель DATA не должен повторно передавать текущий DATA после дублированного ACK. Тогда устаревшее подтверждение не запускает копию следующего блока. Таймер ACK у получателя можно убрать после соблюдения этого правила или оставить для замены действительно потерянного ACK; таймер повторной передачи у отправителя остаётся необходимым.
Точечное правило до пересмотра протокола
В мае 1992 года Noel Chiappa включил исправление в пересмотр протокола. RFC 1350 вышел в июле, заменил RFC 783 и отметил это изменение. Хронология различает требование к реализации в RFC 1123 и закрепление правила в обновлённой спецификации TFTP. Она не показывает, когда обновили каждый конкретный вариант программы.
Позднейшие расширения решали иную задачу. Увеличение размера блока и передача нескольких блоков до ACK повышают производительность, когда остановка после каждого пакета слишком дорога. Они не заменяют запрет на повтор DATA по старому подтверждению. История TFTP показывает, что минимальный формат пакета может оставить сложность в переходах состояний. Исправление сохранило один активный блок, убрав ответ, который делал дубликаты самовоспроизводящимися.
Sources
- RFC 783 — The TFTP Protocol (Revision 2), 1981
- RFC 1123 — Requirements for Internet Hosts, 1989, §§4.2.1–4.2.3
- RFC 1350 — The TFTP Protocol (Revision 2), 1992
- RFC 768 — User Datagram Protocol
- RFC 951 — Bootstrap Protocol
- RFC 1542 — BOOTP Clarifications and Extensions
- RFC 2347 — TFTP Option Extension
- RFC 2348 — TFTP Blocksize Option
- RFC 2349 — TFTP Timeout and Transfer Size Options
- RFC 7440 — TFTP Windowsize Option
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
