«Е. Д. Жиганов А. П. Мощевикин Передача данных в компьютерных сетях Учебное пособие Петрозаводск Издательство ПетрГУ 2007 УДК 681.324 ББК 32.973.202 Ж68 Печатается по решению редакционно-издательского совета ...»

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

5. После выхода из режима ожидания станция снова может начинать передачу (переход на пункт 1).

Метод доступа к среде в сетях Ethernet (CSMA/CD) носит конкурентный характер. Станции прослушивают среду, и если она свободна, имеют право начать передачу. Из-за неопределенности этого момента и достаточно большой длины кабельной системы в среде могут возникать коллизии (то есть "столкновения" сигналов). Это приводит к необходимости повторной передачи через некоторый, случайным образом выбранный, интервал времени. Коллизии уменьшают общую пропускную способность сети.

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

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

рис.):

a) коллизий не существует (сетевые карты работают в дуплексном режиме);

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

в) домен коллизий ограничен кабелем от сетевой карты до коммутатора (сетевые карты работают в полудуплексном режиме).

Отсюда становится понятным, что в полнодуплексном режиме при использовании технологии Fast Ethernet в случае а) общая пропускная способность между двумя компьютерами будет 200 Мбит/сек. В случае использования репитеров (повторителей, хабов) общая пропускная способность понижается по мере подключения новых компьютеров в сеть (обработка ситуации с коллизиями отбирает часть времени, которое могло быть затрачено на передачу полезного трафика).

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

2.2. Формат кадра Ethernet Существует 4 различных вида кадров Ethernet, их общий вид представлен ниже.

• DA – адрес назначения (Destination Address, 6 байтов);

• SA – адрес источника (Source Address, 6 байтов);

• L/T – длина или тип кадра (Length/Type, 2 байта);

• Data – данные верхнего уровня (например, IP-уровня, 46– байтов);

• CRC – поле контрольной суммы (Cyclical Redundancy Check, 4 байта).

Необходимо также отметить, что перед каждым кадром станцияотправитель добавляет преамбулу и начальный ограничитель кадра (8 байтов). Кроме того, все станции должны выдерживать межкадровые промежутки в 96 тактов (например, 9.6 мкс при битовой скорости 10 Мбит/с).

2.3. Promiscuous mode (режим прослушивания сети) В обычном режиме функционирования сетевого интерфейса при получении кадра данные (46–1500 байтов) будут переданы обработчику верхнего уровня только в случаях, если адрес назначения, установленный в поле DA, широковещательный либо он совпадет с уникальным МАС-адресом принимающей станции.

Однако каждый адаптер Ethernet может быть переведен в режим, в котором будут обрабатываться все кадры, поступающие из среды передачи. На английском языке такой режим носит название "promiscuous", что переводится как "безразличный" или "неразборчивый". Этим свойством сетевых адаптеров можно пользоваться, например, для создания программных анализаторов сетевого трафика (tcpdump, см. главу с описанием сетевых утилит).

Контрольные вопросы к главе 1. Опишите метод доступа к среде передачи CSMA/CD, используемый в Ethernet.

2. Что такое МАС-адрес? Укажите уровень по модели OSI/RM, в рамках которого уместно упоминать MAC-адрес.

3. В чем разница между физической и логической топологиями посроения сетей?

4. Рассчитайте полезную пропускную способность сети Fast Ethernet (100 Мбит/с), учитывая в качестве накладных расходов межкадровые промежутки, преамбулу кадра и заголовки канального уровня.

5. В каком случае при поступлении кадра с физического уровня станция будет "изучать" поле канального уровня?

6. Что такое promiscuous режим?

7. Укажите максимальное количество возможных уникальных (unicast) МАС-адресов.

Глава 3.

Протоколы стека TCP/IP и прикладного уровня Стек TCP/IP (Transmission Control Protocol / Internet Protocol, протокол управления передачей / межсетевой протокол) в отличие от OSI/RM содержит всего 4 уровня: I – прикладной, II – транспортный, III – межсетевой, IV – физический (физического интерфейса). Все они в той или иной степени соответствуют уровням идеальной модели, то есть выполняют похожие функции.

TCP UDP II

IP ICMP

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

ARP/RARP4 – протокол, заголовки и данные которого инкапсулированы непосредственно в кадр канального уровня, а не в IP-датаграмму5, предназначен для взаимосвязи адресации канального (чаще всего MACадресация) и сетевого уровней (IP-адресация). ICMP6 инкапсулирован в ARP/RARP – Address Resolution Protocol / Reversed ARP (протокол распознавания адреса / протокол обратного распознавания адреса).

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

ICMP – Internet Control Message Protocol (межсетевой протокол управляющих сообщений).

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

Транспортный уровень представлен двумя способами организации связи: с гарантированной (TCP) и негарантированной (UDP7) доставкой данных.

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

3.1. Межсетевой протокол IP (Internet Protocol) Протокол IP – это протокол сетевого уровня по модели OSI/RM.

Формат IP-датаграммы представлен ниже; каждая строчка содержит 32 бита (4 байта).

Version – версия IP-протокола (для IPv4 в это поле заносится 4, что соответствует в бинарном виде 0100 в старшем полубайте первого октета датаграммы);

IHL – длина заголовка в 32-битовых словах (Internet Header Length, 4 бита; в случае IPv4 и длины заголовка в 32-битовых словах, равной 5, в первом байте IP-датаграммы содержится 0x45);

TOS – тип сервиса (Type of Service, 1 байт);

TL – полная длина IP-датаграммы в байтах (Total Length, 2 байта);

Identification – 16-битовое число, одинаковое для всех фрагментов одной датаграммы (2 байта);

Flags – флаги (DF – не фрагментировать, MF – еще фрагменты, 3 бита, один флаг зарезервирован);

UDP – User Datagram Protocol (протокол пользовательских датаграмм).

Fragment Offset – смещение фрагмента внутри датаграммы в 8 байтовых единицах (13 битов);

TTL – время жизни IP-датаграммы (Time To Live, значение в этом поле уменьшается на 1 при прохождении через очередной маршрутизатор, 1 байт);

Protocol – протокол верхнего уровня (например, 0x06 для TCP, 0x для UDP, 0x01 для ICMP, 1 байт);

Header Checksum – контрольная сумма заголовков IP-датаграммы (2 байта);

Source Address – IP-адрес источника (4 байта);

Destination Address – IP-адрес назначения (4 байта);

Options – опции (если есть);

Padding – байты выравнивания поля опций до 32-битового слова;

Data – данные верхнего уровня.

3.2. Протокол UDP (User Datagram Protocol) Протокол передачи пользовательских датаграмм UDP – протокол транспортного уровня по модели OSI/RM. Формат UDP-датаграммы представлен ниже.

• Source Port – порт источника (2 байта);

• Destination Port – порт назначения (2 байта);

• Length – полная длина UDP-пакета (2 байта);

• Checksum – контрольная сумма (2 байта);

• Data – данные, инкапсулированные в UDP-пакет.

3.3. Протокол TCP (Transmission Control Protocol) Протокол управления передачей TCP – протокол транспортного и сеансового уровней по модели OSI/RM. Формат TCP-сегмента представлен ниже.

• Source Port – порт источника (2 байта);

• Destination Port – порт назначения (2 байта);

• Sequence Number – номер последовательности (4 байта);

• Acknowledgement Number – номер подтверждения (4 байта), оба этих числа используются для контроля правильности приема переданных данных;

• Data Offset – длина TCP-заголовков в 32-битовых словах (4 бита);

• однобитовые TCP-флаги (U, A, P, R, S, F);

• Window – размер окна в байтах (2 байта);

• Checksum – контрольная сумма TCP-сегмента и псевдозаголовков • Urgent pointer – указатель срочности (2 байта);

• Option-kind, Option-length и Option-data – тип (1 байт), длина (1 байт) и данные опций TCP;

• Padding – поле заполнения до 32-битового слова;

• Data – данные верхнего уровня, инкапсулированные в TCP-сегмент.

TCP-флаги:

URG (urgent) – флаг срочности, указывает на использование поля Urgent Pointer (например, при нажатии Ctrl-C в сеансе telnet или при передаче файла в поле Urgent Pointer записывается смещение передаваемых в этом сегменте данных относительно номера последовательности);

ACK (acknowledgement) – флаг подтверждения, указывает на подтверждение приема данных и необходимость использования Acknowledgement Number;

PSH (push) – указатель немедленной передачи инкапсулированных данных приложению на стороне получателя (например, в сеансе telnet для отправки сегментов, содержащих отдельные буквы, при побайтовой отсылке на сервер);

RST (reset) – флаг сброса соединения;

SYN (synchronization) – флаг инициирования соединения, указывает на необходимость использования Sequence Number;

FIN (finish) – флаг запроса закрытия соединения.

3.4. Протокол ICMP (Internet Control Message Protocol) ICMP (протокол управляющих сообщений в сети Internet) инкапсулирован в IP-датаграмму (при этом поле Protocol в IP-заголовках содержит 0x01).

• Type – тип ICMP-сообщения (1 байт);

• Code – код сообщения (зависит от значения поля Type, 1 байт);

• Checksum – контрольная сумма;

• Data – данные.

3.5. Протоколы ARP и RARP (Address Resolution Protocol и Reversed ARP) Протоколы ARP (распознавания МАС-адреса по известному IP-адресу) и RARP (распознавания IP-адреса по известному МАС-адресу) связывают канальный и сетевой уровни в модели OSI/RM. Оба протокола носят широковещательный характер, поэтому используются только в локальных сетях (в пределах одного сегмента сетевой архитектуры канального уровня, что называется "до первого маршрутизатора").

Необходимо обратить внимание, что ARP и RARP организуют взаимосвязь не только для Ethernet – IP, но и для других сетевых архитектур и протоколов сетевого уровня; формат ARP и RARP пакетов представлен ниже.

Sender Protocol Address (bytes 3-4) • Hardware Type – тип сетевой архитектуры (канальный уровень, 0x0001 для 10 Mb Ethernet);

• Protocol Type – идентификатор протокола сетевого уровня ( • HW Address Length – длина адреса канального уровня (006 для MAC-адреса);

• Protocol Address Length – длина адреса сетевого уровня (004 для IP-адреса);

• Opcode – код операции (1 – ARP-запрос, 2 – ARP-ответ, 3 – RARPзапрос, 4 – RARP-ответ);

• Sender и Target HW Address и Protocol Address – адреса канального и сетевого уровней источника и приемника соответственно.

Часть полей может быть пустой. Так, при формировании ARP-запроса поле Target HW Address остается незаполненным. Станция, имеющая такую информацию, сформирует ARP-ответ, в котором укажет искомый адрес канального уровня.

3.6. Процесс отправки, перенаправления и получения датаграмм Процесс отправки, перенаправления и получения датаграммы сетевого уровня можно рассмотреть на примере приведенного рисунка.

На схеме слева и справа изображены два компьютера, у каждого есть интерфейс канального уровня (например, сетевой адаптер стандарта Ethernet) с уникальными адресами МАС1 и МАС4 соответственно.

Между ними находится маршрутизатор (устройство сетевого уровня по модели OSI/RM), в задачу которого входит перенаправление датаграмм с одного из физических интерфейсов (МАС2, МАС3) на другой.

Основанием для перенаправления является соответствие сетевого адреса назначения, считанного из заголовков сетевого уровня датаграммы, сети назначения, указанной в таблице маршрутизации. При этом компьютер 1 и левый физический интерфейс маршрутизатора имеют разные адреса сетевого уровня и входят в одну сеть net1, а компьютер и правый интерфейс маршрутизатора – в сеть net2.

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

Во время подготовки датаграммы отправителю становятся известны адреса источника net1.ip1 (свой) и получателя net2.ip2 на сетевом уровне (например, удаленный адрес сетевого уровня можно узнать, воспользовавшись службой DNS). Сформированная датаграмма записывается в поле данных кадра канального уровня. Свой адрес канального уровня МАС1 отправителю, понятно, известен. Драйвер сетевой платы записывает его в поле SA (Source Address). Проблема возникает с тем, что писать в поле DA (Destination Address) и куда отправлять кадр с данными. Ответ очевиден: на маршрутизатор по умолчанию, коим является интерфейс сетевого уровня с адресом net1.ip2. МАС-адрес этого сетевого интерфейса можно узнать, воспользовавшись службой ARP (Address Resolution Protocol). Компьютер формирует широковещательный на канальном уровне ARP-запрос (только в пределах левого сегмента, маршрутизатор не пропустит сквозь себя широковещательные кадры канального уровня) для того, чтобы по известному адресу сетевого уровня (net1.ip2) узнать его МАС-адрес.

После того, как SA и DA будут известны, кадр с инкапсулированной датаграммой отправляется маршрутизатору.

Маршрутизатор получает кадр с левого (на рисунке) интерфейса, вскрывает его и находит датаграмму сетевого уровня, в которой указан адрес назначения net2.ip2. По своей таблице маршрутизации, пользуясь маской сетевого адреса, он определяет, что датаграмму необходимо переслать на интерфейс с МАС-адресом МАС3. Поскольку компьютер 2 включен логически в сеть (на сетевом уровне модели OSI/RM), непосредственно подсоединенной к маршрутизатору, последний сформирует ARP-запрос на адрес назначения net2.ip2. В ответ ему придет информация о МАС4. Он сформирует новый кадр канального уровня, вложив в него исходную неизмененную датаграмму.

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

3.7. Установление и разрыв TCP-соединения Для того чтобы установить TCP-соединение, необходимо проделать следующие действия.

1. Сторона-инициатор соединения (клиент) отправляет SYN-сегмент (выставленный бит SYN в поле флагов заголовков TCP), указывая номер порта сервера, к которому клиент хочет подсоединиться, и исходный номер последовательности клиента (поле Sequence Number в заголовках TCP).

2. Сервер отвечает сегментом SYN, содержащим свой исходный номер последовательности сервера вместе с выставленным флагом SYN. Также он выставляет флаг ACK и заполняет поле "номер подтверждения" (Acknowledgement number), вставляя в него полученный от клиента номер последовательности + 1.

3. Клиент должен подтвердить приход SYN-сегмента от сервера с использованием ACK-флага и нового значения в поле подтверждения (полученный от сервера номер последовательности +1).

Передачи таких трех сегментов достаточно для установления соединения (часто этот процесс называется трехразовым рукопожатием, threeway handshaking). После этого между сторонами возможен двусторонний обмен данными по установившемуся соединению.

При одностороннем закрытии соединения сторона-инициатор закрытия должна послать по установленному соединению FIN-сегмент (выставленный флаг FIN), а также получить ACK-ответ от удаленной стороны с уведомлением о получении FIN-сегмента.

После этого соединение с возможностью двустороннего обмена данными переходит в однонаправленное состояние (одна сторона закрыла соединение, вторая, активная, поддерживает его открытым).

Для того чтобы полностью закрыть соединение, активная сторона должна сформировать FIN-сегмент и получить на него подтверждение.

Таким образом, при установлении соединения двум сторонам необходимо послать и принять 3 сегмента, при его разрыве – 4.

3.8. Hyper Text Transfer Protocol (HTTP) Под аббревиатурой HTTP (протокол доставки гипертекстовых документов) понимается протокол, обеспечивающий функционирование Сети и являющийся его базовой транспортной подсистемой. На данный момент все средства просмотра страниц в Internet должны соответствовать спецификации HTTP/1.1, представленной в июне 1999 г. (RFC 2616).

Любой стандарт, связанный с Internet, публикуется в виде RFCдокументов (Request for Comments, запрос на рецензию и комментарии).

Основным разработчиком алгоритмов и процедурных правил клиентсерверного Web-взаимодействия следует признать Тима Бернерс-Ли (T. Berners-Lee), участвовавшего в создании всех версий протокола HTTP, начиная с HTTP/0.9 (1991 г.), HTTP/1.0 (окончательно утвержденного в RFC 1945 в мае 1996 г.) и заканчивая HTTP/1.1 (RFC и RFC 2616). Все упомянутые RFC-документы можно найти по адресу:

http://www.ietf.org/ ("штаб-квартира" WWW).

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

Чаще всего страничка начнет появляться на экране монитора только после того, как полностью загрузится в память компьютера (это связано с особенностями отображения браузерами содержимого веб-страниц).

Протокол HTTP описывает порядок действий клиентского программного обеспечения в момент запроса им гипертекстовых документов и другой информации у серверов, а также отправку ответов этими серверами. Ранние версии протокола позволяли строить запрос в упрощенной форме, тогда как HTTP/1.1 требует, чтобы были явно указаны несколько полей внутри него, например обязательное поле host.

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

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

Вот так, например, выглядит HTTP-запрос, посылаемый браузером открытым текстом по предварительно установленному TCP-каналу:

GET /index.shtml HTTP/1. Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT;

DigExt) Host: thermo.karelia.ru Connection: Keep-Alive Cookie: voted=21; uid= В нем запрашивается index.shtml – главная страница сервера thermo.karelia.ru. При этом указываются:

• версия HTTP;

• возможность gzip- и deflate-компрессии;

• сигнатура браузера, сформировавшего запрос (Mozilla/4. (compatible; MSIE 5.0; Windows NT; DigExt));

• имя Web-сервера (thermo.karelia.ru);

• правило поддержания общения между браузером и Web-сервером (постоянное соединение);

• полученные ранее этим пользователем файлы персонализации (voted со значением "21" и uid со значением "45639").

Web-сервер (thermo.karelia.ru) обязан как-то отреагировать на такую информацию. Он либо пришлет требуемый документ, либо сформирует пакет, содержащий код ошибки. Если этого не произойдет, то через некоторое время клиентская сторона закроет соединение и отобразит пользователю сообщение о недоступности хоста.

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

GET / HTTP/1. и нажать два раза Enter () В ответ сервер, скорее всего, выдаст сообщение об ошибке.

3.9. Simple Mail Transfer Protocol (SMTP) В качестве транспортного средства доставки сообщений в Internet выступает SMTP (simple mail transfer protocol, простой протокол передачи почты), который был стандартизован в виде RFC 821 (Request For Comments).

Упрощенно схема взаимодействия представлена на следующем рисунке (объемными стрелками показано направление движения почтовых сообщений).

клиент Со стороны пользователя обычно одна и та же программа выступает в роли и POP3-клиента и SMTP-клиента отправителя. Наиболее распространенными на данный момент являются MS Outlook, The Bat, Netscape Messenger, Eudora, Pegasus mail, Mutt, Pine и др. При нажатии в них на кнопочку "отправить" происходит формирование очереди сообщений (если посылается не одно письмо) и установление двустороннего сеанса общения с SMTP-сервером провайдера. На схеме представлено так, что у пользователя есть клиентское ПО, а у провайдера – серверная часть приложения. На самом деле это немного не так.

Протокол SMTP делает возможным смену сторон даже в ходе одного сеанса. Условно принято считать клиентом ту сторону, которая начинает взаимодействие и хочет отослать почту, а сервером – ту, что принимает запросы. После того, как клиент посылает серверу несколько служебных команд и получает положительные ответы на них, он отправляет SMTP-серверу собственно тело сообщения. SMTP-сервер получает сообщение, вносит в него дополнительные заголовки, указывающие на то, что он обработал данное послание, устанавливает связь со следующим SMTP-сервером по пути следования письма. Общение между любыми SMTP-серверами происходит по той же схеме. Инициирует переговоры клиент, сервер на них отвечает, а затем получает корреспонденцию и "ставит штампик" в теле письма (в его заголовочной части). Все это очень напоминает обычную бумажную почту, где работу по сортировке и отправке почты выполняют люди.

Если на каком-нибудь этапе передачи SMTP-клиент обнаружит невозможность подключиться к следующему серверу (например, компьютер отправили на профилактику или аппаратура связи вышла из строя), он будет пытаться отправить сообщение через некоторое время – 1 час, 4 часа, день и т. д., до 4 суток в общем случае. Причем временные отрезки между попытками, как правило, зависят от настроек программы-пересыльщика почты. Одновременно такой сервер должен уведомить отправителя сообщения о невозможности доставить почту, послав ему стандартное письмо "Failed delivery" (доставка невозможна) и рассказав о графике дальнейших попыток по продвижению исходного сообщения. Если канал связи не восстановится за указанный большой промежуток времени (например, 4 дня), посланная информация будет считаться утерянной.

Как только почта достигнет конечного пункта (SMTP-сервера адресата сообщения), она будет сложена в почтовый ящик абонента, который всегда сможет в удобное для него время изъять ее по протоколам POP или IMAP в зависимости от того, какой из них поддерживается провайдером.

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

Получить эту информацию можно в "Свойствах письма", кликнув правой кнопкой мыши на самом письме в MS Outlook, нажав Ctrl + Shift + H в The Bat или совершив нечто подобное в других почтовых клиентах.

Received: from mx10.mail.ru (mx10.mail.ru [194.67.57.20]) by dfe3300.karelia.ru (8.9.0/8.9.0) with ESMTP id JAA Thu, 18 Apr 2002 09:19:13 +0400 (????) Received: from f5.int ([10.0.0.57] helo=f5.mail.ru) by mx10.mail.ru with esmtp (Exim MX.A) id 16y46p-0002ox- for [email protected]; Thu, 18 Apr 2002 09:05: + Received: from mail by f5.mail.ru with local (Exim FE.5) id 16y46o-000CfY- for [email protected]; Thu, 18 Apr 2002 09:05: + Received: from [213.59.200.7] by win.mail.ru with HTTP;

Thu, 18 Apr 2002 09:05:26 + From: "Testing" To: [email protected] Subject: For testing purposes only Mime-Version: 1. X-Mailer: mPOP Web-Mail 2. X-Originating-IP: [213.59.200.7] Date: Thu, 18 Apr 2002 09:05:26 + Reply-To: "Testing" Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id:

X-UIDL: 74fb663e2be8352b3a0b88ca08030c1e Тестовое сообщение.

Данный пример показывает четкую структуру письма. Тело почтового сообщения состоит из заголовочной части и текста (в данном случае слова "Тестовое сообщение") плюс вложения. До слова "From:" информация заносится промежуточными SMTP-серверами, каждый из которых добавляет свои данные в самое начало, тем самым постоянно увеличивая количество передаваемых далее байтов. Средняя заголовочная часть (начиная с "From:" и заканчивая "X-UIDL") почти полностью формируется почтовым агентом отправителя. Исключение составляет, например, поле "Message-Id:", которое было сформировано первым по пути следования SMTP-сервером – f5.mail.ru. Некоторые поля являются стандартизованными и желательными для употребления, например From, To, Subject, Reply-To… А некоторые являются дополнительными по отношению к описанным в стандарте текстовых сообщений в среде Internet (RFC 822) и необязательными. Такие поля начинаются с "X-" и служат, например, для идентификации самого почтового клиента.

[213.59.200.7] by win.mail.ru with HTTP; говорят о том, что письмо было отослано с помощью браузера с использованием протокола HTTP (hypertext transfer protocol). На пути от win.mail.ru к dfe3300.karelia.ru встретилось два транзитных SMTP-сервера: f5.mail.ru и mx10.mail.ru.

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

Составляя почтовое сообщение, пользователь должен заполнить поле "To", куда заносится адрес назначения (запись "From" подставится в заголовки письма автоматически). В Internet существуют правила хорошего тона, которые рекомендуют также указывать тему сообщения (поле "Subject").

Если необходимо разослать почту по нескольким адресам "в открытую", необходимо воспользоваться полем "CC" (carbon copy) или дописать их через запятую в поле "To". Слова "в открытую" означают, что человек, получивший такое письмо и просмотревший его заголовки, может определить, кому еще оно было послано в качестве копии. Если вдруг возникнет необходимость доставить один и тот же текст нескольким людям, но так, чтобы каждый из них не знал, кому еще адресовано это письмо, придется воспользоваться полем "BCC" (blind carbon copy – слепая копия). В этом случае все адресаты, указанные в поле "BCC" через запятую, получат сообщение, как если бы оно предназначалось только им. Эту работу по "размножению" почты выполняют незаметно для глаз пользователя почтовый клиент пользователя и первый по пути следования SMTP-агент. Они анализируют заголовочную часть письма, и если обнаруживают заполненные поля "CC", "BCC", то действуют в соответствии со своими алгоритмами обработки почтовых сообщений.

Теперь более подробно рассмотрим клиент-серверное взаимодействие по протоколу SMTP. Программа пользователя, выбрав для связи соответствующий почтовый сервер, устанавливает с ним контакт на транспортном и сеансовом уровнях эталонной модели взаимодействия открытых систем OSI/RM (в терминах TCP/IP (transmission control protocol / internet protocol) это – TCP-уровень). Взаимодействие на более низких уровнях (канальном, сетевом) происходит прозрачно для обеих сторон. Протокол SMTP – протокол прикладного уровня и базируется поверх TCP. В его рамках не оговариваются ни размер сегментов данных, ни правила квитирования, ни отслеживание ошибок, возникающих при передаче информации.

Итак, по уже установленному соединению клиентское ПО передает команды SMTP-серверу, ожидая тут же получить ответы. В арсенал SMTP-клиента, равно как и сервера, входит около 10 команд, но воспользовавшись только пятью из них, уже можно легально послать почтовое сообщение, это HELO, MAIL, RCPT, DATA, QUIT. Их использование подразумевается именно в такой последовательности.

HELO (усеченная форма от hello, приветствие) предназначена для идентификации отправителя, MAIL указывает адрес отправителя, RCPT (от англ. recipient – принимающий) – адрес назначения. После команды DATA и ответа на нее клиент посылает серверу тело сообщения, которое должно заканчиваться строкой, содержащей лишь одну точку.

Выражаясь языком программистов, сервер узнает о прекращении посылки сообщения, встретив следующий набор символов "\r\n.\r\n" или "." (CRLF – так называемый возврат каретки с переходом на новую строчку, обычно такое получается при нажатии клавиши Enter во многих редакторах).

Для демонстрации вышесказанного можно воспользоваться программой telnet (ssh). Если выполнить в командной строке Unix-подобных операционных систем следующую команду:

telnet name_of_mail_server.ru или, нажав Пуск / Выполнить, ввести telnet name_of_mail_server.ru (для пользователей Windows), то установится TCP-соединение с 25-м портом указанного сервера (естественно, вместо слов name_of_mail_server следует набрать имя почтового сервера). Этот TCPпорт служит для обеспечения взаимодействия по протоколу SMTP (например, 80-й TCP-порт обычно закреплен за веб-сервером, принимающим и отсылающим информацию по HTTP-протоколу). Если не будет видно набираемых символов в сеансе telnet, попробуйте изменить параметры вывода на экран (Параметры / Отображение ввода).

В следующем примере приведен telnet-сеанс общения с несуществующим public_mail_server.ru, абонентом которого является некто с именем test_only, ему и предназначается почтовое сообщение.

220 ESMTP PUBLIC_MAIL_SERVER.RU Thu, 25 Apr 2002 14:15:50 + helo my_comp.ru 250 public_mail_server.ru Hello as1-52.dialup.onego.ru [195.161.137.53] mail from: me@my_comp.ru 250 is syntactically correct rcpt to: test_only@public_mail_server.ru 250 verified data 354 Enter message, ending with "." on a line by itself body of the test message from me@my_comp.ru to test_only@public_mail_server.ru 250 OK id=170gLG-000FEI- quit Непосредственно после установления соединения сервер выдает строчку с кодом ответа 220. В ответ на нее клиент может инициировать сеанс связи по протоколу SMTP, послав команду HELO (можно маленькими буквами) и указав у нее в аргументах имя своего компьютера. Сюда можно писать все, что вздумается, потому что по принятии команды HELO сервер обязан сделать запрос в DNS и, если это возможно, по IP-адресу определить доменное имя компьютера клиента. (IPадрес уже известен на момент установления соединения по протоколу TCP.) Именно поэтому в строчке "250 public_…" присутствует имя as1dialup.onego.ru, соответствующее одному из IP-адресов модемного пула провайдера, а не my_comp.ru, как было указано на стадии приветствия.

Далее в команде "MAIL FROM:" клиент сообщает обратный адрес отправителя, который проверяется обычно только на корректность (это зависит от настроек SMTP-сервера). После слов "RCPT TO:" следует набрать адрес электронной почты абонента на данном сервере. Ответ "250 verified" свидетельствует о существовании логина с именем test_only. Клиент отсылает команду DATA и ждет приглашения начать пересылку тела письма (код 354).

Сообщение может быть достаточно длинным, но обязательно должно заканчиваться строкой, в которой есть одна-единственная точка. Это служит сигналом SMTP-серверу о том, что тело письма закончилось. Он присваивает этому письму определенный идентификатор и ждет команды QUIT, после чего сеанс считается завершенным.

Как будут действовать пользовательское и серверное ПО в случае необходимости "массовой" рассылки? Если клиент посылает сообщение, у которого в заголовочной части в поле CC указаны несколько e-mail адресов, первый по пути следования SMTP-сервер должен будет в общем случае установить сеанс продвижения почты с каждым из серверов данного списка и отослать точную копию письма каждому. В случае использования поля BCC клиент, формирующий сообщение, уничтожит запись BCC в теле сообщения и несколько раз (по количеству адресатов) отошлет первому SMTP-серверу команду "RCPT TO:" каждый раз с новым адресом в качестве аргумента. Таким образом, сервер получит указание разослать почту по многим адресатам. Причем в этом случае получатели писем ничего не будут знать друг о друге, т. к. рассылка осуществляется посредством команд SMTP-протокола (без использования информации в заголовочной части письма).

Что будет, если попробовать соединиться с каким-нибудь мейлсервером и через него передать почту, предназначенную другому?

(В предыдущем примере адресатом был test_only@public_mail_server.ru, поэтому устанавливалось соединение именно с public_mail_server.ru.) Чаще всего на ввод команды "RCPT TO:" в ответ вы получите "relaying denied" (пересылка запрещена). Сделано это с целью борьбы с неконтролируемыми и несанкционированными почтовыми рассылками.

В принципе, эта ситуация очень похожа на простое использование транзитных серверов исходящих сообщений. Вы указываете один компьютер в качестве следующего пункта пересылки, а сообщение предназначается другому. Поэтому при настройке почтовых серверов администраторами вводятся ограничения на круг IP-адресов и доменных имен, для которых работает пересылка. Если этого не сделать, их сервер сразу же попадет в черный список, используемый при фильтрации такими гигантами, как hotmail.com, yahoo.com, mail.com и почта от абонентов "проштрафившихся" адресов будет блокироваться.

Протокол SMTP существует достаточно давно – с 1982 года (RFC 821);

впоследствии в него были внесены некоторые дополнения, выразившиеся в появлении ESMTP (Extended SMTP, RFC 1425; 1993 год). Если клиент поддерживает ESMTP, его первая команда будет EHLO (Extended Hello), а не HELO. Сервер в ответ на нее должен выдать список всех дополнительных команд, которые он умеет обрабатывать.

Клиент может ими воспользоваться, а может проигнорировать, послав сообщение продемонстрированным выше способом.

Контрольные вопросы к главе 1. Укажите положение в стеке OSI/RM следующих протоколов: IP, TCP, UDP, ARP/RARP, ICMP.

2. Что такое датаграмма?

3. На каких уровнях по модели OSI/RM для стека TCP/IP может применяться (обычно применяется) контроль качества переданной информации?

4. Как узнать длину поля "данные" в TCP-сегменте?

5. Что такое фрагментация IP-датаграмм? Какие механизмы существуют для поддержки фрагментации?

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

7. Опишите схему действий устройств, изображенных на рисунке в разделе 3.6, при отправке, перенаправлении и получении датаграмм.

8. Опишите схему действий устройств, изображенных на рисунке в разделе 3.6, при отправке, перенаправлении и получении датаграмм в случае, если добавлен еще один маршрутизатор между изображенным маршрутизатором и компьютером 2.

9. Опишите схему действий устройств, изображенных на рисунке в разделе 3.6, при установлении TCP-соединения между компьютерами 1 и 2 (в пояснениях следует затронуть транспортно-сеансовый, сетевой и канальный уровни).

10. Каким образом происходит подтверждение приема данных при общении по протоколу TCP?

Глава 4.

Средства и утилиты сетевого тестирования 4.1. ping Программа ping предназначена для проверки доступности удаленного хоста или сетевой службы и часто используется в качестве самой первичной диагностики неисправностей (отсутствия связи) в глобальных и локальных сетях. Программа посылает ICMP (Internet Control Message Protocol) эхо-запрос на хост и ожидает возврата ICMP эхоотклика. Время между посылкой ICMP-запроса и получением ответа может свидетельствовать о пропускной способности канала связи.

Программа ping реализована во всех сетевых операционных системах.

С ее помощью можно тестировать сеть IP-пакетами любой длины от минимальной (64 байта) до максимально допустимой (~64 килобайтов) (длина пакета задается опциями в командной строке).

Следует также помнить, что во многих случая ping-пакеты могут блокироваться промежуточными маршрутизаторами, а хосты – пункты назначения могут быть сконфигурированы на запрет приема / отправки ICMP-сообщений.

Результат выполнения команды ping приведен ниже.

[alexmou@plasma alexmou]$ ping -c 3 localhost PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.

64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl= time=134 usec 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl= time=155 usec 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl= time=106 usec --- localhost.localdomain ping statistics --packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.106/0.131/0.155/0.024 ms В последней строке указывается время обращения ICMP-пакетов (минимальное / среднее / максимальное для нескольких пакетов и отклонение от среднего). Это время складывается из двойного времени прохождения по сети и времени обработки пакета на удаленной стороне и промежуточных маршрутизаторах (usec обозначает микросекунды).

Определить пропускную способность сети можно, если построить график зависимости времени обращения от длины ICMP-сообщения.

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

Внимание! При посылке ICMP-пакета длиной более 1.5 кбайта в сетях Ethernet он будет дробиться на более мелкие фрагменты.

4.2. traceroute (tracert) Программа traceroute позволяет посмотреть маршрут, по которому двигаются IP-датаграммы от одного хоста к другому. Обычно две последовательные датаграммы, отправленные от одного и того же источника к одному и тому же пункту назначения, проходят по одному и тому же маршруту, однако гарантировать это невозможно. С помощью traceroute можно также воспользоваться IP-опцией маршрутизации от источника.

traceroute, как и ping, использует ICMP и поле TTL в IP-заголовке.

Поле TTL (время жизни) – это 8-битовое поле, в которое отправитель записывает конкретное значение (зависит от операционной системы).

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

На хост назначения отправляется IP(UDP)-датаграмма 1 с TTL, установленным в единицу. Первый маршрутизатор, который должен обработать датаграмму 1, уничтожает ее (так как TTL равно 1) и отправляет ICMP-сообщение 2 об истечении времени (time exceeded).

ICMP-сообщение инкапсулировано в IP-датаграмму 2, следовательно, отправитель изначальной UDP-датаграммы 1 всегда знает IP-адрес отправителя 2. Таким образом определяется первый маршрутизатор по пути следования.

Затем traceroute отправляет датаграмму с TTL, равным 2, что позволяет получить IP-адрес второго маршрутизатора. Это продолжается до тех пор, пока датаграмма не достигнет хоста назначения. Однако если датаграмма прибыла именно на хост назначения, он не уничтожит ее и не сгенерирует ICMP-сообщение об истечении времени, так как датаграмма достигла своего конечного пункта назначения.

В UDP-датаграммах (User Datagram Protocol), которые посылает traceroute, устанавливается, например, неиспользуемый номер UDPпорта (больше чем 30000), что делает невозможным обработку этой датаграммы каким-либо приложением. Поэтому, когда прибывает подобная датаграмма, UDP-модуль хоста назначения генерирует ICMPсообщение другого типа: "порт недоступен" (port unreachable).

Результат выполнения команды может содержать строки со звездочками. Они говорят о том, что пакет либо утерян (отброшен вследствие загруженности маршрутизаторов), либо маршрутизатор не имеет права отсылать ICMP-сообщение "time exceeded" (в случае * * *) 12 * bubble-gum.net (211.10.11.170) 187.258 ms 163.876 ms 14 www.star-systems.com (64.78.63.91) 223.622 ms * 260.829 ms 4.3. netstat Программа netstat показывает текущее состояние различных структур данных, связанных с сетевым взаимодействием. В зависимости от выбранных опций можно узнать информацию о таблице маршрутизации (-r), текущих TCP-соединениях (-a), статистическую информацию попротокольно (-s).

Для сокетов TCP (просмотр с опцией -a) допустимы следующие состояния:

CLOSED

LISTEN

SYN RECEIVED

ESTABLISHED

В Unix-подобных операционных системах эта утилита находится в каталоге /usr/sbin/ и обычно запускается с правами суперпользователя.

Наиболее часто используемый вызов утилиты tcpdump выглядит следующим образом:

tcpdump [-c count] [-s snaplen] [-w file] [expression] При этом в файл file будут записаны несколько (count) первых отловленных кадров, удовлетворяющих маске expression (например, not port 25). Причем если длина кадра была более snaplen, то он будет усечен до этой величины.

Начало созданного файла будет содержать заголовки библиотеки pcap (24 байта), а далее последовательно будут расположены кадры, каждому из которых предшествует временная метка (8 байт), полная длина кадра (4 байта) и длина захваченной части кадра (4 байта). Таким образом, начало первого Ethernet кадра (MAC-адрес назначения) будет находиться по смещению 40 относительно начала файла. Формат заголовка всего файла и заголовка кадра можно посмотреть в заголовочном файле pcap.h.

Анализируя значение 13-го и 14-го байтов внутри каждого кадра, можно узнать, например, каков был протокол верхнего уровня по отношению к канальному ( 0 ) { // родительский процесс // здесь, например, можно проверить // что дочерний процесс успешно проинициализировался exit(0); // родительский процесс завершается } else { // pid == 0, дочерний процесс close(STDIN_FILENO);

close(STDOUT_FILENO);

close(STDERR_FILENO);

// после закрытия стандартных устройств ввода-вывода // и создания сессии дочерний процесс является "демоном" // здесь можно запустить на исполнение // какую-то другую программу Пояснения к примеру "демонизации". В ОС семейства Unix процессы могут объединяться в группы. Это сделано для того, чтобы можно было послать сигнал не отдельному процессу, а группе. Все процессы, входящие в группу, имеют одинаковый идентификатор группы. У группы процессов имеется лидер группы. Это такой процесс, идентификатор группы которого совпадает с идентификатором этого процесса. В свою очередь группы процессов могут объединяться в так называемые "сеансы" или "сессии". Аналогично группам, в сеанс входят все процессы, у которых идентификатор сеанса одинаков. Один из процессов, входящих в сеанс, является его лидером. Сеанс может иметь управляющий терминал, что используется для организации интерактивного взаимодействия с пользователем. Создание сеанса (сессии) производится, как уже упоминалось, с помощью системного вызова setsid(). Создать сессию не может процесс, являющийся лидером группы.

Именно по этой причине в приведенном примере перед "демонизацией" используется fork() - когда родительский процесс завершается, дочерний становится потомком процесса init, что гарантирует то, что этот потомок после этого не является лидером группы. После вызова setsid(), то есть после создания сеанса, данный процесс становится лидером этого нового сеанса и лидером группы.

Замечание по поводу закрытия стандартных потоков ввода-вывода.

Иногда рекомендуют не закрывать их, а перенаправить все эти потоки в псевдоустройство /dev/null. Это делается из опасения, что какаянибудь функция из используемых программой библиотек (или же сама программа, вследствие неаккуратности программиста) может выводить данные в стандартный поток вывода или в стандартный поток диагностического вывода. Если речь идет о серверах, то потоки с дескрипторами 1 и 2 могут соответствовать сокетам, поэтому запись в эти потоки "случайной" информации будет нарушением протокола взаимодействия.

Если же мы перенаправим эти потоки, то этим самым мы гарантируем, что потоки с дескрипторами 0, 1, 2 остаются открытыми и поэтому никакой сокет не будет иметь такой дескриптор.

В заключение этого раздела отметим, что в стандартной библиотеке имеется функция daemon(), которая выполняет "демонизацию", при этом имеется возможность указать, что нужно сделать с дескрипторами 0, 1 и 2 - просто закрыть их или же перенаправить в /dev/null.

7.2. Использование select() и poll() В этом разделе рассматривается вопрос о том, как организовать работу с более чем одним дескриптором потока ввода-вывода при помощи вызовов select() и poll(). Эти системные вызовы используются для синхронного мультиплексирования ввода-вывода. Рассмотрим сначала вызов select().

Для удобства его использования имеется ряд вспомогательных макроопределений (FD_CLR, FD_ISSET, FD_SET, FD_ZERO), которые применяются для манипуляций так называемыми наборами дескрипторов. Набор дескрипторов – это битовый массив, каждый бит которого определяет, входит ли данный дескриптор в набор или не входит. Набор дескрипторов представлен типом fd_set; иными словами, в программе набор дескрипторов – это переменная обозначенного типа.

Первые три макроопределения (FD_CLR, FD_ISSET, FD_SET) имеют два параметра, дескриптор и указатель на набор дескрипторов. Они производят следующие действия: первый исключает данный дескриптор из данного набора, второй проверяет, входит ли данный дескриптор в данный набор и, наконец, третий включает данный дескриптор в данный набор. Последнее макроопределение (FD_ZERO) имеет один параметр – указатель на набор дескрипторов; оно очищает данный набор, то есть удаляет из него все дескрипторы.

Прототип вызова select() имеет следующий вид:

int select( Вызов select() имеет пять параметров; второй, третий и четвертый – это наборы дескрипторов (точнее, указатели на них), за которыми select() будет наблюдать. Дескрипторы из первого набора отслеживаются на предмет наличия данных для чтения, из второго – на предмет возможности немедленной записи и из третьего – на предмет возникновения исключительных ситуаций. Первый параметр – целое число, которое должно быть на единицу больше максимального (по значению) файлового дескриптора в этих трех наборах, а пятый – это указатель на структуру, содержащую максимальное время ожидания изменения состояния дескрипторов в наборах (так называемый "тайм-аут"). Если это время равно 0, то select() возвращается немедленно; если же сам указатель равен NULL, то тайм-аут равен бесконечности. Вызов возвращает число дескрипторов, готовых к операциям ввода-вывода, то есть суммарное число дескрипторов, оставшихся в трех наборах.

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

Для выявления того, какие дескрипторы остались в наборе, а значит, готовы к той или иной операции, используйте FD_ISSET. Не забывайте отслеживать максимальный по величине дескриптор: полагаться на то, что самый "большой" дескриптор – это тот, который был возвращен самым последним вызовом open() или socket(), не следует, потому что некоторые из созданных ранее дескрипторов уже могли быть закрыты и их номера могли быть повторно использованы для вновь создаваемых дескрипторов.

Пример использования select() имеется в страничке руководства программиста, посвященной этому системному вызову (man select), а также в разделе 8.4, в котором приведен пример программы-сервера.

Остановимся еще на том, какой смысл имеет то обстоятельство, что какой-либо дескриптор остался в наборе после возврата select().

Первый набор – дескрипторы, проверяемые на наличие данных для чтения. Для терминалов и обычных сокетов наличие дескриптора в этом наборе после возврата select() означает, собственно, то, что имеются данные для чтения (вызов read() или recv() не заблокируется).

В отличие от них, для сокета, который находится в режиме прослушивания (см. далее), готовность дескриптора к чтению означает, что была попытка установления соединения (вызов accept() не заблокируется). Второй набор – дескрипторы, проверяемые на возможность записи данных без блокировки. Отметим, что для сокетов это можно использовать для определения того, завершился ли вызов connect() или нет.

Перейдем теперь к рассмотрению вызова poll(). Как уже говорилось, он предназначен для достижения тех же целей, что и вызов select().

Отличие состоит в том, что информация о том, за какими дескрипторами надо следить и какие из дескрипторов готовы к записи-чтению, организована иным способом. Вызов имеет три параметра: первый представляет собой массив некоторых структур, второй – длина массива, то есть количество этих структур (беззнаковое целое), третий – тайм-аут в миллисекундах (знаковое целое). Знаковое потому, что любое отрицательное значение используется для указания бесконечного тайм-аута. При успешном завершении вызов возвращает количество дескрипторов, готовых к операциям ввода-вывода или имеющих какуюто исключительную ситуацию (ошибку): 0 – если произошел тайм-аут, а при ошибке, как обычно, константу –1 с установлением соответствующего значения переменной errno.

Элементами массива (первого параметра вызова) являются структуры следующего вида:

struct pollfd { Первый элемент структуры – собственно сам файловый дескриптор, второй – битовая маска событий, которые подлежат отслеживанию для этого дескриптора, третий – какие события реально произошли (тоже битовая маска). Второй элемент является входным параметром, а третий – выходным. В качестве событий для отслеживания можно указывать POLLIN (есть данные для чтения), POLLPRI (есть срочные данные для чтения), POLLOUT (запись не будет заблокирована); в качестве выходных событий могут встретиться три упомянутые (из числа тех, которые были запрошены, естественно), а также дополнительно POLLERR (ошибка), POLLHUP (связь разорвана), POLLINVAL (неправильный запрос, открытого файла с таким дескриптором нет). Запрос на отслеживание нескольких типов событий формируется из упомянутых констант посредством операции побитового ИЛИ. Например, POLLIN | POLLPRI – будем отслеживать, когда появятся данные для чтения или срочные данные для чтения.

Далее приводится пример использования вызова poll().

#include #include #include struct pollfd stdinfd = {0,POLLIN,0};

одна структура struct pollfd;

первое поле структуры - НУЛЬ, значит, отслеживаем дескриптор НУЛЬ (стандартное устройсто ввода), второе поле структуры означает, что будем отслеживать события, состоящие в том, что имеются данные для чтения;

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

int poll_ret;

char buf[1024];

int timeout = 7000; /* 7s */ int delta = 1000;

int main(void) poll_ret = poll(&stdinfd, 1, timeout);

printf("TIMED OUT, nuthin entered, bye :-P\n");

Программа работает с одним дескриптором (0, стандартный ввод).

Просит ввести что-нибудь; если в течение заданного тайм-аута ничего не вводилось, завершается. Тайм-аут все время уменьшается. Для терминала наличие данных для чтения означает, что была нажата клавиша Enter. Программа не проверяет, какое именно событие произошло (не анализирует поле stdinfd[0].revents).

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

Процесс может отреагировать на сигнал тремя "способами", а именно:

он может отреагировать стандартно (вызывается стандартный обработчик), может проигнорировать сигнал (никакой обработчик не вызывается) и, наконец, он может реагировать произвольным образом (вызывается нестандартный обработчик, то есть обработчик, определенный программистом, разрабатывающим программу). Однако не для всех сигналов у процессов имеется такая свобода выбора. Для некоторых сигналов реакция фиксирована (SIGKILL, SIGSTOP, SIGCONT). Такие сигналы нельзя перехватывать (задавать собственный обработчик для них) и их также нельзя игнорировать. Кроме того, есть сигналы, игнорирование которых возможно, но не рекомендуется, ибо приводит к неопределенному поведению (например, SIGSEGV, SIGFPE, SIGILL).

Рассмотрим примитивы работы с сигналами, определенные стандартом POSIX. Процесс может определить реакцию на сигнал, может послать сигнал какому-либо процессу (в частности, самому себе), может ждать прихода сигнала, а может блокировать сигналы и деблокировать их.

Для определения реакции на сигнал (установки обработчика) используется системный вызов sigaction(). Напомним, что речь идет именно о стандарте POSIX; в стандарте ANSI C для этих целей используется вызов signal(), который мы рассматривать не будем.

Вызов sigaction() имеет 3 параметра: первый задает номер сигнала, на который устанавливается реакция, второй задает, собственно, эту реакцию в виде указателя на некоторую структуру, третий параметр (указатель такого же типа) используется для возвращения информации о старом обработчике. Сигнал, на который определяется реакция, может быть любым допустимым в данной системе сигналом, кроме SIGKILL, SIGSTOP и SIGCONT. Структура, в которой содержится информация об обработчике сигнала, содержит 5 полей:

struct sigaction { void (*sa_handler)(int);

void (*sa_sigaction)(int, siginfo_t *, void *);

void (*sa_restorer)(void);

Последний элемент считается устаревшим, использовать его не следует.

Первый элемент – указатель на функцию-обработчик сигнала; он может также иметь значения SIG_DFL (установить на данный сигнал реакцию по умолчанию) и SIG_IGN (игнорировать данный сигнал). Третий элемент задает набор сигналов, которые будут блокированы во время работы обработчика. Блокирован будет (по умолчанию) также сигнал, который обрабатывается. Четвертый элемент – набор флагов, модифицирующих поведение подсистем ОС и libc, ответственных за управление сигналами. Он формируется посредством операции побитового "ИЛИ" из следующих возможных флагов.

• Флаг SA_NOCLDSTOP означает, что не надо посылать сигнал SIGCHLD, когда процесс-потомок останавливается.

• Флаг SA_ONESHOT (SA_RESETHAND) означает, что после того, как обработчик сигнала один раз проделает свою работу, в качестве реакции на данный исгнал устанавливается реакция «по умолчанию»; интыми словами, обработчик, определенный пользователем, будет вызван только один раз, в дальнейшем будет вызываться обработчик по умолчанию.

• Флаг SA_RESTART означает, что если во время исполнения системных вызовов приходит сигнал и его обработчик нормально возвращается, то вызов производится повторно; в случае, если этот флаг не установлен, прерванный сигналом системный вызов завершается с ошибкой (errno при этом принимает значение EINTR).

• Флаг SA_NOMASK означает, что сигнал не будет блокироваться во время работы его обработчика.

• Флаг SA_SIGINFO говорит о том, что обработчик сигнала будет принимать не один параметр, а три.

Важно отметить, что если флаг SA_SIGINFO установлен, то в структуре struct sigaction перед вызовом sigaction() необходимо вместо элемента sa_handler заполнять элемент sa_sigaction. В этом случае обработчику сигнала будет передан указатель на некоторую структуру. Эта структура содержит массу информации, в частности номер сигнала, значение errno, PID процесса, который послал сигнал, номер файлового дескриптора (для случая сигнала SIGIO).

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

Для посылки сигналов используется вызов kill(); отметим, что он одинаков в обоих упомянутых стандартах. Вызов имеет два параметра.

Первый задает получателя сигнала. Второй представляет собой номер сигнала, который нужно послать. При успешном завершении kill() возвращает 0, а при ошибке, как обычно, константу –1.

Перед тем как продолжить рассмотрение действий по отношению к сигналам, опишем вспомогательные функции, определенные стандартом POSIX и предназначенные для манипуляций так называемыми наборами сигналов. Всего их 5, называются они sigemptyset(), sigfillset(), sigaddset(), sigdelset(), sigismember().

Первые две имеют один параметр – указатель на набор сигналов;

остальные функции имеют два параметра, первый – такой же указатель, второй – номер сигнала.

Названия этих функций говорят сами за себя: sigemptyset() очищает заданный набор сигналов, то есть удаляет из него все сигналы;

sigfillset() включает в заданный набор все возможные сигналы;

sigaddset() добавляет заданный сигнал в заданный набор;

sigdelset() удаляет заданный сигнал из заданного набора;

sigismember() проверяет, входит ли заданный сигнал в заданный набор. Все функции, кроме последней, возвращают –1 при ошибке и при успешном завершении. Последняя возвращает 1, если сигнал имеется в наборе, 0 – если не имеется и –1 при ошибке. Три системных вызова для работы с сигналами по стандарту POSIX имеют хотя бы один параметр, представляющий собой указатель на набор сигналов.

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

Продолжим теперь рассмотрение действий, которые можно осуществлять по отношению к сигналам. Сигналы можно блокировать и деблокировать. Когда сигнал заблокирован, его обработчик не вызывается, даже если имеется сигнал, требующий обработки. Сигнал как бы ожидает обработки (на английском языке такой сигнал называется "pending signal" – "сигнал, ожидающий обработки", "висячий сигнал").

Обработчик сигнала будет вызван сразу, как только процесс разблокирует этот сигнал.

Блокировка сигнала, по сути, означает временное игнорирование сигнала; разница в том, что если процесс никогда не хочет получать данный сигнал, он его игнорирует, а ОС при возникновении данного сигнала для данного процесса его просто аннулирует; если же для процесса нежелательно получать тот или иной сигнал лишь в течение некоторых промежутков времени, то он его блокирует, а ОС сохраняет информацию о наличии сигнала для данного процесса и доставляет его (сигнал) процессу, когда последний разблокирует этот сигнал.

Совокупность всех сигналов, которые в данный момент времени заблокированы, – маска сигналов. У каждого процесса, естественно, своя маска сигналов; при создании процесса она наследуется от родительского процесса. Для манипуляций с маской сигналов предназначен системный вызов sigprocmask(). Не следует путать их с описанными выше манипуляциями над наборами сигналов, которые ничего не блокируют и не деблокируют.

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

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

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

Еще пример. Допустим, в программе нужно выполнить некое действие только в том случае, если сигнал не пришел. Обработчик сигнала устанавливает флаг. В основной программе вы проверяете этот флаг и, если он не установлен, выполняете требуемые действия. Такой алгоритм ненадежен! Дело в том, что сигнал может прийти в момент времени сразу после проверки флага, но до начала выполнения нужных действий. Можно возразить, что так не может быть, что между проверкой флага и началом действий нет никакого промежутка.

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

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

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

Наконец, в третьем случае маска сигналов заменяется указанным набором. Если неинтересно, какая была маска до вызова, в качестве третьего параметра передаем NULL. Если не желаем ничего менять, а просто нужно знать, какая сейчас маска, передаем в качестве второго параметра NULL. Вызов возвращает 0, если все нормально, –1 при ошибке. Если вызов приводит к разблокированию сигналов, которые уже ожидали обработки, то он возвращается только после того, как будет вызван, по крайней мере, один из обработчиков этих сигналов.

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

Нам осталось рассмотреть операцию ожидания прихода сигнала. Ее можно производить с помощью двух вызовов: pause() и sigsuspend(). Первый определен также в стандарте ANSI C.

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

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

Стандарт POSIX, однако, предлагает другое средство для ожидания сигнала, а именно системный вызов sigsuspend(). Вызов имеет один параметр – указатель на набор сигналов. Он переводит процесс в состояние сна до тех пор, пока не придет один из сигналов, не входящий в указанный набор. Сигналы, не входящие в этот набор, на время исполнения вызова блокированы (то есть вызов sigsuspend() изменяет маску сигналов). После возврата маска сигналов восстанавливается. Фактически данный вызов позволяет ожидать определенные сигналы, в то время как другие сигналы будут обрабатываться соответствующими обработчиками.

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

#include #include extern const char * const sys_siglist[];

void print_blocked(void) int nblocked = 0;

sigset_t blocked;

// get signal mask ret = sigprocmask(SIG_BLOCK, NULL, &blocked);

perror("sigprocmask()");

for ( sig = 0; sig < NSIG; sig++ ) { if ( sys_siglist[sig] ) { if ( nblocked ) printf(" total %d signal(s) blocked } \n\n", sigset_t blocked_orig;

sigset_t blocked_new;

int ret;

int main(void) printf("\nsigprocmask() example\n\ ~~~~~~~~~~~~~~~~~~~~~\n\n");

printf(" { originally blocked signals:\n");

print_blocked();

// формируем набор сигналов, // содержащий SIGINT, SIGTERM, SIGSEGV ret = sigemptyset(&blocked_new);

ret = sigaddset(&blocked_new, SIGINT);

ret = sigaddset(&blocked_new, SIGTERM);

ret = sigaddset(&blocked_new, SIGSEGV);

// блокируем SIGINT, SIGTERM, SIGSEGV, // сохраняем первоначальную маску сигналов ret = sigprocmask(SIG_BLOCK, &blocked_new, &blocked_orig);

perror("sigprocmask()");

printf(" { currently blocked signals:\n");

print_blocked();

ret = sigdelset(&blocked_new, SIGINT);

ret = sigdelset(&blocked_new, SIGTERM);

// SIGSEGV все еще в наборе // разблокируем SIGSEGV, сохраняем маску ret = sigprocmask(SIG_UNBLOCK, &blocked_new, NULL);

perror("sigprocmask()");

printf(" { currently blocked signals:\n");

print_blocked();

// восстанавливаем первоначальную маску сигналов ret = sigprocmask(SIG_SETMASK, &blocked_orig, NULL);

perror("sigprocmask()");

return 0;

В программе определена одна функция (помимо main()), которая выводит на стандартное устройство вывода список заблокированных сигналов. Главная функция распечатывает с ее помощью этот список, затем блокирует сигналы SIGINT, SIGTERM, SIGSEGV (одновременно запоминая текущую маску сигналов), снова печатает список, наконец деблокирует SIGSEGV и опять распечатывает список. Перед завершением программа восстанавливает первоначальную маску сигналов.

Далее приведен пример, демонстрирующий организацию чтения данных со стандартного устройства ввода с использованием сигнала SIGIO.

#define _GNU_SOURCE #include #include #include #include #include #include #include void io_handler(int sig, siginfo_t* sinfo, void * add_info);

struct sigaction io_action;

struct sigaction io_action_old;

sigset_t blocked;

int main(void) printf("\nsigaction() (interrupt i/o) exersise\n");

if ( fcntl(STDIN_FILENO, F_SETFL, O_ASYNC) == -1 ) { perror("fcntl/F_SETFL");