Тривиальный протокол передачи файлов
| Протокол связи | |
| Аббревиатура | ТФТП |
|---|---|
| Цель | Передача файлов |
| Разработчик(и) | Доктор Карен Р. Соллинз |
| Введение | июнь 1981 года |
| Порт(ы) | 69/УДП |
| RFC(ы) | РФК 1350 |
Тривиальный протокол передачи файлов ( TFTP ) — это простой , протокол передачи файлов который позволяет клиенту получить файл или поместить файл на удаленный хост . Одно из его основных применений — ранние этапы загрузки узлов из локальной сети . Для этого приложения использовался TFTP, поскольку его очень просто реализовать.
TFTP был впервые стандартизирован в 1981 году. [ 1 ] а текущую спецификацию протокола можно найти в РФК 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, октет и почта.
- 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 байт данных.
- Получатель отвечает на каждый DATA соответствующим номером 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. Наконец, версия 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-стека ROM хоста в BOOTP или PXE- не реализует (или не реализует должным образом) фрагментацию и повторную сборку 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 ]
Документация по стандартам IETF
[ редактировать ]| Номер RFC | Заголовок | Опубликовано | Автор | Устаревшая и обновленная информация |
|---|---|---|---|---|
| RFC 783 | Протокол TFTP (версия 1) | Июнь 1981 г. | К. Соллинз | Устарело - РФК 1350 |
| РФК 906 | Начальная загрузка с использованием TFTP | июнь 1984 г. | Росс Финлейсон | — |
| RFC 951 | Протокол начальной загрузки | Сентябрь 1985 г. | Билл Крофт | Обновлено RFC 1395 , 1497 , 1532 , 1542 , 5494 |
| РФК 1350 | Протокол TFTP (версия 2) | июль 1992 г. | К. Соллинз | Обновлено RFC 1782 , 1783 , 1784 , 1785 , 2347 , 2348 , 2349 |
| РФК 1782 | Расширение опции TFTP | март 1995 г. | Г. Малкин | Устарело - РФК 2347 |
| РФК 2131 | Протокол динамической конфигурации хоста | март 1997 г. | Р. Дромс | Обновлено RFC 3396 , 4361 , 5494 , 6842 |
| РФК 2347 | Расширение опции TFTP | май 1998 г. | Г. Малкин | — |
| RFC 2348 | Опция размера блока TFTP | май 1998 г. | Г. Малкин | — |
| РФК 2349 | Интервал тайм-аута TFTP и параметры размера передачи | май 1998 г. | Г. Малкин | — |
| RFC 5505 | Принципы настройки интернет-хоста | май 2009 г. | Б. Абоба | — |
| RFC 7440 | Опция размера Windows TFTP | январь 2015 г. | П. Масотта | — |
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ RFC 783
- ^ Карен Р. Соллинз (29 января 1980 г.). Протокол TFTP . IETF . ИЕН 133 . Проверено 1 мая 2010 г.
- ^ RFC 1350, стр. 5.
- ^ Карен Р. Соллинз (июль 1992 г.). Протокол TFTP (версия 2) . IETF . дои : 10.17487/RFC1350 . РФК 1350 . Проверено 1 мая 2010 г.
- ^ «Спецификация среды выполнения перед загрузкой (PXE) — версия 2.1» (PDF) . Корпорация Интел. 20 сентября 1999 г. Архивировано из оригинала (PDF) 2 ноября 2013 г. Проверено 8 февраля 2014 г.
- ^ «Спецификация унифицированного расширяемого интерфейса встроенного ПО» (PDF) . УЕФИ. 2013-12-02 . Проверено 4 апреля 2014 г.
- ^ «Анализ производительности загрузки UEFI PXE» (PDF) . Корпорация Интел. 02.02.2014. Архивировано из оригинала (PDF) 8 августа 2014 г. Проверено 4 апреля 2014 г.
- ^ RFC 2348, стр. 3.
- ^ RFC 5505, стр. 7.
- ^ «Расширение TFTP» . КомпуФаза . Проверено 12 декабря 2018 г.
- ^ RFC 7440, стр. 1.
- ^ RFC 7440, стр. 7.