Разделение на уpовни и вычисление контpольной суммы UDP

Наблюдательные читатели заметят кажущееся пpотивоpечие между правилом разделения на уpовни и вычислением контpольной суммы. Напомним, что контpольная сумма UDP включает псевдо-заголовок, содеpжащий поля для IP-адpесов отпpавителя и получателя. Можно доказать, что IP-адpес получателя должен быть известен пользователю пpи посылке UDP-датагpаммы, и что пользователь должен передать его на уpовень UDP. Поэтому, уpовень UDP может получить IP-адpес, не взаимодействуя с уpовнем IP. Однако, IP-адpес источника зависит от выбpанного пути для датагpаммы, так как IP-адpес источника опpеделяет сетевой интерфейс, через который будет пеpедаваться датагpамма. Таким обpазом, UDP не может знать IP-адpес источника без контакта с уpовнем IP.

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

Наpушит ли явное взаимодействие между UDP и IP нашу главную пpедпосылку о том, что разделение на уpовни отpажает pазделение функций? Да. UDP тесно связан с IP пpотоколом. В данном случае налицо отход от принципа полного pазделения, сделанный по совеpшенно пpактическим пpичинам. Мы вынуждены наpушить принцип разделения на уpовни, так как невозможно полностью идентифицировать пpогpамму-получателя, не указав компьютеp получателя, и мы хотим сделать отображение адpесов, используемых UDP и IP эффективным. В одном из упpажнений в конце главы этот вопрос анализируется с другой точки зрения и в нем спpашивается, должны ли UDP и IP быть pазделены.

14-15. Протокол TFTP: принцип работы, команды. пример. FTP

TFTP - тоже протокол FTP, но поверх протокола UDP (т.е. протокол без гарантированной доставки). Может использоваться в локальной сети, где скорость передачи важнее. На практике используется редко.

Служба FTP (от протокола - File Transfer Protocol) - предназначена для обмена файлами.

FTP служба построена по хорошо известной схеме "клиент-сервер".

Клиент (браузер,Windows Commander, NetVampir...) посылает запросы серверу и принимает файлы.

Сервер FTP (vsftpd, IIS...) обрабатывает запросы клиента на получение файла.

Взаимодействие клиент и сервера по протоколу FTP.

Служба FTP базируется на двух стандартах:

o URL (Universal Resource Locator) - универсальный способ адресации ресурсов в сети;

o FTP (File Transfer Protocol) - протокол передачи файлов.

o Активный FTP выгоден для FTP-сервера, но вреден для стороны клиента. FTP сервер пытается соединиться со случайными высокими (по номеру) портами на клиенте, такое соединение наверняка будет блокировано брандмауэром на стороне клиента.

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

o 5.2.1.3 Примеры

o Ниже приведены примеры запроса клиента и ответа сервера:

o 5.2.1.3.1 Пример запроса на чтение каталога

o

o Установка соединения
Connecting to ftp.ru...
Connected to ftp.ru [194.87.5.52]

o
сервер: 220 megillah.demos.su FTP server (Version wu-2.4) ready. - // код ошибки, имя хоста, протокол, версия сервера, только для чтения
клиент: USER anonymous - // имя пользователя
сервер: 331 Guest login ok, send your complete e-mail address as password.- //код ошибки, имя пользователя корректно, нужен пароль
клиент: PASS ****** - // пароль клиента
сервер: 230 Guest login ok, access restrictions apply. - //код ошибки, пользователь идентифицирован, продолжайте
клиент: CWD / - // переход к корневой директории
сервер: 250 CWD command successful. - // команда выполнена успешно
клиент: TYPE A - // передавать информацию в текстовом виде
сервер: 200 Type set to A. - // текстовый тип установлен
клиент: PASV - // сервер должен определить нестандартный порт данных, начать его слушать
сервер: 227 Entering Passive Mode (194,87,5,52,9,75) - // сервер возвращает ip-адрес (194.87.5.52) и номер порта (2383)
клиент: LIST - // передать по соединению данных список имен файлов в директории
сервер: Data connection established - // установлено соединение данных
клиент: 150 Opening ASCII mode data connection for /bin/ls. - // татус файла правилен, подготавливается открытие канала

o Передача информации по каналу данных
сообщение: Data transfer started - // начало передачи информации
сообщение: DATA connection closed by remote server - // закрытие канала передачи данных

o Информирование клиентом пользователя
сообщение: Received 1 428 bytes in 0:00:00 (35 700 bytes/s) - // сколько байт получено ( 1 428 ), за какое время (ч.мм.сс) и с какой средней скоростью ( 35 700 bytes/s )
сообщение: JOB COMPLETED SUCCESSFULLY - // работа завершена

o 5.2.1.3.2 Пример запроса файла

o

o Установка соединения
Connecting to ftp.ru...
Connected to ftp.ru [194.87.5.52]

o
сервер: 220 megillah.demos.su FTP server (Version wu-2.4) ready. - // код ошибки, имя хоста, протокол, версия сервера, только для чтения
клиент: USER anonymous - // имя пользователя
сервер: 331 Guest login ok, send your complete e-mail address as password. - // имя пользователя корректно, нужен пароль
клиент: PASS ****** - // пароль клиента
сервер: 230 Guest login ok, access restrictions apply. - // пользователь идентифицирован, продолжайте
клиент: CWD /www.FAQ.win - // сменить каталог на /www.FAQ.win
сервер: 550 /www.FAQ.win: Not a directory. - // директория /www.FAQ.win не найдена
клиент: TYPE I - // передавать файл в бинарном виде
сервер: 200 Type set to I. - // бинарный тип установлен
клиент: STAT /www.FAQ.win - // запрос информации о файле /www.FAQ.win
сервер: 211-status of /www.FAQ.win: - // начало передачи информации
сервер: -rw-r--r-- 1 root root 31368 Jan 18 1999 /www.FAQ.win - // продолжение передачи информации
сервер: 211 End of Status - // конец передачи информации
клиент: PASV - // сервер должен определить нестандартный порт данных, начать его слушать
сервер: 227 Entering Passive Mode (194,87,5,52,9,79) - // сервер возвращает ip-адрес (194.87.5.52) и номер порта (2383)
клиент: REST 64 - // начать докачку файла, пропустив первые 64 байта
сервер: Data connection established - // установлено соединение данных
сервер: 350 Restarting at 64. (null) - // команда принята
клиент: REST 0 - // начать докачку файла, пропустив первые 0 байтов
сервер: 350 Restarting at 0. (null) - // команда принята
клиент: RETR /www.FAQ.win - // выдать файл www.FAQ.win
сервер: 150 Opening BINARY mode data connection for /www.FAQ.win (31368 bytes). - // статус файла правилен, подготавливается открытие канала данных, размер файла 31 368 байт

o Передача информации по каналу данных
сообщение: Data transfer started - // начало передачи файла
сообщение: DATA connection closed by remote server - // закрытие канала передачи данных

o Информирование клиентом пользователя
сообщение: Received 31 368 bytes in 0:00:02 (10 477 bytes/s) - // сколько байт получено ( 31 368 ), за какое время (ч.мм.сс) и с какой средней скоростью (10 477 bytes/s)
сообщение: JOB COMPLETED SUCCESSFULLY - // работа завершена

5.2.1.4 Некоторые команды

управления доступом
USER - имя пользователя
PASS - пароль
CWD - имя новой рабочей директории
CDUP - перейти на один уровень директории вверх
QUIT - выход

установки параметров передачи
PORT ip1,ip2,ip3,ip4,p1,p2 - IP адрес клиента (ip1,ip2,ip3,ip4) и порт (p1,p2) (расчет порта p1*256+p2=номер порта)
Пример:
Entering Passive Mode (194,87,5,52,9,79)
194.87.5.52 - IP адрес
2383 - номер порт, расчет порта 9*256+79=2383
PASV - сервер должен определить нестандартный порт данных, начать его слушать и вернуть ip-адрес и номер порта в формате PORT
TYPE { { A | E } [ N | T | C ] } | I | L размер-байта (по умолчанию - A N) - специфицирует тип информации

действия
RETR - имя файла (взять файл)
STOR - имя файла (передать файл)
REST - маркер (для докачки уже частично скаченного файла - обычно указывается смещение в байтах)
DELE - имя удаляемого файла
RMD - имя удаляемой директории
MKD - имя создаваемой директории
PWD - в ответе указать имя текущей директории
LIST [имя директории или файла] - передать по соединению данных список имен файлов в директории или информацию о файле
SYST - ответ должен содержать тип ОС сервера и др. полезную информацию
STAT - ответ содержать информацию о текущем состоянии сервера; если команда выдана в процессе передачи файла и предварена посылкой сигналов telnet-а IP и Synch, то ответ д. содержать информацию о состоянии пересылки
STAT имя файла - ответ должен содержать информацию о файле

прочее
HELP [имя команды] - описание работы данной команды
NOOP - пустая команда

5.2.1.5 Некоторые типы данных:

o ASCII (TYPE A) - передача текстовой информации

o IMAGE (TYPE I) - передача бинарных файлов