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

редактировать
Стандартный протокол для передачи файлов по сетям TCP / IP

Протокол передачи файлов (FTP ) - стандартный сетевой протокол, используемый для передачи компьютерных файлов между клиентом и сервером в компьютерной сети.

FTP построен на архитектуре модели клиент-сервер, использующей отдельные соединения управления и передачи данных между клиентом и сервером. Пользователи FTP могут аутентифицироваться с помощью протокола входа в виде открытого текста, обычно в форме имени пользователя и пароля, но могут подключаться анонимно, если сервер настроен на это. Для безопасной передачи, которая защищает имя пользователя и пароль и шифрует контент, FTP часто защищен с помощью SSL / TLS (FTPS ) или заменяется на Протокол передачи файлов SSH (SFTP).

Первыми клиентскими приложениями FTP были программы командной строки, разработанные до того, как операционные системы имели графические пользовательские интерфейсы, и до сих пор поставляются с большинством Операционные системы Windows, Unix и Linux. Многие клиенты FTP и служебные программы автоматизации были разработаны для настольных компьютеров, серверов, мобильных устройств и оборудования, а FTP был включен в приложения для повышения производительности, например.

Содержание
  • 1 История FTP-серверов
  • 2 Обзор протокола
    • 2.1 Обмен данными и передача данных
    • 2.2 Обход NAT и межсетевой экран
    • 2.3 Типы данных
    • 2.4 Файловые структуры
    • 2.5 Режимы передачи данных
  • 3 Вход в систему
    • 3.1 Анонимный FTP
  • 4 Отличия от HTTP
  • 5 Поддержка веб-браузера
    • 5.1 Синтаксис
  • 6 Безопасность
    • 6.1 FTP через SSH
  • 7 Производные
    • 7.1 FTPS
    • 7.2 Протокол передачи файлов SSH
    • 7.3 Простой протокол передачи файлов
    • 7.4 Простой протокол передачи файлов
  • 8 Команды FTP
  • 9 Коды ответов FTP
  • 10 См. Также
  • 11 Ссылки
  • 12 Дополнительная литература
  • 13 Внешние ссылки
История FTP-серверов

Первоначальная спецификация для протокола передачи файлов была написана Абхаем Бхушаном и опубликована как RFC 114 от 16 апреля 1971 г. До 1980 г. FTP работал на NCP, предшественнике TCP / IP. Позднее протокол был заменен версией TCP / IP, RFC 765 (июнь 1980 г.) и RFC 959 <182.>(Октябрь 1985 г.) текущая спецификация. Несколько предложенных стандартов изменяют RFC 959, например, RFC 1579 (февраль 1994 г.) включает протокол FTP с поддержкой межсетевого экрана. (пассивный режим), RFC 2228 (июнь 1997 г.) предлагает расширения безопасности, RFC 2428 (сентябрь 1998 г.) добавляет поддержку IPv6 и определяет новый тип пассивного режима.

Обзор протокола

Связь и передача данных

Иллюстрация запуска пассивного соединения с использованием порта 21

FTP может работать в активном или пассивном режиме, который определяет, как устанавливается соединение для передачи данных. (Обратите внимание, что это несколько сбивает с толку, это значение «режима» отличается от значения команды MODE в протоколе FTP и фактически соответствует командам PORT / PASV / EPSV / etc.) В обоих случаях клиент создает TCP управлять соединением от случайного, обычно непривилегированного, порта N к командному порту 21 FTP-сервера.

  • В активном режиме клиент начинает прослушивать входящие соединения для передачи данных от сервера на порт M. Он отправляет команду FTP PORT M, чтобы сообщить серверу, какой порт он прослушивает. Затем сервер инициирует канал данных для клиента со своего порта 20, порта данных FTP-сервера.
  • В ситуациях, когда клиент находится за межсетевым экраном и не может принимать входящие TCP-соединения, может использоваться пассивный режим. В этом режиме клиент использует управляющее соединение для отправки команды PASV на сервер, а затем получает от сервера IP-адрес и номер порта сервера, которые затем использует клиент для открытия подключения к данным от произвольного клиентского порта к серверу. Получены IP-адрес сервера и номер порта сервера.

Оба режима были обновлены в сентябре 1998 года для поддержки IPv6. В то время были внесены дальнейшие изменения в пассивный режим, обновив его до расширенного пассивного режима.

Сервер отвечает через управляющее соединение трехзначным кодом состояния в ASCII с дополнительным текстом сообщение. Например, «200» (или «200 OK») означает, что последняя команда была успешной. Цифры представляют собой код ответа, а необязательный текст представляет понятное человеку объяснение или запрос (например, ). Текущая передача файловых данных по соединению для передачи данных может быть прервана с помощью сообщения прерывания, отправляемого по управляющему соединению.

Причина, по которой FTP требуется два порта (один для отправки и один для приема), связана с тем, что изначально он был разработан для работы с программой управления сетью (NCP), которая была симплексный протокол, который использует два адреса порта, устанавливая два соединения для двусторонней связи. Нечетный и четный порт были зарезервированы для каждого приложения или протокола прикладного уровня. Стандартизация TCP и UDP снизила необходимость использования двух симплексных портов для каждого приложения до одного дуплексного порта, но протокол FTP никогда не изменялся так, чтобы использовать только один порт, а продолжал использовать два для обратной совместимости.

NAT и обход брандмауэра

FTP обычно передает данные, когда сервер подключается обратно к клиенту после того, как клиент отправляет команду PORT. Это проблематично как для NAT, так и для брандмауэров, которые не разрешают подключения из Интернета к внутренним хостам. Для NAT дополнительная сложность заключается в том, что представление IP-адресов и номера порта в команде PORT относится к IP-адресу и порту внутреннего хоста, а не к общедоступному IP-адресу и порту NAT.

Есть два подхода к решению этой проблемы. Один из них заключается в том, что FTP-клиент и FTP-сервер используют команду PASV, которая устанавливает соединение для передачи данных от FTP-клиента к серверу. Это широко используется современными FTP-клиентами. Другой подход состоит в том, чтобы NAT изменял значения команды PORT, используя для этой цели шлюз уровня приложения.

Типы данных

При передаче данных по сети определены четыре типа данных:

  • ASCII (TYPE A): используется для текста. При необходимости данные преобразуются из символьного представления хоста-отправителя в «8-bit ASCII» перед передачей и (опять же, если необходимо) в символьное представление хоста-получателя. Как следствие, этот режим не подходит для файлов, содержащих данные, отличные от обычного текста.
  • Изображение (ТИП I, обычно называемый двоичным режимом): отправляющее устройство отправляет каждый файл байт байтом, и получатель сохраняет поток байтов по мере его получения. (Поддержка режима изображения рекомендована для всех реализаций FTP.)
  • EBCDIC (TYPE E): используется для обычного текста между хостами с использованием набора символов EBCDIC.
  • Local (TYPE L n) : Разработан для поддержки передачи файлов между машинами, которые не используют 8-битные байты, например 36-битные системы, такие как DEC PDP-10s. Например, «TYPE L 9» будет использоваться для передачи данных в 9-битных байтах или «TYPE L 36» для передачи 36-битных слов. Большинство современных FTP-клиентов / серверов поддерживают только L 8, что эквивалентно I.

Просроченный Internet Draft определяет ТИП U для передачи текстовых файлов Unicode с использованием UTF -8 ; хотя проект так и не стал RFC, он был реализован несколькими FTP-клиентами / серверами.

Обратите внимание, что эти типы данных обычно называются «режимами», хотя неоднозначно это слово также используется для обозначения режима связи «активный-пассивный» (см. Выше) и режимов, установленных командой MODE протокола FTP ( увидеть ниже).

Для текстовых файлов (TYPE A и TYPE E) предусмотрены три различных параметра управления форматом, чтобы контролировать способ печати файла:

  • Непечатаемый (TYPE AN и TYPE EN) - файл не содержит символов управления кареткой, предназначенных для принтера
  • Telnet (TYPE AT и TYPE ET) - файл содержит символы управления кареткой Telnet (или другими словами ASCII C0) (CR, LF и т. д.)
  • ASA (TYPE AA и TYPE EA) - файл содержит символы управления кареткой ASA

Эти форматы в основном относились к линейным принтерам ; большинство современных FTP-клиентов / серверов поддерживают только управление форматом по умолчанию N.

Файловые структуры

Файловая организация указывается с помощью команды STRU. Следующие файловые структуры определены в разделе 3.1.1 RFC959:

  • Fили структура FILE (ориентированная на поток). Файлы рассматриваются как произвольная последовательность байтов, символов или слов. Это обычная файловая структура в системах Unix и других системах, таких как CP / M, MSDOS и Microsoft Windows. (Раздел 3.1.1.1)
  • Rили структура RECORD (ориентированная на записи). Файлы рассматриваются как разделенные на записи, которые могут быть фиксированной или переменной длины. Эта файловая организация распространена на мэйнфреймах и системах среднего уровня, таких как MVS, VM / CMS, OS / 400 и VMS, которые поддерживают файловые системы, ориентированные на записи,.
  • Pили структуру PAGE (ориентированную на страницы). Файлы разделены на страницы, которые могут содержать данные или метаданные; каждая страница может также иметь заголовок с различными атрибутами. Эта файловая структура была специально разработана для систем TENEX и обычно не поддерживается на других платформах. Раздел 4.1.2.3 RFC1123 рекомендует не применять эту структуру.

Большинство современных FTP-клиентов и серверов поддерживают только STRU F. STRU R все еще используется в приложениях для передачи файлов мэйнфреймов и мини-компьютеров.

Режимы передачи данных

Передача данных может осуществляться в любом из трех режимов:

  • Потоковый режим (РЕЖИМ S): данные отправляются в виде непрерывного потока, освобождая FTP от любой обработки. Скорее, вся обработка оставлена ​​до TCP. Индикатор конца файла не требуется, если данные не разделены на записи.
  • Блочный режим (РЕЖИМ B): предназначен в первую очередь для передачи файлов, ориентированных на записи (STRU R), хотя также может использоваться для передачи потоковые текстовые файлы (STRU F). FTP помещает каждую запись (или строку) данных в несколько блоков (заголовок блока, счетчик байтов и поле данных), а затем передает их TCP.
  • Сжатый режим (РЕЖИМ C): расширяет РЕЖИМ B данными сжатие с использованием кодирования длин серий.

Большинство современных FTP-клиентов и серверов не реализуют РЕЖИМ B или РЕЖИМ C; Исключением являются FTP-клиенты и серверы для операционных систем мэйнфреймов и миникомпьютеров.

Некоторое программное обеспечение FTP также реализует режим сжатия на основе DEFLATE, который иногда называют «Режим Z» после команды, которая его включает. Этот режим был описан в Internet Draft, но не стандартизован.

GridFTP определяет дополнительные режимы, MODE E и MODE X, как расширения MODE B.

Login

FTP-вход использует обычную схему имени пользователя и пароля для предоставления доступа. Имя пользователя отправляется на сервер с помощью команды USER, а пароль отправляется с помощью команды PASS. Эта последовательность не зашифрована «на проводе», поэтому может быть уязвима для сетевой атаки сниффингом. Если информация, предоставленная клиентом, принимается сервером, сервер отправляет приветствие клиенту, и сеанс начинается. Если сервер поддерживает это, пользователи могут входить в систему без предоставления учетных данных, но тот же сервер может разрешать только ограниченный доступ для таких сеансов.

Анонимный FTP

Хост, предоставляющий службу FTP, может предоставить анонимный доступ по FTP. Пользователи обычно входят в службу с «анонимной» (строчной и чувствительной к регистру на некоторых FTP-серверах) учетной записью при запросе имени пользователя. Хотя пользователей обычно просят отправить свой адрес электронной почты вместо пароля, проверка предоставленных данных фактически не выполняется. Многие FTP-узлы, предназначенные для предоставления обновлений программного обеспечения, допускают анонимный вход.

Отличия от HTTP

HTTP по существу исправляет ошибки в FTP, которые делали его неудобным для использования для многих небольших эфемерных передач. типично для веб-страниц.

FTP имеет управляющее соединение с отслеживанием состояния, которое поддерживает текущий рабочий каталог и другие флаги, и для каждой передачи требуется вторичное соединение, через которое передаются данные. В «пассивном» режиме это вторичное соединение от клиента к серверу, тогда как в «активном» режиме по умолчанию это соединение от сервера к клиенту. Эта очевидная смена ролей в активном режиме и случайные номера портов для всех передач - вот почему межсетевые экраны и шлюзы NAT так тяжело работают с FTP. HTTP не имеет состояния и мультиплексирует управление и данные через одно соединение от клиента к серверу на хорошо известных номерах портов, которые тривиально проходят через шлюзы NAT и просты для управления брандмауэрами.

Установка управляющего соединения FTP происходит довольно медленно из-за задержек отправки всех требуемых команд и ожидания ответов в оба конца, поэтому принято устанавливать управляющее соединение и удерживать его открытым для нескольких файлов. передает, а не отбрасывает и каждый раз заново устанавливает сеанс. Напротив, HTTP изначально сбрасывал соединение после каждой передачи, потому что это было очень дешево. Хотя впоследствии HTTP получил возможность повторно использовать TCP-соединение для множественных передач, концептуальная модель все еще представляет собой независимые запросы, а не сеанс.

Когда FTP передает через соединение для передачи данных, контрольное соединение не используется. Если передача занимает слишком много времени, брандмауэр или NAT могут решить, что контрольное соединение не работает, и прекратить его отслеживание, фактически разорвав соединение и запутав загрузку. Одиночное HTTP-соединение простаивает только между запросами, и это нормально и ожидается, что такие соединения будут сброшены после тайм-аута.

Поддержка веб-браузера

Наиболее распространенные веб-браузеры могут получать файлы, размещенные на FTP-серверах, хотя они могут не поддерживать такие расширения протокола, как FTPS. Когда предоставляется FTP - а не HTTP - URL, доступное содержимое на удаленном сервере представляется способом, аналогичным тому, который используется для другого веб-содержимого. Полнофункциональный FTP-клиент может быть запущен в Firefox в форме расширения под названием FireFTP.

. С 2019 года основные браузеры, такие как Chrome и Firefox, в разной степени отказываются от поддержки FTP, Google планирует полностью удалить его в Chrome 82. Mozilla в настоящее время обсуждает предложения, в том числе удаление поддержки только старых реализаций FTP, которые больше не используются, для упрощения их кода.

Синтаксис

FTP Синтаксис URL описан в RFC 1738 и имеет форму: ftp: // [пользователь [: пароль] @] хост [: порт] / url- путь(части в квадратных скобках необязательны).

Например, URL-адрес ftp://public.ftp-servers.example.com/mydirectory/myfile.txt представляет файл myfile.txt из каталога mydirectory на сервере public.ftp-servers.example.com как FTP-ресурс. URL-адрес ftp: // user001: [email#160;protected]/mydirectory/myfile.txt добавляет спецификацию имени пользователя и пароля, которые должны использоваться для доступа к этому ресурсу.

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

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

Безопасность

FTP не был разработан для быть безопасным протоколом и имеет много слабых мест. В мае 1999 года авторы RFC 2577 перечислили уязвимость для следующих проблем:

FTP не шифрует свой трафик; все передачи осуществляются в виде открытого текста, а имена пользователей, пароли, команды и данные могут быть прочитаны любым лицом, способным выполнить захват пакетов (прослушивание ) в сети. Эта проблема характерна для многих спецификаций интернет-протокола (таких как SMTP, Telnet, POP и IMAP), которые были разработаны до создания таких механизмов шифрования, как TLS. или SSL.

Общие решения этой проблемы включают:

  1. Использование безопасных версий незащищенных протоколов, например, FTPS вместо FTP и TelnetS вместо Telnet.
  2. Использование другого, более безопасного протокола, который может обрабатывать задание, например Протокол передачи файлов SSH или Протокол безопасного копирования.
  3. Использование безопасного туннеля, такого как Secure Shell (SSH) или виртуальная частная сеть (VPN).

FTP через SSH

FTP через SSH - это практика туннелирования обычного сеанса FTP через соединение Secure Shell. Поскольку FTP использует несколько соединений TCP (необычно для протокола TCP / IP, который все еще используется), туннелирование через SSH особенно сложно. Со многими клиентами SSH попытка настроить туннель для канала управления (начальное соединение клиент-сервер на порту 21) защитит только этот канал; при передаче данных программное обеспечение FTP на обоих концах устанавливает новые TCP-соединения (каналы данных) и поэтому не имеет конфиденциальности или защиты целостности.

В противном случае это необходимо для клиентского программного обеспечения SSH иметь специальные знания о протоколе FTP, отслеживать и перезаписывать сообщения канала управления FTP и автономно открывать новые пересылки пакетов для каналов данных FTP. Программные пакеты, поддерживающие этот режим, включают:

Derivatives

FTPS

Явный FTPS - это расширение стандарта FTP, которое позволяет клиентам запрашивать шифрование FTP-сеансов. Это делается путем отправки команды «AUTH TLS». Сервер может разрешить или запретить подключения, которые не запрашивают TLS. Это расширение протокола определено в RFC 4217. Неявный FTPS - это устаревший стандарт FTP, требующий использования SSL или TLS-соединения. Было указано использовать порты, отличные от обычного FTP.

Протокол передачи файлов SSH

Протокол передачи файлов SSH (хронологически второй из двух протоколов, сокращенно SFTP) передает файлы и имеет аналогичный набор команд для пользователей, но использует Secure Протокол Shell (SSH) для передачи файлов. В отличие от FTP, он шифрует как команды, так и данные, предотвращая открытую передачу паролей и конфиденциальной информации по сети. Он не может взаимодействовать с программным обеспечением FTP.

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

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

Simple File Transfer Protocol

Simple File Transfer Protocol ( первый протокол, сокращенно SFTP), как определено в RFC 913, был предложен как (незащищенный) протокол передачи файлов с уровнем сложности, промежуточным между TFTP и FTP. Он никогда не был широко принят в Интернете, и теперь ему присвоен исторический статус IETF. Он работает через порт 115 и часто получает инициализацию SFTP. Он имеет набор команд из 11 команд и поддерживает три типа передачи данных: ASCII, двоичный и непрерывный. Для систем с размером слова, кратным 8 битам, реализация двоичного и непрерывного языков одинакова. Протокол также поддерживает вход с использованием идентификатора пользователя и пароля, иерархические папки и управление файлами (включая переименование, удаление, загрузку, загрузку, загрузку с перезаписью и загрузку с добавлением).

Команды FTP
Коды ответов FTP

Ниже приводится сводка кодов ответов FTP, которые могут быть возвращены сервером FTP . Эти коды были стандартизированы IETF в RFC 959. Код ответа представляет собой трехзначное значение. Первая цифра используется для обозначения одного из трех возможных результатов - успех, неудача или для обозначения ошибки или неполного ответа:

  • 2yz - успешный ответ
  • 4yz или 5yz - неудачный ответ
  • 1yz или 3yz - Ошибка или Неполный ответ

Вторая цифра определяет вид ошибки:

  • x0z - Синтаксис. Эти ответы относятся к синтаксическим ошибкам.
  • x1z - Информация. Отвечает на запросы информации.
  • x2z - Connections. Ответы касаются управления и передачи данных.
  • x3z - Аутентификация и учет. Ответы на процесс входа в систему и процедуры учета.
  • x4z - Не определено.
  • x5z - Файловая система. Эти ответы ретранслируют коды состояния из файловой системы сервера.

Третья цифра кода ответа используется для предоставления дополнительных сведений для каждой из категорий, определяемых второй цифрой.

См. Также
Ссылки
Дополнительная литература
  • RFC 697 - CWD Команда FTP. Июль 1975 г.
  • RFC 959 - (стандартный) протокол передачи файлов (FTP). Дж. Постел, Дж. Рейнольдс. Октябрь 1985 г.
  • RFC 1579 - (информационный) FTP с поддержкой межсетевого экрана. Февраль 1994.
  • RFC 1635 - (Информационный) Как использовать анонимный FTP. Май 1994.
  • RFC 1639 - FTP-операция по большим адресным записям (FOOBAR). Июнь 1994 г.
  • RFC 1738 - унифицированные указатели ресурсов (URL). Декабрь 1994 г.
  • RFC 2228 - (Предлагаемый стандарт) Расширения безопасности FTP. Октябрь 1997 г.
  • RFC 2389 - (Предлагаемый стандарт) Механизм согласования функций для протокола передачи файлов. Август 1998 г.
  • RFC 2428 - (Предлагаемый стандарт) Расширения для IPv6, NAT и расширенного пассивного режима. Сентябрь 1998 г.
  • RFC 2577 - (информационный) соображения безопасности FTP. Май 1999 г.
  • RFC 2640 - (Предлагаемый стандарт) Интернационализация протокола передачи файлов. Июль 1999 г.
  • RFC 3659 - (Предлагаемый стандарт) Расширения FTP. П. Хетмон. Март 2007 г.
  • RFC 5797 - (Предлагаемый стандарт) Реестр команд и расширений FTP. Март 2010 г.
  • RFC 7151 - (Предлагаемый стандарт) Команда HOST протокола передачи файлов для виртуальных хостов. Март 2014 г.
  • Реестр команд и расширений FTP IANA - Официальный реестр команд и расширений FTP
Внешние ссылки
Последняя правка сделана 2021-05-20 03:41:34
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте