Компьютерные системы обычно требуют от пользователя идентификатор регистрации и пароль до того, как разрешить пользователю просматривать или манипулировать файлами. Однако иногда полезно создать возможность работы с общедоступными файлами. 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

 

Какие команды можно передавать по управляющему соединению? Существуют команды аутентификации, дающие возможность пользователю указать идентификатор, пароль и регистрационную запись для работы с 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 (остановить).

 

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

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

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

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

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

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

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

 

14.5.1 Типы данных

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

■ Символы вертикального форматирования Telnet для режима NVT (т.е. , , , , )

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

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

 

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

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

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

 

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

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

 

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 без форматирования для печати и файловая структура (соответствующая неструктурированному файлу).

 

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

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

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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.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. Конфигурирование клиента для работы через средство защиты

 

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

Простейший протокол пересылки файлов (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