102
1 Основные Интернет протоколы 8. Протоколы маршрутизации (RIP, OSPF и BGP) Интернет – это комбинация сетей, соединяемых с помощью маршрутизаторов. Когда дейтаграмма идет от источника к пункту назначения, она, вероятнее всего, проходит много маршрутизаторов, пока достигает маршрутизатора, закрепленного за сетью пункта назначения. Маршрутизатор получает пакет от сети и передает его другой сети. Маршрутизатор обычно закрепляется за несколькими сетями. Когда он получает пакет, он должен решить две задачи: 1. к какой сети он должен его передать; 2. по какому пути. Последнее решение основано на выборе оптимального пути. Какой доступный путь является оптимальным путем? Это обычно определяется метрикой. Метрика – это условная стоимость передачи по сети. Полное измерение конкретного маршрута равно сумме метрик сетей, которые включают в себя маршрут. Маршрутизатор выбирает маршрут с наименьшей метрикой. Метрика назначается для интерфейса сети в зависимости от типа протокола. Некоторые простые протоколы, подобно протоколу маршрутной информации (RIP – Routing Information Protocol), рассматривают все сети как одинаковые. Тогда стоимость прохождения через каждую сеть — одна и та же, и для определения метрики подсчитываются участки. Так, если пакет, чтобы достигнуть конечного пункта, проходит через 10 сетей, полная стоимость составляет 10 участков. Другие протоколы, такие как "первоочередное открытие наикратчайших путей" (OSPF — Open Shortest Path First), позволяют администратору назначить стоимость для передачи через сеть, основанную на типе требуемого обслуживания. Маршрут через сеть может иметь различную стоимость (метрику). Например, если для типа сервиса желательна максимальная производительность, спутниковый канал имеет меньшую метрику, чем оптическая линия. С другой стороны, если типу сервера желательна минимальная задержка, оптическая линия имеет меньшую метрику, чем спутниковый канал. OSPF позволяет каждому маршрутизатору иметь таблицу последовательностей маршрутов, основанную на требуемом типе сервиса. Другие протоколы определяют метрику различно. В протоколе пограничной маршрутизации (BGP — Border Gateway Protocol) критерий — это политика, которую может устанавливать администратор. Политика это принцип, по которому определяется путь. В любой метрике маршрутизатор должен иметь таблицы маршрутизации, чтобы консультироваться при дальнейшей передаче пакета. Таблица маршрутизации задает оптимальный путь для пакета. Таблица может быть либо статическая, либо динамическая. Статическая таблица — одна из тех, которые часто не меняются. Динамическая таблица — одна из тех, которая обновляется автоматически, когда имеются изменения где-либо в Интернете. Сегодня Интернет нуждается в динамических таблицах. Таблицы нужно обновлять по мере появления изменений в Интернете. Например, их нужно обновить, когда маршрут вышел из строя, или они должны быть обновлены всякий раз, когда создается лучший маршрут.

Osnovnije Internet Protokoli 4

  • Upload
    -

  • View
    76

  • Download
    2

Embed Size (px)

Citation preview

Page 1: Osnovnije Internet Protokoli 4

1

Основные Интернет протоколы

8. Протоколы маршрутизации (RIP, OSPF и BGP)

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

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

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

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

Маршрутизатор обычно закрепляется за несколькими сетями. Когда он получает пакет, он

должен решить две задачи:

1. к какой сети он должен его передать;

2. по какому пути.

Последнее решение основано на выборе оптимального пути. Какой доступный путь

является оптимальным путем? Это обычно определяется метрикой. Метрика – это

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

сумме метрик сетей, которые включают в себя маршрут. Маршрутизатор выбирает

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

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

маршрутной информации (RIP – Routing Information Protocol), рассматривают все сети как

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

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

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

Другие протоколы, такие как "первоочередное открытие наикратчайших путей" (OSPF —

Open Shortest Path First), позволяют администратору назначить стоимость для передачи

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

иметь различную стоимость (метрику). Например, если для типа сервиса желательна

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

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

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

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

основанную на требуемом типе сервиса.

Другие протоколы определяют метрику различно. В протоколе пограничной

маршрутизации (BGP — Border Gateway Protocol) критерий — это политика, которую

может устанавливать администратор. Политика — это принцип, по которому

определяется путь.

В любой метрике маршрутизатор должен иметь таблицы маршрутизации, чтобы

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

оптимальный путь для пакета. Таблица может быть либо статическая, либо динамическая.

Статическая таблица — одна из тех, которые часто не меняются. Динамическая

таблица — одна из тех, которая обновляется автоматически, когда имеются изменения

где-либо в Интернете. Сегодня Интернет нуждается в динамических таблицах. Таблицы

нужно обновлять по мере появления изменений в Интернете. Например, их нужно

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

когда создается лучший маршрут.

Page 2: Osnovnije Internet Protokoli 4

2

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

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

позволяют в Интернете маршрутизаторам информировать друг друга об изменениях.

Протоколы маршрутизации также включают процедуры для комбинирования

информации, полученной от других маршрутизаторов.

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

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

Внутренняя и внешняя маршрутизация

Сегодня Интернет — громадная сеть, так что один протокол маршрутизации не может

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

Интернет разделяется на автономные системы. Автономная система (Autonomous System –

AS) — группа сетей и маршрутизаторов под управлением одного администратора.

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

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

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

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

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

протокол маршрутизации.

Разработано несколько внутренних и внешних протоколов. В этой лекции мы коснемся

только наиболее популярных из них — внутренних протоколов RIP и OSPF и одного

внешнего протокола BGP. RIP и OSPF используются для обновления таблиц

маршрутизации внутри автономной системы. Протокол BGP применяется в обновлении

таблиц маршрутизации для маршрутизаторов, которые объединяют вместе автономные

системы.

Протокол маршрутной информации (RIP)

Протокол маршрутной информации (RIP – Routing Information Protocol) — внутренний

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

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

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

применяется в RIP, а затем обсудим сам протокол RIP.

Вектор расстояния маршрутизации

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

делится своей информацией о входах в Интернет со своими соседями. Ниже приводятся

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

1. Распределение информации о входе в автономную систему. Каждый

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

Вначале эта информация может быть не подробной. Однако объем и качество

информации не играют роли. Маршрутизатор посылает, во всяком случае, все что имеет.

2. Распределение только соседям. Каждый маршрутизатор посылает свою

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

интерфейсы.

Page 3: Osnovnije Internet Protokoli 4

3

3. Распределение через регулярные интервалы. Каждый маршрутизатор посылает

свою информацию соседней автономной системе через фиксированные интервалы,

например, каждые 30 с.

Таблицы маршрутизации

Каждый маршрутизатор хранит таблицы маршрутизации, имеющие один вход для каждой

сети назначения, которую маршрутизатор зарегистрировал. Вход содержит:

• адрес сети пункта назначения,

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

участках,

• следующий участок (следующий маршрутизатор), к которому должен быть

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

• счетчик участков – это число сетей, которые пакет пересечет для достижения

своего конечного пункта назначения.

Таблица может содержать другую информацию, такую как маску подсети (или префикс)

или время, когда этот вход был обновлен. Табл. 8.1. показывает пример таблицы

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

Таблица 8.1. Таблица вектора расстояния маршрутизации

Номер входа в

таблицу участков

Пункт

назначения

Счет

участков

Следующий

участок

Другая

информация

0 163.5.0.0 7 172.6.23.4

1 197.5.13.0 5 176.3.6.17

2 189.45.0.0 4 200.5.1.6

3 115.0.0.0 6 131.4.7.19

Алгоритм обновления таблиц в RIP

Таблица маршрутизации обновляется после получения "квитанции" ответного сообщения

RIP. На рис. 8.1 показан алгоритм модификации, использованный RIP.

Page 4: Osnovnije Internet Protokoli 4

4

Рис. 8.1. Алгоритм обновления таблицы маршрутизации

На рис. 8.2 показан пример обновления таблицы. Маршрутизатор получает RIP-

сообщение от соседнего маршрутизатора. Сообщение перечисляет сети пунктов

назначения и их соответствующие счетчики участков. Первый шаг соответствует

алгоритму обновления по рис. 8.1. Он увеличивает счетчики участков сообщения на

единицу. Следующий шаг алгоритма RIP обновления: таблица, полученная в сообщении,

и старая таблица маршрутов сравниваются. Результат — это таблица маршрутизации с

обновленными счетчиками участков для каждого пункта назначения. Для "Сети 1" нет

новой информации в сообщении, поэтому вход "Сети 1" остается без изменений.

Page 5: Osnovnije Internet Protokoli 4

5

Рис. 8.2. Пример обновления таблицы

Для "Сети 2" информация в таблице и сообщения определены как счетчик участков от

маршрутизатора C. Хотя значения счета участков (см. рис. 8.2) в таблице (2) меньше, чем

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

что исходное значение пришло от того же самого маршрутизатора C.

"Сеть 3" в таблице отсутствует, в таблицу устанавливается значение сообщения. Таблица

дополняется новой сетью. Для "Сети 6" RIP-сообщение содержит меньшее значение

счетчика участков, поэтому значение маршрутизатора F, содержащееся в таблице,

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

таблицу записывается значение счетчика участков, содержащееся в сообщении. "Сеть 8"

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

сообщении равен значению аналогичного счетчика в таблице. "Сеть 9" в сообщении имеет

большее значение, но оно не касается узла, от которого пришло сообщение, поэтому в

новой таблице сохраняется старое значение.

Инициализация таблицы маршрутизации

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

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

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

Следующее поле участка, которое идентифицирует следующий маршрутизатор, пустое.

Обновление таблицы маршрутизации

Page 6: Osnovnije Internet Protokoli 4

6

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

алгоритм обновления, рассмотренный выше.

Формат сообщения RIP

Формат сообщения RIP показан на рис. 8.3.

Рис. 8.3. Формат RIP сообщения

• Команда. Это поле 8 бит задает тип сообщения: запрос (1) или ответ (2).

• Версия. Это поле 8 бит определяет версию. В этой книге мы используем версию 1,

но в конце этого раздела мы назовем некоторые особенности версии 2.

• Семейство. Это поле 16 бит определяет семейство используемых протоколов. Для

TCP/IP значение равно 2.

• Адрес сети. Поле адрес определяет адрес пункта назначения. RIP отводит 14 байт

для этого поля в приложении к любым протоколам. Однако IP в настоящее время

использует только 4 байта. Остаток адреса заполняется нулями.

• Расстояние. Это поле 32 бита определяет счет участков для каждого объявленного

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

Заметим, что часть сообщения повторяется для каждой сети назначения. Эта часть

относится к понятию вход.

Запрос и ответ

RIP имеет два типа сообщения: запрос и ответ.

Запрос

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

или маршрутизатором, который запущен по таймауту. Запрос может запрашивать о

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

сетевой адрес, во втором — все поле заполняется нулями.

Ответ

Ответ может быть двух типов: либо запрошенный, либо не запрошенный. Запрошенный

ответ посылается только в ответ на запрос. Он содержит информацию о пункте

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

периодически, каждые 30 с., и содержит информацию о входе в таблицу маршрутизации.

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

Таймеры в RIP

Page 7: Osnovnije Internet Protokoli 4

7

RIP использует три таймера для поддержки своих операций: периодический таймер

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

третий таймер собирает мусор объявленных ошибочными маршрутов.

Периодический таймер

Периодический таймер контролирует объявленные регулярные и сообщения обновления.

Хотя протокол задает, что этот таймер может быть установлен на 30 с., работающая

модель использует случайное число между 25 и 35 с. Это сделано, чтобы предотвратить

любую возможную синхронизацию и, в связи с этим, перегрузку Интернета, если

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

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

устанавливается случайно между 25 и 35. Он отсчитывает время назад; когда достигается

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

величину.

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

периодический таймер не подходит. Сообщения периодического обновления выходят по

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

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

Таймер истечения срока

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

получает информацию обновления для маршрута, таймер окончания устанавливается на

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

маршрута, таймер переустанавливается. В нормальной ситуации это возникает каждые 30

с. Однако если имеются проблемы в Интернете и не получено обновление в течение

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

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

имеет свое собственное время окончания.

Таймер сбора мусора

Когда поступила некорректная информация о маршруте, маршрутизатор не сразу стирает

маршрут из своей таблицы. Вместо этого он продолжает объявлять маршрут со значением

счетчика 16. На это время таймер называется таймером сбора мусора и устанавливается на

120 с. для этого маршрута. Когда счет достигает нуля, маршрут стирается из таблицы. Это

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

он будет изъят.

Медленная сходимость

Одна из проблем RIP — медленная сходимость, то есть изменения, произошедшие на

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

Интернет. Допустим, имеется изменение на "Сети 1", управляемой маршрутизатором R1.

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

периодические обновления каждые 30 с., то пройдет в среднем 15 с. (в пределах от 0 до

30), прежде чем изменения достигнут следующего узла (обозначим его R2). Если

распространить эти рассуждения на другие участки (среднее время 15 с.), то пройдет 30 с.

до того момента, когда третий маршрутизатор (R3) получит изменения, и так далее. Когда

Page 8: Osnovnije Internet Protokoli 4

8

информация, в конечном счете, достигает маршрутизатора Rn, проходит 15 * (n – 1) с.

Если n = 20, тогда это 285 с. За это время сеть ATM может передать более чем один

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

миллиарды бит.

Один метод сокращения этого недостатка — лимитировать счетчик участков до 15. Это

предотвращает пакеты данных от вечного блуждания – "зацикливания" Интернета.

Автономная система, используемая RIP, ограничена числом переприемных участков 15.

Поэтому число 16 означает недостижимую сеть.

Нестабильность

Гораздо более важная проблема RIP — нестабильность, которая означает, что сеть

Интернет, работающая по протоколу RIP, может стать нестабильной.

Это случается, когда пакет от одного маршрутизатора к другому может идти по петле.

Ограничение участков в 15 будет увеличивать стабильность, но не снимет все проблемы.

Для того чтобы понять проблему, предположим, что соединение к Сети 1 на рис. 8.4. не

работает. Маршрутизатор A показывает стоимость 1 для этой сети в его таблице

маршрутизации. Когда доступ определяет, что Сеть 1 повреждена, маршрутизатор A

немедленно изменяет колонку стоимости Сети 1 на 16 (бесконечность). Однако он должен

ждать 30 с., прежде чем послать свое обновление с этой новой информацией. Тем

временем может случиться, что маршрутизатор B посылает сообщение собственного

обновления к A. Маршрутизатор A теперь имеет два входа для Сети 1: от своей таблицы

(стоимость равна 16) и от маршрутизатора B (стоимость равна 2). Согласно алгоритму

обновления A заменяет доступ к сети Сеть 1 через более короткий путь B. Маршрутизатор

A затем изменяет колонку стоимости (счетчик участков) для Сети 1 на 3 (2+1), и это

обновление идет к B. Маршрутизатор B знает, что Сеть 1 доступна через маршрутизатор

A, согласно алгоритму обновления изменяет свою стоимость до 4 (3+1). Это обновление

"туда и обратно" продолжается, пока оба маршрутизатора достигнут стоимости 16. На

этой точке маршрутизаторы останавливаются, и соединение к Сети 1 становится

недостижимым.

Page 9: Osnovnije Internet Protokoli 4

9

Рис. 8.4. Пример нестабильной работы сети

Некоторые средства увеличения стабильности

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

не является эффективным на 100 процентов.

Запускаемое обновление

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

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

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

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

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

интервалом времени, чем в среднем за 15 с. Например, на рис. 8.4, когда маршрутизатор A

распознает, что Сеть 1 недоступна, он изменяет стоимость до 16 в таблице маршрутизации

и затем немедленно посылает эти сведения к B. Маршрутизатор B затем изменяет свою

таблицу, и теперь обе таблицы показывают стоимость 16 для Сети 1. Рассылаемые

Page 10: Osnovnije Internet Protokoli 4

10

сообщения обновления с изменениями приращения в стоимости позволяют избежать

любых проблем зацикливания.

Хотя запускаемое обновление может значительно улучшить маршрутизацию, оно не

может решить все проблемы маршрутизации. Например, ошибка маршрутизатора не

может быть обнаружена этим методом.

Расщепление горизонта

Второй метод для улучшения стабильности — "расщепленный горизонт" (spilt horizon).

При этом методе данные о достижимых узлах сети передаются регулярно всем

маршрутизаторам, кроме того, от которого эта информация исходит. Если маршрутизатор

передал информацию, чтобы помочь обновлению, эта информация не должна быть

послана назад; он уже все знает. "Расщепленный горизонт" может улучшить стабильность.

Предположим, что на рис. 8.4 Сеть 1 недоступна маршрутизатору А. Маршрутизатор B

принимает свою информацию о Сети 1 из А и не посылает информацию о Сети 1 к

маршрутизатору А. Маршрутизатор поэтому имеет один сигнал для Сети 1 стоимостью 1

и не обманывается, думая, что имеет обходной доступ к Сети 1 через маршрутизатор B.

Маршрутизатор А посылает свою таблицу маршрутизации к B, и оба будут иметь в

таблице значение 16.

Поглощение ответа

Поглощение ответа – вариант "расщепленного горизонта". В этом методе информация,

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

всем интерфейсам. Однако вход таблицы, который получил информацию через

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

рассылки обновления.

При использовании поглощения возврата стабильность улучшается. Рассмотрим снова

рис. 8.4 Маршрутизатор B получает информацию о Сети 1 от А. В каждом обновлении B

посылает свою таблицу маршрутизации к А со значением 16 для Сети 1. Это

неэффективно на А, если Сеть 1 недоступна, потому что он не будет проверять входы B

для Сети 1 и устанавливать значение 16. Однако если Сеть 1 не испорчена, он будет

устанавливать меньшее значение.

RIP версии 2

RIP версии 2 был разработан для преодоления некоторых недостатков версии 1.

Разработчики версии 2 не дополнили длину сообщения для каждого входа. Они только

заменили те поля в версии 1, которые были заполнены нулями для TCP/IP-протокола,

некоторыми новыми полями.

Формат сообщения

Pис. 8.5 показывает формат сообщения RIP версии 2. Новые поля этого сообщения

приводятся ниже.

Page 11: Osnovnije Internet Protokoli 4

11

Рис. 8.5. Формат RIP версии 2

• Тэг маршрута. Это поле переносит такую информацию, как номер автономной

системы. Он может использоваться для обеспечения возможности RIP получать

информацию от внешнего протокола маршрутизации.

• Маска подсети. Это поле в 4 байта, которое несет маску к подсети (или префикс).

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

междометную маршрутизацию CIDR (Classless Inter Domain Routing).

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

системы вместе используют сеть (основную). По этому сообщению можно определить

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

должен пройти пакет.

Аутентификация

Аутентификация дополняет защиту сообщения против неполномочного объявления, но

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

информация для аутентификации. Чтобы указать, что вход содержит информацию

аутентификации, а не информацию маршрутизации, вводится значение FFFF16 в поле

семейство ( рис. 8.6). Второе поле, тип аутентификации, определяет метод, используемый

для аутентификации, а третье поле содержит реальные данные аутентификации.

Рис. 8.6. Аутентификация

Множественный доступ (Multicasting)

Версия 1 RIP использует широковещательный доступ, чтобы посылать сообщения RIP к

каждому соседу. При этом методе все маршрутизаторы в сети получают пакеты, так же

как и хосты. В RIP версии 2 используют множественный доступ с адресом 224.0.9 для

сообщений только RIP-маршрутизаторов в сети.

Инкапсуляция

Page 12: Osnovnije Internet Protokoli 4

12

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

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

UDP пакета. Закрепленным (well-known) портом назначается для RIP в UDP порт 520.

Первоочередное открытие кратчайших путей (OSPF — Open Shortest Path First)

Протокол "первоочередное открытие кратчайших Путей" (OSPF — Open Shortest Path

First) — это другой внутренний протокол, который получил популярность. Его область

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

маршрутизатором автономных систем, отвечает за распространение информации об

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

эффективно и вовремя, OSPF разделяет автономную систему на зоны.

Зоны

Зона — это набор всех сетей, хостов и маршрутизаторов, содержащихся в автономной

системе (рис. 8.7). Автономная система может разделяться на много различных зон. Все

сети внутри зоны должны быть соединены.

Рис. 8.7. Зоны автономной системы

Маршрутизаторы внутри зоны содержат зоновую информацию маршрутизации. На

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

маршрутизаторами зоны, суммируют информацию о зоне и посылают другим зонам.

Среди зон внутри автономной системы есть специальная зона, называемая основной. Все

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

говоря, основная зона обслуживает как первичная зона, а другие зоны — как вторичные.

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

каждый с каждым.

Маршрутизатор внутри основной зоны называется основным маршрутизатором. Заметим,

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

Отметим одну из проблем: если соединение между основной зоной и любой зоной

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

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

зоны.

Каждая зона имеет идентификатор зоны.

Page 13: Osnovnije Internet Protokoli 4

13

Метрика

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

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

задержка, максимальное число переприемов и так далее). Фактически, маршрутизатор

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

сервиса.

Маршрутизация по состоянию канала

Для обновления таблиц маршрутизации OSPF использует маршрутизацию по состоянию

канала. Маршрутизация по состоянию линии — процесс, при помощи которого каждый

маршрутизатор распространяет свою информацию о его соседях каждому

маршрутизатору в зоне.

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

1. Распределение информации об окружении. Каждый маршрутизатор посылает

информацию о состоянии своего окружения для каждого другого маршрутизатора зоны.

2. Распределение информации другим маршрутизатором. Каждый маршрутизатор

посылает информацию о состоянии окружения для каждого другого маршрутизатора

зоны. Он делает это с помощью волнового процесса. При его помощи маршрутизатор

посылает свою информацию всем другим соседям (через все выходные порты). Каждый

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

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

маршрутизатор (без исключения) получает копию одной и той же информации.

3. Распределение информации, когда имеются изменения. Каждый маршрутизатор

распределяет информацию о состоянии его окружения, только когда есть изменения. Это

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

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

Идея маршрутизации по состоянию линии – это то, что каждый маршрутизатор должен

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

маршрутизатор должен иметь полную "картину" Интернета. Исходя из этой топологии,

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

Топология здесь означает граф существующих узлов и границ. Однако для того чтобы

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

Типы связей

В OSPF-терминологии соединение называется связь (link). Определены четыре типа связи:

"точка-точка", транзит, ответвление и виртуальная.

Связь "точка-точка". Связь "точка-точка" соединяет два маршрутизатора без участия

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

(сети) — соединить два маршрутизатора. Например, этот тип связи представляют два

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

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

представляется узлами графа, и связь представляется двунаправленной границей,

соединяющей эти узлы. Метрика, которая обычно одна и та же, показана для двух концов,

Page 14: Osnovnije Internet Protokoli 4

14

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

одного соседа на другой стороне линии (рис. 8.8).

Рис. 8.8. Связь "точка-точка"

Транзитная связь. Транзитная связь – это сеть с несколькими маршрутизаторами,

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

покинуть сеть через любой другой. Все локальные сети (LAN) и глобальные сети (WAN) с

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

маршрутизатор имеет несколько соседей. Например, рассмотрим сеть Ethernet на рис. 8.9

а. Маршрутизатор A имеет соседей B, C, D. Маршрутизатор B имеет соседей A, C, D.

Отношение соседей в этой ситуации показано в виде графа на рис. 8.9 а.

На рис. 8.9 б показана транзитная связь в сети типа "каждый с каждым". Такой тип

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

маршрутизаторов. При числе таких соседей n число связей = C2 n. Это не эффективно и

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

и в телефонных сетях.

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

Рис. 8.9. Транзитная связь

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

(сеть) имеет четырех соседей. Мы видим, что число оповещаемых соседей уменьшилось

до 8 (поскольку связь двунаправленная). Однако пока имеется метрика от каждого узла к

назначенному маршрутизатору, нет метрики от назначенного маршрутизатора ни к

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

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

Ответвление связи – это сеть, которая подключает только один маршрутизатор. Пакеты

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

самый маршрутизатор. Это специальный случай транзитной сети.

Page 15: Osnovnije Internet Protokoli 4

15

Виртуальная линия. Когда линия между двумя маршрутизаторами повреждена,

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

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

Извещение о состоянии связи

Для того чтобы распределять информацию о соседях, каждый вход распределяет

извещения о состоянии связи (Link State Advertisements – LSAs). LSA извещают состояние

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

различных извещений о состоянии связи (LSAs), которые различаются объектами

рассылки:

• связь маршрутизатора;

• сетевая связь (узловым маршрутизатором);

• суммарная связь к автономной системе;

• внешняя связь.

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

маршрутизатору. Маршрутизатор использует для извещения информацию обо всех его

связях и связях соседей.

Сетевая связь. Узловой маршрутизатор от имени всей транзитной сети распределяет этот

тип LSA-пакетов. Пакеты извещают о состоянии всех маршрутизаторов, подключенных к

сети.

Суммарная связь сети. Информация о линиях маршрутизаторов и сетевых линиях внутри

зоны распространяется внутри зоны. Информация о состоянии линий вне зоны

распространяется пограничным маршрутизатором. Пограничный маршрутизатор зоны

действует более чем в одной зоне. Он получает извещения о линиях маршрутизатора

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

этих зон. Например, на рис. 8.10 маршрутизатор R1 есть пограничный маршрутизатор.

Рис. 8.10. Суммарная связь сети

Он имеет две таблицы маршрутизации, одна для зоны 1 и одна для зоны 0. R1 заполняется

информацией о зоне 1 и вторая — информацией о том, как достигнуть сети,

расположенной в зоне 0. Тем же самым способом маршрутизатор R2 заполняется

информацией о зоне 2 и о том, как достигнуть по этой же самой сети зоны 0. Суммарная

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

Page 16: Osnovnije Internet Protokoli 4

16

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

виртуальная.

Суммарная связь к пограничному маршрутизатору автономной системы. Предыдущее

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

чтобы выбрать маршрут внутри автономной системы. Если маршрутизатор внутри зоны

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

пограничному маршрутизатору автономной системы. Суммарная линия к пограничному

маршрутизатору автономной системы (АС) обеспечивает эту информацию. Зоновый

пограничный маршрутизатор заполняет их зоны этой информацией ( рис. 8.11).

Рис. 8.11. Суммарная связь к пограничному маршрутизатору автономной системы

Внешняя связь. Извещения внешней связи обеспечивают информацией о том, какая сеть

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

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

сеть. Если имеется более чем одна сеть, делаются отдельные извещения.

База данных состояний линии

Каждый маршрутизатор в зоне получает линию LSAs маршрутизатора и сетевую линию

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

База данных состояния связи – это таблица, представляющая топологию Интернета

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

включая метрику.

Алгоритм Дейкстры

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

баз данных состояния линии этого маршрутизатора (рис. 8.12). Алгоритм Дейкстры

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

и границ. Алгоритм разделяет узлы на два множества: пробные и постоянные. Он

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

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

нижеследующие шаги.

Page 17: Osnovnije Internet Protokoli 4

17

Рис. 8.12. Алгоритм вычисления наикратчайших путей

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

сеть представлена в виде графа. На этом графе нанесена назначенная стоимость

прохождения по участкам. Далее на рис. 8.13 б приводится вычисление накопленной

стоимости при прохождении.

Page 18: Osnovnije Internet Protokoli 4

18

Рис. 8.13. Вычисление стоимости наикратчайшего участка

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

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

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

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

направления с накопленной стоимостью 14 и 10. При этом сохраняется направление с

накопленной стоимостью 10, а второе удаляется.

Таблицы маршрутизации

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

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

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

сети, суммарной линии пограничного маршрутизатора и внешней линии. Табл. 8.2

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

вычислений по рис. 8.13 в.

Таблица 8.2. Таблица состояния линий для маршрутизатора A

Сеть Стоимость Следующий маршрутизатор Другая информация

N1 5

N2 7 C

N3 10 D

Page 19: Osnovnije Internet Protokoli 4

19

N4 11 B

N5 15 D

Типы пакетов

OSPF использует пять различных типов пакетов: пакет "hello", пакет распределения базы

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

подтверждения состояния линии.

Формат пакета

Все OSPF-пакеты имеют один и тот же состав заголовка (рис. 8.14). Перед изучением

различных типов пакетов рассмотрим этот общий заголовок.

Рис. 8.14. Заголовок пакета OSPF

Версия. Это поле 6 бит, определяющее версию протокола OSPF. Текущая версия — 2.

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

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

Длина сообщения. Это поле 16 бит определяет длину всего сообщения, включая

заголовок.

• IP-адрес маршрутизатора источника. Это поле 32 бита определяет IP-адрес

маршрутизатора, посылающего пакет.

• Идентификация зоны. Это поле 32 бит определяет зону, в которой работает

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

• Контрольная сумма. Это поле 16 бит используется для обнаружения ошибок во

входящем пакете, исключая поля "аутентификация типа" и "аутентификация данных".

• Тип аутентификации. Поле 16 бит, определяющее метод опознавания, который

используется в этой зоне. Иногда определяют два типа опознавания: 0 для отсутствия и 1

для пароля.

• Аутентификация данных. Это поле 64 бита для действующего значения данных. В

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

результат вычисления аутентификации. В настоящее время, если тип опознавания 0, это

поле заполнено нулями. Если тип 1 — поле содержит пароль длиной восемь символов.

Сообщение "hello"

OSPF использует сообщение "hello" (рис. 8.15) для создания отображения окружающей

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

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

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

Page 20: Osnovnije Internet Protokoli 4

20

обмена своим соседям. Он должен определить, работоспособны ли они. И он должен

знать, доступны ли они.

Рис. 8.15. Пакет "hello"

Маска сети. Это поле 32 бита определяет маску сети, по которой посылается сообщение

"hello".

Интервал "hello". Это поле 16 бит определяет число секунд между сообщениями "hello".

E-флаг. Это поле 1 бит – флаг. Когда он установлен, это означает, что зона является

ответвлением.

T-флаг. Это поле 1 бит флага. Когда он установлен, это означает, что маршрутизатор

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

Приоритет. Это поле определяет приоритет маршрутизатора. Приоритет используется для

выбора назначенного маршрутизатора. После того как все соседи объявят свои

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

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

назначенный маршрутизатор. Если значение этого поля 0, это значит, что маршрутизатор

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

Интервал неисправности. Это поле 32 бита определяет число секунд до момента, когда

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

IP-адрес назначенного маршрутизатора. Это поле 32 бита — IP-адрес назначенного

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

IP-адрес резервного назначенного маршрутизатора. Это поле 32 бита - IP-адрес резервного

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

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

согласованы как соседи для посылающего маршрутизатора. Другими словами, это

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

"hello".

Сообщение описания базы данных

Page 21: Osnovnije Internet Protokoli 4

21

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

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

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

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

каждого из маршрутизаторов. Поэтому, после того как маршрутизатор подключен к

системе, он посылает пакеты "hello" для того, чтобы оповестить соседей. Если соседи

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

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

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

содержание, название каждой линейки в базе данных. Заново подключенный

маршрутизатор анализирует общее описание и узнает, какие линейки информации у него

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

чтобы иметь полную информацию об этих конкретных линиях. Когда два маршрутизатора

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

другой роль ведомого. Поскольку сообщение может быть очень длинным, содержание

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

базы данных показан на рис. 8.16

Рис. 8.16. Пакет сообщения описания базы данных

Он имеет следующие поля:

• E-флаг. Это поле 1 бит – флаг, устанавливаемый на 1, если извещающий

маршрутизатор — пограничный маршрутизатор автономной системы (E означает

внешний, external).

• B-флаг. Это поле 1 бит – флаг, устанавливаемый на 1, если извещающий

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

• I-флаг. Это поле 1 бит – инициализирующий флаг, устанавливаемый на 1, если

сообщение есть первое сообщение.

• M-флаг. Это поле 1 бит – флаг "еще больше", устанавливаемый на 1, если это не

последнее сообщение.

• M/S-флаг. Это поле 1 бит – ведомый/ведущий, указывает, что источник пакета —

ведомый (M/S=1) или ведущий (M/S=0).

• Порядковый номер сообщения. Это поле 32 бита содержит порядковый номер

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

• LSA-заголовок. Это 20-байтное поле, используемое при каждом сообщении о

состоянии связи (LSA). Формат этого заголовка обсуждался в разделе "сообщение

обновления состояния линии" Этот заголовок — краткое описание каждой линии, без

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

Пакет запроса состояния линейки

Этот формат пакета запроса состояния линейки показан на рис. 8.17. Это пакет, который

посылается маршрутизатором, нуждающимся в информации о маршрутах. На него

Page 22: Osnovnije Internet Protokoli 4

22

отвечают пакетом с обновлением состояний линий. Он может быть использован во вновь

подключенном маршрутизаторе для запроса большей информации о некоторых

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

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

запрашивают для единственного LSA. Набор повторяется, если желательно иметь более

чем одно извещение.

Рис. 8.17. Пакет запроса состояния линии

Пакет обновления состояния связи

Пакет обновления состояния связи — "сердце" работы OSPF. Он используется

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

пакета обновления состояния связи показан на рис. 8.18. Каждый пакет обновления может

содержать несколько различных извещений о состоянии связи (LSAs).

Рис. 8.18. Пакет обновления состояния связи

Например, пакет обновления состояния связи может содержать 14 LSAs,

• четыре из которых — извещения линий маршрутизатора;

• три из которых — извещения о сетевых связях;

• два из которых — извещения о суммарных связях сети;

• два из которых — суммарные связи к пограничным маршрутизаторам автономной

системы.

Ниже приводятся поля.

Номер извещения о состоянии связи. Поле на 32 бита, определяющее номер извещения.

Один пакет может извещать о состоянии нескольких линий.

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

LSAs, имеющих один и тот же формат заголовка, но различное содержание. Рассмотрим

сначала общий для всех заголовок. Формат заголовка LSA показан на рис. 8.19

Page 23: Osnovnije Internet Protokoli 4

23

Рис. 8.19. Заголовок LSA

Возраст состояния связи. Это поле показывает число секунд, прошедших с момента

генерации этого сообщения. Этот тип сообщения может повторяться при переходе от

маршрутизатора к маршрутизатору (распространение). Когда маршрутизатор создает

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

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

дополняет его для накопления в этом поле.

E-флаг. Это поле 1 бит – флаг, устанавливаемый на 1, если это зона ответвления.

Напомним, что зона ответвления – это зона, которая подключена к основной зоне только

по одному пути.

T-флаг. Это поле 1 бит – флаг, устанавливаемый на 1. Это означает, что маршрутизатор

может работать со многими типами обслуживания.

Тип состояния связи. Это поле определяет тип LSA.

ID состояния связи. Значение этого поля зависит от типа линии. Для типа 1 (связь

маршрутизатора) — это IP-адрес маршрутизатора. Для типа 2 (сетевая связь) — это IP-

адрес сети. Для типа 3 (суммарная связь сети) — это IP-адрес сети. Для типа 4 (суммарная

связь пограничного маршрутизатора к автономной системе) — это IP-адрес автономной

системы. Для типа 5(внешняя связь) — это адрес внешней сети.

Извещающий маршрутизатор. Это IP-адрес извещающего маршрутизатора для этого

сообщения.

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

сообщения обновления состояния линии.

Контрольная сумма состояния связи. Это поле — не обычное поле контрольной суммы.

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

пакете, за исключением поля возраста сообщения.

Длина. Это поле определяет длину полного пакета в битах.

Извещение о состоянии связи маршрутизатора. Извещение о состоянии линии (LSA) связи

маршрутизатора сообщает обо всех связях маршрутизатора. Формат пакета линии

маршрутизатора показан на рис. 8.20. Поля маршрутизатора показаны ниже.

Page 24: Osnovnije Internet Protokoli 4

24

Рис. 8.20. LSA Состояния связи маршрутизатора

ID-связи. Значение этого поля зависит от типа связи. Табл. 8.3. показывает различные

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

Данные связи. Это поле дает дополнительную информацию о связи. Значение зависит от

типа связи (см. табл. 8.3.)

Тип связи. Различают четыре типа связей, основанных на типе сети, к которой подключен

маршрутизатор (см. табл. 8.3.).

Таблица 8.3. Типы связей, идентификаторы связей и данные связей

Тип линий Идентификатор линий Данные линий

Тип 1: Подключение к другому

маршрутизатору "Точка – точка"

Адрес соседнего

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

Номер интерфейса

Тип:2: Подключение к сети "любой с

любым"

Адрес соседнего

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

Адрес

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

Тип 3:Подключение сети "ответвление" Сетевой адрес Сетевая маска

Тип 4: Виртуальная линия Адрес соседнего

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

Адрес

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

Число типов обслуживания (TOS – Type of Service). Это поле определяет число типов

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

Метрика для TOS 0. Это поле определяет метрику по умолчанию для данного типа

обслуживания (TOS).

Тип сервиса TOS (The type of Service). Поле определяет тип обслуживания.

Метрика. Это поле определяет метрику для соответствующего TOS.

Извещение о состоянии сетевой связи. Извещение о состоянии сетевой связи несет

информацию об устройствах, подключенных к сети связи. Формат извещения сетевой

связи показан на рис. 8.21 Поля LSA сетевой связи следующие:

Page 25: Osnovnije Internet Protokoli 4

25

Рис. 8.21. Формат извещения LSA сетевой связи

• Маска сети. Это поле определяет сетевую маску.

• Подключаемые маршрутизаторы. Эти повторяющиеся поля определяют IP-адреса

всех подключаемых маршрутизаторов.

Извещение о суммарном состоянии связи к сетям. Оно используется узловым

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

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

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

Заметим, что каждое извещение описывает только единственную сеть.

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

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

маршрутизатора, содержащегося в заголовке в поле "ID состояния связи". Из этой

информации и маски можно однозначно вывести адрес сети. Формат этого извещения

показан на рис. 8.21. Поля LSA суммарной связи сети следуют ниже рис. 8.22.

Рис. 8.22. Формат LSA суммарной связи сети

• Маска сети. Это поле определяет маску сети.

• TOS. Это поле определяет тип обслуживания (the Type Of Service).

• Метрика. Это поле задает метрику для типа обслуживания, определенного в поле

TOS.

Извещение о суммарном состоянии связи к пограничному маршрутизатору автономной

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

маршрутизатору автономной системы (АС). Его формат такой же, как в предыдущей

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

маршрутизатор. Если сообщение может достигнуть сети, оно может быть принято

пограничным маршрутизатором автономной сети. Формат пакета показан на рис. 8.23

Поля такие же, как и поля у сообщения суммарной сетевой связи.

Page 26: Osnovnije Internet Protokoli 4

26

Рис. 8.23. LSA суммарной линии к пограничному маршрутизатору автономной сети (АС)

Извещение о состоянии внешней связи. Оно используется, чтобы известить все станции

сети о внешних связях к другим АС. Этот формат похож на LSA суммарной линии

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

Пограничный маршрутизатор АС может определяться маршрутизатором,

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

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

протоколами, но не OSPF. Этот формат пакета показан на рис. 8.24.

Рис. 8.24. LSA внешней связи

Пакет подтверждения состояния связи

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

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

подтверждения состояния связи показан на рис. 8.25 Он имеет общий заголовок OSPF и

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

Рис. 8.25. Пакет подтверждения состояния связи

Инкапсуляция

OSPF-пакет инкапсулируется в IP-дейтаграммы. Они содержат извещающий механизм для

управления потоком и контроля ошибок. Они не нуждаются в протоколе транспортного

уровня, для того чтобы быть обеспеченными эти сервисом.

Протокол пограничной маршрутизации (BGP — Border Gateway Protocol)

Протокол пограничной маршрутизации (BGP — Border Gateway Protocol) – это протокол

маршрутизации между автономными системами. Он основан на методах маршрутизации,

называемых "маршрутизация вектором пути". Рассмотрим вначале принципы такой

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

Page 27: Osnovnije Internet Protokoli 4

27

маршрутизация с помощью вектора расстояния маршрута (RIP) и маршрутизация по

состоянию линии (OSF), не являются желательными для использования системой

маршрутизации между автономными системами.

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

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

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

автономную систему, которая не обеспечивает безопасности по наикратчайшему

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

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

к пункту назначения, без анализа состояния всего пути (например, перегрузки участков),

который ведет к этому пункту назначения.

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

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

большая сеть для этого метода маршрутизации. Чтобы использовать маршрутизацию по

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

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

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

алгоритма Дейкстры.

Маршрутизация с использованием вектора путей

Маршрутизация с использованием вектора путей отличается и от маршрутизации с

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

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

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

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

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

векторов пути.

Таблица 8.4. Маршрутного вектора пути

Сеть Следующий маршрутизатор Путь

N01 R01 AS14,AS23, AS67

N02 R05 AS22,AS67, AS05, AS89

N03 R06 AS67,AS89, AS09, AS34

N04 R12 AS62,AS02, AS09

Сообщения вектора путей

Автономный пограничный маршрутизатор, который участвует в маршрутизации с

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

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

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

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

самой сети, – соседи.

Заметим, что пограничный маршрутизатор автономной системы получает свою

информацию от внутреннего алгоритма маршрутизации, такого как RIP и OSPF.

Page 28: Osnovnije Internet Protokoli 4

28

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

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

который управляет маршрутизатором). Если политика маршрутизации соответствует

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

модифицирует сообщение, прежде чем послать его к следующему соседу. Модификация

содержит дополнение номера своего АС для пути и замещающий номер следующего

маршрутизатора, входящего со своим собственным идентификатором.

Например, рис. 8.26 показывает сеть Интернет с четырьмя автономными системами.

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

N1, маршрутизатор R2 получает сообщение, обновляет свою таблицу маршрутизации,

после этого добавляет свою информацию об автономной системе к информации пути и

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

маршрутизатору R3. Маршрутизатор R3 получает сообщение, обновляет свою таблицу

маршрутизации и посылает сообщение после изменения к маршрутизатору R4.

Рис. 8.26. Принцип формирования вектора путей

Предотвращение петли

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

маршрутизации и порождения петель можно избежать при маршрутизации с

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

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

назначения. Если он есть, то возможно возникновение петель и сообщение игнорируется.

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

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

путей. Когда маршрутизатор получает сообщение, он проверяет путь. Если одна из

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

игнорировать этот путь и этот конечный пункт. Он не обновляет свою таблицу

маршрутизации в части этого пути и не посылает сообщения своим соседям. Это означает,

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

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

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

Атрибуты пути

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

фактически это список атрибутов.

Page 29: Osnovnije Internet Protokoli 4

29

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

когда применяется его политика.

Атрибуты разделяются на две категории: закрепленные (well-know) и опциональные.

Закрепленный атрибут — единица, которую каждый BGP-маршрутизатор должен

распознавать. Опциональный атрибут — единица, которую не надо распознавать

каждому BGP-маршрутизатору.

Закрепленный атрибут сам разделяется на две категории: обязательный и по усмотрению.

Закрепленный атрибут по усмотрению — единица, которая должна быть опознана

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

Единица обязательного закрепленного атрибута – это ORGIN. Она определяет

информацию об источнике маршрутизации (RIP, OSPF и так далее). Другой хорошо

известный закрепленный обязательный атрибут – это AS_PATH. Он определяет список

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

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

которому должен быть послан пакет данных.

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

не транзитные. Опциональный транзитный атрибут — единица, которая должна быть

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

атрибут. Опциональный не транзитный атрибут — единица, которая должна быть удалена,

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

Формат пакета

Все BGP-пакеты используют одни и те же заголовки. Перед изучением различных типов

пакетов рассмотрим общий заголовок (рис. 8.27). Поля этого заголовка приведены ниже.

Рис. 8.27. Заголовок пакета BGP

• Маркер. Это 16-байтовое поле, зарезервированное для опознавания.

• Длина. Это поле в 2 байта, которое определяет длину полного сообщения,

включающего заголовок.

• Тип. Это поле 1 байт — тип пакета. Как было сказано раньше, мы имеем четыре

типа, от 1 до 4.

Типы пакетов

Page 30: Osnovnije Internet Protokoli 4

30

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

уведомления.

Сообщение "открытие"

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

протокол BGP, устанавливает TCP-соединение с соседями и посылает сообщение

"открытие". Если сосед согласно политике принимает отношения соседства, он отвечает

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

маршрутизаторами установлены. Описание формата "открытие" см. на рис. 8.28

Рис. 8.28. Сообщение открытия

Поля сообщения "открытие" приведены ниже.

Версия. Это поле 1 байт, определяющее версию BGP. Текущая версия — 4.

Моя автономная система. Это поле 2 байта, определяющее номер автономной системы.

Время удержания. Это поле 2 байта, определяющее максимальное число секунд, которые

могут пройти, прежде чем одна из сторон получит дежурное сообщение или сообщение

обновления от другой стороны. Если маршрутизатор не получает одно из этих сообщений

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

BGP-идентификатор. Это поле 4 байта, определяющее маршрутизатор, который прислал

сообщения "открытие". Маршрутизатор обычно использует для этой цели один из своих

адресов IP (потому что он уникален).

Длина параметра опции. Сообщение "открытие" может содержать некоторые параметры

опции. Если это так, то здесь содержится 1 байт, определяющий длину всех параметров

опции. Если параметров опции нет, значение этого поля — ноль.

Параметры опции. Если значение длины параметров опции не равно нулю, это означает,

что имеются некоторые параметры опций. Каждый параметр опции сам имеет два

подполя: длина параметра и значение параметра.

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

Page 31: Osnovnije Internet Protokoli 4

31

Сообщение "обновление"

Сообщение "обновление" — основа протокола BGP — используется маршрутизатором

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

новому конечному пункту или замены обеих пунктов назначения. Заметим, что BGP

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

известить только один новый пункт назначения в одном сообщении. Формат

обновленного сообщения показан на рис. 8.29.

Рис. 8.29. Сообщение обновления

Поля сообщения обновления перечислены ниже.

Длина отзываемых маршрутов. Это поле определяет длину следующего за ним поля.

Отзываемый маршрут. Это поле — список всех маршрутов, которые должны быть

удалены из предыдущего объявленного списка.

Длина атрибутов пути. Это поле 2 байта определяет длину следующего поля.

Атрибуты пути. Это поле определяет атрибуты пути (маршрута) к сети, которая

достижима и объявлена в этом маршруте.

Информация достижимости сетевого уровня. Это поле определяет сеть, которая заявлена

этим сообщением. Оно имеет длину поля и префикс IP-адреса. Длина определяет число

бит в префиксе. Префикс определяет общую часть сетевого адреса. Например,

153.18.7.0/24.

Префикс 153.18.7, длина префикса – это 24 бита. Это означает, что BGP4 поддерживает

классическую адресацию и CIDR (Classes InterDomain Routing – бесклассовая

междоменная маршрутизация).

Дежурное сообщение

Page 32: Osnovnije Internet Protokoli 4

32

Маршрутизатор (называемый равный – peers на языке BGP), выполняющий BGP-

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

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

ожидания. Дежурные сообщения, с типом сообщений 3 (поле Тип = 3), содержат только

общий заголовок, показанный на рисунке 8.28.

Сообщение уведомления

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

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

на рис. 8.30

Рис. 8.30. Сообщение уведомления

Поля, содержащиеся в поле извещения, следующие:

Код ошибки. Это поле 1 байт, определяющее категорию ошибки ( табл. 8.5.).

Подкод ошибки. Это поле 1 байт дополнительно определяет тип ошибки в каждой

категории.

Данные об ошибке. Это поле может быть использовано, чтобы дать больше

диагностической информации об ошибке.

BGP инкапсулируются в TCP-сегменты, использующие закрепленный порт 179. Это

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

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

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

Таблица 8.5. Коды ошибок

Код

ошибки

Описание

подкода ошибки Описание подкода ошибки

1 Ошибка заголовка

сообщения

Определены три различных подкода для этого типа ошибки:

проблемы синхронизации(1), плохая длина сообщения (2),

плохой тип сообщения (3)

2 Ошибка

сообщения

открытия

Определены 6 различных подкодов для этого типа ошибки:

номер неподдерживаемой версии (1), плохой прямой АС (2),

плохой идентификатор BGP (3), неподдерживаемые

опциональные параметры (4), ошибка опознавания (5),

неприемлемое время удержания (6)

3 Ошибка Определены 6 различных подкодов для этого типа ошибки:

Page 33: Osnovnije Internet Protokoli 4

33

сообщения

обновления

плохо сформированный список атрибутов (1), неопознанные

атрибуты хорошо известного порта (3), ошибка флага

атрибутов(5), ошибка длины атрибутов (6), АС-

зацикливание маршрутизации (7), недействительный

атрибут следующего участка (8), ошибка опциональных

атрибутов (9), недействительное поле сети (10), плохо

сформированный AS_PATH (11)

4 Истекло время

удержания

Подкод не определен

5 Ошибка автомата

с конечным

числом состояний

Это определенная процедурная ошибка. Подкод не

определен.

6 Прекращение Подкод не определен

Page 34: Osnovnije Internet Protokoli 4

34

9. Транспортный уровень. Пользовательский протокол дейтаграмм

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

программами сетевого уровня. Прикладная программа посылает поток данных

транспортному уровню. На передающей станции транспортный уровень разбивает поток

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

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

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

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

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

соединение. Набор программ для транспортного уровня задается двумя протоколами: UDP

и TCP. В этом разделе мы изучим простейший из них — пользовательский протокол

дейтаграмм (UDP — User Datagram Protocol).

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

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

операциями.

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

"процесс-процесс" (процесс – это работающая прикладная программа); чтобы это

выполнить, UDP использует номер порта. Другая задача — обеспечить механизм

управления транспортным уровнем. UDP занимается этой задачей в очень малой степени:

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

подтверждения полученных пакетов. Однако UDP обеспечивает в некоторой степени

контроль ошибок. Если UDP обнаруживает ошибку в принятом пакете, он, ничего не

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

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

подогнать их в пакет передачи. UDP называют не ориентированным на соединение,

недостоверным транспортным протоколом.

Наряду с недостатками он имеет некоторые преимущества. UDP — очень простой

протокол, использующий минимальные дополнительные затраты. Если процесс может

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

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

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

использовании TCP.

Пользовательская дейтаграмма

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

размер 8 байт. Рис. 9.1. показывает формат пользовательской дейтаграммы.

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

• Адрес порта источника. Это номер порта, который используется процессом,

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

может быть в пределах от 0 до 65 535. Если хост источника — это клиент (клиент,

посылающий зарос), номер порта в большинстве случаев – это кратковременный номер

порта, затребованный процессом и выбранный работающим на хосте источника

программным обеспечением UDP.

Page 35: Osnovnije Internet Protokoli 4

35

• Адрес порта пункта назначения. Это номер порта, используемый процессом в хосте

пункта назначения. Он также имеет 16 бит длины. Если хост пункта назначения – это

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

известен. Если хост пункта назначения – это клиент (сервер, посылающий отклик), номер

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

кратковременный номер порта, он получен в пакете запроса.

• Длина. Это поле длиной 16 бит, которое определяет полную длину дейтаграммы

пользователя, плюс заголовок данных. Эти 16 бит могут определять полную длину от 0 до

65 535 байт.

• Контрольная сумма. Это поле используется для обнаружения всей

пользовательской дейтаграммы (заголовок плюс данные).

Рис. 9.1. Формат UDP дейтаграммы

Контрольная сумма

Вычисление UDP контрольной суммы отличается от IP и ICMP. Здесь контрольная сумма

включает три раздела: псевдозаголовок, заголовок UDP и данные, поступившие от

прикладного уровня.

Псевдозаголовок – это часть заголовка IP-пакета, в котором дейтаграмма пользователя

инкапсулирована в некоторые поля, заполненные нулями ( рис. 9.2.).

Поле протокола добавлено для того, чтобы гарантировать, что пакет принадлежит UDP, а

не TCP. Мы увидим позже, что если процесс будет использовать либо UDP, либо TCP,

номер порта назначения может быть тот же самый. Значение поля протокола для UDP –

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

приемника будет обнаружено, он и UDP удалят этот пакет — он не будет доставлен к

ложному протоколу.

Заметим совпадение между полем псевдозаголовка и последними 12 битами заголовка IP.

Вычисление контрольной суммы у передатчика.

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

1. Дополняет псевдозаголовок к пользовательской дейтаграмме UDP.

2. Заполняет нулями поле контрольной суммы.

3. Разделяет все биты на 16-битовые (2-байтовые) слова. Если полное число байтов

четное — дополняет один байт заполнения (все нули).

Page 36: Osnovnije Internet Protokoli 4

36

4. Это заполнение делается только с целью вычисления контрольной суммы и в

дальнейшем будет удалено.

5. Складывает все 16-битовые секции с использованием арифметики с дополнением

единиц.

6. Дополняет результат (изменяет нули на единицы и все единицы на нули). Это16-

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

7. Удаляет псевдозаголовок и все дополнительные заполнения.

8. Доставляет UDP пользовательскую дейтаграмму к IP программному обеспечению

для инкапсуляции.

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

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

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

(20 байт) с UDP-дейтаграммой, установить поле "время жизни" на ноль и удалить IP-

контрольную сумму. Результат должен быть тот же самый.

Рис. 9.2. Псевдозаголовок, дополняемый к UDP дейтаграмме

Вычисление контрольной суммы на стороне приемника

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

1. Дополняет псевдозаголовок к пользовательской дейтаграмме UDP.

2. Если надо, то дополняет заполнение.

3. Разделяет все биты на 16-битовые секции.

4. Складывает все 16-битовые секции с использованием арифметики с дополнением

единиц.

5. Дополняет результат.

6. Если результат равен нулю, отбрасывает псевдозаголовок и любые заполнения и

принимает UDP-дейтаграмму только 7 байт. Если результат какой-либо другой,

пользовательская дейтаграмма удаляется.

Пример

Page 37: Osnovnije Internet Protokoli 4

37

На рис. 9.3. показано вычисление контрольной суммы для очень маленькой

пользовательской дейтаграммы всего лишь с 7 байтами. Поэтому число байтов данных —

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

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

дейтаграмма будет доставлена к IP.

Рис. 9.3. Пример контрольной суммы, простой пользовательской дейтаграммы UDP

Использование контрольной суммы

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

необязательно. Если контрольная сумма не вычислена, поле заполняется нулями.

Как же программное обеспечение UDP на компьютере пункта назначения, когда получает

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

определить, используется или не используется контрольная сумма, или если используется,

то как возник результат, состоящий из всех нулей? Ответ очень прост. Если источник

вычисляет контрольную сумму и возникает результат "все нули", в этом случае он должен

быть дополнен. Так что все нули не посылаются, а посылаются все единицы, которые

подсчитываются, в противоположность нулям, в арифметике с дополнением единиц.

UDP-операции

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

концепцию, затем она будет более подробно рассмотрена в следующей лекции для TCP-

протокола.

Услуги, не ориентированные на соединение

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

соединение. Это означает, что каждая дейтаграмма посылает независимую UDP-

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

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

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

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

различным путем.

Page 38: Osnovnije Internet Protokoli 4

38

Одно из направлений существующих не ориентированных на соединение услуг — это то,

что процесс не может передавать потоки данных поэтому применяется протокол UDP

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

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

подгоняется под размер дейтаграммы пользователя UDP. Для использования в UDP

желательны процессы, посылающие короткие сообщения.

Управление потоком и контроль ошибок

UDP — очень простой, но недостоверный транспортный протокол. Он не имеет

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

быть переполнен входящими сообщениями.

В UDP нет механизма защиты от ошибок, кроме контрольной суммы. Это означает, что

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

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

диаграмму без внешних сообщений.

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

UDP, должен сам обеспечивать эти механизмы.

Инкапсуляция и деинкапсуляция

Чтобы послать сообщение от одного процесса к другому, UDP-протокол инкапсулирует и

деинкапсулирет сообщения ( рис. 9.4.).

Инкапсуляция

Когда процесс хочет послать сообщение с помощью UDP, он передает сообщение к UDP в

соответствии с парой гнездовых адресов и длины данных. UDP получает данные,

дополненные заголовком UDP. Затем UDP передает пользовательскую дейтаграмму к IP с

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

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

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

окончание) и передает ее к физическому уровню. Этот физический уровень кодирует биты

в электрические или оптические сигналы и посылает их отдаленной машине.

Page 39: Osnovnije Internet Protokoli 4

39

Рис. 9.4. Инкапсуляция и деинкапсуляция

Деинкапсуляция

Когда сообщение пребывает на хост пункта назначения, физический уровень декодирует

биты и передает их к уровню звена данных. Уровень звена данных использует заголовок

(и окончание) для проверки данных. Если нет ошибки, заголовок и окончание

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

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

дейтаграмма передается UDP с адресами передатчика и приемника. UDP вычисляет

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

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

передаются процессу. Гнездовой адрес передатчика передается процессу в случае

необходимости отклика на полученное сообщение.

Организация очередей

В UDP организация очереди связана с портом ( рис. 9.5.).

На стороне клиента, процесс начинает с того, что запрашивает номер порта при помощи

операционной системы. Некоторые реализации создают и входящую, и исходящую

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

очереди, связанные с процессом.

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

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

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

номером порта. Функции очереди выполняются в течение процесса. Когда процесс

заканчивается, очередь разрушается.

Page 40: Osnovnije Internet Protokoli 4

40

Рис. 9.5. Очередь UDP

Процесс клиента может послать сообщение к исходящей очереди, используя номер порта

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

добавления UDP-заголовка доставляет их в IP. Исходящая очередь может переполниться.

Если это произойдет, операционная система, прежде чем послать любое другое

сообщение, запросит процесс клиента и передаст сообщение ожидания.

Когда сообщение прибывает к клиенту, UDP проверяет, создана ли входящая очередь для

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

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

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

недостижим.

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

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

очереди. Входящая очередь может быть переполнена. Если это произойдет, UDP

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

недостижимости порта.

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

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

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

исходящей очереди. Эта очередь остается открытой, пока сервер работает.

Когда сообщение прибывает к серверу, UDP проверяет, создана ли входящая очередь для

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

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

очереди. Если такой очереди нет, UDP удаляет пользовательскую дейтаграмму и просит

протокол послать клиенту сообщение "порт недостижим". Все входящие сообщения для

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

посылаются к одной и той же очереди. Если входящая очередь переполнится, UDP

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

недостижим".

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

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

сообщения одно за одним, после этого добавляет заголовок UDP и доставляет их к IP.

Page 41: Osnovnije Internet Protokoli 4

41

Исходящая очередь может переполниться. Если это произойдет, операционная система

просит сервер подождать, прежде чем передавать любое сообщение.

Мультиплексирование и демультиплексирование

В хосте, выполняющем набор протоколов TCP/IP, имеется только один UDP, но возможны

несколько процессов, которые могут вызвать услуги UDP. Для того чтобы обработать эту

ситуацию, UDP использует процессы мультиплексирования и демультиплексирования (

рис. 9.6.).

Мультиплексирование

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

дейтаграммы. Однако имеется только один UDP. Это соотношение "много к одному", и

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

процессов, различая их по заданным номерам портов. После добавления заголовка UDP

передает пользовательскую дейтаграмму IP.

Демультиплексирование

На стороне приемника есть только один UDP. Однако мы можем иметь много процессов,

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

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

процессу, основываясь на номере порта.

Рис. 9.6. Мультиплексирование и демультиплексирование

Области использования UDP

Ниже перечислены некоторые области использования UDP-протокола.

• UDP подходит для процесса, который требует простой связи "запрос – ответ", мало

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

Page 42: Osnovnije Internet Protokoli 4

42

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

FTP.

• UDP подходит для процессов с внутренним механизмом управления потоком и

контролем ошибок. Например, тривиальный протокол передачи файлов (Trivial File

Transfer Protocol — TFTP) включает в себя механизмы управления потоком и контроля

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

• UDP подходит как транспортный протокол для многоадресного и

широковещательного распространения. Многоадресные и широковещательные

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

обеспечении TCP

• UDP используется для процессов административного управления, таких как SNMP.

• UDP применяется для нескольких протоколов обновления маршрута, таких как

протокол информации маршрутизации (Routing Information Protocol –RIP).

Блок-схема совокупности программ управления UDP

Чтобы показать работу UDP по обработке передаваемых и принимаемых

пользовательских дейтаграмм UDP, на рис. 9.7. представлена версия совокупности

программных модулей UDP.

Она включает в себя пять компонентов: таблицу управления блоком, очередь на вводе,

модуль блока управления, модули ввода и вывода. Рис. 9.7. показывает эти модули и их

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

Рис. 9.7. Блок схема управления UDP

Таблица блока управления

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

сохранить текущее состояние открытых портов. Каждый вход в этой таблице имеет как

Page 43: Osnovnije Internet Protokoli 4

43

минимум четыре поля: состояние, которое может быть СВОБОДНО или ЗАНЯТО,

идентификатор процесса (ID), номер порта и соответствующий номер очереди.

Буферы очередей

В этом примере используется входная очередь. Особенности такого обслуживания уже

рассматривались при описании коммутаторов ATM.

Модуль управления

Модуль управления отвечает за управление вводом, выводом, таблицей управления. Когда

процесс стартует, он запрашивает номер порта у операционной системы. Операционная

система задает номер порта, закрепленного за удаленным сервером UDP, и

кратковременный номер порта данного компьютера для выхода на этот сервер. Процесс

передает идентификатор процесса (ID) и номер порта таблице управления, чтобы

отметить в таблице состояние процесса.

Алгоритмы работы модулей блок-схемы управления UDP

Алгоритмы работы модулей блок-схемы управления UDP показаны на рис. 9.8.- 9.9.

Алгоритм блока управления ( рис. 9.8.) показывает, что алгоритм получает идентификатор

процесса (ID) и номер порта. Напомним, что любой процесс, возникающий в компьютере,

получает свой номер. Адрес порта — это адрес порта назначения. Если это первичная

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

состоянием ЗАНЯТО. Если свободной строки (входа) нет, то вызов обслуживается

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

рассмотрены. Если этот вызов уже обслуживается, то в очередь записываются новые

данные.

На рис. 9.9. показан алгоритм работы модуля ввода дейтаграммы UDP. Алгоритм

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

показан на рис. 9.1. В этом формате номер порта содержит ID процесса, по этому номеру

определяется соответствующий вход в таблицу. Если такой вход (строка) найден, то в нем

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

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

сетевого уровня – протокол управляющих сообщений Интернета — ICPM (Internet Control

Message Protocol), который передает назад к передатчику сигнал "порт недостижим".

Page 44: Osnovnije Internet Protokoli 4

44

Рис. 9.8. Алгоритм работы модуля управления UDP

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

пересылки вместе с адресами, формирует UDP-дейтаграмму и передает ее на уровень IP.

Page 45: Osnovnije Internet Protokoli 4

45

Рис. 9.9. Алгоритм работы модуля ввода дейтаграммы UDP

Page 46: Osnovnije Internet Protokoli 4

46

Рис. 9.10. Алгоритм работы модуля вывода дейтаграммы UDP

Примеры

Рассмотрим некоторые примеры работы рассмотренных выше алгоритмов ввода и вывода.

Первоначально таблица управления (табл. 9.1.) имеет вид:

Таблица 9.1. Таблица управляющего блока в начале примера

Состояние ID процесса Номер порта Номер в очереди

ЗАНЯТО 2 345 53 010 34

ЗАНЯТО 3 422 52 011

СВОБОДНО

ЗАНЯТО 4 652 52 012 38

СВОБОДНО

Пример 1

Первое действие — доставка пользовательской дейтаграммы для конечного пункта 52 012.

Модуль ввода ищет номер этого порта в таблице и находит его. Номер в очереди 38 для

этого порта задан. Это означает, что порт был использован раньше. Модуль ввода

посылает данные в очередь с номером 38. Таблица управляющего блока не меняется.

Пример 2

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

После того как процесс стартует, он запрашивает операционную систему с целью

присвоения номера порта и получает номер 52 014. Теперь процесс посылает свой ID (4

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

Page 47: Osnovnije Internet Protokoli 4

47

таблицу. Модуль управления находит первый вход СВОБОДНО и вводит полученную

информацию. Модуль в этот момент не устанавливает процесс в очередь, потому что нет

пользовательской дейтаграммы для этого конечного пункта (табл. 9.2.).

Таблица 9.2. Таблица управляющего блока после выполнения примера 2

Состояние ID процесса Номер порта Номер в очереди

ЗАНЯТО 2 345 53 010 34

ЗАНЯТО 3 422 52 011

ЗАНЯТО 4 978 52 014

ЗАНЯТО 4 652 52 012 38

СВОБОДНО

Пример 3

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

занятого порта 52 011. Модуль ввода проверяет таблицу и находит, что порт занят, но нет

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

в первый раз. Модуль создает очередь и присваивает дейтаграмме номер 43 (табл. 9.3.).

Таблица 9.3. Таблица управляющего блока после примера 3

Состояние ID процесса Номер порта Номер в очереди

ЗАНЯТО 2 345 53 010 34

ЗАНЯТО 3 422 52 011 43

ЗАНЯТО 4 978 52 014

ЗАНЯТО 4 652 52 012 38

СВОБОДНО

Пример 4

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

Модуль ввода проверяет таблицу и не может найти вход для этого конечного порта.

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

источнику сообщение "порт не достижим".

Пример 5

Процессу нужно послать пользовательскую дейтаграмму. Он доставляет данные на

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

Комментарии к адресации UDP

UDP поддерживает передачу "процесс-процесс", т. е. обеспечивает доставку информации

от одной программы к другой, размещенной в другом компьютере. На рис. 9.11. показана

организация адреса при обмене "процесс-процесс".

Page 48: Osnovnije Internet Protokoli 4

48

Рис. 9.11. Организация адреса при обмене "процесс-процесс"

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

многопрограммный режимы. Компьютер может выполнять несколько программ сервера в

одно и то же время. Для связи на уровне "процесс-процесс" мы должны определить

адреса:

• местного хоста;

• местного процесса;

• удаленного хоста;

• удаленного процесса.

Местный хост и удаленный хост определяются IP-адресами. Чтобы определить

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

номерами порта. В наборе протоколов TCP/IP номера порта – это целые числа между 0 и

65 535.

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

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

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

помощью UDP программного обеспечения, выполняемого местным хостом. Это

называется кратковременный номер порта. Однако этот номер порта не может быть

выбран случайно.

IANA (Internet Assigned Numbers Authority — Агентство по выделению имен и

уникальных параметров) разделяет номера портов на три ранга: закрепленные (Well-

know), регистрируемые и динамические, как это показано на рис. 9.12.

Рис. 9.12. Классификация IANA

• Закрепленные порты. Порты, классифицируемые от 0 до 1 023, назначаются и

управляются IANA. Это – закрепленные порты. Обычно эти порты закрепляются за

Page 49: Osnovnije Internet Protokoli 4

49

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

пример такого закрепления (табл. 9.4.).

• Регистрируемые порты. Порты, классифицируемые от 1 024 до 49 151, не

назначаются и не управляются IANA. Они могут быть зарегистрированы IANA для

предотвращения дублирования.

• Динамические порты. Порты, классифицируемые от 49 152 до 65 535, не

контролируются и не регистрируются. Они могут быть использованы процессом. Это

кратковременные порты.

Таблица 9.4. Закрепленные порты, используемые UDP

Порт Протокол Описание

7 Echo Возвращает принятую дейтаграмму назад к передатчику

9 Discard Отклоняет любую дейтаграмму, которая получена

11 Users Активный пользователь

13 Daytime Возврат данных и времени

17 Quote Возврат ссылки дня

19 Charge Возврат строки с символами

20 FTP, Data Протокол передачи файлов (соединение данных)

53 Nameserver Служба доменных имен

67 Bootps Порт сервера загружает первоначальную информацию загрузки

68 Bootpс Порт клиента загружает первоначальную информацию загрузки

53 DNS Сервер доменных имен

69 TFTP Тривиальный протокол загрузки файлов

111 RPC Дистанционный вызов процедур

123 NTP Сетевой протокол службы времени

161 SNMP Простой протокол управления сетью

162 SNMP Простой протокол управления сетью (ловушка)

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

нежели IANA, для закрепленных и кратковременных портов. Например, BSD UNIX (BSD

Berkley Software Distribution) имеет три ранга: зарезервированные, кратковременные и не

привилегированные.

Гнездовые адреса

Как мы видели, UDP нужны два адреса для идентификации, IP-адрес и адрес порта, для

каждого конца создаваемого соединения. Комбинация IP-адреса и номера порта

называется адресом гнезда.

Page 50: Osnovnije Internet Protokoli 4

50

10. Транспортный уровень. Протокол управления передачей (Transmission Control

Protocol — TCP)

TCP называют надежный, ориентированный на соединение транспортный протокол

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

обеспечение надежности для обслуживания.

TCP не похож на UDP – это протокол, ориентированный на поток. В UDP процесс

(прикладная программа) посылает большую порцию байт UDP для доставки, UDP

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

дейтаграммой, и доставляет ее IP для передачи. Процесс может доставлять несколько

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

связь между ними.

TCP позволяет создать процесс, передающий информацию, доставлять данные как поток

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

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

данные по сети Интернет. Воображаемая среда изображена на Рис. 10.1 Передающий

процесс вырабатывает поток байтов, а приемный процесс "поглощает" его.

Рис. 10.1. Передача через TCP потока байтов

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

разных скоростях, TCP нуждается в буферной памяти для накопления. Имеются два

буфера, передачи и приема, для каждого направления. (Заметим, что эти буферы также

применяются в TCP-механизме управления потоком и контролем над ошибками.) Один из

путей реализации буфера — использовать буферные регистры с обратной связью

однобайтовыми сегментами, как это показано на Рис. 10.1. Для простоты мы указали два

буфера с небольшим объемом байт. Обычно буферы содержат сотни или тысячи байт

памяти, в зависимости от реализации.

Рис. 10.2 показывает движение данных в одном направлении. На передающей стороне

буфер имеет три типа участков. Белая секция — пустой участок, который может

заполняться с помощью процесса передачи (производитель). Серая область содержит

байты, которые переданы, но на них еще не получено подтверждение. TCP сохраняет эти

байты в буфере, пока не примет подтверждение. Закрашенный темно-серым цветом

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

лекции, TCP может послать только часть этой закрашенной секции; это может произойти

Page 51: Osnovnije Internet Protokoli 4

51

из-за замедления процесса приема или из-за перегрузки сети. Также заметим, что после

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

доступным для использования процессом передачи.

Рис. 10.2. Передающий и принимающий буферы

Вот почему мы показываем буфер с обратной связью.

Обработка буфера на стороне приемника проста. Буфер с обратной связью разделяется на

две области (показанные белым и темно-серым цветом). Белая область состоит из пустого

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

байты, предназначенные для процесса на стороне приема. Когда байты приняты

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

добавляется к общему множеству пустых участков.

Сегменты

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

сегментом. TCP добавляет заголовок к каждому сегменту (с целью контроля) и доставляет

сегмент на IP-уровень для передачи. Сегмент инкапсулируется и передается в IP-

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

разрушены. Все эти сегменты обрабатываются TCP и передаются процессу на стороне

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

байтов переносятся в буфера.

Page 52: Osnovnije Internet Protokoli 4

52

Рис. 10.3. TCP сегменты

Заметим, что сегменты могут отличаться размером. Реально сегменты переносят сотни,

если не тысячи байт.

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

направлениях одновременно. Каждый TCP поэтому имеет буфер приема и передачи и

посылает сегменты в оба направления.

TCP, в отличие от UDP, — протокол, ориентированный на соединение. Когда процесс на

стороне A посылает и принимает данные от другого процесса на стороне B, необходимо

провести следующие действия:

1. TCP на стороне A информирует TCP на стороне B и получает подтверждение от

стороны B.

2. TCP стороны A и TCP стороны B обмениваются данными в обоих направлениях.

3. После того как у обоих процессов не остается больше данных для передачи и

буферы пустые, оба TCP уничтожают буферы.

Заметим, что это не физическое, а виртуальное соединение. TCP-сегмент инкапсулируется

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

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

путь для достижения пункта назначения. Физического соединения не происходит. TCP

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

ответственность за доставку байтов в заданном порядке на другую сторону.

TCP — достоверный транспортный протокол. Он использует механизм подтверждения

для проверки сохранности и нормальности пребывающих данных.

Нумерация байт

Хотя программное обеспечение TCP сохраняет трассу передачи сегмента, который послан

или получен, он не имеет поля, в котором указано значение номера сегмента. Вместо

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

поля ссылаются на номер байта, а не на номер сегмента.

Номера байтов

Page 53: Osnovnije Internet Protokoli 4

53

TCP нумерует все байты данных, которые передаются в соединении. Нумерация зависит

от каждого направления. Когда TCP получает байты данных от процесса и накапливает их

в буферах передачи, он нумерует их. Нумерация не обязательно начинается от 0 — она

начинается со случайного числа. TCP генерирует случайный номер между 0 и 232-1 для

номера первого байта. Например, если выпадает случайный номер 1 057 и всего

посылается 6000 байт, байты нумеруются от 1 057 до 7 056.

После того как байты пронумерованы, TCP назначает порядковый номер для каждого

сегмента, который посылается. Порядковый номер для каждого сегмента – это номер

первого байта, переносимого в этом сегменте.

Пример 1

Представим себе, что TCP-соединение передает файл объемом 6000 байт. Первый байт

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

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

последнем — 2 000 байт?

Решение

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

Номер подтверждения

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

передавать и принимать данные одновременно. Каждая сторона нумерует байты, обычно с

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

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

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

определяет номер следующего байта, который каждая сторона ожидает получить. Кроме

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

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

устанавливает эту сумму как номер подтверждения. Термин "интегральная" здесь

означает, что если сторона использует 5 643 как номер подтверждения, она получила все

байты, начиная с 5 642 и ниже. Заметим, что это не означает, что сторона получила 5 642

байта, потому что первый байт может не иметь начального номера 0.

Управление потоком

Управление потоком — определение количества данных, которое может послать

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

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

прежде чем послать следующий байт. Но это чрезвычайно медленный процесс. Если

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

Page 54: Osnovnije Internet Protokoli 4

54

Другой крайний случай — транспортный протокол посылает все данные, не беспокоясь о

подтверждении. Это наиболее быстрый процесс, но он может нарушить работу

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

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

пунктом назначения.

Для TCP выбрано решение, которое лежит где-то между этими крайностями. Протокол

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

прикладных программ и готовность к посылке. TCP посылает столько данных, сколько

определено протоколом "скользящего окна" (sliding window).

Протокол "скользящего окна"

Для достижения управления потоком TCP использует протокол "скользящего окна". При

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

небольшую часть буфера, содержащую байты, которые буфер может передать, прежде

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

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

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

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

Рис. 10.4 показывает буфер передачи, определенный ранее на Рис. 10.1 и 10.2. Однако

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

Рис. 10.4. Буфер передатчика

На рис. 10.4 байты перед 200 посланы и подтверждены. Передатчик может снова

использовать эти места. Байты с 200 до 202 посланы, но не подтверждены.

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

искажены. Байты с 203 до 211 — в буфере (поставлены процедурой), но еще не переданы.

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

этом случае передатчик может продвигаться вперед и посылать все байты (до 211 в его

буфере), не заботясь о состоянии приемника. Если процесс приема идет не достаточно

быстро, буфер приемника с его ограниченным размером может окончательно заполниться.

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

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

приемнике.

Окно приемника

Page 55: Osnovnije Internet Protokoli 4

55

Рис. 10.5 показывает буфер приемника. Заметим, что следующий байт, который будет

принят процессом, – 194. Приемник ожидает получения от передатчика байта 200

(который послан, но не получен). Сколько байт может накопить приемник? Если общий

размер буфера приемника N, а M мест уже занято, то может быть получено не только N-M

байт. Например, на Рис. 10.5 N = 13, а M = 6, это означает, что может быть получено еще 7

байт. Это значение называется текущим окном приемника.

Рис. 10.5. Окно приемника

Создадим окно передатчика с размером менее и равным размеру окна приемника. Окно

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

посланы. Рис. 10.6 показывает буфер передатчика с окном передатчика, равным размеру

окна приемника. На рисунке показано, что это окно равно 7. Серым цветом показаны

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

Рис. 10.6. Буфер передачи и окно передатчика

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

послал 3 байта. Он может посылать только 4 байта. Заметим также, что хотя байты от 207

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

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

"Скользящее окно" передатчика

Рассмотрим теперь, как передатчик меняет позицию окна передатчика. В нашем примере,

допустим, передатчик посылает еще два байта (203 и 204) и получает из приемника

подтверждение на успешный прием байтов 200-202. Теперь ожидают подтверждение два

байта (203 и 204). Если размер окна приемника не меняется (пока еще равен 7), то

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

202, которые могут быть использованы повторно. Рис. 10.7 показывает состояние буфера

передатчика и окно передатчика перед и после этого события. Во второй части этого

рисунка передатчик может теперь посылать байты с 205 до 209 (5 следующих байт).

Page 56: Osnovnije Internet Protokoli 4

56

Рис. 10.7. "Скользящее окно" передатчика

Расширение "скользящего окна"

Если процесс приемника принимает данные быстрее, чем они поступают, размер окна

может быть расширен (в буфер можно добавить свободные места). Эта ситуация может

привести к увеличению (расширению) размера окна в передатчике. На рис. 10.8 приемник

прислал подтверждение еще на 2 байта (теперь ожидает подтверждения байт 205), и в то

же самое время размер окна приемника увеличен до 10. Такое увеличение позволяет

процессу передачи ввести дополнительно 5 байт и передать 5 байт.

Рис. 10.8. Расширение окна передатчика

Уменьшение окна передатчика

Если процесс приемника принимает данные медленнее, чем они поступают, размер окна

приемника уменьшается (сжимается). На рисунке приемник принимает 5 байт (с 205 до

209); однако процесс приема берет на обслуживание только один байт — это означает, что

число свободных мест уменьшается по сравнению с показанным на Рис. 10.5. до 6 (10-

5+1). Он подтверждает байты с 205 до 209 (ожидающий байт 210), но информирует

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

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

процесса передатчика, мы будем иметь окно и буфер, показанный на рис. 10.9

Рис. 10.9. Уменьшение окна передатчика

Закрытие окна передатчика

Page 57: Osnovnije Internet Protokoli 4

57

Что произойдет, если буфер приемника заполнен? В этом случае размер окна приемника

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

(левая и правая стенки перекрываются). Передатчик не может передать ни одного байта,

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

Синдром "глупого окна"

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

либо передающая прикладная программа медленно создает данные, либо приемная

прикладная программа медленно принимает данные, либо имеют места оба случая. В

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

которые уменьшают эффективность работы. Например, если TCP посылает сегмент,

содержащий один байт данных, это означает, что мы посылаем дейтаграмму 41 байт (20

байт — TCP-заголовок и 20 байт — IP-заголовок), которая передает только 1 байт

пользовательских данных. Соотношение заголовок/информация (41/1) указывает, что

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

синдром "глупого окна". Рассмотрим детальнее, как создается эта проблема, а затем — как

она может быть решена.

Синдром, создаваемый передатчиком

Протокол передачи TCP может создать синдром "глупого окна", если он обслуживает

медленную прикладную программу, которая медленно создает данные, например, 1 байт

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

буфер передачи TCP. Если передающее TCP не имеет никаких заданных инструкций, он

может создать сегмент, содержащий один байт данных. Результат — передача большого

числа 41-байтных сегментов, которые проходят через Интернет.

Элементарное решение — запретить TCP-передатчику передавать данные длиной 1 байт.

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

данные, чтобы послать большой блок. Как долго должно TCP ждать? Если ожидание

слишком долгое, то это может замедлить процесс. А если ждать недостаточно, это может

окончиться посылкой маленького сегмента.

Простое решение в случае, когда передающий процесс медленнее принимающего, состоит

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

Естественно, что такая передача может начаться, только когда накоплен сегмент заданной

величины и к этому времени получено подтверждение приема предыдущего сегмента.

Алгоритм Нагела

Алгоритм Нагела прост, но решает проблему. Этот алгоритм для передатчика TCP:

1. Передатчик TCP посылает первый кусок данных, приемник получает этот кусок от

передающей прикладной программы, даже если это только один байт.

2. После посылки первого сегмента TCP передатчик накапливает данные в выходном

буфере и ждет, пока приемник TCP пришлет подтверждение или пока накопится

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

TCP может передать сегмент.

3. Шаг 2 может повториться для всей дальнейшей передачи. Сегмент 3 может быть

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

заполнения максимального размера сегмента.

Page 58: Osnovnije Internet Protokoli 4

58

Алгоритм Нагела прост и фактически делается на скорости вычислений прикладной

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

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

(максимальный сегмент). Если прикладная программа медленнее, чем сетевая – создается

сегмент, меньший, чем максимальный.

Синдром, создаваемый приемником

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

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

Предположим, что программа передачи создает данные в блоках 1K, но программа

приемника принимает 1 байт за один цикл. Также предположим, что входной буфер TCP

приема равен 4 Кбайта. Передатчик посылает 4 Кбайта данных. Приемник сохраняет их в

своем буфере. Теперь его буфер полный. Он превращает размер окна в нуль, что означает,

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

первый байт данных из входного буфера приемника. Теперь мы имеем 1 байт

пространства во входящем буфере. TCP приемника объявляет размер окна 1 байт, который

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

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

только один байт. Процедура будет продолжаться. Один байт данных поглощается, и

посылается сегмент, переносящий один байт данных. Опять мы имеем проблему

эффективности.

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

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

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

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

максимального размера или когда буфер пуст.

Второе решение — задержать передачу подтверждения. Это означает, что когда сегмент

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

пространства во входящем буфере станет подходящим, прежде чем подтвердить

прибывший сегмент. Задержка подтверждения предотвращает передающий TCP от

возникновения эффекта "глупого окна". После посылки данных окно останавливается.

Данные не передаются до получения подтверждения. Это устраняет синдром.

Задержанное подтверждение также имеет другое преимущество: оно уменьшает трафик,

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

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

неподтвержденный сегмент.

Протокол находит баланс достоинств и недостатков. Он теперь определяет, что

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

Контроль ошибок

TCP — достоверный протокол транспортного уровня. Это означает, что прикладная

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

порядке, без ошибок и без потери любой части или дублирования.

Page 59: Osnovnije Internet Protokoli 4

59

TCP обеспечивает достоверность, используя контроль ошибок. Контроль ошибок

включает в себя механизмы обнаружения:

• искаженных сегментов;

• потери сегментов, нарушения порядка следования сегментов;

• дублирования сегментов.

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

обнаружены.

Обнаружение и коррекция ошибок

Обнаружение ошибок в TCP достигается с помощью использования трех простых

инструментов: контрольной суммы, подтверждения и контроля по времени (time-out).

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

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

назначения TCP. TCP применяет метод подтверждения для получения сведений о том, что

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

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

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

Искаженный сегмент

Рис. 10.10 показывает прибытие искаженного сегмента на пункт назначения.

Рис. 10.10. Искаженный сегмент

Page 60: Osnovnije Internet Protokoli 4

60

В этом примере источник посылает сегменты с 1 до 3, каждый по 200 байт.

Последовательность номеров начинается с 1201 в сегменте 1.

TCP приемника принимает сегменты 1 и 2 , используя контрольную сумму, находит, что

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

601, который означает, что получены нормально и неискаженно байты 1201 до 1600 и

ожидается получения байта 1601. Однако он нашел, что сегмент 3 искажен, и удаляет

сегмент 3. Заметим, что, хотя он получил байты 1601 до 1800 в сегменте 3, пункт

назначения не считает его полученным, потому что этот сегмент искажен. После того как

сработает счетчик времени для сегмента 3, источник TCP передаст повторно сегмент 3.

После получения сегмента 3 пункт назначения посылает подтверждение для байта 1801,

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

заданного времени.

Потеря сегмента

Рис. 10.11. показывает случай потери сегмента. Ситуация точно та же, как и при

искаженном сегменте. Другими словами, от точки источника и до пункта назначения

действия при потере сегмента те же, что и при его искажении. Разница в том, что

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

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

Рис. 10.11. Потерянный сегмент

Дублированный сегмент

Дублированный сегмент, например, может быть создан источником TCP, когда до

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

сегмента — простой процесс для пункта назначения TCP. Пункт назначения TCP ждет

Page 61: Osnovnije Internet Protokoli 4

61

продолжения потока байт. Когда прибывает пакет, который содержит тот же порядковый

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

Сегмент с нарушением порядка

TCP использует услуги IP, протокола сетевого уровня, не обеспечивающего

достоверности, не ориентированного на соединение. TCP-сегмент инкапсулируется в IP-

дейтаграмму. Каждая дейтаграмма — независимая единица. Маршрутизаторы могут

послать каждую дейтаграмму по любому маршруту, найденному ими по ситуации. Одна

дейтаграмма может следовать маршрутом с короткой задержкой; другая может следовать

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

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

вероятности будут в беспорядке.

Обработка сегментов с нарушением порядка пунктом назначения очень проста: он не

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

предшествуют ему. Конечно, если подтверждение задержано, в TCP-источнике может

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

будет удален пунктом назначения.

Потеря подтверждения

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

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

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

предыдущей информации, до последнего переданного байта.

Например, если пункт назначения посылает подтверждение (ACK) сегмента с номером

подтверждения 1801, это предполагает, что байты с 1201 до 1800 приняты. Если конечный

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

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

Page 62: Osnovnije Internet Protokoli 4

62

Рис. 10.12. Потерянное подтверждение

Таймеры TCP

TCP использует четыре таймера, показанных на рис. 10.13.

Рис. 10.13. TCP-таймеры

Таймер повторной передачи

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

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

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

конкретного сегмента. При этом могут возникнуть две ситуации:

1. Если подтверждение получено для этого конкретного сегмента прежде, чем истечет

контрольное время, то таймер стирается.

2. Если контрольное время таймера истечет прежде, чем придет подтверждение,

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

Page 63: Osnovnije Internet Protokoli 4

63

Вычисление времени повторной передачи

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

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

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

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

пути, созданного другим соединением. Это означает, что TCP не может использовать одно

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

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

последствиям. Если время повторения передачи не соответствует времени для достижения

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

исходного пункта, то это может привести к повторной передаче сегмента, который еще в

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

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

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

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

в период отсутствия трафика, чем в периоды перегрузки. TCP применяет динамическое

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

изменяться в течение одного и того же соединения.

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

"туда и обратно" (round-trip time — RTT). С этой целью используется несколько формул.

Наиболее общая формула для вычисления времени повторения передачи есть двойное

RTT:

Время повторения передачи = 2 x RTT.

Вычисление RTT

Теперь вопрос: как вычислить само RTT? RTT тоже вычисляется динамически. Имеются

два метода. Первый метод — TCP использует опцию метки времени, когда при посылке

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

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

между посланным сегментом и полученным подтверждением дает значение RTT.

Значение RTT используется в вычислениях времени повторения передачи — в

соответствии со следующей формулой:

RTT = a x предыдущее RTT + (1 – a) текущее RTT.

Значение "a" обычно 90 процентов. Это означает, что новое RTT – это 90 процентов

предыдущего значения RTT плюс 10 процентов значения текущего RTT. Например, если

предыдущее RTT 250 микросекунд, и TCP принимает в этот момент сегмент,

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

RTT = 90% x 250 + 10% x 70 = 232 мкс.

Время повторной передачи = 2 x 232 = 464 мкс.

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

Page 64: Osnovnije Internet Protokoli 4

64

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

передан повторно. Когда TCP передатчика получает подтверждение на этот сегмент, он не

знает — подтверждение это на исходный сегмент или на повторный. Значение RTT

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

было потеряно и подтверждение пришло на повторную единицу, значение RTT будет

вычислено от времени повтора сегмента. Это дилемма, которая решается следующим

образом:

• не определять RTT повторного сегмента в вычислении нового RTT;

• не корректировать значения RTT, пока вам не послан сегмент и не получено

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

Время настойчивости

Для того чтобы иметь дело с объявлением окна с нулевым размером, TCP необходим

другой таймер. Предположим, TCP приемника получил извещение о нулевом размере

окна. TCP передатчика затем останавливает передачу сегментов, пока TCP приемника не

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

может быть потеряно. Напомним, что подтверждения не подтверждаются в TCP. Если

TCP приемника думает, что он отработал, и ждет, что TCP передатчика пришлет еще

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

того, чтобы послать извещение о размере окна. И оба TCP могут продолжать ждать друг

друга бесконечно.

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

соединения. Когда TCP передатчика получает подтверждение с размером окна нуль, он

запускает таймер настойчивости. Когда время таймера настойчивости истечет, TCP

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

только 1 байт данных. Он имеет порядковый номер, но порядковый номер никогда не

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

остальных данных.

Значение таймера настойчивости устанавливается по времени повторения передачи.

Однако если отклик не получен от приемника, посылается другой пробный сегмент и

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

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

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

этого передатчик посылает один пробный сегмент каждые 60 с., пока окно не откроется

снова.

Дежурный таймер

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

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

соединение TCP к серверу, потом передал некоторые данные и затих. Может быть, клиент

"упал", в этом случае соединение останется открытым навсегда.

Чтобы избавиться от этой ситуации, в большинстве реализаций оборудуется сервер с

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

таймер. Отсчет времени обычно — два часа. Если нет никакого отклика после 10 проб (см.

предыдущий раздел), каждая по 75 раз, он предполагает, что клиент "не в порядке", и

заканчивает соединение.

Page 65: Osnovnije Internet Protokoli 4

65

Таймер времени ожидания

Таймер времени ожидания используется после окончания соединения. Когда TCP

закрывается, он реально не разъединяется. Соединение удерживается в неопределенности

на период времени ожидания. Если что-либо прибудет к пункту назначения, то оно будет

удалено. Значение для этого таймера равно двум временам ожидаемого времени

существования сегмента.

Page 66: Osnovnije Internet Protokoli 4

66

11. Управление перегрузкой и основные алгоритмы работы TCP

Управление перегрузкой

Как мы уже говорили, Интернет — комбинация сетей и устройств связи, например, таких

как маршрутизаторы. Пакет, стартующий от передатчика, может пройти через несколько

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

Маршрутизатор имеет буфер, который накапливает входящие пакеты, обрабатывает их и

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

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

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

Передатчик не имеет выбора, кроме как передать повторно потерянный пакет. Это может

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

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

которой система не сможет больше передавать данные. Поэтому TCP нуждается в

механизмах, позволяющих избежать этой ситуации.

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

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

пространством буфера в приемнике. При этом полностью игнорируются другие

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

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

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

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

Окно перегрузки

Сегодня размер окна передатчика определяется не только приемником, но также

перегрузкой в сети. Передатчик имеет два кванта информации: размер окна, объявленный

приемником, и размер окна перегрузки. Действующий размер окна – минимальный из

этих двух размеров.

Предотвращение перегрузки

Чтобы избежать перегрузки, передатчик TCP использует две стратегии. Мы называем

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

уменьшение.

Медленный старт и увеличение прибавлением

Это – комбинация двух стратегий: медленного старта и дополнительного увеличения.

Медленный старт. В начале соединения TCP устанавливает размер окна перегрузки на

максимальный размер сегмента. Для каждого сегмента, который подтвержден, TCP

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

не достигнет порога половины разрешенного размера окна. Это называется медленным

стартом, который полностью обманчив, потому что этот процесс не такой медленный.

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

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

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

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

восьми сегментов и так далее. Другими словами, после получения третьего

Page 67: Osnovnije Internet Protokoli 4

67

подтверждения размер окна увеличивается до восьми сегментов. Скорость роста окна —

экспоненциальная 23 = 8.

Увеличение прибавлением. Чтобы избежать перегрузки, прежде чем она возникнет, нужно

замедлить этот экспоненциальный рост. После того как размер достигает порога, размер

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

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

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

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

Мультипликативное уменьшение

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

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

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

передачи, он предполагает, что это перегрузка. Поскольку сети сегодня имеют

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

Стратегия гласит: если окончилось контрольное время, размер текущего окна должен

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

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

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

экспоненциально (мультипликативное уменьшение). Рис. 11.1. показывает идею

мультипликативного уменьшения.

Рис. 11.1. Мультипликативное уменьшение

На Рис. 11.1. максимальный размер окна — 32 сегмента, а порог установлен до 16

сегментов (половина максимального значения размера окна). При процедуре медленный

старт размер окна начинается от 1 и растет экспоненциально, пока не достигнет порога 16

при условии, что не истечет время тайм-аута.

После достижения порога процедура дополнительного увеличения позволяет наращивать

линейно по 1 байту, пока не сработает тайм-аут или размер не достигнет максимального

окна (32). На рисунке возник таймаут, когда был послан сегмент 8. В этот момент

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

Page 68: Osnovnije Internet Protokoli 4

68

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

тайм-аут, так что новый порог теперь 10.

Этот цикл (медленный старт, дополнительное увеличение, мультиплексное уменьшение)

продолжается с этим размером окна опять с единицы. Рис. 11.2. показывает ту же самую

идею.

Рис. 11.2. Стратегия предотвращения перегрузки

Сегмент

Сегмент – это единица данных, передаваемых между устройствами, которые используют

TCP (рис. 11.3.). Формат сегмента TCP состоит из 20–60-байтных заголовков и

следующих за ними данных для прикладной программы. Заголовок – это 20 байт, если не

имеет опций, и 60 байт, если состоит из нескольких опций.

Page 69: Osnovnije Internet Protokoli 4

69

Рис. 11.3. Формат заголовка TCP сегмента

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

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

приложениях.

Адрес порта источника. Это поле длиною 16 бит, определяющее номер порта прикладной

программы в хосте, в который посылает сегмент. Это обслуживание имеет ту же самую

цель, что адрес источника в заголовке UDP, обсуждавшемся ранее (см. рис. 9.1.).

Адрес порта пункта назначения. Это поле длиною 16 бит, определяющее номер порта

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

цель, что и адрес порта назначения в заголовке UDP, рассмотренном ранее (см. рис. 9.1.).

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

начальный порядковый номер (ISN – initial sequence number), который обычно отличается

в каждом направлении. Например, если ISN – 2 368 и первый сегмент переносит 1000

байт, порядковый номер – 2 369 (2 367 и 2 368 используются для установления

соединения); второй сегмент после 1000 байтного сегмента, переносит 500 байт. Он будет

иметь номер 3 369, и так далее. Пункт назначения может определить номер последнего

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

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

Порядковый номер. Это поле на 32 бита определяет номер, назначенный от первого бита

данных, которые содержатся в этом сегменте. Как мы уже говорили прежде, TCP —

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

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

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

сегмента.

Номер подтверждения. Это поле занимает 32 бита и определяет номер байта, который

ожидает приемник сегмента от другой стороны. Если приемник сегмента успешно принял

байт с номером x от другой стороны, он определяет номер подтверждения как x+1.

Page 70: Osnovnije Internet Protokoli 4

70

Длина заголовка. Это поле длиной 4 бита указывает номер 4-байтного слова в TCP

заголовке. Эта длина заголовка может быть между 20 и 60 байтами. Поэтому значение

этого поля может быть между 5 (5 x 4 = 20) и 15 (14 x 4 = 60).

Зарезервировано. Это поле 6 бит, зарезервировано для будущего использования.

Управление. Это поле определяет 6 различных управляющих бит, или флагов, как это

показано на Рис. 11.3.

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

устройствами, а также режимом передачи TCP. Короткое описание каждого из бит дано в

таблиц 11.1.

Таблица 11.1. Описание флагов в поле управления

Флаг Описание

Срочно Указатель срочности сообщения

Подтверждение Подтверждает правильность действия

Запуск Запуск данных

Повтор Соединение должно быть переустановлено

Синхронизация Порядковый номер синхронизации в течение соединения

Конечное Оконечное соединение

Размер окна. Это поле определяет размер окна в байтах, который может использовать

другая сторона. Заметим, что длина этого поля – 16 бит, что означает максимальный

размер окна – 65 535 байт.

Контрольная сумма. Это поле на 16 бит, которое действительно, только если установлен

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

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

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

Опция. В ТСР-заголовке может быть до 40 байт информации опций. Мы обсудим

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

Опции

Заголовок TCP может содержать до 40 байт информации опций. Опции передают

дополнительную информацию для пункта назначения или выравнивают другие опции.

Определены две категории опций: однобайтовая и многобайтовая опция. Первая

категория имеет два типа опций: оконечная опция и нет операции. Вторая категория

содержит три типа опций: размер максимального сегмента, коэффициент масштаба, а

также метку времени ( Рис. 11.4.).

Page 71: Osnovnije Internet Protokoli 4

71

Рис. 11.4. Опции

Конец опции. Это опция в 1 байт используется для заполнения поля опции, чтобы

выровнять формат. Она должна быть использована только как последняя опция и только с

одного конца. После этой опции приемник ищет полезную нагрузку. Иногда поле опции

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

опции, используя несколько опций типа "нет операции" (ничего не делать), после чего

поставить конец опции (рис. 11.5.). Конец опции несет три значения информации для

конечного пункта, она указывает, что:

1. нет больше опций в заголовке;

2. остаток от последнего 32-битового слова – это мусор и его можно не обрабатывать;

3. данные от прикладной программы стартуют с начала следующего 32-битового

слова.

Рис. 11.5. Конец опции

Нет операций. Эта опция (рис. 11.6.) в один байт используется как разделитель между

опциями. Например, она может применяться для выравнивания следующей опции до 32-

битовой границы.

Page 72: Osnovnije Internet Protokoli 4

72

Рис. 11.6. Опция "нет операции"

Максимальный размер сегмента (MSS – Maximum segment size). Эта опция определяет

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

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

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

65 535 байт. Значение по умолчанию — 536.

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

Размер определяется пунктом назначения сегмента, но не источником. Так, сторона 1

определяет MSS стороны 2. Сторона 2 определяет, что должно быть MSS, посланным со

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

умолчанию.

Эта опция применяется только в сегментах, которые осуществляют соединение. Она не

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

опции. Он содержит код опции, общую длину опции и значение опции.

Рис. 11.7. Опция "максимальный размер сегмента"

Масштабный коэффициент окна. Поле размера окна в заголовке определяет размер

скользящего окна. Это поле 16 бит длины, что означает, что окно может иметь рамки от 0

до 65 535. Хотя этот размер окна кажется очень большим, он еще может не быть

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

способностью с малыми задержками передачи.

Возьмем, например, канал оптического кабеля (OC-24), имеющего пропускную

способность 1 244 160 Мбит/с и соединяющего два компьютера куском 6000 миль. Когда

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

подтверждение. В течение этого периода могут быть посланы 10 Мбайт. Однако размер

окна позволяет станции послать только 65 535 байт.

Для того чтобы увеличить размер окна, используется масштабный коэффициент окна.

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

коэффициентом окна. Затем этот результат умножается на значение размера окна в

заголовке.

Page 73: Osnovnije Internet Protokoli 4

73

Размер нового окна = размер окна, определенный в заголовке x 2масштабный элемент окна

.

Например, если значение масштабного коэффициента окна равно 3, действующий размер

окна есть восьмикратное значение размера окна. Масштабный коэффициент может иметь

значение не более 16 — наибольшее из позволяемых TCP/IP, то есть максимальный

размер окна может быть 216

x 216

= 232

и совпадать с максимальным значением

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

значение порядкового номера.

Масштабный коэффициент окна может быть определен только во время фазы

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

может изменяться, но он может быть умножен на тот же самый масштабный

коэффициент. Формат опции масштабного коэффициента показан на рис. 11.8. Он

содержит код опции, общую длину опции и значение масштабного коэффициента.

Рис. 11.8. Опция "масштабный коэффициент окна"

Масштабный коэффициент иногда называют сдвигающим счетчиком, потому что

умножение числа на величину 2 – это то же самое, что операция побитового сдвига влево.

Метка времени. Это 10-битовая опция с форматом, показанным на рис. 11.9. Поле метки

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

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

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

значение в поле "эхо ответа". Источник, когда получает подтверждение, проверяет

текущее время по сравнению с этим значением. Разность – это время прохождения "туда и

обратно". Время "туда и обратно" может быть использовано TCP динамически для

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

Рис. 11.9. Опция "метка времени"

Контрольная сумма

Вычисление контрольной суммы TCP следует той же самой процедуре, что была описана

для UDP в предыдущем разделе. Однако включение контрольной суммы в дейтаграмму

UDP необязательно, в то время как включение контрольной суммы для TCP обязательно.

Page 74: Osnovnije Internet Protokoli 4

74

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

сегмент. Для псевдозаголовка TCP значение поля протокола – 6 (рис. 11.10.).

Рис. 11.10. Псевдозаголовок, дополняемый к TCP дейтаграмме

Соединение

TCP — это протокол, ориентированный на соединение. Протокол, ориентированный на

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

назначения. Все сегменты, принадлежащие сообщению, затем посылаются этим

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

подтверждения, а также для повторной передачи поврежденных или потерянных кадров.

В TCP передача, ориентированная на соединение, требует двух процедур: установления

соединения и окончания соединения.

Установление соединения

TCP передает данные в нормальном дуплексном режиме. Когда два TCP в двух

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

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

одобрение другой стороны перед каждой передачей данных. Предпринимаются четыре

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

1. Хост A посылает сегмент, чтобы известить о своем желании установить связь, и

включает в сообщение начальную информацию о трафике от A к B.

2. Хост B посылает сегмент для подтверждения запроса A.

3. Хост B посылает сегмент, который включает его начальную информацию о

трафике между A и B.

4. Хост A посылает сегмент, чтобы подтвердить запрос B.

Page 75: Osnovnije Internet Protokoli 4

75

Это установление соединения достигается в четыре шага. Однако шаги 2 и 3 могут

возникнуть одновременно, они могут быть скомбинированы в один шаг. Хост B может

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

Метод взаимодействия в три шага

Установление соединения, рассмотренное выше, называется методом взаимодействия в

три шага. В этой процедуре прикладная программа, называемая "клиент", желает

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

как транспортный протокол.

Процедура тройного подтверждения связи начинается с сервера. Программа сервера

говорит ему, что TCP готов принять соединение. Это называется запросом пассивного

открытия. Хотя сервер TCP готов принять любое соединение от любого компьютера в

мире, но он не может сам установить это соединение.

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

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

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

как это показано на рис. 11.11.

Имеются следующие шаги этого процесса:

1. Клиент посылает первый сегмент — SYN-сегмент. Этот сегмент включает номера

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

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

клиента (ISN – Initialization Sequence Number), в примере он равен 1200, также

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

клиент хочет определить максимальный размер сегмента (MSS — Maximum Segment

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

соответствующую опцию. Также если клиенту надо большее окно, он задает масштабный

коэффициент окна, используя соответствующую опцию. Этот сегмент определяется

желанием клиента сделать соединение с определенного рода параметрами. Заметим, что

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

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

2. Сервер посылает второй сегмент, SYN + ACK. Этот сегмент имеет двойную цель.

Первая: подтверждение получения первого сегмента, использующего флаг ACK и поле

подтверждающего номера. Подтверждающий номер – это начальный номер клиента плюс

один (1201). Сервер должен также определить размер окна клиента. Второй сегмент

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

номер (4800), используя номер байта, посланного от сервера к клиенту. Он также

содержит опцию масштабного коэффициента окна (если это надо) для использования

сервером и MSS, определенный сервером. Как мы говорили раньше, это два сегмента,

скомбинированные в один.

3. Клиент посылает третий сегмент. Это только сегмент ACK. Он подтверждает

сообщение второго сегмента, использующего ACK. Он содержит поле подтверждающего

порядкового номера: это начальный порядковый номер сервера плюс единица (4801).

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

посланы с третьим пакетом.

Page 76: Osnovnije Internet Protokoli 4

76

Рис. 11.11. Метод взаимодействия в три шага

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

открытие. В этом случае оба TCP пошлют друг другу сегмент SYN + ACK, и между ними

будет установлено одно-единственное соединение.

Окончание соединения

Любые две стороны, включенные в обмен данными (клиент или сервер), могут завершить

соединение. Когда соединение в одном направлении закончено, другая сторона может

продолжить передачу данных в обратном направлении. Поэтому для завершения

соединения в обоих направлениях нужны четыре действия:

1. Хост A посылает сегмент, извещающий о его желании закончить соединение.

2. Хост B посылает сегмент, подтверждающий запрос A. После этого завершает

соединение в одном направлении, но не в другом. Хост B может продолжить послать

данные к A.

3. Когда хост B закончит передачу своих данных, он посылает сегмент, чтобы

указать, что он желает завершить соединение.

4. Хост A подтверждает запрос B.

Шаги 2 и 3 могут возникнуть одновременно, соединение может быть завершено в одном

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

Метод взаимодействия в четыре шага

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

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

соединение.

Процедура начинается с клиента. Программа клиента говорит TCP, что она оканчивает

передачу данных и желает завершить соединение. Это – запрос на действия по

окончанию.

Page 77: Osnovnije Internet Protokoli 4

77

После получения запроса на действия по окончанию клиент TCP закрывает связь в

направлении клиент-сервер. Однако связь в другом направлении еще открыта.

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

может запросить от TCP закрыть соединение в направлении сервер-клиент. Это обычно

пассивное окончание. Метод взаимодействия в четыре шага показан на рис. 11.12.

Рис. 11.12. Метод взаимодействия в четыре шага

Четыре шага – это:

1. Клиент TCP посылает первый сегмент, FIN-сегмент.

2. Сервер TCP посылает второй сегмент, ACK-сегмент, чтобы завершить получение

FIN-сегмента от клиента. В этом сегменте он использует подтверждающий номер,

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

3. TCP-сервер может продолжить передачу данных в направлении сервер-клиент.

Когда он не имеет больше данных, он посылает третий сегмент. Этот сегмент – FIN-

сегмент.

4. TCP-клиент посылает четвертый сегмент, чтобы завершить получение FIN-

сегмента от TCP-сервера. Этот сегмент содержит подтверждающий номер, который равен

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

Переустановление соединения

TCP может запросить переустановление соединения для несуществующего порта.

Переустановление здесь означает, что текущее соединение нарушено. Это случается в

одном из трех случаев:

1. TCP на одной стороне запросил соединение к не существующему порту. TCP на

другой стороне может послать сегмент с RST(Reset — переустановление)-битом,

установленным, чтобы аннулировать запрос.

Page 78: Osnovnije Internet Protokoli 4

78

2. Один TCP может прервать соединение из-за ненормальной ситуации. Он может

послать сегмент переустановления (RST), чтобы закончить соединение.

3. TCP на одной стороне может обнаружить, что TCP на другой стороне свободен

длительное время. Он может послать RST-сегмент для разрушения соединения.

Операции TCP

Проталкивание данных

Как уже обсуждалось, передающий TCP использует буфер, чтобы накопить поток данных,

поступивших от передающих прикладных программ; а передающий TCP может выбрать

размер сегментов. Принимающий TCP также применяет буферы данных, когда

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

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

зрения всей сети. Эта гибкость увеличивает эффективность TCP.

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

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

прикладной программой на другом конце. Прикладная программа на одной стороне хочет

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

отклик в конце. Задержка передачи и задержка в доставке данных может быть

неприемлема для прикладной программы.

TCP может обработать такую ситуацию. Прикладная программа на передающей стороне

может запросить операцию "протолкнуть" (push). Это означает, что передающий TCP не

должен ждать заполнения окна. Он должен создать сегмент и послать его немедленно.

Передающий TCP должен также установить push(PSH)-бит, чтобы сказать, что сегмент

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

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

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

большинство реализаций игнорируют такой запрос. TCP может выбирать или нет эту

операцию.

Срочные данные

TCP — протокол, ориентированный на поток. Это означает, что данные представляются

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

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

послать срочный байт. Это означает, что передающая прикладная программа хочет

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

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

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

обнаружить серьезные нарушения. Она захочет прервать процесс, но уже послано

огромное количество данных. Если дать команду остановки процесса (Control + C), эти

два символа будут накоплены в буфере TCP приемного конца и эта команда будет

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

есть слишком поздно.

Решение — послать сегмент с установленным битом URG. Передающая прикладная

программа таким образом сообщит передающему TCP, что квант данных — срочный.

Передающий TCP создаст сегмент и вставит срочные данные в начало сегмента.

Page 79: Osnovnije Internet Protokoli 4

79

Остальной сегмент может содержать нормальные данные из буфера. Поле указателя

срочности в заголовке определяет конец срочных данных и начало нормальных данных.

Когда принимающий TCP получает сегмент с установленным битом URG, он извлекает

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

вне очереди к приемной прикладной программе.

Блок-схема совокупности программ управления TCP

TCP — очень сложный протокол. Он обслуживает поток, он ориентирован на соединение

со сложной диаграммой переходов состояний. Он использует управление потоком и

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

тысяч строк.

В этом разделе мы представим простейшую блок-схему TCP. Наша цель — показать, как

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

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

(transmission control block – TCB), установку таймера и три программных модуля. На Рис.

11.13. показаны 5 компонентов и их взаимодействие.

Рис. 11.13. Блок-схема TCP

Поскольку в любой момент времени мы можем иметь несколько соединений, TCB

сохраняет массивы TCB в форме таблицы. Таблица обычно именуются как TCB (рис.

11.14.).

Page 80: Osnovnije Internet Protokoli 4

80

Рис. 11.14. Общий вид таблицы TCB

Алгоритм работы главного модуля TCP

Алгоритм работы главного модуля TCP показан на Рис. 11.15.

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

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

алгоритмы в виде переходов от состояния к состоянию конечных автоматов. В

дальнейшем при рассмотрении программного обеспечения телефонных станций будет

продемонстрировано, как такой подход упрощает программирование. Там же будет

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

Ниже приводятся таблицы, в которых перечисляются состояния ( таблице 11.2.), входы (

таблице 11.3.), выходы ( таблице 11.4.), используемые в данном алгоритме.

Таблица 11.2. Состояние для TCP

СОСТОЯНИЕ

Английское

обозначение Русское обозначение

Описание

CLOSED ЗАКРЫТО Нет соединения

LISTEN СЛУШАЮ Сервер ожидает вызова от клиента

SYN-SENT ПЕРЕДАЧА Соединение запрашивает

передачу; ожидание

подтверждения

SYN-RCVD ПРИЕМ Состояние ожидания приема

ESTABILISHED УСТАНОВЛЕНО Соединение установлено

FIN-WAIT1 ОЖИДАНИЕ ОКОНЧАНИЯ1 Клиент запросил закрытие

соединения

FIN-WAIT2 ОЖИДАНИЕ ОКОНЧАНИЯ2 Другая сторона принимает

закрытие соединения

CLOSING ЗАВЕРШАЮЩЕЕ Обе стороны решили закрыть

соединение одновременно

TIME-WAIT ВРЕМЯ ОЖИДАНИЯ Ожидание повторной передачи

CLOSE-WAIT ОЖИДАНИЕ ЗАКРЫТИЯ Сервер ожидает закрытия

приложения

LAST-ASK ПОСЛЕДНЕЕ

ПОДТВЕРЖДЕНИЕ

Сервер ожидает последнего

подтверждения

Таблица 11.3. Входы для TCP

Page 81: Osnovnije Internet Protokoli 4

81

ВХОД

Английское

обозначение

Русское

обозначение

Описание

Active open Активное

открытие

Заявка процесса на передачу данных

Passive open Пассивное

открытие

Заявка на входящую связь (ожидается заявка от

процесса соединения для приема)

RST Повторная

передача

Запрос на переустановление соединения

Send Передача Запрос на передачу

SYN Запрос Запрос на соединение

SYN+ ACK Подтверждение

запроса

Подтверждение запроса на соединение

ACK Подтверждение Подтверждение сигнала

FIN Отбой Запрос на завершение соединения

FIN+ACK Подтверждение

отбоя

Подтверждение сигнала на окончательное

соединение

Close Закончить Сигнал, о том, что данная сторона закончила

соединение

Time-out Контрольное

время

Окончание установленного контрольного

времени

Таблица 11.4. Выходы для TCP

ВЫХОД

Английское

обозначение

Русское

обозначение

Описание

SYN Заявка на передачу Сегмент, который посылается другой стороне,

как заявка на передачу

SYN+ACK Подтверждение

заявки

Подтверждение заявки на передачу

ACK Подтверждение Подтверждение сигнала

FIN Отбой Сигнал, на окончательное завершение

SYN Запрос на прием Заявка на соединение для приема

FIN Отбой Сигнал, на окончательное завершение

Time-out Контрольное время Окончание установленного контрольного

времени

Рассмотрим работу алгоритма на Рис. 11.15.

Page 82: Osnovnije Internet Protokoli 4

82

Рис. 11.15 а. Алгоритм работы главного модуля совокупности программ управления TCP

Рис. 11.15 б. Алгоритм работы главного модуля совокупности программ управления TCP

Page 83: Osnovnije Internet Protokoli 4

83

Рис. 11.15 в. Алгоритм работы главного модуля совокупности программ управления TCP

Page 84: Osnovnije Internet Protokoli 4

84

Рис. 11.15 д Алгоритм работы главного модуля совокупности программ управления TCP

Исходящее соединение

Алгоритм находится в начальном состоянии ЗАКРЫТО (Оператор 1). В данном случае

инициатор (клиент) вырабатывает команду для TCP активное открытие (Оператор 10);

клиент подключается к прикладной программе и посылает сегмент SYN к серверу как

запрос на прием (Оператор 12). После чего алгоритм включает контрольное время

(Оператор 12) и переходит в состояние ПЕРЕДАЧА (SYN-SENT) пока он не получит

SYN+ACK от TCP — подтверждение запроса на стороне сервера (Оператор 18). Он

посылает сегмент ACK другому TCP (Оператор 19) и переходит в состояние

УСТАНОВЛЕНО (ESTABLSHED) — Оператор 20 (стр.2). Это состояние передачи

данных. Клиент остается в этом состоянии столько времени, сколько он посылает и

получает данные.

Если алгоритм не получает сигнала подтверждения запроса SYN+ACK, то заканчивается

контрольное время и поступает сигнал окончания тайм-аута (Оператор 15), ресурсы

освобождаются и алгоритм переходит в начальное состояние ЗАКРЫТО (CLOSED) —

Операторы 16, 17.

В состоянии ESTABLSHED (УСТАНОВЛЕНО) — Оператор 20 (стр.2) — алгоритм может

получать данные (Операторы 30-32) или информацию от приложения (Операторы 33-35).

Клиент остается в этом состоянии столько времени, сколько он посылает и получает

данные.

В этом состоянии клиент TCP может принять запрос на окончание от прикладной

программы клиента. Он посылает сегмент Отбой (FIN) к другому TCP и переходит в

состояния ОЖИДАНИЕ ОКОНЧАНИЯ1 – (FIN-WAIT1) — Оператор 36 (стр.3).

В этом состоянии клиент TCP ожидает получить ACK (Оператор 52, стр.3) от сервера

TCP. ACK получен, клиент переходит в состояние FIN-WAIT2 (ОЖИДАНИЕ

Page 85: Osnovnije Internet Protokoli 4

85

ОКОНЧАНИЯ2) — Оператор 54 (стр.3). Он не посылает ничего. Теперь соединение

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

Клиент остается в этом состоянии, ожидая окончания соединения с другого конца. Если

клиент получает сегмент FIN (Отбой) с другого конца — Оператор 55 (стр.3), он посылает

сегмент ACK — Оператор 56 (стр.3) и переходит в состояние TIME-WAIT (ВРЕМЯ

ОЖИДАНИЯ) — Оператор 42 (стр.3). Когда клиент в этом состоянии, он включает таймер

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

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

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

пакет, если какой-либо пакет достигает своего пункта назначения и будет отклонен. После

тайм-аута клиент переходит в состояние CLOSED (ЗАКРЫТО) и алгоритм переходит в

начальное состояние.

Кроме того, на Рис. 11.15 а показаны еще два возможных случая завершения соединения:

когда в этом состоянии приходит отбой с другого конца (одновременный отбой) либо

отбой приходит вместе с подтверждением.

Входящее соединение

Алгоритм начинает работу в состоянии CLOSED (ЗАКРЫТО) – Оператор 1. В этом

состоянии TCP алгоритм может получить запрос на пассивное открытие (Оператор 2). Он

переходит в состояние LISTEN (СЛУШАЮ) – Оператор 4. Во время этого состояния TCP-

сервер может получить сегмент SYN от клиента TCP – Оператор 5. В этом случае он

посылает сегмент SYN+ACK – Оператор 6 — подтверждение заявки на передачу и

переходит в состояние SYN–RCVD (Прием) – Оператор 7.

В этом состоянии TCP-сервер может получить сегмент ACK от клиента TCP (Оператор 58

на стр.4). Он переходит в состояние ESTABILISHED (УСТАНОВЛЕНО) – Оператор 20

(стр.2). Это состояние передачи данных. Алгоритм остается в этом состоянии на время

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

б.

В этом состоянии TCP-сервер может получить сегмент CLOSE (оператор 24) от клиента

— это означает, что клиент желает завершить соединение. Он может послать сегмент FIN

клиенту и перейти к состоянию FIN-WAIT1(ОЖИДАНИЕ ОКОНЧАНИЯ1). Далее

выполняется алгоритм по Рис. 11.15 в.

По правилам составления спецификаций в каждом состоянии предусматривается

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

ситуация сбоя или ошибки. В этом случае формируется сообщение об ошибке. На рис.

11.15. эта часть алгоритма не показана.

Page 86: Osnovnije Internet Protokoli 4

86

12. Протоколы прикладного уровня. TELNET

Главная задача Интернета и его набора протоколов TCP/IP — это обеспечить сервис для

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

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

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

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

доступны программы передачи файлов (FTP и TFTP), электронной почты (SMTP) и так

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

невозможно.

Лучшее решение — общецелевая программа клиент-сервер, которая позволяет

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

После входа в систему пользователь может использовать услуги, доступные на удаленном

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

TELNET — это сокращение от Terminals NETwork. Это стандартный протокол TCP/IP для

услуг виртуального терминала. TELNET дает возможность устанавливать соединение с

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

терминал – это терминал удаленной системы.

Концепция

TELNET основан на концепциях, которые обсуждаются ниже.

Внешняя среда с разделением времени

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

работали с внешней средой по принципу разделения времени. Согласно этому принципу,

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

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

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

мышки. Даже микрокомпьютер может моделировать терминал с помощью терминального

эмулятора.

В среде с разделением времени вся обработка информации проводится в центральном

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

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

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

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

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

Логин

В среде с разделением времени пользователь — это часть системы с некоторыми правами

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

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

Для доступа к системе пользователь начинает сеанс с пользовательского идентификатора

(id) или с регистрационного имени (login name). Система помогает проверке пароля,

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

Местный логин

Page 87: Osnovnije Internet Protokoli 4

87

Когда пользователь входит в местную систему с разделением времени, это называется

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

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

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

Терминальный драйвер передает символы операционной системе, в рамках этой системы

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

или утилиту (рис. 12.1 ).

Рис. 12.1. Местный login

Однако этот механизм не такой простой, как кажется, потому что операционная система

может назначить специальные значения для специальных символов. Скажем, в UNIX

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

управляющих символов с символом "z", которые означают прекращение действия;

комбинации управляющих символов с символом "c" означают остановку; и так далее.

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

вхождении в систему (login), потому что терминальный эмулятор и терминальный

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

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

интерпретировать специальные символы? Клиент или сервер? Эта ситуация будет

рассмотрена в этой лекции позднее.

Удаленный логин

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

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

(логин). Здесь TELNET берет на себя функции клиента и сервера. Пользователь посылает

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

принимает символы и интерпретирует их. Эти символы посылает TELNET-клиент,

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

виртуального сетевого терминала (Network Virtual Terminal Characters), и доставляет их к

местному стеку протоколов TCP/IP (рис. 12.2 ).

Page 88: Osnovnije Internet Protokoli 4

88

Рис. 12.2. Дистанционный login

Команды или текст в форме сетевого виртуального терминала (NTV) перемещаются через

Интернет и прибывают на стек протоколов TCP/IP в удаленной машине. Здесь символы

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

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

прямо на операционную систему, потому что удаленная операционная система не

разработана для получения трактовки этих символов от TELNET. Она спроектирована так,

чтобы принимать символы от драйвера терминала. Решение, добавляющее необходимое

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

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

терминала. Операционная система затем предает символы к соответствующей прикладной

программе.

Сетевой виртуальный терминал (NTV)

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

специфики каждой операционной системы. Например, для некоторых операционных

систем знак конца — это Ctrl+z, в то время как в других операционных системах — это

Ctrl+d.

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

сначала знать специфику терминального эмулятора, используемую этим компьютером.

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

NTV (Network Virtual Terminal — виртуальный сетевой терминал). Для каждого

интерфейса TELNET переводит символы (данные или команды), которые получает от

местного терминала, в NTV-форму и доставляет их в сеть. С другой стороны, сервер

TELNET переводит команды из формы NTV в форму, доступную удаленному

компьютеру. Все иллюстрации этой концепции смотрите на рисунке 12.3.

Page 89: Osnovnije Internet Protokoli 4

89

Рис. 12.3. Концепция NVT

Набор символов NTV

Символы данных

NTV набор символов обычно использует набор, называемый NVT ASCII. Это 8-битовый

набор символов, в котором семь младших бит такие же, как в US ASCII, имеющие

старший бит — 0 (рис. 12.4). Хотя возможно посылать 8-битовый ASCII (с высшим

разрядом, установленным в 0 или 1), это должно быть согласовано между клиентом и

сервером с использованием опции "переговоры".

Рис. 12.4. Формат символов данных

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

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

наоборот), NTV использует 8-битовый набор символов, в которых высший разряд

установлен в 1 (рис. 12.5. ).

Рис. 12.5. Формат управляющих символов

Таблица 12.1. содержит список некоторых символов дистанционного управления и их

значения.

Page 90: Osnovnije Internet Protokoli 4

90

Таблица 12.1. Некоторые NVT-символы дистанционного управления

Символ Десятичное

значение

Двоичное

значение Смысл

EOF 236 11101100 Конец файла (End of file)

EOR 239 11101111 Конец записи (End record)

SE 240 11110000 Конец подопции (Suboption end)

NOP 241 11110001 Нет обработки (No operation)

DM 242 11110010 Метка данных (data mark)

BRK 243 11110011 Разрыв (Break)

IP 244 11110100 Прерывание процесса (Interrupt process)

AO 245 11110101 Остановка выхода (Abort output)

AYT 246 11110110 Вы есть? (Are you there?)

EC 247 11110111 Вычеркнуть символ (Erase character)

EL 248 11111000 Вычеркнуть линию (Erase line)

GA 249 11111001 Пройти вперед (Go ahead)

SB 250 11111010 Начинается подопция (Suboption begin)

WILL 251 11111011 Соглашение для допущения опции (Agreement

to enable option)

WONT 252 11111100 Отказ от допустимости опции (Refusal to enable)

DO 253 11111101 Утверждение запроса опции (Approval to option

request)

DONT 254 11101110 Отклонение запроса опции (Denial of option

request)

IAC 255 11111111 Интерпретация (следующего символа) как

управления (Interpret (the next character) as

control)

Вставка документа

TELNET использует только одно TCP-соединение. Сервер задействует закрепленный порт

23, а клиент — кратковременный порт. Такое же соединение применяется для посылки

данных и управляющих символов. TELNET достигает этого, вставляя управляющие

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

каждая последовательность управляющих символов предваряется специальным

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

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

удаленному серверу для отображения файла (file1).

Cat file1

Однако имя файла неправильно набрано на клавиатуре (filea вместо file1), и пользователь

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

Cat filea<backspace>1

Page 91: Osnovnije Internet Protokoli 4

91

Но неправильное выполнение TELNET-пользователь не может редактировать на месте,

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

переводится в два дистанционных символа (IAC EA), которые внедряются в данные и

посылаются к удаленному серверу. Что посылает сервер, показано на рис. 12.6.

Рис. 12.6. Пример вставки

Опции

TELNET позволяет клиенту и серверу опции ведения переговоров перед и в течение

использования услуги. Опция дополнительных свойств возможна для пользователя с

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

минимальные свойства. Таблица 12.2. показывает некоторые употребительные опции.

Таблица 12.2. Опции

Код Опция Смысловое значение

0 Binary (Двоичная) Используется 8-битовый двоичный обмен

1 Echo (Эхо) Эхо-данные, полученные на одной стороне

для другой

3 Suppress go ahead (Продвижение вперед

запрещено)

Сигнал запрещения продвижения вперед

после данных

5 Status (состояние) Запрос состояния TELNET

6 Timing mark (метка времени) Определяет метку времени

24 Terminal type (тип терминала) Настройка типа терминала

32 Terminal speed (скорость терминала) Настройка скорости терминала

34 Line mode (режим линии) Изменение режима линии

• Binary (двоичная). Опция позволяет приемнику интерпретировать каждый 8-

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

следующий символ или символы интерпретируются как команды. Однако если получены

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

данные.

• Echo (эхо). Эта опция позволяет серверу получать эхо-данные от клиента. Это

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

назад на экран терминала. В этом случае пользовательский терминал обычно не

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

сервера.

• Suppress go ahead (продвижение вперед запрещено). Эта опция запрещает

продвижение символа вперед (GA – go ahead). Мы будем обсуждать символ GA при

обсуждении режимов TELNET

Page 92: Osnovnije Internet Protokoli 4

92

• Status (состояние). Эта опция разрешает пользователю или процессу,

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

• Timing mark (метка времени). Эта опция позволяет одной стороне ставить марку

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

• Terminal type (тип терминала). Эта опция позволяет клиенту послать тип своего

терминала.

• Terminal speed (скорость терминала). Эта опция позволяет клиенту повысить

скорость своего терминала.

• Line mode (режим линии). Эта опция позволяет клиенту переключать режимы

линии. Мы будем обсуждать режимы линии позже.

Опции переговоров

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

переговоры между клиентом и сервером. Для этой цели применяются четыре

управляющих символа; они показаны в таблице 12.3.

Таблица 12.3. NVT-символы настройки для опций переговоров

Символ Десятичное

значение

Двоичное

значение Смысловое значение

WILL 251 11111011 1. Предложение для запуска

2. Принятие запроса на запуск

WONT 252 11111100 1. Отказ запросу на запуск

2. Предложение для отключения

3. Принятие запроса на отключение

DO 253 11111101 1. Одобрение предложения на

запуск

2. Требование на запуск

DONT 254 11111110 1. Неодобрение предложения на за

пуск

2. Одобрение предложения на

блокировку

3. Требование на отключение

Запуск опций

Некоторые опции могут быть запущены только сервером, некоторые — только клиентом,

а некоторые — обеими сторонами.

Сторона может запустить опцию, если она имеет право для этого. Предложение может

быть принято и не принято другой стороной. Предлагаемая сторона посылает команду

WILL , которая означает "Я запущу опцию?". Другая сторона может в ответ послать

команду DO, которая означает "Пожалуйста, запускай" (рис. 12.7). Ответом будет команда

WILL, которая означает "Запускаю".

Page 93: Osnovnije Internet Protokoli 4

93

Рис. 12.7. Предложение на запуск опции

В другом варианте вторая сторона может передать команду WONT, которая означает "Не

запущу опцию" (рис. 12.8).

Рис. 12.8. Запрос на запуск опции

Отключение опции

Сторона может предложить отключить опцию. Другая сторона может принять

предложение; может не принять предложение. Предлагающая сторона посылает команду

WONT, которая означает "Я больше не хочу использовать эту опцию". Ответ может быть

команда DONT, которая означает "Больше не используйте ее". Рис. 12.9 показывает

предложение для блокировки опции.

Рис. 12.9. Предложение на отключение опции

Также запрашивающая сторона посылает команду DONT, которая означает "Я больше не

буду использовать эту опцию". Рис. 12.10 показывает запрос на блокировку опции.

Рис. 12.10. Запрос на отключение опции

Пример

Page 94: Osnovnije Internet Protokoli 4

94

Рисунок 12.11 показывает пример переговоров об опции. В этом примере клиент хочет,

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

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

сервер и отослать обратно на экран пользователя, прежде чем обработать. Опция "эхо"

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

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

используя команду DO. Запрос содержит три символа: IAC, DO и ECHO. Сервер

принимает запрос и возможную опцию. Он информирует клиента посылкой трех

символов одобрения: IAC, WILL и ECHO.

Рис. 12.11. Пример эхо-опции

Симметрия

Одно из интересных свойств TELNET — симметричность опции переговоров, в которой

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

протокол предполагает, что обе стороны используют простую реализацию TELNET без

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

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

предложение или отклонить запрос, если эта сторона не способна или не хочет

использовать опцию. Это делает возможным расширение TELNET. Клиент или сервер

может установить более сложную версию TELNET с большим количеством опций. Когда

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

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

случае они отклоняются.

Переговоры по подопциям

Некоторые опции требуют дополнительной информации, например, для того чтобы

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

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

проведения переговоров по субопциям.

Таблица 12.4. NVT-символы настройки подопций

Символ Десятичное значение Двоичное значение Смысловое значение

SE 240250 11110000 Конец подопции

SB 11111010 Начало подопции

Например, тип терминала – это настройка клиентом, показанная на рис. 12.12.

Page 95: Osnovnije Internet Protokoli 4

95

Рис. 12.12. Пример переговоров о субопции

Управляющий сервер

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

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

специальные символы для прерывания (остановки) программы (например, Ctrl+c) или

стирания последнего напечатанного символа (например, кнопка "удалить" или кнопка

"возвращение на одну позицию назад") и так далее. Однако когда программа выполняется

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

машину. Пользователь еще печатает те же самые последовательности, но они изменяются

на специальные символы и посылаются к серверу. Таблица 12.5. показывает некоторые из

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

программой, которая выполняется там.

Таблица 12.5. Символы, которые используются прикладными программами,

выполняемыми на сервере

Символ Десятичное значение Двоичное значение Смысловое значение

IP 244 11110100 Процесс прерывания

AO 245 11110101 Прекращение вывода

AYT 246 11110110 Вы там есть?

EC 247 11111111 Стирание последнего символа

EL 248 11111000 Стирание линии

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

• IP (прерывание процесса). Когда программа выполняется в местном компьютере,

пользователь может прервать (остановить) программу, если, например, она зациклилась.

Пользователь может нажать комбинацию Ctrl+c, операционная система вызывает

функцию, и функция прерывает программу. Однако если программа продолжается на

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

системой удаленной машины. TELNET определяет IP (interrupt process — процесс

Page 96: Osnovnije Internet Protokoli 4

96

прерывания) управляющим символом, который читается и интерпретируется как

соответствующая команда для вызова функции прерывания в удаленной машине.

• AO (abort output – остановка вывода). Это то же самое, что и IP, но он позволяет

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

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

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

имеет состояние выхода. Пользователь может хотеть сохранить состояние выхода для

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

• AYT (Are you there? — Вы там есть?). Этот символ управления используется,

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

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

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

• EC (Erase character — стирание символа). Когда пользователь посылает данные с

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

стереть последний напечатанный символ. Чтобы сделать то же самое в удаленной машине,

TELNET определяет управляющий символ EC.

• EL (Erase line — стирание линии). Это используется, чтобы стереть текущую

линию в удаленном хосте.

Например, рисунок 11.13 показывает, как прервать выполняющуюся бесконечно

прикладную программу на стороне сервера. Пользователь напечатает Ctrl+c, а клиент

TELNET посылает на сервер комбинацию IAC и IP.

Рис. 12.13. Пример прерывания прикладной программы

Передача сигналов вне полосы

Чтобы сделать символы управления эффективными, в специальных ситуациях TELNET

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

предшествует IAC, и удаленному процессу посылают сигнал неисправности.

Вообразим ситуацию, в которой прикладная программа, функционирующая на стороне

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

прервать прикладную программу, но программа не читает данные от буфера. TCP на

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

окна клиента должен быть равен нулю. Другими словами, TCP на стороне сервера

объявляет, что больше не примет регулярный трафик. Чтобы исправить такую ситуацию,

TCP нужно послать от клиента серверу срочный сегмент. Срочный сегмент отменяет

регулярный механизм управления потоком. Хотя TCP обычно не принимает сегменты, он

должен принять срочный сегмент.

Page 97: Osnovnije Internet Protokoli 4

97

Когда процесс TELNET (клиент или сервер) хочет послать вне полосы

последовательность символов к другому процессу (клиент или сервер), он включает

последовательность в поток данных и вставляет специальный символ, названный DM

(Data Marker – знак данных). Однако чтобы вызвать другую сторону для обработки

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

срочность указывается символом DM. Когда TCP получает сегмент, он читает данные и

удаляет любые данные, предшествующие символу управления (например, IAC и IP.).

Когда он достигает символа DM, остающиеся данные обработаются обычным образом.

Другими словами, символ DM используется как символ синхронизации, который

переключает TCP от срочного режима получения к нормальному режиму и

восстанавливает синхронизацию на двух концах (рис. 12.14 ).

Рис. 12.14. Сигнализация вне полосы

Этим способом символ управления (IP) доставляется вне полосы к операционной системе,

которая использует соответствующую функцию, чтобы прервать функционирующую

прикладную программу.

Знак ESC

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

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

случае пользователь может использовать символ escape, обычно Ctrl +] (показанный как

^). Это — сигнал клиенту, указывающий, что команда — не для удаленного сервера, а для

клиента. Рисунок 12.15. сравнивает прерывание прикладной программы удаленной

стороны с прерыванием процесса клиента на местной стороне, с использованием символа

ESC.

Page 98: Osnovnije Internet Protokoli 4

98

Рис. 12.15. Два различных прерывания прикладной программы

Режим работы

Большинство реализаций TELNET работает в одном из трех режимов: заданный по

умолчанию режим, символьный режим и режим линии.

Режим, заданный по умолчанию

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

запрошены никакие другие режимы. В этом режиме возвращение символов делается

клиентом. Пользователь печатает символ, а клиент отображает символ на экране (или

принтере), но не посылает его, пока не закончится вся строка. После посылки полной

строки на сервер клиент ждет команду GA (go ahead) от сервера, перед принятием новой

строки — от пользователя. Эта работа — полудуплексная. Полудуплексная работа не

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

устаревает.

Символьный режим

В символьном режиме каждый напечатанный клиентом символ посылается серверу.

Сервер обычно обрабатывает символ, чтобы отобразить на экране клиента. В этом режиме

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

(такое, как при спутниковой связи). Оно также создает перегрузку (трафика) для сети,

потому что для каждого символа данных нужно послать три сегмента TCP:

Page 99: Osnovnije Internet Protokoli 4

99

1. пользователь вводит символ, который посылает серверу;

2. сервер признает полученный символ и повторяет символ назад (в одном сегменте);

3. клиент подтверждает получение отображенного на экране символа.

Режим строки

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

символьного режима. В этом режиме, названном режимом строки, редактирование строки

(повторение, стирание символа, стирание строки и так далее) делается клиентом. Затем

клиент посылает целую строку серверу.

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

сходство. Режим, заданный по умолчанию, работает в полудуплексном режиме; режим

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

потребности во вмешательстве символа GA (иди дальше — go ahead) от сервера.

Примеры

В этом разделе мы показываем два примера TELNET-взаимодействия между клиентом и

сервером.

Пример 1

В этом примере мы используем режим по умолчанию, чтобы показать его концепцию и

недостатки (несмотря на то, что он сегодня устарел). Клиент и север ведут переговоры о

типе терминала и скорости терминала, и затем сервер проверяет пароль пользователя (рис.

12.16 ).

Page 100: Osnovnije Internet Protokoli 4

100

Рис. 12.16. Пример 1

Пример 2

В этом примере мы покажем, как клиент переключается на символьный режим. Клиент

запрашивает сервер, чтобы запустить в работу опции SUPPRESS GO AHEAD и ECHO

(рис. 12.17 ).

Page 101: Osnovnije Internet Protokoli 4

101

Рис. 12.17. Пример 2

Пользовательский интерфейс

Обычно пользователь не использует команды TELNET так, как это определено выше. Как

правило, операционная система (например, UNIX) определяет интерфейс с командами,

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

таблице 12.6. Заметим, что интерфейс отвечает за перевод команд, дружественных

пользователю, к командам, определенным ранее в протоколе.

Таблица 12.6. Пример команд интерфейса

Команда Смысловое значение

Open Связь к удаленному компьютеру

Close Завершение связи

Display Показ рабочих параметров

Mode Изменение режима строки или символьного режима

Set Установка рабочих параметров

Status Отображение информации о состоянии

Page 102: Osnovnije Internet Protokoli 4

102

Send Посылка специальных символов

quit Выход из TELNET

Команды от клиента на сервер

Клиент может послать команды серверу. Чтобы отличать команду от данных, команды

должны начинаться с двух специальных символов — с двух FF16. Следующие 2 байта

определяют тип команды. Обратите внимание, что, если клиент посылает поток данных,

начинающийся с двух FF16 символов, сервер может воспринять их неправильно. Однако,

очень маловероятно, что эти два символа — часть потока данных.

Пока только одна команда была определена. Это — ss (screen size — размер экрана),

команда, используемая для объявления размера окна экрана. Клиент посылает два

символа из всех единиц (FF16), следующие за ss и

• сопровождаемые 2 байтами, которые показывают число символов в строке,

• сопровождаемые 2 байтами, которые показывают число символов в столбце,

• сопровождаемые 2 байтами, которые показывают число пикселей (элементы

картинки) в X (горизонтальном) направлении,

• сопровождаемые 2 байтами, которые показывают число пикселей в Y

(вертикальном) направлении.