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

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

Первыми клиентскими приложениями FTP были программы командной строки, разработанные до того, как в операционных системах появился графический пользовательский интерфейс , и они все еще поставляются с большинством операционных систем Windows , Unix и Linux . ^{[2] [3]} С тех пор было разработано множество FTP-клиентов и утилит автоматизации для настольных компьютеров , серверов, мобильных устройств и оборудования, а FTP был включен в рабочие приложения, такие как редакторы HTML .

В январе 2021 года поддержка протокола FTP была отключена в Google Chrome ( начиная с версии 88), ^[4], а также отключена в других основных браузерах, таких как Firefox (начиная с версии 88.0). ^[5]

История FTP-серверов [ править ]

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

Обзор протокола [ править ]

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

FTP может работать в активном или пассивном режиме, который определяет, как устанавливается соединение для передачи данных. ^[7] (Этот смысл «режима» отличается от значения команды MODE в протоколе FTP и вместо этого соответствует командам PORT / PASV / EPSV / etc.) В обоих случаях клиент создает управляющее соединение TCP из случайным образом , как правило , непривилегированный , порт Н на командный порт 21 сервера FTP.

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

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

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

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

Обход NAT и брандмауэра [ править ]

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

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

Типы данных [ править ]

При передаче данных по сети определяются четыре типа данных: ^{[2] [3] [6]}

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

Интернет-черновик с истекшим сроком действия определил ТИП U для передачи текстовых файлов Unicode с использованием UTF-8 ; ^[12] хотя проект так и не стал 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 все еще используется в приложениях для передачи файлов на мэйнфреймах и мини-компьютерах.

Режимы передачи данных [ править ]

Передача данных может осуществляться в любом из трех режимов: ^{[1] [2]}

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

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

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

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

Дополнительные команды [ править ]

Более поздние реализации FTP поддерживают команду Modify Fact: Modification Time (MFMT), которая позволяет клиенту настраивать этот атрибут файла удаленно, обеспечивая сохранение этого атрибута при загрузке файлов. ^{[16] [17]}

Чтобы получить временную метку удаленного файла, есть команда MDTM . Некоторые серверы (и клиенты) поддерживают нестандартный синтаксис команды MDTM с двумя аргументами, которая работает так же, как MFMT ^[18]

Войти [ редактировать ]

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

Анонимный FTP [ править ]

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

Отличия от HTTP [ править ]

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

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

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

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

Поддержка веб-браузера [ править ]

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

С 2019 года основные браузеры, такие как Chrome и Firefox, в разной степени отказываются от поддержки FTP. ^[22] Google полностью удалил его в Chrome 88. ^[23] По состоянию на 2019 год Mozilla обсуждала предложения, включая удаление поддержки только старых реализаций FTP, которые больше не используются, для упрощения их кода. ^{[24] [25]} По состоянию на апрель 2021 года и в Firefox Release 88.0 Mozilla отключила поддержку FTP для Firefox и планировала полностью удалить ее в более позднем выпуске. ^[26]

Синтаксис [ править ]

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

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

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

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

Безопасность [ править ]

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

• Атака грубой силой
• Атака с отказом FTP
• Захват пакетов
• Кража порта (угадывание следующего открытого порта и узурпация законного соединения)
• Атака спуфингом
• Перечисление имени пользователя
• DoS или DDoS

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

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

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

FTP через SSH [ править ]

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

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

• Tectia ConnectSecure (Win / Linux / Unix) ^[31] из SSH Communications Security пакет программного обеспечения «s

Производные [ править ]

FTPS [ править ]

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

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

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

Тривиальный протокол передачи файлов [ править ]

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

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

Простой протокол передачи файлов (первый протокол, сокращенно 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 - Подключения. Ответы, относящиеся к управляющим и информационным соединениям.
• 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.

Внешние ссылки [ править ]

• Сети связи / Протокол передачи файлов в Викиучебнике
• Интернет-тестер FTP-сервера Аутентификация, шифрование, режим и возможность подключения.
• Анонимные FTP-серверы по TLD с кодом страны (2012 г.): «Необычный Интернет - Общий доступ - FTP» . www.jumpjet.info . 2012 . Проверено 16 января 2020 года .