Загрузка...



  • 14.1 Введение
  • 14.2 Общедоступный и личный доступ FTP
  • 14.2.1 Вводный диалог
  • 14.3 Модель FTP
  • 14.4 Команды FTP
  • 14.4.1 Использование команд в текстовом диалоге
  • 14.5 Типы данных, структуры файлов и методы пересылки
  • 14.5.1 Типы данных
  • 14.5.2 Пересылка текста ASCII
  • 14.5.3 Пересылка текста EBCDIC
  • 14.5.4 Пересылка двоичных данных
  • 14.5.5 Структуры файлов
  • 14.5.6 Режимы пересылки
  • 14.6 Протокол FTP
  • 14.6.1 Команды управления доступом
  • 14.6.2 Команды управления файлами
  • 14.6.3 Команды установки формата данных
  • 14.6.4 Команды пересылки файлов
  • 14.6.5 Дополнительные команды
  • 14.6.6 Команды сайта
  • 14.6.7 Восстановления после ошибок и перезапуск
  • 14.6.8 Коды ответов
  • 14.7 Безопасность
  • 14.7.1 Проверка имен хоста клиента
  • 14.7.2 PASV или PORT?
  • 14.7.3 Промежуточные прокси
  • 14.8 Замечания о производительности
  • 14.9 Trivial File Transfer Protocol
  • 14.9.1 Протокол TFTP
  • 14.9.2 Элементы данных протокола TFTP
  • 14.9.3 Варианты TFTP
  • 14.9.4 Сценарий TFTP
  • 14.10 Дополнительная литература
  • Глава 14

    Протокол FTP

    14.1 Введение

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

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

    ■ Различные правила именования файлов

    ■ Различные правила перемещения по каталогам файловой системы

    ■ Ограничения на доступ к файлам

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

    Разработчики стека протоколов TCP/IP старались найти не слишком сложное решение этих проблем и создали достаточно общий, но очень элегантный протокол пересылки файлов (File Transfer Protocol — FTP), который легко обслуживается и прост в использовании.

    Протокол FTP создан для взаимодействия с интерактивным конечным пользователем или прикладной программой. Мы ограничимся рассмотрением интерактивных служб этого протокола для конечного пользователя, всегда доступных во всех реализациях TCP/IP.

    Пользовательский интерфейс разработан для клиента пересылки файлов операционной системы Berkeley Unix (BSD) и далее перенесен на различные типы многопользовательских компьютеров. В этой главе мы рассмотрим диалоги конечного пользователя с текстовым интерфейсом, а также несколько графических интерфейсов для настольных компьютеров.

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

    В конце главы мы проанализируем простейший протокол пересылки файлов (Trivial File Transfer Protocol — TFTP), использующийся в базовых операциях по переносу файлов в определенных ситуациях, например при загрузке программного обеспечения в маршрутизаторы, мосты или бездисковые рабочие станции.

    14.2 Общедоступный и личный доступ FTP

    Компьютерные системы обычно требуют от пользователя идентификатор регистрации и пароль до того, как разрешить пользователю просматривать или манипулировать файлами. Однако иногда полезно создать возможность работы с общедоступными файлами. FTP обеспечивает как общедоступное совместное использование информации, так и частный доступ к файлам, предлагая два вида услуг:

    ■ Доступ к общедоступным файлам через анонимную регистрацию

    ■ Доступ к личным файлам, разрешенный только для пользователя с системным идентификатором регистрации и паролем

    14.2.1 Вводный диалог

    Представленный ниже диалог демонстрирует копирование из сайта AT&T InterNIC Data Services (общедоступного репозитария документов RFC).

    Сегодня многие имеют на своих настольных системах графические пользовательские интерфейсы (GUI) для пересылки файлов. С одним из таких интерфейсов мы познакомимся ниже. Однако текстовый интерфейс позволяет лучше понять происходящие в процессе пересылки файлов события, поэтому сначала мы познакомимся с подключением к InterNIC через текстового клиента.

    Архив файлов InterNIC доступен для всех, так что при регистрации мы будем вводить идентификатор ftp. Традиционно обращение к общедоступным системам происходило через идентификатор анонимного (anonymous) доступа. В настоящее время больше применяется ftp, который легче напечатать. Общедоступные серверы для пересылки файла предполагают ввод пользователем адреса электронной почты в качестве пароля.

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

    > ftp ftp.internic.net              
    Команда ftp запускает пользовательский

     интерфейс программы-клиента FTP. Пользователь хочет соединиться с удаленным хостом ftp.intemic.net

    Connected to ftp.ds.internic.net.   
    Локальный клиент FTP отчитывается

     об успешном соединении.

    220- InterNIC Directory and

    Database Services                   
    Это сообщение пришло от удаленной системы.

    220- . . .                           
    Мы опустим приветствие.

    220 ds.internic.net FTP server ready.

    Name (ftp.internic.net:sfeit) : ftp 
    Локальная клиентская программа FTP

     запрашивает ввод идентификатора пользователя. Для InterNIC нужно ввести ftp.

    331 Guest login ok, send ident

    as password.

    Password:                           
    Локальная клиентская программа FTP

     запрашивает пароль. Вежливый ответ подразумевает ввод идентификатора электронной почты.

    230 Guest login ok, access restrictions apply.

    Ftp>                                
    Это приглашение запрашивает ввод команд.

    ftp> cd rfc                         
    Пользователь переходит в удаленный каталог rfc,

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

    250 CWD command successful.         
    Команда изменения каталога (cd) пересылается

     на сервер как CWD (изменить рабочий каталог). Каталог сервера изменяется на rfc, и можно начинать копирование документов RFC.

    ftp> get rfc1842.txt myrfc           
    Запрашивается копирование файла rfc1842.txt,

     для чего будет создано второе соединение.

    200 PORT command successful.        
    Локальный клиент FTP получил второй порт

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

    150 Opening ASCII mode data

    connection for rfc1842.txt

    (24143 bytes).                       
    Открытие соединения для пересылки файла.

    226 Transfer complete.              
    Завершение пересылки файла.

    local: newfile remote: rfcl842.txt  
    Создан новый локальный файл.

    24818 bytes received in 0.53 seconds

    (46 Kbytes/s)

    ftp> quit                           
    Завершение сеанса.

    221 Goodbye.

    Первая команда запрашивала у сервера переход в каталог rfc. Затем проведено копирование удаленного документа rfcl842.txt в локальный файл, названный myrfc. Если не вводить имя файла, локальный файл получит то же имя, что и удаленный файл.

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

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

    200 PORT command successful.

    150 Opening ASCII mode data connection for rfcl842.txt (24143 bytes).

    На рис. 14.1 показан доступ к другому общедоступному архиву, но через приложение для пересылки файлов Chameleon (в среде Windows), имеющее графический пользовательский интерфейс.

    Рис. 14.1. Доступ к архиву пересылки файлов из программы Chameleon

    Файлы могут копироваться перетаскиванием их значков из одного окна в другое или щелчком мыши на кнопке со стрелкой. Имя локального файла можно ввести в окне слева, расположенном ниже метки Files.

    К тому же самому сайту можно обратиться и из клиента пересылки файлов Netscape (см. рис. 14.2). Копирование файла выполняется щелчком мыши на его имени. Текстовые файлы выводятся на экран, и их можно сохранить на локальном компьютере через пункт Save меню File. Если запрашивается локальное сохранение двоичного файла, то выводится раскрывающееся меню с запросом о месте хранения этого файла.

    Рис. 14.2. Доступ к архиву пересылки файлов из Netscape

    14.3 Модель FTP

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

    В сущности, управляющее соединение — это обычный сеанс telnet в режиме NVT. Клиент отправляет команду на сервер через управляющее соединение, а сервер возвращает ответ по этому же соединению.

    Когда пользователь запрашивает пересылку файла, открывается отдельное соединение для передачи данных, и по нему пересылается файл. Это соединение используется и для пересылки содержимого каталогов. Модель FTP показана на рис. 14.3. Обычно сервер использует порт 20 для соединения пересылки данных.

    Рис. 14.3. Управляющее соединение и соединение пересылки данных в FTP

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

    14.4 Команды FTP

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

    Команды пересылки файлов позволяют:

    ■ Копировать одиночный файл между хостами

    ■ Копировать несколько файлов между хостами

    ■ Добавлять содержимое локального файла к удаленному файлу

    ■ Копировать файл и добавлять к его имени номер для формирования уникального имени (например, файлы ежедневной регистрации получат имена log.1, log.2 и т.д.)

    Команды обслуживания файлов разрешают:

    ■ Просмотреть список файлов каталога

    ■ Узнать текущий каталог и изменить его на другой

    ■ Создавать и удалять каталоги

    ■ Переименовывать или удалять файлы

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

    ■ Идентификации пересылки файлов ASCII, EBCDIC или двоичных файлов

    ■ Проверки структурирования файла (как последовательность байт или как последовательность записей)

    ■ Указания способа пересылки файла (например, как поток октетов)

    Пересылаемые по управляющему соединению команды имеют стандартный формат. Например, команда RETR используется для копирования файла из сервера на сайт клиента.

    FTP не накладывает ограничений на пользовательский интерфейс, поэтому разработчики могут создавать (как мы уже видели) хитроумные системы для настольных компьютеров либо простые в применении клиентские программы. Т.е. ввод с клавиатуры get, перетаскивание мышью значка или щелчок на имени файла транслируются в одну и ту же команду RETR.

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

    ■ Запросить FTP о выводе звукового сигнала при завершении пересылки файла

    ■ Для текстового интерфейса запросить вывод символа диез (#) при пересылке каждого блока данных

    ■ Установить автоматическое преобразование регистра символов в имени файла или таблицу трансляции символов

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

    14.4.1 Использование команд в текстовом диалоге

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

    Нижеприведенный текстовый диалог начинается с вывода справки. Существующие команды имеют синонимы, например ls и dir — для запроса сведений о каталоге, put и send — для копирования файла на удаленный хост, get и recv — для получения файла от удаленного хоста или bye и quit — для выхода из FTP.

    Используя команды mget или mput и глобальные подстановочные символы можно одновременно копировать несколько файлов. Например, mget а* извлечет копии каждого файла с именем, начинающимся на букву а. Такой режим включается параметром glob, который разрешает или запрещает применение глобальных подстановочных символов.

    В представленный ниже диалог включен вывод отладочной информации, чтобы дать некоторое представление о работе протокола:

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

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

    plum-feit > ftp

    ftp> help

    Commands may be abbreviated. Commands are:

    !       cr         macdef  proxy     send

    $       delete     mdelete sendport   status

    account debug      mdir    put        struct

    append  dir        mget    pwd        sunique

    ascii   disconnect mkdir   quit       tenex

    bell    form       mls     quote      trace

    binary  get        mode    recv       type

    bye     glob       mput    remotehelp user

    case    hash       nmap    rename     verbose

    cd      help       ntrans  reset      ?

    cdup    led        open    rmdir

    close   ls         prompt  runique


    ftp> debug

    Debugging on (debug = 1).


    ftp> open tigger.jvnc.net

    Connected to tigger.jvnc.net.

    220 tigger.jvnc.net FTP server (Version wu-2.4(1) Fri Apr 15 13:54:36 EDT 1994)

    ready.

    Для обращения к личным файлам введены реальные идентификатор пользователя (userid) и пароль.

    Name (tigger.jvnc.net:sfeit): feit

    --> USER feit

    331 Password required for feit.

    Password:

    --> PASS abcd1234

    230 User feit logged in.

    Команда status (статус) показывает текущие параметры сеанса FTP. Многие из них будут рассмотрены ниже. Пока отметим, что тип данных (Type) указан как ASCII. При пересылке текстовых файлов FTP часто предполагает это значение по умолчанию.

    ftp> status

    Connected to tigger.jvnc.net.

    No proxy connection.

    Mode: stream; Type: ascii; Form: non-print; Structure: file

    Verbose: on; Bell: off; Prompting: on; Globbing: on

    Store unique: off; Receive unique: off

    Case: off; CR stripping: on

    Ntrans: off

    Nmap: off

    Hash mark printing: off; Use of PORT cmds: on

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

    ftp> dir

    FTP необходим порт для пересылки данных. Клиент посылает команду PORT, которая идентифицирует его IP-адрес (4 байта) и новый порт (2 байта), чтобы использовать эти значения при пересылке данных. Байты преобразуются в десятичный формат и разделяются запятыми. IP-адрес 128.36.4.22 будет записан как 128,36,4,22, а порт 2613 — как 10,53.

    --> PORT 128,36,4,22,10,53

    200 PORT command successful.

    Сервер откроет соединение по указанному адресу socket. Команда LIST — это формальное сообщение для запроса подробного списка файлов каталога:

    --> LIST

    Далее сервер открывает соединение с объявленным клиентом портом:

    150 Opening ASCII mode data connection for /bin/ls.

    total 531

    -rw-r-r- 1 feit tigers 0 Oct 24 1994 .addressbook

    -rw-r-r- 1 feit tigers 2808 Sep 23 1994 .article

    -rw-r-r- 1 feit tigers 397 Mar 14 1993 .cshrc

    . . .

    -rw-r-r- 1 feit tigers 3113 Jul 31 13:29 subnets

    -rw-r-r- 1 feit tigers 59901 Jun 5 17:48 typescript

    226 Transfer complete.

    2239 bytes received in 0.31 seconds (7 Kbytes/s)

    Сразу после пересылки списка файлов соединение данных будет закрыто. Затем мы можем получить файл.

    ftp> get subnets

    Клиент указывает новый адрес socket для переноса файла. Отметим, что на сей раз используется клиентский порт 2614 (10,54).

    --> PORT 128,36,4,22,10,54

    200 PORT command successful.

    --> RETR subnets

    150 Opening ASCII mode data connection for subnets (3113 bytes).

    226 Transfer complete.

    По завершении пересылки файла соединение для данных закрывается.

    local: subnets remote: subnets

    3187 bytes received in 0.27 seconds (11 Kbytes/s)

    ftp> quit

    --> QUIT

    221 Goodbye.

    plum-feit>

    Отметим, что сценарий для соединения данных был таким:

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

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

    ■ Данные были переданы.

    ■ Соединение было закрыто.

    Можно применять альтернативный сценарий. Если клиент посылает команду PASV, сервер возвращает номер порта и переходит к прослушиванию установки соединения данных от клиента. Ранее преобладало использование команды PORT. Однако теперь клиент может послать команду PASV для пересылки файлов через простую систему защиты (firewall), которая не разрешает установку соединений из поступающих сообщений (этот вариант будет подробно рассмотрен чуть позже).

    При работе с файлами большого размера иногда обнаруживается, что пересылается не тот файл. Хорошая реализация должна позволять отменить пересылку. Для текстового интерфейса это обычно делается через комбинацию клавиш CONTROL-C, а в графическом интерфейсе — специальной кнопкой Abort (остановить).

    14.5 Типы данных, структуры файлов и методы пересылки

    На обоих концах соединения необходимо обеспечить единый формат для пересылаемых данных. Этот файл текстовый или двоичный? Он структурирован по записям или по блокам?

    Для описания формата пересылки используются три атрибута: тип данных (data type), структура файла (file structure) и режим пересылки (transmission mode). Допустимые значения этих атрибутов рассмотрены ниже. В общем случае применяются:

    ■ Пересылка текста ASCII или двоичных данных.

    ■ Неструктурированный файл, который рассматривается как последовательность байт.

    ■ Режим пересылки рассматривает файл как поток байт.

    Однако есть и несколько исключений. Некоторые хосты структурируют текстовые файлы как последовательность записей. Хосты IBM используют для текстовых файлов кодирование EBCDIC и проводят обмен файлами как набором структурированных блоков, а не как потоком байт.

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

    14.5.1 Типы данных

    Файл может содержать текст ASCII, EBCDIC или двоичный образ данных (существует еще тип, называемый локальным или логическим байтом и применяемый для компьютеров с размером байта в 11 бит). Текстовый файл может содержать обычный текст или текст, форматированный для вывода на принтер. В последнем случае в нем будут находиться коды вертикального форматирования:

    ■ Символы вертикального форматирования Telnet для режима NVT (т.е. <CR>, <LF>, <NL>, <VT>, <FF>)

    ■ Символы вертикального форматирования ASA (ФОРТРАН)

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

    14.5.2 Пересылка текста ASCII

    Хотя текст ASCII является стандартным, компьютеры интерпретируют его по-разному из-за различия в кодах конца строки. Системы Unix используют для этого <LF>, компьютеры PC — <CR><LF>, a Macintosh — <CR>.

    Для устранения этих различий FTP превращает локальный текстовый файл ASCII в формат NVT, а приемник преобразует NVT ASCII в собственный локальный формат. Например, если текстовый файл копируется с системы Unix на PC, все коды концов строк (в Unix — <LF>) при получении файла на PC нужно преобразовать в <CR><LF>.

    14.5.3 Пересылка текста EBCDIC

    Поддерживающие кодировку EBCDIC хосты обеспечивают весьма полезную команду пользовательского интерфейса, инициирующую пересылку по управляющему соединению команды TYPE Е. Текстовые символы EBCDIC пересылаются по соединению в своем обычном 8-разрядном формате. Строки завершаются символом новой строки EBCDIC (<NL>).

    14.5.4 Пересылка двоичных данных

    С пересылки текстов ASCII легко переключиться на двоичный образ данных. В текстовом пользовательском интерфейсе для этого служит команда binary, а в графическом — командная кнопка binary (двоичные данные). Клиент меняет тип пересылаемых данных командой TYPE I, передаваемой по управляющему соединению.

    Что произойдет, если пользователь забудет переключить тип данных с ASCII на двоичный при копировании двоичного файла? Хорошие реализации FTP предупредят, что задана ошибочная операция, и позволят до начала пересылки файла изменить тип данных. К сожалению, многие реализации идут еще дальше и "помогают" изменять все двоичные байты, которые выглядят как символы конца строк (исправляя их на специальные заполнители или полностью удаляя их из текста). Некоторые действительно плохие реализации все же начинают пересылку файла и аварийно завершаются в середине выполнения такой операции.

    14.5.5 Структуры файлов

    В FTP поддерживаются две структуры (ранее использовалась также страничная структура для файлов DEC TOPS-20, сейчас устаревшая):

    ■ Файловая структура, соответствующая неструктурированному файлу, который рассматривается как последовательность байт.

    ■ Структура записей, которая применяется для файлов, состоящих из последовательности записей.

    Более распространена файловая структура, которая применяется по умолчанию. Перейти на структуру записей можно стандартной командой STRU R, пересылаемой по управляющему соединению.

    14.5.6 Режимы пересылки

    Режим пересылки и структура файла определяют, как будут форматированы данные для обмена по соединению. Существуют три режима пересылки: stream (поток), block (блочный режим) и compressed (сжатые данные).

    ■ В режиме потока и файловой структуры файл передается как поток байт. FTP возлагает на TCP обеспечение целостности данных и не включает в данные никаких заголовков или разделителей. Единственным способом указания на конец файла будет нормальное завершение соединения для данных.

    ■ Для режима потока и структуры записей каждая запись отделяется 2-байтовым управляющим кодом конца записи (End Of Record — EOR), а конец файла отмечается символами конца файла (End Of File — EOF). EOR кодируется как X'FF 01, a EOF — X'FF 02. Для последней записи файла EOR и EOF записываются как X'FF 03. Если файл содержит байт данных из одних единиц, то такой байт представляется при пересылке как X'FF FF.

    ■ В блочном режиме файл пересылается как последовательность блоков данных. Каждый блок начинается 3-байтовым заголовком (см. рис. 14.4).

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

    Рис. 14.4. Формат заголовка блочного режима пересылки FTP

    Блок может содержать целую запись, или в записи объединяются несколько блоков. Дескриптор содержит:

    ■ Флаг End Of Record для идентификации границы записи

    ■ Флаг End Of File, который указывает, является ли блок последним при пересылке файла

    ■ Флаг Restart Marker (маркер перезапуска), указывающий, содержит ли данный блок текстовую строку, которую можно использовать для указания точки перезапуска после неудачной пересылки файла в более поздней точке

    Режим потока наиболее распространен и используется по умолчанию. Изменить его на блочный режим можно стандартной командой MODE В, пересылаемой по управляющему соединению.

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

    В показанном ранее диалоге ответ на команду status содержал:

    Mode: stream; Type: ascii; Form: non-print; Structure: file

    Т.е. по умолчанию был установлен поточный режим пересылки данных, тип данных ASCII без форматирования для печати и файловая структура (соответствующая неструктурированному файлу).

    14.6 Протокол FTP

    С протоколом FTP связаны следующие понятия:

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

    ■ Числовые коды, возвращенные в ответ на команду

    ■ Формат пересылаемых данных

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

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

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

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


    Таблица 14.1 Команды авторизации пользователя для доступа к архиву файлов

    Команда Определение Параметр(ы)
    USER Идентифицирует пользователя Идентификатор пользователя
    PASS Ввод пароля Пароль
    ACCT Указание регистрационной записи пользователя Идентификатор регистрационной записи
    REIN Повторная инициализация для указания состояния Нет
    QUIT Выход Нет
    ABOR Отмена предыдущей команды и запущенной этой командой пересылки данных Нет

    14.6.2 Команды управления файлами

    Команды из таблицы 14.2 дают возможность выполнять типичные операции позиционирования на каталог и управления файлами удаленного хоста. Рабочим каталогом (working directory) называется текущий каталог пользователя.


    Таблица 14.2 Команды выбора каталога и управления файлами

    Команда Определение Параметр(ы)
    CWD Перейти в другой каталог сервера Имя каталога
    CDUP Перейти в родительский каталог Нет
    DELE Удалить файл Имя файла
    LIST Вывести информацию о файлах Имя каталога, список файлов (без параметра — вывод информации о рабочем каталоге)
    MKD Создать каталог Имя каталога
    NLST Вывести список файлов каталога Имя каталога (для рабочего каталога может отсутствовать)
    PWD Вывести имя рабочего каталога Нет
    RMD Удалить каталог Имя каталога
    RNFR Указать файл, который будет переименован Имя файла
    RNTO Переименовать файл Имя файла
    SMNT Монтировать другую файловую систему Идентификатор (Identifier)

    14.6.3 Команды установки формата данных

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


    Таблица 14.3 Команды описания типа, структуры и режима

    Команда Определение Параметр(ы)
    TYPE Указание типа данных и необязательного формата вывода на принтер A (ASCII), Е (EBCDIC), 1 (двоичный образ), N (не распечатываемые), Т (telnet), С (ASA).
    STRU Структура файла F (файл) или R (записи)
    MODE Формат пересылки S (поток), В (блок) или С (сжатие)

    14.6.4 Команды пересылки файлов

    Команды из таблицы 14.4 применяются с целью установки соединения для данных, копирования файлов и восстановления при перезапуске.


    Таблица 14.4 Команды поддержки пересылки файлов

    Команда Определение Параметр(ы)
    ALLO Выделяет (резервирует) достаточное пространство для поступающих данных Целое число байт
    APPE Добавляет локальный файл в конец удаленного файла Имя файла
    PASV Запрашивает у сервера IP-адрес и порт для инициализируемого клиентом соединения пересылки данных. Нет. Сервер возвратит IP-адрес и номер порта
    PORT Идентифицирует сетевой адрес и номер порта для инициируемого сервером соединения IP-адрес и номер порта
    REST Устанавливает маркер перезапуска (вводится сразу за перезапускаемой командой пересылки) Значение маркера
    RETR Извлечение или получение файла Имя файла (файлов)
    STOR Сохранение или помещение файла Имя файла (файлов)
    STOU Сохранение файла с уникальным именем Имя файла

    14.6.5 Дополнительные команды

    Последний набор команд (таблица 14.5) выводит конечному пользователю полезную информацию.


    Таблица 14.5 Дополнительные информационные команды

    Команда Определение Параметр(ы)
    HELP Вывод сведений о реализованных на сервере возможностях Нет
    NOOP Запрос от сервера ответа OK Нет
    SITE Используется для специфичных серверных подкоманд, которые не стандартизованы, но могут быть доступны на данном сервере Нет
    SYST Запрос к серверу о типе его операционной системы Нет
    STAT Запрос информации о параметрах и состоянии соединения Нет

    14.6.6 Команды сайта

    Многие файловые серверы Unix используют программное обеспечение WU-FTP от Вашингтонского университета (Сент-Луис). Эта реализация имеет команду SITE для выполнения на файловом сервере различных специальных программ. Например, пользователь может сначала получить доступ по идентификатору ftp, а затем указать в команде SITE регистрационный идентификатор группы и пароль. В этом случае обеспечивается доступ к большему числу файлов, чем при анонимном доступе.

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

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

    В блочном режиме работы FTP и при реализации службы перезапуска пересылающая информацию сторона может передавать блоки, содержащие в нужных местах общего потока данных маркеры перезапуска. Каждый маркер представляет собой распечатываемую строку текста. Например, последовательные маркеры могли бы быть: 1, 2, 3 и т.д. Всякий раз, когда приемник получает маркер, он записывает принятые данные на энергонезависимое устройство хранения и отслеживает положение маркера в общем потоке данных.

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

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

    14.6.8 Коды ответов

    Каждой команде в диалоге соответствует ответ, состоящий из кода ответа и сообщения. Например:

    ftp> get subnets

    --> PORT 128,36,0,22,10,54

    200 PORT command successful.

    --> RETR subnets

    150 Opening ASCII mode data connection for subnets (3113 bytes).

    226 Transfer complete.

    Коды ответов состоят из трех цифр, каждая из которых имеет определенное назначение:

    ■ Коды от 200 до 300 указывают на успешное выполнение команды.

    ■ Коды от 100 до 200 указывают на начало выполнения операции.

    ■ Коды от 300 до 400 указывают на успешное достижение промежуточной точки.

    ■ Коды от 400 до 500 сигнализируют о временной ошибке.

    ■ Коды от 500 свидетельствуют о постоянной ошибке (это плохие новости).

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

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

    14.7.1 Проверка имен хоста клиента

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

    Некоторые файловые серверы запрещают доступ клиентам, которые не перечислены в базе данных DNS. Сервер FTP может выполнять обратный поиск для всех входных IP-адресов. Если такого адреса нет в базе данных DNS — доступ блокируется. Единственным решением такой проблемы может быть обращение к администратору DNS для включения имени системы в базу данных. Некоторые серверы производят двойную проверку — транслируют адрес клиента в имя, а затем полученное имя опять в адрес для сравнения его с исходным адресом запроса. Благодаря этому исключаются обращения с подстановочными символами для элементов DNS.

    14.7.2 PASV или PORT?

    Организации обеспечивают безопасность своих сетей через средства защиты (firewall), применяющие к датаграммам определенный критерий фильтрации и ограничивающие входящий трафик. Часто простейшие средства защиты разрешают пользователям локальной сети инициировать соединение, но блокируют все попытки создания соединения извне.

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

    К счастью, новые реализации поддерживают команду PASV, указывающую серверу на выделение нового порта для соединения данных с пересылкой IP-адреса и номера порта сервера в ответе клиенту. Далее клиент может самостоятельно открыть соединение с сервером.

    14.7.3 Промежуточные прокси

    Некоторые организации создают более изощренные системы безопасности. Каждый запрос реально пересылается на промежуточный прокси, реализующий систему зашиты локальной сети. Прокси становится единственной системой, которая будет видна из внешнего мира. Для работы через прокси клиент предоставляет:

    ■ Имя или IP-адрес прокси

    ■ Идентификатор пользователя и пароль для получения доступа к прокси

    ■ Номер порта для доступа к прокси пользователям пересылки файлов (необязательно порт 21)

    ■ Дополнительную информацию, зависящую от конкретной реализации данного прокси-агента

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

    Рис. 14.5. Конфигурирование клиента для работы через средство защиты

    14.8 Замечания о производительности

    На эффективность операций пересылки файлов влияют следующие факторы:

    ■ Файловая система хоста и производительность его дисков

    ■ Объем обработки по переформатированию данных

    ■ Используемая служба TCP

    Краткий отчет о пропускной способности приводится в конце каждой пересылки файла:

    226 Transfer complete

    local: rfc1261 remote: rfc1261

    4488 bytes sent in 0.037 seconds (1.2e + 02 Kbytes/s)

    Средние значения производительности FTP и TCP можно получить при пересылке больших файлов.

    14.9 Trivial File Transfer Protocol

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

    Простейший протокол пересылки файлов (Trivial File Transfer Protocol — TFTP) используется как очень полезное средство копирования файлов между компьютерами. TFTP передает данные в датаграммах UDP (при реализации в другом стеке протоколов TFTP должен запускаться поверх службы пакетной доставки данных). Для этого не потребуется слишком сложное программное обеспечение — достаточно только IP и UDP. Особенно полезен TFTP для инициализации сетевых устройств (маршрутизаторов, мостов или концентраторов).

    Характеристики TFTP:

    ■ Пересылка блоков данных размером в 512 октетов (за исключением последнего блока)

    ■ Указание для каждого блока простого 4-октетного заголовка

    ■ Нумерация блоков от 1

    ■ Поддержка пересылки двоичных и ASCII октетов

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

    ■ Отсутствие ограничений по аутентификации пользователей

    Один из партнеров по TFTP пересылает нумерованные блоки данных одинакового размера, другой партнер подтверждает их прибытие сигналом ACK. Отправитель ожидает ACK для посланного блока до того, как пошлет следующий блок. Если за время тайм-аута не поступит ACK, выполняется повторная отправка того же самого блока. Аналогично, если к получателю не поступят данные за время тайм-аута, он отправляет еще один ACK.

    14.9.1 Протокол TFTP

    Сеанс TFTP начинается запросами Read Request (запрос чтения) или Write Request (запрос записи). Клиент TFTP начинает работу после получения порта, посылая Read Request или Write Request на порт 69 сервера. Сервер должен идентифицировать различные номера портов клиентов и использовать их для последующей пересылки файлов. Он направляет свои сообщения на порт клиента. Пересылка данных производится как обмен блоками данных и сообщениями ACK.

    Каждый блок (за исключением последнего) должен иметь размер в 512 октетов данных и завершаться EOF (конец файла). Если длина файла кратна 512, то заключительный блок содержит только заголовок и не имеет никаких данных. Блоки данных нумеруются от единицы. Каждый ACK содержит номер блока данных, получение которого он подтверждает.

    14.9.2 Элементы данных протокола TFTP

    В TFTP существуют пять типов элементов данных:

    ■ Read Request (RRQ, запрос чтения)

    ■ Write Request (WRQ, запрос записи)

    ■ Data (DATA, данные)

    ■ Acknowledgment (ACK, подтверждение)

    ■ Error (ERROR, ошибка)

    Сообщение об ошибке указывает на события, подобные таким: "файл не найден" или "для записи файла на диске нет места".

    Каждый заголовок TFTP начинается операционным кодом, идентифицирующим тип элемента данных протокола (Protocol Data Unit — PDU). Форматы PDU показаны на рис. 14.6.

    Рис. 14.6. Форматы элементов данных TFTP

    Отметим, что длина Read Request и Write Request меняется в зависимости от длины имени файла и полей режима, каждое из которых представляет собой текстовую строку ASCII, завершенную нулевым байтом. В поле режима могут присутствовать netascii (сетевой ASCII) или octet (октет).

    14.9.3 Варианты TFTP

    Улучшенный вариант TFTP разрешает согласование параметров через предварительные запросы чтения и записи. Его основная цель — позволить клиенту и серверу согласовывать между собой размер блока, когда он больше 512 байт (для увеличения эффективности пересылки данных).

    14.9.4 Сценарий TFTP

    Работу протокола TFTP можно проиллюстрировать простым сценарием. На рис. 14.7 показано, как в TFTP реализуется чтение удаленного файла. После отправки запрашиваемой стороной блока данных она переходит в режим ожидания ACK на посланный блок и, только получив этот ACK, посылает следующий блок данных.

    Рис. 14.7. Чтение удаленного файла в TFTP

    14.10 Дополнительная литература

    Протокол FTP определен в RFC 959, a TFTP — в RFC 1350.








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх