Сценарий ftp соединения

File Transfer Protocol, или протокол передачи файлов, — это протокол, относящийся к прикладному уровню и отвечающий за передачу данных между двумя системами. Как и протокол HTTP, он работает поверх протокола TCP. При передаче файлов FTP использует одновременно два TCP-канала: один из них отвечает за управление передачей данных, а второй — передает их.

Первоначально протокол FTP использовался как способ связи и обмена информацией между двумя физическими устройствами. Его могут использовать как компании, так и обычные пользователи для переноса данных с одной компьютерной системы на другую. Также протокол полезен в работе с веб-сайтами — для загрузки или выгрузки файлов с серверов.

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

При установлении FTP-соединения создаются два типа каналов связи, которые называются канал команд и канал данных.

Командный канал требуется для:

• передачи сообщений о тех или иных действиях
• ответов между клиентом и сервером (и наоборот).

Протокол FTP применяет тот же подход, что TELNET и SMTP, для связи посредством управляющего соединения. Для этого используется набор символов NVT ASCII. Общение осуществляется через порт 21.

Канал данных используется непосредственно для передачи информации и работает через порт 20.

FTP-клиент, применяя URL в качестве адреса (как и протоколы передачи гипертекста HTTP/S), посылает команду FTP и адрес клиента. После установки соединения пользователь выполняет авторизацию, вводя логин и пароль.

В зависимости от настроек сервера пользователь может получить к нему доступ без логина и пароля. Данная форма авторизации называется «Анонимный FTP». В таком случае на сервере заранее создана специальная учетная запись, которая разрешает авторизацию при любых данных, внесенных в поле пароля. После этого со стороны сервера выполняется проверка введенных данных и выдается разрешение/запрет на действия с данными. Клиент/Сервер обмениваются нужными файлами, после чего происходит выход из соединения.

Как выглядит FTP в графическом интерфейсе ОС

Для взаимодействия с удаленным сервером можно использовать либо командную строку (терминал), либо специализированные приложения. В Windows интерфейс выглядит следующим образом:

При работе через приложение взаимодействие с файлами становится гораздо проще благодаря понятности и удобства интерфейса. На скриншоте ниже — пример интерфейса приложения FileZilla:

Описание команд FTP для командной строки Windows и Linux

Эти команды помогут использовать протокол FTP через консольную строку без сторонних приложений.

ftp> *команда*

Больше — по ссылке. Те же команды актуальны для работы в ОС Linux.

Какие сервисы лучше использовать для FTP-протокола

• FileZilla — это бесплатная FTP-утилита с открытым исходным кодом, которая дает пользователю возможность передавать файлы с локального компьютера на удаленный. FileZilla доступна в виде клиентской и серверной версий. Работает под ОС Windows, MacOS и Linux.
• WinSCP — это бесплатный SFTP-, WebDAV-, S3-, SCP- и FTP-клиент для Windows с открытым исходным кодом. Работает только на ОС Windows.
• Cyberduck — это FTP-клиент с бесплатными облачными возможностями и поддержкой систем Windows и Mac OS X. Cyberduck использует графический интерфейс пользователя (GUI) для предоставления доступа к файлам с серверов и для иного управления данными в различных местах, включая их редактирование и хранение.
• Transmit — это приложение для MacOS, позволяющее работать с FTP, SFTP и множеством других протоколов. Отличается удобным дизайном и высокой скоростью работы.
• CrossFTP — это приложение для ОС Windows, MacOS и Linux, поддерживающее множество протоколов, включая WebDav, SFTP, Amazon S3 и прочие.
• Nautilus — это менеджер файлов для ОС Linux, работающих на основе окружения Gnome. Основным его плюсом является то, что он уже встроен в систему. Позволяет работать с протоколами FTP(S), SMB, NFS, SSH и прочими.
• AndFTP — популярный FTP-клиент для ОС Android. Обладает несколько нагруженным интерфейсом, однако он дает пользователю те же функции, что и полноценные десктопные приложения.
• X-plore File Manager — это FTP-клиент для ОС Android, аналог AndFTP.
• FTP-manager — это FTP-клиент для iOS, позволяющий копировать, перемещать и удалять файлы между устройством и сервером. Плюсами данного приложения является возможность использовать многооконность на iPad, просматривать различные типы файлов на устройстве, а также вносить изменения в код через специальный редактор.

В чем назначение безопасного FTP-протокола

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

Однако существует несколько общих принципов, позволяющие обеспечить безопасное использование протокола, — FTPS  и SFTP.

FTPS

FTPS, или FTP с использование Secure Socket Layer, — это метод, который позволяет выполнять шифрование соединения по требованию пользователя. FTPS был предложен в качестве альтернативы в RFC 2228.

FTPS был введен на серверах Windows, начиная с IIS 7.0. IIS, или Internet Information Services, — набор инструментов Windows, позволяющих развертывать web-сервер.

В IIS 7.0 FTPS-протокол был автономным дополнительным элементом и требовал отдельной загрузки. IIS 7.5 и каждая последующая версия имеют функциональность FTPS из «коробки». Следовательно, чтобы настроить безопасное FTP-соединение, необходимо установить только IIS Manager и/или FTP-сервис, который входит в пакет IIS.

Как работает FTPS

Как и FTP, FTPS работает по модели клиент-сервер, используя канал управления и канал передачи данных для обмена командами FTP и данными во время клиентского сеанса FTPS.

Сессия FTPS аутентифицируется при помощи логина, пароля и сертификата открытого ключа (аналогично тому, как работает  HTTPS). Инструменты, такие как OpenSSL, позволяют запрашивать и создавать сертификат ключа. При соединении с сервером FTPS клиент сначала проверяет надежность сертификата сервера, после чего осуществляет подключение. Когда доверенный центр сертификации (CA) подписывает эти сертификаты, он гарантирует, что клиент подключен к надежному и безопасному серверу. Это помогает защититься от ряда атак, в том числе от атак посредника.

Сертификаты, не подписанные СА, которые известны как самозаверяющие сертификаты, могут побудить клиента FTPS создать уведомление о том, что сертификат не является подлинным. После этого пользователь может либо подтвердить действие и осуществить подключение или отклонить его.

FTPS (через SSL) использует сертификаты X.509 для аутентификации. Эти цифровые сертификаты содержат в себе открытый ключ шифрования и информацию о том, кто является его владельцем. Открытый ключ выполняет две основные функции: проверку подлинности и шифрование данных. Открытый ключ имеет связанный с ним закрытый ключ. Он находится отдельно от открытого ключа, и его главное предназначение — расшифровка сообщений, зашифрованных при помощи открытого ключа.

SFTP

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

Больше об SSH-ключах →

Как создать сетевой FTP-протокол  для Windows

Шаг 1. Активация встроенного в ОС FTP-протокола

Для создания FTP-сервера на Windows потребуется выполнить несколько действий.

Мы сделаем это через Панель управления. Найдите ее в режиме поиска.

 Далее перейти в пункт Программы → Программы и компоненты:

В открывшемся окне следует нажать на пункт Включение или отключение компонентов Windows:

Далее в списке найдите пункт Службы IIS и включите пункты FTP-сервер (Расширяемость FTP и Служба FTP), а также пункт Сценарии и средства управления IIS:

Шаг 2. Создание сервера

Для создания собственного сервера следует перейти на главную страницу Панель управления, выбрать раздел Система и безопасность, где выбрать пункт Администрирование:

Далее требуется выбрать Диспетчер служб IIS ( если он не появляется, отметьте все поля в Службы IIS и перезагрузите компьютер):

В левой части окна нажмите правой кнопкой мыши и выберите Добавить веб-сайт. У вас появится следующее окно:

Далее нажмите правой кнопкой мыши по созданному сайту и выберите Добавить FTP-публикацию:

После этого заполните поля в соответствии с вашими требованиями, указав порт 21:

Как создать FTP-сервер на Linux

Для создания FTP-сервера на Linux (дистрибутив Ubuntu) следуйте данному алгоритму:

1. Обновление ОС. Для выполнения этого шага введите следующую команду: sudo apt update.
2. Установка vsftpd (FTP-сервера). Для выполнения введите следующую команду: sudo apt intall vsftpd.
3. Проверка работоспособности сервера. Для этого введите следующую команду: sudo systemctl status vsftpd. В случае успешной установки в терминале будет выведено active (running).
4. Добавление службы в автозагрузку. Для выполнения используйте следующую команду: sudo systemctl enable vsftpd.

А что с MacOS?

С компьютерами на MacOS ситуация обстоит несколько другим образом. Начиная с MacOS Sierra (вышла в 2016 г.) сервис FTP был полностью удален из ОС.

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

Разница работы с FTP и HTTP

Мы уже упоминали об этих двух протоколах в контексте статьи. Оба работают поверх TCP — самого известного транспортного протоколы. Тем не менее между ними много различий. Рассмотрим основные.

Нужен ли FTP-протокол в наши дни

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

Доказательством этого становятся отказы от использования протокола. Как это сделали MacOS или браузер Chrome, разработчики которого удалили поддержку протокола в версии Chrome 95. Впрочем, FTP все еще остается востребованным для локальных целей, а также для доступа к различных старым интернет-архивам.

FTP (File Transfer Protocol) представляет собой протокол удаленной передачи файлов. С его помощью можно загрузить на сервер и скачивать с него же данные любого типа и размера, создавать или удалять файлы и папки.

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

Данные для доступа к FTP-серверу

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

Теперь о том, какие данные необходимо иметь под рукой:

• логин,
• пароль,
• ссылка на FTP-сервер (указывается в том же письме),
• порт (по умолчанию устанавливается значение 21).

Как подключится к FTP через Проводник Windows

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

В результате откроется окно мастера добавления сетевого расположения. В начальном окне просто нажимаем «Далее».

Следом надо выбрать его дальнейшее местоположение, но в этом окне нам доступен только один вариант. Для продолжения снова нажимаем на кнопку «Далее».

В этом окне понадобится указать ссылку на сетевой ресурс, к которому планируется провести подсоединение. Важно соблюдать предписанный формат (чуть ниже есть несколько примеров). В поле вводим адрес/ссылку и вновь идем дальше.  

Теперь понадобится ввести в поле имя пользователя. Пароль заранее вводить не нужно, он будет запрашиваться только при подключении. Если на вашем хосте есть такая возможность, вход можно осуществить анонимно, отметив соответствующую галочку.

В самом конце даем название новому сетевому окружению.

На этом настройка завершена. При необходимости можно поставить галочку, чтобы сразу после нажатия на кнопку «Готово» открыть указанный сервер и приступить к работе.

Новое подключение теперь находится в «Сетевых расположениях» в разделе «Этот компьютер».

Теперь подключаемся – открываем только что созданное соединение. Открывается маленькое окошко, где мы вводим пароль, затем жмем на кнопку «Вход».

Если все данные введены успешно, откроется папка сервера. Можно приступать к работе.

Подключение через командную строку Windows

Теперь расскажу, как подключиться к FTP-серверу в Windows с помощью командной строки. Этот способ многим может показаться не очень удобным, потому что вручную придется вбивать команды на загрузку документов, открытие папок и их скачивание. А для входа следуем указанной ниже последовательности.

1.     Вводим команду ftp и жмем на клавишу Enter для подтверждения.
2.     Задаем команду open наименование_ftp_хоста.
3.     Вводим логин пользователя. Можно осуществить анонимный вход, просто введя Anonymous.
4.     Вбиваем пароль. В случае с анонимом оставляем это поле пустым и жмем снова Enter.

Теперь подробнее по командам:

•       dir – просмотр содержимого сервера.
•       cd «имя_папки» – открытие указанной папки.
•       put «путь_к_файлу» – загрузка этого документа с компьютера на сервер.
•       get «наименование_файла.формат» – скачивание с хоста на компьютер.
•       quit – отключение от FTP-сервера.

FTP-подключение через любой браузер

Подключиться к FTP-серверу можно и через браузер на любых операционных системах. В таком случае будет доступна лишь часть функций. Необходимо ввести в адресной строке IP-адрес хоста, только с добавлением приставки «ftp://». Нажимаем на клавишу Enter. Дальше потребуется ввести имя пользователя и пароль, а потом нажать на кнопку «Вход».

Как подключиться к FTP с помощью FileZilla

FileZilla – наиболее востребованный и рекомендуемый FTP-клиент, бесплатный и простой в использовании. Подключиться к FTP-серверу через FileZilla можно вне зависимости от операционной системы, установленной на компьютере.

Сперва потребуется скачать приложение на официальном сайте. Есть версии для Linux, Windows (портативная и установочная) и macOS. Просто выбираем нужный вариант и жмем по нему для начала закачки.

Устанавливаем приложение и открываем его. В верхней панели вводим следующую информацию:

•       Хост. Это может быть IP-адрес или ссылка.
•       Логин пользователя, предварительно высланный на почту сервисом.
•       Пароль.
•       Порт. Оставляем пустым или устанавливаем значение 21. 

После того как все нужные поля будут заполнены, нажимаем на кнопку «Быстрое соединение».

После открытия каталога можно приступать к загрузке и скачиванию необходимых данных. Чтобы не вводить каждый раз данные для подключения, следует воспользоваться менеджером сайтов, который доступен в меню «Файл».

Подключаемся с помощью Total Commander

Вам потребуется скачать и установить приложение Total Commander. Рекомендуем делать это с официального сайта. После завершения установки открываем приложение. Переходим во вкладку «Сеть» и выбираем там пункт «Соединиться с FTP-сервером». Для этого действия, кстати, предусмотрена комбинация горячих клавиш – Ctrl + F.

В новом окне нажимаем на кнопку «Добавить». Дальше вводим имя нового соединения, адрес хоста, учетную запись и пароль. Нажимаем на кнопку ОК, чтобы сохранить всю введенную информацию.

Новое подключение отразится в списке. Остается только соединиться с сервером, нажав на соответствующую кнопку.

Как подключиться к FTP-серверу через терминал Linux

В Linux к FTP можно подключиться через системное приложение «Терминал». Это очень похоже на использование командной строки в Windows. Последовательность абсолютно та же – набираем команду ftp и активируем ее нажатием на кнопку Enter. Потом пишем open ссылка_на_хост. Не забываем, что затем надо указать логин и пароль.

Вот примеры доступных опций:

•       Is – отображение списка файлов и папок.
•       get – скачивание файла.
•       mget – скачивание документов определенного формата. Например, mget * – все данные в каталоге, mget *, php – файлы формата php.
•       put – загрузка файла на ресурс.
•       mput – загрузка нескольких документов единого формата.
•       mkdir – создание нового каталога.
•       rmdir – удаление каталога.
•       delete – удаление файла.
•       bye – завершение работы.
•       close – выход из текущего сеанса и возврат в контекст командной строки FTP.
•       status – отображение статуса FTP клиента.

В Linux предусмотрен и другой вариант подключения к FTP. Сначала надо установить нужный пакет, дав вот такой запрос:

sudo apt-get install curlftpfs

Следом нужно предоставить права на определенную папку:

sudo chmod 777 ~/ftp

Теперь производится монтирование ftp-директории:

sudo curlftpfs -o allow_other ftp://user: password@server.ru /home/virtdiver/ftp/

Если работать необходимо от имени пользователя, то вводится вот такая опция:

-o allow_other

Для размонтирования FTP-папки используем такую команду:

sudo umount ~/ftp

Подключение к FTP через сайт хостинга

В этом случае достаточно лишь войти на сайт хостинга и перейти в соответствующий раздел. Покажу на примере Timeweb.

В правой части окна есть панель управления. Находим в ней пункт «Файловый менеджер» и жмем по нему. Перед нами предстанет веб-интерфейс FTP-сервера. Работать с ним очень просто, переносить файлы можно посредством drag-n-drop. 

Заключение

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

Способ третий: командная строка DOS

Утилиту «ftp.exe», входящую в состав Windows по умолчанию, можно запустить из командной строки. Она позволяет скачивать и загружать файлы по протоколу FTP вручную, но главное ее достоинство — функции автоматизации. С ее помощью можно запланировать и автоматизировать передачу файлов по FTP на регулярной основе.

Чтобы получить справку по утилите FTP, введите в командной строке ftp -? и нажмите [Enter]. Чтобы посмотреть список доступных команд, введите ftp и нажмите [Enter] для запуска утилиты, а затем введите ? и снова нажмите [Enter]. Для завершения работы утилиты введите bye и нажмите [Enter].

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

Передача одного файла

Скопируйте в Блокнот (Notepad) следующий текст, подставив нужные значения, и сохраните его как «H:TransferTesttransfer.bat».

ftp -v -n -s:H:TransferTesttransfer.ftp

Назначение команд:

• ftp — запускает утилиту FTP;
• -v — отключает вывод информации об ответах удаленного FTP-сервера;
• -n — отключает автоматический вход;
• -s: — указывает путь к файлу, содержащему команды для FTP-передачи.

Путь не должен содержать пробелов.

Затем скопируйте в Блокнот следующий текст, подставив нужные значения, и сохраните его как «H:TransferTesttransfer.ftp».

open example.yourhostingsite.com
user yourusername
password
cd /public_ftp/test
put “W:pecos-softwareworksshtmlchanges_to_the_windows7_taskbar_you_should_know_about.shtml”
bye

Назначение команд:

• open — открывает удаленный FTP-сервер;
• user — указывает имя пользователя для входа на сервер;
• password — указывает пароль для входа на сервер;
• cd — переходит в указанный удаленный каталог для загрузки файлов, в данном примере — «/public_ftp/test»;
• put — загружает указанный локальный файл на удаленный сервер; кавычки можно не использовать, если путь не содержит пробелов;
• bye — завершает сеанс подключения и работу утилиты FTP.

Совет: команды FTP можно сокращать до трех символов — например, использовать bin вместо binary.

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

• Откройте в Проводнике папку, в которой хранится нужный файл, нажмите правой кнопкой мыши на любом фрагменте адреса в адресной строке и выберите опцию «Копировать адрес как текст» (Copy Address as Text). Вставьте скопированный адрес в сценарий FTP и добавьте к нему имя файла.
• Нажмите правой кнопкой мыши на файле в Проводнике, выберите опцию «Свойства» (Properties) и откройте вкладку «Безопасность» (Security). Скопируйте полный путь к файлу из строки «Имя объекта» (Object name) и вставьте его в сценарий FTP.

В командной строке введите H:TransferTesttransfer.bat и нажмите [Enter] или запустите командный файл двойным щелчком. При этом может появиться предупреждение безопасности, показанное на рис. I.

Для скачивания файла с удаленного сервера на клиентский ПК используется команда get.

Передача нескольких файлов

Скопируйте в Блокнот следующий текст, подставив нужные значения, и сохраните его как «H:TransferTestmultiple_transfer.bat».

cd /D W:pecos-softwareworksshtml
ftp -v -n -s:H:TransferTestmultiple_transfer.ftp

Скопируйте в Блокнот следующий текст, подставив нужные значения, и сохраните его как «H:TransferTestmultiple_transfer.ftp».

open example.yourhostingsite.com
user yourusername
password
cd /public_ftp/test
prompt
mput “changes_to_the_windows7_taskbar_you_should_know_about.shtml” “a_case_of_maxtaken_identity.shtml”
lcd ProjectsPSWWVICPackage
binary
mput “vista_image_capture_1_1_2.zip” “vista_image_capture_1_2_0.zip”
bye

Назначение команд:

• open — открывает удаленный FTP-сервер;
• user — указывает имя пользователя для входа на сервер;
• password — указывает пароль для входа на сервер;
• cd — переходит в указанный удаленный каталог для загрузки файлов, в данном примере — «/public_ftp/test»;
• prompt — отключает интерактивные приглашения на ввод при загрузке множественных файлов с использование команды mput;
• mput — загружает указанные файлы ASCII с локального ПК; кавычки можно не использовать, если путь не содержит пробелов;
• lcd — переходит в указанный локальный каталог, в котором хранятся файлы для загрузки, в данном примере — «ProjectsPSWWVICPackage»;
• binary — переключается в режим двоичной передачи;
• mput — загружает указанные бинарные файлы с локального ПК; кавычки можно не использовать, если путь не содержит пробелов;
• bye — завершает сеанс подключения и работу утилиты FTP.

Теперь в командной строке введите H:TransferTestmultiple_transfer.bat и нажмите [Enter] или запустите командный файл двойным щелчком (рис. K).

Обратите внимание — я использовал команду cd для смены каталога в командном файле и команду lcd для смены локального каталога в сценарии FTP, чтобы упростить команду mput за счет использования относительного пути вместо полного.

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

Команда mput позволяет загрузить несколько файлов с клиентского компьютера на удаленный сервер. Если на сервере такие файлы уже существуют, они будут заменены.

Для скачивания нескольких файлов с удаленного сервера на локальный ПК используйте команду mget.

Передача текстовых и бинарных файлов

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

Проблемы безопасности

При передаче файлов по протоколу FTP возникает очевидная угроза безопасности. Если имя пользователя и пароль хранятся в незашифрованном текстовом файле, их может украсть любой, кто имеет доступ к компьютеру. Так что сценарий FTP стоит зашифровать. Подробнее о шифровании можно узнать в штатной справке Windows, воспользовавшись поиском по ключевому слову «шифрование». Нужные сведения содержатся в разделе «Шифрование или расшифровка папки или файла» (Encrypt or Decrypt a Folder or File). О шифровании в Windows 2000, Windows Server 2003, Windows XP, Windows Vista и Windows 7 рассказывается также на сайте Microsoft. В Википедии приводится полный версий Windows, поддерживающих систему шифрования данных Encrypting File System (EFS). Кроме того, можно воспользоваться сторонним приложением для шифрования, например, TrueCrypt.

Проблемы при использовании брандмауэра

Если при попытке подключиться к FTP-серверу вы получаете сообщение об ошибке «425 Невозможно установить соединение: Время ожидания истекло» (Unable to build data connection: Connection timed out), скорее всего, проблема связана с брандмауэром. Утилита FTP не поддерживает передачу данных в пассивном режиме, поэтому при использовании брандмауэра могут возникать ошибки в передаче данных. Я сталкивался с такой проблемой при использовании Comodo Firewall 4.0. Чтобы ее устранить, необходимо разрешить утилите FTP удаленный доступ в настройках брандмауэра.

В заключение

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

Автор: Alan Norton
Перевод

SVET

Оцените статью: Голосов

Глава 27 FTP: протокол передачи файлов

Введение

FTP это еще одно широко

используемое приложение. Оно является

стандартом Internet для передачи файлов. Необходимо

различать передачу файлов, именно то, что

предоставляет FTP, и доступ к файлам, что

предоставляется такими приложениями как NFS (Network File System, глава 29).

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

целого файла из одной системы в другую. Чтобы

использовать FTP, необходимо иметь открытый

бюджет на сервере, или можно воспользоваться так

называемым анонимным FTP (anonymous FTP).

Как и Telnet, FTP был создан для того, чтобы

работать между хостами работающими под

управлением различных операционных систем,

использующих различные структуры файлов и,

возможно, различные наборы символов. Telnet, однако,

обеспечивает связь между разнородными

системами, заставляя каждого участника

соединения работать с одним и тем же стандартом:

NVT, использующий 7-битный ASCII. FTP

сглаживает различия между системами с

использованием другого подхода. FTP поддерживает

ограниченное количество типов файлов (ASCII,

двоичное и так далее) и структуру файлов (поток

байтов или ориентированный на запись).

RFC 959 [Postel and Reynolds 1985] является

официальной спецификацией FTP. Этот RFC описывает

историю и развитиие передачи файлов в течение

времени.

Протокол FTP

FTP отличается от других приложений тем, что

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

файла.

1. Управляющее соединение

   устанавливается как обычное соединение

   клиент-сервер. Сервер осуществляет пассивное

   открытие на заранее известный порт FTP (21) и

   ожидает запроса на соединение от клиента. Клиент

   осуществляет активное открытие на TCP порт 21,

   чтобы установить управляющее соединение.

   Управляющее соединение существует все время,

   пока клиент общается с сервером. Это соединение

   используется для передачи команд от клиента к

   серверу и для передачи откликов от сервера. Тип IP сервиса для управляющего

   соединения устанавливается для получения

   «минимальной задержки», так как команды

   обычно вводятся пользователем (рисунок 3.2).

2. Соединение данных открывается

   каждый раз, когда осуществляется передача файла

   между клиентом и сервером. (Оно также открывается

   и в другие моменты, как мы увидим позже.) Тип

   сервиса IP для соединения данных должен быть

   «максимальная пропускная способность», так

   как это соединение используется для передачи

   файлов.

На рисунке 27.1 показано общение клиента и

сервера по двум соединениям.

Рисунок 27.1 Процессы, участвующие в

передаче файлов.

Из рисунка видно, что интерактивный

пользователь обычно не видит команды и отклики,

которые передаются по управляющему соединению.

Эти детали оставлены двум интерпретаторам

протокола. Квадратик, помеченный как

«пользовательский интерфейс», это именно то,

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

(полноэкранный интерфейс, основанный на меню,

командные строки и так далее). Интерфейс

конвертирует ввод пользователя в FTP команды,

которые отправляются по управляющему

соединению. Отклики, возвращаемые сервером по

управляющему соединению, конвертируются в

формат, удобный для пользователя.

Обратите внимание на то, что существуют два

интерпретатора протокола, которые по

необходимости используют две функции передачи

данных.

Представление данных

Протокол FTP предоставляет различные

способы управления передачей и хранения файлов.

Необходимо сделать выбор по четырем пунктам.

1. Тип файла.

(а)

ASCII файлы.

(По умолчанию) Текстовый файл передается по

соединению данных как NVT ASCII. При этом

требуется, чтобы отправитель конвертировал

локальный текстовый файл в NVT ASCII, а получатель

конвертировал NVT ASCII в текстовый файл. Конец

каждой строки передается в виде NVT ASCII символа

возврата каретки, после чего следует перевод

строки. Это означает, что получатель должен

просматривать каждый байт в поисках пары

символов CR, LF. (Мы видели тот же сценарий в случае

передачи ASCII файла с помощью TFTP в разделе «Протокол» главы 15.)

(b)

EBCDIC файлы.

Альтернативный способ передачи текстовых

файлов, когда на обоих концах системы EBCDIC.

(c)

Двоичные или бинарные файлы. (Image.)

Данные передаются как непрерывный поток битов.

(d)

Локальный тип файлов.

Способ передачи бинарных файлов между хостами,

которые имеют различный размер байта. Количество

битов в байте определяется отправителем. Для

систем, которые используют 8-битные байты,

локальный тип файла с размером байта равным 8

эквивалентен бинарному типу файла.

2. Управление форматом.

   Применяется только для ASCII и EBCDIC файлов.

(a)

Nonprint. (По умолчанию)

Файл не содержит информацию вертикального

формата.

(b)

Telnet format control.

Файл содержит управляющие символы вертикального

формата Telnet, которые интерпретируются принтером.

(c)

Fortran carriage control.

Первый символ каждой строки это Fortran символ

управления формата.

3. Структура.

   (a)

   Структура файла.

   (По умолчанию) Файл воспринимается в виде

   непрерывного потока байтов. Файл не имеет

   внутренней структуры.

   (b)

   Структура записи.

   Эта структура используется только в случае

   текстовых файлов (ASCII или EBCDIC).

   (c)

   Структура страницы.

   Каждая страница передается с номером страницы,

   что позволяет получателю хранить страницы в

   случайном порядке. Предоставляется операционной

   системой TOPS-20. (Требование к хостам Host

   Requirements RFC не рекомендует использовать эту

   структуру.)

4. Режим передачи. Указывает на то,

   как файл передается по соединению данных.

   (a)

   Режим потока.

   (По умолчанию) Файл передается как поток байтов.

   Для файловой структуры конец файла указывает на

   то, что отправитель закрывает соединение данных.

   Для структуры записи специальная 2-байтовая

   последовательность обозначает конец записи и

   конец файла.

   (b)

   Режим блоков.

   Файл передается как последовательность блоков,

   перед каждым из них стоит один или несколько байт

   заголовков.

   (c)

   Сжатый режим.

   Простое кодирование неоднократно встречающихся

   повторяющихся байт. В текстовых файлах обычно

   сжимаются пустые строки или строки из пробелов, а

   в бинарных строки из нулевых байт. (Этот режим

   поддерживается редко. Существуют более

   оптимальные способы сжатия файлов для FTP.)

Если посчитать количество комбинаций из

приведенных вариантов, то получится 72 способа

передачи и хранения файла. К счастью, можно

игнорировать многие из этих опций, потому что они

не поддерживаются в большинстве реализаций.

Самые распространенные Unix реализации FTP

клиента и сервера предоставляют следующий выбор:

• Тип: ASCII или двоичный.
• Управление форматом: только nonprint.
• Структура: только файловая структура.
• Режим передачи: только потоковый режим.

Это ограничивает нас одним из двух режимов:

ASCII или двоичный.

Подобная реализация

отвечает минимальным требованиям к хостам Host Requirements RFC. (RFC также требует

обеспечить поддержку для структуры записи,

однако только если операционная система

поддерживает это, а Unix, как правило, не

поддерживает.)

Большинство не-Unix реализаций

предоставляет FTP возможности, которые позволяют

обрабатывать их собственные форматы файлов.

Требование к хостам Host Requirements RFC говорит:

«Протокол FTP включает множество характеристик,

некоторые из которых распространены не очень

широко. Однако, для каждой характеристики в FTP

существует по меньшей мере одна реализация.»

Команды FTP

Команды и отклики передаются по

управляющему соединению между клиентом и

сервером в формате NVT ASCII. В конце

каждой строки команды или отклика присутствует

пара CR, LF.

Единственные команды Telnet (начинающиеся с

IAC), которые могут быть отправлены клиентом

серверу — это команда прерывания процесса (<IAC,

IP>) и Telnet сигнал синхронизации (<IAC, DM> в режиме

срочности). Мы увидим, что эти две команды Telnet

используются для прекращения передачи файла или

для того, чтобы отправить серверу запрос в

процессе передачи. Если сервер получает от

клиента команду с Telnet опцией (WILL, WONT, DO или DONT), он

отвечает либо DONT, либо WONT.

Команды состоят из 3 или 4 байт, а именно из

заглавных ASCII символов, некоторые с

необязательными аргументами. Клиент может

отправить серверу более чем 30 различных FTP

команд. На рисунке 27.2 показаны некоторые

наиболее широко используемые команды,

большинство из которых мы рассмотрим в этой

главе.

Команда	Описание
ABOR	прервать предыдущую команду FTP и любую передачу данных
LIST список файлов	список файлов или директорий
PASS пароль	пароль на сервере
PORT n1,n2,n3,n4,n5,n6	IP адрес клиента (n1.n2.n3.n4) и порт (n5 x 256 + n6)
QUIT	закрыть бюджет на сервере
RETR имя файла	получить (get) файл
STOR имя файла	положить (put) файл
SYST	сервер возвращает тип системы
TYPE тип	указать тип файла: A для ASCII, I для двоичного
USER имя пользователя	имя пользователя на сервере

Рисунок 27.2 Распространенные FTP команды.

В примерах мы увидим, что некоторые команды

полностью совпадают с тем, что вводит

интерактивный пользователь в качестве FTP команд.

В этом случае они передаются по управляющему

соединению, однако некоторые вводимые

пользователем команды генерируют несколько FTP

команд, которые, которые в свою очередь,

передаются по управляющему соединению.

FTP отклики

Отклики состоят из 3-циферных значений в

формате ASCII, и необязательных сообщений, которые

следуют за числами. Подобное представление

откликов объясняется тем, что программному

обеспечению необходимо посмотреть только

цифровые значения, чтобы понять, что ответил

процесс, а дополнительную строку может прочитать

человек. Поэтому пользователю достаточно просто

прочитать сообщение (причем нет необходимости

запоминать все цифровые коды откликов).

Каждая из трех цифр в коде отклика имеет

собственный смысл. (В главе 28 мы

увидим, что протокол передачи почтовых сообщений

— SMTP, использует те же соглашения для своих команд

и откликов.) На рисунке 27.3 показаны значения

первых и вторых цифр в коде отклика.

Отклик	Описание
1yz	Положительный предварительный отклик. Действие началось, однако необходимо дождаться еще одного отклика перед отправкой следующей команды.
2yz	Положительный отклик о завершении. Может быть отправлена новая команда.
3yz	Положительный промежуточный отклик. Команда принята, однако необходимо отправить еще одну команду.
4yz	Временный отрицательный отклик о завершении. Требуемое действие не произошло, однако ошибка временная, поэтому команду необходимо повторить позже.
5yz	Постоянный отрицательный отклик о завершении. Команда не была воспринята и повторять ее не стоит.
x0z	Синтаксическая ошибка.
x1z	Информация.
x2z	Соединения. Отклики имеют отношение либо к управляющему, либо к соединению данных.
x3z	Аутентификация и бюджет. Отклик имеет отношение к логированию или командам, связанным с бюджетом.
x4z	Не определено.
x5z	Состояние файловой системы.

Рисунок 27.3 Значения первой и второй цифр в

3-циферном коде отклика.

Третья цифра дает дополнительное

объяснение сообщению об ошибке. Ниже приведены

некоторые типичные отклики с возможными

объясняющими строками.

• 125 Соединение данных уже открыто; начало

  передачи.

• 200 Команда исполнена.
• 214 Сообщение о помощи (для пользователя).
• 331 Имя пользователя принято, требуется

  пароль.

• 425 Невозможно открыть соединение данных.
• 452 Ошибка записи файла.
• 500 Синтаксическая ошибка (неизвестная

  команда).

• 501 Синтаксическая ошибка (неверные

  аргументы).

• 502 Нереализованный тип MODE.

Обычно каждая FTP команда генерируют отклик

в одну строку. Например, команда QUIT сгенерирует

следующий отклик:

221 Goodbye.

Если необходим отклик в несколько строк,

первая строка содержит дефис вместо пробела

после 3-циферного кода отклика, а последняя

строка содержит тот же самый 3-циферный код

отклика, за которым следует пробел. Например,

команда HELP сгенерирует следующий отклик:

214- The following commands are recognized (* =>’s unimplemented).

   USER    PORT    STOR    MSAM*

    RNTO    NLST    MKD

     CDUP

   PASS    PASV    APPE    MRSQ*

    ABOR    SITE    XMKD

    XCUP

   ACCT*   TYPE    MLFL*   MRCP*

    DELE    SYST    RMD

     STOU

   SMNT*   STRU    MAIL*   ALLO

     CWD     STAT    XRMD

    SIZE

   REIN*   MODE    MSND*   REST

     XCWD    HELP    PWD

     MDTM

   QUIT    RETR    MSOM*   RNFR

     LIST    NOOP    XPWD

214 Direct comments to ftp-bugs@bsdi.tuc.noao.edu.

 Управление

соединением

Использовать соединение данных можно тремя

способами.

1. Отправка файлов от клиента к серверу.
2. Отправка файлов от сервера к клиенту.
3. Отправка списка файлов или директорий от

   сервера к клиенту.

FTP сервер посылает список файлов по

соединению данных, вместо того чтобы посылать

многострочные отклики по управляющему

соединению. При этом появляется возможность

избежать любых ограничений в строках,

накладывающихся на размер списка директории, и

позволяет просто сохранить список директории в

файле, вместо того чтобы выдавать список на

терминал.

Мы сказали, что управляющее соединение

остается в активизированном состоянии все время,

пока установлено соединение клиент-сервер,

однако соединение данных может выключаться и

включаться по необходимости. Как выбираются

номера портов для соединения данных, и кто

осуществляет активное открытие, а кто пассивное

открытие?

Во-первых, как было сказано ранее,

распространенный режим передачи (в случае Unix это

единственный режим передачи) — это потоковый

режим. В этом режиме конец файла обозначает

закрытие соединения данных. Из этого следует, что

для передачи каждого файла или списка директории

требуется новое соединение данных. Обычная

процедура выглядит следующим образом:

1. Создание соединения данных осуществляется

   клиентом, потому что именно клиент выдает

   команды, которые требуют передать данные

   (получить файл, передать файл или список

   директории).

2. Клиент обычно выбирает динамически

   назначаемый номер порта на хосте клиента для

   своего конца соединения данных. Клиент

   осуществляет пассивное открытие с этого порта.

3. Клиент посылает этот номер порта на сервер

   по управляющему соединению с использованием

   команды PORT.

4. Сервер принимает номер порта с управляющего

   соединения и осуществляет активное открытие на

   этот порт хоста клиента. Сервер всегда

   использует порт 20 для соединения данных.

На рисунке 27.4 показано состояние

соединений, пока осуществляется шаг номер 3. Мы

предполагаем, что динамически назначаемый порт

клиента для управляющего соединения имеет номер

1173, а динамически назначаемый порт клиента для

соединения данных имеет номер 1174. Команда,

посылаемая клиентом — PORT, а ее аргументы это шесть

десятичных цифр в формате ASCII, разделенные

запятыми. Четыре первых числа — это IP адрес

клиента, на который сервер должен осуществить

активное открытие (140.252.13.34 в данном примере), а

следующие два — это 16-битный номер порта. Так как

16-битный номер порта формируется из двух цифр,

его значение в этом примере будет 4 x 256 + 150 = 1174.

На рисунке 27.5 показано состояние

соединений, когда сервер осуществляет активное

открытие на конец клиента соединения данных.

Конечная точка сервера это порт 20.

Рисунок 27.4 Команда PORT, передаваемая

по управляющему соединению FTP.

Рисунок 27.5 FTP сервер осуществляет

активное открытие соединения данных.

Сервер всегда осуществляет активное

открытие соединения данных. Обычно сервер также

осуществляет активное закрытие соединения

данных, за исключением тех случаев, когда клиент

отправляет файл на сервер в потоковом режиме,

который требует, чтобы клиент закрыл соединение

(что делается с помощью уведомления сервера о

конце файла).

Если клиент не выдает команду PORT, сервер

осуществляет активное открытие на тот же самый

номер порта, который использовался клиентом для

управляющего соединения (1173 в данном примере). В

этом случае все работает корректно, так как

номера порта сервера для двух соединений

различны: один 20, другой 21. Тем не менее, в

следующем разделе мы посмотрим, почему

современные реализации не поступают таким

образом.

Примеры FTP

Сейчас мы рассмотрим некоторые примеры

использования FTP: как осуществляется управление

соединением данных, как передаются текстовые

файлы с использованием NVT ASCII, как в FTP

используется сигнал синхронизации Telnet для

прекращения процесса передачи. В завершение мы

рассмотрим «анонимный FTP» (anonymous FTP).

Управление соединением: динамически

назначаемый порт

Давайте, рассмотрим управление FTP

соединением на примере простой FTP сессии, в

течение которой просматривается список файлов

на сервере. Клиент запущен на хосте svr4 с флагом -d (отладка). При этом печатаются

команды и отклики, которыми происходит обмен по

управляющему соединению. Все строки,

начинающиеся с —>, отправляются клиентом

серверу, а строки, которые начинаются с 3-циферных

чисел, это отклики от сервера. Клиенту

выдается приглашение в виде ftp>.

Когда FTP клиент просит нас ввести имя

пользователя, он выводит имя по умолчанию (наше

имя на хосте клиента). Когда мы нажимаем клавишу

RETURN, отправляется это имя по умолчанию.

Когда мы спрашиваем, присутствует ли

указанный файл в директории, устанавливается

соединение данных. Этот пример является

продолжением процедуры, показанной на рисунках

27.4 и 27.5. Клиент спрашивает свой TCP модуль о

динамически назначаемом номере порта для своего

конца соединения данных и отправляет этот номер

порта (1174) серверу в виде команды PORT. Мы также

видим, что одна команда, введенная пользователем

(dir) генерирует две FTP команды (PORT и LIST).

На рисунке 27.6 приведена временная

диаграмма, иллюстрирующая обмен пакетами по

управляющему соединению. (Мы удалили все, что

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

управляющего соединения, вместе со всеми

объявлениями размера окна.) На этом рисунке

показано как открывается соединение данных,

используется и затем закрывается.

Рисунок 27.7 это временная диаграмма для

соединения данных. Времена на этом рисунке

начинаются с того же момента, как и на рисунке 27.6.

Мы удалили все объявления окна, однако оставили

поле типа сервиса, чтобы показать, что соединение

данных использует отличный тип сервиса

(максимальная пропускная способность), нежели

управляющее соединение (минимальная задержка).

(Значения TOS приведены на рисунке 3.2.)

На этой временной диаграмме FTP сервер

осуществляет активное открытие соединения

данных с порта 20 (который называется ftp-data) на

номер порта из команды PORT (1174). Также в этом

примере, где сервер выдает информацию в

соединение данных, сервер осуществляет активное

закрытие соединения данных, тем самым сообщая

клиенту, когда список завершен.

Рисунок 27.6 Пример управляющего

соединения FTP.

Рисунок 27.7 Пример соединения

данных FTP.

Управление соединением: порт данных по

умолчанию

Если клиент не посылает команду PORT на

сервер, чтобы указать номер порта для клиентской

стороны соединения данных, сервер использует тот

же номер порта для соединения данных, который был

использован для управляющего соединения. Это

может вызвать проблемы для клиента, который

использует потоковый режим (который Unix FTP клиенты

и сервера используют всегда), как мы покажем ниже.

Требование к хостам Host Requirements RFC рекомендует, чтобы FTP

клиент использовал потоковый режим, посылая

команду PORT, чтобы не использовать номер порта по

умолчанию перед каждым использованием

соединения данных.

Давайте снова обратимся к предыдущему

примеру (рисунок 27.6). Что произойдет, если мы

попробуем узнать содержимое другой директории

через несколько секунд после того, как узнали

содержимое первой? Клиент попросит свое ядро

выбрать еще один динамически назначаемый порт

(может быть, с номером 1175), после чего будет

открыто следующее соединение данных между svr4

порт 1175 и bsdi порт 20. Однако на рисунке 27.7 сервер

осуществляет активное закрытие соединения

данных, и мы видели на рисунке 18.6, что сервер не в

состоянии назначить порт 20 для нового соединения

данных, так как считается, что локальный порта

используется предыдущим соединением, пока

находится в состоянии ожидания 2MSL.

Сервер обходит эту проблему, указывая опцию

SO_REUSEADDR, которую мы упоминали в

разделе «Диаграмма состояний

передачи TCP» главы 18. Это позволяет ему

назначить порт 20 для нового соединения, которое

будет иметь другой номер удаленного порта (1175). В

состоянии ожидания 2MSL находится порт 1174.

Однако процедура открытия соединения

изменяется, если клиент не пошлет команду PORT,

указывая динамически назначаемый номер порта

клиента. Мы можем смоделировать подобную

ситуацию, исполнив пользовательскую команду

sendport на FTP клиенте. Unix FTP клиенты используют эту

команду, чтобы выключить отправку команд PORT на

сервер перед каждым использованием соединения

данных.

На рисунке 27.8 показана временная диаграмма

для соединений данных при использовании двух

команд LIST. Управляющее соединение установлено от

порта 1176 на хосте svr4, так что в случае отсутствия

команды PORT клиент и сервер используют тот же

самый номер порта для соединения данных. (Мы

удалили объявления окна и значения типа сервиса.)

Рисунок 27.8 Соединение данных для

двух последовательных команд LIST.

Последовательность событий в данном случае

следующая.

1. Управляющее соединение устанавливается от

   порта клиента 1176 на порт сервера 21. (Здесь это не

   показано.)

2. Когда клиент осуществляет пассивное

   открытие для соединения данных на порт 1176, он

   должен указать опцию SO_REUSEADDR, так как

   этот порт уже используется управляющим

   соединением клиента.

3. Сервер осуществляет активное открытие

   соединения данных (сегмент 1) с порта 20 на порт 1176.

   Клиент принимает это (сегмент 2), даже если порт 1176

   уже используется клиентом, потому что две пары

   сокетов

   <svr4,

   1176, bsdi, 21>

   <svr4, 1176, bsdi, 20>

   различны (номер порта на bsdi отличается). TCP демультиплексирует входящие сегменты,

   просматривая IP адрес источника, номер порта

   источника, IP адрес назначения и номер порта

   назначения, поэтому пока один из четырех

   элементов отличается, все в порядке.

4. Сервер осуществляет активное закрытие

   соединения данных (сегмент 5), при этом пара

   сокетов на сервере

   <svr4,

   1176, bsdi, 20>

   помещается в состояние ожидания 2MSL.

5. Клиент отправляет еще одну команду LIST по

   управляющему соединению. (Мы не показали этого.)

   Перед этим клиент осуществляет пассивное

   открытие порта 1176 на своем конце соединения

   данных. Клиент должен указать снова опцию SO_REUSEADDR, так как номер порта 1176 уже

   используется.

6. Сервер осуществляет активное открытие

   соединения данных с порта 20 на порт 1176. Перед тем

   как сделать это, сервер должен указать SO_REUSEADDR,

   так как локальный порт (20) связан с соединением,

   которое находится в состоянии ожидания 2MSL,

   однако, как мы показали в разделе «Диаграмма

   состояний передачи TCP» главы 18, соединение

   открыть не удасться. Дело в том, что пара сокет

   для требуемого соединения эквивалентна паре

   сокет из шага 4, которая все еще находится в

   состоянии ожидания 2MSL. Правила TCP запрещают

   серверу отправить SYN. Для сервера не существует

   способа игнорировать состояние 2MSL для пары

   сокетов, если ему понадобилось повторно

   использовать эту же пару сокетов.

   В этом

   месте BSD серверы повторяют попытки установить

   соединение каждые 5 секунд, до 18 раз, что в целом

   составляет 90 секунд. Мы видим, что сегмент 9

   успешно прошел примерно через одну минуту. (Мы

   говорили в главе 18, что SVR4

   использует MSL равное 30 секундам, при этом

   получается, что ожидание 2MSL составляет 1 минуту.)

   Мы не увидим ни одного SYN в это время на временной

   диаграмме, потому что активное открытие не

   удалось, и TCP модуль сервера даже не пытается

   посылать SYN.

Причина, по которой требования к хостам Host Requirements RFC рекомендуют использовать

команду PORT, заключается в том, что эта команда

позволяет обойти состояние ожидания 2MSL между

последовательными использованиями соединения

данных. Так как порты последовательно меняются

на одном конце, проблема, которую мы только что

показали, исчезает сама собой.

Передача текстовых файлов: представление NVT ASCII

или двоичное?

Давайте убедимся в том, что при передаче

текстовых файлов по умолчанию используется

формат NVT ASCII. В этот раз мы не будем

использовать флаг -d, поэтому мы не увидим команды

клиента, однако клиент все еще печатает отклики

от сервера:

Сорок два байта было передано по соединению

данных, потому что файл содержит четыре строки.

Каждый Unix символ новой строки (n) конвертируется

в 2-байтную последовательность NVT ASCII конец строки

(rn) сервером для передачи, а затем

конвертируется обратно клиентом при записи на

диск.

Более новые клиенты стараются определить,

используется ли подобная система на сервере, и

если да, передают файлы в двоичном виде (image тип

файла) вместо ASCII. Это помогает в двух

случаях.

1. Отправитель и получатель не должны

   просматривать каждый байт (это большая экономия

   времени и ресурсов).

2. Передается меньше байт, если операционная

   система хоста использует меньше байтов в

   качестве символа конца строки, нежели 2-байтовая

   последовательность NVT ASCII (это меньшая часть

   экономии).

Мы можем увидеть подобную оптимизацию с

использованием BSD/386 клиента и

сервера. Включен отладочный режим, что позволяет

увидеть команды FTP клиента:

После того как мы правильно ввели имя и

пароль серверу, FTP клиент автоматически посылает

команду SYST, в ответ на которую сервер сообщает

свой тип системы. Если отклик начинается со

строки «215 UNIX Type: L8», и если клиент работает

под управлением Unix системы с 8-битными байтами,

для передачи всех файлов используется двоичный

(image) режим, если его не сменит пользователь.

Когда мы забираем файл hello.c, клиент

автоматически посылает команду TYPE I, чтобы

установить тип файла в двоичный. На этот раз по

соединению данных было передано 38 байт.

Требования к хостам Host Requirements RFC говорят, что FTP сервер

должен поддерживать команду SYST (это было

необязательным условием в RFC 959). Из систем

описанных в тексте (см. внутреннюю сторону

обложки) эту команду поддерживают BSD/386

и AIX 3.2.2. SunOS 4.1.3 и Solaris

2.x выдают на эту команду отклик 500 (команда

неизвестна). SVR4 ведет себя совсем

по-дикому: отвечает 500 и закрывает управляющее

соединение!

Прекращение передачи файла: сигнал

синхронизации Telnet

Сейчас мы посмотрим, как FTP клиент

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

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

просто — клиент прекращает посылку данных по

соединению данных и посылает ABOR на сервер по

управляющему соединению. Прекращение приема,

однако, более сложная задача, потому что клиент

хочет, чтобы сервер немедленно прекратил

передачу данных. Ранее мы упоминали, что для

этого используется сигнал

синхронизации Telnet.

Мы начали прием, после чего ввели символ

прерывания. Ниже приведена интерактивная сессия,

процесс идентификации пользователя удален:

После того как введен символ прерывания,

клиент немедленно сообщает, что он

инициализировал прерывание передачи файла и

ожидает, когда сервер его завершит. Сервер

посылает два отклика: 426 и 226. Оба отклика

посылаются Unix сервером, когда он принимает

срочные данные от клиента с командой ABOR.

На рисунках 27.9 и 27.10 показаны временные

диаграммы для этой сессии. Мы объединили вместе

управляющее соединение (сплошные линии) и

соединение данных (прерывистые линии), чтобы

показать взаимосвязь между ними.

Рисунок 27.9 Прерывание передачи

файла (первая половина).

Первые 12 сегментов на рисунке 27.9 как раз

такие, как мы ожидали. Команды и отклики по

управляющему соединению настраивают системы на

передачу файла, открывается соединение данных и

от сервера к клиенту посылается первый сегмент

данных.

Рисунок 27.10 Прерывание передачи

файла (вторая половина).

Сегмент 13 на рисунке 27.10 — это квитанция на

шестой сегмент данных от сервера по соединению

данных. Затем следует сегмент 14, который

сгенерирован нашим вводом символа прерывания.

Для того чтобы прервать передачу, клиент

посылает десять байт:

<IAC, IP, IAC, DM, A,

B, O, R, r, n>

Мы видим два сегмента (14 и 15), это связано с

проблемой определения положения указателя

срочности TCP (подробно описанной в разделе «Режим срочности (Urgent Mode)»

главы 20). (На рисунке 26.17 мы

видели, как Telnet решает эту проблему.) Требование к

хостам Host Requirements RFC говорит, что

указатель срочности должен указывать на

последний байт срочных данных, тогда как

большинство Berkeley реализаций указывают на один

байт позади последнего байта срочных данных. FTP

клиент специально пишет первые 3 байта как

срочные данные, зная, что указатель срочности

будет (некорректно) указывать на следующий байт,

который будет записан (метка данных, DM, с номером

последовательности 54). Эта первая запись из 3 байт

срочных данных посылается немедленно, вместе с

указателем срочности, за ними следуют следующие 7

байт. (BSD FTP сервер не имеет проблемы с

интерпретацией указателя срочности, который

используется клиентом. Когда сервер принимает

срочные данные по управляющему соединению, он

читает следующую FTP команду, в поиске ABOR или STAT,

игнорируя любые вложенные команды Telnet.)

Несмотря на то, что сервер сообщил о

прекращении передачи (сегмент 18, по управляющему

соединению), клиент получил еще 14 сегментов

данных (номера последовательности 1537 — 5120) по

соединению данных. Эти сегменты, скорее всего,

были поставлены в очередь в драйвере сетевого

устройства на сервере, когда был принят сигнал о

прекращении передачи. Однако клиент печатает

«1536 байт принято», а это означает, что он

проигнорировал эти сегменты данных (сегменты 17 и

позже), которые были приняты после отправки

прерывания передачи (сегменты 14 и 15).

В случае Telnet, когда пользователь вводит

символ прерывания (рисунок 26.17), Unix клиент по

умолчанию не посылает команду прерывания

процесса в виде срочных данных. В этом нет ничего

страшного, потому что существует очень маленькая

вероятность того, что поток данных от клиента к

серверу остановлен управлением потока данных. В

случае FTP клиент также посылает команду

прерывания процесса по управляющему соединению,

и так как используется два соединения,

существует очень небольшая вероятность того, что

управляющее соединение будет остановлено

управлением потока данных. Почему FTP посылает

команду прерывания процесса в виде срочных

данных, тогда как Telnet не делает этого? Дело в том,

что FTP использует два соединения, тогда как Telnet

использует одно, а для некоторых операционных

систем довольно сложно обработать информацию

приходящую по двум соединениям одновременно. FTP

подразумевает, что эти операционные системы по

крайней мере смогут понять, что по управляющему

соединению срочные прибыли данные, и что в свою

очередь позволит серверу переключиться от

обработки соединения данных на обработку

управляющего соединения.

Анонимный FTP

Существует невероятно популярная форма

использования FTP. Она называется анонимный FTP

(anonymous FTP). Если эта форма поддерживается сервером,

она позволяет любому получить доступ к серверу и

использовать FTP для передачи файлов. С помощью

анонимного FTP можно получить доступ к огромному

объему свободно распространяемой информации.

Тут возникает еще одна проблема, которая

заключается в том, что очень сложно найти то, что

нужно в этом море информации. Кратко это описано

в разделе «Archie, WAIS, Gopher, Veronica и

WWW» главы 30.

Воспользуемся анонимным FTP, чтобы получить

файл опечаток для этой книги с хоста ftp.uu.. Чтобы

использовать анонимный FTP, мы входим в систему с

именем пользователя «anonymous» (чтобы выучить,

как пишется это слово, попробуйте повторить его

несколько раз). Когда появляется приглашение

ввести пароль, мы вводим наш адрес электронной

почты.

Программа uncompress используется

потому, что большинство файлов, доступных через

анонимный FTP, сжаты с использованием Unix программы

compress(1), такие файлы имеют расширение

.Z. Эти файлы должны быть переданы в виде двоичных

файлов, а не ASCII файлов.

Анонимный FTP с неизвестного IP

адреса

Мы можем объединить вместе некоторые

характеристики маршрутизации и системы имен (Domain

Name System) с использованием анонимного FTP. В

разделе «Запросы указателя»

главы 14 мы говорили о запросах

указателя в DNS — которые воспринимают IP адреса и

возвращают имя хоста. К сожалению, не все

администраторы систем корректно конфигурируют

свои DNS серверы таким образом, чтобы они отвечали

на запросы указателей. Они часто добавляют новые

хосты к файлам, необходимым для установления

соответствия имя-адрес, однако забывают добавить

их в файлы, устанавливающие соответствие

адрес-имя. С этим можно столкнуться, работая с

программой traceroute, когда она выдает IP

адреса вместо имен хостов.

Некоторые анонимные FTP серверы требуют,

чтобы клиент имел корректное имя домена. Это

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

хоста, с который осуществлен заход. Единственная

информация, которую может узнать сервер о

клиенте из IP датаграммы — это IP адрес клиента.

Сервер осуществляет запрос указателя, чтобы

узнать доменное имя клиента. Если DNS сервер,

отвечающий за хост клиента, не сконфигурирован

корректно, запрос указателя не сработает.

Давайте смоделируем подобную ошибку.

1. Изменим IP адрес хоста slip (см. рисунок на

   внутренней стороне обложки) на 140.252.13.67. Это

   нормальный IP адрес для нашей подсети, однако его

   нет на DNS сервере домена noao.edu.

2. Изменим IP адрес назначения SLIP канала на bsdi

   на 140.252.13.67.

3. Добавим пункт в таблицу маршрутизации на sun,

   который будет направлять датаграммы для 140.252.13.67

   на маршрутизатор bsdi. (Обратитесь к описанию этой

   таблицы маршрутизации, которое приведено в

   разделе «Принципы

   маршрутизации» главы 9.)

Хост slip доступен по Internet, потому что, как мы

видели в разделе «RIP: протокол

обмена информацией о маршрутизации» главы 10,

маршрутизаторы gateway и netb все еще посылают

датаграммы, которые предназначены в подсеть

140.252.13, на маршрутизатор sun. Наш маршрутизатор sun

знает, что делать с этими датаграммами, в

соответствии с пунктом маршрутизации, который мы

сделали в шаге номер 3. Таким образом, мы создали

хост, который полностью подключен к Internet, однако

не имеющий корректного имени домена. Таким

образом, запрос указателя для IP

адреса 140.252.13.67 не будет работать. А сейчас

воспользуемся анонимным FTP на сервер, который,

как мы знаем, требует корректного имени домена.

slip % ftp ftp.uu.net

Connected to ftp.uu.net.

220 ftp.UU.NET FTP server (Version 2.OWU(13) Fri Apr 9 20:44:32 EDT 1993) ready.

Name (ftp.uu.net:rstevens): anonymous530- Sorry, we’re unable to map your IP address 140.252.13.67 to a hostname

530- in the DNS. This is probably because your nameserver does not have a

530- PTR record for your address in its tables, or because your reverse

530- nameservers are not registered. We refuse service to hosts whose

530- names we cannot resolve. If this is simply because your nameserver is

530- hard to reach or slow to respond then try again in a minute or so, and

530- perhaps our nameserver will have your hostname in its cache by then.

530- If not, try reaching us from a host that is in the DNS or have your

530- system administrator fix your servers.

530 User anonymous access denied..

Login failed.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> quit

221 Goodbye.

 

(К сожалению, мы не можем найти имя хоста,

соответствующее вашему IP адресу. Возможно, это

потому, что у вашего сервера имен нет в таблице PTR

записи, соответствующей вашему адресу, или ваш

сервер не зарегистрирован. Мы не работаем с

хостами, для которых мы не можем определить имя

домена. Если проблема в том, что ваш DNS сервер

медленно отвечает или до него сложно

достучаться, попробуйте еще раз через минуту.

Может быть, в этот раз DNS сервер уже будет иметь

ваше имя в своем кэше. Если дело не в этом,

попробуйте зайти к нам с хоста, который корректно

зарегистрирован в DNS, или попросите

администратора починить ваш сервер.) Сообщение

об ошибке говорит само за себя.

Краткие выводы

FTP это стандарт, признанный в Internet, для

передачи файлов. В отличие от большинства других

TCP приложений, он использует два TCP соединения

между клиентом и сервером — управляющее

соединение, которое существует в течение всего

продолжения сессии клиент-сервер, и соединение

данных, которое создается и удаляется по

необходимости.

Управление соединением, которое

осуществляется FTP, позволило нам увидеть, какие

требования выдвигает TCP к управлению

соединением. Мы видели состояние ожидания 2MSL на

клиенте, который не выдает команды PORT.

FTP использует формат NVT ASCII для

всех команд и откликов, которые передаются по

управляющему соединению. Режим передачи данных

по умолчанию это, как правило, также NVT ASCII.

Мы видели, что более новые Unix клиенты

автоматически посылают команду, чтобы убедиться

в том, что сервер это Unix хост с 8-битными байтами, и

если так, используют двоичный режим для передачи

всех файлов, которые являются более

эффективными.

Также мы показали пример анонимного FTP,

популярного способа распространения

программного обеспечения по Internet. 

Упражнения

1. Обратитесь к рисунку 27.8. Что

   изменится, если клиент осуществит активное

   открытие второго соединения данных вместо

   сервера?

2. В примере для FTP клиента в этой главе мы сказали,

   что такие строки, как, например

   local: hello.c remote: hello.c

   42 bytes received in 0.0037 seconds (11 Kbytes/s)

   выдаются клиентом. Не

   заглядывая в исходные тексты, как можно

   определить, что они не от сервера?

Это еще одна статья «давно гуляющая» по интернету, и опять, как автор, сделаю перепост. Думаю пригодиться и тут.

Введение

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

Общие сведения о протоколе FTP

Итак, FTP (File Transfer Protocol) – протокол передачи файлов в сетях стандарта TCP/IP. Этот протокол был специально создан для облегчения и стандартизации программирования алгоритмов передачи файлов между клиентом и сервером. Как и все протоколы высокого уровня, он не занимается непосредственной передачей данных (этим занимается протокол более низкого уровня – TCP, а так же протоколы ниже), а лишь описывает способ «общения» клиент-сервер.

Перейдем непосредственно к описанию протокола. Отличительной его особенностью является использование двух соединений между сервером и клиентом. Одно соединение (командное или управляющее) используется для передачи команд серверу, а так же приема ответов на эти команды. Второе соединение (соединение данных) используется непосредственно для приема или передачи данных. Управляющее соединение всегда происходит со стороны клиента на порт сервера 21 и остается на протяжении всего сеанса работы открытым. Соединение данных открывается и закрывается по мере необходимости в приеме или получении данных.

После того как установлено управляющее соединение клиент может отправлять по нему серверу различные команды. Каждая команда представляет из себя 3 или 4 заглавных символа ASCII, за которыми после одного или более пробелов следуют, в некоторых командах не обязательные аргументы. Любая команда заканчивается парой CR, LF – это, несомненно, известные всем 0dh, 0ah – если речь идет о DOS/Windows. В общих чертах схема команды такая:

Команда [аргумент(ы)] CR, LF.

Всего существует чуть более 30 команд (в RFC959 – 33) которые могут быть посланы серверу, но это совсем не значит что сервер все их будет поддерживать. Приведу пример наиболее часто используемых команд.

USER имя пользователя
Указывает имя пользователя

PASS пароль
Указывает пароль пользователя

LIST список файлов
Запрос списка файлов

PORT n1,n2,n3,n4,n5,n6
Указание IP и порта для соединения данных

RETR имя файла
Получить файл с сервера

STOR имя файла
Положить файл на сервер

TYPE тип
Тип передаваемых данных

QUIT
Отключение от сервера

ABOR
Отмена предыдущее команды. Прекращение передачи данных.

При получении запроса сервер, по тому же управляющему соединению отправляет ответ на него. Ответ сервера состоит из трех символов (цифр) в формате ASCII, за которыми следует не обязательный текст, обычно поясняющий цифирный код ответа, за этим пояснением следуют неизменные CR, LF. Ответ например может быть таким: 226 File send OK. – в этом примере сервер сообщает нам о том, что файл отправлен с его стороны (что совсем не означает, что он уже получен со стороны клиента). Первая цифра отклика сервера наиболее значимая, и дает однозначное представление о том как выполнилась (или не выполнилась) команда. Значения могут быть такими:

• 1хх Команда находится в процессе выполнения, необходимо дождаться еще одного сообщения перед тем, как давать следующую команду.
• 2хх Команда выполнена. Сервер находится в ожидании следующей.
• 3хх Команда выполнена, но для продолжения необходима еще одна команда
• 4хх Команда не была выполнена, необходимо подождать и повторить команду
• 5хх Команда не была выполнена и не будет выполнена при повторе.

По второй цифре отклика можно судить о том, какая ситуация привела к возникновению отклика:

• x0x Ошибка синтаксиса.
• x1x Информация.
• x2x Отклик относится к состоянию управляющего или соединению данных.
• x3x Отклик относится к аутентификации пользователя или состоянию бюджета.
• x4x Не определенно.
• x5x Отклик относится к состоянию файловой системы.

Ну и наконец третья цифра отклика несет в себе дополнительную информацию.

Следует обратить особое внимание на то, что хотя на большую часть команд сервер отвечает одним откликом, есть и широко используются команды, в ответ на которые сервер генерирует несколько откликов. При этом первая цифра первого отклика будет «1» — т.е. если взглянуть на таблицы выше, сервер сообщает нам о том, что необходимо подождать еще одного сообщения от него, перед тем, как посылать следующую команду. Примером такой команды может служить команда RETR, когда сервер принимает ее и начинает пересылку данных он отвечает нам что-то вроде: «150 Opening BINARY mode data connection for HIDE.ASM (958 bytes).» — смысл сообщения сводится к «начата передача данных». Затем, когда данные им уже будут отправлены (но опять хочу заострить внимание – не факт, что получены клиентом) он отправит по управляющему соединению еще один отклик – «226 File send OK.» — т.е. «файл отправлен». Вот в этом случае только после получения второго сообщения сервер готов к выполнению следующей команды. Вместо последнего сообщения мы вполне можем получить сообщение с ошибкой начинающееся с «4» — в том случае, если возникнут какие-либо проблемы с передачей файла.

В общих чертах это все, что касается управляющего соединения.

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

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

• клиент выбирает свободный порт на своем хосте и осуществляет пассивное открытие на него;
• клиент сообщает серверу по управляющему соединению свой IP-адрес и номер порта, на который сделал пассивное открытие;
• сервер, получив порт и IP-адрес осуществляет его активное открытие;
• передаются или принимаются данные;
• в зависимости от того кто передает, а кто принимает данные осуществляется закрытие порта.

Небольшое отступление: если вы внимательно прочтете второй пункт, может возникнуть вопрос – «А что будет если мы передадим серверу фиктивный адрес и порт?». Ответ неоднозначен, сервер может проверять IP-адрес, но это происходит не всегда, поэтому существуют некоторые интересные «заморочки» с использованием фиктивных адресов.

Что касается порта, выбираемого для соединения данных клиентом. Обычно используется динамически назначаемый ОС порт, — т.е. делается запрос к системе, она дает первый свободный. Если клиент не указывает серверу порт для соединения, оно происходит на порт с которого было проведено управляющее соединение (поступать так не рекомендуется). Сервер всегда осуществляет соединение данных с 20-го порта.

Это все основное, что я хотел рассказать о соединении данных.

Теперь, когда мы знаем для чего и как работают оба соединения, хочу отметить еще один момент (при первом прочтении можно пропустить). Команда LIST возвращает список файлов текущей директории, и возвращает его по соединению данных. Список представляет из себя набор строк ASCII оканчивающихся символами CR, LF. Каждая строка несет в себе информацию об одном из элементов запрашиваемого каталога. Общий шаблон этой строки такой:

Txxxxxxxxx[ ]uk[ ]user[ ]group[ ]size[ ]mm[ ]dd[ ]yytt[ ]name CR, LF

где,

T – тип элемента («d» — каталог, «-» — файл, «l» — ссылка и т.д.);
xxxxxxxxx – атрибуты защиты файла;
user – пользователь, владелец файла;
group – группа владельца;
size — размер элемента;
mm – месяц создания элемента в текстовом виде, например «jul»;
dd – день месяца создания элемента;
yytt – здесь может быть год или время создания элемента;
name – имя элемента (файла, каталога, ссылки);
[ ] – один или более пробелов.

Да, между этими элементами может быть различное количество пробелов, надо сказать спасибо, что в различных реализациях серверов оставили одно количество значимых столбцов, поэтому при анализе таблицы файлов следует это учитывать. Стоит еще учесть такую вещь, что не всегда первая строка из таблицы есть значимая строка, несущая информацию о первом элементе каталога. В некоторых реализациях FTP-серверов (например ftpd на FreeBSD), первой строкой списка является строка «total NN».

Как это должно работать?

Давайте немного отвлечемся и посмотрим, как же должен выглядеть FTP сеанс получения файла «изнутри». Итак, мы запускаем клиента. Сервер в это время уже пассивно открыл и слушает 21-ый порт. В первую очередь нам необходимо создать управляющее соединение – конектимся на сервер на порт 21. Что дальше? Сразу, как только мы удачно законектились с сервером по созданному управляющему соединению нам приходит приветствие от сервера, это будет что-то вроде «220 VSFTP deamon base on Alt Linux 2.2, Shpakovsky».

Следующим шагом должна быть регистрация – допустим мы соединяемся с анонимным сервером — по управляющему соединению клиент посылает серверу команду USER anonymous, на что, если сервер поддерживает анонимного пользователя получаем ответ: «331 Please specify the password.» — «пожалуйста сообщите пароль», заметим цифру «3» в ответе сервера, что означает, что для продолжения требуется еще команда, что собственно и делает клиент – посылаем команду PASS 1@1 – в качестве пароля указав фиктивный e-mail. На что получаем ответ сервера «230 Login successful. Have fun.» — «Регистрация прошла успешно».

Все, теперь наши действия зависят от того что мы хотим, а как говорилось выше, хотим мы получить с сервера файл, пусть к примеру это будет файл «HIDE.EXE», расположенный в корневом каталоге сервера. Перед тем, как осуществлять прием или передачу данных серверу необходимо указать какой тип данных будет передаваться, делается это командой TYPE N, где N = «A», если тип ASCII и N = «I», если файл бинарный. Клиент посылает серверу команду TYPE I, на что получает ответ – «200 Switching to Binary mode.».

Итак, осталось только получить файл. Для этого клиенту необходимо открыть соединение данных. Клиентом выбирается свободный порт, осуществляется пассивное открытие, т.е. клиент его «слушает». Дальше клиенту нужно сообщить серверу свой IP-адрес и номер порта, который только что пассивно открыл (допусти IP-адрес хоста клиента будет 10.21.23.10, а номер порта 2000). Клиент посылает серверу по управляющему соединению команду PORT 10,21,23,10,7,208 – «что за 7,208?» — спросите вы. Это и есть номер порта строится он так – 7*256+208 = 2000. Сервер после получения этой команды попытается сделать активное открытие указанного порта и в случае удачи вернет что-то вроде «200 PORT command successful. Consider using PASV.».

Все, соединение данных установлено остается дать команду передачи данных серверу, что и делает клиент — RETR HIDE.EXE, на что в случае если все нормально (файл существует и может быть передан) сервер отвечает «150 Opening BINARY mode data connection for HIDE.EXE (4096 bytes).» и начинает сливать файл по соединению данных. Опять обращаю ваше внимание на первую цифру ответа. Когда файл будет полностью отправлен сервер пошлет сообщение «226 File send OK.» и произведет закрытие соединения данных.

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

Итак файл получен клиентом, остается разорвать управляющее соединение, клиент посылает команду QUIT, сервер отвечает «221 Goodbye.» и разрывает соединение.

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

Реализация.

Теперь о самой реализации. В этой реализации клиента я использую non-blocking (не блокирующие) сокеты, поэтому модель клиента – событийная, т.е. выполнять те или иные действия, касающиеся используемых клиентом сокетов клиент будет только при возникновении соответствующего события (например закрытие соединения, уведомление о получении данных и т.д.). В качестве событий используются сообщения, приходящие в процедуру главного окна. Кроме того, модель программы поточная, используется поток для чтения соединения данных и поток для чтения управляющего соединения, а так же основной поток клиента, запускающийся при нажатии на кнопку «соединение». Так как программа многопоточная для синхронизации работы этих трех потоков (а так же процедуры сообщений главного окна) используются «event’s» («события», не путать эти события, используемые программой как датчик 1 или 0 – произошло или не произошло событие, и события касающиеся сокетов, которые приходят на процедуру главного окна).

Итак, начнем. При создании основного окна приложения мы проводим основную инициализацию программы, поясню основные моменты:

call VirtualAlloc,ebx,1024000,MEM_COMMIT+MEM_RESERVE,PAGE_READWRITE
mov ReciveDataBufferOffset,eax
call VirtualAlloc,ebx,10240,MEM_COMMIT+MEM_RESERVE,PAGE_READWRITE
mov ReciveCommandBufferOffset,eax
Здесь выделяется память под буфер приема файла (1 Мб) и под буфер команд (10 Кб).

call CreateEventA,ebx,ebx,ebx,ebx
mov HDataReciveEvent,eax
……
Создаются объекты event (события) более подробно о назначении событий позже.

call CreateThread,ebx,ebx,offset ReciveThread,offset ReciveDataThreadStruc,
NORMAL_PRIORITY_CLASS,offset ThreadID_data
call CreateThread,ebx,ebx,offset ReciveThread,offset ReciveCommandThreadStruc,
NORMAL_PRIORITY_CLASS,offset ThreadID_command
Создаются 2 потока – один для чтения данных, другой для чтения управляющего потока. Оба этих потока при старте находятся в приостановленном состоянии, и начинают работать только при установлении соответствующего события.

call gethostname, offset HostName,64
call gethostbyname,offset HostName
…..
mov PortInPort,esi
ret 0

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

На этом процесс начальной инициализации заканчивается, и программа находится в состоянии ожидания команды пользователя. Давайте посмотрим что происходит при нажатии пользователем кнопки «соединиться».

В основной процедуре окна создается главный поток приложения, рассмотрим его ключевые моменты.

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

- создаем сокет;
call socket, AF_INET, SOCK_STREAM, IPPROTO_TCP
mov ReciveCommandSock,eax
- выбираем неблокирующий режим для сокета, указываем что хотим получать
сообщения о получении новых данных на сокет, а так же о успешном его
приконекчивании.
call WSAAsyncSelect, ReciveCommandSock, newhwnd, WM_COMMANDSOCK,FD_READ+FD_CONNECT
- получаем информацию об удаленном хосте и конектимся к нему
…..
call connect,ReciveCommandSock,offset sockaddr_in,16
- ждем получения события FD_CONNECT, когда оно приходит в процедуру главного окна
обработчик с помощью call SetEvent,HWaitConnectEvent устанавливает событие,
чего мы и ожидаем в следующей строке, если событие не будет установлено в течении
5 секунд, выводим сообщение об ошибке и заканчиваем сеанс связи.
call WaitForSingleObject,HWaitConnectEvent,5000
call ResetEvent,HWaitConnectEvent
- так как после соединения сервер должен послать нам приветствие, ждем его еще 5
секунд, если оно не поступило - выходим. Процедура WaitAnswerRecive описана ниже.
call WaitAnswerRecive,5000
or eax,eax
jnz errorwithregisration

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

WaitAnswerRecive proc TimeToWait:dword
call WaitForSingleObject,HWaitCommandEvent,TimeToWait
- ожидаем возникновение события HWaitCommandEvent, которое устанавливается в потоке
получения данных по управляющему соединению, в случае успешного получения данных.
or eax,eax
jz NoTimeOutGet
call MessageBoxA,newhwnd,offset ErrTimeOutCommand,offset ErrorCap,40h
call ResetEvent,HWaitCommandEvent
- сбросили событие HWaitCommandEvent т.к. истек таймаут, и событие осталось в
сигнальном состоянии.
NoTimeOutGet:
ret
WaitAnswerRecive endp

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

Универсальный трэд для получения данных по управляющему и соединению данных приведен ниже.

- в качестве параметра поток получает адрес структуры ReciveDataThreadStruc
или ReciveCommandThreadStruc в зависимости от предназначения трэда.
Структура для ReciveCommandThreadStruc такая:
- хэндл события по которому трэд активизируется;
HCommandReciveEvent dd ?
- хэндл события, которое устанавливает трэд если все данные успешно получены;
HWaitCommandEvent dd ?
- адрес буфера получения данных;
ReciveCommandBufferOffset dd ?
- здесь содержится общее количество полученных данных;
BytesCommandRecived dd 0
- и наконец, с какого сокета надо получить данные;
ReciveCommandSock dd ?

ReciveThread proc parametr:dword
mov edi,parametr
InfinityLoop:
- ждем возникновения события, что данные можно принимать;
call WaitForSingleObject,dword ptr [edi],-1
- настраиваем esi на место, куда данные будут считаны - адрес буфера+количество
полученных ранее;
mov esi,[edi+8]
add esi,[edi+12]
- получаем не более 4096 байт;
call recv,dword ptr [edi+16],esi,4096,0
- прибавляем к уже полученным ранее, полученные в данный момент;
add [edi+12],eax
- в ebx заносим хэндл события, которое надо установить, если получены все нужные данные;
mov ebx,[edi+4]
- если мы получаем данные по соединению данных то идем к проверке конца получения
данных по соединению данных, иначе - проверяем получили ли мы все данные по
управляющему соединению;
cmp edi,offset ReciveDataThreadStruc
je comparefordata
- по управляющему соединению получены все данные в случае если последние байты ответа
0dh, 0ah, что мы и проверяем;
mov eax,[edi+12]
mov esi,[edi+8]
cmp byte ptr [esi+eax-1],10
je short CallEvent
jmp InfinityLoop
comparefordata:
- по соединению данных получено все, если количество полученных байт = длине файла;
mov eax,[edi+12]
cmp FileLenght,eax
jne InfinityLoop
CallEvent:
- в случае если все данные получены выставляем соответствующее событие;
call SetEvent,ebx
jmp InfinityLoop
ReciveThread endp

Вернемся теперь к основному потоку, мы успешно получили ответ от сервера, в том что он готов к приему команд, теперь мы можем передавать ему команды, в данной реализации за отправку команд серверу отвечает функция SendCommandInSocket, в основном потоке далее мы вызываем эту функцию для отправки серверу последовательно команд: USER, PASS, TYPE, CWD, PORT и LIST. Сама функция выглядит так:

- принимает аргументами сокет, в который нужно передать команду, и смещение на буфер,
в котором содержится команда;
SendCommandInSocket proc uses ebx ecx esi edi, hSocket:dword, OutBufOffset:dword
- сначала определяем длину команды;
mov edi,OutBufOffset
push edi
mov eax,0ah
mov ecx,100
repne scasb
sub edi,OutBufOffset
mov ecx,edi
pop esi
push edi
- переносим команду в буфер для приема ответов для сервера, сделано это для того,
что бы потом его можно было сохранить в удобочитаемом виде лога;
mov edi,ReciveCommandBufferOffset
add edi,BytesCommandRecived
rep movsb
pop edi
add BytesCommandRecived,edi
- посылаем команду в сокет;
call send,hSocket,OutBufOffset,edi,ebx
- ждем ответа сервера, с помощью уже описанной выше функции WaitAnswerRecive;
mov eax,5001
Wait2Answer:
dec eax
push eax
call WaitAnswerRecive
or eax,eax
jnz ErrorProcessed
- ответ получен, ищем первый байт ответа, мы его ИЩЕМ, а не просто используем
смещение на конец предпоследнего полученого сообщения, потому, что нами может
быть получено в одном сеансе получения данных обновременно два ответа от сервера.
Уясните себе этот момент.
mov edi,ReciveCommandBufferOffset
mov ecx,BytesCommandRecived
dec ecx
dec ecx
add edi,ecx
mov al,0ah
std
repne scasb
cld
xor eax,eax
- проверяем первый символ ответа;
mov cl,[edi+2]
cmp cl,'1'
- если это "1" то ждем еще одного сообщения от сервера
jz Wait2Answer
cmp cl,'3'
- если ответ больше "3" - произошла ошибка;
jna NoErrorProcessed
call MessageBoxA,newhwnd,edi,offset ErrorCap,40h
ErrorProcessed:
xor eax,eax
inc eax
NoErrorProcessed:
ret
SendCommandInSocket endp

Необходимо учесть еще одну вещь – перед отправкой команды PORT, нам надо создать слушающий сокет, это мы делаем с помощью вызова процедуры CreateListenSock.

CreateListenSock proc
pushad
- создаем сокет;
call socket, AF_INET, SOCK_STREAM, IPPROTO_TCP
mov datasock,eax
- переводим его в не-блокирующий режим, указывая, что хотим получать в процедуре
окна сообщения о подтверждении приконекчивания к этому сокету, о поступлении
новых данных, и о закрытии соединения;
call WSAAsyncSelect, datasock, newhwnd, WM_DATASOCK, FD_ACCEPT+FD_READ+FD_CLOSE
- ввязываем сокет с локальным адресом;
mov sin_port,0 ; указываем ноль, в этом случае система даст нам
; первый свободный порт
mov sin_family,AF_INET
mov sin_addr,INADDR_ANY
call bind, datasock, offset sockaddr_in, 16
- получаем инфу о сокете;
call getsockname,datasock,offset sockaddr_in,offset szSockaddr_in
- преобразуем номер порта к нормальному виду;
xor eax,eax
mov ax,sin_port
call ntohs,eax
push eax
shr eax,8
- дальше преобразуем номер порта в символы ASCII;
call DECtoASCII,eax,PortInPort
- и записываем их в шаблон команды PORT
mov al,','
stosb
pop eax
and eax,0ffh
call DECtoASCII,eax,edi
mov ax,0a0dh
stosw
mov esi,PortInPort
- слушаем сокет;
call listen, datasock, 1
popad
ret
CreateListenSock endp

Итак последней отправленной командой была команда LIST, после нее на соединение данных должен прийти список файлов текущей директории, соответственно после отправки сообщения нам необходимо подождать пока этот список будет нами получен, т.к. даже если сервер отправил нам сообщение о том, что он успешно завершил отправку всех данных это совсем не значит, что наш поток уже все отработал и получил, поэтому мы ожидаем окончания получения функцией WaitTransferComplete.

- получает в качестве аргумента в течении которого мы буде ждать ОКОНЧАНИЯ получения
данных, после того, как соединение будет закрыто со стороны сервера.
WaitTransferComplete proc uses ecx edi, TimeToWaitEndTransfer:dword
WaitProgress:
- ждем установления события закрытия соединения со стороны сервера, оно устанавливается
в главной процедуре окна;
call WaitForSingleObject,HWaitCloseEvent,-1
- дальше ждем, события успешного получения данных нашим потоком, которое в нем и
устанавливается;
call WaitForSingleObject,HWaitDataEvent,TimeToWaitEndTransfer
or eax,eax
jz CloseDataSocks
- был таймаут, и если мы получаем директорию, то выходим без ошибки, т.к. при получении
директории у нас всегда таймаут, потому, что мы заранее не знаем количество получаемых
байт и поток получения не может установить событие успешного получения;
cmp TimeToWaitEndTransfer,1000 ;если ждем каталог
jz CloseDataSocks
call MessageBoxA,newhwnd,offset ErrTimeOutCommand,offset ErrorCap,40h

CloseDataSocks:
- сбрасываем событие успешного получения;
call ResetEvent,HWaitDataEvent
- закрываем соединение со своей стороны;
call closesocket,ReciveDataSock
call closesocket,datasock
ret
WaitTransferComplete endp

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

Заключение.

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

Продолжаем тему работы с FTP сервером! Мы уже рассмотрели основы протокола FTP, а так же способы работы с FTP сервером, а сегодня мы рассмотрим работу с FTP сервером через командную строку cmd. Как я и говорил данный метод используется довольно редко, по крайней мере мной, так как проще работать через FTP клиент. Однако, для написания автоматизированных скриптов для обмена данными между вашей локальной машиной и FTP сервером эти знания вам очень даже пригодятся.

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

И для начала нам необходимо запустить командную строку (Пуск Приложения Служебные программы Командная строка) или Win+R cmd.

Первым делом необходимо перейти в режим работы с FTP сервером делается это через команду FTP

Далее необходимо подключиться непосредственно к серверу, с которым мы будем работать, делается это через команду OPEN АДРЕС_FTP_СЕРВЕРА

Вводим ИМЯ_ПОЛЬЗОВАТЕЛЯ который имеет доступ к данному серверу и ПАРОЛЬ

Если мы ведем команду DIR то нам выведется список файлов и папок которые содержатся на FTP сервере.

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

Вы всегда можете набрать команду HELP и вам выведется список поддерживаемых команд, чтобы узнать назначение команды достаточно ввести HELP НАЗВАНИЕ_КОМАНДЫ.

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

У меня нет доступа для непосредственно записи файлов в корень данного FTP-сервера, но есть доступ к папке htdocs, поэтому для начала перейдём в данную папку. Делается это команды CD ИМЯ_ПАПКИ.

Мы видим, что в данной папке у нас ничего нет. Давайте попробуем скопирую сюда какой-нибудь файл с нашего локального компьютера. Для этого на локальном компьютере создадим папочку, допустим у меня это будет nod32_update так как в одном из следующих видео, я буду рассказывать о том, как написать скрипт для автоматического обновления антивируса NOD32. И давайте создадим какой-нибудь текстовый документ допустимым 123.txt.

Чтобы скопировать файл 123.txt на FTP-сервер вводим команду PUT c:nod32_update123.txt. Файл скопирован, можем проверить это командой DIR. Как вы видите, файл скопировался именно в ту папку, в которую мы перешли через команду CD.

Если нам необходимо скопировать все файлы с определенной папки на локальном компьютере в папку на FTP сервере, то нам необходимо указать текущий локальный каталог и каталог на сервере.

Каталог на сервере мы научились указывать, через команду CD

Локальный каталог указывается через команду LCD, если мы её наберем, то увидим, что текущий каталог — это папка с профилем текущего пользователя. А так как я собираюсь копировать файлы из другой папки то ввожу команду LCD ПУТЬ_К_НУЖНОЙ_ПАПКЕ

В чем суть, есть команда MPUT которая копирует файлы из локальной папки на удаленную и она не запрашивает какие именно это папки, поэтому нам эту информацию нужно сообщить.

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

Здесь у нас задаётся вопрос подтверждение для каждого файла хотим его скопировать или нет для этого живём Enter. Чтобы подобные подтверждение не выводились есть команда PROMT отключает интерактивный режим выключен.

Теперь попробуем сделать обратное действие, а именно скопировать все файлы с удаленной папки на FTP сервере в локальную. Делается это через команду MGET *.*.

Как видите всё отлично, в нашей папке появились все необходимые файлы и теперь мы можем закончить работу с FTP сервером через команду QUIT.