WikiDer > Простой протокол передачи файлов

Trivial File Transfer Protocol
"TFTP" перенаправляется сюда. Для правительственной программы США см. Программа отслеживания финансирования терроризма.

Простой протокол передачи файлов (TFTP) простой шаг протокол передачи файлов что позволяет клиент получить файл или поместить файл на удаленный хозяин. Одно из основных его применений - на ранних этапах загрузки узлов из локальная сеть. TFTP был использован для этого приложения, потому что он очень прост в реализации.

TFTP был впервые стандартизирован в 1981 г.[1] текущую спецификацию протокола можно найти в RFC 1350.

Обзор

Благодаря своей простой конструкции TFTP может быть легко реализован с помощью кода с небольшим объем памяти. Таким образом, это протокол выбора на начальных этапах любого загрузка по сети стратегия как BOOTP, PXE, BSDPи т. д. при таргетинге с компьютеров с высоким уровнем ресурсов на компьютеры с очень низким уровнем ресурсов Одноплатные компьютеры (SBC) и Система на чипе (SoC). Он также используется для передачи прошивка изображения и файлы конфигурации для сетевых устройств, таких как маршрутизаторы, брандмауэры, IP телефоныи т. д. Сегодня TFTP практически не используется для передачи данных через Интернет.

На дизайн TFTP повлиял более ранний протокол EFTP, который был частью Щенок набор протоколов. 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 обычно используется только на локальные сети (ЛВС).

подробности

(W1) Хост A запрашивает запись
(W2) Сервер S подтверждает запрос
(W3) Хост A отправляет пронумерованные пакеты данных.
(R1) Хост A запрашивает чтение
(R2) Сервер S отправляет пакет данных 1
(R3) Хост A подтверждает пакет данных 1

В TFTP передача инициируется клиентом, отправляющим запрос на чтение или запись определенного файла на сервере. Запрос может дополнительно включать набор согласованных параметров передачи, предложенных клиентом на условиях, указанных RFC 2347. Если сервер удовлетворяет запрос, файл отправляется блоками фиксированной длины по 512 байт по умолчанию или числом, указанным в согласованной опции размера блока, определяемой RFC 2348. Каждый блок передаваемых данных, который обычно переносится в одном IP-пакете, чтобы избежать IP-фрагментации, должен быть подтвержден пакетом подтверждения перед отправкой следующего блока. Пакет данных размером менее 512 байт или согласованный вариант размера блока сигнализируют о завершении передачи. Если пакет теряется в сети, предполагаемый получатель истекает по таймауту и ​​может повторно передать свой последний пакет (который может быть данными или подтверждением), тем самым заставляя отправителя потерянного пакета повторно передать этот потерянный пакет. Отправитель должен иметь под рукой только один пакет для повторной передачи, поскольку подтверждение шага блокировки гарантирует, что все старые пакеты были правильно получены. Обратите внимание, что оба устройства, участвующие в передаче, считаются отправителями и получателями. Один отправляет данные и получает подтверждения, другой отправляет подтверждения и получает данные.

TFTP определяет три режима передачи: netascii, октет и почту.

  1. Netascii - это модифицированная форма ASCII, определенный в RFC 764. Он состоит из 8-битного расширения 7-битного пространства символов ASCII от 0x20 до 0x7F (печатаемые символы и пробел) и восьми управляющих символов. Допустимые управляющие символы включают ноль (0x00), перевод строки (LF, 0x0A) и возврат каретки (CR, 0x0D). Netascii также требует, чтобы маркер конца строки на хосте транслировался в пару символов CR LF для передачи, и чтобы за любым CR должен был следовать либо LF, либо ноль.
  2. Октет позволяет передавать произвольные необработанные 8-битные байты, при этом полученный файл имеет побайтовую передачу, идентичную отправленной. Более правильно, если хост получает файл октетов, а затем возвращает его, возвращенный файл должен быть идентичен оригиналу.[3]
  3. В режиме передачи почты используется передача Netascii, но файл отправляется получателю электронной почты с указанием адреса электронной почты получателя в качестве имени файла. RFC 1350 объявил этот режим передачи устаревшим.

TFTP использует UDP как его транспортный протокол. Запрос на передачу всегда инициируется на порт 69, но порты передачи данных выбираются отправителем и получателем независимо во время инициализации передачи. Порты выбираются случайным образом в соответствии с параметрами сетевого стека, обычно из диапазона эфемерные порты.[4]

  1. Инициирующий хост A отправляет пакет RRQ (запрос чтения) или WRQ (запрос записи) хосту S на порт номер 69, содержащий имя файла, режим передачи и, возможно, любой согласованный вариант в соответствии с условиями RFC 2347.
  2. S отвечает опцией ACK, если опции использовались, и пакетом ACK (подтверждение) на WRQ и непосредственно пакетом DATA на RRQ. Пакет отправляется из случайно выделенного эфемерный порт, и все будущие пакеты на хост S должны быть направлены на этот порт.
  3. Исходный хост отправляет нумерованные пакеты DATA на целевой хост, все, кроме последнего, содержат полноразмерный блок данных (по умолчанию 512 байт). Хост назначения отвечает пронумерованными пакетами ACK для всех пакетов DATA.
  4. Последний пакет DATA должен содержать меньше, чем полноразмерный блок данных, чтобы сигнализировать о том, что он последний. Если размер переданного файла в точности кратен размеру блока, источник отправляет последний пакет DATA, содержащий 0 байтов данных.
  5. Приемник отвечает на каждый ДАННЫЕ соответствующим пронумерованным ACK. Отправитель отвечает на первый полученный ACK блока ДАННЫМИ следующего блока.
  6. Если ACK в конечном итоге не получен, таймер повторной передачи повторно отправляет пакет DATA.

TFTP всегда был связан с загрузкой по сети. Одной из первых попыток в этом отношении была загрузка Bootstrap с использованием стандарта TFTP. RFC 906, опубликованный в 1984 году, который установил опубликованный в 1981 году стандарт Trivial File Transfer Protocol. RFC 783 для использования в качестве стандартного протокола передачи файлов для начальной загрузки. Вскоре после этого последовал Протокол начальной загрузки стандарт RFC 951 (BOOTP), опубликованный в 1985 году, который позволил бездисковой клиентской машине обнаруживать свой собственный IP-адрес, адрес TFTP-сервера и имя Программа сетевой загрузки (NBP) для передачи по TFTP, загрузки в память и выполнения. Протокол динамического конфигурирования сервера стандарт RFC 2131 (DHCP), опубликованный в 1997 году, улучшил возможности BOOTP. Наконец, Среда выполнения предварительной загрузки (PXE) версия 2.0 была выпущена в декабре 1998 года, а обновление 2.1 было обнародовано в сентябре 1999 года с расчетом на TFTP в качестве протокола передачи файлов.[5] Intel недавно решила широко поддерживать PXE в новом UEFI спецификация, расширяющая поддержку TFTP на все среды EFI / UEFI.[6][7]

Исходный протокол имеет ограничение на размер файла передачи 512 байт / блок x 65535 блоков = 32 МБ. В 1998 году этот предел был увеличен до 65535 байт / блок x 65535 блоков = 4 ГБ с помощью опции TFTP Blocksize. RFC 2348. Если указанный размер блока дает размер IP-пакета, превышающий минимальный MTU в любой точке сетевого пути фрагментация и повторная сборка IP-адресов не только увеличат накладные расходы[8] но также приводит к полному сбою передачи, когда минималистский Стек IP реализация в хосте 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 года. 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П. Масотта-

Смотрите также

использованная литература

  1. ^ RFC 783
  2. ^ Карен Р. Соллинз (1980-01-29). Протокол TFTP. IETF. IEN 133. Получено 2010-05-01.
  3. ^ RFC 1350, стр. 5.
  4. ^ Карен Соллинз (июль 1992 г.). Протокол TFTP (Версия 2). IETF. Дои:10.17487 / RFC1350. RFC 1350. Получено 2010-05-01.
  5. ^ «Спецификация среды выполнения предварительной загрузки (PXE) - версия 2.1» (PDF). Корпорация Intel. 1999-09-20. Архивировано из оригинал (PDF) на 2013-11-02. Получено 2014-02-08.
  6. ^ «Спецификация унифицированного расширяемого интерфейса микропрограмм» (PDF). UEFI. 2013-12-02. Получено 2014-04-04.
  7. ^ «Анализ производительности загрузки UEFI PXE» (PDF). Корпорация Intel. 2014-02-02. Архивировано из оригинал (PDF) на 2014-08-08. Получено 2014-04-04.
  8. ^ RFC 2348, стр. 3.
  9. ^ RFC 5505, стр.7.
  10. ^ «Расширение TFTP». CompuPhase. Получено 2018-12-12.
  11. ^ RFC 7440, Страница 1.
  12. ^ RFC 7440, стр.7.