Протокол связи | |
Цель | Передача файлов |
---|---|
Разработчики) | Абхай Бхушан для RFC 959 |
Введено | 16 апреля 1971 г . |
Слой OSI | Уровень приложения |
Порт (ы) | 21 для управления, 20 для передачи данных |
RFC (ы) | RFC 959 |
Набор интернет-протоколов |
---|
Уровень приложения |
Транспортный уровень |
Интернет-уровень |
Связующий слой |
|
Протокол передачи файлов ( 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] В июле 2021 года Firefox 90 полностью отказался от FTP. [6]
Первоначальная спецификация протокола передачи файлов была написана Абхаем Бхушаном и опубликована как 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 и определяет новый тип пассивного режима. [7]
FTP может работать в активном или пассивном режиме, который определяет, как устанавливается соединение для передачи данных. [8] (Этот смысл "режима" отличается от значения команды MODE в протоколе FTP и вместо этого соответствует командам PORT / PASV / EPSV / etc.) В обоих случаях клиент создает управляющее соединение TCP из случайным образом , как правило , непривилегированный , порт Н на командный порт 21 сервера FTP.
Оба режима были обновлены в сентябре 1998 года для поддержки IPv6 . В то время были внесены дальнейшие изменения в пассивный режим, обновив его до расширенного пассивного режима . [10]
Сервер отвечает через управляющее соединение трехзначными кодами состояния в ASCII с дополнительным текстовым сообщением. Например, «200» (или «200 OK») означает, что последняя команда была успешной. Цифры представляют собой код ответа, а необязательный текст представляет понятное человеку объяснение или запрос (например, <Требуется учетная запись для хранения файла>). [1] Текущая передача данных файла по соединению для передачи данных может быть прервана с помощью сообщения прерывания, отправленного по управляющему соединению.
FTP требуется два порта (один для отправки и один для приема), потому что он изначально был разработан для работы с программой управления сетью (NCP), которая была симплексным протоколом, который использовал два адреса порта , устанавливая два соединения для двусторонней связи. Нечетным и четным порт были зарезервированы для каждого слоя приложения приложения или протокола. Стандартизация TCP и UDP снизила потребность в использовании двух симплексных портов для каждого приложения до одного дуплексного порта, [11] : 15 но протокол FTP никогда не изменялся для использования только одного порта и продолжал использовать два для обратной совместимости. .
FTP обычно передает данные путем обратного подключения сервера к клиенту после того, как клиент отправляет команду PORT. Это проблематично как для NAT, так и для брандмауэров, которые не разрешают подключения из Интернета к внутренним узлам. [12] Для NAT дополнительная сложность заключается в том, что представление IP-адресов и номера порта в команде PORT относится к IP-адресу и порту внутреннего хоста, а не к общедоступному IP-адресу и порту NAT.
Есть два подхода к решению этой проблемы. Один из них заключается в том, что FTP-клиент и FTP-сервер используют команду PASV, которая устанавливает соединение для передачи данных от FTP-клиента к серверу. [12] Это широко используется современными FTP-клиентами. Другой подход состоит в том, что NAT изменяет значения команды PORT, используя для этой цели шлюз уровня приложения . [12]
При передаче данных по сети определяются четыре типа данных: [2] [3] [7]
Интернет-черновик с истекшим сроком действия определил ТИП U для передачи текстовых файлов Unicode с использованием UTF-8 ; [13] хотя проект так и не стал RFC, он был реализован несколькими FTP-клиентами / серверами.
Обратите внимание, что эти типы данных обычно называются «режимами», хотя неоднозначно это слово также используется для обозначения активного и пассивного режима связи (см. Выше) и режимов, устанавливаемых командой MODE протокола FTP (см. Ниже).
Для текстовых файлов (TYPE A и TYPE E) предусмотрены три различных параметра управления форматом, чтобы контролировать, как файл будет напечатан:
Эти форматы в основном относились к линейным принтерам ; большинство современных FTP-клиентов / серверов поддерживают только стандартное управление форматом N.
Файловая организация указывается с помощью команды STRU. Следующие файловые структуры определены в разделе 3.1.1 RFC959:
Большинство современных FTP-клиентов и серверов поддерживают только STRU F. STRU R все еще используется в приложениях для передачи файлов на мэйнфреймах и мини-компьютерах.
Передача данных может осуществляться в любом из трех режимов: [1] [2]
Большинство современных FTP-клиентов и серверов не поддерживают РЕЖИМ B или РЕЖИМ C; Исключением являются FTP-клиенты и серверы для операционных систем мэйнфреймов и миникомпьютеров.
Некоторое программное обеспечение FTP также реализует режим сжатия на основе DEFLATE , который иногда называют «Режим Z» после команды, которая его включает. Этот режим был описан в Интернет-проекте , но не стандартизирован. [14]
GridFTP определяет дополнительные режимы MODE E [15] и MODE X, [16] как расширения MODE B.
Более поздние реализации FTP поддерживают команду Modify Fact: Modification Time (MFMT), которая позволяет клиенту настраивать этот атрибут файла удаленно, обеспечивая сохранение этого атрибута при загрузке файлов. [17] [18]
Чтобы получить временную метку удаленного файла, есть команда MDTM . Некоторые серверы (и клиенты) поддерживают нестандартный синтаксис команды MDTM с двумя аргументами, которая работает так же, как MFMT [19]
Для входа в систему FTP используется обычная схема имени пользователя и пароля для предоставления доступа. [2] Имя пользователя отправляется на сервер с помощью команды USER, а пароль отправляется с помощью команды PASS. [2] Эта последовательность не зашифрована «на проводе», поэтому может быть уязвима для атаки сетевого сниффинга . [20] Если информация, предоставленная клиентом, принимается сервером, сервер отправляет приветствие клиенту, и сеанс начинается. [2] Если сервер поддерживает это, пользователи могут войти в систему без предоставления учетных данных, но тот же сервер может разрешить только ограниченный доступ для таких сеансов. [2]
Хост, предоставляющий службу FTP, может предоставлять анонимный доступ по FTP. [2] Пользователи обычно входят в службу с «анонимной» (строчной и чувствительной к регистру на некоторых FTP-серверах) учетной записью при запросе имени пользователя. Хотя пользователей обычно просят отправить свой адрес электронной почты вместо пароля, [3] на самом деле проверка предоставленных данных не выполняется. [21] Многие FTP-узлы, предназначенные для предоставления обновлений программного обеспечения, допускают анонимный вход. [3]
HTTP по существу исправляет ошибки в FTP, из-за которых его было неудобно использовать для многих небольших эфемерных передач, которые типичны для веб-страниц.
FTP имеет управляющее соединение с отслеживанием состояния, которое поддерживает текущий рабочий каталог и другие флаги, и для каждой передачи требуется вторичное соединение, через которое передаются данные. В «пассивном» режиме это вторичное соединение от клиента к серверу, тогда как в «активном» режиме по умолчанию это соединение от сервера к клиенту. Эта очевидная смена ролей в активном режиме и случайные номера портов для всех передач - вот почему межсетевые экраны и шлюзы NAT так тяжело работают с FTP. HTTP не имеет состояния и мультиплексирует управление и данные через одно соединение от клиента к серверу на хорошо известных номерах портов, которые тривиально проходят через шлюзы NAT и просты для управления брандмауэрами.
Настройка управляющего соединения FTP происходит довольно медленно из-за задержек отправки всех необходимых команд и ожидания ответов в оба конца, поэтому обычно создается управляющее соединение и удерживается его открытым для передачи нескольких файлов, а не отбрасывается и повторно -установить сеанс каждый раз заново. Напротив, HTTP изначально сбрасывал соединение после каждой передачи, потому что это было очень дешево. Хотя впоследствии HTTP получил возможность повторно использовать TCP-соединение для множественных передач, концептуальная модель по-прежнему представляет собой независимые запросы, а не сеанс.
Когда FTP передает данные через соединение для передачи данных, контрольное соединение не используется. Если передача занимает слишком много времени, брандмауэр или NAT могут решить, что контрольное соединение не работает, и прекратить его отслеживание, фактически разорвав соединение и запутав загрузку. Одиночное HTTP-соединение простаивает только между запросами, и это нормально и ожидается, что такие соединения будут сброшены после тайм-аута.
Большинство распространенных веб-браузеров могут получать файлы, размещенные на FTP-серверах, хотя они могут не поддерживать расширения протокола, такие как FTPS . [3] [22] Когда предоставляется URL-адрес FTP, а не HTTP , доступное содержимое на удаленном сервере представляется таким же образом, как и для другого веб-содержимого. Полнофункциональный FTP-клиент может быть запущен в Firefox в виде расширения под названием FireFTP .
Google Chrome полностью удалил поддержку FTP в Chrome 88. [23] В 2019 году Mozilla обсуждала предложения, включая удаление поддержки только старых реализаций FTP, которые больше не используются, для упрощения их кода. [24] [25] В апреле 2021 года Mozilla выпустила Firefox 88.0, в котором по умолчанию отключена поддержка FTP. [26] В июле 2021 года Firefox 90 полностью отказался от поддержки FTP. [6]
Синтаксис 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 не шифрует свой трафик; все передачи выполняются в виде открытого текста, а имена пользователей, пароли, команды и данные могут быть прочитаны любым, кто может выполнять захват ( анализ ) пакетов в сети. [2] [30] Эта проблема является общей для многих спецификаций Интернет-протоколов (таких как SMTP , Telnet , POP и IMAP ), которые были разработаны до создания механизмов шифрования, таких как TLS или SSL. [7]
Общие решения этой проблемы включают:
FTP через SSH - это практика туннелирования обычного сеанса FTP через соединение Secure Shell. [30] Поскольку FTP использует несколько TCP- соединений (что необычно для протокола TCP / IP, который все еще используется), туннелирование через SSH особенно сложно. Со многими клиентами SSH попытка настроить туннель для канала управления (начальное соединение клиент-сервер на порту 21) защитит только этот канал; при передаче данных программное обеспечение FTP на обоих концах устанавливает новые TCP-соединения (каналы данных) и, таким образом, не имеет защиты конфиденциальности или целостности .
В противном случае клиентскому программному обеспечению SSH необходимо иметь специальные знания о протоколе FTP, чтобы отслеживать и перезаписывать сообщения канала управления FTP и автономно открывать новые пересылки пакетов для каналов данных FTP. Программные пакеты, поддерживающие этот режим, включают:
Явный FTPS - это расширение стандарта FTP, которое позволяет клиентам запрашивать шифрование сеансов FTP. Это делается путем отправки команды «AUTH TLS». Сервер может разрешить или запретить соединения, которые не запрашивают TLS. Это расширение протокола определено в RFC 4217 . Неявный FTPS - это устаревший стандарт FTP, который требовал использования SSL или TLS-соединения. Было указано использовать порты, отличные от обычного FTP.
Протокол передачи файлов 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 . Эти коды стандартизированы IETF в RFC 959 . Код ответа представляет собой трехзначное значение. Первая цифра используется для обозначения одного из трех возможных результатов - успеха, неудачи или для обозначения ошибки или неполного ответа:
Вторая цифра определяет вид ошибки:
Третья цифра кода ответа используется для предоставления дополнительных сведений для каждой из категорий, определяемых второй цифрой.