69578

Курс Internet Protocol

Практическая работа

Информатика, кибернетика и программирование

Способы передачи информации в компьютерных сетях были рассмотрены в курсе Локальные сети при этом для описания использовались первые два уровня модели OSI физический и канальный образующих базовую сетевую технологию БСТ.

Русский

2014-10-07

458 KB

2 чел.

Курс Internet Protocol

Урок № 1

 Введение

Объектом изучения курса «Internet Protocol» являются методы взаимодействия в составных сетях. Под составной сетью понимают множество взаимосвязанных сетей, образующих единое информационное пространство.  Способы передачи информации в компьютерных сетях были рассмотрены в курсе «Локальные сети», при этом, для описания использовались первые два уровня модели OSI – физический и канальный, образующих базовую сетевую технологию (БСТ). Взаимодействие в составных сетях осуществляется на третьем уровне модели – сетевом.

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

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

Рассмотрим их на примере сети Ethernet с бесконечно большим количеством участников:

  •  Длительность построения таблицы коммутатора. Если узлов очень много, то коммутаторы будут самообучаться вечно. При этом размер таблицы будет бесконечно большим, что требует дополнительное количество памяти.
  •  Так как размер таблиц коммутатора очень велик, то время поиска в таблице будет очень большим, что приведет к непроизводительной работе коммутатора.
  •  Пока коммутатор самообучается, трафик передается методом флудинга, таким образом, сеть будет затапливаться обычным трафиком до окончания процесса самообучения, а из вышесказанного следует, что этот процесс никогда не закончится.
  •  Даже если предположить, что затопления сети обычным трафиком можно было бы избежать, остается широковещательный трафик, который всегда передается коммутатором методом флудинга. Если одна из станций вследствие чего бы то ни было (программной или аппаратной неисправности, воздействия вируса и т.д.) начнет генерировать интенсивный широковещательный трафик, то это полностью парализует гигантскую сеть. Такая ситуация называется «широковещательный шторм».
  •  В обычных условиях каждый узел сети генерирует небольшой объем широковещательного трафика, но трафик каждого узла при этом достигает всех узлов, а каждого узла достигает трафик всех узлов, таким образом, при большом числе узлов сеть снова затапливается широковещательным трафиком (притом, что неисправности в работе узлов нет). Такую ситуацию можно назвать «широковещательный шум».
  •  Необходимо строить топологии без петель, так как коммутаторы в топологии с петлями не могут работать. (происходит зацикливание кадров между коммутаторами).
  •  На канальном уровне сложно и нефункционально управлять трафиком, настраивая правила фильтрации кадров в коммутаторе.
  •  В гигантской сети могут применяться различные канальные технологии: Ethernet, Token Ring, ppp, Frame Relay, трансляция одного канального протокола в другой не всегда возможно и не всегда удобна.

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

  •  Вечное самообучение коммутаторов. Эту проблему формально можно преодолеть, вручную составив соответствующие таблицы коммутации. Во-первых, это требует применения только управляемых коммутаторов, поддерживающих функцию ручного создания таблиц коммутации. Но это не главное! Главное – это означает, что для КАЖДОГО коммутатора необходимо внести в таблицу руками администратора записи обо ВСЕХ узлах гигантской сети, так как в таблицах коммутации присутствуют адреса каждого хоста в отдельности! Это явно непосильная задача! Усугубляется это тем, что при смене любого адаптера в сети в таблицы всех коммутаторов необходимо вносить изменения, так как в таблицах коммутации фигурируют МАС адреса узлов, которые назначаются производителем сетевого адаптера. Очевидно, что такое решение абсолютно не приемлемо из-за нереально огромного количества ручной работы, которую, кроме того, нельзя выполнить лишь однажды – добавление новых узлов (или замена адаптера в существующих) в любом месте такой сети требует внесения изменений в таблицы коммутации всех коммутаторов. Вывод: корень проблемы в самом принципе работы коммутатора и сделать с этим просто нечего, кроме того, плохо, что в таблицах коммутации фигурируют адреса отдельных хостов и что эти адреса назначаются производителем адаптера.
  •  Огромный размер таблиц коммутации. С этим совершенно ничего нельзя сделать, причина снова таки в самом принципе работы коммутатора, который оперируют «маршрутами» к отдельным хостам, а их (хостов) – много. Просто необходимо снабжать коммутаторы огромным объемом памяти, что, конечно же, очень дорого.  
  •  Поиск в таблице коммутации. С этим, очевидно, тоже ничего нельзя сделать, кроме как снабжать коммутаторы очень быстрыми процессорами и, что самое главное, очень быстрой памятью. Причина, как и прошлом примере в самом принципе работы коммутатора, который оперируют «маршрутами» к отдельным хостам.
  •  Флудинг в процессе самообучения. Если избежать самого процесса самообучения, то и этой проблемы удастся избежать.
  •  Борьба с «широковещательным штормом». Не перенаправлять  широковещательный трафик коммутатор не может – узлы пользуются им, на базе широковещания работают многие сетевые технологии верхних уровней, так что остается лишь пытаться бороться именно со штормами. Ранее мы рассматривали возможный метод борьбы – технологию Broadcast storm control, которая, по сути, очень проста – коммутатор просто конфигурируется таким образом, чтобы не перенаправлять более чем некоторое пороговое количество широковещательных кадров в единицу времени на некоторый порт (или не принимать с некоторого порта). Однако такой метод весьма посредственен: коммутатор не может отделить кадры, вызывающие «шторм» от других широковещательных кадров, поэтому при возникновении «шторма» будет страдать и нужный широковещательный трафик, что отрицательно скажется на работе технологий верхнего уровня, пользующихся широковещанием. И снова таки, для применения этой технологии все коммутаторы сети должны быть управляемыми. Вывод: причина – в самом принципе работы коммутатора, который перенаправляет широковещательный трафик на все порты.
  •  Борьба с «широковещательным шумом». Это очень большая проблема – действительно, единственное, что здесь можно предложить, это все тот же Broadcast storm control. Но при этом страдать будет заведомо нужный трафик, что, вероятно, значительно ухудшит работу тех протоколов и служб верхних уровней, которые опираются на широковещание. С широковещательным шумом фактически нельзя бороться, необходимо устранить причину, к нему приводящую, (а причина – в самом принципе работы коммутатора, который перенаправляет широковещательный трафик на все порты), а устранить ее как выше говорилось – нельзя.
  •  Топологии без петель. Эта проблема относительно легко решается применением технологии Spanning Tree, однако это означает, что все коммутаторы в сети должны быть управляемыми и поддерживать STA.
  •  Управление трафиком. Это очевидно не главное для функционирования сети, но весьма важно для организации безопасной работы сети, что, в конечном счете, тоже влияет на нормальное функционирование.
  •  Различные канальные технологии. В предыдущих курсах мы рассматривали возможность транслировать кадры IEEE 802 друг в друга или передавать их, например, поверх PPP. Но это не всегда удобно или даже возможно, кроме того, требует достаточно сложных коммутаторов, да еще и может выполняться неоднозначно. В целом это не главная проблема, но тоже, тем не менее, проблема.
  •  Привязка адреса хоста к сетевому адаптеру. Эту проблему можно решить некоторой службой сопоставления имен, так что эта проблема не особо страшна, однако в базы сопоставлений придется вносить новую информацию при добавлении новых узлов и замене сетевых адаптеров в уже существующих узлах.

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

  1.  Строить огромные сети как совокупности небольших сетей, работающих на известных нам принципах канального уровня, в которых перечисленные выше недостатки не мешают нормальному сетевому взаимодействию.
  2.  Соединять эти сети между собой с помощью следующих принципов: следует адресовать не каждый узел в отдельности, а группировать узлы, это позволит в таблицах перенаправлений промежуточных устройств иметь «маршруты» к группам, что уменьшит число записей в таблицах, снизит нагрузку на аппаратные ресурсы промежуточных устройства, увеличит скорость работы с этими таблицами, сделает потенциально возможным и не слишком обременительным ручное построение таких таблиц. Очевидно, что подобную группировку узлов можно осуществить на основе принадлежности к той или иной канальной сети. Вышесказанное означает, что сети (в привычном понимании этого слова, канальные сети) необходимо снабдить номерами (идентификаторами, адресами), на основании которых будет происходить перенаправление данных между сетями. Раньше адресовать сети не было необходимости. При желании можно дать новые адреса и узлам, чтобы отойти от использования МАС адресов как единственных идентификаторов узлов, а можно этого и не делать. В рамках своей сети широковещательные кадры остаются, разумеется, возможными, но полное широковещание во все огромную сеть недопустимо в принципе.
  3.  Между отдельными сетями установить активное оборудование, которое выполняло бы необходимую передачу данных из одной небольшой сети в другую.

Внедрение указанных выше мероприятий фактически означает введение нового уровня сетевого взаимодействия: «сетевого» (в рамках модели OSI), который будет располагаться над канальным уровнем и выполнять функции объединения многих канальных сетей в единое целое.  Основными функциями сетевого уровня является адресация сетей и перенаправление промежуточными устройствами («маршрутизаторами») данных из одной сети в другую («маршрутизация»), т.е. создание единой (универсальной) транспортной системы для взаимодействия в составных сетях. Таким образом функции первых трех уровней модели OSI выглядят следующим образом:

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

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

Понятие составной сети. Маршрутизация.

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

Единая сеть или Составная сеть – это сеть состоящая  из множества отдельных локальных и/или глобальных сетей, связанных воедино средствами третьего уровня модели OSI.

Разница между глобальной и составной сетями заключается в следующем:

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

Таким образом, чтобы стать членом глобальной сети, узел должен иметь физический интерфейс в этой сети, а чтобы стать членом составной сети узел может оставаться членом собственной канальной сети, которая с помощью маршрутизатора будет соединена с составной сетью. Очевидно, что типичная структура составной сети такова: отдельные небольшие сети компаний, построенные на базе Ethernet, связанные между собой глобальными технологиями типа Frame Relay, ISDN, E1 и т.д.

Теперь попытаемся в первом приближении рассмотреть, как же работают маршрутизаторы – устройства соединяющие локальные и глобальные сети между собой. Очевидно, что маршрутизатором  может быть устройство, имеющее более чем один интерфейс, как минимум – два (возможны исключения, но об этом позднее). Каждым своим интерфейсом маршрутизатор подключен к какой ни будь сети. Каждый интерфейс маршрутизатора должен иметь свой собственный адрес сетевого уровня (т.е. как минимум номер сети, к которому он подключен). Кроме этого, маршрутизатор должен быть снабжен специальной таблицей перенаправлений, называемой «таблица маршрутизации», которая содержит в себе информацию о том, куда отправлять пакеты данных, предназначенные в ту или иную сеть. Такая таблица содержит (как минимум) два столбца: № сети назначения и адрес следующего маршрутизатора. Это напоминает ,  таблицу коммутации, в которой тоже два столбца: МАС адрес получателя и номер выходного порта коммутатора.

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

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

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

Теперь рассмотрим содержимое таблицы маршрутизации. Так как никакой сетевой протокол нами пока не изучен, мы не можем пользоваться адресами сетей и портов маршрутизатора в каком-то формате, поэтому пока просто будем нумеровать сети, например, Сеть1, Сеть2 и т.д., а адреса портов маршрутизаторов будем рассматривать в виде M12, что будет означать: Маршрутизатор №1, порт №2.

Например:

Обратите внимание на то, что не может быть связей сеть-сеть напрямую – это возможно только с применением маршрутизатора. Так же не может быть связей маршрутизатор-маршрутизатор напрямую – их может связать только некоторая сеть.

Построим для каждого маршрутизатора в этой сети вручную таблицу маршрутизации вида:

Сеть назначения

Адрес следующего маршрутизатора

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

Начнем с маршрутизатора М1. Данный маршрутизатор является членом нескольких сетей, а именно сетей 1,2,3. Очевидно, если на маршрутизатор поступит пакет в одну из этих сетей, то его не нужно передавать следующему маршрутизатору, а нужно просто передать узлу получателю на канальном уровне, так как узел и маршрутизатор принадлежат одной сети. Тогда в таблицу маршрутизации в качестве адреса следующего маршрутизатора записывается тот порт самого маршрутизатора М1, через которой он должен доставить пакет непосредственно узлу получателю. Во всех остальных случаях в поле «Адрес следующего маршрутизатора» записывается адрес порта другого маршрутизатора, и лишь в строках о маршрутах в сети, членами которых маршрутизатор является непосредственно в поле «Адрес следующего маршрутизатора» записывается адрес своего порта. Это и является сигналом для маршрутизатора к тому, что пакет нужно передать непосредственно получателю. Итого, в таблицу маршрутизации маршрутизатора М1 вносим три строки:

Сеть назначения

Адрес следующего маршрутизатора

1

М11

2

М12

3

М13

Как маршрутизатор М1 может передать пакет в сеть 4? Он может передать пакет маршрутизатору М2, который подключен к сети 4 непосредственно, но может передать его и маршрутизатору М3, который в свою очередь передаст его маршрутизатору М5, а тот может передать его М2, который подключен к сети 4, или передать его М6, который передаст его М4, который снова таки непосредственно подключен к сети 4. Так как мы строим таблицу маршрутизации для маршрутизатора М1, то нас интересует только ответ на вопрос, кому ОН передаст пакет: М2 или М3. Видно, что в составной сети могут быть петлевидные связи, и ясно как с этим работать – просто выбирать оптимальный маршрут и заносить именно его в таблицу маршрутизации. Какой маршрут для М1 в сеть 4 оптимален? На первый взгляд кажется, что это маршрут через М2. Но предположим, что сеть 2 – коммутируемый аналоговый канал 19200 кбит/с, а сети 3,6,5 – Fast Ethernet. Тогда конечно выгоднее отправить пакет по маршруту с большим числом прыжков (хопов), так как, у этого маршрута и скорость выше, и задержка меньше и надежность лучше. Для описания этой особенности, в общем случае, вводят понятие метрики маршрута, некоторой абстрактной «стоимости» передачи пакетов по этому маршруту. Чем ниже метрика (цена) маршрута – тем более выгодно пользоваться этим маршрутом. Более подробно о метриках мы проговорим позже, пока же в качестве метрики при выборе оптимального маршрута будем использовать самую простую – количество переходов. Чем меньше переходов необходимо для доставки пакета по маршруту, тем такой маршрут предпочтительнее. В нашем случае маршрут в сеть 4 для маршрутизатора М1 через маршрутизатор М2 имеет метрику 2 (принимая, что маршрут в подключенную сеть имеет метрику 1), а маршрут в сеть 4 через маршрутизатор М3 имеет метрику 4 (или даже 5, смотря куда пакет будет передан маршрутизатором М5). Таким образом добавляем в таблицу маршрутизатора М1 маршрут в сеть 4:

Сеть назначения

Адрес следующего маршрутизатора

4

М21

Обратите внимание, так как сеть 4 не подключена к маршрутизатору М1, то в таблицу вносят адрес порта СЛЕДУЮЩЕГО маршрутизатора (М21), а не свой порт, через который передается пакет (М12). Если бы мы ошиблись, указав в качестве адреса следующего маршрутизатора порт М12, а не М21, то маршрутизатор должен был бы думать, что получать с ним в одной сети (что неверно) и послал бы кадр канального уровня в сеть 2 для получателя, который на самом деле находится в сети 4, что очевидно, привело бы к невозможности доставить пакет.

Добавим остальные маршруты в таблицу маршрутизации маршрутизатора М1, таблица приобретает следующий вид:

Сеть назначения

Адрес следующего маршрутизатора

1

М11

2

М12

3

М13

4

М21

5

М21

6

М31

7

М21

8

М31

9

М31

10

М31

Строим таблицу для маршрутизатора М2. У маршрутизатора М2 есть маршрут в сеть 7 через М41 и через М61 , при чем в обоих случаях метрика равна 2. В таком случае мы можем просто выбрать один из этих маршрутов, на свой вкус, так как не имеет значения, какой из них будет использоваться. Таблица маршрутизации для М2 будет иметь вид:

Сеть назначения

Адрес следующего маршрутизатора

1

М12

2

М21

3

М12

4

М22

5

М23

6

М51

7

М61

8

М51

9

М51

10

М51

Обратите внимание - Маршруты в сети 6,7,8,9,10 таковы, что пакет будут передан через собственный порт маршрутизатора М23 . Но маршрут в сеть 7 лежит через следующий маршрутизатор М61 , а маршруты в сеть 6,8,9,10 лежат через следующий маршрутизатор М51 . Именно поэтому в таблице маршрутизации указывается адрес следующего маршрутизатора, а не свой собственный порт, через который маршрутизатор выдает пакет: за своим портом может быть несколько портов разных маршрутизаторов (в сетях с множественным доступом, именно таковой является сеть 5).

Строим таблицу для М3:

Сеть назначения

Адрес следующего маршрутизатора

1

М13

2

М13

3

М31

4

М52

5

М52

6

М32

7

М52

8

М72

9

М72

10

М72

Строим таблицу для М4:

Сеть назначения

Адрес следующего маршрутизатора

1

М22

2

М22

3

М22

4

М41

5

М22

6

М62

7

М42

8

М62

9

М62

10

М62

Видно, что в сети 5,6,8,9,10 маршрут мог бы пролегать через М22 и М62 – метрики маршрутов одинаковы. Но так как в сети 1,2,3 маршрут пролегает через М22 , то имеет смысл в сети 6,8,9,10 пакеты пересылать через М62 , а, например, в 5-ую сеть через М22  так как в противном случае сеть 4 будет перегружена, в то время как сеть 7 не будет использоваться, разумеется, балансировка нагрузки каналов связи выгодна.

Строим таблицу для М5:

Сеть назначения

Адрес следующего маршрутизатора

1

М32

2

М23

3

М32

4

М23

5

М51

6

М52

7

М61

8

М72

9

М72

10

М72

Строим таблицу для М6:

Сеть назначения

Адрес следующего маршрутизатора

1

М23

2

М23

3

М51

4

М42

5

М61

6

М51

7

М62

8

М51

9

М51

10

М51

Строим таблицу для М7:

Сеть назначения

Адрес следующего маршрутизатора

1

М32

2

М32

3

М32

4

М52

5

М52

6

М72

7

М52

8

М71

9

М82

10

М82

Строим таблицу маршрутизации для маршрутизатора М8

Сеть назначения

Адрес следующего маршрутизатора

1

М71

2

М71

3

М71

4

М71

5

М71

6

М71

7

М71

8

М82

9

М81

10

М91

И, наконец, строим таблицу маршрутизации для маршрутизатора М9

Сеть назначения

Адрес следующего маршрутизатора

1

М81

2

М81

3

М81

4

М81

5

М81

6

М81

7

М81

8

М81

9

М91

10

М92

Проанализируем эту таблицу: маршрутизатор М9 имеет две подключенные сети, маршруты к которым описаны в таблице и адресами следующих маршрутизаторов являются интерфейсы самого М9, все остальные маршруты проходят через М81 . Эта ситуация вполне типична для пограничных маршрутизаторов, находящихся на периферии сети. Вместо маршрутов в сети 1-8 в таблицу маршрутизатора М9 можно внести одну единственную запись – запись о маршруте по умолчанию. Т.е. маршрут по которому будут отправляться пакеты с адресом сети получателя отличным от адреса подключенных к маршрутизатору сетей. Маршрут по умолчанию, так же называют “Default”.

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

Сеть назначения

Адрес следующего маршрутизатора

9

М91

10

М92

Default

М81

При поступлении на маршрутизатор М9 пакета, будет произведена проверка на основании номера сети получателя в пакете, не нужно ли отправить его в сеть 9, если нет – то не назначен ли он узлу в сети 10, и если нет, то пакет будет отправлен в соответствии с маршрутом по умолчанию на порт М81.

Не только в тупиковом маршрутизаторе можно применить идею о маршруте по умолчанию. Рассмотрим «почти» тупиковый, «около периферийный» маршрутизатор М8. Помимо двух подключенных сетей 8 и 9, он может достигнуть сети 10 через порт М92 , а всех прочих сетей через порт М81. Тогда можно записать в его таблицу специфические маршруты, ведущие от маршрутизатора М8 к периферии сети, а все остальные маршруты заменить маршрутом по умолчанию.

Новая таблица маршрутизации маршрутизатора М8 выглядит так:

Сеть назначения

Адрес следующего маршрутизатора

8

М82

9

М81

10

М91

Default

М71

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

Сеть назначения

Адрес следующего маршрутизатора

1

М22

2

М22

3

М22

4

М41

5

М22

6

М22

7

М42

8

М22

9

М22

а затем переписать в виде:

Сеть назначения

Адрес следующего маршрутизатора

4

М41

7

М42

Default

М22

А можно сохранить распределение нагрузки на сети 4 и 7, переписав таблицу все того же маршрутизатора М4 в таком виде:

Сеть назначения

Адрес следующего маршрутизатора

1

М22

2

М22

3

М22

4

М41

7

М42

Default

М62

Задание для закрепления пройденного материала:

– записать таблицу маршрутизации каждого маршрутизатора на схеме, используя в качестве адресов портов адреса вида М12

Выбор протокола сетевого уровня.

Итак, основные принципы и обзор основных функций лежащих в основе работы сетевого уровня нами сделан, теперь самое время перейти к рассмотрению конкретных протоколов и реализаций взаимодействия. Но возникает вопрос: какой из стеков протоколов рассматривать? Обратите внимание, что мы выбираем не просто сетевой протокол, а стек протоколов так как что в общем случае нельзя применить подходящий протокол некоторого уровня, не привязываясь к другим протоколам стека, из которого он взят. Для принятия окончательного решения необходимо проанализировать существующие на сегодняшний день стки протоколов, имеющих в составе и протокол 3-го уровня.

Из курса «Локальные сети» известны названия стеков протоколов IPX/SPX, TCP/IP, ISO, AppleTalk, DECNet, XNS. Известно так же, что сетевой уровень вводит адресацию сетей, а возможно и узлов. Например в IPX/SPX нумеруются сети, а адрес хоста в сети является его же MAC адресом, в TCP/IP – напротив и сеть и хост имеют адреса 3-го уровня образующие единый IP адрес. Если сетевой протокол вводит новую адресацию узлов сети, то необходимы механизмы сопоставления канальных адресов узлов с сетевыми адресами узлов. С чего же все начиналось ?

Первые версии протоколов Internet появились в середине 70-х гг. прошлого века, когда управление перспективных исследовательских программ (Defense Advansed Research Project Agency, DARPA) заинтересовалось в создании сети с коммутацией пакетов, которая бы способствовала обмену данными между разнородными вычислительными системами, установленными в исследовательских институтах. Для обеспечения связи между неоднородными сетями DARPA финансировало исследования Стэндфордского университета, а так же компании Bolt, Beranek and Newman (BBN). Их результатом стал набор протоколов Internet. Протокол TCP/IP был включен в набор позже, вместе с BSD UNIX, и с тех пор стал основой Internet и Word Wide Web (WWW).

Протоколы Internet образуют наиболее распространенный сегодня набор протоколов, поскольку они могут быть использованы для обмена данными между любыми связанными сетями и одинаково хорошо подходят как для локальных так и для глобальных сетей. В набор протоколов Internet входят протоколы обмена данными, двумя наиболее известными из которых являются протокол управления передачей (Transmission Control Protocol, TCP) и Internet-протокол (Internet Protocol, IP).

В начале 80-х гг. прошлого века компанией Novell были разработаны протоколы NetWare, среди них IPX и SPX. Протокол IPX  (Internetwork Packet Exchange, межсетевой пакетный обмен) – это протокол третьего уровня, используемый для маршрутизации пакетов между сетями. Протокол SPX (Sequenced Packet Exchange, последовательный обмен пакетами) является наиболее распространенным протоколом NetWare 4-го уровня. В наборе протоколов NetWare SPX располагается поверх IPX. SPX – надежный протокол, ориентированный на соединение, дополняющий службу дейтаграмм протокола IPX NetWare. Стандарт Novell так же поддерживает протокол Internet в виде протокола UDP. Дейтаграммы IPX инкапсулируются в заголовки UDP/IP для транспортировки по объединенным IP сетям.

Примерно в это же время международная организация по стандартизации (ISO) разработала полный набор протоколов взаимодействия промежуточных систем IS-IS (Intermediate System-to-Intermediate System), протокол взаимодействия конечной и промежуточной систем ES-IS (End System-to-Intermediate System) и протокол междоменной маршрутизации IDRP (Interdomain Routing Protocol). В основе протокола IS-IS лежит технология, разработанная корпорацией DEC (Digital Equipment Corporation) для сетей DECnet/OSI (DECnet Phase V). Первоначально IS-IS предназначался для маршрутизации в сетях CLNP (Connectionless Network Protocol, протокол сетевого обслуживания без подтверждения соединения). В последствии была разработана версия этого протокола, поддерживающая как сети CLNP, так и IP-сети; обычно ее называют объеденным протоколом IS-IS (Integrated IS-IS) или Dual IS-IS. Протоколы маршрутизации OSI описаны в ISO 10589, и поддерживаются Комитетом по сетевым и транспортным протоколам (X3S3.3) при Национальном институте стандартизации США (ANSI). Другими документами ISO являются стандарт ISO 9542 (ES-IS) и ISO 10747 (IDRP).

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

Итак - когда создавался стек TCP/IP, модели OSI еще просто не существовало, и разработчики TCP/IP опирались на собственную модель, которая имеет много общего с появившейся позже моделью OSI (точнее, наоборот, модель OSI имеет много общего с моделью TCP/IP ), но так же имеет и ряд отличий. Но прежде чем перейти к описанию отличий, предлагаю вспомнить названия и задачи уровней модели OSI, которые рассматривались в предыдущем курсе.

  •  Физический уровень – Physical layer
  •  Канальный уровень – Data Link Layer
  •  Сетевой уровень – Network Layer
  •  Транспортный уровень – Transport layer
  •  Сеансовый уровень – Session layer
  •  Представительский уровень – Presentation layer
  •  Прикладной уровень – Application layer

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

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

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

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

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

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

Прикладной уровень. Реализует среду взаимодействия приложений выполняемых в двух или более взаимодействующих системах. На прикладном уровне  определяется тот язык, с помощью которого обмениваются данными приложения. Например: browser хочет передать запрос web-серверу, для этого они должны поддерживать некоторый язык, с помощью которого обмениваются запросами и ответами – это и есть прикладной уровень

Теперь вернемся к сравнению уровней модели TCP/IP и современной модели OSI.

В модели TCP/IP изначально отсутствую уровни, по смыслу эквивалентные физическому и канальному уровням модели OSI (при этом, два нижних уровня модели OSI описывают работу локальной или глобальной сети, а стек протоколов готово работать поверх любой сети). Вот как выглядит  4-х уровневая модель TCP/IP по сравнению с уже известной моделью OSI :

Модель OSI

Модель TCP

Протоколы для каждого уровня

Прикладной

Прикладной

DHCP, DNS, FTP, HTTP, SMTP, POP3, TELNET, SNMP, TFTP etc

Представительский

Сеансовый

Основной

TCP, UDP

Транспортный

Сетевой

Сетевой

IP, ICMP, RIP, IGRP, OSPF etc.

Межсетевых интерфейсов

ARP

Канальный

Нет

Физический

Нет

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

Если бы протоколы физического и канального уровня входили в стек протоколов, это бы значило, что верхние уровни этого стека могут работать только с физическим и канальным уровнями этого же стека - это бы означало жесткую привязку программного обеспечения к аппаратному: смена используемого программного обеспечения (операционной  системы и используемых приложений) требовала бы смены физического и канального уровня, т.е. замены аппаратной части сети и наоборот. Для того, чтобы добиться независимости используемых программ от используемого железа (т.е. получить возможность изменять одно без замены другого) необходимо стандартизовать интерфейс между программно и аппаратно  реализуемыми уровнями, интерфейс между канальным и сетевым  уровнями. Именно так и реализуют сетевое взаимодействие: отдельно реализуют аппаратную часть сети (физический и канальный уровни) и отдельно программную часть сети (с сетевого уровня до прикладного) и используют стандартизованные интерфейсы канальный – сетевой. В TCP/IP такой интерфейс реализован в виде отдельного уровня собственной модели.

Функции протоколов прикладного (по модели TCP) уровня:

  •  DHCP – автоматическая конфигурация удаленного хоста
  •  DNS – разрешение символьных адресов в числовые составные, например www.itstep.org  195.248.190.129
  •  FTP – передача файлов с гарантией доставки
  •  HTTP – передача текстовой и графической информации в виде страниц (основа службы WWW)
  •  SMTP – передача почтовых сообщений от клиента к серверу и между почтовыми серверами
  •  POP3 – доставка почтовых сообщений от сервера к клиенту
  •  TELNET – удаленное подключение в режиме терминала, например для управления сервером (устарело)
  •  SNMP – сбор информации о работе сегментов сети и отдельных интерфейсов,  автоматическое управление работой сети
  •  TFTP – упрощенный протокол передачи файлов без гарантии доставки

Функции протоколов сетевого уровня:

  •  IP  – отвечает за адресацию сетей и узлов составной сети, за маршрутизацию
  •  ARP  – отвечает за сопоставление канальных и сетевых адресов узлов, так как в TCP/IP узлы получают новые адреса (вместе с адресами сетей)
  •  ICMP  – вспомогательный протокол, предназначенный для уведомлений об ошибках в составной сети и для диагностики неисправностей
  •  RIP, IGRP, OSPF – для автоматизации построения таблиц маршрутизации

Некоторые уровни модели OSI реализованы в модели OSI как один уровень, это произошло по следующим причинам:

  •  Реализация сеансовых и транспортных функций в одном (основном) уровне обусловлена тем, что протокол TCP, будучи главным протоколом этого уровня, соединяет в себе как функции установления логического соединения, так и функции последующей гарантированной передачи данных по этому соединению, по аналогии с LLC, который тоже один выполняет установку логических соединений и гарантирует доставку. Описанные функции крайне взаимосвязаны и вполне логично, если выполняются одним протоколом вопреки модели OSI.  Присутствие на основном уровне двух протоколов (TCP и UDP) так же логически объяснимо. Напомню, что протокол TCP это протокол с гарантией доставки данных, UDP – напротив – дэйтаграмный протокол. Это отчасти напоминает типы процедур LLC. Протокол LLC мог работать как с гарантированием доставки и установкой соединения, так и дейтаграммном режиме, в отличие от LLC протокол TCP может работать лишь в режиме с установкой соединения и гарантирования доставки пакетов, и поэтому, для служб и приложений, которым гарантии доставки и установка соединений не нужны с стеке TCP/IP существует протокол UDP, заменяющий TCP для передачи данных таких приложений.
  •  Представительский уровень должен уведомлять получателя, какого типа данные переданы для правильной их интерпретации. Так как в каждом прикладном протоколе передаются данные специфических для данного протокола типов, достаточно логично, предположить, что каждый прикладной протокол (нуждающийся в этом) содержит в себе представительские функции, сообщая получателю своим заголовком, что за данные переданы. Например, протокол HTTP: он может принести получателю web страницу (HTML), картинку, видео клип, flash анимацию и т.д., в самом заголовке HTTP, как будет рассмотрено позже, есть соответствующие поля для описания переносимых данных.

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

Решение этой задачи продолжим определением слова «Интернет» приведенным в словаре, итак:

Интернет - глобальная информационная сеть, части которой логически взаимосвязаны друг с другом посредством единого адресного пространства, основанного на протоколе TCP/IP. Интернет состоит из множества взаимосвязанных компьютерных сетей и обеспечивает удаленный доступ к компьютерам, электронной почте, доскам объявлений, базам данных и дискуссионным группам.

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

         SprintNet.
         Еще одной важной общемировой компьютерной сетью передачи данных является сеть SprintNet. Ее физическую основу составляют надежные оптоволоконные линии связи по всему миру. Для передачи данных используется технология X25, а также некоторые более современные технологии (Frame Relay, ATM). Поскольку SprintNet обеспечивает повышенную надежность и качество передачи информации, то ее услугами пользуются государственные организации, различные коммерческие структуры, общественные организации, а также МВД, таможенные службы и т.д.. SprintNet кроме услуг электронной почты и других видов связи предлагает доступ к различным собственным информационным ресурсам, а также к ресурсам сети Интернет. SprintNet обеспечивает работу международной банковской сети электронных расчетов S.W.I.F.T., а также телекоммуникационные услуги в системах платежей на основе пластиковых магнитных карточек.

Т.е. Интернет является одной из (пожалуй самой большой) составных-глобальных сетей, построенной на базе протокола IP. Однако это не означает, что нельзя построить IP сеть, не связанную с Интернет. IP – протокол, предназначенный для построения произвольных составных сетей, Интернет – лишь одна из реализованных на базе протокола IP составных сетей, впрочем, самая известная и большая. Аббревиатуры IP: Internet Protocol вовсе не означает «Протокол Интернета» уже хотя бы потому, что когда создавался IP, никакого Интернета не существовало. IP необходимо расшифровывать как «Межсетевой протокол», подчеркивая, ради чего его создавали и то, что вкладывали в это название разработчики – протокол для связывания сетей. Тот факт, что для названия «Интернет» достаточно банально позаимствовали слова «Inter» и «net», по сути назвав его «Составная сеть» означает потенциальную путаницу в терминологии: мы можем сказать «internet», подразумевая нечто межсетевое, а можем сказать «Internet» («Интернет») подразумевая вполне конкретную сеть. Поэтому при записи стоит Самую Большую И Всем Известную Сеть называть «Интернет или Internet» (с большой буквы), а желая написать по-английски слово «межсетевой» стоит использовать «internet» с маленькой буквы, а еще лучше, если возможно пользоваться терминами «inter-network» или «internetworking». К сожалению даже Microsoft  в своих продуктах (на которые мы будем во многом опираться) использует не слишком удачную терминологию, называя протокол IP «протоколом Интернета». Именно Интернет играет особую роль в стандартизации и развитии IP и всего стека TCP/IP, как раз к разговору о стандартизации мы сейчас и переходим.

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

Из вышесказанного следует: TCP/IP – универсальный стек протоколов, позволяющий строить произвольного размера составные сети, Интернет – лишь одна из этих составных сетей, но, тем не менее, именно развитие Интернет двигает развитие стека TCP/IP сегодня. Так что некоторый смысл в том, чтобы говорить, что IP – это протокол Интернета все же есть, однако говорить так все же не стоит, просто необходимо понимать, что на базе TCP/IP можно строить и не связанные с Интернет сети, но понимать роль Интернет в популярности и развитии TCP/IP сегодня.

Стандарты и регулирующие документы.

Развитие Интернет приводит к дальнейшему развитию и совершенствованию стека TCP/IP, а эффективность стека TCP/IP позволяет Интернет развиваться. Можно сказать, что Интернет и TCP/IP – это очень удачный симбиоз – каждый полезен друг другу! Изучение любой технологии прежде всего начинается со знакомства со стандартами и регламентирующими документами, описывающими все тонкости и нюансы изучаемого предмета. Знание стандартов – предупреждает от возможного получения неточной информации из других источников. Большинство стандартов, на сегодняшний день являются открытыми документами, т.о. для получения необходимого материала достаточно знать адрес организации поддерживающей тот или иной стандарт.

Стандартизация и документация Интернет осуществляется следующими организациями:

Internet Society (ISOC)  это неправительственная международная организация, занимающаяся координацией развития Интернета в мире, организующая сотрудничество международных и национальных организаций в области развития мировой инфраструктуры Сети, межсетевого взаимодействия, разработки сетевых технологий и приложений Интернета. На страницах сервера вы сможете подробно познакомиться с деятельностью ISOC, новостями, поддерживаемыми информационными службами, материалами проводимых международных конференций. Имеются разделы, посвященные стандартам Интернета, координирующим органам, действующим при ISOC (http://www.isoc.org)

IAB (Internet Architecture Board или «Совет по архитектуре Internet») представляет собой группу приглашённых лиц, которые добровольно изъявили желание принять участие в его работе. IAB регулярно собирается, чтобы утверждать стандарты и распределять ресурсы (например, адреса). Internet работает благодаря наличию стандартных способов взаимодействия компьютеров и прикладных программ друг с другом. Наличие таких стандартов позволяет без проблем связывать между собой компьютеры производства разных фирм. IAB несёт ответственность за эти стандарты, решает, нужен ли тот или иной стандарт и каким он должен быть. Если возникает необходимость в каком-нибудь стандарте, IAB рассматривает проблему, принимает этот стандарт и объявляет об этом по сети. Кроме того, IAB следит за разного рода номерами (и другими вещами), которые должны оставаться уникальными. Например, каждый компьютер Internet имеет свой уникальный 32-х разрядный адрес; такого адреса больше ни у одного компьютера нет. Как присваивается этот адрес, решает IAB. Точнее, сам этот орган присвоением адресов не занимается, он устанавливает правила присвоения адресов (http://www.iab.org)

У каждого пользователя в Internet имеется своё мнение относительно того, как должна функционировать сеть. Пользователи Internet выражают свои мнения на заседаниях инженерной комиссии IETF (Internet Engineering Task Force). IETF - ещё один общественный орган; он собирается регулярно для обсуждения текущих технических и организационных проблем Internet. Если возникает достаточно важная проблема, IETF формирует рабочую группу для дальнейшего её изучения. (На практике «достаточно важная» означает, как правило, что находится достаточно добровольцев для создания рабочей группы.) Посещать заседания IETF и входить в состав рабочих групп может любой; важно, чтобы он работал. Рабочие группы выполняют много различных функций - от выпуска документации и принятия решений о том, как сети должны взаимодействовать между собой в специфических ситуациях, до изменения значений битов в определённом стандарте. Рабочая группа обычно составляет доклад. Это может быть либо предоставляемая всем желающим документация с рекомендациями, которым следовать не обязательно, либо предложение, которое направляется в IAB для принятия в качестве стандарта (http://www.ietf.org)

Результаты работы IETF оформляются в виде документов, т.н. RFC. Аббревиатура RFC - Requests for Comments - это постоянно пополняемое собрание рабочих материалов (технических отчетов, проектов протоколов и описаний стандартов протоколов), используемых разработчиками и пользователями Интернет.

  •  RFC доступны для свободного скачивания в Интернет, например http://www.ietf.org/rfc.html  
  •  Каждый RFC имеет уникальный номер, номера никогда не повторяются, существующие RFC никогда не изменяются
  •  Новые RFC могут полностью заменять собой старые RFC, могут также и дополнять их
  •  Не все RFC являются стандартами, RFC могут иметь различные статусы: «неизвестно», «исторический», «информационный», «лучшее текущее решение» «экспериментальный», «предлагаемый стандарт», «черновой стандарт», «стандарт».

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

Подведем итоги: из существующих стеков протоколов мы выбираем TCP/IP, так как популярность этого стека протоколов сегодня очень велика благодаря Интернет, который в свою очередь опирается на эффективный стек TCP/IP. Основные функции сетевого уровня, выполняемые протоколом IP:

  •  Адресация
  •  Маршрутизация

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

На сегодняшний день существует достаточно способов и алгоритмов осуществления данной задачи. Ниже предлагается метод, позволяющий осуществлять действия без использования подручных средств, в т.ч. и бумаги с карандашом – т.е. с его помощью действия осуществляются «в уме». Именно этот момент наиболее важен, т.к. четко ориентироваться в двоичных последовательностях и их десятичных эквивалентах, можно только в случае полного понимания соответствия этих систем.

X Y = Z

  , где  X – основание степени

   Y – показатель степени

   Z – результат возведения

Начнем с повторения степеней двойки, и закономерностей с этим связанных:

20 = 1

21 = 2

22 = 4

23 = 8

24 = 16

25 =  32

26 = 64

27 = 128

28 = 256

Зная значения степеней двойки рассмотрим таблицу

            Двоичное восьми битовое число (байт)         Десятичный эквивалент

0 0 0 0 0 0 0 0 = 20 = 1

0 0 0 0 0 0 0 1 = 21 = 2

0 0 0 0 0 0 1 0 = 22 = 4

0 0 0 0 0 1 0 0 = 23 = 8

0 0 0 0 1 0 0 0 = 24  = 16

0 0 0 1 0 0 0 0 = 25  =  32

0 0 1 0 0 0 0 0 = 26  = 64

0 1 0 0 0 0 0 0 = 27  = 128

1 0 0 0 0 0 0 0 = 28  = 256

- Как вы уже заметили, десятичный эквивалент двоичного числа равен результату возведения 2 в степень указывающую порядковый номер единицы в двоичном числе с права на лево:

00000000= 20 =1, степень двойки равна 0, т.к. единиц в байте нет

00000001= 21 =2, степень двойки равна 1, т.к. единица в байте первая с права на лево

00000010= 22 =4, степень двойки равна 2, т.к. единица в байте вторая с права на лево

00000100= 23 =8, степень двойки равна 3, т.к. единица в байте третья с права на лево

……..  и т.д. ………………

10000000= 28  =256, степень двойки равна 8, т.к. единица в байте восьмая с права на лево

Таким образом, каждому биту в байте можно присвоить десятичное значение в случае если этот бит равен 1.

В случае, если набор битов в байте состоит из 1 и 0 в любом порядке, применяют следующий метод:

Рассмотрим число 00000101. Данное число можно представить в виде суммы

00000100

+ 00000001

-------------

00000101

Т.е. мы представили число в виде суммы двоичных чисел десятичные эквиваленты которых нам известны по предыдущей таблице:

00000100 =4

+ 00000001 =1

-------------

00000101 =4+1=5

Подобное действие можно осуществлять и устно, если сразу рассмотреть исходное число 00000101, как 4+1 – обратив внимание , что единицы стоят в соответствующих позициях. И в этом поможет знание и понимание  рассмотренной ранее таблицы соответствий.

Рассмотрим примеры

10011010 = 128 + 0 + 0 + 16 + 8 + 0 +2 + 0 = 128+16+8+2= 154

01110111 = 0 + 64 + 32 + 16 + 0 + 4 + 2 + 1 = 119

11101100 = 128+64+32+0+8+4+0+0 = 236

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

Упражнения для закрепления материала.

Перевести из двоичной в десятичную СС.

01010101

10101010

11001010

10011011

11001111

00111101

00011110

10111010

11111110

11111100

11111000

11110000

11100000

11000000

 10000000

 11111111

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

Рассмотрим число 8.

Его значение нам известно из таблицы  00000100, или

8 – это 23 , значит единица стоит третья справа на лево 00000100

Рассмотрим число 5.

Такого значения в таблице нет. Тогда представим 5 в виде суммы чисел, значения которых присутствуют в таблице : 5 = 4 + 1 . Поставим единицы в байте в позициях соответствующих, значениям слагаемых:

5 = 00000101

Рассмотрим число 23.

Такого значения в таблице нет. Тогда представим 23 в виде суммы чисел, значения которых присутствуют в таблице : 23 = 16+4+2+1 . Поставим единицы в байте в позициях соответствующих, значениям слагаемых:

23 = 00010111

Обратите внимание – при составлении суммы, первым выбирается число из таблицы наиболее близко расположенное к переводимому числу.

Рассмотрим число 138.

Такого значения в таблице нет. Тогда представим 138 в виде суммы чисел, значения которых присутствуют в таблице : 138 = 128+8+2 . Поставим единицы в байте в позициях соответствующих, значениям слагаемых:

138 = 10001010

Упражнения для закрепления материала.

Перевести из десятичной в двоичную СС.

7 12 55 89 121 135 165 211 235 244

15 26 63 94 98 28 83 74 204 35

Для перевода из двоичной в шестнадцатеричную СС используют таблицу

Десятичная система

Двоичная система

Шестнадцатиричная система

1

1

1

2

10

2

3

11

3

4

100

4

5

101

5

6

110

6

7

111

7

8

1000

8

9

1001

9

10

1010

A

11

1011

B

12

1100

C

13

1101

D

14

1110

E

15

1111

F

Переведем из двоичной СС число 111010102 в шестнадцатиричную СС. Группируем цифры по 4: 1110.1010. Каждую группу переводим в шестнадцатиричную СС: 1010216, 11102=E16. Получаем 111010102=ЕА16. (= 23410)

IP адресация

Адресация является неотъемлемой составляющей любого взаимодействия в сети. Виды адресов могут изменяться в зависимости от типа взаимодействия, но их наличие необходимо. В курсе «Локальные сети»  были рассмотрены адреса канального уровня, их роль заключалась в идентификации хостов внутри канальной сети. В последствии – при использовании коммутаторов поддерживающих трансляцию кадров разных базовых сетевых технологий MAC адреса стали идентифициоровать хосты при межсегментных взаимодесйствих методом коммутации. Неудобства использования коммутации для объединения большого количества сетей привели к введению сетевого уровня, и в частности протокола IP. Необходимость назначения адресов при этом сохранилась.

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

Рассмотрим, каким критериям должен удовлетворять сетевой адрес:

  •  Он должен быть достаточно длинным, чтобы с его помощью можно было адресовать достаточное количество узлов и сетей. Так как протокол сетевого уровня создается для построения очень больших сетей, то следует исходить из того, что длина адреса должна позволять построить сеть ЛЮБОГО разумного размера, например, соединяющую все компьютеры в мире.
  •  Он должен образовывать иерархическую структуру – т.е. содержать старшую и младшую части для того, чтобы осуществлять маршрутизацию в составной сети
  •  Он должен иметь разумную длину, так как слишком длинный адрес будет занимать много места в заголовке сетевого уровня, и уменьшать полезную пропускную способность сети.

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

Длина IP адреса составляет 4 байта (32 бита), куда входит и номер сети и номер узла в этой сети. Т.е. количество адресов, описываемых с его помощью                           232 = 4 294 967 296 (четыре миллиарда двести девяносто четыре миллиона девятьсот шестьдесят семь тысяч двести девяносто шесть). По сравнению с населением Земли (около 6 млрд. человек) это число не вполне достаточно, так как не позволяет обеспечить каждого человека компьютером с интерфейсом в составной сети. Кроме того, один человек может иметь несколько компьютеров – дома, на работе, карманный компьютер.

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

Форма записи IP адреса.

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

4-х байтовый адрес может быть представлен в различных системах счисления: в двоичной, шестнадцатеричной, десятичной. Например

01110001110011000011111000100101 (двоичная)

71CC3E25 (шестнадцатеричная)

113 204 062 037 (десятичная)

Шестнадцатеричная система записи адреса достаточно удобна, так как для записи четырех байт необходимо и достаточно 8 знаков, так как байт занимает полностью 2 знака. Двоичная система записи слишком громоздка, десятичная тоже удобна, особенно человеку, привыкшему жить в окружении именно десятичной системы счисления, но в десятичной системе для записи байта необходимо три знака, а не два, кроме того, эти три знака принимают не все, а только ¼ часть возможных значений. Однако, не смотря на удобство именно шестнадцатеричной системы счисления для записи IP адреса, принято использовать десятичную систему. Для того, чтобы не записывать те байты, для записи которых нет нужды в трех знаках (000-099), принято убирать из десятичной записи байтов ведущие нули, но тогда адрес вида: 1132046237 (см. выше) можно трактовать по разному: 113 20 46 237 или 113 204 62 37. Для однозначного прочтения адреса, записанного в такой форме необходимо установить какие-то разделители между байтами, в качестве таких разделителей принята десятичная точка. Тогда адрес записывается в таком виде: 113.204.62.37 Такая форма записи называется точечно-десятичной. Кроме записывания адресов в точечно-десятичной форме нам придется постоянно записывать адреса так же и в двоичной системе счисления.

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

Итак, теперь форма записи адреса рассмотрена, переходим к рассмотрению структуры IP адреса. Как уже говорилось, адрес состоит из двух частей: номера сети и номера узла в ней. Где в адресе проходит граница между номером узла и номером сети?

В первом RFC760, посвященном IP сказано:

«Addresses are fixed length of four octets (32 bits). An address begins with a one octet network number, followed by a three octet local address. This three octet field is called the "rest" field.» - Первый байт адреса являлся номером сети, три остальных байтаномером узла. Однако такой подход, очевидно, позволял иметь в составе составной сети всего 256 различных сетей (28 = 256),

xxxxxxxx . yyyyyyyy . yyyyyyyy . yyyyyyyy 

x – биты описывающие номер сети

y – биты описывающие номер хоста

,при этом количество хостов в каждой сети огромо : 224 = 16 777 216. Очевидно, что 256 составляющих сетей – слишком мало для «произвольного масштаба» составной сети, при том, что в таком количестве узлов в этих сетях нет потребности. Можно ли провести границу лучше?

Например, между вторым и третьим байтом: получим около 64 тыс. сетей по 64 тыс. узлов каждой.

xxxxxxxx . xxxxxxxx . yyyyyyyy . yyyyyyyy 

x – биты описывающие номер сети

y – биты описывающие номер хоста

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

xxxxxxxx . xxxxxxxx . xxxxxxxx . yyyyyyyy 

x – биты описывающие номер сети

y – биты описывающие номер хоста

Тогда сетей будет действительно много (около 16 млн.), но в каждой сети сможет быть только по 256 узлов, а этого уже недостаточно. Так же можно рассмотреть вопросы о проведении границы между битами, не привязываясь к границе байта. Например:

xxxxxxxx . xxxxxxxx . xxxxyyyy . yyyyyyyy 

x – биты описывающие номер сети

y – биты описывающие номер хоста

Но где не проведи такую границу, получится негибкое решение: либо получится мало сетей, либо мало узлов! Если бы адрес был бы длиннее, можно было провести некую статическую границу в адресе и было бы достаточное количество и сетей и узлов. Так как возможны ситуации, когда сети относительно велики (тысячи узлов, может и более), необходимо отвести под номер узла достаточно много бит. Тогда на номер сети останется недостаточно бит, и это при том, что таких больших сетей не много, большинство сетей невелики (десятки, сотни узлов) и использование большого количества бит на номер узла в итоге мало оправдано, но если этого не сделать, то большие сети нельзя будет адресовать в рамках выбранной схемы адресации. При длине адреса в 4 байта провести границу где бы то ни было статически НЕ гибко – или сетей мало, или их размер мал для некоторых сетей. Поэтому в RFC791, заменившем собой RFC760 было принято более гибкое решение – появилась техника деления адреса на две части, получившая название «техника классов».

Классы IP адресов

Из рассмотренного ранее известно, что IP адрес это код состоящий из старшей и младшей части. Старшая часть называется номер сети, младшая часть называется номер хоста. В этом простом на первый взгляд делении и заключается  смысл использования числовых составных адресов, в том числе и IP адреса. Следовательно необходимо ввести систему согласно которой IP адрес можно будет разделять на адрес сети и адрес хоста. В первом RFC описывающем протокол IP (RFC 760) была предложена система деления, поздее названная «Доклассовым методом». Суть этого метода заключалась в выделении первого байта IP адреса под адрес сети и остальных трех – под адрес хоста.

Addresses are fixed length of four octets (32 bits).  An address

begins with a one octet network number, followed by a three octet

local address.  This three octet field is called the "rest" field.

Адрес сети

Адрес хоста

Адрес хоста (продолжение)

Адрес хоста (продолжение)

Таким образом на адресацию сетей отводилось 8 бит и их количество составляло

28 = 256

На адресацию хостов отводилось остальные 24 бита, и их количество составляло

224 –2 = 16 777 214

Предложенный метод деления IP адреса вполне подходил для экспериментальных IP сетей на этапе тестирования, и даже немного после – при реальной работе. Но, доклассовый метод деления имел явный недостаток: огромное количество хостов в сети при сравнительно мизерном количестве самих сетей. Т.е. приведенный метод мог применяться только в очень больших сетях, количество самих сетей в этом случае составило бы всего 256 «на весь мир».

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

Что собой представляет техника деления на классы? В рамках классового подхода адрес снова состоит из двух частей – номера сети и номера узла. Но граница между адресом сети и узла пролегает в разных частях адреса в зависимости от нескольких первых бит адреса. Это позволяет поделить адресное пространство на неравные части (по RFC760 все сети были одной величины): существует некоторое небольшое количество очень больших сетей, среднее количество среднего размера сетей и множества маленьких сетей. Рассказываем технику классов.

Делим адресное пространство на две части: 0xxxxxxx.Y.Z.W и 1xxxxxxx.Y.Z.W. Часть адресного пространства 0xxxxxxx.Y.Z.W называют адресами класса А,  в адресах класса А граница в адресе между номером сети и узла проходит между первым и вторым байтом IP адреса. Рассчитаем, сколько существует сетей класса А. По определению, данному выше, номер сети – первый байт, но его первый бит фиксирован и равен «0», поэтому сети нумеруют с помощью не 8-и, а лишь семи бит, таким образом сетей класса А всего 128 (27). Узлов в каждой сети класса А примерно по 16 млн. (224). В точечно-десятичной записи номера узлов сети класса А принадлежат диапазону:

0.x.y.z – 127.x.y.z Адреса класса А использую половину доступного адресного пространства IP.

Не используемой осталась еще половина адресов вида: 1xxxxxxx.Y.Z.W. Делим эту часть адресного пространства еще пополам. Получаем два диапазона адресов: 10xxxxxx.Y.Z.W и 11xxxxxx.Y.Z.W. Часть адресного пространства 10xxxxxx.Y.Z.W называют адресами класса В, в адресах класса В граница в адресе между номером сети и узла проходит между вторым и третьим байтом IP адреса. Рассчитаем, сколько существует сетей класса В. По определению, данному выше, номер сети – первые два байта, но два первых бита фиксированы и равны «10», поэтому сети нумеруют с помощью не 16-и, а лишь 14-и бит, таким образом сетей класса В всего примерно 16 тыс. (214). Узлов в каждой сети класса В примерно по 64 тыс. (216). В точечно-десятичной записи номера узлов сети класса В принадлежат диапазону:

128.x.y.z – 191.x.y.z. Адреса класса В использую четверть полного доступного адресного пространства IP.

Не используемой осталась еще четверть адресов вида: 11xxxxxx.Y.Z.W. Делим эту часть адресного пространства еще пополам. Получаем два диапазона адресов: 110xxxxx.Y.Z.W и 111xxxxx.Y.Z.W. Часть адресного пространства 110xxxxx.Y.Z.W называют адресами класса С, в адресах класса С граница в адресе между номером сети и узла проходит между третьим и четвертым байтом IP адреса. Рассчитаем, сколько существует сетей класса С. По определению, данному выше, номер сети – первые три байта, но три первых бита фиксированы и равны «110», поэтому сети нумеруют с помощью не 24-х, а лишь 21-о бита, таким образом сетей класса С всего примерно 2 млн. (221). Узлов в каждой сети класса С по 256 (28). В точечно-десятичной записи номера узлов сети класса С принадлежат диапазону:

192.x.y.z – 223.x.y.z. Адреса класса С использую восьмую часть полного доступного адресного пространства IP.

 

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

Не используемой осталась еще восьмая часть адресов вида: 111xxxxx.Y.Z.W. Делим эту часть адресного пространства еще пополам. Получаем два диапазона адресов: 1110xxxx.Y.Z.W и 1111xxxx.Y.Z.W. Часть адресного пространства 1110xxxx.Y.Z.W называют адресами класса D. Адреса этого класса не могут быть уникальными идентификаторами  узлов, не содержат в себе номера сети и номера узла и выполняют в IP с специальную функцию – используются для групповой адресации. Это значит: узел сети помимо того, что имеет один IP адрес из классов А, В или С (являющийся его уникальным идентификатором в составной сети) может иметь один или множество адресов класса D. При этом, в отличии от адресов классов A, B, C адреса класса D могут быть одинаковы для множества узлов. Адрес класса D является адресом именно ГРУППЫ узлов, членами группы являются все те узлы, который имеют одинаковый адрес класса D. Пакет посланный с адресом получателя класса D должен быть доставлен всем без исключения узлам, являющимся членами той группы, на адрес которой послан пакет. Более детально об адресах класса D будет рассказано позднее. В точечно-десятичной записи номера узлов сети класса D принадлежат диапазону:

224.x.y.z – 239.x.y.z. Адреса класса D использую шестнадцатую часть полного доступного адресного пространства IP.

 

Не используемой осталась еще шестнадцатая часть адресов вида: 1111xxxx.Y.Z.W. Часть адресного пространства 1111xxxx.Y.Z.W называют адресами класса Е. Адреса этого класса не могут быть уникальными идентификаторами  узлов, не содержат в себе номера сети и номера узла, а являются зарезервированными для дальнейшего использования и сегодня в IP не используются. В точечно-десятичной записи номера узлов сети класса E принадлежат диапазону:

240.x.y.z – 255.x.y.z. Адреса класса E использую шестнадцатую часть полного доступного адресного пространства IP.

Подведем итоги: техника классов, в отличии о доклассовой (RFC760) является гораздо более гибкой: она позволяет разделить адресное пространство на неравные сети:

  •  128 сетей по 16 млн. узлов
  •  16 тыс. сетей по 64 тыс. узлов
  •  2 млн. сетей по 256 узлов
  •  Дополнительная возможность организовать групповую доставку пакетов, 256 млн. групп

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

Особые адреса.

Работа с IP адресами предполагает использование таких типов адресов, которые бы могли использоваться в особых целях. Т.е. вместо основной задачи IP адреса – идентифицировать компьютер в составной сети, в особых случаях адресу вменяется в обязанность идентификация группы компьютеров – участников одной IP сети, идентификация номера сети и т.д. Для систематизации назначения подобных IP адресов были приняты соглашения по их форме и способу идентификации. Рассмотрим особые адреса.

Если ВСЕ биты, ответственные за номер узла в IP адресе равны «0», то такой адрес не может быть присвоен узлу. Такой адрес является номером сети. Приведем примеры номеров сетей:

  •  В классе А:
    •  1.0.0.0, номер узла х.0.0.0 – это номер сети
    •  56.0.0.0, номер узла х.0.0.0 – это номер сети
    •  126.0.0.0, номер узла х.0.0.0 – это номер сети
    •  127.0.0.0, номер узла х.0.0.0 – это номер сети
  •  В классе В:
    •  128.10.0.0, номер узла х.х.0.0 – это номер сети
    •  150.150.0.0, номер узла х.х.0.0 – это номер сети
    •  190.0.0.0, номер узла х.х.0.0 – это номер сети
    •  191.200.0.0, номер узла х.х.0.0 – это номер сети
  •  В классе С:
    •  192.10.11.0, номер узла х.х.х.0 – это номер сети
    •  201.30.0.0, номер узла х.х.х.0 – это номер сети
    •  222.0.0.0, номер узла х.х.х.0 – это номер сети
    •  223.45.89.0, номер узла х.х.х.0 – это номер сети

Обратите внимание, адреса типа: 10.1.2.0, 67.77.0.0, 155.34.89.0, 228.4.5.0, 250.249.248.0 не являются номерами сетей, так как НЕ все биты, отвечающие за номер узла в этих адресах равны нулю, (а ответ на вопрос, какие биты адреса являются адресом узла следует из использования понятия класса), или вообще не содержат в себе номера сети и узла (классы D, E):

  •  10.1.2.0, класс А, за номер узла отвечают х.1.2.0 – следовательно, это не номер сети
  •  67.77.0.0, класс А, за номер узла отвечают х.77.0.0 – следовательно, это не номер сети
  •  155.34.89.0, класс В, за номер узла отвечают х.х.89.0 – следовательно, это не номер сети
  •  228.4.5.0, класс D, вообще не содержит в себе номера сети и узла
  •  250.249.248.0, класс E, вообще не содержит в себе номера сети и узла

Где применяются IP адреса, являющиеся адресами сетей? Конечно же в таблицах маршрутизации – вспомним, что в простейшей таблице маршрутизации два столбца: номер сети назначения и адрес интерфейса следующего маршрутизатора. Могут существовать в сети пакеты, посланные таким образом, что в поле получателя и отправителя IP пакета указан номер сети? Нет, это не допустимо, в адресных полях IP пакета номера сетей встречаться не могут.

Если ВСЕ биты, ответственные за номер узла в IP адресе равны «1», то такой адрес так же не может быть присвоен узлу. Такой адрес называется широковещательным или широковещательным в заданную сеть. Приведем примеры широковещательных адресов в сетях различных классов:

  •  В классе А:
    •  1.255.255.255, номер узла х.255.255.255 – это широковещательный адрес
    •  56.255.255.255, номер узла х.255.255.255 – это широковещательный адрес
    •  126.255.255.255, номер узла х.255.255.255 – это широковещательный адрес
    •  127.255.255.255, номер узла х.255.255.255 – это широковещательный адрес
  •  В классе В:
    •  128.10.255.255, номер узла х.х.255.255 – это широковещательный адрес
    •  150.150.255.255, номер узла х.х.255.255 – это широковещательный адрес
    •  190.0.255.255, номер узла х.х.255.255 – это широковещательный адрес
    •  191.200.255.255, номер узла х.х.255.255 – это широковещательный адрес
  •  В классе С:
    •  192.10.11.255, номер узла х.х.х.255 – это широковещательный адрес
    •  201.30.0.255, номер узла х.х.х.255 – это широковещательный адрес
    •  222.0.0.255, номер узла х.х.х.255 – это широковещательный адрес
    •  223.45.89.255, номер узла х.х.х.255 – это широковещательный адрес

 

Обратите внимание, адреса типа: 10.1.2.255, 67.77.255.255, 155.34.89.255, 228.4.5.255, 250.249.248.255 не являются широковещательными адресами, так как НЕ все биты, отвечающие за номер узла в этих адресах равны «1», (а ответ на вопрос, какие биты адреса являются адресом узла следует из использования понятия класса), или вообще не содержат в себе номера сети и узла (классы D, E):

  •  10.1.2.255, класс А, за номер узла отвечают х.1.2.255 – следовательно, это не широковещательный адрес
  •  67.77.255.255, класс А, за номер узла отвечают х.77.255.255 – следовательно, это не широковещательный адрес
  •  155.34.89.255, класс В, за номер узла отвечают х.х.89.255 – следовательно, это не широковещательный адрес
  •  228.4.5.255, класс D, вообще не содержит в себе номера сети и узла
  •  250.249.248.255, класс E, вообще не содержит в себе номера сети и узла

Где и как применяются в IP сети широковещательные адреса, и как их применение согласуется с тем, что мы говорили о недопустимости широковещания в составной сети? В IP действительно нет широковещания во всю составную сеть, но так как каждая сеть, входящая в составную сеть сама по себе широковещательная (или может быть широковещательной), то в широковещании в пределах одной канальной сети нет ничего плохого. При передаче из одной канальной сети в другую широковещательного IP пакета, по составной сети перемещается один пакет, адрес получателя которого, например, 45.255.255.255. Такой пакет, перемещаясь между транзитными маршрутизаторами является самым обычным пакетом – он просто маршрутизируется так же как и индивидуально назначенный узлу пакет до маршрутизатора, который подключен к сети назначения 45.0.0.0 и только лишь в саму канальную сеть номер 45.0.0.0 отправляется широковещательным кадром канального уровня. Таким образом видно, что передача таких пакетов не нарушает общей идеи составной сети, которая заключается в запрете широковещания ВСЕМ узлам составной сети.

Из вышесказанного следует, что широковещательный адрес может фигурировать в заголовке IP пакета в качестве адреса получателя, но не может фигурировать в заголовке в качестве отправителя.

Следующий особый адрес – неопределенный адрес. Адрес, являющийся номером сети класса А, а именно 0.0.0.0 применяется для указания отсутствия IP адреса у узла. Зачем это может быть нужно? Если при интерфейс старте не имеет адреса, то с помощью специального протокола, он может получить адрес, которым будет пользоваться в дальнейшем, от специального сервера (более детально этот вопрос будет рассмотрен в последующих курсах). Пока же узел не имеет своего адреса, он пользуется адресом 0.0.0.0. Такой адрес не может фигурировать в заголовке IP пакета в качестве адреса получателя, но может фигурировать в качестве адреса отправителя, указывая, что отправитель не имеет собственного адреса. Очевидно, такой адрес не может быть присвоен узлу как уникальный идентификатор.

 

Еще один специальный адрес – ограниченно широковещательный (limited broadcast). Это адрес, все биты которого равны «1», т.е. 255.255.255.255. Этот адрес принадлежит классу Е (который является зарезервированным), и является единственным используемым адресом из этого диапазона. Пакет, посланный по такому адресу принимается всеми узлами своей сети и никогда не маршрутизируется в другие сети. Положим, мы являемся узлом 5.1.1.1. номер нашей сети 5.0.0.0, широковещательный адрес, по которому можно послать пакет всем узлам нашей сети 5.255.255.255, но из высказанного следует, что того же можно добиться, послав пакет по адресу 255.255.255.255. Зачем это нужно, ведь любой узел знает свой адрес, значит знает номер своей сети, знает широковещательный адрес своей сети и может послать на этот адрес пакет, зачем же еще ограниченно широковещательный адрес? Ответ как раз и сформулирован в предыдущем предложении: если узел еще НЕ имеет IP адреса, то он не знает широковещательного адреса той сети, которой принадлежит, а послать пакет по адресу 255.255.255.255 может всегда! Итого: ограниченно широковещательный адрес нужен для коммуникаций между узлом, пока не имеющим IP адреса (и не знающего номера сети, которой принадлежит) и сервером, предоставляющем IP адреса. Мы уже говорили, что узел не имея адреса, шлет пакеты специального прикладного протокола, предназначенного для получения IP адресов (DHCP) от неопределенного адреса 0.0.0.0. При этом узел не знает адреса того сервера, который назначит ему адрес, так же он не знает номера своей сети, и поэтому шлет такой пакет на ограниченно широковещательный адрес. И если в одной сети с безадресным узлом есть DHCP сервер, то он получит данный пакет! А как DHCP сервер ответит клиенту, если у того нет адреса? Тоже ограниченно широковещательно. Действительно, положим, у нас нет еще адреса, и мы получаем ограниченно широковещательный пакет. Мы знаем, что такой пакет не покидает сети, в которой отправлен, и хоть мы не знаем номера своей сети, но мы знаем, что если мы уже получили такой пакет, то мы находимся в той же сети, как и отправитель этого пакета, следовательно, этот пакет предназначен и для нас тоже! Таким образом, с помощью неопределенного адреса и ограниченно широковещательного адреса безадресный клиент и DHCP сервер обмениваются информацией, что приводит к назначению узлу IP адреса. Т.е. безадресный клиент посылает IP пакеты с обратным адресом 0.0.0.0 и адресом получателя 255.255.255.255, а в ответ получает пакеты от адреса DHCP сервера и адресом получателя 255.255.255.255. Ясно, что ограниченно широковещательный адрес может фигурировать в заголовке IP пакета только в качестве адреса получателя. Если станция знает номер своей сети и хочет послать пакет всем узлам своей сети, она может использовать как широковещательный, так и ограниченно широковещательный. Так же очевидно, что в удаленные сети широковещательно можно обратиться используя лишь широковещательный, но не ограниченно широковещательный адрес.

 

Другие особые адреса: сеть класса А, 0.0.0.0 является зарезервированной (и не используемой) и не может присваиваться реальным сетям. Ее номер сети, как уже говорилось выше, используется для указания отсутствия IP адреса у отправителя пакета.

Сеть класса А 127.0.0.0 является зарезервированной для специального применения. Все пакеты, которые стек TCP/IP генерирует в эту сеть НИКОГДА не отправляются в линии связи через любые сетевые интерфейсы. Вместо этого такие пакеты «закольцовываются», т.е. послав такой пакет, станция сама выступает его получателем (стек просто переносит такие пакеты из буфера отправки в буфер приема). Это полезно для локального тестирования  правильной работы стека TCP/IP, если обмен пакетами с узлом, например, 127.0.0.1 проходит нормально, то с программным обеспечением стека TCP/IP все в порядке. Если же нет, то проблемы носят локальный характер, и не связаны с неисправностью сетевых интерфейсов, линий связи и удаленными системами. Разумеется, сетевой интерфейс не может иметь адреса в сети 127.0.0.0. Так же очевидно, что в линии связи пакеты с такими адресами отправителей и получателей вообще никогда не попадают, такие пакеты остаются в памяти того узла, который их сгенерировал.

 

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

Сетей класса А пригодных для адресации в реальных сетях – 126, а не 128, так как сети 0.0.0.0 и 127.0.0.0 являются используемыми особо. Узлов в сети класса А – 224-2, так как узлу нельзя присвоить ни адрес, являющейся номером сети, ни широковещательный адрес.

Сетей класса B пригодных для адресации в реальных сетях – 214, узлов в сети класса В – 216-2, так как узлу нельзя присвоить ни адрес, являющейся номером сети, ни широковещательный адрес.

Сетей класса С пригодных для адресации в реальных сетях – 221, узлов в сети класса С – 254, а не 256, так как узлу нельзя присвоить ни адрес, являющейся номером сети, ни широковещательный адрес.

 

Практическое задание:

  1.  К какому классу принадлежит данный адрес, запишите номера соответствующих сетей:

 5.6.7.8   Класс А, номер сети 5.0.0.0 и т.д.

 210.10.10.10  

 150.0.0.1

 225.6.7.8

 222.15.0.1

 192.16.0.0

 0.0.0.0

 255.255.255.255

 254.0.0.0

 127.0.0.0

 126.0.0.0

 128.255.255.254

  1.  Укажите адреса, являющиеся адресами сетей, для тех адресов, который являются адресами узлов, укажите номер сети:

 5.6.7.8   номер узла, сеть 5.0.0.0

 5.6.7.0

 5.6.0.0

 5.0.0.0   номер сети

 150.150.150.150

 150.150.150.0

 150.150.0.0

 150.0.0.0

 192.192.1.1

 192.192.1.0

 192.192.0.0

 192.0.0.0

 225.225.0.0

 225.0.0.0

  1.  Укажите широковещательные адреса из ниже перечисленных:

 5.6.7.255

 5.6.255.0

 5.6.255.255

 5.255.255.255

 255.255.255.255

 190.190.190.255

 190.190.255.255

 190.255.255.255

 210.255.255.255

 210.210.255.255

 210.255.255.255

 225.1.2.255

 225.255.255.255

  1.  Укажите, какие адреса недопустимы для присвоения интерфейсам:

 0.0.0.1

 1.2.3.0

 0.0.0.0

 1.0.0.0

 192.168.256.8

 210.0.0.0

 222.233.255.255

 227.7.8.9

 255.255.255.255

 127.5.6.7

 213.255.0.0

 13.255.0.0

 177.255.0.0

 177.255.255.255

 177.255.255.0

 5.6.7.0

 5.6.0.0

 5.255.0.255


 

А также другие работы, которые могут Вас заинтересовать

66416. СУДОВЕ ПРАВОЗАСТОСУВАННЯ В УКРАЇНІ: ПРОБЛЕМИ ТЕОРІЇ І ПРАКТИКИ 136.5 KB
  На сучасному етапі дослідження питань правозастосування та правозастосовчого процесу знаходять розвиток у працях таких вітчизняних дослідників як О. Проблематика судового правозастосування в вітчизняній юридичній літературі на превеликий жаль майже не досліджена.
66417. МАЛІ КОЛИВАННЯ ЗЧЛЕНОВАНИХ ГІРОСТАТІВ 407 KB
  У цьому випадку дуже характерні і задачі про малі коливання зчленованих гіростатів. Розроблено підхід який оснований на використанні теорії операторних матриць що діють у гільбертовому просторі і який дозволяє перейти від вихідної початково крайової задачі для гідромеханічної системи...
66418. Удосконалення методів передачі розміру одиниці електричного опору нерівнономінальним мірам 1.65 MB
  Питання удосконалення методів передачі розміру одиниці електричного опору нерівнономінальним мірам виникло у зв'язку зі збільшенням обсягів прецизійних вимірювань у яких здійснюється порівняння нерівнономінальних некратнодесятинних мір.
66419. Виховання патріотизму в учнів середніх шкіл США 169 KB
  Тому ставлення до виховання патріотизму в молодого покоління у сучасній українській школі повинно докорінно змінитися. Вдосконаленню і збагаченню вітчизняних традицій патріотичного виховання в школі може слугувати аналогічний зарубіжний досвід зокрема Сполучених Штатів Америки країни де цьому питанню завжди приділялася належна увага.
66420. РОЗВИТОК ПІДПРИЄМСТВ ОРГАНІЧНОГО СЕКТОРУ АГРОБІЗНЕСУ В КОНТЕКСТІ ВИКЛИКІВ ГЛОБАЛІЗАЦІЇ ТА ЄВРОІНТЕГРАЦІЇ 211.5 KB
  В контексті викликів глобалізації та євроінтеграції не повинна стати винятком і Україна тим більше що є всі передумови для ефективного функціонування підприємств органічного сектору. Теоретичні основи й узагальнення практичного досвіду розвитку...
66421. МЕХАНІЗМ РЕГУЛЮВАННЯ РИНКУ ФІНАНСОВИХ ПОСЛУГ УКРАЇНИ 979 KB
  На сучасному етапі розвитку економіки України ринок фінансових послуг знаходиться лише на стадії свого формування у зв’язку з чим виникає потреба в адекватному механізмі регулювання що є необхідною передумовою ефективного функціонування цього ринку.
66422. ТОВАРОЗНАВЧА ХАРАКТЕРИСТИКА РЕДИСКИ ЗАЛЕЖНО ВІД СОРТУ ТА УМОВ ЗБЕРІГАННЯ 231 KB
  В літку якісні коренеплоди ізза біологічних особливостей редиски виростити неможливо. Проблемами зберігання редиски в різні часи займалися такі науковці як П. Дженєєв 1968 але залишилось багато невирішених питань щодо збереженості...
66423. ПОДАТКИ НА СПОЖИВАННЯ В УКРАЇНІ: ОРГАНІЗАЦІЯ СПРАВЛЯННЯ ТА ФІСКАЛЬНІ НАСЛІДКИ ФУНКЦІОНУВАННЯ 306 KB
  Фіскальна історія свідчить що оподаткування споживання давно практикується державами. Поряд з цим саме представники групи податків на споживання універсальні акцизи відіграли роль рятівників бюджетів провідних держав світу в умовах гіперінфляції під час двох Світових воєн та низки економічних криз.
66424. Клініко-патогенетичні особливості перебігу ревматоїдного артриту за наявності ендотеліальної та субклінічної гіпотиреоїдної дисфункції 214 KB
  Не дивлячись на дуже часте співіснування цих нозологічних одиниць клінічна діагностика уражень ЩЗ у хворих на РА достатньо складна особливо у випадках м’якої клінічної маніфестації. У хворих із ревматичними захворюваннями ЕД відіграє не менш важливу роль у розвитку та прогресуванні...