Протокол IP

Автор: Пользователь скрыл имя, 23 Февраля 2012 в 08:16, курсовая работа

Краткое описание

Стек протоколов TCP/IP тесно связан с сетью Internet, ее историей и современностью. Создан он был в 1969 году, когда для сети ARPANET понадобился ряд стандартов для объединения в единую сеть компьютеров с различными архитектурами и операционными системами. На базе этих стандартов и был разработан набор протоколов, получивших название TCP/IP. Вместе с ростом Internet протокол TCP/IP завоевывал позиции и в других сетях. На сегодняшний день этот сетевой протокол используется как для связи компьютеров всемирной сети, так и в подавляющем большинстве корпоративных сетей.

Файлы: 1 файл

Сети.doc

— 354.50 Кб (Скачать)

 

                  Рисунок 3 - Пространство доменных имен

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

Разделение административной ответственности позволяет решить проблему об­разования уникальных имен без взаимных консультаций между организация­ми, отвечающими за имена одного уровня иерархии. Очевидно, что должна существовать одна организация, отвечающая за назначение имен верхнего уровня иерархии. Совокупность имен, у которых несколько старших составных частей совпадают, образуют домен {domain) имен. Например, имена www1.zil.mmt.ru, ftp.zil.mmt.ru, yauidex.ru и s1 .mgu.ru входят в домен ru, так как все эти имена имеют одну общую старшую часть — имя ru. Другим примером является домен mgu.ru. Из представ­ленных на рис. 3 имен в него входят имена s1.mgu.ru, s2.mgu.ru и rn.mgu.ru. Этот домен образуют имена, у которых две старшие части всегда равны mgu.ru. Имя www.mmt.ru в домен mgu.ru не входит, так как имеет отличающуюся состав­ляющую mmt.Если один домен входит в другой домен как его составная часть, то такой домен могут называть поддоменом (subdomain), хотя название домен за ним также оста­ется. Обычно поддомен называют по имени той его старшей составляющей, ко­торая отличает его от других поддоменов. Например, поддомен mmt.ru обычно называют поддоменом (или доменом) mmt. Имя поддомену назначает админист­ратор вышестоящего домена. Хорошей аналогией домена является каталог фай­ловой системы. Если в каждом домене и поддомене обеспечивается уникальность имен следую­щего уровня иерархии, то и вся система имен будет состоять из уникальных имен.

По аналогии с файловой системой в доменной системе имен различают краткие имена, относительные имена и полные доменные имена. Краткое имя — это имя конечного узла сети: хоста или порта маршрутизатора. Краткое имя — это лист дерева имен. Относительное имя — это составное имя, начинающееся с некото­рого уровня иерархии, но не самого верхнего. Например, wwwl.zil — это относи­тельное имя. Полное доменное имя (fully qualified domain name, FQDN) включает составляющие всех уровней иерархии, начиная от краткого имени и кончая кор­невой точкой: wwwl .zil.mmt.ru.Корневой домен управляется центральными органами Интернета: IANA и InterNIC. Домены верхнего уровня назначаются для каждой страны, а также на организационной основе. Имена этих доменов должны следовать международно­му стандарту ISO 3166. Для обозначения стран используются трехбуквенные и двухбуквенные аббревиатуры, например, ru (Россия), uk (Великобритания), fin (Финляндия), us (Соединенные Штаты), а для различных типов организаций — следующие обозначения:

  com — коммерческие организации (например, microsoft.com);

  edu — образовательные организации (например, mit.edu);

  gov — правительственные организации (например, nsf.gov);

  org — некоммерческие организации (например, fidonet.org);

  net — организации поддержки сетей (например, nsf.net).

Каждый домен администрируется отдельной организацией, которая обычно раз­бивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Чтобы получить доменное имя, необходимо зарегистрироваться в какой-либо организации, которой организация InterNIC делегировала свои полномочия по распределению имен доменов. В России такой организацией является РосНИИРОС, которая отвечает за делегирование имен поддоменов в домене ru. Необходимо подчеркнуть, что компьютеры входят в домен в соответствии со своими составными именами, при этом они могут иметь абсолютно независимые друг от друга IP-адреса, принадлежащие к различным сетям и подсетям. Напри­мер, в домен mgu.ru могут входить хосты с адресами 132.13.34.15, 201.22.100.33 и 14.0.0.6.

Доменная система имен реализована в Интернете, но она может работать и как автономная система имен в любой крупной корпоративной сети, которая также использует стек TCP/IP, но никак не связана с Интернетом.

 

1.4 Автоматизация процесса порядка назначения IP-адресов узлами сети протокол DHCP

 

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

В больших сетях, подобных Интернету, уникальность сетевых адресов гаранти­руется централизованной, иерархически организованной системой их распреде­ления. Главным органом регистрации глобальных адресов в Интернете с 1998 года является ICANN (Internet Corporation for Assigned Names and Numbers) — непра­вительственная некоммерческая организация, управляемая советом директоров. Эта организация координирует работу региональных отделов, деятельность ко­торых охватывает большие географические площади: ARIN (Америка), RIPE (Европа), APNIC (Азия и Тихоокеанский регион). Региональные отделы выде­ляют блоки адресов сетей крупным поставщикам услуг, те, в свою очередь при­сваивают их своим клиентам, среди которых могут быть ц более мелкие постав­щики услуг.

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

 

Рисунок 4 - Нерациональное использование пространства IP-                                                                

                                             адресов     

 

Если же некоторая IP-сеть создана для работы в «автономном режиме», без свя­зи с Интернетом, тогда администратор этой сети волен назначить ей произволь­но выбранный номер. Но и в этой ситуации для того, чтобы избежать каких-либо коллизий, в стандартах Интернета определено несколько адресов, рекомендуе­мых для автономного использования: в классе А — это сеть 10.0.0.0, в классе В — это диапазон из 16 номеров сетей 172.16.0.0-172.31.0.0, в классе С — это диапа­зон из 255 сетей

192.168.0,0-192.168.255.0. Подробнее о том, как использование данных зарезервированных адресов позволяет справляться с дефицитом сетевых адресов, читайте в разделе «Трансляция сетевых адресов» главы .

Для смягчения проблемы дефицита адресов разработчики стека TCP/IP предла­гают разные подходы. Принципиальным решением является переход на новую версию IPv6, в которой резко расширяется адресное пространство за счет исполь­зования 16-байтных адресов. Однако и текущая версия IPv4 поддерживает неко­торые технологии, направленные на более экономное расходование IP-адресов. Одной из таких технологий является технология бесклассовой междоменной маршрутизации (Classless Inter-Domain Routing, CIDR). Технология CIDR осно­вана на масках, она отказывается от традиционной концепции разделения адре­сов протокола IP на классы, что позволяет выдавать в пользование столько адре­сов, сколько реально необходимо потребителю. Благодаря CIDR поставщик услуг получает возможность «нарезать» блоки из выделенного ему адресного пространства в точном соответствии с требованиями каждого клиента. Как уже было сказано, IP-адреса могут назначаться администратором сети вручную. Это представляет для администратора утомительную процедуру. Ситуация усложняется еще тем, что многие пользователи не обладают достаточными знаниями для того, чтобы конфигурировать свои компьютеры для работы в интерсети и должны поэтому полагаться на администраторов. Протокол Dynamic Host Configuration Protocol (DHCP) был разработан для того, чтобы освободить администратора от этих проблем. Основным назначением DHCP является динамическое назначение IP-адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов. В ручной процедуре назначения адресов активное участие принимает администратор, который предоставляет DHCP-серверу информацию о соответствии IP-адресов физическим адресам или другим идентификаторам клиентов. Эти адреса сообщаются клиентам в ответ на их запросы к DHCP-серверу. При автоматическом статическом способе DHCP-сервер присваивает IP-адрес (и, возможно, другие параметры конфигурации клиента) из пула наличных IP-адресов без вмешательства оператора. Границы пула назначаемых адресов задает администратор при конфигурировании DHCP-сервера. Между идентификатором клиента и его IP-адресом по-прежнему, как и при ручном назначении, существует постоянное соответствие. Оно устанавливается в момент первичного назначения сервером DHCP IP-адреса клиенту. При всех последующих запросах сервер возвращает тот же самый IP-адрес. При динамическом распределении адресов DHCP-сервер выдает адрес клиенту на ограниченное время, что дает возможность впоследствии повторно использовать IP-адреса другими компьютерами. Динамическое разделение адресов позволяет строить IP-сеть, количество узлов в которой намного превышает количество имеющихся в распоряжении администратора IP-адресов. DHCP обеспечивает надежный и простой способ конфигурации сети TCP/IP, гарантируя отсутствие конфликтов адресов за счет централизованного управления их распределением. Администратор управляет процессом назначения адресов с помощью параметра "продолжительности аренды" (lease duration), которая определяет, как долго компьютер может использовать назначенный IP-адрес, перед тем как снова запросить его от сервера DHCP в аренду. Примером работы протокола DHCP может служить ситуация, когда компьютер, являющийся клиентом DHCP, удаляется из подсети. При этом назначенный ему IP-адрес автоматически освобождается. Когда компьютер подключается к другой подсети, то ему автоматически назначается новый адрес. Ни пользователь, ни сетевой администратор не вмешиваются в этот процесс. Это свойство очень важно для мобильных пользователей. Протокол DHCP использует модель клиент-сервер. Во время старта системы компьютер-клиент DHCP, находящийся в состоянии "инициализация", посылает сообщение discover (исследовать), которое широковещательно распространяется по локальной сети и передается всем DHCP-серверам частной интерсети. Каждый DHCP-сервер, получивший это сообщение, отвечает на него сообщением offer (предложение), которое содержит IP-адрес и конфигурационную информацию. Компьютер-клиент DHCP переходит в состояние "выбор" и собирает конфигурационные предложения от DHCP-серверов. Затем он выбирает одно из этих предложений, переходит в состояние "запрос" и отправляет сообщение request (запрос) тому DHCP-серверу, чье предложение было выбрано. Выбранный DHCP-сервер посылает сообщение DHCP-acknowledgment (подтверждение), содержащее тот же IP-адрес, который уже был послан ранее на стадии исследования, а также параметр аренды для этого адреса. Кроме того, DHCP-сервер посылает параметры сетевой конфигурации. После того, как клиент получит это подтверждение, он переходит в состояние "связь", находясь в котором он может принимать участие в работе сети TCP/IP. Компьютеры-клиенты, которые имеют локальные диски, сохраняют полученный адрес для использования при последующих стартах системы. При приближении момента истечения срока аренды адреса компьютер пытается обновить параметры аренды у DHCP-сервера, а если этот IP-адрес не может быть выделен снова, то ему возвращается другой IP-адрес. В протоколе DHCP описывается несколько типов сообщений, которые используются для обнаружения и выбора DHCP-серверов, для запросов информации о конфигурации, для продления и досрочного прекращения лицензии на IP-адрес. Все эти операции направлены на то, чтобы освободить администратора сети от утомительных рутинных операций по конфигурированию сети. Однако использование DHCP несет в себе и некоторые проблемы. Во-первых, это проблема согласования информационной адресной базы в службах DHCP и DNS. Как известно, DNS служит для преобразования символьных имен в IP-адреса. Если IP-адреса будут динамически изменятся сервером DHCP, то эти изменения необходимо также динамически вносить в базу данных сервера DNS. Хотя протокол динамического взаимодействия между службами DNS и DHCP уже реализован некоторыми фирмами (так называемая служба Dynamic DNS), стандарт на него пока не принят. Во-вторых, нестабильность IP-адресов усложняет процесс управления сетью. Системы управления, основанные на протоколе SNMP, разработаны с расчетом на статичность IP-адресов. Аналогичные проблемы возникают и при конфигурировании фильтров маршрутизаторов, которые оперируют с IP-адресами. Наконец, централизация процедуры назначения адресов снижает надежность системы: при отказе DHCP-сервера все его клиенты оказываются не в состоянии получить IP-адрес и другую информацию о конфигурации. Последствия такого отказа могут быть уменьшены путем использовании в сети нескольких серверов DHCP, каждый из которых имеет свой пул IP-адресов.   Как уже отмечалось, в адресной схеме протокола выделяют особые IP-адреса. Если биты всех октетов адреса равны нулю, то он обозначает адрес того узла, который сгенерировал данный пакет. Это используется в ограниченных случаях, например в некоторых сообщениях протокола IP. Если биты сетевого префикса равны нулю, полагается, что узел назначения принадлежит той же сети, что и источник пакета. Когда биты всех октетов адреса назначения равны двоичной единице, пакет доставляется всем узлам, принадлежащим той же сети, что и отправитель пакета. Такая рассылка называется ограниченным широковещанием. Наконец, если в битах адреса, соответствующих узлу назначения, стоят единицы, то такой пакет рассылается всем узлам указанной сети. Это называется широковещанием. Специальное значение имеет, так же, адреса сети 127/8. Они используются для тестирования программ и взаимодействия процессов в пределах одной машины. Пакеты, отправленные на этот интерфейс, обрабатываются локально, как входящие. Потому адреса из этой сети нельзя присваивать физическим сетевым интерфейсам.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 ОРГАНИЗАЦИЯ ПОДСЕТЕЙ

 

  Очень редко в локальную вычислительную сеть входит более 100-200 узлов: даже если взять сеть с большим количеством узлов, многие сетевые среды накладывают ограничения, например, в 1024 узла. Исходя из этого, целесообразность использования сетей класса А и В весьма сомнительна. Да и использование класса С для сетей, состоящих из 20-30 узлов, тоже является расточительством. Для решения этих проблем в двухуровневую иерархию IP-адресов (сеть -- узел) была введена новая составляющая -- подсеть. Идея заключается в "заимствовании" нескольких битов из узловой части адреса для определения подсети. Полный префикс сети, состоящий из сетевого префикса и номера подсети, получил название расширенного сетевого префикса. Двоичное число, и его десятичный эквивалент, содержащее единицы в разрядах, относящихся к расширенному сетевому префиксу, а в остальных разрядах -- нули, назвали маской подсети. Но маску в десятичном представлении удобно использовать лишь тогда, когда расширенный сетевой префикс заканчивается на границе октетов, в других случаях ее расшифровать сложнее. Допустим, что мы хотели бы для подсети использовать не 8 бит, а десять. Тогда в последнем (z-ом) октете мы имели бы не нули, а число 11000000. В десятичном представлении получаем 255.255.255.192. Очевидно, что такое представление не очень удобно. В наше время чаще используют обозначение вида "/xx", где хх -- количество бит в расширенном сетевом префиксе. Таким образом, вместо указания: "144.144.19.22 с маской 255.255.255.192", мы можем записать: 144.144.19.22/26. Как видно, такое представление более компактно и понятно.

 

2.1 Маска под сети переменной длины (Variable Length Subnet Mask)

 

Однако вскоре стало ясно, что подсети, несмотря на все их достоинства, обладают и недостатками. Так, определив однажды маску подсети, приходится использовать подсети фиксированных размеров. Скажем, у нас есть сеть 144.144.0.0/16 с расширенным префиксом /23.

    Таблица 3 - С расширенный префикс

 

 

Сетевой префикс

Подсеть

Узел

144.144.0.0/23

    <-->

  10010000

10010000

   0000000

0       00000000

 

 

   Расширенный сетевой префикс

 

Информация о работе Протокол IP