Аппаратное и программное обеспечение ЭВМ и сетей Тема 24 Связь между сетевым и канальным уровнем. Служба ARP. Сопоставление адресов. Протоколы DNS, DHCP Раздел 5 Сети TCP/IP. Сетевой уровень. Транспортный уровень. Прикладной уровень

Связь между сетевым и канальным уровнем На каждом маршрутизаторе протокол IP определяет, какому следующему маршрутизатору направить пакет, другими словами определяется IP адрес следующего маршрутизатора. Чтобы технология любой локальной сети могла доставить пакет на следующий маршрутизатор, необходимо : упаковать пакет в кадр соответствующего для данной подсети (EtherNet, Token Ring, X.25,Frame Relay) формата ; снабдить данный кадр локальным адресом данной подсети следующего маршрутизатора. Решением этой задачи занимается сетевой уровень стека протоколов TCP/IP.

Протокол разрешения адресов Для определения локального адреса по IP- адресу используется протокол разрешения адресов (Address Resolution Protocol, ARP ). Единственный способ установления соответствия ведение таблиц. В результате конфигурирования сети каждый интерфейс знает свои IP- адрес и локальный адрес, что можно рассматривать как таблицу, состоящую из одной строки. Обменм имеющейся информацией между узлами сети и реализуется ARP протоколом Протокол разрешения адресов реализуется различным образом в зависимости от того, работает ли в данной сети протокол локальной сети (Ethernet, Token Ring, FDDI) с возможностью широковещания, а также глобальных старых сетей таких как Х.25, Frame Relay. Рассмотрим работу протокола ARP в локальных сетях с широковещанием.

Протокол разрешения адресов Рис Схема работы протокола ARP

Протокол разрешения адресов На рис показан фрагмент IP- сети, включающий две сети Ethernet, которые подключены к интерфейсам 1 и 2 маршрутизатора. Каждый сетевой интерфейс имеет IP- адрес и МАС - адрес. Пусть в какой - то момент IP- модуль узла С направляет пакет узлу D. Протокол IP узла С определил IP- адрес интерфейса следующего маршрутизатора это IP 1. Теперь, прежде чем упаковать пакет в кадр Ethernet и направить его маршрутизатору, необходимо определить соответствующий МАС - адрес. Для решения этой задачи протокол IP обращается к протоколу ARP. Протокол ARP поддерживает на каждом интерфейсе сетевого адаптера или маршрутизатора отдельную ARP- таблицу, в которой в ходе функционирования сети накапливается информация о соответствии между IP- адресами и МАС - адресами других интерфейсов данной сети. Первоначально, при включении компьютера или маршрутизатора в сеть все его ARP- таблицы пусты.

Протокол разрешения адресов 1. На первом шаге происходит передача от протокола IP протоколу ARP примерно такого сообщения : « Какой МАС - адрес имеет интерфейс с адресом IP 1 ?» 2. ARP начинает просматривать ARP- таблицу соответствующего интерфейса. Допустим, что необходимой записи с IP 1 адресом нет. 3. В этом случае исходящий IP- пакет, для которого оказалось невозможным определить локальный адрес из ARP- таблицы, запоминается в буфере, а протокол ARP формирует ARP- запрос, вкладывает его в кадр протокола Ethernet и широковещательно рассылает. 4. Все интерфейсы сети Ethernet 1 получают ARP- запрос и направляют его « своему » протоколу ARP. ARP сравнивает указанный в запросе адрес IP 1 с IP- адресом интерфейса, на который поступил этот запрос. Протокол ARP, который констатировал совпадение ( в данном случае это ARP маршрутизатора 1), формирует ARP- ответ. В ARP- ответе маршрутизатор указывает локальный адрес МАС своего интерфейса и отправляет его запрашивающему узлу ( в данном примере узлу С ), используя его локальный адрес. Широковещательный ответ в этом случае не требуется, так как формат ARP- запроса предусматривает поля локального и сетевого адресов отправителя. Заметим, что зона распространения ARP- запросов ограничивается сетью Ethernet_1, так как на пути широковещательных кадров барьером стоит маршрутизатор.

Протокол разрешения адресов Рис Инкапсуляция сообщений ARP в кадр Ethernet

Протокол разрешения адресов Ниже проиллюстрирована структура пакета, используемого в запросах и ответах ARP. В сетях Ethernet в этих пакетах используется EtherType 0x0806, и рассылаются широковещательно MAC- адрес FF:FF:FF:FF:FF:FF. В структуре пакета, условно используются 32- битные слова реальная длина определяется физическим устройством и протоколом. Рис Поля сообщений ARP

Протокол разрешения адресов Hardware type (HTYPE) Каждый канальный протокол передачи данных имеет свой номер, который хранится в этом поле. Например, Ethernet имеет номер 0x0001. Protocol type (PTYPE) Код сетевого протокола. Например, для IPv4 будет записано 0x0800. Hardware length (HLEN) Длина физического адреса в байтах. Адреса Ethernet имеют длину 6 байт. Protocol length (PLEN) Длина логического адреса в байтах. IPv4 адреса имеют длину 4 байта. Operation

Протокол разрешения адресов Код операции отправителя : 1 в случае запроса и 2 в случае ответа. Sender hardware address (SHA) Физический адрес отправителя. Sender protocol address (SPA) Логический адрес отправителя. Target hardware address (THA) Физический адрес получателя. Поле пусто при запросе. Target protocol address (TPA) Логический адрес получателя.

Протокол разрешения адресов На рис показан кадр Ethernet с вложенным в него ARP- сообщением. ARP- запросы и ARP- ответы имеют один и тот же формат. В табл в качестве примера приведены значения полей реального ARP- запроса, переданного по сети Ethernet. В поле типа сети для сетей Ethernet указывается значение 1. Поле типа протокола позволяет использовать протокол ARP не только с протоколом IP, но и с другими сетевыми протоколами. Для IP значение этого поля равно 0x0800. Длина локального адреса для протокола Ethernet равна 6 байт, а длина IP- адреса 4 байт. В поле операции для ARP- запросов указывается значение 1, для ARP- ответов значение 2.

Протокол разрешения адресов Таблица Пример ARP- запроса Из этого запроса видно, что в сети Ethernet узел с IP- адресом пытается определить, какой МАС - адрес имеет другой узел той же сети, сетевой адрес которого Поле искомого локального адреса заполнено нулями. Поле Значение Тип сети 1 (0x1) (Ethernet) Тип протокола 2048 (0x800 )IP протокол Длина локального адреса 6(0x6) (MAC-адрес) Длина сетевого адреса 4 (0x4) Операция 1 (0x1) запрос Локальный адрес отправителя ЕВ7Е60 Сетевой адрес отправителя Локальный (искомый) адрес получателя Сетевой адрес получателя

Протокол разрешения адресов Таблица Пример ARP- ответа Ответ присылает узел, опознавший свой IP- адрес. Если в сети нет машины с искомым IP- адресом, то ARP- ответа не будет. Протокол IP уничтожает IP- пакеты, направляемые по этому адресу. В табл показаны значения полей ARP- ответа, который мог бы поступить на приведенный в табл ARP- запрос. Поле Значение Тип сети 1 (0x1) Тип протокола 2048 (0x800) Длина локального адреса 6(0x6) Длина сетевого адреса 4 (0x4) Операция 2 (0x2) Локальный адрес отправителя 00E0F77F1920 Сетевой адрес отправителя Локальный (искомый) адрес получателя ЕВ7Е60 Сетевой адрес получателя

Протокол разрешения адресов В результате обмена ARP- сообщениями модуль IP, пославший запрос с интерфейса, имеющего адрес , определил, что IP- адресу соответствует МАС - адрес 00E0F77F1920. Этот адрес будет затем помещен в заголовок кадра Ethernet, ожидавшего отправления IP- пакета. Чтобы уменьшить число ARP- обращений в сети, найденное соответствие между IP- адресом и МАС - адресом сохраняется в ARP- таблице соответствующего интерфейса, в данном случае это запись : E0F77F1920 Данная запись в ARP- таблице появляется автоматически, спустя несколько миллисекунд после того, как модуль ARP проанализирует ARP- ответ. Теперь, если вдруг вновь возникнет необходимость послать пакет по адресу , то протокол IP, прежде чем посылать широковещательный запрос, проверит, нет ли уже такого адреса в ARP- таблице.

Протокол разрешения адресов ARP- таблица пополняется не только за счет поступающих на данный интерфейс ARP- ответов, но и в результате извлечения полезной информации из широковещательных ARP- запросов. Таблица Пример ARP- таблицы В ARP- таблицах существует два типа записей : динамические и статические. Статические записи создаются вручную с помощью утилиты ARP и не имеют срока устаревания, точнее, они существуют до тех пор, пока компьютер или маршрутизатор остается включенным. Динамические записи должны периодически обновляться. Если запись не обновлялась в течение определенного времени ( порядка нескольких минут ), то она исключается из таблицы. Таким образом, в ARP- таблице содержатся записи не обо всех узлах сети, а только о тех, которые активно участвуют в сетевых операциях. Поскольку такой способ хранения информации называют кэшированием, ARP- таблицы иногда называют ARP- кэшем. IP-адресМАС-адрес Тип записи E0F77F1920Динамический ЕВ7Е60Динамический ЕВ7567Статический

Способ реализации ARP в глобальных сетях. В глобальных сетях, не поддерживается широковещательная рассылка, здесь администратору сети приходится вручную формировать и помещать на какой - либо сервер ARP- таблицы, в которых он задает, например, соответствие IP- адресов адресам Х.25, имеющих для протокола IP смысл локальных адресов. Для автоматизации работы протокола ARP в глобальных сетях, выделяется специальный маршрутизатор, который ведет ARP- таблицу для всех остальных узлов и маршрутизаторов этой сети. Всякий раз, при необходимости модуль ARP обращается к выделенному маршрутизатору с запросом и автоматически получает ответ. Работающий таким образом маршрутизатор называют ARP- сервером. В некоторых случаях возникает обратная задача нахождение IP- адреса по известному локальному адресу. Тогда в действие вступает реверсивный протокол ARP (Reverse Address Resolution Protocol, RARP). RARP используется, например, при старте бездисковых станций, не знающих в начальный момент времени своего IP- адреса, но знающих МАС - адрес своего сетевого адаптера.

Протокол разрешения адресов Протокол Proxy-ARP Протокол Proxy-ARP это одна из разновидностей протокола ARP, позволяющая отображать IP- адреса на аппаратные адреса в сетях, поддерживающих широковещание, даже в тех случаях, когда искомый узел находится за пределами данного домена коллизий. На рис показана сеть, один из конечных узлов которой ( компьютер D) работает в режиме удаленного узла ( конечный узел в таком режиме обладает всеми возможностями компьютеров, работающих в основной части сети Ethernet, в частности, он имеет IP- адрес (IP D ), относящийся к той же сети. Для всех конечных узлов сети Ethernet особенности подключения удаленного узла ( наличие модемов, коммутируемая связь, протокол РРР ) абсолютно прозрачны они взаимодействуют с ним обычным образом. Чтобы такой режим взаимодействия стал возможным, среди прочего, необходим протокол Proxy -ARP. Поскольку удаленный узел подключен к сети по протоколу РРР, то он, очевидно, не имеет МАС - адреса

Протокол разрешения адресов Рис Схема работы протокола Proxy-ARP

Протокол разрешения адресов Протокол Proxy-ARP Пусть приложение, работающее, например, на компьютере С, решает послать пакет компьютеру D. Ему известен IP- адрес узла назначения (IP D )» однако как мы уже не раз отмечали, для передачи пакета по сети Ethernet его необходимо упаковать в кадр Ethernet и снабдить МАС - адресом. Для определения МАС - адреса IP- протокол узла С обращается к протоколу ARP, который посылает широковещательное сообщение с ARP- запросом. Если бы в этой сети на маршрутизаторе не был установлен протокол Proxy - ARP, на этот запрос не откликнулся бы ни один узел.

Протокол разрешения адресов Протокол Proxy-ARP Однако протокол Proxy-ARP установлен на маршрутизаторе и работает следующим образом. При подключении к сети удаленного узла D в таблицу ARP- маршрутизатора заносится запись IP D – MAC 1 - int2, которая означает, что : при поступлении ARP- запроса на маршрутизатор относительно адреса IP D в ARP- ответ будет помещен аппаратный адрес МАС 1 соответствующий аппаратному адресу интерфейса 1 маршрутизатора ; узел, имеющий адрес IP D, подключен к интерфейсу 2 маршрутизатора.

Протокол разрешения адресов Протокол Proxy-ARP В ответ на посланный узлом С широковещательный ARP- запрос откликается маршрутизатор с установленным протоколом Proxy -ARP. Он посылает « ложный » ARP- ответ, в котором на место аппаратного адреса компьютера D помещает собственный адрес МАС 1. Узел С, не подозревая « подвоха », посылает кадр с IP- пакетом по адресу МАС 1 Получив кадр, маршрутизатор с установленным протоколом Proxy - ARP « понимает », что он направлен не ему ( в пакете указан чужой IP- адрес ) и, следовательно, надо искать адресата в ARP- таблице. Из таблицы видно, что кадр надо направить узлу, подключенному ко второму интерфейсу.

Система DNS Плоские символьные имена В операционных системах, которые первоначально разрабатывались для локальных сетей, таких как Novell NetWare, Microsoft Windows или IBM OS/2, пользователи всегда работали с символьными именами компьютеров. Так как локальные сети состояли из небольшого числа компьютеров, применялись так называемые плоские имена, состоящие из последовательности символов, не разделенных на части. Для установления соответствия между символьными именами и МАС - адресами в этих операционных системах применялся механизм широковещательных запросов, подобный механизму запросов протокола ARP. Так, широковещательный способ разрешения имен реализован в протоколе NetBIOS, на котором были построены многие локальные ОС. Так называемые NetBIOS- имена стали на долгие годы одним из основных типов плоских имен в локальных сетях. (WINS – для Windows) Для стека TCP/IP, рассчитанного в общем случае на работу в больших территориально распределенных сетях, подобный подход оказывается неэффективным.

Система DNS Иерархические символьные имена В стеке TCP/IP применяется доменная система имен, которая имеет иерархическую древовидную структуру, допускающую наличие в имени произвольного количества составных частей ( рис ). Рис Пространство доменных имен

Система DNS Иерархия доменных имен аналогична иерархии имен файлов, принятой во многих популярных файловых системах. Дерево имен начинается с корня, обозначаемого здесь точкой (). Затем следует старшая символьная часть имени, вторая по старшинству символьная часть имени и т. д. Младшая часть имени соответствует конечному узлу сети. В отличие от имен файлов, запись доменного имени начинается с самой младшей составляющей, а заканчивается самой старшей. Составные части доменного имени отделяются друг от друга точкой. Например, в имени partnering.microsoft.com составляющая partnering является именем одного из компьютеров в домене microsoft.com. Разделение имени на части позволяет разделить административную ответственность за назначение уникальных имен между различными людьми или организациями в пределах своего уровня иерархии. Так, для примера, приведенного на рис , один человек может нести ответственность за то, чтобы все имена, которые имеют окончание « ru », имели уникальную следующую вниз по иерархии часть. Если этот человек справляется со своими обязанностями, то все имена типа mail.mmt.ru или т 2,zil.mmt.ru будут отличаться второй по старшинству частью.

Система DNS Но, очевидно, что должна существовать одна организация, отвечающая за назначение имен верхнего уровня иерархии. Совокупность имен, у которых несколько старших составных частей совпадают, образуют домен имен (domain). Например, имена www1.zil.mmt.ru, ftp.zil.mmt.ru, yandex.ru и s1.mgu.ru входят в домен ru. Другим примером является домен mgu.ru. Образованные домены s1.mgu.ru, s2.mgu.ru и rn.mgu.ru являются поддоменами домена mgu.ru, так как имеют общую старшую часть имени. Часто поддомены для краткости называют только младшей частью имени, то есть поддомены s1, s2 и m.

Система DNS ПРИМЕЧАНИЕ – Если в каждом домене и поддомене обеспечивается уникальность имен следующего уровня иерархии, то и вся система имен будет состоять из уникальных имен. По аналогии с файловой системой в доменной системе имен различают краткие имена, относительные имена и полные доменные имена. Краткое имя это имя конечного узла сети : хоста или порта маршрутизатора. Краткое имя это лист дерева имен. Относительное имя это составное имя, начинающееся с некоторого уровня иерархии, но не самого верхнего. Например, wwwl.zil это относительное имя. Полное доменное имя (Fully Qualified Domain Name, FQDN) включает составляющие всех уровней иерархии, начиная от краткого имени и кончая корневой точкой : www1.zil.mmt.ru.

Система DNS Корневой домен управляется центральными органами Интернета IANA и InterNIC. Домены верхнего уровня назначаются для каждой страны, а также для различных типов организаций. Имена этих доменов должны следовать международному стандарту ISO Для обозначения стран используются трехбуквенные и двух - буквенные аббревиатуры, например ru ( Россия ), uk ( Великобритания ), fi ( Финляндия ), us ( Соединенные Штаты ), а для различных типов организаций например, следующие обозначения : com коммерческие организации ( например, microsoft.com); edu образовательные организации ( например, mit.edu); gov правительственные организации ( например, nsf.gov); org некоммерческие организации ( например, fidonet.org); net сетевые организации ( например, nsf.net).

Система DNS Каждый домен администрирует отдельная организация, которая обычно разбивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Чтобы получить доменное имя, необходимо зарегистрироваться в какой - либо организации, которой орган InterNIC делегировал свои полномочия по распределению имен доменов. ВНИМАНИЕ ! Компьютеры входят в домен в соответствии со своими составными именами, при этом они могут иметь абсолютно независимые друг от друга IP- адреса, принадлежащие различным сетям и подсетям. Например, в домен mgu.ru могут входить хосты с адресами , и Доменная система имен реализована в Интернете, но она может работать и как автономная система имен в любой крупной корпоративной сети, которая хотя и использует стек TCP/IP никак не связана с Интернетом.

Система DNS Схема работы DNS В крупных сетях, где возможность всеобщей широковещательной рассылки не поддерживается, нужен другой способ разрешения символьных имен. Хорошей альтернативой широковещательной рассылке является применение централизованной службы, поддерживающей соответствие между различными типами адресов всех компьютеров сети. Например, компания Microsoft для своей корпоративной операционной системы Windows NT разработала централизованную службу WINS, которая поддерживала базу данных NetBIOS- имен и соответствующих им IP- адресов. В сетях TCP/IP соответствие между доменными именами и IP- адресами может устанавливаться средствами как локального хоста, так и централизованной службы. На раннем этапе развития Интернета на каждом хосте вручную создавался текстовый файл с известным именем hosts.txt. Этот файл состоял из некоторого количества строк, каждая из которых содержала одну пару « доменное имя IP- адрес », например : ns1.mogilev.by

Система DNS По мере роста Интернета файлы hosts.txt также увеличивались в объеме, и создание масштабируемого решения для разрешения имен стало необходимостью. Таким решением стала централизованная служба DNS (Domain Name System система доменных имен ), основанная на распределенной базе отображений « доменное имя IP- адрес ». Служба DNS использует в своей работе DNS- серверы и DNS- клиенты. DNS- серверы поддерживают распределенную базу отображений, а DNS- клиенты обращаются к серверам с запросами о разрешении доменного имени в IP- адрес. Служба DNS использует текстовые файлы почти такого формата, как и файл hosts, и эти файлы администратор также подготавливает вручную. Однако служба DNS опирается на иерархию доменов, и каждый сервер службы DNS хранит только часть имен сети, а не все имена, как это происходит при использовании файлов hosts. При росте количества узлов в сети проблема масштабирования решается созданием новых доменов и поддоменов имен и добавлением в службу DNS новых серверов.

Система DNS Для каждого домена имен создается свой DNS- сервер. Имеется два распределения имен на серверах. В первом случае сервер может хранить отображения « доменное имя IP- адрес » для всего домена, включая все его поддомены. Однако такое решение оказывается плохо масштабируемым, так как при добавлении новых поддоменов нагрузка на этот сервер может превысить его возможности. Чаще используется другой подход, когда сервер домена хранит только имена, которые заканчиваются на следующем ниже уровне иерархии по сравнению с именем домена. ( Аналогично каталогу файловой системы, который содержит записи о файлах и подкаталогах, непосредственно в него « входящих ».) Именно при такой организации службы DNS нагрузка по разрешению имен распределяется более - менее равномерно между всеми DNS- серверами сети. Например, в первом случае DNS- сервер домена mogilev. by будет хранить отображения для всех имен, заканчивающихся на mogilev.by ( bru. mogilev. by, www. asu. bru. mogilev. by, mail. mogilev. by и т. д.). Во втором случае этот сервер хранит отображения только имен типа mail. mogilev. by, www. mogilev. by, а все остальные отображения должны храниться на DNS- сервере поддомена bru.

Система DNS Каждый DNS- сервер помимо таблицы отображений имен содержит ссылки на DNS- серверы своих поддоменов. Эти ссылки связывают отдельные DNS- серверы в единую службу DNS. Ссылки представляют собой IP- адреса соответствующих серверов. Для обслуживания корневого домена выделено несколько дублирующих друг друга DNS- серверов, IP- адреса которых являются широко известными ( их можно узнать, например, в InterNIC). Процедура разрешения DNS- имени во многом аналогична процедуре поиска файловой системой адреса файла по его символьному имени. Действительно, в обоих случаях составное имя отражает иерархическую структуру организации соответствующих справочников каталогов файлов или DNS- таблиц. Здесь домен и доменный DNS- сервер являются аналогом каталога файловой системы. Для доменных имен, так же как и для символьных имен файлов, характерна независимость именования от физического местоположения. Процедура поиска адреса файла по символьному имени заключается в последовательном просмотре каталогов, начиная с корневого. При этом предварительно проверяются кэш и текущий каталог. Для определения IP- адреса по доменному имени также необходимо просмотреть все DNS- серверы, обслуживающие цепочку поддоменов, входящих в имя хоста, начиная с корневого домена.

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

Система DNS Во втором варианте реализуется рекурсивная процедура. 1. DNS - клиент запрашивает локальный DNS - сервер, то есть тот сервер, обслуживающий поддомен, которому принадлежит имя клиента. 2. Далее возможны два варианта действий. A. если локальный DNS - сервер знает ответ, то он сразу же возвращает его клиенту ( т. е. когда запрошенное имя входит в тот же поддомен, что и имя клиента, или когда сервер уже сохранил его в своем кэше ); B. если локальный сервер не знает ответ, то он выполняет итеративные запросы к корневому серверу и т. д. точно так же, как это делал клиент в предыдущем варианте, а получив ответ, передает его клиенту, который все это время просто ждет его от своего локального DNS - сервера.

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

Система DNS Обратная зона Обратная запись не всегда существует даже для тех адресов, для которых есть прямые записи. Ее могли просто забыть создать или же ее создание требует дополнительной оплаты. Обратная задача решается в Интернете путем организации так называемых обратных зон. Обратная зона это система таблиц, которая хранит соответствие между IP- адресами и DNS- имена хостов некоторой сети. Для организации распределенной службы и использования для поиска имен того же программного обеспечения, что и для поиска адресов, применяется оригинальный подход, связанный с представлением IP- адреса в виде DNS- имени.

Система DNS Первый этап преобразования заключается в том, что составляющие IP- адреса интерпретируются как составляющие DNS- имени. Например, адрес рассматривается как состоящий из старшей части, соответствующей домену 192, затем идет домен 31, в который входит домен 106. Далее, учитывая, что при записи IP- адреса старшая часть является самой левой частью адреса, а при записи DNS- имени самой правой, то составляющие в преобразованном адресе указываются в обратном порядке, то есть для данного примера Для хранения соответствия всех адресов, начинающихся, например, с числа 192, заводится зона 192 со своими серверами имен. Для записей о серверах, поддерживающих старшие в иерархии обратные зоны, создана специальная зона in-addr.arpa, поэтому полная запись для использованного в примере адреса выглядит так : in-addr.arpa Серверы для обратных зон используют файлы баз данных, не зависящие от файлов основных зон, в которых имеются записи о прямом соответствии тех же имен и адресов. Такая организация данных может приводить к несогласованности, так как одно и то же соответствие вводится в файлы дважды.

Протокол DHCP Для нормальной работы сети каждому сетевому интерфейсу компьютера и маршрутизатора должен быть назначен IP- адрес. Назначение IP- адресов может происходить вручную в результате выполнения процедуры конфигурирования интерфейса, для компьютера, маршрутизатора. При этом администратор должен помнить, какие адреса из имеющегося множества он уже использовал для других интерфейсов, а какие еще свободны. При конфигурировании администратор должен назначить клиенту не только IP- адрес, но и другие параметры стека TCP/IP, необходимые для его эффективной работы, например маску и IP- адрес маршрутизатора по умолчанию, IP- адрес сервера DNS, доменное имя компьютера и т. п. При большом размере сети эта работа представляет для администратора утомительную процедуру. Протокол динамического конфигурирования хостов (Dynamic Host Configuration Protocol, DHCP) автоматизирует процесс конфигурирования сетевых интерфейсов, гарантируя защиту от дублирования адресов за счет централизованного управления их распределением. Работа DHCP описана в RFC 2131 и 2132.

Протокол DHCP Dynamic Host Configuration Protocol Режимы DHCP Протокол DHCP работает в соответствии с моделью клиент - сервер. Во время старта системы компьютер, являющийся DHCP- клиентом, посылает в сеть широковещательный запрос на получение IP- адреса. DHCP- сервер откликается и посылает сообщение - ответ, содержащее IP- адрес и некоторые другие конфиг - параметры. При этом сервер DHCP может работать в разных режимах, включая : ручное назначение статических адресов ; автоматическое назначение статических адресов ; автоматическое распределение динамических адресов. Во всех режимах работы администратор при конфигурировании DHCP- сервера сообщает ему один или несколько диапазонов IP- адресов, причем все эти адреса относятся к одной сети, то есть имеют одно и то же значение в поле номера сети. В ручном режиме администратор, помимо пула доступных адресов, снабжает DHCP- сервер информацией о жестком соответствии IP- адресов физическим адресам или другим идентификаторам клиентских узлов. DHCP- сервер, пользуясь этой информацией, всегда выдает определенному DHCP- клиенту один и тот же назначенный ему администратором IP- адрес ( а также набор других конфигурационных параметров.

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

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

Протокол DHCP Рис Схемы взаимного расположение серверов и клиентов DHCP

Протокол DHCP Иногда наблюдается и обратная картина : в сети нет ни одного DHCP- сервера, его подменяет связной DHCP- агент программное обеспечение, играющее роль посредника между DHCP- клиентами и DHCP- серверами ( пример такого варианта сеть 2 на рисунке ). Связной агент переправляет запросы клиентов из сети 2 DHCP- серверу сети 3. Таким образом, один DHCP- сервер может обслуживать DHCP- клиентов нескольких разных сетей. Ниже дана упрощенная схема обмена сообщениями между клиентскими и серверными частями DHCP. 1. Когда компьютер включают, установленный на нем DHCP- клиент посылает ограниченное широковещательное сообщение DHCP- поиска (IP- пакет с адресом назначения, состоящим из одних единиц, который должен быть доставлен всем узлам данной IP- сети ). 2. Находящиеся в сети DHCP- серверы получают это сообщение. Если в сети DHCP- серверы отсутствуют, то сообщение DHCP- поиска получает связной DHCP- агент. Он пересылает это сообщение в другую, возможно, значительно отстоящую от него сеть DHCP- серверу, IP- адрес которого ему заранее известен.

Упрощенная схема обмена Протокол DHCP 3. Все DHCP- серверы, получившие сообщение DHCP- поиска, посылают DHCP- клиенту, обратившемуся с запросом, свои DHCP- предложения. Каждое предложение содержит IP- адрес и другую конфигурационную информацию. (DHCP- сервер, находящийся в другой сети, посылает ответ через агента.) 4. DHCP- клиент собирает конфигурационные DHCP- предложения ото всех DHCP- серверов. Как правило, он выбирает первое из поступивших предложений и отправляет в сеть широковещательный DHCP- запрос. В этом запросе содержатся идентификационная информация о DHCP- сервере, предложение которого принято, а также значения принятых конфигурационных параметров. 5. Все DHCP- серверы получают DHCP- запрос, и только один выбранный DHCP- сервер посылает положительную DHCP- квитанцию ( подтверждение IP- адреса и параметров аренды ), а остальные серверы аннулируют свои предложения, в частности возвращают в свои пулы предложенные адреса. 6. DHCP- клиент получает положительную DHCP- квитанцию и переходит в рабочее состояние.

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

Протокол DHCP Во - первых, возникают сложности при преобразовании символьного доменного имени в IP- адрес. Действительно, представьте себе функционирование системы DNS, которая должна поддерживать таблицы соответствия символьных имен IP- адресам в условиях, когда последние меняются каждые два часа ! Учитывая это обстоятельство, для серверов, к которым пользователи часто обращаются по символьному имени, назначают статические IP- адреса, оставляя динамические только для клиентских компьютеров. Однако в некоторых сетях количество серверов настолько велико, что их ручное конфигурирование становится слишком обременительным. Это привело к разработке усовершенствованной версии DNS ( так называемой динамической системы DNS), в основе которой лежит согласование информационной адресной базы в службах DHCP и DNS.

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

Протокол ICMP Протокол межсетевых управляющих сообщений (Internet Control Message Protocol, ICMP) играет в сети вспомогательную роль. Спецификация этого протокола содержится в RFC 792. Существует ряд ситуаций, когда протокол IP не может доставить пакет адресату, например, когда истекает время жизни пакета, когда в таблице маршрутизации отсутствует маршрут к заданному в пакете адресу назначения, когда пакет не проходит проверку по контрольной сумме, когда шлюз не имеет достаточно места в своем буфере для передачи какого - либо пакета и т. д. и т. п.. Протокол ICMP служит дополнением протокола IP несколько другого рода. Он не предназначен для исправления возникших при передаче пакета проблем : если пакет потерян, ICMP не может послать его заново. Задача ICMP другая он является средством оповещения отправителя о « несчастных случаях », произошедших с его пакетами. В то время как протокол IP посылает пакет и забывает о нем, протокол ICMP « отслеживает » передвижение пакета по сети и при отбрасывании пакета маршрутизатором передает сообщение об этом узлу - источнику, обеспечивая таким образом обратную связь между посланным пакетом и отправителем. Пусть, например, протокол IP, работающий на каком - либо маршрутизаторе, обнаружил, что пакет для дальнейшей передачи по маршруту необходимо фрагментировать, но в пакете установлен признак DF ( не фрагментировать ). Протокол IP, обнаруживший, что он не может передать IP- пакет далее по сети, должен отправить диагностическое ICMP- сообщение узлу - источнику и только потом отбросить пакет.

Протокол ICMP Помимо диагностики ICMP также используется для мониторинга сети. Так, в основе популярных утилит для мониторинга IP- сетей ping и tracert лежат ICMP- сообщения. С помощью ICMP- сообщений приложение может определить маршрут перемещения данных, оценить работоспособность сети, определить время прохождения данных до заданного узла, сделать запрос о значении маски определенного сетевого интерфейса и т. п. Заметим, что некоторые из пакетов могут исчезнуть в сети, не вызвав при этом никаких оповещений. В частности, протокол ICMP не предусматривает передачу сообщений о проблемах, возникающих при обработке IP- пакетов, несущих ICMP- сообщения об ошибках. ( Это правило, однако, не действует для I СМР - запросов.) Такое решение было принято разработчиками протокола, чтобы не порождать « штормы » в сетях, когда количество сообщений об ошибках лавинообразно возрастает. По этой же причине ICMP- сообщения не передаются, если ошибка возникла при передаче какого - либо фрагмента, кроме первого, а также когда потерянный пакет имел широковещательный IP- адрес или был упакован в кадр с широковещательным адресом несущей технологии. Поскольку IP- пакет содержит адрес отправителя, но не содержит никакой адресной информации о промежуточных маршрутизаторах, ICMP- сообщения направляются только конечным узлам. Здесь сообщения могут быть обработаны либо ядром операционной системы, либо протоколами транспортного и прикладного уровней, либо приложениями, либо просто проигнорированы. Важно, что обработка ICMP- сообщений не входит в обязанности протоколов IP и ICMP.

Протокол ICMP Типы ICMP- сообщений Все типы ICMP- сообщений могут быть разделены на два класса : диагностические сообщения об ошибках ; информационные сообщения типа запрос / ответ. ICMP- сообщение инкапсулируется в поле данных IP- пакета ( рис ). Рис Инкапсуляция и формат ICMP- сообщения

Протокол ICMP Заголовок ICMP состоит из 8 байт ; поля заголовка перечислены ниже. Тип ( размером 1 байт ) содержит код, определяющий тип сообщения. Основные типы сообщений перечислены в табл Код ( размером 1 байт ) более тонко дифференцирует тип ошибки. Контрольная сумма, подсчитанная для всего ICMP- сообщения, занимает 2 байта. Поле из 4 байт : 1. В сообщениях типа запрос / ответ это поле содержит 2- байтовые подполя идентификатора и порядкового номера ( см. далее ). Числа из этих подполей дублируются из сообщения - запроса в сообщение - ответ. Идентификатор позволяет узлу - получателю сообщения определить, какому приложению направлен этот ответ, а порядковый номер используется приложением, чтобы связать ответ с соответствующим запросом ( учитывая, что одно приложение может выдать несколько однотипных запросов ). 2. В сообщениях об ошибке это поле не используется и заполняется нулями.

Протокол ICMP Таблица Возможные значения поля типа Значение Тип сообщения 0Эхо-ответ 3Узел назначения недостижим 4Подавление источника 5Перенаправление маршрута 8Эхо-запрос 11Истечение времени дейтаграммы 12Проблема с параметром пакета 13Запрос отметки времени 14Ответ отметки времени 17Запрос маски 18Ответ маски

Протокол ICMP Каждый тип ошибки может быть более точно охарактеризован кодом ошибки. Например, в табл приведены коды для сообщения о недостижимости узла назначения ( ошибка типа 3 из предыдущей таблицы ). Эти коды, которые могут быть указаны в сообщении этого типа, позволяют выявить множество различ ­ ных причин данной ситуации. Недостижимость узла назначения может, в частности, быть вызвана временной неработоспособностью аппаратуры, неверным адресом назначения, отсутствием протокола прикладного уровня или открытого порта UDP/TCP в узле назначения.

Протокол ICMP Таблица Коды, детализирующие причину ошибки о недостижимости узла назначения Код Причина 0Сеть недостижима 1Узел недостижим 2Протокол недостижим 3Порт недостижим 4Требуется фрагментация, а бит DF установлен 5Ошибка в маршруте, заданном источником 6Сеть назначения неизвестна 7Узел назначения неизвестен 8Узел-источник изолирован 9Взаимодействие с сетью назначения административно запрещено 10Взаимодействие с узлом назначения административно запрещено 11Сеть недостижима для заданного класса сервиса 12Узел недостижим для заданного класса сервиса 13Взаимодействие административно запрещено путем фильтрации

Протокол ICMP Формат поля данных ICMP- сообщения также зависит от значений полей типа и кода. Чтобы показать различия в форматах разных типов сообщений, мы рассмотрим в следующих разделах два примера : сообщения типа эхо - запрос и эхо - ответ ; сообщение о недостижимости узла назначения. Формат эхо - запроса / эхо - ответа и утилита ping На рис показаны форматы эхо - запроса и эхо - ответа. Они отличаются друг от друга только значением поля типа ( нули для ответа, единицы для запроса ). В поле данных запроса отправитель помещает информацию, которую затем получает в ответе от узла назначения. Рис Формат ICMP- сообщений типа эхо - запрос / эхо - ответ

Протокол ICMP Эхо - запрос и эхо - ответ, в совокупности называемые эхо - протоколом, представляют собой очень простое средство мониторинга сети. Компьютер или маршрутизатор посылает по составной сети эхо - запрос, указывая в нем IP- адрес узла, достижимость которого нужно проверить. Узел, получивший эхо - запрос, формирует и отправляет эхо - ответ отправителю запроса. Так как эхо - запрос и эхо - ответ передаются по сети внутри IP- пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы составной сети. Во многих операционных системах используется утилита ping, предназначенная для тестирования достижимости узлов. Эта утилита обычно посылает серию эхо - запросов к тестируемому узлу и предоставляет пользователю статистику об утерянных эхо - ответах и среднем времени реакции сети на запросы. Утилита ping выводит на экран сообщения следующего вида обо всех поступивших ответах : # ping serverl.citmgu.ru Pinging serverl.citmgu.ru [ ] with 64 bytes of data: Reply from : bytes-64 time-256ms TTL- 123 Reply from : bytes=64 time-310ms TTL= 123 Reply from : bytes=64 time=260ms TTL- 123 Reply from : bytes=64 time=146ms TTL= 123

Протокол ICMP Из приведенной распечатки видно, что в ответ на тестирующие запросы, посланные узлу server1.mgu.ru, было получено 4 эхо - ответа. Длина каждого сообщения составляет 64 байта. В следующей колонке помещены значения времени оборота (RTT), то есть времени от момента отправки запроса до получения ответа на тот запрос. Как видим, сеть работает достаточно нестабильно время в последней строке отличается от времени во второй более чем в два раза. На экран выведено также оставшееся время жизни поступивших пакетов. В зависимости от конкретной реализации утилиты ping, а также ее настроек ( ключей ) выводимые экранные формы могут отличаться. У утилиты ping обычно имеется несколько ключей, с помощью которых можно установить размер поля данных сообщения, начальное значение поля TTL, количество повторных передач пакетов, флаг DF. В том случае, когда за установленное время тайм - аута ответы не приходят или протокол ICMP сообщает об ошибках, утилита ping выводит на экран соответствующие диагностические сообщения.

Протокол ICMP Формат сообщения об ошибке и утилита traceroute На рис показан формат ICMP- сообщения об ошибке, в данном случае это сообщение о недостижимости узла назначения. Остальные ICMP- сообщения об ошибках имеют такой же формат и отличаются друг от друга только значениями полей типа и кода. Рис Формат ICMP- сообщения об ошибке недостижимости узла назначения Когда маршрутизатор не может передать или доставить IP- пакет, он отсылает узлу, отправившему этот пакет, сообщение о недостижимости узла назначения. В поле типа помещается значение 3, а в поле кода значение из диапазона 0-15, уточняющее причину, по которой пакет не был доставлен. Следующие за полем контрольной суммы 4 байт заголовка не используются и заполняются нулями.

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

Протокол ICMP Как было показано на примере утилиты ping, ICMP- сообщения эффективно используются для мониторинга сети. В частности, сообщения об ошибке истечения тайм - аута лежат в основе работы другой популярной утилиты traceroute для Unix, имеющей в Windows 2000 название tracert. Эта утилита позволяет проследить маршрут до удаленного хоста, определить RTT, IP- адрес и доменное имя для каждого промежуточного маршрутизатора ( если это имя зарегистрировано в обратной зоне службы DNS). Такая информация полезна для локализации маршрутизатора, на котором обрывается путь пакета к удаленному хосту. Утилита traceroute осуществляет трассировку маршрута путем посылки обычных IP- пакетов с адресом назначения, являющимся конечной точкой изучаемого маршрута. Суть метода трассировки состоит в том, что значение TTL первого отправляемого пакета установлено равным 1. Когда протокол IP первого маршрутизатора принимает этот пакет, то он в соответствии со своим алгоритмом уменьшает значение TTL на 1 и получает 0. Маршрутизатор отбрасывает пакет с нулевым временем жизни и возвращает узлу - источнику ICMP- сообщение об ошибке истечения тайм - аута вместе с заголовком IP и первыми 8 байтами потерянного пакета.

Протокол ICMP Получив ICMP- сообщение о причине недоставки пакета, утилита traceroute запоминает адрес первого маршрутизатора ( который извлекает из заголовка IP- пакета, несущего ICMP- сообщение ) и вычисляет для него RTT. Затем traceroute посылает следующий IP- пакет, но теперь со значением TTL, равным 2. Этот пакет благополучно проходит первый маршрутизатор, но « умирает » на втором, о чем немедленно отправляется аналогичное ICMP- сообщение об ошибке истечения тайм - аута. Утилита traceroute запоминает адрес и время для второго маршрутизатора и т. д. Такие действия выполняются с каждым маршрутизатором вдоль маршрута вплоть до узла назначения. Мы рассмотрели работу утилиты traceroute весьма схематично, но и этого достаточно, чтобы оценить изящество идеи, лежащей в основе ее работы.

Протокол ICMP Ниже приведена копия экранной формы, выведенной утилитой tracert (Windows) при трассировке хоста ds.internjc.net [ ]: ms 290 ms 261 ms ms 300 ms 271 ms ms 290 ms 311 ms moscow-m9-2-S5.relcom.eu.net [ ] ms 261 ms 280 ms MSK-M9-13 Relcom.EU.net [ ] ms 281 ms 290 ms MSK.RAIL-l-ATM0-155Mb.Relcom.EU.net [ ] ms 311 ms 290 ms SPB-RASC0M-l-E3-l-34Mb.Relcom.EU.net [ ] ms 300 ms 300 ms Hssill-0.GW1.STK2.ALTER.NET [ ] ms 330 ms 291 ms 421.ATM6-0-0.CR2.STK2.Alter.Net [ ] ms 331 ms 330 ms 219 Hssi4-0.CR2.LND1.Alter.Net [ ] ms 330 ms 331 ms 412.Atm5-0.BRl.LNDl.Alter.net [ ] ms 461 ms 420 ms 167.ATM8-0-0.CR1.ATL1.Alter.Net [ ] ms 441 ms 440 ms 311.ATM BR1.ATL1.Alter.Net [ ] ms 410 ms 431 ms atlantal-brl.bbnplanet.net [ ] ms 411 ms 410 ms viennal-br2.bbnplanet.net [ ] ms 430 ms 2514 ms viennal- nbr3.bbnplanet.net [ ] ms 421 ms 441 ms viennal-nbr2.bbnplanet.net [ ] ms 451 ms 420 ms cambridgel-brl.bbnplanet.net [ ] ms 461 ms 441 мс cambridgel-crl4.bbnplanet.net [ Ц мс 461 мс 460 мс attbcstoll.bbnplanet.net [ мс 460 мс 481 мс shutdown.ds.internic.net [ ]

Протокол ICMP Последовательность строк соответствует последовательности маршрутизаторов, образующих маршрут к заданному узлу. Первое число в строке число хопов до соответствующего маршрутизатора. Утилита traceroute тестирует каждый маршрутизатор трижды, поэтому следующие три числа в строке это значения RTT, вычисленные путем посылки трех пакетов, время жизни которых истекло на этом маршрутизаторе. Если ответ от какого - либо маршрутизатора не приходит за заданное время, то вместо времени на экране печатается звездочка (*). Далее идут IP- адрес и доменное имя ( если оно имеется ) маршрутизатора. Видно, что почти все интерфейсы маршрутизаторов поставщиков услуг Интернета зарегистрированы в службе DNS, а первые два, относящиеся к локальным маршрутизатором, нет. Еще раз подчеркнем, что время, указанное в каждой строке, это не время прохождения пакетов между двумя соседними маршрутизаторами, а время, за которое пакет проделывает путь от источника до соответствующего маршрутизатора и обратно. Так как ситуация в Интернете с загрузкой маршрутизаторов постоянно меняется, то время достижимости маршрутизаторов не всегда нарастает монотонно, а может изменяться достаточно произвольным образом.

Список использованных источников В.Г. Олифер, Н.А. Олифер Компьютерные сети, 3-е издание, 2009 г.