Blog literacki, portal erotyczny - seks i humor nie z tej ziemi
Оглавление темы 8 Польска
версия документа
8.4.2 Протокол FTP (обзор)
Содержание
Введение
История создания
Как это работает
Библиография
Вопросы и ответы
Введение
Протокол FTP был разработан для следующих целей:
для поддержки совместного использования файлов (компьютерные программы
и/или данные);
для поддержки неявного (используя программы) использования удаленных
компьютеров;
для актуализации версий програм на серверах файлов;
для точной и эффективной передачи файлов.
Хотя FTP может использоваться пользователем непосредственно на терминале,
этот протокол был создан с мыслью о использовании его программами.
Целью протокола является удовлетворение потребностей пользователей больших
и малых хостов, персональных рабочих станций с возможностью легкой реализации.
История создания
FTP имеет долгую историю создания. Первое раз механизм передачи файлов
был разработан в 1971 году и реализован для хоста на M.I.T. (см. RFC114
с коментариями в RFC141).
В RFC172 был описан ориентированный на пользователя протокол передачи
файлов между хостами (велючая терминал IMPs). В RFC265 и RFC281 были пересмотрены
некоторые аспекты. Использование "Set Data Type" было предложено
в RFC294 в январе 1972 года.
RFC354 заменил RFC264 и RFC265. File Transfer Protocol был теперь определен
как протокол для передачи между HOST-ами для сети ARPANET. Основной функцией
протокола была названа передача файлов эффективно и точно между хостами.
Эта функция должна была помочь в использовании удаленных серверов файлов.
Позднее появилось довольно большое количество документов RFC, посвященных
этому вопросу. Приведу лишь некоторые из них: RFC385, RFC414, RFC430. Первая
"официальная" версия протокола была опубликована в RFC454.
В июле 1983 года были исправлены некоторые неточности спецификации,
но структура осталась прежней. се эти изменения были отражены в RFC542
- новой "официальной" версии протокола.
В 1974 году были продолжены дискусси на тему FTP. В результате появились
следующие документы: RFC607, RFC614, RFC624, в 1975 - RFC686, RFC691.
В связи с переводом протокола нижнего уровня с NCP в TCP, появился новый
документ, описывающий стандарт: RFC765.
Последняя (какую смог найти автор этого документа) версия протокола
появилась в октябре 1985 года под номером RFC959. В ней были исправлены
некоторые неточности из RFC765 и введены некоторые необязательные для реализации
команды.
Как это работает
Рисунок, поданый ниже представляет структуру FTP сервиса:
Замечания: 1. Data Connection может использоваться в обу направлениях
2. Существование Data Connection не обязательно.
PI - интерпретатор протокола (Protocol Interpreter). Протокол со сторон
пользователя и сервера реализован по-разному в User-PI и Server-PI.
Server-PI - протокол сервера ожидает на порту Х соединения с User-PI
и устанавливает соединение. Он принимает стандартные FTP комманды от User-PI,
посылает ответы и управляет Server-DTP-ом.
User-PI - интерпретатор протокола пользователя является инициатором
устанавления соединения со своего порта Y с процессом Server-FTP, высылает
FTP-комманды и управляет User-DTP, если этот процесс появится в процессе
работы.
Server-DTP - процесс передачи данных (Data Transfer Process), в своем
нормальном "активном" состоянии устанавливает соединение "слушая"
порт данных. Он устанавливает параметры для передачи и приема и передает
данные с командами из Server-PI.
User-DTP - процесс передачи данных "слушает" порт данных
для соединения с процессом Server-FTP. Когда два сервера передают данные
между собой, User-DTP находится в неактивном состоянии.
В модели, представленной на рисунке, User-PI инициализирует control
connection, которое реализуется как в Telnet-протоколе. Команды, сформированные
пользователем, транслируются в User-PI и передаются процессу сервера через
control connection. Стандартные ответы пересылаются от Server-PI к UserPI
через control connection как реакция на команды.
Команды FTP определяют параметры для DATA-соединения (порт данных, вид
передачи, тип представления данных и структуру) и сущность операции (сохранение,
поиск, добавление, удаление и т.д.). User-DTP должен "слушать"
определенный порт данных, и сервер определит data connection и data-передатчик
(data-transfier) в соответствии с определенными параметрами. Следует отметить,
что порт данных (data port) не обязательно должен находиться на том самом
хосте, что передает комманды через управляющее соединение (control connection),
однако пользователь или процесс FTP-пользователя должен обеспечивать "слушание"
на определенным порте данных. Необходимо также отметить, что data соединение
(data connection) может использоваться для одновременной передачи и приема.
Может возникнуть ситуация, когда пользователь хочет переместить файлы
между двумя хостами, ни один из которых не является локальным.В этом случае
пользователь устанавливает управляющее соединение с двумя серверами и потом
организовывает data-соединение между ними. Таким образом, управляющая информация
проходит через User-PI, а данные передаются между процессами передачи данных
серверов. Ниже представлена диаграма подобного взаимодействия:
Протокол требует, чтобы управляющее соединение было открыто пока идет
передача данных. Пользователь сам должен запрашивать о закрытии управляющего
соединения, в то время как закрытием соединения будет заниматься сервер.
Сервер может закрыть передачу данных, если управляющие соединения были
закрыты без команды.
Отношения между FTP и Telnet
FTP использует Telnet протокол в управляющем соединении (control connection).
Это может быть достигнуто двумя способами:
User-PI или Server-PI могут иметь реализованными правила Telnet Protocol
непосредственно в собственных процедурах
User-PI или Server PI могут использовать внешний Telnet модуль.
Простая реализация, разделенный код и модульное программирование указывают
на второй способ. Еффективность и независимость указывают на первый метод.
В практике, FTP использует небольшую часть Telnet протокола, таким образом
реализация первого способа не должна быть трудна.
Библиография
RFC0959. File Transfer
Protocol (FTP). J. Postel, J. Reynolds, October 1985
Programowanie zastosowan sieciowych w systemie UNIX.
R. Stevens
Вопросы и ответы
Почему нет никакого исходного кода?
Дело в том, что реализация этого протокола не входит в ядро Linux'а.
Ну и потом, в заголовке ясно написано, что это только обзор. Описание протокола
занимает 69 страниц, приводить его все, да еще с примерами исходного кода
- это уже не будет обзор ;-)
Автор: Дмитрий Мажар