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

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

420.png

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

Рассмотрим теперь более интересный случай, когда хосту А нужно передать дейтаграмму другому хосту, например хосту Е, находящемуся в другой сети. Хост А также обращается к своей таблице продвижения данных и находит в ней адрес сети 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), а не адрес интерфейса промежуточного маршрутизатора.

421.png

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

422.png

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

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

Таким образом, мы видим, что таблицы продвижения данных на маршрутизаторах играют центральную роль в маршрутизации дейтаграмм через Интернет. Но как эти таблицы конфигурируются и управляются в большой сети (такой как Интернет) с большим количеством маршрутов между отправителями и получателями? Очевидно, таблицы продвижения данных должны конфигурироваться так, чтобы дейтаграммы следовали по оптимальным маршрутам от отправителя к получателю. Как вы, возможно, уже догадались, для конфигурирования и поддержки таблиц продвижения данных служат алгоритмы маршрутизации, которые мы рассматривали в разделе «Основы маршрутизации». Алгоритмы маршрутизации, применяемые в Интернете, мы обсудим в разделе «Маршрутизация в Интернете». Но прежде чем перейти к обсуждению вопроса реализации алгоритмов маршрутизации в Интернете, поговорим о пяти наиболее важных составляющих успешного функционирования протокола IP. Это, во-первых, формат дейтаграмм; во-вторых, фрагментация IP-дейтаграмм; в-третьих и в-четвертых, уже упоминавшиеся протоколы ICMP и DHCP; и наконец в-пятых, трансляция сетевых адресов (NAT). Рассмотрим эти составляющие поочередно.

Данная статья "Адресация, маршрутизация и продвижение дейтаграмм" размещена на сайте Компьютерные сети и многоуровневая архитектура интернета (conlex.kz) в ознакомительных целях.

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

Ответственность, за все изменения, внесённые в систему по советам данной статьи, Вы берёте на себя.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *