Родичев Ю.А. Компьютерные сети - архитектура, технологии, защита

Подождите немного. Документ загружается.

231

Посмотрим снова на рис. 7.3, только на этот раз хост 1 хочет

послать пакет хосту 4 (192.31.63.8). Обращение к ARP не даст ре-

зультата, так как хост 4 не увидит широковещательного пакета

(маршрутизаторы не переправляют широковещательные пакеты

Ethernet-уровня). Решение состоит в том, что хост 1 сразу видит,

что адресат находится в удаленной сети, поэтому он посылает

весь

внешний трафик по Ethernet-адресу, обрабатывающему все

пакеты для удаленных адресатов, то есть маршрутизатору Е3.

Хост 1 помещает IP-пакет в поле полезной нагрузки Ethernet-

кадра, адресованного маршрутизатору ЕЗ. Получив Ethernet-кадр,

маршрутизатор извлекает из поля полезной нагрузки IP-пакет и

ищет его IP-адрес в своих таблицах. Он обнаруживает, что паке-

ты, адресованные сети 192.31.63.0, должны пересылаться

мар-

шрутизатору 192.31.60.7. Если ему еще не известен FDDI-адрес

маршрутизатора 192.31.60.7, то он посылает по кольцу широко-

вещательный ARP-пакет и узнает, что нужный ему адрес F3. За-

тем он помещает IP-пакет в поле полезной нагрузки FDDI-кадра,

адресованного маршрутизатору F3, и отправляет его по кольцу.

Когда кадр попадает на маршрутизатор F3, FDDI-драйвер извле-

кает из поля

полезной нагрузки IP-пакет и передает его IP-

программе, которая видит, что этот пакет следует переслать

192.31.63.8. Если этого IP-адреса еще нет в ARP-кэше, маршрути-

затор посылает широковещательный ARP-запрос по сети Ethernet

и узнает, что нужный ему адрес принадлежит хосту E6, поэтому

он создает Ethernet-кадр, адресованный хосту Е6, помещает IP-

пакет в поле полезной нагрузки

и передает его по сети Ethernet.

Получив Ethernet-кадр, хост 4 извлекает из поля полезной нагруз-

ки IP-пакет и передает его. IP-программе для обработки.

В некоторых случаях возникает обратная задача – нахождение

IP-адреса по известному локальному адресу. Тогда в действие

вступает реверсивный протокол ARP (Reverse Address Resolution

Protocol, RARP). Этот протокол используется, например, при стар-

те бездисковых станций, не

знающих в начальный момент своего

IP-адреса, но знающих МАС-адрес своего сетевого адаптера.

Недостаток протокола RARP заключается в том, что в нем для

обращения к RARP-серверу используется адрес, состоящий из

всех единиц (ограниченное широковещание). Однако эти широ-

232

ковещательные запросы не переправляются маршрутизаторами в

другие сети, поэтому в каждой сети требуется свой RARP-сервер.

Для решения данной проблемы был разработан альтернатив-

ный загрузочный протокол BOOTP. В отличие от RARP он ис-

пользует UDP- сообщения, пересылаемые маршрутизаторами в

другие сети. Он также снабжает бездисковые рабочие станции

дополнительной информацией, включающей IP-адрес файлового

сервера, содержащего

образ памяти, IP-адрес маршрутизатора по

умолчанию, а также маску подсети.

7.4.3. Организация доменов и доменных имен

Для идентификации компьютеров аппаратное и программное

обеспечение в сетях ТСР/IP полагается на IP-адреса, поэтому для

доступа к сетевому ресурсу в параметрах программы вполне дос-

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

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

предпочитают работать с символьными именами компьютеров, и

операционные системы локальных сетей

приучили их к этому

удобному способу. Следовательно, в сетях ТСР/IP должны суще-

ствовать символьные имена хостов и механизм для установления

соответствия между символьными именами и IP-адресами.

В операционных системах, которые первоначально разраба-

тывались для работы в локальных сетях, таких как Novell

NetWare, Microsoft Windows или IBM OS/2, пользователи всегда

работали с символьными именами компьютеров. Так как

локаль-

ные сети состояли из небольшого числа компьютеров, то исполь-

зовались так называемые плоские имена, состоящие из последо-

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

ния соответствия между символьными именами и МАС- адреса-

ми в этих операционных системах применялся механизм широко-

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

ARP. Так, широковещательный

способ разрешения имен реали-

зован в протоколе NetBIOS, на котором были построены многие

локальные ОС. Так называемые NetBIOS-имена стали на долгие

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

Для стека ТСР/IP, рассчитанного в общем случае на работу в

больших территориально распределенных сетях, подобный под-

233

ход оказывается неэффективным по нескольким причинам. Пло-

ские имена не дают возможности разработать единый алгоритм

обеспечения уникальности имен в пределах большой сети. В не-

больших сетях уникальность имен компьютеров обеспечивает

администратор сети, записывая несколько десятков имен в жур-

нале или файле. При росте сети задачу решают уже несколько

администраторов, согласовывая имена

между собой неформаль-

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

или странах, то администраторам каждой части сети нужно при-

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

на новым компьютерам независимо от других администраторов,

обеспечивая в то же время уникальность имен во всей сети. Са-

мым надежным

способом решения этой задачи является отказ от

плоских имен.

В сети ARPANET соответствие текстовых и двоичных адресов

просто записывалось в файле hosts. txt, в котором перечислялись

все хосты и их IP-адреса. Каждую ночь все хосты получали этот

файл с сайта, на котором тот хранился. В сети, состоящей из не-

скольких сот больших машин

, работающих под управлением сис-

темы с разделением времени, такой подход работал вполне не-

плохо. Однако когда к сети были подключены тысячи рабочих

станций, всем стало ясно, что этот способ не сможет работать

вечно. Во-первых, размер файла стал слишком большим. Однако,

что еще важнее, если управление именами хостов не будет

осу-

ществляться централизованно, неизбежно возникновение кон-

фликтов имен. В то же время представить себе централизованное

управление именами всех хостов гигантской международной сети

довольно сложно.

Управление большим и постоянно изменяющимся набором

имен представляет собой нетривиальную проблему. В почтовой

системе на письмах требуется указывать (явно или неявно) стра-

ну, область, город, улицу, номер

дома, квартиру и фамилию по-

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

не возникает путаницы между Ивановым Иваном Ивановичем,

живущим в Самаре и Ивановым Иваном Ивановичем, живущим в

Москве.

Для разрешения проблем с адресацией в глобальной сети была

разработана аналогичная служба имен доменов DNS (Domain

234

Name System). Суть системы DNS заключается в иерархической

схеме имен, основанной на доменах, и распределенной базе дан-

ных, реализующей эту схему имен. В первую очередь эта система

используется для преобразования имен хостов и пунктов назна-

чения электронной почты в IP-адреса, но также может использо-

ваться и в других целях. В настоящее время система DNS

являет-

ся одним из важнейших компонентов инфраструктуры Интернет.

Интернет концептуально разделен на 200 доменов верхнего

уровня. Доменами называют в Интернете множество хостов, объ-

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

подразделяется на поддомены, которые, в свою очередь, также

могут состоять из других доменов, и т.д. Все эти домены можно

рассматривать

в виде дерева. Каждый домен управляет доступом

к доменам, расположенным под ним.

Домены верхнего уровня разделяются на две группы: родовые

домены и домены государств. К родовым относятся домены: com

(commercial – коммерческие организации), edu (educational –

учебные заведения), gov (government – федеральное правительст-

во США), int (international – определенные международные орга-

низации), mil (military – вооруженные силы, net (network – сете-

вые

операторы связи) и org (некоммерческие организации). За

каждым государством в соответствии с международным стандар-

том ISO 3166 закреплен один домен государства.

Решение о введении первых доменов верхнего уровня общего

назначения COM, EDU, GOV, MIL, ORG, NET, INT было принято

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

DNS и реализован первый сервер доменных имен. В 1985 году

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

имена (поддомены) в

зоне COM.

В ноябре 2000 года было утверждено 4 новых родовых имени

доменов верхнего уровня, а именно: biz (бизнес), info (информа-

ция), name (имена людей) и pro (специалисты, такие как доктора и

адвокаты). Кроме того, по просьбе соответствующих отраслевых

организаций были введены еще три специализированных имени

доменов верхнего уровня: aero (аэрокосмическая

промышлен-

ность), соoр (кооперативы) и museum (музеи). К концу 2004 года в

зоне COM было зарегистрировано около 33 млн доменных имен, а

во всех доменах верхнего уровня около 63 млн имен.

235

В будущем появятся и другие домены верхнего уровня. Меж-

ду прочим, по мере коммерциализации Интернета появляется все

больше спорных вопросов. Взять хотя бы домен pro. Он предна-

значен для сертифицированных специалистов. Но кто является

специалистом, а кто нет? Кем должны быть эти специалисты сер-

тифицированы? Понятно, что доктора и адвокаты это

профессио-

налы. А что делать со свободными художниками, учителями му-

зыки, водопроводчиками, парикмахерами, мусорщиками? Имеют

ли право квалифицированные представители всех этих и многих

других профессий получать домены pro? Если да, то кто выдаст

сертификат каждому из этих специалистов? В принципе, полу-

чить домен второго уровня типа пате-of-company. com не сложно.

Надо лишь

проверить, не занято ли желаемое имя домена кем-то

другим и не является ли оно чьей-нибудь торговой маркой. Для

этого надо зайти на сайт регистрационного бюро верхнего уровня

(в данном случае com). Если все в порядке, заказчик регистриру-

ется и за небольшую ежегодную абонентскую плату получает

домен второго уровня

Имя каждого домена, подобно полному пути к файлу в файло-

вой системе, состоит из пути от этого домена до вершины дерева.

Компоненты пути разделяются точками. Имена доменов не чув-

ствительны к изменению регистра символов. Так, например, edu

и EDU означают одно и то же. Длина имен компонентов может

достигать 63 символов, а длина

полного пути не должна превос-

ходить 255 символов. На практике, почти все организации в

США помещаются под родовыми доменами, тогда как почти все

организации за пределами Соединенных Штатов располагаются

под доменами их государств.

Структура доменов отражает не физическое состояние сети, а

логическое разделение между организациями и их подразделе-

ниями.

В общих

чертах система DNS применяется следующим обра-

зом. Для преобразования имени в IP-адрес прикладная программа

обращается к библиотечной процедуре, называющейся распо-

знавателем, передавая ей имя в качестве параметра. Распознава-

тель посылает IР-пакет локальному DNS-серверу, который ищет

имя в базе данных и возвращает соответствующий IP-адрес рас-

познавателю, который, в свою очередь, передает его

вызывавшей

236

его прикладной программе. Имея IP- адрес, программа может ус-

тановить ТСР-соединение с адресатом или послать ему UDP-

пакеты.

Теоретически один сервер мог бы содержать всю базу данных

DNS и отвечать на все запросы к ней. На практике этот сервер

оказался бы настолько перегруженным, что был бы просто бес-

полезным. Более того, если

бы его когда-либо выключили, то

весь Интернет оказался бы неработоспособен. Чтобы избежать

проблем, связанных с хранением всей информации в одном мес-

те, пространство имен DNS разделено на непересекающиеся зо-

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

нее входят серверы имен, хранящие управляющую информацию

об этой зоне. Обычно в

каждой зоне находится один основной

сервер зоны, получающий информацию из файла на своем диске,

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

информацию от основного сервера имен. Для большей надежно-

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

за пределами самой зоны. Где провести границы зон, целиком за-

висит от администратора зоны.

Это решение основывается на

том, сколько серверов имен требуется в той или иной зоне.

Распознаватель обращается с запросом разрешения имени до-

мена к одному из локальных серверов имен. Если искомый домен

относится к сфере ответственности данного сервера имен, тогда

данный DNS-сервер сам отвечает распознавателю на его запрос.

Однако если домен удаленный

и информацию о запрашиваемом

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

ние с запросом серверу домена верхнего уровня запрашиваемого

домена.

Служба DNS использует текстовые файлы почти такого фор-

мата, как и файл hosts, и эти файлы администратор также подго-

тавливает вручную. Однако служба DNS опирается на иерархию

доменов, и каждый

сервер службы DNS хранит только часть имен

сети, а не все имена, как это происходит при использовании фай-

лов hosts. При росте количества узлов в сети проблема масшта-

бирования решается созданием новых доменов и поддоменов

имен и добавлением в службу DNS новых серверов.

Для каждого домена имен создается свой DNS-сервер. Каж-

дый DNS-сервер

кроме таблицы отображений имен содержит

237

ссылки на DNS-серверы своих поддоменов. Эти ссылки связыва-

ют отдельные DNS-серверы в единую службу DNS. Ссылки

представляют собой IP-адреса соответствующих серверов. Для

обслуживания корневого домена выделено несколько дублирую-

щих друг друга DNS-серверов, IP-адреса которых являются ши-

роко известными (их можно узнать, например, в InterNIC).

Процедура разрешения DNS-имени во многом аналогична

процедуре поиска файловой

системой адреса файла по его сим-

вольному имени. Действительно, в обоих случаях составное имя

отражает иерархическую структуру организации соответствую-

щих справочников – каталогов файлов или таблиц DNS. Здесь

домен и доменный DNS-сервер являются аналогом каталога фай-

ловой системы. Для доменных имен, так же как и для символь-

ных имен файлов, характерна независимость

именования от фи-

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

символьному имени заключается в последовательном просмотре

каталогов, начиная с корневого. Для определения IP-адреса по

доменному имени также необходимо просмотреть все DNS-

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

хоста, начиная с корневого домена. Существенным отличием яв-

ляется то, что файловая система расположена

на одном компью-

тере, а служба DNS по своей природе является распределенной.

История российского сегмента доменных имен начинается с

1994 года, когда появился национальный домен RU. Управление

национальным доменом было передано Российскому НИИ Обще-

ственных Сетей (РосНИИРОС). На конец 2004 года в домене RU

165822 компаниями и частными лицами было зарегистрировано

305339 доменов (http://www. nic. ru). Распределение доменов по

территории России (федеральным округам) следующее: Цен-

тральный – 63.17%, Северо-Западный – 10.16%, Приволжский –

4.43%, Сибирский – 4.21%, Уральский – 3.56%, Южный – 3.06%,

Дальневосточный – 1.31%. Более половины доменов (54.2%) за-

регистрировано в Москве и Московской области, в Санкт-

Петербурге – 8.7%, в Свердловской области – 2.3%, Новосибир-

ской – 1.9%, Самарской – 1.3%. По итогам 2004года и начала

2005 года наблюдается тенденция снижения доли Центрального

федерального округа и повышение доли

остальных округов. В

последние годы наблюдается увеличение чила регистраций рос-

238

сийских организаций в международных доменах COM, NET,

ORG. К концу 2004 года число таких регистраций достигла 29%

от общего количества регистраций в зоне RU.

7.4.4. Протокол внутреннего шлюза OSPF

Сеть Интернет состоит из большого количества автономных

систем (подсетей). Каждая автономная система управляется сво-

ей организацией и может использовать внутри свой алгоритм

маршрутизации. Алгоритм маршрутизации внутри автономной

системы называется протоколом внутреннего шлюза.

Алгоритм маршрутизации между автономными системами назы-

вается протоколом внешнего шлюза.

Алгоритм маршрутизации внутри автономной системы введен

с 1990 года

и называется OSPF (Open Shortest Path First – откры-

тый алгоритм предпочтительного выбора кратчайшего маршру-

та). В ближайшем будущем он, скорее всего, станет главным про-

токолом внутреннего шлюза. При разработке протокола стави-

лись ряд требований, которые необходимо было удовлетворить.

Во-первых, этот алгоритм должен был быть напечатан в откры-

той литературе, откуда буква «О» (Open – открытый

) в OSPF. Во-

вторых, новый протокол должен был уметь учитывать широкий

спектр различных параметров, включая физическое расстояние,

задержку и т.д. В-третьих, этот алгоритм должен был быть дина-

мическим, автоматически и быстро адаптирующимся к измене-

ниям топологии. В-четвертых, он должен был поддерживать вы-

бор маршрутов, основываясь на типе сервиса.

Новый протокол

должен был уметь по-разному выбирать маршрут для трафика

реального времени и для других видов трафика. IP-пакет содер-

жит поле «Тип службы», но ни один из имеющихся протоколов

маршрутизации не использовал его. В-пятых, новый протокол

должен был уметь распределять нагрузку на линии. Большинство

предыдущих протоколов посылало все пакеты

по одному лучше-

му маршруту. Следующий по оптимальности маршрут не исполь-

зовался совсем. Во многих случаях распределение нагрузки по

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

необходима поддержка иерархических систем.

239

К 1988 г. Интернет вырос настолько, что ни один маршрути-

затор не мог вместить сведения о его полной топологии.

Протокол OSPF поддерживает три следующих типа соедине-

ний и сетей:

1. Двухточечные линии, соединяющие два маршрутизатора.

2. Сети множественного доступа с широковещанием (то есть

большинство локальных сетей).

3. Сети множественного доступа без широковещания (то есть

большинство глобальных сетей с коммутацией пакетов).

Сеть множественного доступа – это сеть, у которой может

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

другом напрямую. Этим свойством обладают все локальные и

глобальные сети. В основе работы протокола OSPF лежит пред-

ставление о множестве сетей, маршрутизаторов и линий в виде

направленного графа, в котором каждой

дуге поставлена в соот-

ветствие ее цена (расстояние, задержка и т.д.). Затем, основыва-

ясь на весе дуг, алгоритм вычисляет кратчайший путь. На рис. 7.4

показана автономная система, содержащая все три типа сетей и ее

представление в виде ориентированного графа.

Многие автономные системы в Интернете сами также доволь-

но велики, и

управлять ими не просто. Протокол OSPF позволяет

делить их на пронумерованные области, то есть на сети или мно-

жества смежных сетей. У каждой автономной системы есть маги-

стральная область. Все области соединены с магистралью. Каж-

дый маршрутизатор, соединенный с двумя и более областями, яв-

ляется частью магистрали. Работа маршрутизаторов заключается

расчете кратчайшего пути от себя до всех остальных маршрути-

заторов этой области, включая маршрутизатор, соединенный с

магистралью, который обязательно должен иметься в области,

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

отдельно.

Протокол OSPF различает четыре класса маршрутизаторов.

1. Внутренние маршрутизаторы, расположенные целиком

внутри области.

2. Маршрутизаторы границы области, соединяющие две

и бо-

лее областей.

3. Магистральные маршрутизаторы, находящиеся на магист-

рали.

240

4. Маршрутизаторы границы автономной системы, общаю-

щиеся с маршрутизаторами других автономных систем.

Рис. 7.4. Автономная система и её представление ориентирован-

ным графом

Эти классы могут перекрываться. Например, все пограничные

маршрутизаторы автоматически являются магистральными.

В OSPF процесс построения таблицы маршрутизации разби-

вается на два крупных этапа. На первом этапе каждый маршрути-

затор строит граф связей сети, в котором вершинами графа явля-

ются маршрутизаторы и IP-сети,

а ребрами интерфейсы маршру-

тизаторов. Все маршрутизаторы для этого обмениваются со

своими соседями той информацией о графе сети (топологии), ко-

торой они располагают к данному моменту времени. Подобные

сообщения называются router links advertisement – объявление о

связях маршрутизатора. Кроме того, при передаче топологиче-

ской информации маршрутизаторы ее не модифицируют, как это