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

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

5. Сетевые

протоколы

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

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

роковещательно), при этом дополнение

(1А) не учитьшается.

Конфигурирование

RDP.

Общий порядок действий

при

конфигурировании

модуля RIP следующий:

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

RIP-систему;

• указать nonbroadcast networks, т. е. сети со статической маршрутизацией

(например,

тупиковые

сети,

подсоединенные к внешнему

миру через

единствен-

ный

шлюз),

куда не нужно рассьшать векторы расстояний;

• указать permanent routes - статические маршруты, например, маршрут по

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

Протокол REP очень прост, но так как он разрабатьшался для локальных

сетей, ему присущи следуюпще недостатки:

• малое значение бесконечности (из-за эффекта «счет до бесконечности»)

ограничивает размер RIP-системы четырнадцатью промежуточньш[и марш-

рутизаторами в любом направлении. Кроме того, по той же причине весьма

затрущпггельно использование

сложных

метрик,

учитьшающих

не просто

коли-

чество

промежуточных

маршрутизаторов,

но и скорость и качество

канала связи

(чем медленнее канал, тем больше метрика);

• само явление счета до бесконечности вызывает сбои в маршрутизации;

• широковещательная рассьшка векторов расстояний каждые 30 с ухудша-

ет пропускную способность сети;

• время схождения алгоритма при создании маршрутных таблиц достаточ-

но велико (по крайней

мере,

по сравнению

протоколами состояния связей);

• несмотря на

то

что каждый маршрутизатор начинает периодическз^о рас-

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

мер,

после включения), через некоторое время в системе наблюдается эффект

синхронизации маршрутизаторов,

сходный с эффектом

синхронизации

аплодис-

ментов. Все маршрутизаторы рассьшают свои вектора в один и тот же мо-

мент

времени,

что приводит к большим пикам трафика и отказам

маршрути-

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

полученных векторов;

• при использовании RIP таблица каждого маршрутизатора содержит пол-

ный список

всех

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

ним.

Она

вклю-

чает сотни или даже тысячи записей для большой объединенной IP-сети с

многочисленными

путями.

Поскольку максимальный размер одного RIP-паке-

та составляет 512 байт, то для отправления больших таблиц маршрутизации

необходимо множество RIP-пакетов.

•

таблице маршрутизации каждой записи

маршруте,

полученном

по

RIP,

назначен

3-минутный

тайм-^пг,

по истечение которого не обновленные записи

удаляются. Если маршрутизатор выходит из строя, распространение измене-

ний по

объединенной

сети может занять

несколько

минут.

Возникает проблема

медленной конвергенции.

390

5.5.

Протоколы

III

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

Протокол маршрутизации OSPF

Протокол маршрутизации OSPF (Open Shortest Path First) представляет со-

бой

протокол состояния связей, использующий алгоритм SPF поиска кратчай-

шего пути в графе. OSPF применяют для внутренней маршрутизации

систе-

мах сетей любой

сложности.

Рассмотрим работу алгоритма SPF и построение

маршрутов на примере OSPF-системы, состоящей из маршрутизаторов, со-

единенных линиями связи типа «точка-точка»

(рис.

5.43).

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

ном физическом канале); чем меньше метрика, тем лучше качество соедине-

ния. Метрика маршрута равна сумме метрик всех связей (сетей), входящих в

маршрут. В простейшем случае, как это имеет место в протоколе

RIP,

метрика

каждой сети равна единице, а метрика маршрута равна его длине в хопах.

Поскольку

при работе

алгоритма

SPF

ситуации, приводящие к

счету до

бес-

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

диапазоне. Кроме того, протокол OSPF позволяет определить для любой сети

различные значения метрик

зависимости

от типа

сервиса (тип сервиса запра-

шивается дейтаграммой в соответствии со значением поля «Тип обслужива-

ния» (ToS) ее заголовка.) Для каждого типа сервиса вычисляется свой марш-

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

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

канал -

по

другому.

Метрика сети, оценивающая пропускную способность, определяется как

количество секунд, требуемое для передачи 100 Мбит через физическую сре-

ду данной

сети.

Например, метрика сети на базе lOBase-T Ethernet равна 10, а

метрика вьщеленной линии 56 кбит/с - 1785. Метрика канала со скоростью

передачи данных

100

М бит/с и выше равна единице.

Порядок расчета

метрик,

оценивающих

надежность,

задержку

стоимость,

не определен. Администратор, желающий поддерживать маршрутизацию по

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

рики по этим параметрам.

^ R2

Рис.

5.43.

Пример структуры OSPF-системы:

R\,

R1,

R3,R4- маршрутгоаторы;

А,

В,

С,

D- связи,

1 -

- метрика каждой связи

391

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

От

До

Сеть

Метрика

Рис.

5.44. База данных

состояния связей

Если не требуется маршрутизация с учетом

типа сервиса (или маршрутизатор ее не поддер-

живает), используют метрику по умолчанию, рав-

ную метрике по пропускной способности. Имен-

но ее и будем использовать в дальнейшем.

Для работы алгоритма SPF на каждом марш-

рутизаторе строится база данных состояния свя-

зей,

представляющая собой полное описание гра-

фа OSPF-системы. При этом вершинами графа

являются маршрутизаторы, а ребрами - соеди-

няющие их связи. Базы данных на всех маршру-

тизаторах идентичны. За создание баз данных и

поддержку их взаимной синхронизации при из-

менениях в структуре системы сетей отвечают

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

OSPF.

Рассмотрим эти алгоритмы позже, а сей-

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

зом построены, синхронизированы и правильно описьгоают

граф

системы в дан-

ный момент времени.

База данных состояния связей (рис. 5.44) представляет собой таблицу, где

для каждой пары смежных вершин графа (маршрутизаторов) указано ребро

(связь), их соединяющее, и метрика этого ребра. Граф считается ориентиро-

ванным, т. е. ребро, соединяющее вершину RI с верышной i?2, и ребро, соеди-

няющее вершину R2c вершиной RI, могут быть различны или это может быть

одно и то же ребро, но с разными метриками.

Алгоритм поиска кратчайшего пути. Рассмотрим алгоритм SPF поис-

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

Е.В.

Дейкстрой

(Е.W.

Dijkstra). Алгоритм

SPF,

основьшаясь на базе данных состояния связей, вьшисляет кратчайшие

пути между заданной вершиной

S-графа

и всеми остальными вершинами. Ре-

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

V-графа указан список ребер, соединяющих заданную вершину S с вершиной

V по кратчайшему пути.

Введем следующие обозначения:

Е - множество обработанных вершин,

т.

е. вершин, кратчайший путь к кото-

рым от заданной вершины S уже найден;

—

множество оставшихся вершин графа (т. е. множество вершин графа за

вычетом множества Е);

О — упорядоченный список путей.

Шаг 1. Инициализировать

E={S},

К={все вершины графа, кроме

S}.

Поме-

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

отсортировав их в порядке возрастания метрик.

Шаг 2. Если О пуст или первый путь в О имеет бесконечную метрику, то

отметить все вершины в R как недостижимые и закончить работу алгоритма.

392

5.5.

Протоколы

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

Шаг 3. Рассмотрим Р - кратчайший путь в списке О. Удалить Р из О.

Пусть V - последний узел в

Р.

Если

е Е, перейти на шаг

иначе Р является

кратчайшим путем из

в V (будем записывать как

V:P);

перенести

из R

Е.

Шаг 4. Построить набор новых путей, подлежащих рассмотрению, путем

добавления к пути Р всех односегментных путей, начинающихся из

Метри-

ка каждого нового пути равна сумме метрики Р и метрики соответствующего

односегментного отрезка, начинающегося из

Добавить новые пути

упоря-

дочешп>1Й

список О, поместив их на места в соответствии со значениями мет-

рик. Перейти к шагу 2.

Все вычисления вычисляются локально по известной базе данных, а пото-

му

значительно быстрее

по

сравнению

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

ми,

при этом результаты получаются на основе полной,

а не

частичной инфор-

мащш о графе системы сетей.

Предположим, что к маршрутизатору

/?4

подключена сеть

компьютеров

(хостов) i/j -

Я^.

Следуя разобранной

вьппе

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

также вершиной графа OSPF-системы, хотя сам и не строит базу данных и не

производит вычисления

маршрутов.

Тем не

менее,

информащм

связях марш-

рутизатора R4 с каждым из хостов сети

ио метриках этих связей должна

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

могли построить маршруты от себя до этих хостов. Очевидно, что такая про-

цедура неэффективна. Вместо информации о связях с каждым хостом в базу

данных вносится информация о связи с сетью, т. е. сама IP-сеть становится

вершиной графа системы, соединенной

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

некоторой свя-

зью Р (рис. 5.45).

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

идентификатор

группы

хостов^

находящихся

в одной

IP-сети,

к которой марш-

рутизатор R4 непосредственно подключен. Вершина

Л^1

назьшается

тупико-

вой

сетью

(stub

network);

все узлы сети, обозначаемые этой вершиной, явля-

ются

хостами,

у которых

установлен маршрут

по

умолчанию,

направленный

на

маршрутизатор R4.

Рис.

5.45.

Дополнею1е

IP-сети

OSPF-систему

393

5. Сетевые

протоколы

От

До

Сеть

Метрика

Рис. 5.46. Запись в базе данных

для тупиковой сети

Протокол OSPF проводит разграничение хо-

стов и маршрутизаторов. Если к IP-сети

Л^1

под-

ключен еще и один из интерфейсов маршрути-

затора R2, то связь между R2 и R4 будет

установлена отдельно, как если бы они были

соединены двухточечной линией связи (при

этом у маршрутизатора R2 также будет связь с тупиковой сетью N1),

При подключении тупиковой сети N1 в базе данных состояния связей по-

явится запись (рис. 5.46).

Связей, направленных из вершины N1, в базе данньпс нет и не будет, потому

что вершина

Л^1

не является марпфутизатором. Построение маршрутов до вер-

шины N1 (т. е. фактически сразу до всех хостов сети N1) будет осуществлено

каждым маршрутизатором обычным способом по алгоритму SPF.

Поддержка множественных маршрутов. Если между двумя узлами сети

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

метриками, протокол OSPF позволяет направлять части трафика по этим мар-

шрутам в пропорщш, соответствующей значениям метрик. Например, если есть

два альтернативных маршрута с метриками 1 и 2, то две трети трафика будет

направлено по первому из них, а оставшаяся треть - по второму. Положитель-

ный эффект такого механизма заключается в уменьшении средней задержки

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

умень-

шении колебаний значения средней задержки.

Менее очевидное преимущество поддержки множественных маршрутов

состоит в следующем. Если при использовании только одного из возможных

маршрутов этот маршрут внезапно выходит из строя, весь трафик будет разом

перемаршрутизирован на альтернативный маршрут, при этом во время процес-

са массового переключения больших объемов трафика с одного маршрута на

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

Если же до аварии использовалось разделение трафика по нескольким марш-

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

что существенно сгладит нежелательные эффекты.

Рассмотрим следующий пример (рис. 5.47). Узел RI отправляет данные в

узел /гЗ, используя поддержку множествен-

ных маршрутов, по маршрутам С

(2/3

трафи-

ка) и АВ (1/3 трафика). Однако узел R2 тоже

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

тей,

и когда к нему пребывают дейтаграммы,

адресованные в R3 (в том числе, и отправ-

ленные из /?1), он применяет к ним ту же ло-

гику,

т.

е. 2/3 из них отправляет

R3 по марш-

руту 5, а одну треть - по маршруту АС,

Следовательно, 1/9 дейтаграмм, отправленньгс

узлом RI

узел

/?3,

возвращаются опять

узел

Рис. 5.47. Частичное защпсливание

/?1,

который 1/3 из них опять отправляет в R3

дейтаграмм по маршруту С, а 2/3 - по маршруту АВ через

394

5.5.

Протоколы

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

узел

J?2 И Т.

Д. В итоге сформировался «частичный цикл» при посьшке дейтаг-

рамм из i?l в i?3, который, помимо частичного зацикливания дейтаграмм, ве-

дет

быстрой перегрузке

линии

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

если

узел X

отправляет

данные в узел Y, он может пересылать их через

узел Q

только

в том случае, если Q блилсе к Y, чем к X,

В приведенном примере, следуя этому правилу, R\ не может посылать дан-

ные

в КЪ

через /f2, поскольку Kl не ближе

ЛЗ,

чем

/?1.

Однако такая посьшка

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

рис.5.47 эти значения приведены

скобках.

Для реализации построения дополнительных альтернативных маршрутов с

учетом вьппеприведенного правила

алгоритме ^PF необходимо внести изме-

нения в шаг 3 и добавить шаг

а. Ниже приведена новая версия алгоритма

SPF,

которой изменение

дополнение показаны курсивом.

Алгоритм SPF с поддержкой мноэюественных маршрутов.

Шаг 1. Инициализировать E={S}, К={все вершины графа, кроме S}. Поме-

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

вершины S, отсортировав их

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

Шаг 2. Если О пуст или первый путь в О имеет бесконечную метрику, то

отметить все вершины в R как недостижимые и закончить работу алгоритма.

Шаг 3. Рассмотрим Р - кратчайший путь в списке О. Удалить Р из О.

Пусть V - последний узел в Р. Если V принадлежит Е, перейти на шаг За;

иначе Р является кратчайшим путем из S в V; перенести V из R в Е. Перейти

на шаг 4,

Шаг За. Рассмотрим W, узел, предшествующий V в пути Р. Если расстоя-

ние от S до W меньше расстояния от S до V, то обозначим Р как приемлемый

альтернативный путь к V. В любом случае перейти на шаг 2.

Шаг 4. Построить набор новых путей, подлежащих рассмотрению, путем

добавления к пути Р всех односегментньпс путей, начинающихся из узла V.

Метрика каждого нового пути равна сумме метрики Р и метрики соответству-

ющего односегмешного отрезка, начинающегося из

Добавить новые пути в

упорядоченный список О, поместив их на места

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

метрик. Перейти на шаг 2.

Накладывающиеся маршруты. Пусть в графе OSPF-системы некий мар-

шрутизатор имеет связи с вершинами N и М, которые представляют сети хос-

тов,

подключенные

различным интерфейсам марпфутизатора. Это означает,

что в таблице маршрутов этого маршрутизатора, будет две записи: для сети N

и для сети М.

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

подсетью сети N. Например, IP-адрес сети N равен 172.16.0.0, а маска сети -

255.255.0.0; для сети М -172.16.5.0 и 255.255.255.0 соответственно.

395

5. Сетевые

протоколы

ЭТОМ

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

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

172.16.5.1 находится как в сети N, так и в сети М, но маска сети М длиннее,

следовательно, дейтаграмма, следующая по этому адресу, будет отправлена в

сеть М.

Внешние маршруты. Для достижения сетей, не входящих в OSPF-систе-

му (в автономную систему), используют пограничные маршрутизаторы ав-

тономной системы (ASBR - Autonomous System Border Router), имеющие

связи, уходящие за пределы системы.

ASBR вносят в базу данных состояния связей данные о сетях за пределами

системы, достижимых через тот или иной маршрутизатор ASBR. Такие сети, а

также ведущие к ним маршруты назьшаются внешними (external).

В простейшем случае, если в системе есть только OWXRASBR^

ОН

объявляет

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

ванные в сети, не входящие в базу данных системы, отправляются через этот

марпфутизатор. Если в системе несколько ASBR, то, возможно, внутренним

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

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

сеть.

Это делается на основе спещ1альных записей, вносимых ASBR в базу

данных системы. Такие записи содержат адрес и маску внешней сети и метри-

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

емыми в OSPF-системе. Если возможно, адреса нескольких внешних сетей

агрегируются в общий адрес с более короткой маской.

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

министратором

(в

том числе единственный маршрут

по

умолчанию) либо ASBR

может получать информащпо о внешних маршрутах от протоколов внешней

марпфутизации.

Построение базы данных состояния связей. Протокол Hello. После

ишщиализащш модуля OSPF (например, после подачи питания на маршрутиза-

тор) через все интерфейсы, включенные в OSPF-систему, начинают рассы-

латься Hello-сообщения. Задача Hello-протокола состоит в обнаружении сосе-

дей и установлении с ними отношений смежности. Соседями называют

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

обменивающиеся Hello-сообщениями. Смеэ/сными назьюают соседние OSPF-

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

формацией, необходимой для синхронизащш базы данных состояния связей и

построения маршрутов. Не все соседи становятся смежными.

Д^)угой задачей протокола Hello является выбор вьщеленного маршрутиза-

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

шрутизаторов.

Hello-пакеты периодически рассьшаются и после того, как соседи обнару-

жены. Так маршрутизатор контролирует состояние своих связей с соседями и

может своевременно обнаружить изменение этого состояния (например, об-

рыв связи или отключение одного из соседей). Обрью связи можно также об-

396

5.5.

Протоколы

III уровня

стека

TCP/IP

наружить и с помощью

протокола

канального

уровня,

которьш просигнализиру-

ет о недоступности канала.

сетях

возможностью широковещательной рассьшки (broadcast networks)

Hello-пакеты рассылаются

по

мультикастинговому адресу 224.0.0.5 («Всем

OSPF-маршрутизаторам»).

других сетях

все

возможные адреса соседей

должны быть введены администратором.

Протокол обмена. После установления отношений смежности

для

каж-

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

их баз

данных. Эта

же

операщм проводится при восстановлении ранее разорванного

соединения,

поскольку

образовавшихся

после

аварии

двух

изолированных

под-

системах базы данных развивались независимо друг

от

друга.

Синхронизация

баз данных происходит

помощью

протокола обмена

(Exchange protocol).

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

баз

дан-

ных (Database Description), содержащими идентификаторы записей

номера

их версий,

что

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

ных,

если нужно синхронизировать

только

несколько.

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

содержимое которых

он

должен запросить (т.

е. эти

записи

в его

базе данных

устарели либо отсутствуют),

соответственно отправляет пакеты запросов

состоянии связей (Link State

Request).

В ответ

он

получает содержимое после-

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

зей (Link State Update)».

После синхронизации баз данных осуществляется построение маршрутов,

как описано ранее.

Протокол затопления. Каждый маршрутизатор отвечает

за те и

только

те записи

базе данных состояния связей, которые описьшают связи,

исходя-

щие

от

данного

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

Это

означает,

что при

образовании новой связи,

изменении

состоянии связи или

ее

исчезновении (обрьше), маршрутизатор,

ответственный

за

эту

связь,

должен соответственно изменить

свою копию

базы

данных

немедленно известить все остальные маршрутизаторы

OSPF-CHCTQ-

мы

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

копии базы

данных.

Подпротокол OSPF, выполняющий

эту

задачу, называется

протоколом

затопления (Flooding protocol). Этот протокол пересьшает сообщения типа

«Обновление состояния связей (Link State Update)», получение которых под-

тверждают сообщения типа «Link State Acknowledgment».

Каждая запись

состоянии связей имеет свой номер (номер версии), кото-

рый также хранится

базе данных. Каждая новая версия записи имеет ббль-

ший

номер.

При

рассьшке сообщений

об

обновлении записи

в базе

данных но-

мер записи также включается

сообщение

для

предотвращеьшя попадания

базу данных устаревших версий.

397

5. Сетевые

протоколы

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

лает сообщение «Обновление состояния связи» по всем интерфейсам. Однако

новые версии состояния одной и

той

же

связи должны

появляться не чаще, чем

оговорено определенной константой. Далее на всех маршрутизаторах OSPF-

системы действует следующий алгоритм.

Получить сообщение. Найти соответствующую запись в базе данных.

Если запись не найдена, добавить ее в базу данных, передать сообщение

по всем интерфейсам.

Если номер записи в базе данных меньше номера пришедшего сообще-

ния,

заменить запись в базе данньпс, передать сообщение по всем интерфей-

сам.

Если номер записи

базе данных больше номера пришедшего сообщения

и эта запись не бьша недавно разослана, разослать содержимое записи из базы

данных через тот интерфейс, откуда пришло сообщение. Понятие «недавно»

определяется значением константы.

5. В случае равных номеров записей сообщение игнорировать.

Протокол OSPF устанавливает для записи характеристику возраст. Возраст

равен нулю при создании записи в базе данньгс. При затоплении OSPF-систе-

мы

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

лирует сообщение, увеличивает возраст

записи на

определенную

величину.

Кро-

ме этого, возраст увеличивается на единицу каждую секунду. Из-за разнищ>1

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

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

маршрутизаторах может несколько различаться.

При

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

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

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

данных.

Поскольку базы данных на всех маршрутизаторах системы должны быть

идентичны, просроченная запись должна

быть

удалена

из

всех копий

базы

дан-

ных на всех марпфутизаторах. Это осуществляется с использованием прото-

кола затопления: маршрутизатор затапливает систему сообщением с просро-

ченной записью. Соответственно, в описанный выше алгоритм обработки

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

общения и удалением соответствующей записи из базы данных.

Чтобы записи в базе данньпс не устаревали, маршрутизаторы, ответствен-

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

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

мое записей

этих сообщениях неизменно, но номер версии больше,

возраст

равен

нулю.

398

5.6.

Протоколы

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

Вышеописанные протоколы обеспечивают актуальность информации, со-

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

изменения

топологии системы

сетей и

синхронизацию

копий базы

данных

на

всех маршрутизаторах системы. Для обеспечения надежности передачи дан-

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

контрольная сумма. В протоколе OSPF может быгь применена ^пгентифика-

ция

сообщений.

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

Протокол управления передачей TCP

Основные характеристики и понятия протокола. Протокол управле-

ния

передачей

TCP

(Transmission Control Protocol) является протоколом транс-

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

вым протоколом IP. Основная задача TCP - обеспечение надежной передачи

данных в сети. Его транспортный адрес в заголовке 1Р-сегмента равен

Опи-

сание протокола TCP дано в RFC 793.

Основные характеристики протокола

TCP

следующие:

• реализует взаимодействие

режиме

установлением логического (вирту-

ального) соединения;

• обеспечивает двунаправленную дуплексную связь;

• организует потоковый (с точки зрения пользователя) тип передачи дан-

ных;

• дает возможность пересылки части данных как «экстренных»;

•

для

идентификации партнеров

по

взаимодействию

на

транспортном

уров-

не использует 16-битовые «номера портов»;

• реализует принцип «скользящего окна» (sliding window) для повьппения

скорости передачи;

• поддерживает ряд механизмов для обеспечения надежной передачи дан-

ных.

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

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

редаче данньпс между любыми

прикладными

процессами,

вьшолняюцщмися

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

кола IP

доставлен

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

кон-

кретному процессу-получателю. Каждый

компьютер может выполнять

несколь-

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

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

Пакеты,

поступающие на транспортный

уровень,

организуются операцион-

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

ных процессов. В терминологии ТСРЯР такие системные очереди назьюают

портами.

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

ном

уровне,

является идентификатор (номер) порта прикладного сервиса. Но-

мер

порта,

задаваемый транспортным

уровнем,

совокупности

номером сети

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

ляют прикладной процесс

сети.

399