Тривиальный протокол передачи файлов ( TFTP ) — это простой протокол передачи файлов , который позволяет клиенту получить файл с удаленного хоста или поместить его на него . Одно из его основных применений — ранние этапы загрузки узлов из локальной сети . Для этого приложения использовался TFTP, поскольку его очень просто реализовать.
TFTP был впервые стандартизирован в 1981 году [1] , а текущую спецификацию протокола можно найти в RFC 1350.
Благодаря простой конструкции TFTP можно легко реализовать с помощью кода с небольшим объемом памяти . Таким образом, это протокол выбора на начальных этапах любой стратегии сетевой загрузки, такой как BOOTP , PXE , BSDP и т. д., при переходе от компьютеров с высоким уровнем ресурсов к одноплатным компьютерам (SBC) с очень низкими ресурсами и системам на кристалле (SoC). ). Он также используется для передачи образов прошивки и файлов конфигурации на сетевые устройства, такие как маршрутизаторы , межсетевые экраны , IP-телефоны и т. д. Сегодня TFTP практически не используется для передачи данных через Интернет.
На дизайн TFTP повлиял более ранний протокол EFTP , который был частью набора протоколов PARC Universal Packet . TFTP был впервые определен в 1980 году в IEN 133. [2] В июне 1981 года протокол TFTP (редакция 2) был опубликован как RFC 783, а затем обновлен в июле 1992 года RFC 1350, который, среди прочего, исправил синдром ученика чародея . В марте 1995 года расширение параметров TFTP RFC 1782, обновленное позже в мае 1998 года RFC 2347, определило механизм согласования параметров, который устанавливает структуру для параметров передачи файлов, которые должны быть согласованы перед передачей с использованием механизма, соответствующего исходной спецификации TFTP.
TFTP — это простой протокол для передачи файлов, реализованный поверх протоколов UDP/IP с использованием хорошо известного порта 69. TFTP был разработан так, чтобы быть небольшим и простым в реализации, и поэтому ему не хватает большинства расширенных функций, предлагаемых более надежными протоколами. протоколы передачи файлов. TFTP только читает и записывает файлы с удаленного сервера или на него. Он не может просматривать, удалять или переименовывать файлы и каталоги и не имеет средств для аутентификации пользователей. Сегодня TFTP обычно используется только в локальных сетях (LAN).
В TFTP передача инициируется клиентом, отправляющим запрос на чтение или запись определенного файла на сервере. Запрос может дополнительно включать набор согласованных параметров передачи, предложенных клиентом в соответствии с условиями, указанными в RFC 2347. Если сервер удовлетворяет запрос, файл отправляется блоками фиксированной длины по 512 байт по умолчанию или числом, указанным в размере блока. согласованный вариант, определенный в RFC 2348. Каждый блок передаваемых данных, который обычно передается в одном IP-пакете во избежание фрагментации IP, должен быть подтвержден пакетом подтверждения, прежде чем можно будет отправить следующий блок. Пакет данных размером менее 512 байт или согласованный размер блока сигнализирует о прекращении передачи. Если пакет теряется в сети, предполагаемый получатель истечет по тайм-ауту и может повторно передать свой последний пакет (который может быть данными или подтверждением), что заставит отправителя потерянного пакета повторно передать этот потерянный пакет. Отправителю приходится иметь под рукой только один пакет для повторной передачи, поскольку подтверждение шага блокировки гарантирует, что все старые пакеты были правильно получены. Обратите внимание, что оба устройства, участвующие в передаче, считаются отправителями и получателями. Один отправляет данные и получает подтверждения, другой отправляет подтверждения и получает данные.
TFTP определяет три режима передачи: netascii, октет и почта.
TFTP использует UDP в качестве транспортного протокола . Запрос на передачу всегда инициируется с использованием порта 69, но порты передачи данных выбираются отправителем и получателем независимо во время инициализации передачи. Порты выбираются случайным образом в соответствии с параметрами сетевого стека, обычно из диапазона эфемерных портов . [4]
TFTP всегда ассоциировался с сетевой загрузкой. Одной из первых попыток в этом отношении была начальная загрузка с использованием стандарта TFTP RFC 906, опубликованная в 1984 году, которая установила опубликованный в 1981 году стандарт тривиального протокола передачи файлов RFC 783, который будет использоваться в качестве стандартного протокола передачи файлов для начальной загрузки. Вскоре за ним последовал стандарт протокола начальной загрузки RFC 951 (BOOTP), опубликованный в 1985 году, который позволил бездисковому клиентскому компьютеру обнаружить свой собственный IP-адрес, адрес TFTP-сервера и имя программы сетевой начальной загрузки . (NBP) для передачи по TFTP, загрузки в память и выполнения. Стандарт протокола динамической конфигурации хоста RFC 2131 (DHCP), опубликованный в 1997 году, улучшил возможности BOOTP. Наконец, версия 2.0 Preboot Execution Environment (PXE) была выпущена в декабре 1998 года, а обновление 2.1 было обнародовано в сентябре 1999 года с использованием TFTP в качестве протокола передачи файлов. [5] Недавно компания Intel решила широко поддерживать PXE в рамках новой спецификации UEFI , расширяя поддержку TFTP на все среды EFI/UEFI. [6] [7]
Исходный протокол имеет ограничение размера передаваемого файла 512 байт/блок x 65535 блоков = 32 МБ. В 1998 году этот предел был расширен до 65535 байт/блок x 65535 блоков = 4 ГБ опцией размера блока TFTP RFC 2348. Если определенный размер блока создает размер IP-пакета, который превышает минимальный MTU в любой точке сетевого пути, происходит фрагментация IP и повторная сборка. произойдет не только увеличение накладных расходов [8] , но также приведет к полному сбою передачи, когда минималистская реализация IP-стека в BOOTP или PXE -ROM хоста не реализует (или не обеспечивает должным образом) фрагментацию и повторную сборку IP. [9] Если пакеты TFTP должны храниться в пределах стандартного Ethernet MTU (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, который иногда наблюдается в опции размера блока RFC 2348 [11].
TFTP не включает в себя механизмы входа или контроля доступа. Необходимо соблюдать осторожность при использовании TFTP для передачи файлов, где необходимы аутентификация, контроль доступа, конфиденциальность или проверка целостности. Обратите внимание, что эти службы безопасности могут предоставляться выше или ниже уровня, на котором работает TFTP. Также необходимо соблюдать осторожность при предоставлении прав процессу сервера TFTP, чтобы не нарушить безопасность файловой системы сервера. TFTP часто устанавливается с такими элементами управления, что через TFTP доступны только файлы, имеющие общий доступ для чтения. Также обычно запрещено просматривать, удалять, переименовывать и записывать файлы через TFTP. Передача файлов по TFTP не рекомендуется, если ограничения, присущие протоколу, могут вызвать непреодолимые проблемы ответственности. [12]