~~~~~~~~~~~~~~~~~~~~ Arc.Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~ 
Номер скриншота №:
✰ D7DDBF6E21A13D9D7598A243A78E3284__1717855560 ✰
Заголовок документа оригинал.:
✰ File Transfer Protocol - Wikipedia ✰
Заголовок документа перевод.:
✰ Протокол передачи файлов — Википедия ✰
Снимок документа находящегося по адресу (URL):
✰ https://en.wikipedia.org/wiki/FTP ✰
Адрес хранения снимка оригинал (URL):
✰ https://arc.ask3.ru/arc/aa/d7/84/d7ddbf6e21a13d9d7598a243a78e3284.html ✰
Адрес хранения снимка перевод (URL):
✰ https://arc.ask3.ru/arc/aa/d7/84/d7ddbf6e21a13d9d7598a243a78e3284__translat.html ✰
Дата и время сохранения документа:
✰ 15.06.2024 20:18:38 (GMT+3, MSK) ✰
Дата и время изменения документа (по данным источника):
✰ 8 June 2024, at 17:06 (UTC). ✰ 

~~~~~~~~~~~~~~~~~~~~~~ Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~~ 
Сервисы Ask3.ru: 
 Архив документов (Снимки документов, в формате HTML, PDF, PNG - подписанные ЭЦП, доказывающие существование документа в момент подписи. Перевод сохраненных документов на русский язык.)https://arc.ask3.ruОтветы на вопросы (Сервис ответов на вопросы, в основном, научной направленности)https://ask3.ru/answer2questionТоварный сопоставитель (Сервис сравнения и выбора товаров) ✰✰
✰ https://ask3.ru/product2collationПартнерыhttps://comrades.ask3.ru


Совет. Чтобы искать на странице, нажмите Ctrl+F или ⌘-F (для MacOS) и введите запрос в поле поиска.
Arc.Ask3.ru: далее начало оригинального документа

Протокол передачи файлов — Википедия Jump to content

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

Из Википедии, бесплатной энциклопедии
(Перенаправлено с FTP )

протокол передачи файлов
Протокол связи
Цель Передача файла
Разработчики) Абхай Бхушан для RFC 114
Введение 16 апреля 1971 г .; 53 года назад ( 1971-04-16 )
Уровень OSI Прикладной уровень
Порт(ы) 21 для управления, 20 для передачи данных
RFC(ы) РФК 959

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

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

FTP-клиент раньше обычно интегрировался в веб-браузеры , где файловые серверы просматриваются с префиксом URI " ftp://". В 2021 году поддержка FTP была прекращена в Google Chrome и Firefox , [4] [5] два основных производителя веб-браузеров, поскольку их заменили более безопасные SFTP и FTPS; хотя ни один из них не реализовал новые протоколы. [6] [7]

История 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 и определяет новый тип пассивного режима. [8]

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

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

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

FTP может работать в активном или пассивном режиме, который определяет способ установления соединения для передачи данных. [9] (Этот смысл «режима» отличается от значения команды MODE в протоколе FTP.)

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

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

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

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

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

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

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

Модельная диаграмма того, как работает FTP

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

При передаче данных по сети определяются пять типов данных: [2] [3] [8]

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

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

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

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

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

Файловые структуры [ править ]

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

  • Структура F или FILE (потоковая). Файлы рассматриваются как произвольная последовательность байтов, символов или слов. Это обычная файловая структура в системах Unix и других системах, таких как CP/M, MS-DOS и Microsoft Windows. (раздел 3.1.1.1)
  • Структура R или RECORD (ориентированная на записи). Файлы рассматриваются как разделенные на записи, которые могут иметь фиксированную или переменную длину. Такая организация файлов распространена в мэйнфреймах и системах среднего уровня, таких как MVS, VM/CMS, OS/400 и VMS, которые поддерживают файловые системы, ориентированные на записи .
  • Структура P или PAGE (странично-ориентированная). Файлы разделены на страницы, которые могут содержать данные или метаданные; каждая страница также может иметь заголовок, дающий различные атрибуты. Данная файловая структура была специально разработана для систем АО «Техснабэкспорт» и, как правило, не поддерживается на других платформах. В разделе 4.1.2.3 RFC1123 рекомендуется не реализовывать эту структуру.

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

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

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

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

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

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

GridFTP определяет дополнительные режимы, MODE E. [17] и РЕЖИМ X, [18] как расширение РЕЖИМА B.

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

Более поздние реализации FTP поддерживают команду «Изменить факт: время модификации» (MFMT), которая позволяет клиенту удаленно настраивать этот атрибут файла , обеспечивая сохранение этого атрибута при загрузке файлов. [19] [20]

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

Войти [ править ]

Компьютер на Южнополярной станции Амундсен-Скотт подключается к FTP-серверу и передает файл, 1994 год.

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

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

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

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

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

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

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

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

Поддержка программного обеспечения [ править ]

Клиент FileZilla, работающий в Windows, один из самых известных программ FTP-клиентов.

Файловые менеджеры [ править ]

Многие файловые менеджеры, как правило, реализуют доступ по FTP, например Проводник (ранее Проводник Windows) в Microsoft Windows . Этот клиент рекомендуется только для передачи небольших файлов с сервера из-за ограничений по сравнению со специальным клиентским программным обеспечением. [24] Он не поддерживает SFTP . [25]

Оба встроенных файловых менеджера KDE в Linux ( Dolphin и Konqueror ) поддерживают как FTP, так и SFTP. [26] [27]

Примитивный FTPd на Android, активно работающий FTP и SFTP-сервер.

В Android файловый менеджер «Мои файлы» на Samsung Galaxy имеет встроенный клиент FTP и SFTP . [28]

Веб-браузер [ править ]

В течение долгого времени большинство распространенных веб-браузеров могли получать файлы, размещенные на FTP-серверах, хотя не все из них поддерживали расширения протокола, такие как FTPS . [3] [29] FTP, а не HTTP Если указан URL-адрес , доступное содержимое на удаленном сервере представляется таким же образом, как и для другого веб-содержимого.

Google Chrome полностью удалил поддержку FTP в Chrome 88, что также затронуло другие браузеры на базе Chromium , такие как Microsoft Edge . [30] В Firefox 88 по умолчанию отключена поддержка FTP, а в Firefox 90 поддержка полностью прекращена. [31] [4]

FireFTP — это прекращенное расширение браузера, которое было разработано как полнофункциональный FTP-клиент для запуска в Firefox , но когда Firefox отказался от поддержки FTP, разработчик расширения рекомендовал использовать Waterfox . [32] Некоторые браузеры, такие как текстовый Lynx , по-прежнему поддерживают FTP. [33]

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

Синтаксис 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 [34] и Интернет Эксплорер [35] ). По умолчанию большинство веб-браузеров используют пассивный режим (PASV), который легче преодолевает брандмауэры конечных пользователей.

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

Менеджер загрузок [ править ]

Большинство распространенных менеджеров загрузки могут получать файлы, размещенные на FTP-серверах, а некоторые из них также предоставляют интерфейс для получения файлов, размещенных на FTP-серверах. DownloadStudio позволяет не только скачать файл с FTP-сервера, но и просмотреть список файлов на FTP-сервере. [37]

Другое [ править ]

LibreOffice объявил, что поддержка FTP устарела с версии 7.4, позже она была удалена в версии 24.2. [38] [39]

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

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

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

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

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

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

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

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

FTP через SSH не следует путать с протоколом передачи файлов SSH (SFTP).

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

FTPS [ править ]

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

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

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

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

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

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

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

FTP-команды [ править ]

Коды ответа FTP [ править ]

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

  • 2yz – успешный ответ
  • 4yz или 5yz – ответ об ошибке
  • 1yz или 3yz — ошибка или неполный ответ.

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

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

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

См. также [ править ]

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

  1. ^ Перейти обратно: а б с Форузан, бакалавр (2000). TCP/IP: Набор протоколов (1-е изд.). Нью-Дели, Индия: Tata McGraw-Hill Publishing Company Limited.
  2. ^ Перейти обратно: а б с д Это ж г час я дж Козерок, Чарльз М. (2005). «Руководство по TCP/IP версии 3.0» . Tcpipguide.com.
  3. ^ Перейти обратно: а б с д Это Дин, Тамара (2010). Network+ Руководство по сетям . Дельмар. стр. 168–171.
  4. ^ Перейти обратно: а б Вонау, Мануэль (7 июля 2021 г.). «Firefox идет по стопам Chrome и отказывается от поддержки FTP (загрузка APK)» . Андроид Полиция . Проверено 12 июля 2021 г.
  5. ^ «Удалить поддержку FTP – Статус платформы Chrome» . www.chromestatus.com . Проверено 2 сентября 2021 г.
  6. ^ автор, Написано (23 марта 2020 г.). «Firefox прекращает поддержку FTP» . Новости Софоса . Проверено 13 октября 2023 г.
  7. ^ Эдвардс, Бендж (14 июля 2022 г.). «Chrome и Firefox прекратили поддержку FTP: вот простая альтернатива» . Как компьютерщик . Проверено 13 октября 2023 г.
  8. ^ Перейти обратно: а б с д Кларк, член парламента (2003). Сети передачи данных IP и Интернет (1-е изд.). Западный Суссекс, Англия: John Wiley & Sons Ltd.
  9. ^ Перейти обратно: а б «Активный FTP против пассивного FTP: подробное объяснение» . Слаксайт.com.
  10. ^ Вайс, Ольга (18 октября 2022 г.). «Порт FTP: Полное руководство по FTP и номерам портов» . Комплексные программные приложения для Mac . Проверено 29 марта 2024 г.
  11. ^ RFC   959 (стандартный) Протокол передачи файлов (FTP). Постел Дж. и Рейнольдс Дж. (октябрь 1985 г.).
  12. ^ Расширения RFC   2428 (предлагаемый стандарт) для IPv6, NAT и расширенного пассивного режима. Оллман М., Мец К. и Остерманн С. (сентябрь 1998 г.).
  13. ^ Стивенс, В. Ричард (1994). TCP/IP, иллюстрированный том I. Том. 1. Ридинг, Массачусетс, США: Издательство Addison-Wesley. ISBN  0-201-63346-9 .
  14. ^ Перейти обратно: а б с Глисон, Майк (2005). «Протокол передачи файлов и ваш брандмауэр/NAT» . Ncftp.com.
  15. ^ Кленсин, Джон. Расширение FTP TYPE для интернационализированного текста . Идентификатор Draft-klensin-ftpext-typeu-00 . Проверено 9 июня 2020 г.
  16. ^ Престон, Дж. (январь 2005 г.). Режим передачи Deflate для FTP . IETF . Идентификатор черновика-preston-ftpext-deflate-03 . Проверено 27 января 2016 г.
  17. ^ Олкок, В. (апрель 2003 г.). «GridFTP: расширения протокола FTP для Grid» (PDF) .
  18. ^ Мандриченко И. (4 мая 2005 г.). «Описание протокола GridFTP v2» (PDF) .
  19. ^ «Команда FTP MFMT» . support.solarwinds.com . 11 октября 2018 г.
  20. ^ «Команды FTP: DSIZ, MFCT, MFMT, AVBL, PASS, XPWD, XMKD | Serv-U» . www.serv-u.com .
  21. ^ «Команда FTP MDTM» . support.solarwinds.com . 11 октября 2018 г.
  22. ^ Принс, Брайан (24 января 2012 г.). «Следует ли организациям отказаться от использования FTP в целях безопасности?» . Неделя безопасности . Проверено 14 сентября 2017 г.
  23. ^ RFC   1635 (информационный) Как использовать анонимный FTP. П. и Эмтаж А. и Марин А. (май 1994 г.).
  24. ^ FTP-доступ через проводник Windows.
  25. ^ «CSC373/406: SSH [27-29 марта 2011 г.]» . fpl.cs.depaul.edu . Проверено 13 октября 2023 г.
  26. ^ «ФТП» . docs.kde.org . Проверено 13 октября 2023 г.
  27. ^ Коэн, Брент (26 июля 2023 г.). «Как подключиться к FTP/SFTP в Dolphin | DeviceTests» . Проверено 13 октября 2023 г.
  28. ^ Персонал, Мойенс (28 февраля 2022 г.). «Samsung My Files против Google Files: какой файловый менеджер лучше на телефонах Galaxy» . Мойенс ввода-вывода . Проверено 13 октября 2023 г.
  29. ^ Мэтьюз, Дж. (2005). Компьютерные сети: Интернет-протоколы в действии (1-е изд.). Дэнверс, Массачусетс: John Wiley & Sons Inc.
  30. ^ Снеддон, Джоуи (26 января 2021 г.). «Сводка новостей о выпусках Linux: GParted, Lightworks, Google Chrome и многое другое» . omgubuntu.co.uk . Проверено 30 января 2021 г.
  31. ^ «Посмотрите, что нового в Firefox: выпуск Firefox 88.0» . сайт mozilla.org . 19 апреля 2021 г. Проверено 20 апреля 2021 г.
  32. ^ «FireFTP — бесплатный FTP-клиент для Waterfox» . FireFTP.net . Архивировано из оригинала 1 марта 2022 года.
  33. ^ «Схемы URL-адресов, поддерживаемые в Lynx» . Сайт Линкс . Проверено 6 июля 2023 г.
  34. ^ «Доступ к FTP-серверам | Как | Справка Firefox» . Поддержка.mozilla.com. 5 сентября 2012 года . Проверено 16 января 2013 г.
  35. ^ «Как ввести пароль FTP-сайта в Internet Explorer» . Архивировано из оригинала 2 июля 2015 года . Проверено 13 февраля 2020 г. . {{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка ) Написано для IE версии 6 и более ранних. Возможно, будет работать с более новыми версиями.
  36. ^ Юкка «Юкка» Корпела (18 сентября 1997 г.). «FTP-URL-адреса» . «ИТ и связь» (jkorpela.fi) . Проверено 26 января 2020 г. .
  37. ^ «DownloadStudio — Менеджер загрузок через Интернет и ускоритель загрузок — Возможности» . Задумать . Проверено 19 октября 2021 г.
  38. ^ «LibreOffice 7.4: Примечания к выпуску» . Вики Document Foundation . Проверено 10 сентября 2022 г.
  39. ^ «Примечания к выпуску/24.2» . Вики Document Foundation . Проверено 24 марта 2024 г.
  40. ^ Перейти обратно: а б с «Защита FTP с помощью SSH» . Nurdletech.com.
  41. ^ «Компоненты платформы обеспечения безопасности информации (раздел Tectia ConnectSecure)» . ssh.com . Архивировано из оригинала 31 июля 2020 года.

Дальнейшее чтение [ править ]

  • 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.

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

Arc.Ask3.Ru: конец оригинального документа.
Arc.Ask3.Ru
Номер скриншота №: D7DDBF6E21A13D9D7598A243A78E3284__1717855560
URL1:https://en.wikipedia.org/wiki/FTP
Заголовок, (Title) документа по адресу, URL1:
File Transfer Protocol - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть, любые претензии не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, денежную единицу можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)