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

В начале 70-х годов разработан специальный протокол межсетевого взаимодействия, который назвали протоколом TCP / IP.

TCP (Transfer Control Protocol) – протокол управления передачи данных. Он определяет правила разбития информации на пакеты определенного размера и формата, их доставку к адресату определенными маршрутами и объединение пакетов в одно целое.

IP (Internet Protocol) – протокол межсетевого взаимодействия. Он дает возможность корректно передавать информацию между компьютерами, которые имеют разную архитектуру и разные операционные системы.

HTTP (HyperText Transfer Protocol) – протокол службы WWW. Это протокол передачи и отображения гипертекста, то есть web-страниц. Он дает возможность с помощью специальных программ-браузеров получать и просматривать web-страницы.

Протоколы электронной почты : SMTP, POP3 и IMAP.

SMTP (Simple Mail Transfer Protocol) – простой протокол передачи сообщений. Он дает возможность передавать сообщения от компьютера пользователя на сервер.

POP3 и IMAP - дают возможность пользователю забирать или читать сообщения из почтового сервера. POP3 (Post Office protocol) – это протокол почтового отделения, IMAP (Internet Mail Access Protocol) – это протокол доступа к электронной почте. Их принцип работы мало чем отличается, и зачастую нет разницы, какой протокол использовать.

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

Ну прежде всего, что значит RS в сокращениях типа RS-232, RS-485, RS-422.. RS - это всего на всего Recommended Standard (рекомендованный стандарт). Ключевое слово тут - "рекомендованный", означающее, что эти стандарты никогда никем не были приняты (в противоположность таким стандартам, как IEEE-1284 или IEEE-1394), они были просто "рекомендованы".

В 1976 году был принят стандарт X.25, который стал основой всемирной системы PSPDN (Packet-Switched Public Data Networks), базирующейся на 7-уровневой модели ISO OSI. Стандарт X.25 был усовершенствован в 1984. X.25 - протокол (ISO 8208:1989; RFC-887, -1381, -1382, -1461, -1598, -1613), который определяет синхронный интерфейс между терминальным оборудованием (DTE - Data Terminal Equipment) и оборудованием передачи данных (DCE - Data Communication Equipment) для терминалов, работающих в пакетном режиме. По существу это протокол связи оборудования с сетью. Главный недостаток протокола X.25 - большие задержки отклика (типовое значение 0.6 сек). Терминалом может служить ЭВМ или любая другая система, удовлетворяющая требованиям X.25. Соединение DTE - DTE осуществляется через DCE. В протоколе X.25 DCE и DTE используют статистическое мультиплексирование с делением по времени. Одновременно могут реализовываться несколько обменных процессов. Схема взаимодействия DTE и DCE выглядит как:

DTE - <логический канал> - DCE <виртуальное соединение> - DCE - <логический канал> - DTE

Асинхронный старт-стопный терминал подключается к сети коммутации пакетов через пакетный адаптер данных ПАД (PAD - packet assemble/disassemble) и отвечает рекомендациям X.3, X.28 и X.29. Один ПАД обеспечивает интерфейс для 8, 16 или 24 асинхронных терминалов. Пакет данных состоит обычно из 128 байтов, которые передаются по адресу, содержащемуся в пакете. Но длина пакета может лежать в пределах 64-4096 байтов. Размер пакета также как и величина окна (число пакетов, принимаемых без подтверждения) определяются на фазе установления канала. Прежде чем пакет будет передан, необходимо установить связь между исходными ЭВМ/ПАД и адресуемыми ЭВМ/ПАД. Существуют два вида соединений: коммутируемый виртуальный канал (SVC) и постоянный виртуальный канал (PVC). Предусмотрены две процедуры доступа к каналу:

• Процедура доступа к каналу (LAP - link access procedure), в основе которой лежат симметричные операции режима асинхронного ответа (ARM - asynchronous response mode) протокола HDLC.
• Балансная процедура доступа к каналу (LAPB - link access procedure balanced) на основе асинхронного балансного режима (ABM - asynchronous balanced mode) протокола HDLC. Сетевой уровень реализуется с использованием 14 различных типов пакетов.

Виртуальный канал описывается в общем формате пакета, как "логический канал". Логический канал имеет идентификатор, состоящий из 12 бит. Этот идентификатор обычно состоит из номера группы (4 бита) и номера логического канала (8 бит). В группе может быть до 256 логических каналов (за исключением группы 0, которая может иметь только 255 логических каналов). Возможное число групп - 16, поэтому теоретически возможное число виртуальных каналов для каждого соединения x.25 равно 4095 (16x256-1).

Постоянный виртуальный канал (PVC - permanent virtual circuit) является аналогом выделенного канала.

Коммутируемый виртуальный канал (SVC - switched virtual circuit - напоминает традиционный телефонный вызов) реализует обмен данными. Имеются три типа коммутируемых виртуальных каналов, работающие в дуплексном режиме, но отличающиеся направлением устанавливаемых соединений: входящий SVC, двунаправленный SVC и выходящий SVC. Адресат каждого пакета распознается с помощью идентификатора логического канала (LCI) или номера логического канала (LCN).

SVC используются только на время соединения и становятся доступными для повторного использования после разъединения. Все типы пакетов, за исключением пакетов запроса повторного пуска, содержат идентификатор логического канала. Пакет запрос соединения в SVC является единственным типом пакетов, которые содержат адреса в соответствии с рекомендацией X.121.

Для установки выходящего соединения через svc ЭВМ выбирает логический канал с наибольшим номером в группе и посылает пакет запрос соединения, содержащий выбранный номер группы канала, адрес получателя (в соответствии с рекомендацией X.121) и в отдельных случаях свой собственный адрес. При установлении входящего соединения центр коммутации пакетов (ЦКП) выбирает свободный логический канал с наименьшим номером в группе каналов порта адресуемой ЭВМ и помещает этот логический номер группы и канала в пакет входящий запрос соединения. После того как соединение через svc установлено, ЭВМ направляют свои пакеты, используя номера своих логических групп/каналов, а ЦПК в сети осуществляет транспортировку пакетов и преобразование номеров логических групп/каналов. Как только установленное по svc логическое соединение разъединяется, номера логических групп/каналов на обоих концах соединения освобождаются и становятся доступными для повторного использования. Соответствие между ЦКП/портом, выделенным для терминального оборудования, адресами (согласно рекомендациям x.121) и номерами логических каналов известно в сети только ЦКП.

Выбор ЭВМ свободного канала с наибольшим номером при каждом выходящем соединении и выбор в ЦКП свободного канала с наименьшим номером для каждого входящего позволяют избежать конфликтов. С этой же целью используются две логические группы: одна только для входящих соединений, а другая только для выходящих. Перед подключением к сети пользователь должен определить, сколько pvc и svc требуется на каждую точку физического интерфейса x.25. Асинхронные терминалы подключаются к сети коммутации пакетов через встроенные или удаленные пакетные адаптеры данных (ПАД).

Встроенный ПАД обычно располагается вместе с ЦКП в его стойке. В этом случае каждый асинхронный терминал, расположенный в удаленном месте, подключается к своему встроенному ПАД через отдельный канал связи (протокол Х.28). В альтернативном случае удаленный ПАД (небольшое отдельное устройство) может быть расположен в удаленном месте и подключается к своему ЦКП через канал связи (X.25). С помощью удаленного ПАД к ЦКП подключается 8-16 асинхронных терминалов.

Встроенный ПАД может быть совместно использован несколькими терминалами, расположенными в различных местах, в то время как удаленный ПАД обслуживает терминалы, расположенные обычно в одном месте. Существует еще один аспект размещения ПАД, связанный с помехами в каналах связи и использованием протоколов. Удаленный ПАД подключается к ЦКП на канальном уровне в соответствии с рекомендацией X.25. В качестве протокола канала данных в рекомендации X.25 реализуется подмножество HDLC, обеспечивающее автоматическую повторную передачу данных в случае их искажения при возникновении помех в линии. Асинхронный терминал использует для диалога с групповым ПАД процедуры, описанные в рекомендации X.28, в которых не предусмотрена возможность повторной передачи в случае ошибки. Поэтому канал между синхронным терминалом и групповым ПАД не защищен от возникновения ошибок данных в результате линейных помех. Процедуры ПАД определены в рекомендациях МККТТ (см. приложение 10.1).

• Рекомендация X.3: "Пакетный адаптер данных (ПАД) в сети передачи данных общего пользования".
• Рекомендация X.28: "Интерфейс между терминальным оборудованием и оборудованием передачи данных (DCE) для старт-стопного оконечного оборудования, осуществляющего доступ к пакетному адаптеру данных в сетях общего пользования".
• Рекомендация X.29: "Процедуры обмена управляющей информацией между терминальным оборудованием пакетного типа и пакетным адаптером (ПАД)".

Основные функции ПАД соответствуют рекомендациям X.3:

• сборка символов (полученных от асинхронных терминалов) в пакеты;
• разборка полей данных в пакетах и вывод данных на асинхронные терминалы;
• управление процедурами установления виртуального соединения и разъединения, сброса и прерывания;
• обеспечение механизма продвижения пакетов при наличии соответствующих условий, таких как заполнение пакета, получение символа (сигнала) на передачу пакета, истечение времени ожидания;
• передача символов, включающих стартстопные сигналы и биты проверки на четность, по требованию подключенного асинхронного терминала;
• обнаружение сигнала разрыв соединения от асинхронного терминала;
• редактирование последовательностей команд ПАД.

В постоянном запоминающем устройстве ПАД хранятся параметры. Эти параметры могут быть установлены либо асинхронным терминалом, подключенным к ПАД, либо любой ЭВМ в сети, которая удовлетворяет условиям рекомендации X.29. В рекомендации X.29 МККТТ эти параметры названы управляющей информацией. Поэтому необходимо квалифицировать данные, проходящие между ЭВМ и ПАД, либо как управляющую информацию (сообщения ПАД), либо как собственно данные от асинхронного терминала.

Сеть X.25 предоставляет пользователю старт-стопного терминала средства, позволяющие выбрать параметры ПАД с заранее определенными значениями. Пользователь посылает в ПАД команду выбора профайла, которая включает идентификатор профайла. Этим определяется один из нескольких стандартных профайлов, хранящихся в ПАД.

Идентификатор профайла и параметр 11 ПАД (скорость терминала) включаются в "поле данных пользователя" пакетов типа запрос соединения, посылаемых ПАД. ЭВМ (ПАД) использует это поле, извлекая из него информацию о терминале, пославшем запрос.

Пакетный терминал является интеллектуальным устройством (например, ЭВМ, или внешним ПАД’ом), которое обеспечивает синхронный обмен с сетью на скорости 2400, 4800, 9600 бит/c или 48 Кбит/с, используя трехуровневый протокол X.25. Возможная схема подключения терминальных устройств к сети X.25 показана на рис. 4.3.2.1.

Из рисунка 4.3.2.1 видно, что подключение ЭВМ и другого терминального оборудования возможно как к встроенному, так и удаленному ПАД (протокол X.28), а также непосредственно к ЦКП (протокол X.25, X.29). Связи с удаленными объектами осуществляются через соответствующие модемы (на рисунке не показаны).

Для международного соединения необходимо указать код страны из трех цифр, а также набрать одну цифру 9 перед сетевым адресом пользователя. Таким образом, всего требуется не более 15 цифровых символов. Для установления коммутируемого соединения оператор вначале вручную набирает номер ПАД и ждет подтверждения соединения с телефонным узлом общего пользования. Как только соединение установлено, оператор набирает 12-символьный код "сетевого идентификатора пользователя". ПАД обеспечивает операцию эхо-контроля, которая позволяет оператору терминала визуально проверять данные, посылаемые в ПАД. Наиболее серьезным недостатком встроенного ПАД является отсутствие какого-либо линейного протокола, предусматривающего устранение ошибок в данных, посылаемых от ПАД к терминалу. В удаленном ПАД предусмотрена процедура восстановления ошибочных данных, однако он подключается к сети как "пакетный терминал".

Рис. 4.3.2.1. Возможная топология сети X.25

Сетевой адрес пользователя состоит из 12 десятичных цифр. 1-4 - идентификатор сети передачи данных (3 - страна, 4 - сеть); 5-12 - национальный номер (5-7 местная область, 8-12 - местный номер). Международная система адресации для систем передачи данных общего пользователя описана в рекомендациях X.121 международного комитета по телефонии и телеграфии. Каждое подключение к сети коммутации пакетов имеет свой национальный номер. Протокол X.25 не определяет технику маршрутизации пакетов по сети. Для целей управления в сетях X.25 используется протокол snmp и база данных MIB (как и в сетях Интернет). Три базовых уровня протокола X.25 и схема потоков информации отображены на рис. 4.3.2.2.

Для подключения по виртуальному каналу ЭВМ/ПАД посылается пакет (call request), содержащий сетевой адрес пользователя. После подтверждения соединения и передачи/приема данных виртуальное соединение может быть разорвано путем передачи пакета (clear request), инициатором в этом случае выступает удаленная ЭВМ. При невозможности установить связь clear request посылается сетью. Такой пакет содержит два информационных октета. Первый содержит код причины, второй является диагностическим кодом. Ниже в таблице 4.3.2.1 приведены коды причин ошибки.

Таблица 4.3.2.1. Коды причины ошибки

Один физический канал связи X.25 может поддерживать несколько коммутируемых виртуальных каналов. Постоянный виртуальный канал подобен выделенной линии - обмен возможен в любой момент. X.25 определяет первые три уровня соединения открытых систем (см. рис. 4.3.2.2).

1. - физический x.21 (X.21bis)
2. - канальный (HDLC - high data link communication - протокол высокого уровня управления каналом). Этот уровень и последующие реализуются программным образом.
3. - сетевой (пакетный)

X.21 - универсальный интерфейс между оконечным оборудованием (DTE) и аппаратурой передачи данных (DCE) для синхронного режима работы в сетях общего пользования. X.21bis – тоже, но для модемов, удовлетворяющих рекомендациям серии V. Для канального уровня используется подмножество протокола HDLC (являющегося развитием стандарта SDLC IBM), обеспечивающее возможность автоматической повторной передачи в случае возникновения ошибок в линии.

Рис. 4.3.2.2. Три уровня X.25 

Формат кадра для протокола HDLC показан на рис. 4.3.2.3 (байты передаются, начиная с младшего бита):

Рис. 4.3.2.3. Формат кадра X.25

Открывающий и закрывающий флаги для бит-ориентированного формата несут в себе код 0x7e. Когда не передается никакой информации, по каналу пересылается непрерывный поток флагов 01111110. Посылка более 6 единиц подряд воспринимается как флаг абортирования связи. Если необходимо передать информационную последовательность 01111110, после первых пяти единиц вводится дополнительный нуль, приемник восстанавливает истинную информацию, удаляя эти лишние нули. В случае байт-ориентированных кадров открывающий и завершающий флаги имеют по два байта [DLE (Символы кодов стандарта ISO 646-1973 (МТК-5, ГОСТ 13059-74). Здесь и далее используется русская терминология в соответствии со стандартом ГОСТ 26556-85, STX и DLE, ETX, соответственно, для информационного кадра и DLE, STX и DLE, ETX для управляющего]. Адрес в пакете X.25 занимает всего один байт, что определяет предельное число терминальных устройств, подключаемых к одному каналу. Кадр на уровне 2 имеет двухбайтовый заголовок, содержащий байт адреса и байт типа. Для нумерации кадров на уровне 2 используется 3 бита. При работе со скользящим окном откликов это позволяет иметь до 7 кадров в очереди. При использовании спутниковых каналов с большими задержками можно переходить в режим расширенной нумерации (7 бит), где длина очереди может достигать 128. Если удаленный партнер не способен работать в режиме расширенной нумерации, он отклонит запрос соединения. При работе в режиме расширенной нумерации возможно применение 3-байтовых заголовков вместо двухбайтовых.

Значения поля идентификатора общего формата (GFI - general format identifier) приведено в таблице 4.3.2.2. Бит 8 этого поля (Q) используется в информационных пакетах как индикатор уровня передаваемых данных. Групповой номер логического канала и номер логического канала присваиваются по соглашению с администрацией сети во время постановки на обслуживание. Поля групповой номер логического канала и номер логического канала присутствуют во всех пакетах кроме пакетов регистрации и повторного пуска, где они принимают нулевое значение.

Таблица 4.3.2.2. Значения кодов идентификатора общего формата (GFI)

x - бит может принимать значения 0 или 1.

Допустимые значения кодов в поле тип пакета приведены в таблице 4.3.2.3.

Таблица 4.3.2.3. Значения кодов тип пакета

x - отмечет разряды, которые могут принимать значения 0 или 1.

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

Рис. 4.3.2.4. Формат кадра запроса на соединение и соединение установлено 

Поле опции содержит целое число октетов, но не более 109, следующее же поле может содержать до 128 байт. Опция типа fast select позволяет поместить до 64 байтов в информационном поле пользователя, во многих случаях этого оказывается достаточно и исключается необходимость переходить в режим пересылки данных.

Если вызываемое DTE не присылает сообщения вызов принят или запрос завершения (установление связи отвергнуто) за отведенное для этого время, процедура завершается и процессу, инициализировавшему запрос, присылается соответствующий код ошибки. При успешной обработке запроса (прислано сообщение соединение установлено) система переходит в режим обмена данными. DTE может в любой момент инициировать процедуру разрыва связи, послав сообщение запрос завершения. DCE сообщает о завершении соединения путем присылки пакета индикация завершения, на который DTE должно прислать отклик подтверждение завершения. Формат пакетов запроса и подтверждения завершения отображен на рис. 4.3.2.4. и 4.3.2.5. Байты 1 и 2 на рисунке 4.3.2.5 не показаны, так как они идентичны тому, что представлено на рис. 4.3.2.4.

Рис. 4.3.2.5. Формат пакетов запроса завершения

Коды причины завершения связи приведены в таблице 4.3.2.1. Однобайтовое поле диагностический код позволяет уточнить причину. В таблице 4.3.2.4 приведены коды причины повторного пуска. Формат пакетов подтверждения завершения представлен на рис. 4.3.2.6.

Таблица 4.3.2.4. Коды причин повторного пуска

Рис. 4.3.2.6. Формат пакетов подтверждения завершения

Для инициализации обмена информацией (первичного или повторного), а также для прерывания виртуальной связи и возвращения виртуальных каналов в исходное состояние используются запросы повторного пуска (и подтверждение повторного пуска). DTE может выдать запрос повторного пуска (к DCE) в любой момент времени, переводя логический канал в исходное состояние. DCE в ответ должно послать сообщение подтверждение повторного пуска. Инициатором повторного пуска может быть и dce, для этого оно посылает сообщение индикация повторного пуска. DTE в результате устанавливает логический канал в исходное состояние и посылает dce сообщение подтверждение повторного пуска. Форматы пакетов, несущих эти сообщения показаны на рис. 4.3.2.6 и 4.3.2.7. Эти пакеты не имеют полей группового номера логического канала и LCN (см. рис. 4.3.2.7 и .8). Процедура повторной установки во многом аналогична повторному пуску и используются всякий раз при выявлении сбоя, чтобы вернуть виртуальную связь или постоянный виртуальный канал в исходное состояние.

Рис. 4.3.2.7. Формат пакета запроса повторного пуска (слева) и повторной установки

Таблица 4.3.2.5. Коды причин повторной установки

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

Инициатором посылки запроса повторной установки может быть dte и dce. Коды причин повторной установки представлены в таблице 4.3.2.5.

Рис. 4.3.2.8. Формат пакета подтверждения повторного пуска (слева) и повторной установки (справа)

Пакеты данных передаются по постоянным виртуальным каналам или через виртуальные соединения после их создания. Пакеты данных распознаются по нулевому младшему биту (бит с номером 1) в третьем октете. Остальные биты этого октета используются для управления. Форматы пакетов данных показаны на рис. 4.3.2.9.

Информационное поле начинается с четвертого байта (при расширенной нумерации с пятого) и может иметь длину 16-4096, хотя в рекомендациях стандарта x.25 оговорена величина 128 октетов. Если принимающая сторона не способна принять пакет данной длины, связь должна быть переустановлена, а стороне-инициатору соединения послано сообщение об ошибке. Каждому пакету данные присваивается порядковый номер N(S), значение которого при установлении соединения равно нулю.

Рис. 4.3.2.9. Форматы пакетов данные. Слева - по модулю 8, справа - по модулю 128

Q -бит определяет тип кадра-пакета, Q=1 - управляющий пакет для PAD, Q=0 - информационный пакет. Бит D используется для запроса специального отклика на пакет со стороны удаленного конца виртуального канала. Бит M указывает на то, что данный пакет является частью более крупного пакета, который должен быть воссоздан позднее.

Индекс S (send) соответствует отправке, а индекс R - приему (receive). Если используется нумерация пакетов по модулю 8, N(S) занимает биты 2-4 включительно, при нумерации по модулю 128 для этого отводятся биты 2-8. Нумерация пакетов позволяет выявить потерю пакетов или изменение порядка их доставки. N(R) является номером пакета с принимающей стороны. Бит подтверждения доставки D (идентификатор формата) служит для указания необходимости сообщения о доставке данных получателем. Если D=1, то DTE обязано подтвердить доставку. Обязательность процедуры подтверждения определяется уже на фазе установления связи (сообщение запрос на установление связи принят). Если какой-либо узел по пути пересылки пакета не поддерживает процедуру подтверждения доставки, он пошлет сообщение запрос завершения (причина - несовместимость у адресата) и связь должна быть сформирована заново с учетом необходимости подтверждения во всех узлах-участниках. Размер поля данные в пакете может быть разным для разных узлов, участвующих в обмене. По этой причине число полученных пакетов может оказаться больше (или меньше) числа посланных. Для таких случаев предусмотрен флаг m (дополнительные данные). Возможность фрагментации и последующей сборки пакетов определяется управляющими битами M и D (см. таблицу 4.3.2.6).

Таблица 4.3.2.6. Управление фрагментацией и сборкой пакетов с помощью битов M и D

Таким образом, при фрагментации исходного сообщения все пакеты кроме последнего должны иметь бит m=1. Нумерация пакетов по модулю 8 означает, что им последовательно присваиваются номера 0,1,2,3,4,5,6,7,0,1,2 и т.д. Аналогично при нумерации по модулю 128 - 0,1,2,...127,0,1,2,3 и т.д. Форма нумерации пакетов определяет также размер “окна”, то есть число пакетов, которые могут быть переданы, не дожидаюсь подтверждения получения. По умолчанию размер окна равен 2, другие значения могут быть согласованы на фазе установления соединения. Принцип использования окон при передаче пакетов более подробно описан в разделе “3.6.2 Протокол TCP”.

Для управления процессом передачи данных используются сообщения “готов к приему” и “не готов к приему”. Форматы этих пакетов показаны на рис. 4.3.2.10 и 4.3.2.11.

Рис 4.3.2.10. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 8.

Рис 4.3.2.11. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 128.

Код N(R) на входе DCE должен лежать в пределах между N(R) последнего принятого пакета и N(S) следующего пакета, который должен быть послан из DCE к DTE. При невыполнении этого условия связь будет переустановлена и передача повторена. Пакеты готовность к приему используются для сообщения о готовности принять пакеты, с номерами, начиная с номера N(R), приведенного в пакете. Пакеты неготовность к приему служат для того, чтобы сообщить о временной неспособности принять данные. При поступлении этого сообщения отправитель должен прервать передачу до получения сообщения готовность к приему. DTE может передавать данные удаленному DTE, не следуя правилам управления потоком данных. Для реализации такой возможности предусмотрена операция прерывания. Эта операция не влияет на передачу данных и управление. Формат пакета прерывание и подтверждение прерывания показан на рис. 4.3.2.12.

Рис. 4.3.2.12. Формат пакетов прерывание и подтверждение прерывания 

Идентификатор формата равен 0x1 для нумерации по модулю 8 и 0x2 при нумерации по модулю 128. Передав сообщение прерывание, DTE должно ожидать получение пакета подтверждение прерывания. Максимальный размер поля данные пользователя в пакете прерывание не должен превышать 32 байт.

Иногда в сетях для сообщения об ошибке используется пакет “диагностика”. Этот пакет посылается DCE, адресуется DTE и несет информацию о неустранимых на уровне пакетов ошибках. Пакет диагностика посылается лишь один раз сразу после выявления ошибки. Подтверждения его получения не требуется. Формат пакета показан на рис. 4.3.2.13.

Рис. 4.3.2.13. Формат пакета диагностика 

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

Современные сети создаются ради доступа к определенным услугам. В протоколе X.25 предусмотрена процедура, которая позволяет получить текущие значения параметров услуг (опций) и модифицировать их. Эта процедура называется регистрацией и не является обязательной. Форматы пакетов запроса регистрации и подтверждения регистрации показаны на рис. 4.3.2.14 и 4.3.2.15. Максимальный размер поля регистрация составляет 109 байт. Инициатором регистрации всегда является dte, которое передает запрос регистрации. В качестве отклика dce посылает пакет подтверждение регистрации, в котором содержатся информация о параметрах доступных услуг. Для выявления доступных услуг может быть послан запрос регистрации, не содержащий списка запрашиваемых услуг.

Рис. 4.3.2.14. Формат пакетов запрос регистрации 

Рис. 4.3.2.15. Формат пакетов подтверждение регистрации 

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

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

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

Повторная передача пакетов согласуется на определенное время и может использоваться во всех логических каналах DTE-DCE. DTE запрашивает повторную передачу одного или нескольких пакетов данные путем посылки сообщения отказ reject), которое определяет логический канал и порядковый номер пакета N(R). Получив пакет отказ DCE, DTE начинает повторную передачу пакетов. Формат пакетов отказ для случаев нумерации по модулю 8 и 128 показан на рис. 4.3.2.16.

Рис. 4.3.2.16. Форматы пакетов типа отказ для нумерации по модулю 8 (слева) и 128

Программное обеспечение принимающей и передающей сторон должно иметь переменные состояния V(R) и V(S), содержащие, соответственно, номера пакетов, которые предстоит получить и послать (см. описание процедуры HDLC). После посылки очередного пакета с N(S) значение V(S) увеличивается на 1. Принимающая сторона сравнивает V(R) с N(S) полученного пакета, при совпадении укладывает N(S) в поле N(R) пакета-отклика и инкрементирует V(R). Отправитель при получении пакета проверяет равенство переменной V(S) и кода поля N(R) в пакете-отклике. Если при получении пакета выясняется, что V(R) не равно N(S), V(R) не инкрементируется, а принимающая сторона отправляет отклик с N(R)=V(R). Отправитель, получив этот отклик и обнаружив, что V(S) не равно N(R), узнает о происшедшем сбое. Номер логического канала (LCN) служит для того, чтобы определить соответствие межу DTE и местным DCE. LCN вместе с полем группового номера логического канала занимают 12 бит, что позволяет иметь до 4095 логических каналов (LCN=0 зарезервировано для использования DCE).

4 бита первого байта управляющего пакета содержат в себе код типа сообщения (таблица 4.3.2.7):

Таблица 4.3.2.7 Коды типов сообщений 

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

Таблица 4.3.2.8. Коды параметров PAD

При работе TCP/IP сети через каналы X.25 и наоборот следует учитывать некоторые отличия кодов предпочтения в полях TOS. Таблица 4.3.2.9 содержит соответствие этих кодов для этих сетей.

Таблица 4.3.2.9. Соответствие кодов TOS для сетей TCP/IP и X.25

Для реализации работы сетей ISDN по существующим каналам сети X.25 разработан протокол X.31. X.31 организует канал пользователь-маршрутизатор X.25 (через посредство ISDN) и регламентирует работу ISDN с пакетами X.25.

Для решения первой задачи используется сообщение SETUP. Вторая задача решается, когда канал до маршрутизатора сформирован. На этом этапе привлекается набор протоколов X.25, возможно применение протокола X.75 (ISO 8208), который является расширением X.25 для межсетевых связей.

Надежная передача данных по протоколу SCTP 

 linux, sctp, протокол

0

0

Протокол передачи с управлением потоком (Stream Control Transmission Protocol, SCTP) — это надежный транспортный протокол, который обеспечивает стабильную, упорядоченную (с сохранением порядка следования пакетов) передачу данных между двумя конечными точками (подобно TCP). Кроме того, протокол обеспечивает сохранение границ отдельных сообщений (подобно UDP). Однако, в отличие от протоколов TCP и UDP, протокол SCTP имеет дополнительные преимущества, такие как поддержка множественной адресации (multihoming) и многопоточности (multi-streaming) — каждая из этих возможностей увеличивает доступность узла передачи данных. В этой статье мы познакомимся с основными характеристиками протокола SCTP ядра Linux® 2.6 и рассмотрим исходный текст программ сервера и клиента, демонстрирующий возможности протокола по многопоточной передаче данных.

SMTP является собственным транспортным протоколом Exchange Server 2003, и он используется коннекторами Routing Group Connector и SMTP Connector (для почты интернета), а также для взаимодействия между серверами Exchange 2003. Другие протоколы - РОРЗ, IMAP4 и OWA - используются различными способами для доступа к процессу Store. Знание преимуществ и ограничений каждого протокола поможет при планировании, реализации, а также в поиске и устранении неисправностей.

Протокол Simple Mail Transfer Protocol (SMTP)

Поскольку мы не можем привести в данном курсе подробный анализ SMTP, этот раздел посвящен описанию тех частей SMTP, которые наиболее связаны с администрированием, а также с поиском и устранением неисправностей в Exchange Server 2003.

Simple Mail Transfer Protocol, SMTP (Упрощенный протокол электронной почты) основан на протоколе передачи файлов File Transfer Protocol (FTP). До того как SMTP был определен в стандарте RFC 561, общепринятым способом считалось копирование сообщений в место назначения в виде простых файлов с помощью протокола FTP. Проблемой этого метода являлось то, что иногда из-за недостатка идентифицирующей информации было трудно определить, кто отправил этот файл, и кому он предназначается. Возникла потребность в передаче информации между двумя хостами с идентификацией отправителя и получателя.

В 1973 г. положено начало определению структуры сообщений, содержащей поля заголовка и основной текст. Дальнейшие улучшения внесены в RFC 680, 724 и 733, после чего выпущен действующий стандарт RFC 822. Теперь каждая строка заголовка состоит из имени поля, которое заканчивается двоеточием, за которым следует тело этого поля. Для достоверности сообщения следует заполнять поля времени, поля источника и поля адресата, а также дополнительные поля: Received (Получено), Subject (Тема), Reply-to (Ответить) и Return-path. Поскольку сообщение передается от одного агента Message Transfer Agent (MTA) другому, то эти обязательные поля учитываются и добавляются к заголовку сообщения, чтобы получатель видел, как сообщение проходило через почтовую систему.

Дополнительная информация. Более подробную информацию по стандартам передачи сообщений см. в документе "F.400/X.400 Standard: Data Networks and Open System Communication Message Handling Systems" от Международного Союза Телекоммуникаций (International Telecommunication Union, ITU) по адресу http://www.itu.org.

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

1. Пользователь направляет почтовый запрос службе SMTP отправителя.
2. SMTP отправителя устанавливает двусторонний канал передачи данных с SMTP получателя.
3. SMTP отправителя генерирует команды протокола SMTP и отправляет их SMTP получателя.
4. SMTP получателя направляет команды-ответы SMTP отправителя.

Например, если пользователь Userl хочет отправить почтовое сообщение пользователю User2 через SMTP, то произойдут события в следующей последовательности (в предположении, что оба пользователя используют на своих компьютерах службу SMTP).

1. Userl обращается к User2 и устанавливает двусторонний канал передачи данных через ТСР-порт 25 с помощью команды HELO
2. Userl отправляет команду MAIL, указывающую отправителя почты. Становится известен отправитель сообщения электронной почты.
3. User2 отправляет ответ ОК.
4. Userl отправляет команду RCPT, указывающую получателя сообщения. Становится известен получатель сообщения.
5. User2 отправляет ответ ОК.
6. Userl отправляет данное сообщение.
7. User2 отправляет ответ ОК.
8. Userl отправляет команду завершения QUIT.
9. User2 отправляет ответ ОК и выполняет отсоединение

Команды отправителя и получателя всегда отправляются по отдельности, и в ответ на каждую команду отправляется одна ответная команда. SMTP не поддерживает отправку нескольких команд в виде пакета. В таблице (см. таблица 7.1) приводится список основных команд SMTP и их назначение.

Набор 7-битных кодов ASCII

Команды протокола SMTP отправляются в виде набора 7-битных символов в стандарте ASCII (American Standard Code for Information Interchange). Этот факт имеет большое значение, поскольку архитектура TCP предполагает использование канала передачи данных с 8 битами на один байт.

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

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

Расширенный набор символов ASCII

Поскольку в алфавитах других стран намного больше символов, то в расширенном наборе символов ASCII определено 256 символов, что подходит для большинства европейских алфавитов. Такое количество симво-лов требует наличия восьмого бита для формирования символов вместо его использования как бита четности. Здесь возникает проблема, поскольку протокол SMTP не позволяет использовать восьмой бит. Таким образом, даже при наличии МТА-агента SMTP, который мог передавать все восемь битов, этот восьмой бит был бы потерян, поскольку сам протокол работает только с семью битами. Решением проблемы стала упаковка восьми битов в семь битов на стороне отправителя и распаковка в восемь битов на стороне получателя. Поскольку биты плохо поддаются упаковке, добавляется несколько дополнительных байтов, чтобы длина последовательности битов делилась на 7 без остатка.

Чтобы выполнить эту задачу, 7 байтов, каждый из которых содержит 8 битов, выстраиваются как последовательность битов, затем каждые 7 битов упаковываются в 1 байт, после чего происходит отправка этих байтов по линии связи. Например, если у вас имеется 7 байтов по 8 битов, то, выстроив последовательно эти байты, можно создать 8 байтов по 7 битов в каждом. На принимающей стороне эти биты переупаковываются в 7 байтов по 8 битов каждый.

Для переупаковки файла с 8-битными данными в другой файл с 7-битными данными при передаче через SMTP используется утилита Uuencode, действующая на основе UNIX. Для обратного преобразования данных в 8-битный стандарт получатель использует утилиту uudecode.

Формат MIME

В настоящее время мы отправляем не только тексты. Выполняется передача файлов из разнообразных PC-приложений на различных языках. Этот уровень сложности требует привлечения таких средств, как стандарт многоцелевых расширений почты интернета (Multipurpose Internet Mail Extension, MIME). Использование MIME позволяет передавать через интернет не только тексты, но и включать в сообщение файлы с различным типом содержимого. Текущее определение MIME дается в документах RFC 2045-2049, и они рассматриваются как единый стандарт.

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

Для каждого типа содержимого указывается тип носителя информации на верхнем уровне и соответствующий подтип. Можно определять дополнительные типы, отличные от указанных в документах RFC, чтобы включать собственные форматы. В таблице (см. таблица 7.2) приводится список наиболее распространенных типов и соответствующих им подтипов. Каждый из пяти дискретных типов соответствует одному файлу. Составные типы могут включать в себя дискретные типы или другие составные типы.

Exchange Server 5.5 основывается на протоколе Х.400, который считается замкнутой системой передачи сообщений. Под этим понимается, что для магистрали Х.400 требуется явно определить агенты МТА для всех узлов в сети или через интернет. С другой стороны, SMTP считается открытой системой передачи сообщений, поскольку любой компьютер, на котором используется SMTP, обычно допускает соединения с любым другим компьютером, использующим SMTP, и эти узловые соединения не требуется указывать заранее. Поскольку SMTP является принятым по умолчанию транспортным протоколом для системы Exchange Server 2003, она имеет больше возможностей взаимодействия с внешними почтовыми системами, чем Exchange Server 5.5.

Каждый сервер SMTP действует как собственный агент передачи сообщений (МТА), направляя сообщения следующему серверу SMTP на основании записей почтового обмена (МХ-записей), которые он ищет в DNS. SMTP передает сообщения через ТСР-порт 25. Если происходит переход от среды Microsoft Exchange 5.5 Server, то вам может показаться удивительным тот факт, что МТА не участвует в передаче сообщений протоколом SMTP. В Exchange 2003 (и Exchange 2000) МТА не играет важной роли при передаче сообщений. МТА по-прежнему существует для соединений с другими системами, основанными на МТА, такими как Exchange 5.5 или Lotus cc:Mail, и он по-прежнему используется для электронной почты, которая передается через коннектор Х.400, однако главным протоколом передачи сообщений внутри среды Exchange 2003 является SMTP, а не МТА.

Расширения службы SMTP

В ноябре 1995 г. был опубликован документ RFC 1869, содержащий несколько расширений структуры команд SMTP. Эти расширения зарегистрированы агентством Internet Assigned Number Authority (IANА). Они позволяют SMTP получателя информировать SMTP отправителя о расширениях, который он поддерживает. Целью этих нововведений в стандарт SMTP являлась адаптация протокола SMTP в предстоящие годы. Этот расширенный SMTP называют ESMTP.

При использовании этих расширений SMTP отправителя передает вместо команды HELO команду EHLO. SMTP получателя может ответить, указав, какие расширения он поддерживает. Если он не поддерживает никаких расширений, то отправляет в ответ сообщение об ошибке.

В Exchange Server 2003 расширения используются с помощью команды ETRN, которая является расширенной версией команды TURN. Эта команда не только просит компьютеры поменяться ролями, но также проверяет имя удаленного хоста, чтобы хосты, отличные от хоста, для которого предназначены сообщения, не могли считывать эти сообщения. Ввиду верификации хост-имени, в которое входит имя домена, ETRN используется для инициирования доставки почты в определенный домен, а не в определенный хост.

Exchange Server 2003 и служба SMTP

SMTP фактически является основой транспортных служб Exchange 2003. Служба SMTP, устанавливаемая Exchange 2003, поддерживает многие команды ESMTP. Хотя имеется только одна служба SMTP, можно сконфигурировать несколько виртуальных серверов SMTP на каждом сервере Exchange 2003. Каждый виртуальный сервер можно запустить, закрыть или приостановить независимо от других виртуальных серверов. Однако закрытие или приостановка самой службы SMTP повлияет на все виртуальные серверы. (Подробнее об этом рассказывается в следующем разделе "Виртуальные серверы SMTP".)

Во время работы службы SMTP могут создаваться новые соединения с пользователями. Закрытие службы повлияет на все соединения пользователей. Если приостановить работу службы SMTP, то каждый виртуальный сервер продолжает обслуживать текущих подсоединенных пользователей, но не допускает подсоединения новых пользователей.

При инсталляции Exchange Server 2003 происходит расширение базовой службы SMTP за счет дополнительных функциональных возможностей:

• команды поддержки информации о состоянии связи (X-LINK2STATE);
• расширенного механизма обработки очередей (AQE);
• улучшенного агента классификации сообщений;
• драйвера хранилищ инсталлируемой файловой системы (IFS).

Примечание. Даже несмотря на то, что в Exchange Server 2003 >-1 устанавливается и функционирует файловая система IFS, базы данных не представляются посредством устройства М:, как это было в Exchange 2000 Server. Поэтому файловая система IFS загружается и работает независимо от того, отображается ли в Exchange 2003 устройство М:.

С: А932 EXAMINE bloop

S: * 17 EXISTS

Команда EXAMINE возвращает те же параметры, что и команда SELECT, а отличается от команды SELECT только тем, что открывает заданный почтовый ящик исключительно на чтение.

С: А042 STATUS blob (MESSAGES UNSEEN)

S: * STATUS blob (MESSAGES 231 UNSEEN 12) '

S: А042 OK STATUS completed

С: А004 LIST "/" *

S: * LIST (\Noinferiors ) "/" INBOX

S: * LIST (\Noinferiors ) "/" OUTBOX

S: * LIST (XNoinferiors ) "/" WasteBox

S: А004 OK LIST completed

Ответ сервера содержит список папок в соответствии с их положением в иерархии и флаги данных папок (флаг "\Noinferiors" означает, что внутри данной папки нет и не может быть построена иерархия).

С: А654 FETCH 10:12 BODY[HEADER]

S: * 10 FETCH (BODY[HEADER] (350)

S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)

S: From: manSglobe.com

S: Subject: Hi

S: To: imapSworld.edu

S: Message-Id:

S: MIME-Version: 1.0

S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

S:

S: )

S: *11 FETCH ....

S: * 12 FETCH ....

S: A654 OK FETCH completed

С: АООЗ STORE 2:4 +FLAGS (\Deleted)

S: * 2 FETCH FLAGS (\Deleted \Seen)

S: * 3 FETCH FLAGS (\Deleted)

S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)

S: АООЗ OK STORE completed

Ответом на выполнение команды будут переданы строки новых флагов указанных сообщении.

С: А282 SEARCH UNSEEN FROM "Smith" SINCE l-Mar-1996

S: * SEARCH 2 84 882

S: А282 OK SEARCH completed

Результатом поиска будут сообщения с последовательными номерами 2, 84 и 882.

С: АООЗ APPEND saved-messages (\Seen) {310}

С : Date: Mon, 7 Feb 1997 21:52:25 -0800 (PST)

С: From: Fred Foobar

С: Subject: afternoon meeting

С: То: mooch@owatagu.siam.edu

С: Message-Id:

С: MIME-Version: 1.0

С: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

С:

С: Hello Joe, do you think we can meet at 3:30 tomorrow

С : S АООЗ OK APPEND completed

Отметим, что команда APPEND не осуществляет доставку сообщения по указанному адресу, она только размещает в данном каталоге набор строк в виде сообщения.

Если сервер IMAP4 поддерживает 8-битовые данные, можно добавлять тексты сообщений в 8-битной кодировке, иначе текст должен быть закодирован в одну из 7-битных кодировок.

С: АООЗ COPY 2:4 MEETING

S: АООЗ OK COPY completed

Более подробное описание этих и других команд управления каталогами и сообщениями вы можете найти, например, в RFC-2060.

Пример сценария

Далее приведен простейший сценарий сессии работы IМАР4-клиента с сервером.

S: * OK IMAP4revl Service Ready

С: aOOl login alladin sesam

S: aOOl OK LOGIN completed

C: a002 select inbox

S: * 18 EXISTS

S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

S: * 2 RECENT

S: * OK [UNSEEN 17] Message 17 is the first unseen message

S: * OK [UIDVALIDITY 3857529045] UIDs valid

S: a002 OK [READ-WRITE] SELECT completed

С: аООЗ fetch 12 body[header]

S: * 12 FETCH (BODY[HEADER] {350}

S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)

S: From: gray@cac.Washington.edu

S: Subject: IMAP4revl WG mtg summary and minutes

S: To: imap@cac.Washington.edu

S: Message-Id:

S: MIME-Version: 1.0

S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

S:

S: )

S: аООЗ OK FETCH completed

С: а004 store 12 +flags \deleted

S: * 12 FETCH (FLAGS (\Seen \Deleted))

S: а004 OK +FLAGS completed

С: а005 logout

S: * BYE IMAP4revl server terminating connection

S: а005 OK LOGOUT completed

Протокол почтового отделения, версия 3 – Post Office Protocol - Version 3 ( POP3) предназначен для получения сообщений, находящихся в почтовом ящике пользователя на удаленном сервере электронной почты.

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

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

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

Протокол POP был разработан в 1984 году, в 1985 году появилась вторая его версия, в 1988 году – третья, которая с существенными модификациями, сделанными в 1991, 1993, 1994 и 1996 годах, используется по сей день. На момент написания этого пособия, последняя модификация протокола POP3 описана в RFC 1939 .

POP3 прост в реализации и предоставляет минимальные необходимые возможности для работы с почтовым ящиком. Вопреки распространенному мнению, третья версия протокола POP дает возможность работать не только с ящиком в целом, но и с отдельными сообщениями, находящимися в нем, позволяя просматривать информацию о письмах, получать и удалять их по отдельности. К сожалению, не все существующие MUA используют эти возможности протокола POP3. Пользователь не всегда хочет скачивать с сервера все содержимое почтового ящика, и часто предпочел бы получать только некоторые сообщения, а другие сообщения, возможно, удалил бы, не получая. Все это можно сделать, используя протокол POP3. Более широкие возможности предоставляет протокол IMAP 4 , но в большом числе случаев возможностей протокола POP3 оказывается вполне достаточно.

Сеанс протокола POP3 делится на три этапа (состояния). Схема переходов между состояниями сеанса POP3 представлена на рис. 5 .

Рис.5. Состояния сеанса POP3 

Сервер ожидает соединения по порту TCP 110.

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

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

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

В ходе сеанса клиент посылает серверу команды, а сервер сообщает о результате выполнения каждой из них. Ответ состоит из индикатора состояния (status indicator) и, если нужно, дополнительной информации, отделенной пробелом. Строка ответа может содержать до 512 символов, включая последовательность CRLF, обозначающую конец строки.

Предусмотрено два индикатора состояния: "+OK" – успешное завершение и "-ERR" – неуспешное завершение. Если строка ответа не содержит дополнительной информации, то после индикатора состояния сразу должна идти последовательность CRLF. Однако некоторые клиенты ожидают пробела после индикатора состояния. Это противоречит существующим стандартам, но наличие таких клиентов все же следует принимать во внимание (см. RFC 1957 ).

Если команда предусматривает многострочный ответ, то индикатор состояния передается только в первой строке, а последняя строка ответа должна состоять из одной точки. Эта строка не является частью ответа, а только обозначает его завершение. Чтобы сделать возможным использование строк, состоящих из одной точки, в ответах сервера, ко всем строкам ответа, начинающимся с точки, добавляется еще одна точка, аналогично тому, как это делается при передаче текста сообщения в команде DATA протокола SMTP . Если на приемном конце в ответе сервера обнаруживается строка, начинающаяся с точки, то, если непосредственно за этой точкой стоит последовательность CRLF, строка интерпретируется как конец ответа, если же за точкой следуют любые другие символы, то ведущая точка удаляется, а строка интерпретируется как часть ответа.

Каждая команда POP3 состоит из ключевого слова и, возможно, из аргументов, разделенных пробелами. Ключевые слова состоят из трех или четырех букв, передаваемых независимо от регистра. Аргументы могут содержать только символы ASCII . Каждый аргумент может состоять не более чем из сорока символов.

Рассмотрим команды протокола POP3, которые обязательно должны быть реализованы.

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

1.1 STAT

В ответ на команду STAT сервер возвращает количество сообщений в почтовом ящике и общий размер ящика в октетах. Сообщения, помеченные для удаления, при этом не учитываются. Например, ответ " +OK 4 223718" означает, что в почтовом ящике имеется 4 сообщения общим объемом 223718 октет.

1.2 LIST

Ответ на команду LIST без аргумента: список сообщений в почтовом ящике, содержащий их порядковые номера и размеры в октетах.

Пример:

В данном примере в ящике имеется 4 сообщения, длины которых, соответственно, 333, 111293, 111285 и 807 октет.

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

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

1.3 RETR

Требует в качестве аргумента номер существующего и не помеченного для удаления сообщения.

В ответ сервер присылает запрошенное сообщение.

1.4 DELE

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

1.5 NOOP

На эту команду сервер должен дать положительный ответ. Никаких других действий не производится.

1.6 RSET

Сервер снимает все установленные ранее пометки для удаления.

1.7 QUIT

Завершение сеанса. Если в ходе сеанса какие-то сообщения были помечены для удаления, то после выполнения команды QUIT они удаляются из ящика.

4.2 Дополнительные возможности POP3

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

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

Предусмотрена команда САРА, позволяющая клиенту получить информацию о дополнительных возможностях, реализованных на сервере, и их параметрах. Ответ на эту команду аналогичен ответу на команду EHLO протокола SMTP .

2.1 Команда САРА

В ответ на команду САРА сервер присылает клиенту список ключевых слов, соответствующих дополнительным возможностям протокола POP3, поддерживаемым сервером, и, при необходимости, параметры этих возможностей.

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

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

Команда САРА описана в RFC 2449 . Там же описан и ряд дополнительных команд протокола POP3.

Пример:

Ниже приведены ключевые слова и описаны соответствующие дополнительные возможности протокола POP3.

2.2 USER – авторизация по паролю

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

Сначала клиент направляет серверу команду USER . В качестве аргумента команды используется имя, под которым на сервере зарегистрирован ящик, к которому запрашивается доступ. Если такой ящик существует, сервер дает положительный ответ, а клиент посылает команду PASS с паролем для доступа к данному ящику в качестве аргумента.

Пример :

2.3 Авторизация по зашифрованному паролю

Серьезный недостаток использования команд USER и PASS – необходимость передавать пароль по сети открытым текстом. Это дает потенциальному злоумышленнику возможность перехватить пароль. Опасность возрастает, если пользователь часто проверяет свою почту: в этом случае соединение устанавливается регулярно, с небольшим интервалом, и каждый раз по сети передается пароль.

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

Сервер, поддерживающий команду APOP , в начальном приветствии посылает клиенту уникальный идентификатор, содержащий метку времени в формате msg-id, описанном в RFC 822 . Поскольку наличие такой метки уже свидетельствует о поддержке сервером команды APOP , ключевого слова, соответствующего этой команде, возвращаемого в ответе сервера на команду САРА, не предусмотрено.

Клиент в качестве аргументов команды APOP передает серверу имя пользователя и шестнадцатизначную последовательность шестнадцатиричных чисел в нижнем регистре, вычисляемую по алгоритму MD 5, описанному в RFC 1321 . В качестве исходного текста для вычисления этой последовательности берется строка, состоящая из переданного сервером уникального идентификатора и пароля пользователя. Чем длиннее строка пароля, тем сложнее злоумышленнику вычислить ее на основании передаваемой в команде APOP последовательности. Рекомендуется использовать пароли, содержащие не меньше восьми символов.

Пример :

Здесь

уникальный идентификатор: <1896.697170952@ dbc . mtview . ca . us >;

имя пользователя: mrose ;

пароль: tanstaaf.

Имя пользователя передается открытым текстом в первом аргументе команды APOP второй аргумент: c 4 c 9334 bac 560 ecc 979 e 58001 b 3 e 22 fb вычисляется по алгоритму MD 5 из строки <1896.697170952@dbc.mtview.ca.us>tanstaaf, состоящей из уникального идентификатора и пароля.

2.4 SASL – авторизация с использованием SASL

Команда AUTH , предложенная в RFC 1734 . Ответы сервера предваряются символами плюс и пробел: "+ ". Если клиент хочет прервать аутентификацию, он посылает символ звездочка: "*".

В строке ответа сервера на команду САРА после ключевого слова " SASL " сервер передает список ключевых слов, соответствующих поддерживаемым сервером механизмам авторизации. Ключевые слова разделяются пробелами. Например:

SASL CRAM - MD 5 KERBEROS _ V 4

2.5 STLS – криптографическая защита сеанса POP3 с использованием протокола TLS

Команда AUTH , описанная выше, предоставляет простейший механизм шифрования данных, передаваемых по протоколу POP3. Более надежный способ криптографической защиты обеспечивается протоколом TLS . Его использование совместно с протоколом POP3 описано в RFC 2595 .

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

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

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

Результаты выполнения команды САРА до начала защищенного сеанса и после могут различаться.

2.6 TOP – первые строки сообщения

Дополнительная команда TOP, описанная в RFC 1939 , позволяет клиенту получить заголовок и первые строки тела указанного в аргументе сообщения. Эта команда дает пользователю возможность, не скачивая все сообщение, на основании адреса отправителя и темы, указанных в заголовке, а также из первых строк письма, принять решение, получать данное сообщение сейчас, сделать это позже или удалить, не читая.

Формат команды:

ТОР номер_сообщения число_строк

Если второй аргумент больше, чем число строк в теле сообщения, то клиент получает сообщение целиком.

2.7 UIDL – уникальный идентификатор сообщения

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

Доступ к уникальным идентификаторам сообщений предоставляет дополнительная команда UIDL , описанная в RFC 1939 . Если она используется без аргументов, то в ответ на нее сервер присылает порядковые номера и уникальные идентификаторы всех сообщений в почтовом ящике, не помеченных для удаления. Если в качестве аргумента указан номер сообщения в ящике, то сервер возвращает порядковый номер и уникальный идентификатор только этого сообщения.

Пример:

2.8 RESP-CODES – расширенные коды ответов

Наличие в ответе команды САРА строки "RESP-CODES" не свидетельствует о поддержке какой-либо команды. Эта дополнительная возможность позволяет серверу использовать расширенные коды ответов.

Расширенные коды ответов передаются после стандартного индикатора состояния: "+OK" или "–ERR" и заключаются в квадратные скобки. Они могут иметь иерархическую структуру, то есть могут состоять из нескольких кодов, каждый из которых уточняет предыдущие. В этом случае коды разделяются косой чертой: "/". Необязательный текст, поясняющий ответ сервера, может следовать после расширенного кода.

RFC 2449 ". Этот код передается после успешной аутентификации и свидетельствует о том, что доступ к почтовому ящику, тем не менее, невозможен, поскольку в настоящее время ящик уже используется, возможно, другим сеансом POP3.

Пример :

2.9 LOGIN-DELAY – определение минимального интервала времени между сеансами

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

Чтобы уменьшить нагрузку на сервер, можно установить время, в течение которого клиенту не разрешается инициировать повторный сеанс. Если оно установлено, то в ответе сервера на команду САРА должна содержаться строка вида:

LOGIN-DELAY время_задержки

где время_задержки – интервал в секундах, в течение которого не разрешается начинать повторный сеанс POP3. Время отсчитывается от момента положительного ответа сервера на одну из команд авторизации (PASS, APOP или AUTH) до следующей попытки авторизации того же пользователя.

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

LOGIN-DELAY время_задержки USER

где время_задержки – максимальное из всех установленных на сервере времен задержки. Пометка "USER" свидетельствует о том, что на самом деле время задержки зависит от пользователя и может быть уточнено после авторизации. Выполнив команду САРА на этапе транзакции, клиент может получить точное время задержки именно для данного пользователя.

2.10 PIPELINING - группирование команд

Аналог одноименного расширения ESMTP .

Эта дополнительная возможность не вводит новых команд, но позволяет клиенту посылать серверу команды, не дожидаясь ответов на предыдущие. Это ускоряет обмен данными. Например, клиент может посылать команды DELE в то время, когда сервер шлет ему запрошенные ранее сообщения.

2.11 EXPIRE – ограничение времени хранения сообщений на сервере

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

Программное обеспечение хранилища сообщений может само удалять из ящиков старые письма. Администратор может определять довольно сложные правила удаления: они могут различаться для разных пользователей, время хранения может отсчитываться от разных моментов: от поступления сообщения, от первого сеанса POP3 после поступления сообщения, от первого прочтения командой RETR или TOP и т.д. Если подобные правила определены, сервер POP3 должен информировать об этом клиента в ответе на команду САРА.

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

0 – прочитанные сообщения на сервере не хранятся;

целое число – минимальное время хранения сообщения в днях;

NEVER – сообщения автоматически не удаляются.

Если для разных пользователей предусмотрены разные правила удаления старых сообщений, то на запрос САРА в состоянии авторизации сервер возвращает минимальное значение параметра EXPIRE для всех пользователей, за которым следует модификатор " USER ". Это означает, что после авторизации клиенту следует повторить команду САРА, чтобы получить более точные данные об удалении с сервера старой корреспонденции именно этого пользователя.

Примеры :

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

2.12 IMPLEMENTATION – информация о сервере

Строка ответа на команду САРА IMPLEMENTATION содержит версию программного обеспечения сервера POP3. Эта информация может быть передана также в строке приветствия сервера при установлении соединения. Но из соображений безопасности эти сведения не желательно делать доступными не аутентифицированным пользователям. Потому строка IMPLEMENTATION обычно передается клиенту только в состоянии транзакции.

Строка IMPLEMENTATION предусматривает только один параметр, потому информация о сервере, передаваемая в ней, не должна содержать пробелов.

4.3 Пример сеанса POP3

FTP-протокол.

FTP (File Transfer Protocol, или “Протокол передачи данных”) - один из старейших протоколов в Internet и входит в его стандарты. Первые спецификации FTP относятся к 1971 году. С тех пор FTP претерпел множество модификаций и значительно расширил свои возможности. FTP может использоваться как в программах пользователей, так и в виде специальной утилиты операционной системы.

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

Обмен данными в FTP происходит по TCP-каналу. Обмен построен на технологии “клиент-сервер”. FTP не может использоваться для передачи конфиденциальных данных, поскольку не обеспечивает защиты передаваемой информации и передает между сервером и клиентом открытый текст. FTP-сервер может потребовать от FTP-клиента аутентификации (т.е. при присоединении к серверу FTP-пользователь должен будет ввести свой идентификатор и пароль). Однако пароль, и идентификатор пользователя будут переданы от клиента на сервер открытым текстом.

Модели работы FTP.

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

Рис.1

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

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

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

Алгоритм работы протокола FTP состоит в следующем:

1. Сервер FTP использует в качестве управляющего соединение на TCP порт 21, который всегда находится в состоянии ожидания соединения со стороны пользователя FTP.
2. После того как устанавливается управляющее соединение модуля “Интерпретатор протокола пользователя” с модулем сервера — “Интерпретатор протокола сервера”, пользователь (клиент) может отправлять на сервер команды. FTP-команды определяют параметры соединения передачи данных: роль участников соединения (активный или пассивный), порт соединения (как для модуля “Программа передачи данных пользователя”, так и для модуля “Программа передачи данных сервера”), тип передачи, тип передаваемых данных, структуру данных и управляющие директивы, обозначающие действия, которые пользователь хочет совершить (например, сохранить, считать, добавить или удалить данные или файл и другие).
3. После того как согласованы все параметры канала передачи данных, один из участников соединения, который является пассивным (например, “Программа передачи данных пользователя”), становится в режим ожидания открытия соединения на заданный для передачи данных порт. После этого активный модуль (например, “Программа передачи данных сервера”) открывает соединение и начинает передачу данных.
4. После окончания передачи данных, соединение между “Программой передачи данных сервера” и “Программой передачи данных пользователя” закрывается, но управляющее соединение “Интерпретатора протокола сервера” и “Интерпретатора протокола пользователя” остается открытым. Пользователь, не закрывая сессии FTP, может еще раз открыть канал передачи данных.

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

Рис. 2

Алгоритм работы при соединение двух FTP-серверов, ни один из которых не расположен на локальном хосте пользователя:

1. Модуль “Интерпретатор протокола пользователя” указал модулю сервера “Интерпретатор протокола сервера 1” работать в пассивном режиме, после чего модуль “Интерпретатор протокола сервера 1” отправил пользователю адрес и номер порта (N) , который он будет слушать.
2. Модуль “Интерпретатор протокола пользователя” назначил модуль сервера 2 “Интерпретатор протокола сервера 2” в качестве активного участника соединения и указал ему передавать данные на хост “Интерпретатор протокола сервера 1” на порт (N).
3. “Интерпретатор протокола пользователя” подал “Интерпретатору протокола сервера 1” команду “сохранить поступившие данные в таком-то файле”, а “Интерпретатор протокола сервера 2” — “передать содержимое такого-то файла”.
4. Между модулями “Интерпретатор протокола сервера 1” и “Интерпретатор протокола сервера 2” образуется поток данных, который управляется клиентским хостом.

Ниже приведена схема организации передачи данных между двумя серверами FTP, соответствующая рисунку 2. Здесь использованы следующие обозначения: User PI - интерпретатор протокола пользователя; Server1(2) интерпретатор протокола сервера1 (сервера2).

Основу передачи данных FTP составляет механизм установления соединения между соответствующими портами и выбора параметров передачи. Каждый участник FTP-соединения должен поддерживать порт передачи данных по умолчанию. По умолчанию “Программа передачи данных пользователя” использует тот же порт, что и для передачи команд (обозначим его “U”), а “Программа передачи данных сервера” использует порт L-1, где “L”- управляющий порт. Однако, участниками соединения используются порты передачи данных, выбранные для них “Интерпретатором протокола пользователя”, поскольку из управляющих процессов участвующих в соединении, только “Интерпретатор протокола пользователя” может изменить порты передачи данных как у “Программы передачи данных пользователя”, так и у “Программы передачи данных сервера”.

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

После того как соединение установлено, между “Программой передачи данных сервера” и “Программой передачи данных пользователя” начинается передача. Одновременно по каналу “Интерпретатор протокола сервера” — “Интерпретатор протокола пользователя” передаются уведомления о получении данных. Протокол FTP требует, чтобы управляющее соединение было открыто, пока по каналу обмена данными идет передача. Сессия FTP считается закрытой только после закрытия управляющего соединения.

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

1. Сервер закончил передачу данных в формате, который требует закрытия соединения.
2. Сервер получил от пользователя команду “прервать соединение”.
3. Пользователь изменил параметры порта передачи данных.
4. Было закрыто управляющее соединение.
5. Возникли ошибки, при которых невозможно возобновить передачу данных.

Команды протокола.

Команды управления контролем передачи данных, которыми обмениваются “Интерпретатор протокола сервера” и “Интерпретатор протокола пользователя”, можно разделить на три большие группы:

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

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

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

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

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

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

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

Команды управления потоком устанавливают параметры передачи данных. Все параметры, описываемые этими командами имеют значение по умолчанию, поэтому команды управления потоком используются только тогда, когда необходимо изменить значение параметров передачи, используемых по умолчанию. Команды управления потоком могут подаваться в любом порядке, но все они должны предшествовать командам FTP-сервиса. Из команд управления потоком данных следует выделить следующие:

PORT. Команда назначает адрес и порт хоста, который будет использоваться как активный участник соединения по каналу передачи данных. Аргументами команды являются 32-битный IP адрес и 16-битный номер порта соединения. Эти значения разбиты на шесть 8-битных полей и представлены в десятичном виде: h1, h2, h3, h4, p1, p2, где hN - байты адреса (от старшего к младшему), а pN - байты порта (от старшего к младшему).

PASV. Эта команда отправляется модулю, который будет играть пассивную роль в передаче данных (“слушать” соединение). Ответом на данную команду должна быть строка, содержащая адрес и порт хоста, находящиеся в режиме ожидания соединения в формате команды PORT — “h1, h2, h3, h4, p1, p2”.

Команды TYPE, STRU, MODE определяют, соответственно, тип передаваемых данных (ASCII, Image и другие), структуру или формат передачи данных (File, Record, Page), способ передачи (Stream, Block и другие). Использование этих команд очень важно при построении взаимодействия в гетерогенных средах и весьма отличающихся операционных и файловых систем взаимодействующих хостов.

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

RETR. Эта команда указывает модулю “Программа передачи данных сервера” передать копию файла, заданного параметром этой команды, модулю передачи данных на другом конце соединения.

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

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

ABOR. Команда предписывает серверу прервать выполнение предшествующей сервисной команды (например, передачу файла) и закрыть канал передачи данных.

Команда DELE удаляет указанный файл.

Команды MKD и RMD, соответственно, создают и удаляют указанный в аргументе каталог.

При помощи команд LIST и NLST можно получить список файлов в указанном каталоге.

Все команды FTP-протокола отправляются “Интерпретатором протокола пользователя” в текстовом виде - по одной команде в строке. Каждая строка команды - идентификатор и аргументы - заканчиваются символами . Имя команды отделяется от аргумента символом пробела - .

Обработчик команд возвращает код обработки каждой команды, состоящий из трех цифр. Коды обработки составляют определенную иерархическую структуру и, как правило, определенная команда может возвратить только определенный набор кодов. За кодом обработки команды следует символ пробела - , затем следует текст пояснения. Например, строка успешного завершения операции выглядит следующим образом: “200 Command okay”.

Ниже приведен пример работы с FTP-протокола. Обозначения: S - сервер, U - пользователь.

S: 220 Service ready for new user
U: USER Gluk
> S: 331 User name okay, need password
U: PASS murmur
S: 230 User logged in, proceed
U: RETR test.txt
S: 150 File status okay; about to open data connection

<Идет передача файла ...>

S: 226 Closing data connection, file transfer successful
U: TYPE I
S: 200 Command okay
U: STOR /home/images/first.my
S: 550 Access denied
U: QUIT

Протокол HTTP и способы передачи данных на сервер

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

HTTP (HyperText Transfer Protocol, протокол передачи гипертекста) – это протокол прикладного уровня, разработанный для обмена гипертекстовой информацией в Internet.

HTTP предоставляет набор методов для указания целей запроса, отправляемого серверу. Эти методы основаны на дисциплине ссылок, где для указания ресурса, к которому должен быть применен данный метод, используется универсальный идентификатор ресурсов (Universal Resource Identifier) в виде местонахождения ресурса (Universal Resource Locator, URL) или в виде его универсального имени (Universal Resource Name, URN).

Сообщения по сети при использовании протокола HTTP передаются в формате, схожем с форматом почтового сообщения Internet (RFC-822) или с форматом сообщений MIME (Multiperposal Internet Mail Exchange).

HTTP используется для коммуникаций между различными пользовательскими программами и программами-шлюзами, предоставляющими доступ к существующим Internet-протоколам, таким как SMTP (протокол электронной почты), NNTP (протокол передачи новостей), FTP (протокол передачи файлов), Gopher и WAIS. HTTP разработан для того, чтобы позволять таким шлюзам через промежуточные программы-серверы (proxy) передавать данные без потерь.

Протокол реализует принцип запрос/ответ. Запрашивающая программа – клиент инициирует взаимодействие с отвечающей программой – сервером и посылает запрос, содержащий:

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

Ответ сервера содержит:

• строку состояния, в которую входит версия протокола и код возврата (успех или ошибка);
• сообщение (в форме, похожей на MIME), в которое входит информация сервера, метаинформация (т.е. информация о содержании сообщения) и тело сообщения.

В протоколе не указывается, кто должен открывать и закрывать соединение между клиентом и сервером. На практике соединение, как правило, открывает клиент, а сервер после отправки ответа инициирует его разрыв.

Давайте рассмотрим более подробно, в какой форме отправляются запросы на сервер.

Форма запроса клиента

Клиент отсылает серверу запрос в одной из двух форм: в полной или сокращенной. Запрос в первой форме называется соответственно полным запросом, а во второй форме – простым запросом.

Простой запрос содержит метод доступа и адрес ресурса. Формально это можно записать так:

<Простой-Запрос> := <Метод> <символ пробел>

    <Запрашиваемый-URI> <символ новой строки>

В качестве метода могут быть указаны GET, POST, HEAD, PUT, DELETE и другие. О наиболее распространенных из них мы поговорим немного позже. В качестве запрашиваемого URI чаще всего используется URL-адрес ресурса.

Пример простого запроса:

GET http://phpbook.info/

Здесь GET – это метод доступа, т.е. метод, который должен быть применен к запрашиваемому ресурсу, а http://phpbook.info/ – это URL-адрес запрашиваемого ресурса.

Полный запрос содержит строку состояния, несколько заголовков (заголовок запроса, общий заголовок или заголовок содержания) и, возможно, тело запроса. Формально общий вид полного запроса можно записать так:

<Полный запрос> := <Строка Состояния>

    (<Общий заголовок>|<Заголовок запроса>|

    <Заголовок содержания>)

    <символ новой строки>

    [<содержание запроса>]

Квадратные скобки здесь обозначают необязательные элементы заголовка, через вертикальную черту перечислены альтернативные варианты. Элемент <Строка состояния> содержит метод запроса и URI ресурса (как и простой запрос) и, кроме того, используемую версию протокола HTTP. Например, для вызова внешней программы можно задействовать следующую строку состояния:

POST http://phpbook.info/cgi-bin/test HTTP/1.0

В данном случае используется метод POST и протокол HTTP версии 1.0.

В обеих формах запроса важное место занимает URI запрашиваемого ресурса. Чаще всего URI используется в виде URL-адреса ресурса. При обращении к серверу можно применять как полную форму URL, так и упрощенную.

Полная форма содержит тип протокола доступа, адрес сервера ресурса и адрес ресурса на сервере (рисунок 4.2).

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

Рис. 4.2.  Полная форма URL

Далее мы рассмотрим наиболее распространенные методы отправки запросов.

Методы

Как уже говорилось, любой запрос клиента к серверу должен начинаться с указания метода. Метод сообщает о цели запроса клиента. Протокол HTTP поддерживает достаточно много методов, но реально используются только три: POST, GET и HEAD. Метод GET позволяет получить любые данные, идентифицированные с помощью URI в запросе ресурса. Если URI указывает на программу, то возвращается результат работы программы, а не ее текст (если, конечно, текст не есть результат ее работы). Дополнительная информация, необходимая для обработки запроса, встраивается в сам запрос (в строку статуса). При использовании метода GET в поле тела ресурса возвращается собственно затребованная информация (текст HTML-документа, например).

Существует разновидность метода GET – условный GET. Этот метод сообщает серверу о том, что на запрос нужно ответить, только если выполнено условие, содержащееся в поле if-Modified-Since заголовка запроса. Если говорить более точно, то тело ресурса передается в ответ на запрос, если этот ресурс изменялся после даты, указанной в if-Modified-Since.

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

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

До сих пор мы только теоретизировали, знакомились с основными понятиями. Теперь пора научиться использовать все это на практике. Далее в лекции мы рассмотрим, как посылать запросы серверу и как обрабатывать его ответы.

• IPX (Internetwork Packet Exchange) - протокол межсетевого обмена пакетами. Это основной протокол стека, он соотносится с сетевым уровнем модели OSI;

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

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

Еще одна особенность IPX заключается в том, что он определяет размеры пакетов, руководствуясь пропускной способностью среды, к которой он подключен. Хотя минимальная величина IPX-пакета составляет 512 байтов, если два узла непосредственно соединены с Ethernet-сегментом, они пользуются пакетами размером 1024 байта. Если оба узла находятся в кольцевой сети с маркерным доступом, они будут использовать пакеты размером 4096 байта. IPX-маршрутизаторы, однако, всегда конвертируют пакеты обратно в стандартные 512-байтовые. Метод маршрутизации, принятый Novell, позволяет также повышать эффективность передачи данных, ограничивая в пакетах "пустое пространство" путем так называемого разреженного пакетирования. Общую длину пакета можно сократить до размера "конверта" и находящихся в нем данных. Этот метод применяется, в основном, для повышения эффективности работы маршрутизатора.

• SPX (Sequenced Packet Exchange) - протокол последовательного обмена пакетами; обеспечивает надежность передачи данных;
• PEP (Packet Exchange Protocol) - протокол обмена пакетами;
• NCP (NetWare Core Protocol) - основной протокол верхнего уровня. Он обеспечивает работу основных служб сетевой ОС Novell NetWare и объединяет функции всех уровней от транспортного до прикладного модели OSI;

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

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

Другой транспортный протокол - протокол обмена пакетами PEP - используется исключительно для доставки команд протокола ядра NetWare (NetWare Core Protocol, NCP). NCP содержит словарь команд сетевого ввода-вывода. NCP - сердце серверной системы NetWare. PEP считается частью подсистемы NCP и не документирован.

PEP выполняет функции коррекции ошибок с помощью "таймеров". Когда из PEP посылается пакет, в NCP запускается внутренний таймер, и до получения ответа больше ни один NCP-пакет не посылается. Если время истекает, PEP повторно отправляет пакет, а NCP перезапускает таймер. Такое квитирование и ожидание приводит к крайне неэкономному "расходованию" полосы пропускания NCP, но гарантирует доставку пакетов. В небольших локальных сетях это проходит незамеченным, но в крупных и чрезвычайно сложных сетях производительность может существенно снизиться.

• SAP (Service Advertising Protocol) - протокол оповещения о сервисах; он используется при широковещательных сообщениях, когда узел передает информацию о сетевых службах, которые он может предоставить; здесь же указывается его сетевой адрес.

Протокол оповещения о сервисах SAP "рекламирует" сетевые устройства и ресурсы. SAP выдает информацию о сервера, маршрутизаторах, интеллектуальных принтерах и т.д. Хотя SAP, в принципе, протокол прикладного уровня, он обращается к IPX напрямую. Информацию у SAP получают и другие подпротоколы, в частности, NCP и SPX.

Поскольку NetWare - это сеть, в которой для адресации используются номера устройств, должен быть какой-то способ перевода установленных человеком имен устройств в "реальные" числовые адреса этих устройств. SAP предоставляет эту услугу. Когда появляется программа или сервис, SAP замечает ее и создает соответствующий элемент у себя в таблицах. Хотя такой динамический реестр имен и облегчает жизнь пользователям, на постоянное обновление информации может быть "истрачена" вся полоса пропускания сети, потому что каждое SAP-устройство имеет свои таблицы рассылки. Для пользователей глобальной сети фильтрация SAP-пакетов на маршрутизаторах - хороший способ освобождения солидной части полосы пропускания. SAP можно также имитировать на маршрутизаторах: сервис объявляется, но линии глобальной сети не занимаются передачей SAP-пакетов - передаются только "образы" сервисов.

• RIP (Routing Information Protocol) - протокол маршрутной информации.

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

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

IPX-сети не относятся к числу иерархических, т.е. каждый маршрутизатор должен знать, как попасть во все остальные сегменты сети. По мере роста сетей эта схема становится неуправляемым и крайне дорогостоящим способом слежения за удаленными сетями. Novell разработала протокол состояния канала (NetWari Link State Protocol, NLSP), который работает гораздо лучше в очень сложных сетях. Маршрутизаторы не соуществляют непрерывную широковещательную передачу информации обо всех сетях и маршрутизаторах, которые им известны, а рассылают только ту информацию, которая изменилась, что значительно сокращает потребность в полосе пропускания.

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

Конфигурирование клиентской части не требует значительных затрат. Адрес узла считывается автоматически из сетевого адаптера узла. Адрес сети узнается из серверных объявлений SAP. Для выяснения адреса маршрутизатора при старте системы клиента посылается сообщение SAP, в ответ на которое имеющиеся маршрутизаторы сообщают свои адреса.