Учебно-методическии комплекс дисциплины «Компьютерные сети» для специальности 6М011100 — «Информатика» (стр. 46 )

Рис. 10.7У Интернет-провайдера «Голубая луна» есть наиболее точный маршрут к организации 1

В этом случае, как показано на рис. 10.7, Интернет-провайдер «Ночные полеты» продолжит поддерживать блок адресов 200.23.16.0/20, а Интернет-провайдер «Голубая луна» — блок адресов 199.31.0.0/16. Однако теперь Интернет-провайдер «Голубая луна» также будет поддерживать блок адресов 200.23.18.0/ 23 для организации 1. Когда другие маршрутизаторы в Интернете увидят блоки адресов 200.23.16.0/20 (от Интернет-провайдера «Ночные полеты») и 200.23.18.0/23 (от Интернет-провайдера «Голубая луна») и захотят направлять пакеты по адресам в блоке 200.23.18.0/23, они воспользуются правилом соответствия самому длинному префиксу и направят пакеты Интернет-провайдеру «Голубая луна», так как он заявил о самом длинном (наиболее конкретном) адресном префиксе, совпадающем с адресом получателя.

Интернет-провайдер — не единственный источник блоков IP-адресов. Очевидно, сами Интернет-провайдеры тоже должны где-то получать IP-адреса. Существует ли организация, в глобальном масштабе отвечающая за управление пространством IР-адресов и выделение блоков адресов Интернет-провайдерам и другим организациям? Разумеется, такая организация есть! ICANN (Internet Corporation for Assigned Names and Numbers — организация по назначению адресов и имен в Интернете) управляет IP-адресами на основе набора правил, опубликованных в RFC 2050. Роль некоммерческой организации ICANN заключается не только в предоставлении IP-адресов, но также в управлении корневыми DNS-серверами. Она также занимается весьма спорной работой по выделению имен доменам и разрешению связанных с этим конфликтов. ICANN предоставляет адреса региональным Интернет-регистратурам, таким как ARIN, RIPE и APNIC, управляющим предоставлением адресов в своих регионах.

Получение адреса хоста

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

□ Ручное конфигурирование. Системный администратор вручную указывает IP-адрес хоста (как правило, в файле).

□ Использование протокола DHCP (RFC 2131). Протокол DHCP (Dynamic Host Configuration Protocol — протокол динамической конфигурации хоста) позволяет хосту автоматически получить IP-адрес, а также дополнительную информацию, такую как адрес ближайшего маршрутизатора и адрес DNS-сервера.

Благодаря своей способности автоматизировать настройку сетевых параметров соединения хоста и сети протокол DHCP часто называют самонастраивающимся (plug-and-play) протоколом. Эта способность делает его очень привлекательным для сетевых администраторов, которым в противном случае пришлось бы выполнять всю эту работу вручную! Протокол DHCP также широко применяется в региональных сетях доступа к Интернету и беспроводных локальных сетях, в которых хосты редко подключаются к сети и редко от нее отключаются.

Сетевой администратор может сконфигурировать протокол DHCP таким образом, чтобы у определенных хостов IP-адреса были постоянными, то есть при каждом подключении к сети хосту будет выделяться один и тот же адрес. Однако у многих организаций и локальных Интернет-провайдеров недостаточно IP-адресов для всех их хостов. В этом случае протокол DHCP позволяет назначать каждому соединившемуся хосту временный IP-адрес. В качестве примера рассмотрим регионального Интернет-провайдера, у которого 2000 клиентов, но одновременно к Интернету подключается не более 400. Для поддержки всех 2000 клиентов Интернет-провайдеру не нужен блок из 2000 адресов. Используя DHCP-сервер, динамически выделяющий адреса, Интернет-провайдер может обойтись блоком из 512 адресов (например, блоком 200.23.30.0/23). Когда хосты подключаются к сети или отключаются от сети, DHCP-сервер обновляет свой список доступных IP-адресов. Каждый раз, когда хост подключается к Интернету, DHCP-сервер выделяет ему произвольный адрес из текущего пула доступных адресов. Каждый раз, когда хост отсоединяется от Интернета, его адрес возвращается в пул.

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

3. Адресация, маршрутизация и продвижение дейтаграмм

Теперь, определив понятия интерфейсов и сетей, а также получив базовое представление об IP-адресации, поговорим о том, как хосты и маршрутизаторы переносят IP-дейтаграмму от отправителя к получателю. Высокоуровневый взгляд на IP-дейтаграмму иллюстрирует рис. 10.8. Каждая IP-дейтаграмма содержит поля адресов отправителя и получателя. Хост-отправитель заполняет поле адреса отправителя собственным 32-разрядным IP-адресом. Поле адреса получателя он заполняет 32-разрядным IP-адресом хоста-получателя, которому предназначается дейтаграмма. Поле данных дейтаграммы, как правило, заполняется TCP - или UDP-сегментом. Остальные поля IP-дейтаграммы мы обсудим чуть позже.

Рис. 10.8 Ключевые поля IP-дейтаграммы

Как после создания IP-дейтаграммы хостом-отправителем сетевой уровень перемещает ее хосту-получателю? Ответ на этот вопрос зависит от того, располагаются оба хоста в одной и той же сети или в разных сетях (здесь под сетью понимается IP-сеть, как было описано ранее). Рассмотрим этот вопрос на примере сети на рис. 10.9. Пусть сначала хост А хочет послать IP-дейтаграмму хосту J5, находящемуся в той же сети 223.1.1.0/24, что и хост Л. Это делается следующим образом. Сначала протокол IP хоста А заглядывает в свою внутреннюю IP-таблицу продвижения данных, также показанную на рисунке, и находит в ней сетевой адрес 223.1.1.0/24, совпадающий со старшими разрядами IP-адреса хоста В. В таблице продвижения данных указывается, что количество ретрансляционных участков до сети 233.1.1.0 равно 1; это означает, что хост В расположен в той же самой сети, что и хост А. Таким образом, хост А узнает, что дейтаграмму хосту В можно послать прямо по выходному интерфейсу хоста А безо всяких промежуточных маршрутизаторов. Тогда хост А передает IP-дейтаграмму протоколу канального уровня, который передает ее хосту В.

Рассмотрим теперь более интересный случай, когда хосту А нужно передать дейтаграмму другому хосту, например хосту Е, находящемуся в другой сети. Хост А также обращается к своей таблице продвижения данных и находит в ней адрес сети 223.1.2.0/24, совпадающий со старшими разрядами IP-адреса хоста Е. Поскольку количество ретрансляционных участков до сети 233.1.2.0/24 равно 2, хост A понимает, что получатель располагается в другой сети, и поэтому дейтаграмму следует посылать промежуточному маршрутизатору. Из той же таблицы хост A узнает, что предназначаемые хосту E дейтаграммы следует направлять интерфейсу маршрутизатора с адресом 223.1.1.4, с которым интерфейс хоста Л соединен напрямую. Затем протокол IP хоста A передает дейтаграмму канальному уровню, сообщая ему, что дейтаграмму следует отправить по IP-адресу 223.1.1.4. Здесь важно отметить, что, хотя дейтаграмма посылается (с помощью канального уровня) интерфейсу маршрутизатора, поле адреса получателя дейтаграммы, по-прежнему содержит адрес конечного получателя (хоста E), а не адрес интерфейса промежуточного маршрутизатора.

Рис. 10.9 Продвижение данных хоста А

Итак, дейтаграмма попадает на маршрутизатор, и теперь маршрутизатор должен переправить дейтаграмму ее конечному получателю. Как показано на рис. 4.22, маршрутизатор сверяется с собственной таблицей продвижения данных и находит в ней адрес сети 223.1.2.0/24, совпадающий с начальными битами IP-адреса хоста Е. В этой таблице также указывается, что дейтаграмму следует направлять интерфейсу маршрутизатора 223.1.2.9. Поскольку количество ретрансляционных участков до получателя равно 1, маршрутизатор понимает, что получающий хост E располагается в той же самой сети, что и его собственный интерфейс 223.1.2.9. Таким образом, маршрутизатор передает дейтаграмму этому интерфейсу, который пересылает ее хосту Е.

Рис. 10.10 Продвижение данных маршрутизатора

Обратите внимание, что все записи в столбце, предназначенном для указания адресов следующих маршрутизаторов, пусты, так как каждая сеть (223.1.1.0/24, 223.1.2.0/24 и 223.1.3.0/24) напрямую соединена с маршрутизатором. В этом случае нет необходимости направлять дейтаграммы промежуточным маршрутизаторам. Однако если бы хосты АиЕ разделяли два маршрутизатора, тогда в таблице продвижения данных первого маршрутизатора на пути от хоста А до хоста Е в соответствующей строке указывалось бы два ретрансляционных участка до адресата, а также IP-адрес второго маршрутизатора вдоль маршрута. Тогда первый маршрутизатор переправлял бы дейтаграмму второму маршрутизатору при помощи протокола канального уровня, соединяющего два маршрутизатора. Второй маршрутизатор направлял бы дейтаграмму хосту-получателю с помощью протокола канального уровня, соединяющего второй маршрутизатор и хост-получатель.

Возможно, вы помните из главы 1, что маршрутизация дейтаграммы в Интернете напоминает водителя автомобиля, спрашивающего дорогу на каждом перекрестке. Теперь должно быть ясно, почему эта аналогия соответствует маршрутизации в Интернете. Путешествуя от отправителя до получателя, дейтаграмма проходит через целую последовательность маршрутизаторов. На каждом маршрутизаторе в этой последовательности она останавливается и «спрашивает» у маршрутизатора дорогу до конечного получателя. Если маршрутизатор не находится в той же сети, что и конечный получатель, таблица продвижения данных как бы говорит дейтаграмме: «Я не знаю точно, как добраться до конечного получателя, но я знаю, что до него можно добраться по этой линии (аналог дороги), соединенной с одним из моих интерфейсов». Затем дейтаграмма отправляется по указанной линии, прибывает на следующий маршрутизатор и снова спрашивает дорогу.