Кратко

  • Клиент посылал RRQ или WRQ на известный TID 69, а принявший запрос сервер отвечал со своего выбранного TID; эта пара использовалась как UDP-порты до конца передачи.
  • Чужой исходный TID получал ошибку 5, не прекращая правильный обмен; исправление каскадных повторов и последующие опции сохранили эту границу при росте производительности.

Конец нельзя было угадать по тишине

Базовый TFTP передавал DATA блоками по 512 октетов. Блок короче этого размера означал завершение. Если файл делился на 512 без остатка, требовался пустой блок: только он явно говорил, что продолжения не будет.

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

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

Порт 69 принимал только начало

Клиент выбирает свой TID и отправляет запрос чтения или записи на известный TID 69 сервера. При чтении сервер подтверждает согласие, посылая DATA 1 с нового TID. При записи с него приходит ACK 0. Два выбранных числа становятся исходным и целевым UDP-портами последующих пакетов.

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

Эта перемена часто важнее статической подписи сервиса. Фильтр способен пропустить RRQ к 69 и отбросить законный DATA с динамического порта. Видимость слушателя тогда ошибочно принимают за работоспособность всего пути.

Первый ответ выбрал разговор

После принятия положительного ответа его исходный TID становится ожидаемым. Другой TID не продолжает тот же обмен. RFC 1350 объясняет это дубликатом начального запроса: сервер может увидеть две копии и ответить на каждую из разных TID.

Клиент продолжает с первым принятым ответом. Поздний пакет из второй пары отбрасывается и получает ERROR 5 — Unknown transfer ID. Уже действующая передача сохраняется.

Неверный исходный порт — признанная ошибка, которая не завершает соединение. Большинство ERROR означают прекращение и сами не подтверждаются и не повторяются. Ошибка 5 относится к постороннему пакету; дать ему право уничтожить правильное состояние означало бы нарушить саму изоляцию.

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

Старое подтверждение запускало лишнюю работу

В RFC 783 обеим сторонам разрешалось отвечать на старый дубликат повтором текущего пакета. После задержки и срабатывания таймера поздняя копия могла вызвать ещё один ответ. Дубликат ответа порождал дубликат с другой стороны, и каждое последующее DATA/ACK шло дважды.

RFC 1123 назвал это синдромом ученика чародея. Байты файла могли остаться верными, но дополнительные пакеты усиливали затор, создавали задержки и приводили к новым тайм-аутам.

Обязательное исправление лишило дублированный ACK права запускать DATA: отправитель данных не должен повторять текущий блок только из-за старого подтверждения. Восстановление разрешает соответствующий таймер или ожидаемое состояние. RFC 1350 заменил RFC 783, закрепив исправление.

Расширения сохраняли право предложения

Один блок в полёте ограничивал скорость. RFC 2347 добавил параметры к RRQ и WRQ, но только клиент мог начать переговоры. Сервер включал в OACK лишь запрошенные и принятые варианты. Неподдерживаемый параметр опускался; неподтверждённый считался отсутствующим.

При чтении ACK 0 принимал OACK, при записи это делал DATA 1. RFC 2348 позволил согласовать размер блока, RFC 2349 — тайм-аут и общий размер. RFC 7440 разрешил окно последовательных блоков с ACK последнего блока окна.

Большое окно увеличивает объём ещё не подтверждённой работы. Оно не меняет два TID и не добавляет контроля доступа. Это соглашение о темпе внутри уже выбранных концов, а не новая идентичность.

Точная доставка не равнялась правильному решению

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

Окружение должно ограничивать достижимость, чтение и запись, проверять происхождение, создавать узкое состояние firewall/NAT и связывать в журнале запрос к 69 с динамической парой. Разрешить весь UDP ради выбранного порта — значит уничтожить границу вместо поддержки протокола.

История TFTP показывает распределение малых полномочий. Известный порт разрешает обратиться. Первый ответ фиксирует разговор. Номер блока показывает прогресс. Таймер разрешает повтор. Ни один из этих сигналов не решает, имел ли файл право перемещаться.

Источники и ограничения

Ранний протокол описан в RFC 783, исправление повторов — в RFC 1123, пересмотренная версия — в RFC 1350. Опции заданы RFC 2347, RFC 2348, RFC 2349 и RFC 7440. Реестр IANA содержит порт 69. Эти источники не измеряют внедрение в 2026 году и не превращают TID в аутентификацию, разрешение, шифрование или проверку содержимого.