Адаптивная система управления потоком для транспортного протокола в сетях с коммутацией пакетов

Ярославский государственный университет имени П. Г. Демидова

На правах рукописи

Адаптивная схема управления потоком для транспортного протокола в сетях с коммутацией пакетов

05.13.17 - теоретические основы информатики

ДИССЕРТАЦИЯ

на соискание ученой степени кандидата физико-математических наук

Алексеев Игорь Вадимович

Ярославль - 2000 г.

Реферат

В работе предложен новый алгоритм управления скоростью передачи данных для транспортного протокола сети с коммутацией пакетов. Разработанный нами новый протокол получил название ARTCP - Adaptive Rate TCP. Нами показано, что трафик протокола ARTCP обладает свойством самоподобия, разработана и реализована программная модель транспортного протокола, проведен ряд модельных экспериментов показывающих преимущества ARTCP по сравнению с TCP.

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

? Скорость отправки ARTCP сегментов в сеть управляется не размером окна передачи (как в TCP) а индивидуальной задержкой каждого сегмента. Изменение скорости отправки потока выражается в изменении его скважности (межсегментного временного интервала).

? Индикатором текущего состояния сети и соответственно, наступления перегрузки служит не потеря пакета, а изменение скважности потока сегментов, измеряемое получателем, а также изменение времени транзита сегментов, измеряемое отправителем.

? Функционирование ARTCP не зависит от потока подтверждений для синхронизации отправки новых сегментов в сеть.

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

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

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

Цель модельного эксперимента, осуществленного в рамках данной работы - определить значения важнейших характеристик транспортного протокола: вероятность потери сегментов, среднюю длину очереди, эффективность использования пропускной способности канала, показатель равноправия разделения ресурсов и, в сравнении с имеющимися данными по стандартному TCP, показать преимущества нового протокола ARTCP. По данным модельного эксперимента делаем вывод, что превосходство ARTCP по отношению к TCP, наиболее очевидно для беспроводных систем, однако и в обычных проводных сетях применение ARTCP имеет явные преимущества: меньшая по сравнению с TCP средняя длина очереди, полное отсутствие потерь сегментов.

Введение

1.1. Предмет исследования

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

Принято разделять коммуникационные протоколы по степени общности задач, решаемых ими, на несколько уровней, упорядоченный набор которых образует сетевую архитектуру. Самой распространенной и универсальной сетевой архитектурой является архитектура TCP/IP [43, 1]. В рамках TCP/IP все системы в сети делятся на конечные системы, между которыми происходит информационный обмен, и промежуточные системы, не являющиеся конечными или исходными точками обмена. Конечные системы называются узлами сети, а промежуточные - маршрутизаторами.

Двусторонний поток информации между парой смежных систем в сети обеспечивается каналом, связывающим две системы. Каналы характеризуются скоростью информационного потока (пропускной способностью), задержкой передачи и вероятностью битовых ошибок. В каждой точке подключения маршрутизатора к каналу имеется буфер, в котором организуется очередь данных ожидающих отправки по этому каналу. Буферное пространство и пропускная способность (ПС) представляют собой разделяемые ресурсы сети. Если скорость прибытия информации в маршрутизатор превышает максимально возможную скорость ее отправки, то происходит перегрузка сети, выражающаяся в переполнении буферов и потерях информации.

Протокол транспортного уровня занимает важнейшее положение в любой сетевой архитектуре, в том числе и в TCP/IP, поскольку он обеспечивает надежную и эффективную передачу информации непосредственно между конечными системами сети. Для этого транспортный протокол задает согласованный набор правил поведения для участников информационного обмена. Эти правила регулируют совместный доступ узлов к разделяемым ресурсам сети, поэтому эффективность транспортного протокола определяет эффективность работы всей сети в целом. Программа, реализующая алгоритм протокола, называется объектом протокола.

Транспортным протоколом в архитектуре TCP/IP является TCP (Transmission Control Protocol) [4, 5, 6], который обеспечивает надежную двустороннюю связь с контролем скорости передачи. Источник TCP потока получает информацию от пользователя в виде последовательности битов, формирует из нее блоки конечной длины, называемые сегментами и отправляет их к TCP получателю. Получатель, принимая сегменты, формирует из них исходную последовательность и передает ее своему пользователю.

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

Набор соединений транспортного протокола, разделяющих общий канал, представляет собой сложную самоорганизующуюся систему в смысле Г. Хакена [101]. Поведение каждого из объектов протокола в этой системе определяется алгоритмом протокола, однако, поведение всей системы, как целого, вообще говоря, не описывается совокупностью действий ее компонентов. Каждый объект протокола стремится максимально эффективно адаптироваться к доступным ресурсам сети в условиях кооперации с другими объектами этого протокола.

На сегодняшний момент известен ряд существенных недостатков алгоритма управления потоком протокола TCP:

1. Для оценки доступной ПС алгоритм управления потоком TCP постоянно увеличивает скорость отправки сегментов, искусственно вызывая перегрузку сети. Это приводит к частым потерям пакетов и, при устойчивом переполнении буферов, к увеличению задержек сегментов в сети.

2. TCP интерпретирует потерю сегмента как признак перегрузки сети и реагирует на любую потерю данных снижением скорости передачи, что ведет к существенным ограничениям эффективности TCP в сетях, где вероятность потери сегментов из-за возникновения ошибок отлична от нуля. Это относится, в частности, ко всем беспроводным сетям.

3. Локальные неравномерности в отправке сегментов TCP приводят к повышению вероятности потери сегментов при максимальном заполнении буферов.

Устранение приведенных выше недостатков TCP является темой большого числа исследований. В работах на эту тему предлагаются разные варианты усовершенствования транспортного протокола. Большинство протоколов, предлагаемых для использования в сетях с ненулевой вероятностью битовых ошибок, не являются совместимыми с TCP и требуют введения дополнительных элементов в структуру сети, усложняя ее и нарушая основной принцип транспортного протокола, состоящий в том, что на транспортном уровне соединение устанавливается между непосредственным источником и получателем информации.

Таким образом, важнейшей задачей является разработка нового транспортного протокола в рамках архитектуры TCP/IP, который был бы более эффективен, чем TCP. Новый протокол должен быть универсальным в смысле возможности использования его как в проводных, так и беспроводных сетях, что особенно важно в свете дальнейшего развития сетевых технологий и расширения областей их применения.

В диссертации разработан новый транспортный протокол ARTCP. В среде языка C++ создан класс, полностью описывающий протокол ARTCP, который может стать основой реализации протокола. Разработана универсальная объектно-ориентированная имитационная модель для конструирования сетей с топологией любой сложности. Проведенные эксперименты работы протокола ARTCP для ряда сценариев показали, что он почти всегда превосходит стандартный протокол TCP.

1.2. Научная новизна работы

Основные научные результаты диссертации состоят в следующем:

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

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

По данным модельного эксперимента в ИПМ определены важнейшие характеристики ARTCP, а также показано наличие свойства самоподобия у трафика ARTCP. Результаты эксперимента позволяют утверждать, что ARTCP превосходит TCP по основным критериям.

1.3. Практическая ценность результатов

Практическая ценность предлагаемой схемы управления потоком очень высока. Во- первых, протокол ARTCP не доводит сеть до состояния перегрузки для выявления доступной максимальной пропускной способности, поэтому потери пакетов в стабильном состоянии работы сети вообще не происходят. Таким образом, повышается эффективность использования сетевой инфраструктуры, что дает прямой экономический эффект.

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

В-третьих, средняя длина очередей в маршрутизаторах сети при использовании ARTCP минимальна, поскольку ARTCP не только адаптирует скорость отправки пакетов в сеть к максимальной скорости обслуживания потока, но и обладает механизмом компенсации перегрузки. Таким образом, среднее время транзитной задержки пакетов в сети снижается.

В-четвертых, алгоритм ARTCP не противоречит созданию совместимой с TCP реализации. Поэтому внедрение ARTCP может происходить постепенно, в первую очередь на тех узлах, где применение нового протокола наиболее выгодно.

1.4. Апробация работы

По результатам, полученным в ходе работы, были сделаны доклады на международном семинаре IEEE «Интернет: технологии и сервисы», а также на семинарах ЯрГУ: "Моделирование и анализ информационных систем", "Нейронные сети". Новый протокол вызвал большой интерес и одобрение со стороны экспертов в области телекоммуникаций.

1.5. Содержание работы

Для создания алгоритма нового протокола и разработки его имитационной модели необходимо рассмотреть все компоненты транспортного протокола. В части 1.7 введения (коммуникационные транспортные протоколы), даны важнейшие определения, принципы и алгоритмы, которые используются далее по тексту. В части 1.8 (управление потоками в коммуникационных системах) рассмотрены работы в области управления скоростью передачи в распределенных сетях построенных на принципе коммутации пакетов. Самоподобие сетевого трафика и важнейшие работы в этой области описаны в части 1.9 (свойство самоподобия сетевого трафика) введения. На основе типичных задач и путей решения проблемы управления потоками можно осуществить постановку задачи - создание протокола, свободного от недостатков TCP, это сделано в главе 1. В главе 2 дано описание алгоритма предлагаемого протокола ARTCP, и его функциональных компонентов. В главе 3 приведено описание разработанной имитационной модели сети и аспекты ее объектной реализации. В главе 4 приведены результаты модельных экспериментов, дано сравнение свойств ARTCP и TCP, а также показано свойство самоподобия ARTCP трафика. Работа завершается выводами.

1.6. Благодарности

Хочу выразить искреннюю благодарность своему научному руководителю проф. В. А. Соколову за ценные советы и помощь с работой. Особенно хочется отметить помощь и поддержку, оказанную научным консультантом проф. Тимофеевым Е. А.

Отдельное спасибо моим коллегам по Центру Интернет ЯрГУ, в частности, проректору по информатизации Русакову А. И. за помощь и поддержку, а также руководителю проекта "Региональный кластер научных вычислений"1 (грант РФФИ № 98-07-90171) Захаровой М. Н. за предоставление возможности осуществлять разработку программной модели и модельный эксперимент, а также всем, кто оказывал мне помощь и поддержку.

Написание данной диссертации является частью работ выполняемых по проекту "Развитие высокоскоростного сегмента Ярославской региональной опорной сети на основе АТМ технологий" (грант РФФИ № 98-07-90307).

1.7. Коммуникационные транспортные протоколы

1.7.1. Современные коммуникационные сети

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

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

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

1.7.2. Аппаратная инфраструктура сетей

Аппаратная часть это физическая инфраструктура, посредством которой осуществляется распространение физических сигналов кодирующих информационные сообщения. Физическая инфраструктура может либо осуществлять информационный обмен между всеми участниками сети одновременно (широковещательная сеть), либо только между двумя узлами (сеть типа точка-точка). В зависимости от масштаба и топологии сетевой инфраструктуры производят ее дальнейшую классификацию: локальные вычислительные сети (ЛВС), территориальные сети (WAN), сотовые сети и т.д.

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

1.7.3. Системы протоколов

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

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

- через определение его функциональных компонентов [3]:

ѕ Протокол определяет точный формат допустимых сообщений (синтаксис);

ѕ Протокол определяет процедурные правила для обмена информацией (грамматика);

ѕ Протокол определяет словарь правильных сообщений и их значения (семантика);

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

1.7.3.1. Методы формального описания

Существуют несколько методов для формального описания протоколов. Это языки SDL (Specification and description language), Lotos и Estelle. Наиболее часто применяется язык SDL, который является стандартом ITU2. Существуют две формы SDL - графическая и программная [55]. Естественно, что из всех компонентов протокола именно процедурные правила могут быть даны с помощью того или иного языка формального описания.

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

ѕ Он должен быть минимальным, т.е. не содержать недостижимых элементов или участков кода

ѕ Он должен быть логически связным

ѕ Он должен удовлетворять условию полноты

ѕ Этот набор должен быть легко реализуем (аппаратным или программным образом)

1.7.3.3. Пять элементов протокола

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

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

1. Сервис, предоставляемый пользователю

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

3. Словарь допустимых сообщений

4. Кодировка сообщений - формат каждого сообщения из словаря

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

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

На низком уровне абстракции протокол можно представить в виде конечных автоматов. В своей монографии [3] Хольцман предлагает так называемую модель связанных конечных автоматов для формализованного описания протокола. В этом случае задачи разработки, формальной верификации и проверки на совместимость сводятся к нахождению желаемых/нежелаемых состояний и переходов. Каждый из связанных конечных автоматов может получать символы на вход, осуществлять переход в новое состояние и генерировать символьную информацию на выходе. Отдельные конечные автоматы связываются между собой посредством ограниченных FIFO очередей, через которые выходной сигнал одного автомата поступает на вход другого. Так моделируется асинхронная связь, характерная для большинства коммуникационных систем.

Определение очереди: очередь сообщений (символов) представляется тройкой (S, N, C), где S - ограниченное множество определяющее словарь очереди, N - целое число позиций в очереди, C - упорядоченное множество элементов из S. S и С: множества сообщений. Если модель системы требует наличия нескольких очередей, то их словари должны образовывать непересекающиеся множества. Если M множество всех системных очередей, индекс

1 ? m ?| M | нумерует очереди, а 1 ? n ? N позиции внутри очереди,

C m - n-ный символ в m-той очереди. Системный словарь тогда выражается через словари каждой из очередей и нулевой символ е :

|M |

m ?1

m Х е . В [3] дается определение связанных конечных автоматов как набора (Q, , M, T), где Q - конечное непустое множество состояний, - элемент Q - начальное q0 q0 состояние, M - множество символьных очередей, определенных выше, T - отношение перехода. T имеет два аргумента T(q, a), где q текущее состояние и a - действие (одно из: ввод, вывод, пустое действие). Реализация перехода с действиями типа ввод/вывод зависит от состояния символьных очередей. При их реализации изменяется состояние одной из очередей. Отношение перехода T задает множество (которое может быть пустым) всех возможных результирующих состояний. Достаточным условием реализации T(q, е ) является то, что текущее состояние есть q.

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

1.7.3.5. Иерархии протоколов

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

Рис. 1. Пример инкапсуляция данных одного протокола в формате сообщений другого. Протокол 2 инкапсулирует сообщения протокола 1.

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

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

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

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

Набор слоев и соответствующих им протоколов называется архитектурой сети. Упорядоченный набор протоколов определенных в рамках конкретной сетевой архитектуры называется стеком протоколов. Каждый из N уровней одной системы осуществляет обмен с уровнем N конечной системы, используя для этого сервисы уровня N-1, при этом каждый из промежуточных уровней инкапсулирует3 данные верхнего уровня внутри своего формата сообщений (рис. 1.). Таким образом, на каждом уровне N процедура, отправляющая или получающая данные от уровню N другой системы, на самом деле отправляет информацию для обработки на уровень N-1 своей системы, снабдив данные своей контрольной информацией.

1.7.3.6. Общие свойства уровней иерархической системы

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

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

1.7.3.7. Сервисы и интерфейсы

Рис. 2. Преобразование потока информации на интерфейсе NSAP между смежными уровнями сетевой архитектуры.

Предоставление сервисов верхним уровням является главной задачей каждого из уровней. Активные элементы внутри каждого из уровней называются объектами протокола. Объект может представлять собой программный процесс или часть функциональности аппаратуры, например интеллектуальный контроллер ввода/вывода. Объекты уровня N реализуют сервисы, используемые уровнем N+1. В этом случае уровень N является поставщиком услуг, а уровень N+1 пользователем. Уровень N для выполнения своей задачи по предоставлению набора сервисов уровню N+1 может сам выступать пользователем услуг уровня N-1. Возможно предоставление нескольких типов сервиса, например быстрой и ненадежной связи наряду с медленной и надежной. Сервисами уровня можно воспользоваться через интерфейс, называемый точкой доступа к сервису (ТДС). Каждый из возможных ТДС уровня N это интерфейс, на котором объект уровня N+1 может иметь доступ к сервисам уровня N. Каждая ТДС идентифицируется уникальным адресом. Чтобы два смежных уровня могли обмениваться информацией необходимо наличие набора правил регламентирующих распределение доступа и интерфейс между ними (рис. 2.).

IDU - формат блока данных на соответствующем интерфейсе

ICI - контрольная информация для нижележащего уровня

PDU - сообщение, определенное протоколом соответствующего уровня

IDU - сообщение в формате интерфейса между уровнями

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

Data - передаваемые данные

Механизм обмена следующий: сущность уровня N снабжает данные заголовком несущим информацию для протокола уровня N. На приемной стороне соединения заголовок Nh будет использован уровнем N для восстановления данных в исходном виде, после чего сами данные будут переданы пользователю уровня N. Данные совместно с заголовком образуют сообщение протокола уровня N (PDU). Кроме того, уровень N передающей стороны снабжает N PDU дополнительной контрольной информацией для уровня N-1 (N-1 ICI). Структура, содержащая ICI и PDU, образует так называемое сообщение в формате интерфейса между уровнями (IDU) которое передается нижележащему уровню.

На уровне N-1 от сообщения отделяется контрольная информация N-1 ICI, которая определяет способ обработки данного сообщения. После этого уровень N-1 генерирует собственную контрольную информацию для уровня N-2 (N-2 ICI) и добавляет ее к сообщению вместе с заголовком протокола уровня N-1 (N-1 h). После этого получившаяся структура данных передается на уровень N-2 для дальнейшей обработки.

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

1.7.3.8. Типы соединений

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

В случае сервиса с установлением логического соединения обмен данными может начаться лишь после того, как от отправителя до получателя установлен логически выделенный канал. Протокол транспортного уровня TCP функционирует именно по такой схеме.

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

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

1.7.3.9. Примитивы сервисов

Сервис формально определяется набором примитивов, определяющих операции, доступные пользователю. Примитивы являются командами объекту сервиса совершить определенное действие или выдать отчет о выполнении действия. Одним из способов классификации операций сервиса является организация их примитивов в четыре основных класса:



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

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

CONNECT.request - запрос на установление соединения

CONNECT.indication - сигнал вызываемой стороне

CONNECT.response - применяется вызываемой стороной для подтверждения/отмены установления соединения

CONNECT.confirm - сообщение вызывающей стороне о приеме запроса на соединение

DATA.request - запрос на передачу данных

DATA.indication - сигнал о приеме данных

DISCONNECT.request - запрос на разъединение

DISCONNECT.indication - сигнал другой стороне о разъединении

1.7.3.10.Связь сервисов и протоколов

Сервис это набор примитивов (элементарных действий) которые уровень N предоставляет пользователю - т.е. уровню N+1. Сервис относится к интерфейсу между двумя уровнями. Протокол, с другой стороны, есть набор правил, определяющих формат и значение сообщений, обмениваемых между объектами коммуникационных узлов, находящимися на одинаковом уровне и связанных через сеть. Объекты пользуются протоколами для реализации своих сервисов. По аналогии с объектными языками программирования сервис является классом, в котором определены операции, которые могут быть осуществлены, но не оговариваются детали их внутренней реализации, каковая и является тем или иным протоколом.

1.7.4 Эталонные модели

1.7.4.1. Модель ISO OSI RM

Международной организацией по стандартизации (ISO) в целях унификации методов разработки протоколов была предложена так называемая эталонная модель взаимодействия открытых систем (OSI RM) (рис. 3.).

Рис. 3. Эталонная модель взаимодействия открытых систем (ЭМВОС). Уровни и направление передачи данных.

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

Эталонная модель OSI RM состоит из семи уровней:

1.7.4.1.1. Физический уровень

В задачу этого уровня входит корректная передача битового потока по физической линии связи. Когда отправитель передает «1», бит принимающая сторона должна получить его как «1» бит, а не «0». Спецификации этого уровня задают как логические, так и физические и схемотехнические параметры. Физический уровень рассматривает информацию как непрерывный битовый поток.

1.7.4.1.2. Канальный уровень

Этот уровень создает логический канал, не имеющий ошибок и сбоев, для нужд сетевого уровня. Отправляемая информация разбивается на блоки, называемые кадрами, которые пересылаются поочередно. В некоторых случаях уровень создает и обрабатывает кадры с подтверждением корректного приема данных. Поскольку физический уровень имеет дело с неструктурированным потоком битов, то канальный уровень должен заботиться о создании и отслеживании границ кадров. Также канальный уровень может применять различные алгоритмы для определения и по возможности коррекции искажения информации.

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

1.7.4.1.3. Сетевой уровень

Задачей сетевого уровня является управление работой базовой подсети. Важнейшая проблема - рассчитать путь от точки отправления то получателя. Такой маршрут может быть основан на статических таблицах хранящихся в памяти устройств подсети или же маршрут может определяться в начале каждой сессии, альтернативным вариантом является высоко- динамическая маршрутизация, когда путь заново определяется для каждого отдельного пакета. Если в базовую подсеть попадает больше пакетов, чем сеть может обрабатывать, то возникает перегрузка, борьба или профилактика которой также является задачей сетевого уровня. Единица информационного обмена на сетевом уровне называется пакетом.

1.7.4.1.4. Транспортный уровень

Транспортный уровень предоставляет услуги (и скрывает от вышележащих уровней) по надежной транспортировке данных по сети. Данный уровень обеспечивает открытие, поддержку и нормальное отключение виртуальных каналов, передает сообщения об ошибках и сбоях, осуществляет управление скоростью потоков информации, чтобы избежать переполнения буферов сетевых устройств и приемников и, соответственно, потерь данных. Отличительной особенностью транспортного уровня является то, что объекты протокола транспортного уровня осуществляют обмен напрямую, вне зависимости от базовой подсети. Единица информационного обмена на транспортном уровне называется сегментом или датаграммой.

1.7.4.1.5. Сеансовый уровень

Этот уровень синхронизирует, открывает, закрывает и манипулирует сеансами связи, активными объектами уровня презентации (каковых может быть несколько). Уровень СЕАНСА присваивает степень срочности сообщениям, руководит ускоренной передачей сообщений об возникших ошибках вышележащим уровням.

1.7.4.1.6. Уровень презентации

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

1.7.4.1.7. Уровень приложения

Этот уровень отличается от остальных тем, что его объектами являются непосредственно приложения, исполняемые на вычислительном узле. Функция этого уровня заключается в определении клиентов, которым необходима коммуникация, синхронизации коммуникации, определении наличие ресурсов для проведения сеанса коммуникации и детектирования ошибок.

1.7.4.2. Модель TCP/IP

В середине 1970-х американской военной исследовательской организацией DARPA было принято решение о создании сети с коммутацией пакетов для обеспечения соединения исследовательских учреждений на территории Соединенных Штатов. В то время исследователи и производители впервые столкнулись с проблемой организации в сеть разнообразных и гетерогенных компьютерных систем. С целью выработки протоколов связи для разнородных систем DARPA начала финансирование исследований проводимых в Станфордском университете по созданию семейства сетевых протоколов. Второй целью было создание сети имеющей возможность продолжать функционировать даже при выходе из строя существенной доли ее аппаратной части. В результате этой работы появились протоколы семейства Internet protocols. Способность новой разработки соединять сети, основанные на разных технологиях, совершенно прозрачным образом была основной задачей разработчиков с самого начала. Наиболее практичными и широко используемыми членами этого семейства являются протоколы Transmission Control Protocol (TCP) - протокол контроля передачи и Internet protocol (IP) протокол интернета, а сама архитектура стала известной под названием эталонной модели TCP/IP.

Семейство протоколов TCP/IP применяется для коммуникации через любое количество промежуточных ЛВС. Протоколы TCP/IP идеально подходят как для коммуникации в ЛВС, так и для глобальных вычислительных сетей. Набор протоколов TCP/IP содержит спецификации не только протоколов низкого уровня, таких как TCP или IP, но также и таких широко распространенных приложений как электронная почта, эмуляция удаленного терминала, протокол передачи файлов и многое другое.

Рис. 4. Сопоставление эталонных моделей сетевых архитектур ЭМВОС и TCP/IP.

Как видно из рис. 4. уровни модели TCP/IP не полностью совпадают с уровнями модели OSI. Основные составляющие модели TCP/IP соответствуют сетевому и транспортному уровням ЭМВОС. Эти протоколы - IP и TCP являются ключевыми для концепции современной коммуникационной архитектуры (рис. 5.).

Рис. 5. Современная концепция сетевой архитектуры.

1.7.4.2.1. Сетевой протокол модели TCP/IP: протокол IP

Протокол IP является единственным протоколом сетевого уровня семейства TCP/IP, поэтому все транспортные протоколы стека TCP/IP используют сервисы протокола IP. Т.е. сервис, представляемый IP, является средой, в которой исполняется протокол TCP.

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

1.7.4.2.2. Транспортные протоколы модели TCP/IP

Транспортный уровень набора протоколов интернета состоит из двух протоколов: TCP (Transmission Control Protocol - протокол контроля передачи) и UDP (User Datagram Protocol - протокол пользовательских датаграмм). TCP предоставляет надежный транспорт с установкой логического соединения

TCP является наиболее важным транспортным протоколом модели TCP/IP он обеспечивает полностью дуплексную связь с кумулятивным подтверждением приема. Он перемещает информацию в виде непрерывного неструктурированного потока, где байты идентифицируются порядковым номером. Объект протокола TCP может одновременно поддерживать множество сеансов информационного обмена для протоколов высших уровней, осуществляя мультиплексирование потоков.

1.7.5. Эволюция коммуникационных протоколов

Рассмотрим процесс развития сетевых протоколов на примере стека TCP/IP. Нас интересует вопрос преемственности в развитии протоколов, и их обратной совместимости. На развитии реальных протоколов отражается множество факторов: это степень сложности протокола, качество его спецификации, верифицируемость данного протокола и результаты его тестирования на соответствие стандартам. Кроме того, ряд практических характеристик протокола может существенно повлиять на его реальное использование и одним из важнейших факторов здесь является обратная совместимость нового протокола с предыдущими версиями или реализациями.

Обратная совместимость новой версии протокола означает, что его реализация сможет взаимодействовать со старыми версиями без потери производительности, причем улучшение характеристик работы системы будет происходить при взаимодействии новых версий протоколов или в некоторых случаях уже при взаимодействии старой версии с новой. Целесообразность требования обратной совместимости вполне оправдана, с другой стороны, диалектическое развитие протоколов коммуникационных систем приводит к необходимости смены одного протокола на другой, несовместимым с прежним на определенном этапе развития системы. При этом обратная совместимость либо не сохраняется вовсе, либо обеспечивается за счет временного применения дополнительных механизмов не являющихся частью системы протоколов. Такая ситуация наблюдается в настоящее время, когда сетевой протокол в сети Интернет IP версии 4 заменяется на новую версию IPv6 [41], которая не предусматривает обратной совместимости со старым протоколом Интернет. Такой подход вполне оправдан, поскольку задача обеспечения обратной совместимости требует усложнения многих компонентов протокола - его словаря и процедурных правил, существенно затрудняет его анализ и верификацию. В случае IPv6 было решено пожертвовать обратной совместимостью для обеспечения минимальности и простоты множества процедурных правил протокола.

Первая спецификация транспортного протокола TCP была дана в работе [4] в 1980 году. За прошедшие 20 лет протокол TCP подвергался большому количеству оптимизаций и дополнений, которые либо решали очевидные проблемы выявляющиеся по ходу применения протокола, либо улучшали его характеристики для систем узкой специализации. Все эти изменения оставляли протокол совместимым со старыми версиями. В результате сложность протокола TCP возросла настолько, что полный перебор достижимых состояний конечного автомата моделирующего протокол и даже контролируемый выборочный перебор не являются возможными для автоматизированной верификации. Вследствие этого затруднена не только автоматизированная верификация протокола TCP, но и ручной анализ даже избранных наборов его состояний.

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

1.7.6. Транспортный уровень: роль и компоненты

Транспортный уровень является центральным для всей иерархии протоколов. Задача этого уровня - обеспечивать надежную и эффективную транспортировку информации от исходного к конечному устройству вне зависимости от физических особенностей сетей или ограничений накладываемых протоколами БС.

1.7.6.1. Сервис транспортного уровня

1.7.6.1.1. Сервисы, предоставляемые пользователю

Рис. 6. Обмен данными на уровне транспортного протокола. Формат данных транспортного протокола: TPDU.

Главная задача транспортного уровня заключается в предоставлении эффективного и надежного сервиса для соответствующих пользователей - главным образом пользовательским процессам уровня приложения. Для выполнения этих задач транспортный уровень полагается на сервисы сетевого уровня. Аппаратное и/или программное обеспечение, выполняющее функции транспортного уровня называется транспортным объектом. Этот объект может быть частью ядра операционной системы, отдельным процессом в пользовательском пространстве, в виде библиотечных объектов скомпонованных с пользовательскими программами или функцией отдельной интерфейсной платы. Блок данных, посредством которого происходит обмен между объектами транспортного протокола, называется TPDU (сообщение транспортного протокола) (рис. 6.).

В отличие от всех нижних уровней, транспортный уровень функционирует непосредственно между участниками обмена информацией, напрямую и позволяет этим системам обмениваться информацией вне зависимости от промежуточных сетей и систем. Пользователи, как правило, не имеют контроля над БС, поэтому единственный способ, посредством которого они могут влиять на качество услуг БС, это использование дополнительного уровня над сетевым.

Транспортные протоколы делают возможным предоставлять пользователю транспортный сервис гораздо более надежный, чем используемый сетевой сервис. Наличие потерянных и поврежденных пакетов контролируется и компенсируется транспортным уровнем. Кроме того, сервисные примитивы транспортного уровня могут быть разработаны таким образом, чтобы быть полностью независимыми от сетевых сервис примитивов, которые радикально различаются для разных типов сетей. Благодаря наличию транспортного уровня, пользовательские приложения могут разрабатываться с применением стандартного интерфейса (стандартного набора вызовов сервис примитивов) и использоваться без изменений на самых разных типах сетевых технологий, что и имеет место на практике. Транспортный уровень изолирует прикладные программы от особенностей технологии, разработки, ненадежности и разнородности сетей. Именно поэтому существует разделение уровней модели OSI RM на две группы с 1-го по 4-й и выше 4-й. Первая называется поставщиком транспортных услуг, вторая - пользователем транспортных услуг. Проведение такого различия, во-первых, влияет на специфику реализации уровней и протоколов, а во- вторых, ставит транспортный уровень на место ключевого звена в иерархической модели, поскольку он находится на интерфейсе между поставщиком и пользователем надежного транспортного сервиса. Основная задача транспортного уровня в том, чтобы максимально улучшить качество услуг сетевого уровня.

Рассмотрим, каким образом протокол TCP улучшает параметры сервиса по сравнению с сервисом сетевого уровня. Как было сказано ранее совокупное влияние физического, канального и сетевого уровней на передаваемые данные выражается в появлении трех типов ошибок данных:

ѕ Потеряѕ Дублирование

ѕ Искажение порядка отправки

Протокол TCP полностью устраняет эти ошибки. С точки зрения пользователя транспортного протокола, сеть выглядит как полностью дуплексный канал, который перемещает поток байтов пользователя без потерь, причем байты появляются из канала в том самом порядке, в котором они поступили в него на передающей стороне и только однократно. Выполнение всех этих функций никак не зависит от используемых технологий сетевого, канального и физического уровней, каковых может быть много на маршруте от отправителя до получателя.

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

1.7.6.1.3. Примитивы транспортного сервиса

Примитивы транспортного сервиса уже являются достаточной формализацией для описания сервисного компонента протокола. Через эти примитивы пользователи (приложения) получают доступ к услугам транспортного уровня. Каждый тип транспортного сервиса имеет свой набор примитивов. В отличие от ненадежной связи без установки ВК на сетевом уровне, транспортный уровень предлагает надежную связь с построением логического канала.

Поскольку реальные сети не могут гарантировать отсутствия ошибок, то задача транспортного уровня как раз в том, чтобы обеспечить надежную связь, пользуясь ненадежной. Например, два процесса использующие именованный коммуникационный канал (pipe) [86] в среде ОС UNIX [64], в своей работе предполагают, что соединение является идеальным. Разработчику программы реализующей эти процессы нет необходимости заботиться об отслеживании подтверждений, потерь сообщений, перегрузок. Соединение для него выглядит как абсолютно надежное. Аналогично, транспортные протоколы представляют ненадежный канал как битовый поток свободный от ошибок для пользователя.

В качестве дополнительного сервиса транспортный уровень может предлагать и ненадежную связь без подтверждений приема и управления потоком, в среде TCP/IP такой сервис реализуется протоколом UDP.

Различны также и пользователи транспортного и сетевого уровня. Сетевой сервис используется только объектами транспортного уровня. Крайне редко программы разрабатываются так, чтобы использовать сервисы сетевого уровня напрямую. Основная масса приложений разрабатывается именно в расчете на использование сервисов, а, следовательно, и примитивов транспортного уровня. Поэтому спецификация сервиса транспортного уровня должна быть универсальной и простой в использовании, как, например, интерфейс Berkeley Sockets.

Для того чтобы составить представление о примитивах транспортного сервиса рассмотрим реальный интерфейс Berkeley Sockets [84, 85]

Это интерфейс для взаимодействия приложений с объектами транспортных протоколов, включая протокол TCP. Изначально был разработан для работы с TCP в операционной системе семейства BSD UNIX [64] в 1980 году. Сейчас интерфейс Berkeley Sockets является промышленным стандартом и используется в большинстве операционных систем.

Примитив	Пояснение
SOCKET	Создать новую точку доступа к системе связи (ТДС)
BIND	Присвоить локальный адрес ТДС
LISTEN	Объявить о готовности к приему соединений, установить размер очереди
ACCEPT	Блокировать инициатора до поступления запроса на соединение
CONNECT	Активная попытка установки соединения
SEND	Передача данных
RECEIVE	Получение данных
CLOSE	Завершить сеанс связи

Пользователь получает доступ к данным примитивам на UNIX системе в виде системных вызовов, поскольку объект протокола TCP в системе UNIX является частью ядра операционной системы [86].

Вызов SOCKET в случае успешного завершения возвращает дескриптор4 файла и выделяет место под таблицы в контрольных блоках на транспортном уровне. Параметры вызова указывают на тип и характеристики требуемого сервиса.

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

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

Разрыв соединения происходит при выполнении примитива CLOSE и является симметричным.

1.7.6.2. Характеристика среды исполнения

Для того, что бы определить среду исполнения протокола TCP или его предложенной модификации ARTCP необходимо рассмотреть принципы функционирования уровней иерархии, сервисами которых пользуется транспортный протокол. Согласно эталонной модели OSI RM транспортному уровню предшествуют сетевой, канальный и физический уровни иерархии. Поскольку задача каждого из уровней в том, чтобы максимально изолировать своего от проблем нижних уровней, достаточно рассмотреть лишь сервис сетевого уровня.

1.7.6.2.1. Сервисы сетевого уровня