Протоколы передачи и получения данных

Размещено на http://www.allbest.ru/

20

Тема 1. Протокол UDP

UDP (англ. User Datagram Protocol - протокол пользовательских датаграмм) - это транспортный протокол для передачи данных в сетях IP без установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. Его IP-идентификатор - 0x11.

В отличие от TCP, UDP не гарантирует доставку пакета, поэтому аббревиатуру иногда расшифровывают как Unreliable Datagram Protocol (протокол ненадёжных датаграмм). Это позволяет ему гораздо быстрее и эффективнее доставлять данные для приложений, которым требуется большая пропускная способность линий связи, либо требуется малое время доставки данных.

Формат сообщений UDP

Единица данных протокола UDP называется UDP-пакетом или пользовательской дейтаграммой (user datagram). UDP-пакет состоит из заголовка и поля данных, в котором размещается пакет прикладного уровня. Заголовок имеет простой формат и состоит из четырех двухбайтовых полей:

· UDP source port - номер порта процесса-отправителя,

· UDP destination port - номер порта процесса-получателя,

· UDP message length - длина UDP-пакета в байтах,

· UDP checksum - контрольная сумма UDP-пакета

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

Состав UDP-датаграммы

Первые 64 бита (8 байт) датаграммы представляют собой UDP-заголовок, остальные биты - данные сообщения:

Биты	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0-31	Порт отправителя (Source port)	Порт получателя (Destination port)
32-63	Длина датаграммы (Length)	Контрольная сумма (Checksum)
64-...	Данные (Data)

Значение поля «длина датаграммы» указывает на длину всего UDP-сообщения, то есть включая и UDP-заголовок. Измеряется в октетах (байтах).

Максимальная длина данных

Для вычисления максимальной длины данных в UDP-сообщении необходимо учесть, что UDP-сообщение в свою очередь является содержимым области данных IP-сообщения. Максимальная длина IP-сообщения (с учетом заголовка) равна 65535 октетов. Потому максимальная длина UDP-сообщения (за вычетом минимального IP-заголовка) равна 65535 ? 20 = 65515 октетов. Длина заголовка UDP-сообщения равна 8 октетам, следовательно, максимальная длина данных в UDP-сообщении равна 65515 ? 8 = 65507 октетов. На практике невозможно использовать максимальную величину IP пакета, так как такой размер превышает MTU любого протокола канального уровня, поэтому обычно используется размер, соотнесенный с MTU используемого канального протокола.

Октеты	IP-сообщение
65535	20	Минимальный IP-заголовок
	65515	Данные IP-сообщения: UDP-сообщение 8 UDP-заголовок 65507 Данные UDP-сообщения

Псевдозаголовок

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

Биты	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0-31	IP-адрес отправителя (Source address)
32-63	IP-адрес получателя (Destination address)
64-95	0	0	0	0	0	0	0	0	Протокол (Protocol)	Длина UDP-датаграммы (UDP length)

Поле «протокол» содержит в себе значение 17 (00010001 в двоичном виде, 0x11 - в шестнадцатеричном) - идентификатор UDP-протокола. Поле «длина UDP-датаграммы» содержит в себе длину UDP-сообщения (UDP-заголовок + данные; длина псевдозаголовка не учитывается) в октетах, то есть совпадает с одноименным полем в UDP-заголовке.

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

Расчёт контрольной суммы

Перед расчетом контрольной суммы UDP-сообщение дополняется в конце нулевыми битами до длины, кратной 16 битам (псевдозаголовок и добавочные нулевые биты не отправляются вместе с сообщением). Поле контрольной суммы в UDP-заголовке во время расчета контрольной суммы отправляемого сообщения принимается нулевым.

Для расчета контрольной суммы псевдозаголовок и UDP-сообщение разбивается на слова (1 слово = 2 байта (октета) = 16 бит). Затем рассчитывается поразрядное дополнение до единицы суммы всех слов с поразрядным дополнением. Результат записывается в соответствующее поле в UDP-заголовке.

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

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

Пример расчёта контрольной суммы

Для примера рассчитаем контрольную сумму нескольких 16-битных слов: 0x398a, 0xf802, 0x14b2, 0xc281. Находим их сумму с поразрядным дополнением:

0x398a + 0xf802 = 0x1318c > 0x318d; 0x318d + 0x14b2 = 0x0463f > 0x463f; 0x463f + 0xc281 = 0x108c0 > 0x08c1.

Теперь находим поразрядное дополнение до единицы полученного результата:

0x08c1 = 0000 1000 1100 0001 > 1111. Это и есть искомая контрольная сумма.

Использование

Недостаточная надёжность протокола может выражаться как в потере отдельных пакетов, так и в их дублировании. UDP используется при передаче потокового видео, игр реального времени, а также некоторых других типов данных.

Ненадёжность протокола UDP надо понимать в том смысле, что в случаях влияния внешних факторов, приводящих к сбоям, протокол UDP не предусматривает стандартного механизма повторения передачи потерянных пакетов. В этом смысле он настолько же надежен, как и протокол ICMP.

Если приложению требуется большая надёжность, то используется протокол TCP или SCTP, либо реализуется какой-нибудь свой нестандартный алгоритм повторения передач в зависимости от условий.

UDP используется в следующих протоколах:

Ш DNS

Ш RTP и RTCP

Ш TFTP

Ш SNTP

Ш NTP

Ш NFS

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

протоколов с помощью протокола UDP

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

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

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

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

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

Зарезервированные и доступные порты UDP

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

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

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

Централизованное присвоение сервисам номеров портов выполняется организацией Internet Assigned Numbers Authority. Эти номера затем закрепляются и опубликовываются в стандартах Internet. Например, упомянутому выше сервису удаленного доступа к файлам TFTP присвоен стандартный номер порта 69.

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

Тема 2. Протокол FTP

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

FTP является одним из старейших прикладных протоколов, появившимся задолго до HTTP, в 1971 году. До начала 90-х годов на долю FTP приходилось около половины трафика в сети Интернет. Он и сегодня широко используется для распространения ПО и доступа к удалённым хостам.

Протокол FTP относится к протоколам прикладного уровня и для передачи данных использует транспортный протокол TCP. Команды и данные, в отличие от большинства других протоколов передаются по разным портам. Порт 20 используется для передачи данных, порт 21 для передачи команд. В случае, если передача файла была прервана по каким-либо причинам, протокол предусматривает средства для докачки файла, что бывает очень удобно при передаче больших файлов.

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

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

Процесс нешифрованной авторизации проходит в несколько этапов (символы \r\n означают перевод строки):

Установка TCP-соединения с сервером (обычно на 21 порт)

Посылка команды USER логин\r\n

Посылка команды PASS пароль\r\n

Если к серверу разрешён анонимный доступ (как правило, лишь для загрузки данных с сервера), то в качестве логина используется ключевое слово «anonymous» или «ftp», а в качестве пароля - адрес электронной почты:

USER anonymous\r\n

PASS someone@email\r\n

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

Основные команды

Ш ABOR - Прервать передачу файла

Ш CDUP - Сменить директорию на вышестоящую.

Ш CWD - Сменить директорию.

Ш DELE - Удалить файл (DELE filename).

Ш HELP - Выводит список команд принимаемых сервером.

Ш LIST - Возвращает список файлов директории. Список передается через соединение данных (20 порт).

Ш MDTM - Возвращает время модификации файла.

Ш MKD - Создать директорию.

Ш NLST - Возвращает список файлов директории в более кратком формате чем LIST. Список передается через соединение данных (20 порт).

Ш NOOP - Пустая операция

Ш PASV - Войти в пассивный режим. Сервер вернет адрес и порт к которому нужно подключиться чтобы забрать данные. Передача начнется при введении следующих команд RETR, LIST и т.д.

Ш PORT - Войти в активный режим. Например PORT 12,34,45,56,78,89. В отличие от пассивного режима для передачи данных сервер сам подключается к клиенту.

Ш PWD - Возвращает текущую директорию.

Ш QUIT - Отключиться

Ш REIN - Реинициализировать подключение

Ш RETR - Скачать файл. Перед RETR должна быть команда PASV или PORT.

Ш RMD - Удалить директорию

Ш RNFR и RNTO - Переименовать файл. RNFR - что переименовывать, RNTO - во что.

Ш SIZE - Возвращает размер файла

Ш STOR - Закачать файл. Перед STOR должна быть команда PASV или PORT.

Ш SYST - Возвращает тип системы(UNIX, WIN, …)

Ш TYPE - Установить тип передачи файла(Бинарный, текстовый)

Ш USER - Имя пользователя для входа на сервер

На многих FTP-серверах существует каталог (под названием incoming, upload и т. п.), открытый на запись и предназначенный для закачки файлов на сервер. Это позволяет пользователям наполнять сервер свежими данными.

FXP (англ. File eXchange Protocol - протокол обмена файлами) - способ передачи файлов между двумя FTP-серверами напрямую, не закачивая их на свой компьютер. При FXP-сессии клиент открывает два FTP-соединения к двум разным серверам, запрашивая файл на первом сервере, указывая в команде PORT IP-адрес второго сервера.

Несомненным преимуществом поддержки стандарта FXP является то, что на конечных пользователей, желающих скопировать файлы с одного FTP-сервера на другой, уже не действует ограничение пропускной способности их собственного Интернет-соединения. Нет необходимости скачивать себе файл, чтобы потом положить его на другой FTP-сервер. Таким образом, время передачи файлов будет зависеть только от скорости соединения между двумя удаленными FTP-серверами, которая в большинстве случаев заведомо больше «пользовательской».

К сожалению, FXP стал использоваться злоумышленникам для атак на другие серверы: в команде PORT указывается IP-адрес и порт атакуемого сервиса на компьютере жертвы, и командами RETR/STOR производится обращение на этот порт от лица FTP-сервера, а не атакующей машины, что позволяло устраивать масштабные DDoS-атаки с использованием сразу многих FTP-серверов, либо обходить систему безопасности компьютера жертвы, если он полагается только на проверку IP клиента и используемый для атаки FTP-сервер находится в доверенной сети или на шлюзе. В результате сейчас практически все серверы проверяют соответствие IP-адреса, указанного в команде PORT, IP-адресу FTP-клиента и по умолчанию запрещают использование там IP-адресов третьих сторон. Таким образом, использование FXP невозможно при работе с публичными FTP-серверами.

Алгоритм работы протокола FTP

Работа FTP на пользовательском уровне содержит несколько этапов:

1. Идентификация (ввод имени-идентификатора и пароля).

2. Выбор каталога.

3. Определение режима обмена (поблочный, поточный, ASCII или двоичный).

4. Выполнение команд обмена (get, mget, dir, mdel, mput или put).

5. Завершение процедуры (quit или close).

FTP довольно необычная процедура, так как поддерживает две логические связи между ЭВМ (Рис 4.5.4.1). Одна связь служит для удаленного доступа и использует протокол Telnet. Другая связь предназначена для обмена данными. Сервер производит операцию passive open для порта 21 и ждет соединения с клиентом. Клиент осуществляет операцию active open для порта 21. Канал остается активным до завершения процедуры FTP. TOS (тип IP-сервиса) соответствует минимуму задержки, так как этот канал используется для ручного ввода команд. Канал для передачи данных (TCP) формируется каждый раз для пересылки файлов. Канал открывается перед началом пересылки и закрывается по коду end_of_file (конец файла). IP-тип сервиса (TOS) в этом случае ориентирован на максимальную пропускную способность.

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

Рисунок 2.1 - Схема работы протокола FTP

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

Организация информационного обмена между двумя удаленными

машинами

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

Рисунок 2.2 - Организация информационного обмена между двумя

удаленными машинами

На фазе задания режима обмена предоставляются следующие возможности:

Команда Block сохраняет структуру логических записей файла.

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

Команда TYPE может задать режимы обмена IMAGE, ASCII или EBCDIC. Из них ASCII - используется по умолчанию. Режим EBCDIC применяется для обменов между ЭВМ, работающими с набором символов EBCDIC. Режим IMAGE предполагает обмен 8-битными байтами, используется для передачи двоичной (а не текстовой) информации. Более подробный список команд помещен ниже. Структурно информация может передаваться в виде файлов (структура по умолчанию), в виде последовательности записей (применимо для текстовых файлов ASCII или EBCDIC) или постранично (последняя структура не относится к числу рекомендуемых).

Для копирования файла из удаленного сервера используется команда GET, для копирования группы файлов - MGET, в последнем случае применяются символы заменители, например, MGET *.txt (или RFC-18*.txt, при этом скопируются файлы с RFC-1800.txt до RFC-1899.txt, если таковые существуют в текущем каталоге). Аналогом команды GET в какой-то степени является команда DIR (ls), только она переносит содержимое каталога, что для некоторых операционных систем эквивалентно. При использовании модификации mget проявляйте осторожность - вы можете заблокировать телекоммуникационный канал длительным копированием. Для записи файла в удаленный сервер применяется команда PUT. При операциях обмена обычно используется текущий каталог локальной ЭВМ. В вашем распоряжении всегда имеется возможность поменять местный каталог с помощью команды LCD или ее аналога. Любая команда обмена выполняется в несколько этапов:

1. Формирование канала под управлением клиента, так как именно клиент выдал команду get, dir, put и т.д.

2. Клиент выбирает произвольный номер порта на своей ЭВМ и осуществляет процедуру passive open для этого порта.

3. Клиент посылает номер порта серверу по каналу управления (порт 21), используя команду PORT. Можно обойтись и без команды PORT (используется тот же порт, что и в командном канале), но это увеличивает задержки и по этой причине не рекомендуется.

4. Сервер получает номер порта по каналу управления и выдает команду active open в указанный порт ЭВМ-клиента. Сервер для канала данных всегда использует порт с номером 20.

Тема 3. Протокол TFTP

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

Основное назначение TFTP - обеспечение простоты реализации клиента. В этой связи он используется для загрузки бездисковых рабочих станций, загрузки обновлений и конфигураций в «умные» сетевые устройства, записи статистики с мини-АТС (CDR) и аппаратных маршрутизаторов/файрволов.

Описание протокола

Обмен между клиентом и сервером начинается с того, что клиент запрашивает сервер либо прочитать, либо записать файл для клиента. В стандартном варианте загрузки бездисковой системы первый запрос - это запрос на чтение (RRQ). На рисунке 3.1 показан формат пяти сообщений TFTP. (Коды операций 1 и 2 имеют одинаковый формат.)

Первые 2 байта TFTP сообщения это код операции (opcode). В запросе на чтение (RRQ) и в запросе на запись (WRQ) имя файла (filename) указывает файл на сервере, который клиент хочет либо считать, либо записать. Мы специально показали на рисунке 15.1, что это имя файла оканчивается нулевым байтом. Режим (mode) это ASCII строка: netascii или octet (любая комбинация больших или маленьких букв), которая также оканчивается байтом 0. netascii означает, что данные являются строками ASCII текста, причем каждая строка оканчивается 2-символьной последовательностью возврата каретки, за которой следует пропуск строки (обозначается - CR/LF).



Рисунок 3.1 - Формат пяти TFTP сообщений

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

Каждый пакет данных содержит номер блока (block number), который затем используется в пакете подтверждении. В качестве примера скажем, что когда необходимо осуществить чтение файла, клиент посылает запрос на чтение (RRQ), указывая имя файла и режим. Если файл может быть прочитан клиентом, сервер отвечает пакетом данных с номером блока равным 1. Клиент посылает подтверждение (ACK) на номер блока 1. Сервер отвечает следующим пакетом данных с номером блока равным 2. Клиент подтверждает номер блока 2. Это продолжается до тех пор, пока файл не будет передан. Каждый пакет данных содержит 512 байт данных, за исключением последнего пакета, который содержит от 0 до 511 байт данных. Когда клиент получает пакет данных, который содержит меньше чем 512 байт, он считает, что получил последний пакет.

В случае запроса на запись (WRQ) клиент посылает WRQ, указывая имя файла и режим. Если файл может быть записан клиентом, сервер отвечает подтверждением (ACK) с номером блока равным 0. Клиент посылает первые 512 байт файла с номером блока равным 1, сервер отвечает ACK с номером блока равным 1.

Так как TFTP использует ненадежный UDP, то именно от TFTP зависит, как будут обработаны потерянные и дублированные пакеты. В случае потери пакета, отправитель отрабатывает тайм-аут и осуществляет повторную передачу. (Возможно появление проблемы, называемой "синдромом новичка" (sorcerer's apprentice syndrome), которая может возникнуть, если с обеих сторон будет отработан тайм-аут и осуществлена повторная передача. Раздел 12.2 [Stevens 1990] показывает, в результате чего может возникнуть подобная проблема.) Как и в большинстве UDP приложений, контрольная сумма TFTP сообщения не рассчитывается, а это означает, что любое повреждение данных может быть определено только с помощью контрольной суммы UDP

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

Поскольку протокол не поддерживает аутентификации, единственный метод идентификации клиента - это его сетевой адрес (который может быть подделан). Обычно в Unix-системах tftpd доступен только каталог /tftpboot. Однако в старых TFTP-серверах было возможным получить файл паролей командой GET../etc/passwd.

Демон tftpd (одна из реализаций tftp-сервера) отказывается обрабатывать файлы, содержащие в своём имени комбинацию «/../» или начинающуюся с «../». Запись разрешается только в файлы, которые уже существуют (любого размера, например нулевого), и доступны для публичной записи (права доступа: -rw-rw-rw-). Дополнительная защита от доступа к произвольным файлам осуществляется с помощью смены корневого каталога на каталог tftpd (обычно /usr/TFTPRoot).

Типы пакета

Сначала в TFTP-пакете идет поле размером в 2 байта, определяющее тип пакета:

Ш Read Request (RRQ, #1) - запрос на чтение файла.

Ш Write Request (WRQ, #2) - запрос на запись файла.

Ш Data (DATA, #3) - данные, передаваемые через TFTP.

Ш Acknowledgment (ACK, #4) - подтверждение пакета.

Ш Error (ERR, #5) - ошибка.

Ш Options Acknowledgment (OACK, #6) - подтверждение опций.

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

Для начала передачи данных клиент должен послать серверу WRQ или RRQ-пакет. У обоих пакетов формат одинаковый:

0x01/0x02 (тип пакета)	Имя файла	0x00 (конец строки)	Режим передачи	0x00 (конец строки)	Опции…(если есть)
2 байта	строка в ASCII	1 байт	строка в ASCII	1 байт	См. «Опции»

В TFTP существует 2 режима передачи (режим Mail, определенный в IEN 133, признан устаревшим):

· netascii - файл перед передачей перекодируется в ASCII.

· octet - файл передается без изменений.

После получения RRQ-пакета сервером, он сразу начинает передачу данных. В случае с WRQ-запросом - сервер должен прислать ACK-пакет c номером пакета 0.

Процесс передачи данных

После получения запроса RRQ, сервер сразу посылает в качестве подтверждения пакет с данными и с ID пакета равным единице. В WRQ в качестве подтверждения используется ACK с ID равным нулю. Всего по TFTP можно передать 32 Мб (65536 * 512 / 1024І), однако из-за использования знакового int вместо беззнакового, размер подтверждения ограничен 16 мегабайтами. Однако если клиент и сервер поддерживают расширения протокола RFC 2347 и RFC 2348, то максимальный размер передаваемого файла увеличивается до 4Gb.

Опции TFTP

В RFC 2347 был предусмотрен формат опций, которые можно присоединять к окончанию RRQ-пакета и WRQ-пакета:

Код опции	0x00 (конец строки)	Значение опции	0x00 (конец строки)
строка в ASCII	1 байт	строка в ASCII	1 байт

Опций может быть несколько. Тогда они будут следовать друг за другом. Порядок опций не важен.

В ответ на RRQ (или WRQ) с опциями, сервер должен прислать OACK с списком опций, которые сервер принял. Наиболее распространённые опции:

Название	Определена в	Код опции
Размер блока	RFC 2348	blksize	В качестве значения опции идёт число, принимающее значение от 8 до 65464, обозначающее размер блока.
Интервал повторной передачи (Timeout)	RFC 2349	timeout	В качестве значения опции идёт число, принимающее значение от 1 до 255, обозначающее время ожидания перед повторной передачей блока в секундах.
Размер файла	RFC 2349	tsize	В качестве значения опции идёт число, обозначающее размер передаваемого файла в байтах.

Ошибки

В TFTP информация об ошибке имеет следующий формат:

0x05 (тип пакета)	Код ошибки	Описание ошибки	0x00 (конец строки)
2 байта	2 байта	строка в ASCII	1 байт

Код ошибки может принимать одно из значений, перечисленных в STD 33 (за исключением кода 8 - он описан в RFC 2347). Вот они:

Код ошибки	Описание
0	Нет определенного кода, см. текст ошибки
1	Файл не найден
2	Доступ запрещен
3	Невозможно выделить место на диске
4	Некорректная TFTP-операция
5	Неправильный Transfer ID
6	Файл уже существует
7	Пользователь не существует
8	Неправильная опция

Тема 4. Протокол NFS

Network File System (NFS) - протокол сетевого доступа к файловым системам, первоначально разработан Sun Microsystems в 1984 году. Основан на протоколе вызова удалённых процедур (ONC RPC, Open Network Computing Remote Procedure Call, RFC 1057, RFC 1831). Позволяет подключать (монтировать) удалённые файловые системы через сеть, описан в RFC 1094, RFC 1813, RFC 3530 и RFC 5661.

NFS абстрагирована от типов файловых систем как сервера, так и клиента, существует множество реализаций NFS-серверов и клиентов для различных операционных систем и аппаратных архитектур. В настоящее время (2010) используется наиболее зрелая версия NFS v.4.1, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC_GSS) и списков контроля доступа (как POSIX, так и Windows-типов).

pNFS (параллельный NFS, см. pnfs.com) - входящая в наиболее свежую версию стандарта NFS v4.1 спецификация, обеспечивающая распараллеленную реализацию общего доступа к файлам, которая увеличивает скорость передачи данных пропорционально размерам и степени параллелизма системы.

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

NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов - а именно, NFS клиент может быть пользовательским процессом, который осуществляет конкретные RPC вызовы на сервер, который так же может быть пользовательским процессом.

Цели разработки

Первоначальная разработка NFS имела следующие цели:

· NFS не должна ограничиваться операционной системой UNIX. Любая операционная система должна быть способной реализовать сервер и клиент NFS.

· Протокол не должен зависеть от каких либо определенных аппаратных средств.

· Должны быть реализованы простые механизмы восстановления в случае отказов сервера или клиента.

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

· Для UNIX-клиентов должна поддерживаться семантика UNIX.

· Производительность NFS должна быть сравнима с производительностью локальных дисков.

· Реализация должна быть независимой от транспортных средств.

Компоненты NFS

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

· Протокол NFS определяет набор запросов (операций), которые могут быть направлены клиентом к серверу, а также набор аргументов и возвращаемые значения для каждого из этих запросов. Версия 1 этого протокола существовала только в недрах Sun Microsystems и никогда не была выпущена. Все реализации NFS (в том числе NFSv3) поддерживают версию 2 NFS (NFSv2), которая впервые была выпущена в 1985 году в SunOS 2.0. Версия 3 протокола была опубликована в 1993 году и реализована некоторыми фирмами-поставщиками.

· Протокол удаленного вызова процедур (RPC) определяет формат всех взаимодействий между клиентом и сервером. Каждый запрос NFS посылается как пакет RPC.

· Внешнее представление данных (XDR - External Data Representation) обеспечивает машинно-независимый метод кодирования данных для пересылки через сеть. Все запросы RPC используют кодирование XDR для передачи данных. Следует отметить, что XDR и RPC используются для реализации многих других сервисов, помимо NFS.

· Программный код сервера NFS отвечает за обработку всех запросов клиента и обеспечивает доступ к экспортируемым файловым системам.

· Программный код клиента NFS реализует все обращения клиентской системы к удаленным файлам путем посылки серверу одного или нескольких запросов RPC.

· Протокол монтирования определяет семантику монтирования и размонтирования файловых систем NFS. NFS использует несколько фоновых процессов-демонов. На сервере набор демонов nfsd ожидают запросы клиентов NFS и отвечают на них.

· Демон mountd обрабатывает запросы монтирования. На клиенте набор демонов biod обрабатывает асинхронный ввод/вывод блоков файлов NFS.

· Менеджер блокировок сети (NLM - Network Lock Manager) и монитор состояния сети (NSM - Network Status Monitor) вместе обеспечивают средства для блокировки файлов в сети. Эти средства, хотя формально не связаны с NFS, можно найти в большинстве реализаций NFS. Они обеспечивают сервисы не возможные в базовом протоколе. NLM и NSM реализуют функционирование сервера с помощью демонов lockd и statd соответственно.

Платформы

протокол сеть файл сервер почта

Хотя NFS чаще всего используют в UNIX-подобных системах, данный протокол можно также использовать и на других операционных системах, таких, как Mac OS Classic, OpenVMS, Microsoft Windows, Novell NetWare, и IBM AS/400. В число альтернативных протоколов удаленного доступа к файлам входят Server Message Block (SMB, также известный как CIFS) протокол, Apple Filing Protocol (AFP), NetWare Core Protocol (NCP). Под операционной системой Microsoft Windows SMB и NetWare Core Protocol (NCP) используется чаще, чем NFS; В системах Macintosh AFP встречается чаще, чем NFS.

Типичные настройки NFS клиента и NFS сервера

· Клиенту безразлично, получает ли он доступ к локальному файлу или к NFS файлу. Ядро определяет это, когда файл открыт.

· NFS клиент отправляет RPC запросы NFS серверу через модуль TCP/IP. NFS обычно использует UDP, однако более новые реализации могут использовать TCP.

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

· Когда NFS сервер получает запрос от клиента, он передается локальной подпрограмме доступа к файлу, которая обеспечивает доступ к локальному диску на сервере.

· Серверу может потребоваться время, для того чтобы обработать запросы клиента. Даже доступ к локальной файловой системе может занять некоторое время. В течение этого времени сервер не хочет блокировать запросы от других клиентов, которые также должны быть обслужены. Чтобы справиться с подобной ситуацией, большинство NFS серверов запускаются несколько раз, то есть внутри ядра существует несколько NFS серверов. Конкретные методы решения зависят от операционной системы. В большинстве ядер Unix систем не «живет» несколько NFS серверов, вместо этого запускается несколько пользовательских процессов (которые обычно называются nfsd), которые осуществляют один системный вызов и остаются внутри ядра в качестве процесса ядра.

· Точно так же, NFS клиенту требуется время, чтобы обработать запрос от пользовательского процесса на хосте клиента. RPC выдается на хост сервера, после чего ожидается отклик. Для того, чтобы пользовательские процессы на хосте клиента могли в любой момент воспользоваться NFS, существует несколько NFS клиентов, запущенных внутри ядра клиента. Конкретная реализация также зависит от операционной системы. Unix система обычно использует технику, напоминающую NFS сервер: пользовательский процесс, называемый biod, осуществляет один единственный системный вызов и остается внутри ядра как процесс ядра.

· Большинство Unix хостов может функционировать как NFS клиент и как NFS сервер, или как и то и другое одновременно. Большинство PC реализаций (MS-DOS) имеют только реализации NFS клиента. Большинство IBM мейнфреймов предоставляет только функции NFS сервера.

Тема 5. Протокол SMTP

SMTP (англ. Simple Mail Transfer Protocol - простой протокол передачи почты) - это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

ESMTP (англ. Extended SMTP) - масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения.

Обзор протокола

SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы POP3 или IMAP.

Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. Mail eXchange - обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись (RFC 2782).

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

Sendmail был одним из первых (если не первым) агентом отправки сообщений, который начал работать с SMTP. В настоящее время протокол SMTP является стандартным для электронной почты и его используют все клиенты и серверы.

Протокол был разработан для передачи только текста в кодировке ASCII, кроме того, первые спецификации требовали обнуления старшего бита каждого передаваемого байта. Это не даёт возможности отсылать текст на национальных языках (например, кириллице), а также отправлять двоичные файлы (такие как изображения, видеофайлы, программы или архивы). Для снятия этого ограничения был разработан стандарт MIME, который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME, позволяющий отправлять двоичные файлы так же просто, как текст.

Сервер SMTP - это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда<пробел>параметры<перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа - число от 100 до 999, представленное в виде строки, трактующийся следующим образом:

Ш 2ХХ - команда успешно выполнена

Ш 3XX - ожидаются дополнительные данные от клиента

Ш 4ХХ - временная ошибка, клиент должен произвести следующую попытку через некоторое время

Ш 5ХХ - неустранимая ошибка

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

ESMTP - расширяемый протокол, в отличие от SMTP. При установлении соединения сервер объявляет о наборе поддерживаемых расширений (в качестве ответа на команду EHLO). Соответствующие расширения могут быть использованы клиентом при работе. Необходимо помнить, что если сессия начинается с команды HELO (используемой в «классическом» SMTP, RFC 821), то список расширений выводиться не будет.

Модель протокола

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

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

Безопасность SMTP и спам

Изначально SMTP не поддерживал единой схемы авторизации. В результате этого спам стал практически неразрешимой проблемой, так как было невозможно определить, кто на самом деле является отправителем сообщения - фактически можно отправить письмо от имени любого человека. В настоящее время производятся попытки решить эту проблему при помощи спецификаций SPF, Sender ID, DKIM. Единой спецификации на настоящий момент не существует.

Команды SMTP

Простой протокол передачи почты обеспечивает двухсторонний обмен сообщениями между локальным клиентом и удаленным сервером МТА. МТА-клиент шлет команды МТА-серверу, а он, в свою очередь, отвечает клиенту. Другими словами, протокол SMTP требует получать ответы (они описаны в этой главе) от приемника команд SMTP. Обмен командами и ответами на них называется почтовой транзакцией (mail transaction). Данные, как мы уже говорили, передаются в формате NVT ASCII. Кроме того, команды тоже передаются в формате NVT ASCII. Команды передаются в форме ключевых слов, а не специальных символов, и указывают на необходимость совершить ту или иную операцию. В табл. 5.1 приведен список ключевых слов (команд), определенный в спецификации SMTP - RFC 821.

Таблица 5.1 - Команды простого протокола передачи почты (SMTP)

Команда	Обязательна	Описание
HELO	X	Идентифицирует модуль-передатчик для модуля-приемника (hello).
MAIL	X	Начинает почтовую транзакцию, которая завершается передачей данных в один или несколько почтовых ящиков (mail).
RCPT	X	Идентифицирует получателя почтового сообщения (recipient).
DATA		Строки, следующие за этой командой, рассматриваются получателем как данные почтового сообщения. В случае SMTP, почтовое сообщение заканчивается комбинацией символов: CRLF-точка-CRLF.
RSET		Прерывает текущую почтовую транзакцию (reset).
NOOP		Требует от получателя не предпринимать никаких действий, а только выдать ответ ОК. Используется главным образом для тестирования.(No operation).
QUIT		Требует выдать ответ ОК и закрыть текущее соединение.
VRFY		Требует от приемника подтвердить, что ее аргумент является действительным именем пользователя. (См. примечание.).
SEND		Начинает почтовую транзакцию, доставляющую данные на один или несколько терминалов (а не в почтовый ящик).
SOML		Начинает транзакцию MAIL или SEND, доставляющую данные на один или несколько терминалов или в почтовые ящики.
SAML		Начинает транзакцию MAIL и SEND, доставляющие данные на один или несколько терминалов и в почтовые ящики.
EXPN		Команда SMTP-приемнику подтвердить, действительно ли аргумент является адресом почтовой рассылки и если да, вернуть адрес получателя сообщения (expand).
HELP		Команда SMTP-приемнику вернуть сообщение-справку о его командах.
TURN		Команда SMTP-приемнику либо сказать ОК и поменяться ролями, то есть стать STMP- передатчиком, либо послать сообщение-отказ и остаться в роли SMTP-приемника.

Коды ответов SMTP

В спецификации SMTP требуется, чтобы сервер отвечал на каждую команду SMTP-клиента. МТА-сервер отвечает трехзначной комбинацией цифр, называемой кодом ответа. Вместе с кодом ответа, как правило, передается одна или несколько строк текстовой информации.

Каждая цифра в коде ответа имеет определенный смысл. Первая цифра означает, было ли выполнение команды успешно (2), неуспешно (5) или еще не закончилось (3). Как указано в приложении Е документа RFC 821, простой SMTP-клиент может анализировать только первую цифру в ответе сервера, и на основании ее продолжать свои действия. Вторая и третья цифры кода ответа разъясняют значение первой. Если вы разрабатываете SMTP-приложение, обязательно изучите конструкцию всех кодов SMTP-ответа. То, как коды составлены в самом SMTP - превосходный образец грамотного подхода к делу. В табл. 5.2 приведены возможные значения кодов ответа SMTP, определенные в RFC 821.

Таблица 5.2 - Коды ответа SMTP и их значение

Код	Значение
211	Ответ о состоянии системы или помощь
214	Сообщение-подсказка (помощь)
220	<имя_домена> служба готова к работе
221	<имя_домена> служба закрывает канал связи
250	Запрошенное действие почтовой транзакции успешно завершилось
251	Данный адресат не является местным; сообщение будет передано по маршруту <forward-path>
354	Начинай передачу сообщения. Сообщение заканчивается комбинацией CRLF-точка-CRLF
421	<имя_домена> служба недоступна; соединение закрывается
450	Запрошенная команда почтовой транзакции не выполнена, так как почтовый ящик недоступен
451	Запрошенная команда не выполнена; произошла локальная ошибка при обработке сообщения
452	Запрошенная команда не выполнена; системе не хватило ресурсов
500	Синтаксическая ошибка в тексте команды; команда не опознана
501	Синтаксическая ошибка в аргументах или параметрах команды
502	Данная команда не реализована
503	Неверная последовательность команд
504	У данной команды не может быть аргументов
550	Запрошенная команда не выполнена, так как почтовый ящик недоступен
551	Данный адресат не является местным; попробуйте передать сообщение по маршруту <forward-path>
552	Запрошенная команда почтовой транзакции прервана; дисковое пространство, доступное системе, переполнилось
553	Запрошенная команда не выполнена; указано недопустимое имя почтового ящика
554	Транзакция не выполнена

Промежуточные агенты

Термин "маршрут доставки" (forward-path) служит для того, чтобы отличать почтовый ящик (mailbox), имя которого абсолютно, от пути (он может быть различным), по которому следует почта. Предположим, что мы хотим доставить два почтовых сообщения на один и тот же сетевой компьютер. Оба сообщения имеют один и тот же адрес, однако не обязательно будут следовать по одному и тому же маршруту. Точно так же, если на пришедшие сообщения выдаются ответы, они не обязательно будут следовать по указанному обратному маршруту (reverse-path). Как правило, конкретный маршрут для почты выбирается системным администратором. Чтобы направить почту по нужному пути, используются значения маршрута доставки и обратного маршрута, в которых указываются промежуточные агенты (relay agents). Промежуточный агент доставки - это МТА, так называемый почтовый хаб (mail hub), настроенный на передачу транзитной почты. Чтобы доставить сообщение, местный агент пользователя (UA) передает его местному МТА, который, в свою очередь, передает его промежуточному агенту МТА. В следующем примере Smith@usc.edu является почтовым ящиком, a HOSTI, HOST2 и HOST3 - промежуточными агентами:

MAIL FROM:<@HOSTI, @HOST2, @HOST3:Smith@usc.edu>

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



Чтобы упростить процесс конфигурации почтовой системы, в локальной сети устанавливается один компьютер, служащий промежуточным агентом (relay host). Вся почта пользователей попадает сначала на него. Затем этот компьютер рассылает сообщения по Internet. Кроме всего прочего, такой компьютер может служить защитой фирмы от взломщиков-хакеров из Internet. Ограничивая общение локальной сети с внешним миром до уровня почты, организация сводит до минимума риск нежелательного вторжения в свои собственные системы.

Кроме того, администрировать и защищать в этом случае приходится единственный компьютер. SMTP в состоянии послать сообщение непосредственно с компьютера пользователя на компьютер адресата в том случае, если между ними существует прямое почтовое соединение. К сожалению, это далеко не всегда так. Как правило, между двумя компьютерами находится один или несколько промежуточных агентов. Чтобы обеспечить доставку, в почтовом сообщении нужно указать имя компьютера-получателя и точное наименование почтового ящика. Аргументом команды MAIL является обратный маршрут, включающий имя источника сообщения и имена всех промежуточных агентов. Аргумент команды RCPT - маршрут доставки, содержащий имя получателя сообщения. Обратный маршрут описывает путь, который прошло сообщение, тогда как маршрут доставки идентифицирует место назначения. Обратный маршрут используется SMTP, когда нужно передать сообщение о случившейся ошибке или о невозможности доставить сообщение, когда оно уже прошло через промежуточный агент. По мере продвижения сообщения по Internet записи о его маршрутах изменяются. В обязанности системных администраторов входит правильно настраивать местные МТА на передачу сообщений промежуточному агенту, и наоборот, промежуточные агенты на доставку сообщений местным МТА. Если у промежуточного МТА изменится имя, все, что нужно сделать в конфигурации местного МТА - изменить имя компьютера в системе DNS. Другие параметры конфигурации не изменяются. Другими словами, повторим еще раз, что иметь один компьютер для промежуточной доставки - значит, снять с себя значительную часть головной боли по настройке почтовой системы - ведь придется заботиться только об одном компьютере.