Trivial File Transfer Protocol ( TFTP ) - это простой протокол передачи файлов с блокировкой, который позволяет клиенту получать файл с удаленного хоста или помещать файл на него . Одно из основных его применений - на ранних этапах загрузки узлов из локальной сети . TFTP был использован для этого приложения, потому что он очень прост в реализации.
TFTP был впервые стандартизирован в 1981 году [1], а текущую спецификацию протокола можно найти в RFC 1350.
Обзор
Благодаря своей простой конструкции TFTP может быть легко реализован с помощью кода с небольшим объемом памяти . Таким образом, это протокол выбора на начальных этапах любой стратегии загрузки из сети , такой как BOOTP , PXE , BSDP и т. Д., При нацеливании с компьютеров с высоким уровнем ресурсов на одноплатные компьютеры (SBC) и системы на кристалле (SoC). ). Он также используется для передачи образов микропрограмм и файлов конфигурации на сетевые устройства, такие как маршрутизаторы , брандмауэры , IP-телефоны и т. Д. Сегодня TFTP практически не используется для передачи данных через Интернет.
На дизайн TFTP повлиял более ранний протокол EFTP , который был частью набора протоколов PUP . TFTP был впервые определен в 1980 году в IEN 133. [2] В июне 1981 года протокол TFTP (версия 2) был опубликован как RFC 783 и позже обновлен в июле 1992 года RFC 1350, который, среди прочего, исправил синдром ученика чародея . В марте 1995 года RFC 1782, дополненный расширением опций TFTP, обновленный позже в мае 1998 года RFC 2347, определил механизм согласования опций, который устанавливает структуру для согласования опций передачи файлов перед передачей с использованием механизма, совместимого с исходной спецификацией TFTP.
TFTP - это простой протокол для передачи файлов, реализованный поверх протоколов UDP / IP с использованием хорошо известного номера порта 69. TFTP был разработан таким образом, чтобы он был небольшим и простым в реализации, поэтому ему не хватает большинства расширенных функций, предлагаемых более надежными. протоколы передачи файлов. TFTP только читает и записывает файлы с удаленного сервера или на него. Он не может перечислять, удалять или переименовывать файлы или каталоги и не имеет условий для аутентификации пользователей. Сегодня TFTP обычно используется только в локальных сетях (LAN).
Подробности
В TFTP передача инициируется клиентом, отправляющим запрос на чтение или запись определенного файла на сервере. Запрос может дополнительно включать набор согласованных параметров передачи, предложенных клиентом в соответствии с условиями, указанными в RFC 2347. Если сервер удовлетворяет запрос, файл отправляется блоками фиксированной длины по 512 байт по умолчанию или числом, указанным в размере блока. согласованная опция, определенная в RFC 2348. Каждый блок передаваемых данных, который обычно переносится в одном IP-пакете, чтобы избежать фрагментации IP, должен быть подтвержден пакетом подтверждения перед отправкой следующего блока. Пакет данных размером менее 512 байт или согласованный вариант размера блока сигнализируют о завершении передачи. Если пакет теряется в сети, предполагаемый получатель истекает по таймауту и может повторно передать свой последний пакет (который может быть данными или подтверждением), тем самым заставляя отправителя потерянного пакета повторно передать этот потерянный пакет. Отправитель должен держать под рукой только один пакет для повторной передачи, поскольку подтверждение шага блокировки гарантирует, что все старые пакеты были правильно получены. Обратите внимание, что оба устройства, участвующие в передаче, считаются отправителями и получателями. Один отправляет данные и получает подтверждения, другой отправляет подтверждения и получает данные.
TFTP определяет три режима передачи: netascii, октет и почту.
- Netascii - это модифицированная форма ASCII , определенная в RFC 764. Она состоит из 8-битного расширения 7-битного пространства символов ASCII от 0x20 до 0x7F (печатаемые символы и пробел) и восьми управляющих символов. Разрешенные управляющие символы включают ноль (0x00), перевод строки (LF, 0x0A) и возврат каретки (CR, 0x0D). Netascii также требует, чтобы маркер конца строки на хосте был преобразован в пару символов CR LF для передачи и чтобы за любым CR должен был следовать либо LF, либо ноль.
- Октет позволяет передавать произвольные необработанные 8-битные байты, при этом полученный файл получается побайтно идентичным отправляемому. Более правильно, если хост получает файл октетов, а затем возвращает его, возвращенный файл должен быть идентичен оригиналу. [3]
- В режиме передачи почты используется передача Netascii, но файл отправляется получателю электронной почты с указанием адреса электронной почты получателя в качестве имени файла. RFC 1350 объявил этот способ передачи устаревшим.
TFTP использует UDP в качестве транспортного протокола . Запрос на передачу всегда инициируется на порт 69, но порты передачи данных выбираются отправителем и получателем независимо во время инициализации передачи. Порты выбираются случайным образом в соответствии с параметрами сетевого стека, обычно из диапазона временных портов . [4]
- Инициирующий хост A отправляет пакет RRQ (запрос чтения) или WRQ (запрос записи) хосту S на порт номер 69, содержащий имя файла, режим передачи и, необязательно, любой согласованный вариант в соответствии с условиями RFC 2347.
- S отвечает опцией ACK, если опции использовались, и пакетом ACK (подтверждение) на WRQ и непосредственно пакетом DATA на RRQ. Пакет отправляется из случайно назначенного временного порта , и все будущие пакеты на хост S должны направляться на этот порт.
- Исходный хост отправляет нумерованные пакеты DATA на целевой хост, все, кроме последнего, содержат полноразмерный блок данных (по умолчанию 512 байт). Хост назначения отвечает пронумерованными пакетами ACK для всех пакетов DATA.
- Последний пакет DATA должен содержать меньше, чем полноразмерный блок данных, чтобы сигнализировать, что он последний. Если размер переданного файла является точным кратным размеру блока, источник отправляет последний пакет DATA, содержащий 0 байтов данных.
- Приемник отвечает на каждый ДАННЫЕ с соответствующим пронумерованным ACK. Отправитель отвечает на первый полученный ACK блока ДАННЫМИ следующего блока.
- Если ACK в конечном итоге не получен, таймер повторной передачи повторно отправляет пакет DATA.
TFTP всегда был связан с загрузкой по сети. Одной из первых попыток в этом отношении была загрузка начальной загрузки с использованием стандарта TFTP RFC 906, опубликованного в 1984 году, который установил опубликованный в 1981 году стандарт протокола тривиальной передачи файлов RFC 783, который будет использоваться в качестве стандартного протокола передачи файлов для начальной загрузки. Вскоре за ним последовал стандарт протокола начальной загрузки RFC 951 (BOOTP), опубликованный в 1985 году, который позволял бездисковой клиентской машине обнаруживать свой собственный IP-адрес, адрес сервера TFTP и имя программы сетевой начальной загрузки. (NBP) для передачи по TFTP, загрузки в память и выполнения. Стандарт протокола динамической конфигурации хоста RFC 2131 (DHCP), опубликованный в 1997 году, улучшил возможности BOOTP. Наконец, в декабре 1998 года была выпущена среда Preboot Execution Environment (PXE) версии 2.0, а в сентябре 1999 года было обнародовано обновление 2.1, рассчитанное на TFTP в качестве протокола передачи файлов. [5] Intel недавно решила широко поддерживать PXE в рамках новой спецификации UEFI, расширяя поддержку TFTP на все среды EFI / UEFI. [6] [7]
Исходный протокол имеет ограничение на размер файла передачи 512 байт / блок x 65535 блоков = 32 МБ. В 1998 году этот предел был расширен до 65535 байт / блок x 65535 блоков = 4 ГБ с помощью опции TFTP Blocksize Option RFC 2348. Если заданный размер блока дает размер IP-пакета, превышающий минимальный MTU в любой точке сетевого пути, происходит фрагментация и повторная сборка IP. произойдет не только добавление дополнительных служебных данных [8], но также приведет к полному сбою передачи, когда реализация минималистичного IP-стека в BOOTP или PXE ROM хоста не реализует (или не выполняет должным образом) фрагментацию и повторную сборку IP. [9] Если пакеты TFTP должны оставаться в пределах стандартного MTU Ethernet (1500), значение размера блока рассчитывается как 1500 минус заголовки TFTP (4 байта), UDP (8 байтов) и IP (20 байтов) = 1468 байтов / блок. , это дает ограничение в 1468 байт / блок x 65535 блоков = 92 МБ. Сегодня большинство серверов и клиентов поддерживают смену номера блока (счетчик блоков возвращается к 0 или 1 [10] после 65535), что дает практически неограниченный размер передаваемого файла.
Поскольку TFTP использует UDP, он должен обеспечивать собственный транспорт и поддержку сеансов. Каждый файл, передаваемый через TFTP, представляет собой независимый обмен. Как правило, эта передача выполняется поэтапно, когда только один пакет (либо блок данных, либо «подтверждение») альтернативно перемещается по сети в любое время. Благодаря этой стратегии с одним блоком данных вместо отправки большего количества непрерывных блоков данных перед приостановкой передачи для ожидания соответствующего подтверждения (оконного управления) TFTP обеспечивает низкую пропускную способность, особенно по каналам с высокой задержкой . Microsoft представила оконный TFTP в Windows 2008 как часть своих служб развертывания Windows (WDS), в январе 2015 года был опубликован вариант TFTP Windowsize RFC 7440. Это существенно повышает производительность таких вещей, как загрузка PXE, без побочного эффекта фрагментации IP, который иногда наблюдается в параметре Blocksize Option RFC 2348 [11]
Соображения безопасности
TFTP не включает механизмов входа в систему или контроля доступа. Необходимо соблюдать осторожность при использовании TFTP для передачи файлов, когда требуются аутентификация, контроль доступа, конфиденциальность или проверка целостности. Обратите внимание, что эти службы безопасности могут быть предоставлены выше или ниже уровня, на котором работает TFTP. Также необходимо проявлять осторожность в правах, предоставляемых процессу сервера TFTP, чтобы не нарушать безопасность файловой системы сервера. TFTP часто устанавливается с такими элементами управления, что только файлы с общедоступным доступом для чтения доступны через TFTP. Также обычно запрещены перечисление, удаление, переименование и запись файлов через TFTP. Передача файлов по TFTP не рекомендуется, если присущие протоколу ограничения могут вызвать непреодолимую ответственность. [12]
Документация по стандартам IETF
Номер RFC | Заголовок | Опубликовано | Автор | Устаревшая и обновленная информация |
---|---|---|---|---|
RFC 783 | Протокол TFTP (редакция 1) | Июнь 1981 г. | К. Соллинз | Устарело - RFC 1350 |
RFC 906 | Загрузка начальной загрузки с использованием TFTP | Июнь 1984 г. | Росс Финлейсон | - |
RFC 951 | Протокол начальной загрузки | Сентябрь 1985 г. | Билл Крофт | Обновлено RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494 |
RFC 1350 | Протокол TFTP (Версия 2) | Июль 1992 г. | К. Соллинз | Обновлено RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349 |
RFC 1782 | Расширение опции TFTP | Март 1995 г. | Г. Малкин | Устарело - RFC 2347 |
RFC 2131 | Протокол динамического конфигурирования сервера | Март 1997 г. | Р. Дромс | Обновлено RFC 3396, RFC 4361, RFC 5494, RFC 6842 |
RFC 2347 | Расширение опции TFTP | Май 1998 г. | Г. Малкин | - |
RFC 2348 | Вариант размера блока TFTP | Май 1998 г. | Г. Малкин | - |
RFC 2349 | Интервал тайм-аута TFTP и параметры размера передачи | Май 1998 г. | Г. Малкин | - |
RFC 5505 | Принципы настройки Интернет-хоста | Май 2009 г. | Б. Абоба | - |
RFC 7440 | Вариант TFTP Windowsize | Январь 2015 | П. Масотта | - |
Смотрите также
- Простой протокол передачи файлов
- Среда выполнения предварительной загрузки
Рекомендации
- ^ RFC 783
- ^ Карен Р. Соллинз (1980-01-29). Протокол TFTP . IETF . IEN 133 . Проверено 1 мая 2010 .
- ^ RFC 1350, стр.
- ^ Карен Соллинз (июль 1992 г.). Протокол TFTP (версия 2) . IETF . DOI : 10,17487 / RFC1350 . RFC 1350 . Проверено 1 мая 2010 .
- ^ «Спецификация среды выполнения предварительной загрузки (PXE) - версия 2.1» (PDF) . Корпорация Intel. 1999-09-20. Архивировано из оригинального (PDF) 2 ноября 2013 года . Проверено 8 февраля 2014 .
- ^ «Спецификация унифицированного расширяемого интерфейса микропрограмм» (PDF) . UEFI. 2013-12-02 . Проверено 4 апреля 2014 .
- ^ «Анализ производительности загрузки UEFI PXE» (PDF) . Корпорация Intel. 2014-02-02. Архивировано из оригинального (PDF) 08.08.2014 . Проверено 4 апреля 2014 .
- ^ RFC 2348, стр.
- ^ RFC 5505, стр. 7.
- ^ «Расширение TFTP» . CompuPhase . Проверено 12 декабря 2018 .
- ^ RFC 7440, стр.
- ^ RFC 7440, стр. 7.