Галкин В.А., Григорьев Ю.А. Телекоммуникации и сети

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

5. Сетевые

протоколы

нение к посылке LQR пакетов маршрутизатор может быгь сконфигурирован

для периодической посылки по каналу пакетов Echo Request. Если маршрути-

затор послал определенное их количество и не получил ни одного пакета Echo

Reply, то все NCP закрываются. Интервал между пакетами Echo Request и

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

ными параметрами.

5.5. Протоколы Ш уровня стека ТСРЯР

Протокол IPv4

Протокол межсетевого взаимодействия IP (Internet Protocol) - протокол

ненадежной доставки. Ненадежность возникает только тогда, когда не хватает

ресурсов или происходят сбои в используемых физических сетях.

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

во всем стеке TCP/IP. Программное обеспечение IP вьшолняет функцию мар-

шрутизации, выбора пути, по которому будут передаваться данные. Помимо

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

ции, IP включает набор правил, которые обеспечивают ненадежную доставку

пакетов. Эти правила указывают, как маршрутизаторам следует обрабаты-

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

вия, при которых можно удалять пакеты.

Протокольный блок данных IP называется межсетевой дейтаграммой (IP-

дейтаграммой или просто дейтаграммой). Как и кадр канального уровня, дей-

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

содержит адреса отправителя, получателя и поле типа, которое идентифициру-

ет содержимое дейтаграммы. Разница между ними состоит в том, что заголо-

вок дейтаграммы содержит IP-адреса, а заголовок кадра - физические адре-

са. Формат дейтаграммы представлен на рис. 5.16.

0 4 8 16 19 24 31

Версия Длина

Тип сервиса

Идентификация

Время жизни Протокол

Общая длина

Флаги

Смещение фрагмента

Контрольная сумма заголовка

1Р-адфес отправителя

1Р-ащ)ес получателя

Опции

Заполнение

Данные

Рис. 5.16.

Формат дейтаграммы

350

5.5. Протоколы III уровня стека TCP/IP

Так как обработка дейтаграммы происходит

помощью программного обес-

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

и формат. Например, первое 4-битовое поле «Версия» в дейтаграмме содер-

жит версию протокола

DP,

используемую при создании дейтаграммы. Оно ис-

пользуется отправителем, получателем, и всеми марпфутизаторами между

ними для уверенности подтверждения того, что все они используют один и тот

же формат дейтаграммы. Всему программному обеспечению IP необходимо

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

того,

что ее формат соответствует формату, который ожидает это обеспечение. Если

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

токола, отличающейся от версии, на которой они работают, предохраняя себя

от неправильной интерпретащш содержимого дейтаграммы из-за устаревшего

формата. В настоящее время наибольшее распространение получила версия

IPv4,

которую постепенно сменит более совершенная IPv6. Рассмотрим пос-

ледовательно эти версии.

Поле длины заголовка «Длина» также занимает 4 бита и хранит длину заго-

ловка дейтаграммы в 32-битных словах. Все поля в заголовке имеют фиксиро-

ванную длину, за исключением поля «Ошщи IP» и соответствующего ему поля

«Заполнение». Наиболее простой заголовок, без ошщй и заполнения, занимает

20 октетов и имеет в поле заголовка «Длина» значение 5.

Поле «Общая длина» определяет длину ЕР-дейтаграммы, измеренную в ок-

тетах, включая октеты в заголовке и данных. Размер области данных можно

вычислить путем вьпитания длины заголовка «Длина» из «Общей

длины».

Так

как поле «Общая длина» занимает 16 бит, то максимально возможный размер

дейтаграммы IPv4 составляет 65535 октет.

Поле «Тип сервиса» 8 бит указывает, как следует обрабатывать дейта-

грамму. Это поле разделено на пять подполей

(рис.

5.17). Три бита «Приорите-

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

(обычный приоритет) до 7 (управление сетью), позволяя отправителям пере-

давать информащпо о важности каждой дейтаграммы, например управляющая

информащы может иметь больший приоритет, чем данные.

Биты D, Т и R описьшают тип передачи, который нужен дейтаграмме. Уста-

новка бига D запрашивает минимальные задержки при передаче, бита Т - мак-

симальную пропускную способность, а бита R - максимальную надежность.

Конечно, межсетевое взаимодействие не может гарантировать вьшолнение зап-

рошенного сервиса (например, может быгь так, что нет пути к назначению с

запрошенньвш качествами). Поэтому можно рассматривать запрос сервиса

как указание алгоритмам маршрутизащш, а не как требование. Если маршру-

тизатор знает более чем один марпфут к указанному назначению, он может

О 2 3 4 5 6 7

Приоритет D

Не используется

Рис. 5.17. Формат

поля «Тип

сервиса» IPv4

351

Сетевые протоколы

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

более близкими требуемым. Например, предположим, что маршрутизатор

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

скоростной (но с большими паузами) спутниковой линией. Дейтаграммы,

передающие нажатия клавиш от пользователя к удаленному компьютеру,

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

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

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

спутниковой линии.

Важно

понимать,

что

алгоритмы маршрутизации

должны

выбирать одну из

возможных используемых физических сетевых

технологий,

которые

имеют

оп-

ределенные характеристики

задержки,

пропускной способности

надежности.

Часто данная технология использует компромисс между этими характеристи-

ками

(например,

высокой скоростью

передачи и большей

задержкой).

Поэтому,

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

но;

не имеет смысла указьшать все три типа сервиса.

Таким образом, спецификацию типа передачи следует рассматривать как

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

сети назначения из возможньпс на основе знаний об аппаратных технологиях,

использующихся на этих путях. Интернет не гарантирует вьшолнения запро-

шенного

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

Инкапсуляция дейтаграмм. В отличие от кадров физической сети, кото-

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

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

Более жесткие ограничения на размер дейтаграммы накладывают пара-

метры сетей. При передаче дейтаграммы от одной мапшны к другой, ее долж-

ны транспортировать базовые физические сети. Для эффективности межсете-

вой передачи нужно

быть уверенным

том,

что каждая

дейтаграмма передается

в отдельном физическом кадре. Передача одной дейтаграммы в одном кадре

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

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

ние как не знает формата дейтаграммы, так и не понимает IP-адреса назначе-

ния. Поэтому, когда одна машина посьшает IP-дейтаграмму другой, вся дей-

таграмма передается как часть данных кадра (рис. 5.18).

Заголовок кадфа

Заголовок дейтаграммы Область данных дейгаграммы

Область данных кадра

Рис.

5.18.

Инкапсулящ1я

IP-дейтаграммы

в кадр

352

5.5.

Протоколы

Шуровня стека TCP/IP

Нв

Ж.

Сеть! ^ /^ СетьЗ

МТи=1500 (R,) , , (R2) МТи=1500

Сеть 2

МТи = 620

Рис.

5.19.

Пример

применения фрагментации

В идеальном случае вся IP-дейтаграмма помещается в одном физическом

кадре, что делает передачу по физической сети более эффективной. Каждая

технология коммутации пакетов устанавливает фиксированную верхнюю гра-

ницу количества данных, которые могут быть переданы в одном физическом

кадре.

Такие ограничения называют «максимальная единица передачи» - MTU

(Maximmn Transfer

Unit).

Значение MTU может

быть

довольно

маленьким:

не-

которые аппаратные технологии ограничивают размер передачи до 128 октет

или даже меньше. Маленькие части, на которые делится дейтаграмма, назы-

ваются

фрагментами,

а процесс деления дейтаграммы -

фрагментацией.

Как показывает рис. 5.19, фрагментация обычно осуществляется маршру-

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

получателем. Маршрутизатор принимает дейтаграмму

из сети с

большим

MTU

и должен передать ее по сети, в которой MTU меньше, чем размер дейтаграм-

мы.

На рисунке оба компьютера Нд и Н^ напрямую присоединены к сетям

Ethernet (Сеть 1 и Сеть 3), которые имеют MTU в 1500 октет. Поэтому оба

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

ны.

Путь между ними, тем не менее, включает сеть с MTU = 620 октет. Если

Нд

посьшает

Н^

дейтаграмму длиннее 620

октет,

маршрутизатор Rj

будет

фраг-

ментировать эту дейтаграмму. Аналогично, если Н^ посьшает большую дей-

таграмму Нд, маршрутизатор R2 будет фрагментировать эту дейтаграмму.

Размер фрагмента выбирается таким, чтобы каждый фрагмент мог транспор-

тироваться в одном кадре. Кроме того, так как IP передает значение смеще-

ния данных

восьмерках

октетов,

размер

фрагмента

должен быть выбран

крат-

ным восьми. Конечно, выбор числа октетов, кратного восьми и наиболее

близкого к сетевой MTU, не обязательно делит дейтаграмму на равные части;

последняя часть часто короче, чем остальные. Фрагменты должны собирать-

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

будет обрабатываться у получателя.

Протокол IP как не ограничивает дейтаграммы до маленького размера, так

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

тации. Отправитель может выбрать любой размер дейтаграммы. Фрагмента-

ция

сборка производятся автоматически,

не

требуя специальных действий от

отправителя. Спецификация IP устанавливает, что маршрутизаторы должны

353

5. Сетевые протоколы

Заголовок

дейтаграммы

Данные 1

(600 октетов)

Данные 2

(600 октетов)

Данные 3

(200 октетов)

1 Заголовок

1 фрагмента 1

Данные 1

(600 октетов)

Заголовок

фрагмента 2

Данные 2

(600 октетов) 1

Заголовок

фрагмента 3

Данные 3

(200 октетов)

Фрагмент

- смещение

Фрагмент 2 - смещение 600

Фрагмент 3 - смещение 1200

Рис.

5.20.

Исходная

дейтаграмма,

несущая 1400 октетов данных

(а)

и три фрагмента для сети с MTU= 620

(б)

принимать дейтаграммы с размерами, не превосходящими MTU сетей, к кото-

рым они присоединены. Кроме того, маршрутизаторы должны всегда обраба-

тывать дейтаграммы размером до 576 октет.

Фрагментация дейтаграммы означает разделение ее на несколько час-

тей.

Рис. 5.20 иллюстрирует результат фрагментации.

Каждый фрагмент содержит заголовок дейтаграммы, дублирующий боль-

шую часть заголовка исходной дейтаграммы (кроме бита в поле «Флаги», ко-

торый показьшает, что это фрагмент), и столько данных, сколько может содер-

жать фрагмент, чтобы общая длина бьша меньше, чем MTU сети, по которой

он путешествует.

Сборка фрагментов. В сетях ТСРЯР после фрагментирования дейтаграм-

мы,

ее фрагменты передаются как отдельные дейтаграммы на всем протяже-

нии пути

до места назначения, где они собираются. Сохранение фрагментащш

на всем протяжении пути имеет два недостатка. Во-первых, так как дейтаг-

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

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

назначения. Сборка дейтаграмм в месте назначения может привести к неэф-

фективности: даже если некоторые сети, проходимые после фрагментащш,

имеют большое значение MTU, их будут пересекать только маленькие фраг-

менты. Во-вторых, если какой-либо фрагмент будет потерян, дейтаграмму

нельзя будет восстановить. Принимающая машина запускает таймер сборки

при приеме первого фрагмента. Если таймер обнуляется до того, как приняты

все фрагменты, принимающая мапшна удаляет оставшиеся части, не обраба-

тывая дейтаграмму. Поэтому вероятность потери дейтаграммы увеличивает-

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

дит к потере всей дейтаграммы.

Несмотря на

эти

недостатки, вьшолнение сборки

месте назначения хоро-

шо работает. Оно позволяет независимо маршрутизировать фрагменты и

не требует от промежуточньгх: маршрутизаторов хранения собираемых фраг-

ментов.

354

5.5. Протоколы III уровня стека TCP/IP

Управление фрагментацией. Три поля в заголовке дейтаграммы - Иден-

тификация,

Флаги и

Смещение фрагмента ~ управляют фрагментацией

сбор-

кой

дейтаграмм (см. рис. 5.16). Поле «Идентификация» содержит уникальное

целое

число,

которое идентифицирует дейтаграл1му.

Напомним,

что когда шлюз

или маршрутизатор фрагментирует дейтаграмму, он копирует большую часть

полей в заголовке дейтаграммы в каждый фрагмент. Поле «Идентификация»

позволяет получателю

узнать,

какой дейтаграмме принадлежат прибьгоающие

фрагменты. Когда появляется фрагмент, получатель для идентификации дей-

таграммы использует поле «Идентификация» вместе с полем адреса источни-

ка. Компьютер, посьшающий ЕР-дейтаграммы, должен генерировать уникаль-

ное значение поля «Идентификация» для каждой отдельной дейтаграммы (в

теории, повторные передачи дейтаграммы должны содержать

то

же самое зна-

чение в поле «Идентификация», что и в исходной дейтаграмме; на практике,

протоколы высокого уровня

обычно вьшолняют

повторную

передачу как новую

дейтаграмму со своим значением поля «Идентификация»). Один из модулей,

используемых в программном обеспечении IP, храшгг глобальный счетчик в

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

и копирует результат в поле «Идентификация» дейтаграммы.

Напомним, что каждый фрагмент имеет точно такой же формат, что и пол-

ная

дейтаграмма. Для фрагмента поле «Смещение фрагмента» указывает сме-

щение в исходной дейтаграмме данных, передаваемых в фрагменте, измеряе-

мое в 8 октетах (смещения измеряются в восьмерках октетов для сохранения

места в заголовке), начиная со смещения ноль. Для сборки дейтаграммы это

поле должно

получить назначение

во

всех фрагментах, начиная

фрагмента со

смещением

до фрагмента с наибольшим смещением. Фрагмешы необяза-

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

ду маршрутизатором, который фрагментирует дейтаграммы, и получателем,

который пытается собирать их.

Младшие два бита из трехбитового поля «Флаги» управляют фрагментаци-

ей.

Обычно прикладное программное обеспечение, использующее TCP/IP, не

заботится о фрагментации, так как и фрагментация, и сборка являются авто-

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

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

тевого программного обеспечения или отладки рабочих программ может ока-

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

фрагментация. Первый управляющий бит помогает при таком тестировании,

указьшая возможность фрагментации

дейтаграммы.

Он назьгаается битом «не

фрагментировать», так как установка его в единицу указьгаает, что дейтаграм-

му нельзя фрагментировать. Приложение может выбрать запрет фрагмента-

ции,

когда нужна лишь целая дейтаграмма. Всякий

раз,

когда маршрутизатору

нужно фрагментировать дейтаграмму

установленным битом «не фрагменти-

ровать»,

он

удаляет дейтаграмму

посьшает обратно источнику сообщение об

ошибке.

355

5. Сетевые

протоколы

Младший бит в поле «Флаги» указывает, содержит ли фрагмент данные из

середины дейтаграммы или из конца. Он назьшается битом «еще фрагменты».

Поясним необходимость наличия этого бита. Программное обеспечение IP у

получателя

будет

получать фрагменты (возможно

не по

порядку),

ему

нужно

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

очередной фрагмент, поле «Общая длина» в заголовке указывает размер фраг-

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

зовать поле «Общая длина» для того, чтобы определить, собрало ли он все

фрагменты. Бит «еще фрагменты» легко решает

проблему:

как только получа-

тель получает фрагмент со сброшенным битом «еще фрагменты», он знает,

что этот фрагмент несет в себе данные из конца исходной дейтаграммы. На

основе полей «Смещение фрагмента» и «Общая длина» оно может вьршслить

длршу исходной дейтаграммы. Проверив «Смещение фрагмента» и «Общая

длина» у всех прибьшших фрагментов, получатель может определить, содер-

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

Время жизни дейтаграммы. Поле «Время жизни» указывает, сколько

секунд может оставаться дейтаграмма в межсетевой системе. Эта идея яв-

ляется насколько

простой,

настолько

важной:

всякий

раз,

когда машина

пере-

дает дейтаграмму в Интернет, она устанавливает максимальное время суще-

ствования дейтаграммы. Шлюзы и маршрутизаторы, обрабатывающие

дейтаграмму, должны декрементировать поле «Время жизни» по мере того,

как идет время, и удалять дейтаграмму из Интернета, когда время вьпшю.

Оценить время точно трудно, так как маршрутизаторы обычно не знают

время передачи между физическими

сетями.

Принятые соглашения упрощают

обработку и делают легкой обработку дейтаграмм без синхронизации часов.

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

буется декрементировать поле «Время жизни» на единицу, когда он обрабаты-

вает заголовок дейтаграммы. В случае, когда маршрутизаторы перегружены,

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

локальное время прихода дейтаграммы и декрементирует «Время жизни» на

число секунд, в течение которого дейтаграмма находилась в маршрутизаторе,

ожидая обслуживания.

Всякий

раз,

когда поле «Время жизни» обнуляется, маршрутизатор удаляет

дейтаграмму

посьшает сообщение

об

ошибке обратно

источнику.

Поле «Вре-

мя жизни» гарантирует, что дейтаграммы не смогут вечно путешествовать по

Ирггернету, даже если таблицы маршрутизации разрушатся и маршрутизаторы

будут маршрутизировать дейтаграммы по кольцу.

Значение в поле «Протокол» указывает, какой протокол высокого уровня

использовался при создании сообщения, передаваемого в области «Данные»

дейтаграммы. По существу, значение в «Протокол» специфицирует формат

области

«Данные».

Соответствие между протоколом высокого уровня

целым

числом,

используемым

в поле

«Протокол»,

должно

устанавливаться ответствен-

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

356

5.5.

Протоколы

III уровня стека TCP/IP

Поле «Контрольная сумма заголовка» удостоверяет целостность значений

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

заголовка как последовательности 16-битовых чисел (с сетевым порядком

байт),

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

ставлением отрицательных

чисел,

получения отрицания

числа.

При

вычисле-

нии контрольной суммы поле «Контрольная сумма заголовка» предполагается

равньп^ нулю. Необходимо помнить, что эта контрольная сумма применима

только к числам, находящимся в заголовке

IP,

а не в данных. Разделение конт-

рольной суммы для заголовка

и для

даннык имеет свои преимущества и недо-

статки. Так как заголовок обычно занимает меньше октетов, чем данные, на-

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

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

Это

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

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

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

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

наружить искажения данных.

ЕР-адреса. Поля «Адрес отправителя IP» и «Адрес получателя IP» содер-

жат 32-битовые IP-адреса отправителя и конечного получателя дейтаграммы

IPv4.

Хотя дейтаграмма может проходить через большое число промежуточ-

ных шлюзов

или

маршрутизаторов, поля отправителя

получателя никогда не

изменяются; они указывают IP-адреса истинного источника и конечного на-

значения.

IP-адрес состоит из адреса сети и адреса узла в этой сети и принадлежит

одному из пяти классов (рис. 5.21). Класс данного IP-адреса можно опреде-

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

бит

достаточно для

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

классов.

Ад-

реса класса А вьщеляют под адрес сети 7 бит, а под адрес узла 24 бит. Адреса

класса

вьщеляют 14 бит под адрес сети и 16 бит под адрес узла. И наконец,

сети класса С, состоящие менее чем из 256 узлов, вьщеляют

бит под адрес

сети

только

бит под адрес

узла.

Маршрутизаторы используют

для

маршру-

тизации поле «Адреса

сети».

Характеристики классов IP-адресов представле-

ны в табл. 5.8.

Классе

Класс/)

Классе

Номер сети

8 16 24 31

Номер узла |

l|0|

Номер сети | Номер узла |

|l|l|0|

Номер сети | Номер узла

1 1

Групповой адрес 1

l|l|l|l|0| Резерв 1

Рис.

5.21.

Структура IP-адресов

протокола IPv4

357

5. Сетевые

протоколы

Таблица5.8.

Классы ff-адресов

Класс

IP-адреса

Диапазон

значений

первого октета

1-126

128-191

192-223

224 - 239

240-247

Возможное

количество

сетей

126

16382

2097150

Возможное

количество

узлов

16777214

65534

254

228

2^^

Когда обьршые компьютеры имеют два или более физических соединений,

их назьюают многоадреснь»«и (multi-homed). Многоадресные узлы требуют

нескольких адресов IP. Каждый адрес соответствует одному из соединений

этой машины с сетью. Так как IP-адреса кодируют как сеть, так и узел в этой

сети,

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

Поэтому маршрутизатор, соединяющий N сетей, имеет N различньпс IP-адре-

сов,

по одному на каждое сетевое соединение.

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

на отдельные узлы. По соглашению адрес сети имеет поле «адреса узла», рав-

ное

нулю.

ГР-адреса могут использоваться

для

указания широковещания и ото-

бражения его

аппаратное широковещание. По соглашению, широковещатель-

ный адрес имеет поле адреса узла со всеми битами, равными «1». Такой

широковещательный адрес назьшают направленным (directed) широковеща-

тельным адресом, так как он содержит как корректный идентификатор сети,

так и корректный широковещательный адрес узла. Направленный широкове-

щательный адрес может однозначно интерпретироваться в любой точке Ин-

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

помимо указания на широковещание

этой сети. Направленные широковеща-

тельные адреса обеспечивают мощный (и чем-то опасный) механизм, позво-

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

нен

режиме широковещания

указанной сети.

С точки зрения адресации, главным недостатком направленного широкове-

щания является то, что оно требует знаний об адресе сети. Другая форма ши-

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

рес или локальный сетевой широковещательный адрес, обеспечивает

широковещательный адрес для локальной сети (сети отправителя), независи-

мо от назначенного ей IP-адреса. Локальный широковещательный адрес

состоит из 32 единиц (поэтому он иногда назьшается широковещательным ад-

ресом из всех единиц). Узел может использовать ограниченный широковеща-

тельный адрес в процессе своего запуска, до того, как он узнает свой IP-адрес

или IP-адрес локальной сети. Как только узел узнает IP-адрес своей сети, он

может использовать направленное широковещание.

358

5.5.

Протоколы

III уровня стека TCP/IP

Если поле адреса, состоящее из единиц, может интерпретироваться как «все

узлы» в сети, то поля, состоящие из нулей, межсетевое программное обеспече-

ние интерпретирует как символ «это». Поэтому IP-адрес с адресом узла, рав-

ным «О», обозначает «этот узел», а межсетевой адрес с идентификатором сети

«О» обозначает «эта сеть». Конечно, использовать эти адреса нужно только в

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

Помимо широковещания схема адресов IP поддерживает спещ1альную фор-

му групповой доставки, известную как групповая доставка (multicasting). Груп-

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

поддерживает групповую доставку.

При описании IP-адресов принято использовать точечную десятичную но-

тащпо. IP-адреса записывают как четыре десятичных числа, разделенных: де-

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

октета IP-адреса. Например, IP-адрес 195.190.21.45 соответствует узлу

сети

195.190.21.0 класса С.

Сетевой адрес класса

У4

127.0.0.0 зарезервирован для обратной связи и вве-

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

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

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

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

адресом 127, не будет передаваться ни по какой сети. Более того, узел или

маршрутизатор никогда не должен распространять информащпо о маршрутах

для сети с номером 127; этот адрес не является адресом сети.

Интерпретащ1я вьзделенных адресов IPv4 представлена в табл. 5.9.

Таблица 5.9. Интерпретация

адресов ЕР

Поле адреса

1 Адрес сети Адрес узла

Все нули

Номер сети

Все нули

Номер узла

Все единищ»!

Номер сети

127

Все едишщы

Интерпретащм

Данный узел

Данная IP-сеть

Узел в данной (локальной) IP-сети

Все узлы в данной (локальной) IP-сети

Все узлы в указанной IP-сети

«Петля»

Поле «Данные», представленное на рис. 5.16, показьшает начало области

данных в дейтаграмме. Его длина зависит от того, что посьшается в дейта-

грамме.

Поле «Опции IP», рассматриваемое ниже, имеет переменную длину. Поле

«Заполнение» зависит от выбранных опций. Оно представляет собой биты, со-

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

таграммы до длины, кратной 32 бит (напомним, что поле длины заголовка ука-

зывает ее в 32-битньпс словах).

Межсетевые опции дейтаграммы. Поле «Опции IP», следующее за адре-

сом назначения, не нужно каждой дейтаграмме; опции включаются, в основном,

359