WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 |
-- [ Страница 1 ] --

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

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

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

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. Предмет исследования 1.2. Научная новизна работы 1.3. Практическая ценность результатов 1.4. Апробация работы 1.5. Содержание работы 1.6. Благодарности 1.7. Коммуникационные транспортные протоколы 1.8 Свойство самоподобия сетевого трафика 1.9 Управление потоками в коммуникационных системах Глава 1. Постановка задачи 1.1. Недостатки протокола TCP 1.2. Цель работы 1.3. Формальная модель системы 1.4. Основные характеристики протокола 1.5. Сеть как самоорганизующаяся система Глава 2. Алгоритм ARTCP 2.1. Аспекты новизны протокола ARTCP 2.2. Эвристика в основе алгоритма ARTCP 2.3. Параметры и переменные 2.4. Формат сообщения 2.5. Структурная схема ARTCP 2.6. Совместимость с TCP 2.7. Сравнение ARTCP и TCP на основе анализа алгоритма 2.8. Направления дальнейшего развития ARTCP Глава 3. Имитационная модель 3.1. Формат сообщения 3.2. Объектная структура ПМ 3.3. Главный цикл 3.4. Дуплексный режим 3.5. Трассировка модели 3.6. Визуализация данных 2 6 6 8 9 9 9 10 10 47 55 65 66 67 67 68 69 70 70 71 72 73 73 81 81 83 85 86 87 95 96 96 Глава 4. Результаты моделирования 4.1. Общая схема модельного эксперимента 4.2. Сценарий 1: изолированный ARTCP 4.3. Сценарий 2: определение важнейших параметров сети 4.4. Сценарий 3: ARTCP и TCP в условиях ошибок передачи 4.5. Сценарий 4: ARTCP и TCP - коэффициент использования 4.6. Сценарий 5: ARTCP и TCP - коэффициент равноправия 4.7. Сценарий 6: ARTCP и TCP средняя длина очереди 4.8. Сценарий 7: 1 ARTCP и 1 CBR 4.9. Сценарий 8: 2 ARTCP и 1 CBR 4.10. Сценарий 9: свойство самоподобия трафика ARTCP Основные выводы Список литературы 102 102 104 111 116 118 120 122 125 129 133 138 Введение 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. (свойство самоподобия сетевого трафика) введения. На основе типичных задач и путей решения проблемы управления потоками можно осуществить постановку задачи - создание протокола, свободного от недостатков TCP, это сделано в главе 1. В главе 2 дано описание алгоритма предлагаемого протокола ARTCP, и его функциональных компонентов. В главе 3 приведено описание разработанной имитационной модели сети и аспекты ее объектной реализации. В главе 4 приведены результаты модельных экспериментов, дано сравнение свойств ARTCP и TCP, а также показано свойство самоподобия ARTCP трафика.

Работа завершается выводами. 1.6. Благодарности Хочу выразить искреннюю благодарность своему научному руководителю проф. В. А. Соколову за ценные советы и помощь с работой. Особенно хочется отметить помощь и поддержку, оказанную научным консультантом проф. Тимофеевым Е. А. Отдельное спасибо моим коллегам по Центру Интернет ЯрГУ, в частности, проректору по информатизации Русакову А. И. за помощь и поддержку, а также руководителю проекта "Региональный кластер научных вычислений"1 (грант РФФИ № 98-07-90171) Захаровой М. Н. за предоставление возможности осуществлять разработку программной модели и модельный эксперимент, а также всем, кто оказывал мне помощь и поддержку. Написание данной диссертации является частью работ выполняемых по проекту "Развитие высокоскоростного сегмента Ярославской региональной опорной сети на основе АТМ технологий" (грант РФФИ № 98-07-90307). 1.7. Коммуникационные транспортные протоколы 1.7.1. Современные коммуникационные сети Важность сетей передачи данных и мультимедиа информации невозможно переоценить сегодня, в начале информационной эпохи развития человечества. Системы сбора, обработки и распределения информации являются важнейшей точкой приложения научного знания. Развитие технологии устранило различия между обработкой и передачей информации, а наиболее актуальной задачей в коммуникации стала спецификация и верификация коммуникационных протоколов, а также повышение их эффективности. Современное определение сети передачи данных такое: сеть это набор автономных вычислительных устройств физически и логически связанных между собой. Иными словами Региональный кластер научных вычислений "Cyclone" состоит из трех Alpha-станций под управлением ОС Digital UNIX. Подробная информация по адресу http://cluster.yars.free.net/cluster набор равноправных узлов имеющих возможность обмениваться информацией. Такое определение относится к так называемой сети передачи данных, однако, не ограничивается только компьютерными данными и может быть расширено для любой сети, построенной по принципу коммутации пакетов, в том числе и универсальной сети с интеграцией сервисов. Сети передачи данных и мультимедиа информации в современном обществе применяются повсеместно – в производстве и в сфере управления, в исследовательской среде и в быту. Экономическая выгода от повышения эффективности коммуникационных протоколов может оказаться очень существенной, особенно с учетом дальнейшего роста и развития коммуникационных систем. Любая коммуникационная система состоит из двух основных компонентов: аппаратной и логической частей. 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. Процедурные правила, контролирующие обмен сообщениями Формализованное описание сервиса и характеристик среды исполнения протокола находят отражение в процедурных правилах. Для реализации своей задачи – предоставления International Telecommunications Union – международная организация разрабатывающая стандарты в области телекоммуникаций сервиса верхнего уровня протокол должен выполнять ряд задач низкого уровня – синхронизации, распознавания и коррекции ошибок. То, как протокол выполняет эти задачи, зависит от свойств среды его исполнения. Словарь допустимых сообщений и их кодировка также связаны с предположениями о среде исполнения протокола – среде передачи данных. Вероятность возникновения битовых ошибок и средняя длина поля последовательности битовых ошибок влияют на набор, формат и кодировку сообщений протокола, а также выбор алгоритма распознавания или коррекции ошибок. 1.7.3.4. Определение протокола через "связанные конечные автоматы" На низком уровне абстракции протокол можно представить в виде конечных автоматов. В своей монографии [3] Хольцман предлагает так называемую модель связанных конечных автоматов для формализованного описания протокола. В этом случае задачи разработки, формальной верификации и проверки на совместимость сводятся к нахождению желаемых/нежелаемых состояний и переходов. Каждый из связанных конечных автоматов может получать символы на вход, осуществлять переход в новое состояние и генерировать символьную информацию на выходе. Отдельные конечные автоматы связываются между собой посредством ограниченных FIFO очередей, через которые выходной сигнал одного автомата поступает на вход другого. Так моделируется асинхронная связь, характерная для большинства коммуникационных систем. Определение очереди: очередь сообщений (символов) представляется тройкой (S, N, C), где S - ограниченное множество определяющее словарь очереди, N - целое число позиций в очереди, C - упорядоченное множество элементов из S. S и С: множества сообщений. Если модель системы требует наличия нескольких очередей, то их словари должны образовывать непересекающиеся множества. Если M множество всех системных очередей, индекс 1 m | M | нумерует очереди, а 1 n N позиции внутри очереди, C nm - n-ный символ в m-той очереди. Системный словарь тогда выражается через словари каждой из очередей и нулевой символ :

M V = |m =|1 S m. В [3] дается определение связанных конечных автоматов как набора (Q, q0, M, T), где Q - конечное непустое множество состояний, q0 - элемент Q - начальное состояние, 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 блокирует процесс вызвавший его в ожидании соединения. Примитив CONNECT блокирует вызвавший его процесс и начинает активную попытку открыть соединение. Когда этот вызов указатель по которому пользовательские программы могут иметь доступ к файлам или другим объектам операционной системы возвращается, процесс деблокируется, и может начинать обмен информацией по уже установленному соединению. Разрыв соединения происходит при выполнении примитива CLOSE и является симметричным. 1.7.6.2. Характеристика среды исполнения Для того, что бы определить среду исполнения протокола TCP или его предложенной модификации ARTCP необходимо рассмотреть принципы функционирования уровней иерархии, сервисами которых пользуется транспортный протокол. Согласно эталонной модели OSI RM транспортному уровню предшествуют сетевой, канальный и физический уровни иерархии. Поскольку задача каждого из уровней в том, чтобы максимально изолировать своего от проблем нижних уровней, достаточно рассмотреть лишь сервис сетевого уровня.

1.7.6.2.1. Сервисы сетевого уровня Доступ к сервисам сетевого уровня возможен на интерфейсе между сетевым и транспортным уровнями. Важность данного интерфейса определяется тем, что часто этот интерфейс отделяет потребителя коммуникационных услуг от их поставщика, т.е. оператора базовой сети. Оператор базовой сети имеет полный контроль над протоколами предшествующими транспортному уровню. Именно по этой причине интерфейс должен прорабатываться особенно тщательно. Сервисы сетевого уровня любой коммуникационной системы должны обладать следующими основными характеристиками: сервисы не зависят от канальной технологии базовой сети. транспортный уровень должен быть экранирован от количества, типов и топологий различных базовых сетей. если сетевые адреса являются доступными для транспортного уровня, то они должны укладываться в пределы стандартной схемы адресации, в которой каждый адрес уникален. Рассмотрим вкратце функционирование протокола IP, и проанализируем его с точки зрения среды исполнения транспортного протокола. Получая данные от вышележащего уровня в виде блоков конечного размера, протокол IP инкапсулирует их в пакет, добавляя к данным пользователя свой заголовок. На рис. 7. приведены поля заголовка протокола IPv6. Для нас представляет интерес то, что в заголовке отсутствует поле кода циркулярного контроля. Это связано с тем, что задача проверки и коррекции ошибок передачи возложена на канальный уровень, который всегда выполняет эту проверку. Протокол IPv4 осуществлял проверку целостности данных при помощи кода контроля четности, но из функциональности IPv6 данная операция была изъята, поскольку она дублирует аналогичную или более мощную систему канального уровня.

Рис. 7. Формат заголовка пакета протокола IP (изображен для IP версии 6).

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

1.7.6.2.2. Возникновение и коррекция ошибок Низкое соотношение энергии сигнала к энергии шума на линии приводит к искажениям принимаемого сигнала и как следствие к высокой вероятности битовых ошибок на приемнике. Ошибки канала передачи данных проявляются как:

1. Вставленные данные: данные, полученные приемником, но никогда не передававшиеся отправителем. 2. Потерянные данные: данные отправленные, но не дошедшие до получателя (исчезнувшие на физическом уровне). 3. Дублированные данные: данные, переданные единожды и полученные в нескольких экземплярах 4. Искаженные данные: данные, поврежденные в транзите 5. Разупорядоченные данные: данные, последовательность получения которых не совпадает с последовательностью передачи Применяемые на канальном уровне алгоритмы распознавания и коррекции ошибок с достаточной вероятностью позволяют отобразить ошибки типа вставленных и искаженных данных на оставшиеся три типа ошибок, а именно потеря, дублирование и разупорядочивание данных. Сетевой уровень стека TCP/IP предоставляет пользователю ненадежный сервис без установки логического соединения. Сказанное означает, что IP пакеты могут начать поступать в сеть без задержки, как только информация готова к отправке (пакет сформирован). Отправленные пакеты не подтверждаются получателем. Пакет может быть потерян, и никогда не дойти до получателя, по нескольким причинам: он может быть отброшен из переполненного буфера маршрутизатора вследствие перегрузки последнего, либо данные в составе пакета могут быть разрушены в процессе передачи по ненадежному каналу. Таким образом, сетевой уровень может привнести дополнительные ошибки типа потерь данных. Также вследствие возможности наличия нескольких маршрутов к получателю порядок прибытия пакетов может не совпадать с порядком их отправки, если поток пакетов будут доставляться по маршрутам с различной задержкой. Более того, существует возможность доставки получателю нескольких копий одного пакета. Протокол TCP, таким образом, должен самостоятельно отслеживать возникновение трех типов ошибок данных и осуществлять самостоятельное восстановление в ситуациях, когда сегмент не приходит вообще, когда сегменты доставляются сетью не в том порядке, в котором были отправлены и когда сеть доставляет несколько копий одного сегмента.

1.7.6.2.3. Управление потоком Каждый из нижележащих уровней осуществляет управление скоростью передачи данных. Физический уровень ответственен за синхронизацию записи и сканирования среды передачи. Канальный уровень управляет скоростью передачи пакетов между двумя узлами, применяя схему управления потоком той или иной сложности, в зависимости от назначения – Xon/Xoff, Alternating bit [42], sliding window [43] и т.п. Сетевой уровень также имеет примитивную схему управления потоком. Маршрутизатор в состоянии перегрузки может отправить своим топологическим соседям сообщение о наличии перегрузки при помощи протокола ICMP. Однако все алгоритмы канального и сетевого уровней осуществляют управление скоростью потока лишь локально. TCP, как протокол транспортного уровня, осуществляет управление потоком по всей длине логического канала между передающей и принимающей системами. В протоколе TCP существует механизм, ограничивающий скорость отправки сегментов в сеть, для того чтобы избежать переполнения буферов промежуточных маршрутизаторов и буфера приемника. 1.7.6.3. Процедурные правила Сервис транспортного уровня реализуется транспортным протоколом между двумя объектами транспортного уровня. Процедурные правила, требуемые для реализации этого сервиса слишком громоздки, поэтому их формальное описание например в виде конечных автоматов было бы слишком громоздким. Далее мы дадим описание процедурных правил TCP в виде отдельных алгоритмов. Отдельными важными аспектами транспортного протокола, которые должны быть учтены в его процедурных правилах являются: Адресация и мультиплексирование Инициализация и закрытие связи Буферизация и управление потоком 1.7.6.4. Словарь транспортного протокола Словарь простейшего транспортного протокола, обеспечивающего надежный канал связи и контроль скорости передачи, должен позволять передавать следующие типы сообщений [1, 3]: Данные (DATA) Подтверждения (ACK) Размер приемного окна (WND) Таким образом, минимальный словарь транспортного протокола обеспечивающего надежную связь таков: V={DATA, ACK, WND}. Если рассматривать каждое направление полнодуплексного транспортного соединения раздельно, то данные противоположном направлении. Поскольку каждое индивидуальное передаются в направлении от отправителя к получателю, а подтверждения и обновления окна в сообщение транспортного протокола инкапсулируется сетевым уровнем в отдельный пакет, то выгодно объединить как можно больше сообщений в каждом TPDU. Реально в каждом сообщении объединяются все эти типы. Формат сообщений транспортного протокола таков: {DATA, SEQ} {ACK, SEQ, WND}, где SEQ и WND – целые числа. Поскольку транспортные соединения рассчитаны на двусторонний обмен сообщениями, то объединяются все поля в едином формате сообщения: {DATA, SEQ, ACK, SEQ, WND} Число SEQ на второй позиции нумерует передаваемые данные, а в третьей позиции – подтверждаемые данные. 1.7.6.5. Кодировка сообщений на транспортном уровне Итак, словарь транспортных протоколов состоит из сообщений – так называемых TPDU, которые инкапсулируют передаваемые данные. Сам TPDU в свою очередь заключен в пакет сетевого уровня. Формат сегмента, как правило, следующий: заголовок фиксированной длины выровненный на 32 битной границе предшествует полю данных переменной длины. Более конкретная схема кодировки сегмента и детализация дополнительных полей приведена в схеме заголовка TCP сегмента (рис. 8.).

Рис. 8. Формат заголовка сегмента TCP.

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

1.7.6.6. Адресация Для установки связи с удаленным приложением требуется указать его адрес. Адресация необходима для всех видов сетей. Существует метод, позволяющий устанавливать транспортный адрес, по которому приложение-сервер ожидает прибытия запроса на соединение. Для архитектуры TCP/IP это пара: IP адреса и номер локального порта. Объекты транспортного уровня допускают использование нескольких транспортных адресов (рис. 9), при этом мультиплексирование потоков в пределах узла осуществляется самим транспортным протоколом. Постоянно существующие серверные приложения адресуются напрямую, для работы с приложениями, запускаемыми лишь на время существования сессии, используется так называемый «протокол первоначального соединения» или интернет сервер (UNIX inetd) [75].

Рис. 9. Точки доступа к сервису транспортного уровня (ТДТС). Изображены интерфейсы транспортного уровня с уровнем приложения и сетевым уровнем.

1.7.6.7. Установка соединения Без способности БС к накоплению пакетов задача установления соединений свелась бы к двум действиям – послать запрос на соединение – дождаться положительного ответа на него. На самом же деле проблема значительно более сложна. Если БС перегружена, и подтверждения не успевают прибыть к отправителю вовремя, то и запросы на установление соединения могут быть отправлены несколько раз. Поскольку маршрутизация каждого пакета происходит независимо, то существует вероятность задержки некоторых пакетов в течение более длительного времени, чем других и, соответственно, сбоев при установлении соединения. Единичная транзакция может, таким образом, случайно произойти два и более раза. Используемый в архитектуре TCP/IP метод сочетает с идентификацию каждого пакета с требованием ограничения времени жизни пакетов в сети. Причем идентификация каждого пакета подразумевает наличие у него порядкового номера. В реальности необходимо гарантировать, что не только сам пакет исчез из сети, но и все его подтверждения, поэтому используется промежуток времени Т, кратный максимальному времени жизни пакета. Если прошло время Т с момента отправки пакета, то мы можем быть уверены, что ни сам пакет, ни его подтверждения не существуют на сети. Если опираться на такую предпосылку, то можно разработать надежный способ безопасной установки соединения. Метод был впервые предложен [37] в 1975 и усовершенствован [38] в 1978. Метод называется «трехсторонний обмен» (Three-way handshake). Этот метод не требует использования обеими сторонами одних и тех же номеров. Нормальная процедура установки соединения иллюстрирована на рис. 10 (часть А.) Устройство А посылает запрос на соединение (CR) устройству В, указывая при этом начальный порядковый номер который будет использоваться транспортным протоколом устройства А для передачи данных. Устройство В, получив запрос, реагирует отправкой пакета, уведомляющего о согласии установить соединение, указывает свой собственный начальный номер у и подтверждает номер x. После этого в первом пакете с данными, который имеет номер х, машина А подтверждает прием сообщения с номером у. Варианты В. и С. иллюстрируют поведение транспортных объектов при получении дубликата запроса на соединение и дубликата подтверждения.

Рис. 10. Установка соединения по методу тройного обмена. Часть А. - нормальная установка соединения. В. - реакция на дубликат запроса. С. - реакция на дубликат запроса и данных.

Схема установки соединения приведенная выше применяется транспортным протоколом TCP. Альтернативная схема надежной установки соединения в условиях наличия задержанных копий сообщений описана [39]. 1.7.6.8. Разрыв соединения Для закрытия транспортного и закрывается по отдельности. Рис. 11 иллюстрирует процесс закрытия соединения с использованием таймеров. Несмотря на относительную надежность такого протокола, он может не сработать в случае потери начального DR и всех N повторных передач. В этом случае инициирующая сторона закроет соединение, противоположная же не получив информации о закрытии будет активной. Такое состояние называется полуоткрытое соединение. Для предотвращения возникновения таких состояний вводится правило, по которому соединение будет автоматически закрываться, если в течение определенного времени на нем не зарегистрировано никакой активности.

соединения используется так называемый симметричный разрыв, при котором каждое направление соединения считается независимым Рис. 11. Сценарии разрыва соединения с использованием подтверждений и таймеров. Часть А. - сценарий без ошибочных ситуаций. В, С и D - различные сценарии возникновения ошибок. Потерянный сегмент изображается звездочкой. Если же соединение должно оставаться открытым в течение длительного времени, ожидая появления данных для передачи, то сторонам придется периодически обмениваться пустыми сообщениями, удерживающими противоположную сторону от закрытия. 1.7.6.9. Управление потоком и буферизация данных Управление потоком непосредственно связано с буферизацией. Задачей процесса управления потоком является не допустить переполнения получателя и промежуточных узлов информацией, которую те не успевали бы обрабатывать. В том случае, если БС предоставляет ненадежный датаграммный сервис, то отправитель должен буферизовывать отправленные сообщения на случай возникновения необходимости повторной отправки. Получатель, зная, что сообщения остаются в памяти отправителя пока не поступит подтверждение их приема, может выделять или не выделять буферное пространство для каждого соединения. В случае буферизации сообщений у получателя, что позволяет существенно повысить производительность системы, возникает вопрос о схеме выделения памяти под буферы. Это может быть и система буферов равных размеров (если все сообщения примерно одного размера) или большой циркулярный буфер или набор буферов разных размеров. Оптимальное решение относительно буферизации у отправителя и получателя зависит от характеристик потока. Например, для трафика порожденного интерактивной работой с удаленным терминалом, характеризуемого небольшой скоростью, лучше вообще не выделять буферов, а получать и передавать информацию приложениям по мере ее поступления (естественно, что переданное сообщение должно оставаться в памяти отправителя до получения подтверждения). С другой стороны для потока созданного не интерактивной передачей данных, например – загрузкой удаленного файла, эффективность может быть существенно повышена, если получатель выделит максимальное количество буферного пространства, чтобы как можно более повысить скорость передачи. Таким образом, с течением времени отправитель и получатель должны согласовывать свои схемы выделения буферного пространства. Отправитель должен иметь возможность запрашивать получателя о выделении определенного количества буферного пространства или же получатель (не имеющий информации о потребностях отправителя) должен сообщать, что для соединения зарезервировано Х буферов. Выделение буферов должно происходить независимо от прихода подтверждений (в отличие от большинства протоколов канального уровня). Эта схема подразумевает наличие «окна» переменного размера. Получатель выделяет такое количество буферного пространства в ответ на запрос отправителя, какое позволяют его ресурсы. Каждый раз, посылая сообщение, отправитель должен уменьшить указанное количество и временно прекратить передачу, если размер свободного буферного пространства у получателя уменьшится до нуля. Получатель, в свою очередь должен указывать текущий размер окна и номер подтверждения в потоке идущем в обратном направлении. При увеличении количества памяти доступной для буферизации сетевых соединений уже не недостаток свободного буферного пространства будет ограничивать максимальную скорость передачи данных, а доступная пропускная способность БС. Таким образом, необходим механизм управления потоком, который учитывает также и несущую способность БС, а не только количество буферного пространства у конечных участников обмена. Если используется механизм ограничивающего окна, то его размер должен отражать текущую пропускную способность БС. 1.7.7. Протокол TCP Семейство протоколов TCP/IP включает в себя два протокола транспортного уровня это TCP – Transmission Control Protocol - и UDP User Datagram Protocol. UDP достаточно прост, по существу это небольшое дополнение к IP, и не использует виртуальный канал. TCP это надежный протокол, который использует предварительную установку виртуального канала и доставляет данные пользователя без ошибок. ТСР был специально разработан, чтобы обеспечивать надежную передачу байтового потока от отправителя к получателю через ненадежную БС. БС может состоять из различных сетевых компонентов, обладающих разными топологическими схемами, технологиями, пропускной способностью, задержками. Формально протокол ТСР был определен в RFC 793 [4]. Со временем накопившиеся ошибки и недостатки были учтены и нашли выражение в требованиях к устройствам интернет в RFC 1122 [5]. В дальнейшем было проведено большое количество исследований с протоколом. Часть модификаций стала стандартом и новые спецификации протокола содержится в RFC 1323 [6]. Каждое устройство, поддерживающее ТСР, содержит в себе объект протокола, который управляет ТСР потоками и взаимодействует с уровнем IP. Этот объект принимает потоки данных от локальных процессов, разбивает их на сообщения определенной длины (сегменты) и передает сегмент на уровень IP для его передачи в виде отдельного IP пакета. По прибытии на адресуемую машину информация из этих пакетов передается ТСР объекту, который реконструирует оригинальный байтовый поток и передает ее пользовательской программе. Уровень IP не гарантирует доставку пакетов, поэтому ТСР должен отслеживать потерянные пакеты и осуществлять повторную отправку. Пакеты могут прибывать и в порядке, отличающемся от порядка, в котором они были отправлены, поэтому задачей ТСР также является реконструкция порядка в битовом потоке. Для управления потоком и предотвращения перегрузок БС ТСР применяет механизм скользящего окна [43]. 1.7.7.1. Модель обслуживания ТСР Доступ к сервису ТСР можно получить путем создания на конечных машинах точек доступа (Sockets). Каждая такая точка имеет адрес, состоящий из IP адреса машины и 16-ти битного номера, уникального в пределах устройства, идентифицирующего порт. ТСР соединение устанавливается между двумя точками доступа и пара транспортных адресов однозначно идентифицирует соединение. Несколько соединений могут оканчиваться на одной точке доступа. Порты с номерами ниже 256 однозначно соответствуют набору конкретных приложений. Порты с другими номерами выделяются приложениям динамически. Все ТСР соединения полнодуплексные и имеют тип точка-точка. Соединение представляет собой неструктурированный байтовый поток, т.е. границы между сообщениями не сохраняются. Когда приложение передает данные ТСР, протокол может либо сразу осуществить их отправку, либо накопить достаточное их количество в буфере. Если же приложению необходимо послать информацию мгновенно, то оно может использовать флаг PUSH. Кроме того, существует возможность пересылать срочную информацию с использованием флага URGENT. Когда приложение устанавливает этот флаг, то ТСР передает все имеющиеся данные без промедления, кроме того, ТСР получателя генерирует прерывание для приложения которому предназначается срочная информация и указывает на положение ее в полученном потоке. Каждый байт ТСР соединения имеет уникальный 32-х битный порядковый номер. Эти номера используются не только для подтверждений, но и для механизма управления окном. Объекты ТСР обмениваются информацией в виде сегментов. Сегмент состоит из 20-ти байтного заголовка (+ необязательная часть) и нуля или более байтов данных (рис. 8). Протокол сам принимает решение относительно размера сегмента. Существуют два ограничения размера сегмента. Первое: сегмент должен умещаться в пределах максимального размера поля полезной нагрузки IP – байт. Второе: каждая сетевая технология имеет так называемую максимальную единицу передачи (Maximum Transfer Unit - MTU) в которую и должен уместиться полный IP пакет, включающий в себя IP и ТСР заголовки и данные. Одновременно с передачей сегмента запускается таймер повторной передачи. Когда сегмент прибывает к получателю, ТСР объект последнего отправляет сегмент, содержащий подтверждение приема этого сегмента. Если таймер повторной передачи для сегмента срабатывает раньше времени прихода подтверждения, то данный сегмент ретранслируется. 1.7.7.3. Формат заголовка ТСР Заголовок сегмента ТСР содержит следующие поля (рис. 8): Порядковый номер идентифицирует первый байт данных в этом пакете, может также использоваться для указания первого номера в серии который будет использоваться в последующих передачах. Номер подтверждения - содержит порядковый номер следующего байта данных, который ожидается на принимающем устройстве. Флаги - разнообразная контрольная информация: URG – срочные данные, указатель на срочные данные в этом случае указывает на их положение в сегменте ACK – 1 значит, что поле подтверждения содержит правильную информацию PSH – получатель должен доставить данные приложению как можно скорее RST – соединение должно быть закрыто SYN – используется для установки соединения, запрос на установку содержит SYN=1, ACK=0, ответ на этот сегмент содержит SYN=1, ACK=1. FIN – отправитель сигнализирует о желании закрыть соединение. После отправки FIN машина может еще неограниченно долго продолжать получать информацию. SYN и FIN сегменты имеют порядковые номера, что гарантирует их обработку в правильном порядке. Размер окна сообщает о том, как много байтов можно отправить, начиная с последнего подтвержденного байта. Этот размер может быть равен нулю. 1.7.7.4. Управление соединением Установка соединения в ТСР использует процедуру трехстороннего обмена. Для открытия соединения пассивная сторона исполняет примитивы LISTEN и ACCEPT, а другая открывает соединение в активном режиме, исполняя примитив CONNECT. Когда запрос на открытие соединения, прибывает к получателю, тот проверяет, есть ли процесс зарегистрированный для приема соединений по указанному порту. Если такой процесс существует, то соединение устанавливается (рис. 12 часть A).

Рис. 12. Сценарии установки соединения TCP. Часть А.- нормальная процедура, часть В.- установка соединения при столкновении запросов.

Хотя ТСР соединения полнодуплексные, закрываются соединения в каждом направлении по отдельности. В нормальной ситуации требуется четыре сегмента, чтобы полностью закрыть соединение (два FIN и два ACK). По каждому из симплексных соединений данные могут передаваться неограниченно долго. Для предотвращения появления полуоткрытых соединений используются несколько таймеров. Если ответ не сегмент FIN не приходит в течение двух максимальных периодов жизни пакета, отправитель сегмента FIN разрывает соединение. 1.7.7.5. Управление передачей Управление окном в ТСР не привязано напрямую к подтверждениям (как во многих протокола канального уровня). Упрощенный вариант схемы управления передачей приведен в примере на рис. 13.

отправитель получатель Буфер Приложение выполняет запись 2К empty 2К;

SEQ = ACK=2048;

Приложение выполняет запись 3К 2К 2К;

SEQ = 2048 4K ACK=4096;

WIN= Отправитель блокирован ACK=4096;

WIN=2048 Можно послать еще 2К Приложение выполняет чтение 2К 2К 1К;

SEQ = 2К Рис. 13. Управление передачей данных и окном в TCP. Ось времени - сверху вниз. Закрашенный элемент буфера означает заполненный. Слева размещены комментарии.

Подтверждения, используемые протоколом TCP, являются кумулятивными, т.е. каждое подтверждение соответствует последнему полученному в правильном порядке байту потока. Приход подтверждения с номером N означает, что все байты [0…N-1] были успешно доставлены получателю. 1.7.7.6. Управление окном и тактика подтверждений На ранних стадиях эксплуатации протокола было замечено, что часто в сетях возникали перегрузки при очень низком эффективном использовании ресурсов [8]. Были выявлены три независимые причины этого: приложение вызывающие протокол для отправки незначительного количества информации, обновление окна ТСР очень маленькими порциями и вызывающие ответные сегменты с малой полезной нагрузкой, и сам протокол посылающий слишком много подтверждений. Было предложено использовать так называемый алгоритм SWS [5] для решения проблемы с обновлением окна. А. Алгоритм SWS у получателя, совмещен с задержкой подтверждения предписывает: обновление окна вместе с подтверждением отправляется только если освободившийся объем буфера превосходит определенную долю общего буферного пространства (30-50%) или 2-3 максимальных размера сегмента. Б. Алгоритм SWS у отправителя предписывает: отправитель пытается приблизительно оценить размер буфера получателя, отслеживая максимальный размер окна открываемого получателем на данном соединении. max(SND.WND5). Используемое окно, данные в пределах которого могут быть отправлены, вычисляется U=SND.UNA6 + SND.WND – SND.NXT7. Если D количество данных буферизованных протоколом, но еще не отправленных, то ТСР отправляет данные если: Есть возможность послать сегмент максимального размера min(D,U) >= Eff.snd.MSS8 установлен флаг PUSH и [SND.NXT = SND.UNA] && PUSHED && D <= U [SND.NXT = SND.UNA] условие налагаемое алгоритмом Nagle. [8]. как минимум доля Fs от максимального окна может быть отправлена [SND.NXT = SND.UNA] && min(D, U) >= Fs * Max(SND.WND) установлен флаг PUSH и сработал таймер В. Алгоритм Nagle: эффективен когда приложение передает малые объемы информации. Согласно этому алгоритму, если есть неподтвержденные данные (SND.NXT > SND.UNA), то ТСР отправителя буферизует данные без отправки, несмотря на наличие флага PUSH, до момента, когда либо приходит подтверждение, либо становится возможным отправить сегмент максимального размера. Существует также таймер, предотвращающий ситуацию взаимной блокировки.

SND.WND переменная в контрольном блоке каждого соединения. SND.WND указывает на «правую» границу окна в потоке данных. SND.UNA – переменная указывающая на последний неподтвержденный байт. SND.NXT – переменная содержащая указатель на следующий готовый к отправке байт данных. Eff.SND.MSS – реальный размер сегмента ТСР. Г. Алгоритм задержки подтверждений требует: Подтверждение должно задерживаться не менее чем на 0.5 с. Подтверждения задерживаются до тех пор, пока не возникнет возможность указать новое окно или данные отправляются Также в противоположном буферизованные направлении. у получателя Таймер генерирует в безусловное неправильной подтверждение каждые 200 мс. Кроме того, каждый второй сегмент должен подтверждаться. сегменты, (прибывшие последовательности) генерируют подтверждение мгновенно для включения механизма быстрой ретрансляции. 1.7.7.7. Управление потоком и предотвращение перегрузок Если суммарная скорость поступления данных в на сеть превышает максимальную скорость, с которой сеть передает эти данные, то возникает перегрузка сети. Если состояние перегрузки длится в течении времени, достаточного для переполнения буферов в сети, то происходят потери данных в сети. Потерянные сегменты ретранслируются протоколом TCP и способствуют продолжению протокола роста перегрузки. Алгоритм управления потоком и транспортного должен предотвращать возникновение перегрузки способствовать выходу сети из состояний перегрузки, в случае его возникновения. Перегрузка сети может быть предотвращена с помощью использования принципа сохранения пакетов9 [2] – если сеть загружена полностью, то не передавать следующий пакет раньше, чем предыдущий покинет сеть (т.е. будет доставлен по назначению). ТСР стремится следовать этому принципу, изменяя размер окна. Схема определения наступления состояния перегрузки в TCP основывается на предположении, что причина всех потерь пакетов заключается в переполнении очередей маршрутизаторов, т.е. перегрузке сети. Таким образом, алгоритм управления потоком в ТСР считает потери связанные с разрушением данных из-за шума на линии несущественными и реагирует на все потери как на признак перегрузки. Такой механизм является неэффективным, особенно в случае беспроводных соединений, таких как радио спутниковые каналы, ИК приемопередатчики. ТСР оперирует двумя окнами, одно определяет размер буфера отправителя, другое (CWND) является результатом попыток протокола определить пропускную способность сети на данном соединении. Для отправки данных используется минимальное из двух окон. и Принцип сохранения здесь применим к равновесному состоянию системы, когда в транзите находится количество данных равное полномстью открытому окну. В таком случе, в любой момент времени интеграл по плотности пакетов по закрытой петле ВК является константой. Механизмы Slow start, congestion avoidance, fast retransmit, fast recovery [6] являются стандартом для современных реализаций ТСР. Slow start (замедленный запуск) применяется для постепенного увеличения скорости передачи информации после открытия соединения или потери пакета. Изначально размер окна CWND устанавливается равным одному сегменту. После получения каждого подтверждения CWND увеличивается на размер одного сегмента. Алгоритм медленного запуска отключается когда происходит потеря сегмента или достигается верхняя граница окна получателя. Время, затрачиваемое для полного открытия окна t = RTT log 2W где W – размер окна в сегментах.

(1) Congestion avoidance (предотвращение перегрузки) используется для определения наличия дополнительной пропускной способности. Обычно этот алгоритм действует совместно с алгоритмом медленного старта. Для фиксации момента перехода с медленного старта на предотвращение перегрузки используют переменную SSTHRESH. SSTHRESH инициализируется размером максимально возможного окна при открытии нового соединения. Медленный старт продолжается пока значение CWND не достигнет SSTHRESH, после этого режим роста CWND изменяется на линейный, а именно, для каждого подтверждения CWND увеличивается на значение (1/ CWND). Fast Retransmit (быстрая ретрансляция). Использует последовательное получение подтверждения одного и того же сегмента, как признак потери, ретранслирует этот сегмент до срабатывания таймера ретрансляции. Fast recovery (быстрое восстановление). После срабатывания механизма быстрой ретрансляции ТСР переходит в режим предотвращения перегрузки, а не медленного старта. После прихода третьего дубликата подтверждения SSTHRESH устанавливается равной CWND, и отсутствующий сегмент ретранслируется, CWND устанавливается равным SSTHRESH+3 (количество сегментов покинувших сеть). Затем на каждое подтверждение CWND увеличивается на размер одного сегмента. Если размер CWND позволяет, передаются дополнительные сегменты. Когда приходит подтверждение, включающее в себя ретранслированный сегмент, CWND устанавливается равным SSTHRESH и ТСР переходит в режим предотвращения перегрузки. Описанные выше механизмы являются стандартной частью протокола TCP, их применение регламентируется RFC 1323 [6].

1.7.7.8. Управление таймерами Объекты ТСР концептуально используют несколько таймеров для выполнения своих функций. Наиболее важным из них является таймер повторной передачи (ТПП). ТПП перезапускается каждый раз при отправке сегмента. Если подтверждение приема сегмента не приходит до срабатывания таймера, то этот сегмент ретранслируется. Определение суммарного времени затрачиваемого сегментом на достижение получателя и времени затрачиваемого подтверждением, чтобы вернуться к отправителю (RTT) само по себе достаточно сложно в реализации, еще сложнее даже зная это время правильно установить интервал таймера. Если ТПП установлен на слишком короткий интервал, то повторная передача произойдет еще до того как может прибыть подтверждение и это еще больше увеличит степень загрузки БС. Если же таймер установлен со слишком длительную задержку, то некоторую часть времени канал будет использоваться неэффективно. Кроме того, среднее значение измеряемого RTT и его дисперсии крайне динамично меняется с течением времени в зависимости от степени загрузки БС. В протоколе TCP используется высоко динамичный алгоритм, который непрерывно корректирует значение ТПП, отслеживая время обращения сегментов в сети. Этот алгоритм функционирует следующим образом [2]: для каждого соединения ТСР сохраняет значение наилучшей текущей оценки времени обращения сегментов в переменной RTT. При отправке сегмента устанавливается таймер для контроля повторного отправления и для измерения RTT. Если подтверждение прибывает до срабатывания таймера, то, измеряя время которое прошло до прихода подтверждения (М), ТСР обновляет среднее значение RTT по формуле:

RTT = RTT + (1 ) M где значением 7/8).

(2) весовой коэффициент применимый к старому значению (с типичным Для того, чтобы значение RTT не искажалось из-за учета ретранслированных сегментов, Карном [7] был предложен алгоритм, который добавил к ТСР следующее правило: не обновлять значение RTT по данным, относящимся к ретранслированным сегментам, вместо этого значение ТПП удваивается с каждой ретрансляцией. Этот принцип получил название “Exponential Backoff”.

1.8 Свойство самоподобия сетевого трафика 1.8.1. Традиционная методология: системы массового обслуживания Традиционной методологией применяемой для изучения процессов происходящих в территориально распределенных сетях с большим количеством пользователей до недавнего времени являлась теория массового обслуживания [9]. Применение теории массового обслуживания к исследованию процессов, происходящих в сетях передачи данных, основывается на предположении о том, что моменты поступления требований в систему (моменты прихода пакетов в маршрутизатор) образуют пуассоновский поток с интенсивностью. Если распределение длительностей времени обслуживания также является пуассоновским, то применение методологии системы массового обслуживания М/М/1 позволяет определить среднее число требований в системе и с помощью теоремы Литтла связать это число со средней задержкой в системе в равновесном состоянии. Анализ систем массового обслуживания предполагает, что процесс, считающий число требований находящихся в системе является марковским процессом с непрерывным или дискретным временем, исследование которого и дает среднее число требований в системе в стационарном режиме. Таким образом, получают формулы для среднего числа требований и среднего времени пребывания требований в системе. N= T= µ 1 µ, где µ - скорость обслуживающего прибора.

(33) (34) Если же предполагается произвольное распределение длительностей обслуживания требований, то такая система массового обслуживания обозначается M/G/1 и среднее время пребывания требования в обслуживающем приборе выражается формулой ПоллачекаХинчина:

W= X 2(1 ), где W – математическое ожидание времени пребывания требования в очереди, = µ = X, если X i - длительность обслуживания i-го требования, а X = E ( X 2 ) момент второго порядка распределения длительностей обслуживания. (35) T=X+ X 2(1 ) (36) Для сетей с коммутацией пакетов вообще и сетей передачи данных в частности долгое время применялись методы, основывающиеся на предположении о том, моментов прибытия пакетов или инициализации соединений имеют ограниченную дисперсию, поскольку аналитическая модель для таких систем хорошо известна [88, 9]. На основании этой модели рассчитывались основные характеристики сети, и производилось планирование ее ресурсов, в частности, объема буферного пространства. 1.8.2. Критика традиционных моделей трафика С развитием сети Интернет и появлением возможности исследования большого количества экспериментального материала по трафику начали появляться свидетельства в пользу того, что трафик в сетях с коммутацией пакетов с большей точностью моделируется статистически самоподобными процессами [95] или, по крайней мере, не имеет экспоненциального распределения [90, 91]. Для самоподобного процесса представляющего пакетный трафик не существует естественного ограничения длительности всплеска. Всплески могут происходить в любом временном масштабе. Кроме того, множество типов обменов в современной сети инициируются и управляются операционной системой сетевых узлов автоматически, например обновления маршрутной информации, трафик протоколов SMTP, NNTP, что может приводить в глобальной синхронизации потоков в сети [92]. Такая ситуация является невозможной для пуассоновской модели, однако имеет место в реальности. Итак, традиционный подход к моделированию трафика сети с коммутацией пакетов базируется полностью на предположении о неограниченности дисперсии процесса поступления пакетов, что позволяет применять теоретический аппарат марковских цепей для анализа таких систем. Однако развитие современных скоростных сетей передачи данных и мультимедиа информации с выраженной гетерогенной физической и логической инфраструктурой и большим набором разнообразных сервисов и генерируемых ими потоков, приводит к появлению существенно более сложных характеристик потоков. Трафик в таких сетях имеет явно выраженный всплесковый характер, не сглаживаемый усреднением по длительным временным промежуткам и большому числу потоков. Традиционный подход к моделированию трафика изменялся путем разработки все более сложных стохастических моделей: fluid flow models, Markov modulated Poisson processes, Markovian arrival processes, Batched Markovian arival processes, и т.д. Основной целью разработки всех этих моделей являлось сохранение возможности аналитического подхода к исследованию задач управления очередями и эффективностью системы. Однако, авторы обзора [93] отмечают, что статистические свойства стохастических моделей не совпадают со свойствами экспериментальных данных по сетевому трафику. Причиной того, что стохастический анализ применялся в течении длительного времени, был недостаток эмпирических данных. Сейчас в экспериментальных данных и модельных экспериментах нет недостатка - получено большое количество наборов данных по трафику в территориально распределенных сетях, в ЛВС, для различных технологий канального уровня и для разнообразных протоколов прикладного уровня, для TCP/IP и ATM сетей. В связи с этим, усилия ученых сейчас направлены на разработку новых способов анализа коммуникационных систем. 1.8.3. Исследования экспериментальных данных Исследования большого объема данных по трафику с высоким разрешением по времени было проведено в целом ряде работ, перечисленных в [93]. Эти работы показали, что трафик реальных сетей с коммутацией пакетов обладает характеристиками самоподобия или мультифрактальности. Более того, в цитируемых работах показывается существенное отличие статистических характеристик трафика генерируемого традиционными стохастическими моделями и эмпирическими данными. Подробный библиографический обзор на тему самоподобия и фрактальных свойств процессов в телекоммуникационных сетях, а также моделирования современных высокоскоростных сетей представлен в работе [93] и включает в себя аннотации 420 работ. Большое число работ, упоминаемых в [93] посвящено нахождению физического или феноменологического объяснения фрактальной природы эмпирически изучаемого трафика. В этих исследованиях приводится связь фрактальной природы наблюдаемого трафика с синдромом бесконечной дисперсии или так называемыми распределениями с тяжелыми хвостами. На настоящий момент, согласно авторам работы [93], не существует аналитического аппарата применимого процессам, характеризующимся свойством самоподобия. Для того чтобы определить наличие характеристик самоподобия у больших последовательностей статистических результатов R/S измерения трафика применяются несколько метод методов: статистика, дисперсионно-временной анализ, спектральных областей и другие [94]. 1.8.4. Определения моно- и мультифрактальных процессов В работе [95] даются принятые на сегодня определения и признаки самоподобных (монофрактальных) и мультифрактальных процессов следующим образом:

Определение:

процесс с непрерывным временем Y = {Y (t ), t T } является самоподобным (с параметром самоподобия H), если удовлетворяет условию: Y (t ) d= a H Y ( at ), t T, a > 0,0 H < 1 (37) (равенство в том смысле, что два процесса имеют одинаковые распределения). Коэффициент H, называется коэффициентом или параметром Хёрста и является мерой самоподобия. Существуют также несколько признаков самоподобия. Признак 1. Дана стационарная последовательность X = { X (i ), i 1}, пусть X ( m ) (k ) = km 1 ) mX1(i ), k = 1, 2, …, m i = ( k 1 + (38) является соответствующей X агрегированной последовательностью с уровнем агрегирования m. Последовательность X ( m ) ( k ) получена путем разбиения исходной последовательности X на непересекающиеся блоки размера m и усреднением по каждому блоку. Индекс k нумерует блоки. Если X является процессом приращения самоподобного процесса Y определенного в (37), т.е. X(i)=Y(i+1)-Y(i), то для всех целочисленных m: X d= m1 H X ( m ) (39) Стационарная последовательность X = { X i, i 1} является самоподобной в точности, если она удовлетворяет выражению (38) для всех уровней агрегирования m. Также стационарная последовательность X = { X i, i 1} считается асимптотически самоподобной, если условие (39) выполняется при m. Еще один признак самоподобия [95] дается через поведение абсолютных моментов. Признак 2. Если определить:

q µ (m) ( q) = E | X (m) q 1m | = E X (i ) m i = (40) Если X обладает свойством самоподобия, то µ ( m ) ( q) пропорционален m (q ), т.е. log[µ ( m ) ( q)] линеен относительно log[m] для фиксированных значений q: log[µ ( m ) ( q)] = ( q) log[m] + C ( q ) (41) также (q) линейна по отношению к q, действительно, поскольку X ( m ) (i ) d= m H 1 X (i ), то (q) = q( H 1) (42) таким образом, второй признак самоподобия в том, что моменты должны масштабироваться согласно (41) и (q) удовлетворять условию (42). Стационарная последовательность не может быть точно или асимптотически самоподобной, если ее среднее значение отлично от нуля. Признак 3. самоподобия процессов. может быть обобщен для так X(t) называемых является мультифрактальных Неотрицательный процесс мультифрактальным, если логарифмы абсолютных моментов масштабируются линейно с логарифмом значения уровня агрегирования m. В отличие от самоподобного процесса здесь не налагается требований на линейность (q) относительно q. Самоподобные процессы, таким образом, являются частным случаем мультифрактальных. 1.8.5. Причина свойств самоподобия Интернет трафика Причиной наличия свойства самоподобия, как показано в работах [98, 97], является распределение ON периодов имеющее тяжелый хвост (убывающий гиперболически). Авторы [97] предлагают разделять объяснения причин самоподобия трафик в больших и малых временных диапазонах. Так самоподобие LAN и WAN трафика в масштабах порядка секунды и более объясняется и математически доказывается в [98]. Однако для полного понимания динамики сетевого трафика необходимо исследовать причины мультифрактальных характеристик трафика в масштабах менее одной секунды, в котором поведение трафика особенно динамично. В этих масштабах локальное поведение каждого из составляющих трафик потоков определяется используемым данным протоколом алгоритмом управления потоком. В общем же поведение суммарного трафика определяется взаимодействием нескольких реализаций одного или нескольких протоколов в совокупности с взаимодействием потоков в обслуживающем приборе. 1.8.5.1. Трафик с малым разрешением по времени Предположим, что каждое индивидуальное соединение i отправляет пакеты с постоянной скоростью в период ON и не отправляет пакетов вообще в период OFF. Такое поведение ЛВС было показано в [100] как обмены типа "запрос-ответ". С другой стороны для территориально распределенных сетей, например Интернет, индивидуальные соединения ассоциируются с сессиями, устанавливаемые транспортным протоколом типа TCP. Каждая такая сессия инициализируется в некоторый случайный момент времени, осуществляет передачу в течение некоторого времени с постоянной скоростью, а затем отключается. Каждая сессия обслуживает то или иное приложение, реализующее свой протокол прикладного уровня, например FTP[DATA], TELNET, NNTP, SMTP, HTTP. Для периодов длиной до 1 часа было показано, что процесс инициализации сессий в сетях является пуассоновским [91]. Для анализа трафика в большом временном масштабе только характеристики самих сессий важны для построения модели, в то время как индивидуальные процессы прибытия пакетов в рамках каждой сессии не рассматриваются. Для полного описания процесса счетчика общего трафика необходимо рассмотреть распределение длительностей сессий или ON/OFF периодов. Данные реальных наблюдений за потоками в LAN и WAN [91, 100] дают основание утверждать, что распределение длин ON/OFF периодов имеет бесконечную дисперсию и тяжелый хвост. Положительная случайная величина U с функцией распределения F имеет распределение с тяжелым хвостом с индексом хвоста > 0, если выполняется: P[U > y ] = 1 F ( y ) cy при y (45) с - положительная конечная константа не зависящая от у. Выражение 45 описывает гиперболическое или степенное распределение, частным случаем которого является хорошо известное распределение Парето [91, 97]. В работе [98] доказывается тот факт, что распределение длительностей периодов ON/OFF спадающее гиперболически или по степенному закону (выражение 13) при больших значениях количества потоков и длительном времени наблюдения определяют наличие свойства LRD суммарного потока с параметром Хёрста H = (3 ) 2.

(46) Авторы доказали, что отклонение от среднего значения представляет собой дробный гауссовский шум (Fractional Gaussian Noise) - классический пример в точности самоподобного процесса. Таким образом, в больших временных масштабах (асимптотическое) самоподобие сетевого трафика является следствием свойств сессий обмена (ON/OFF периодов). А именно того, что длительности этих периодов имеют распределение с тяжелым хвостом. Поэтому в больших масштабах самоподобие трафика не зависит от инфраструктуры сети или ее протоколов, а определяется набором информационных объектов передаваемых по этой сети. Дальнейшее развитие этой гипотезы дано в [99], где показано, что причиной наличия тяжелых хвостов в распределении длительностей ON периодов является соответствующее распределение размеров объектов в WWW - доминантной информационной системы в сети Интернет. В [99] наблюдения за реальным HTTP трафиком и файлами отчета крупнейших WWW серверов показывают наличие связи между гиперболическим распределением размеров информационных объектов WWW и гиперболическим распределением длительностей HTTP сессий, трафик которых составляет более половины всего Интернет трафика (по результатам множества исследований). Таким образом, трафик с малым разрешением по времени адекватно моделируется самоподобными или асимптотически самоподобными процессами согласно результатам [95, 97, 100]. 1.8.5.2. Трафик с высоким разрешением по времени Возвращаясь к высокодинамичному поведению сетевого трафика в малых временных масштабах, авторы [97] указывают на то, что причинами появления свойства LRD трафика в этих условиях являются свойства самих транспортных протоколов, управляющих потоками. Поскольку эти алгоритмы отвечают непосредственно за диспетчеризацию индивидуальных пакетов в рамках отдельных соединений, то вызываемые ими выраженные локальные нерегулярности трафика не являются связанными с самоподобными свойствами трафика в более грубом временном масштабе. Так при малом временном разрешении интернет трафик наиболее качественно описывается именно мультифрактальными процессами [96]. Надо отметить, что до настоящего времени неизвестна причина вызывающая такое поведение трафика. 1.8.6. Методы определения меры самоподобия Для оценки меры самоподобия трафика ARTCP нами применены два метода - метод R/S статистики и метод Aggregated Variance. Оба метода относятся к числу хорошо изученных и успешно применяются в целом ряде работ [94]. 1.8.6.1. Метод R/S статистики Для последовательности n X = { X i, i 1}, с частными суммами Y (n ) = X i i = n и дисперсией S 2 (n ) = ( 1 ) X i2 ( 1 ) 2 Y (n ) 2 n i =1 n R/S статистика (Rescaled adjusted range) определяется выражением: R t 1 t (n) = max (Y (t ) n Y ( n )) min (Y (t ) n Y ( n )) S S ( n ) 0 t n 0 t n поскольку для FGN выполняется свойство:

E [ R S ( n )] ~ C H n H при n (47) (48) то для определения коэффициента H по методу R/S применяется такой алгоритм: Последовательность длиной N разбивается на K блоков размером N K. Затем для каждого значения n вычисляется R ( ki, n ) S (ki, n ).

ki начальный номер элемента последовательности ki = iN K + 1, i = 1, 2, …, но таких, что k i + n N. Таким образом получаем для значений n < N/K K оценок R ( n ) S ( n ), по мере роста n число получаемых оценок для каждого n уменьшается. Если построить график зависимости log[R( ki, n ) S ( ki, n )] от log[n], то параметр H вычисляется как коэффициент наклона прямой, аппроксимированной по точкам полученной зависимости, после отбрасывания точек соответствующих большим и малым n. 1.8.6.2. Метод Aggregated Variance Если исходную последовательность X = { X i, i 1} разбить на блоки размера m и произвести усреднение по каждому блоку k, то получим агрегатную последовательность:

X ( m ) (k ) = 1 km X (i ) m i =( k 1) m + (49) для последовательности значений m. Вычислим затем дисперсию X ( m ) ( k ) по всем блокам. Поскольку для дробного гауссовского шума:

VarX ( m ) ~ m( 2 H 2 ), то для определения H пользуются следующим алгоритмом. Для определенного значения m разбить данные на N/m блоков размера m. Вычислить X ( m ) ( k ) для k = 1, 2, …, N/m и дисперсию:

VarX (m) 1 N / m (m) 1 N / m (m) = [ X (k )]2 X ( k ) N m k =1 N m k = (50) Повторяя эту процедуру для различных значений m (m << N) можно построить график зависимости log[VarX (m ) ] от log[m]. По полученным точкам аппроксимируем прямую, и по углу ее наклона определяем коэффициент H. 1.9 Управление потоками в коммуникационных системах 1.9.1. Общие принципы Управление потоками в коммуникационных сетях обозначает регулировку скорости отправки данных в сеть с целью достижения максимального использования ресурса сети и минимизации потерь данных. В состав протокола TCP входит большое число разнообразных механизмов, которые отвечают за различную функциональность и находятся в определенном взаимодействии между собой в силу концептуально-необходимой связи или связи, возникшей при реализации. На рис. 14 приведена схема основных механизмов, входящих в состав самой распространенной реализации протокола TCP - Reno в составе 4.4 BSD UNIX [64].

Рис. 14. Набор функций и алгоритмов в составе стандартного протокола TCP.

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

Последствия перегрузки проявляются в увеличении времени доставки данных, падении эффективности использования сетевых ресурсов и так называемом сетевом коллапсе, когда процесс передачи полезных данных в сети полностью прекращается. Изучение систем управления потоками и предотвращения перегрузок, очень важно для развития сетей. Из множества предложенных схем лишь несколько стали стандартами и получили широкое распространение: IBM Systems Networking Architecture (SNA) [10], Digital's Networking Architecture (DNA) [11], и модель TCP/IP [12]. Наиболее полная классификация различных методик управления потоком приводится в [13].

1.9.1.1. Перегрузка и методы ее контроля в сетях с коммутацией пакетов Перегрузка является проблемой неэффективного совместного использования разделяемых ресурсов. В сети ресурсы распределены между всеми узлами, коммутаторами и каналами передачи данных. Любой из этих трех компонентов может стать узким местом в сети и вызвать ее перегрузку. С одной стороны сеть должна обслуживать все пользовательские запросы на передачу данных, которые, как правило, не могут быть предсказаны детерминистически и выражаются в виде всплесков по отношению к времени возникновения, скорости и объему передаваемой информации. С другой стороны все физические ресурсы сети имеют ограниченную мощность и должны быть управляемыми для достижения оптимального общего использования многими сессиями обмена данными. Более формальное описание ее состояния работы в перегрузки сети от можно получить (рис. рассмотрев 15). Мерой производительность зависимости нагрузки производительности может служить мощность, определенная как P = W / RTT (4) Рис. 15. Зависимость характеристик сети от нагрузки. Пропускная способность (вверху), время задержки (в середине), мощность сети (внизу). После достижения сетью насыщенного состояния (точка А) пропускная способность перестает расти, а время ответа (RTT) продолжает, поскольку происходит заполнение буферов внутри сетевых устройств. Мощность сети достигает пика в точке А – это оптимальный режим работы сети. Механизмы управления потоками должны удерживать режим работы сети на оптимальном значении нагрузки и обеспечивать возможность выхода из состояния перегрузки, если перегрузка все-таки произошла. Механизм управления потоками в сетях TCP/IP обеспечивается как самими конечными системами, в которых исполняются объекты протокола TCP, так и с помощью определенных механизмов управления очередями и диспетчеризации потоков в маршрутизаторах. 1.9.2. Управление задержкой сети Задержка данных при их передаче по сети состоит из двух компонентов:

D = DT + Dq (5) DT есть время, затрачиваемое пакетом на прохождение по элементам физической инфраструктуры линии связи зависящее лишь от скорости распространения электромагнитных волн в той или иной среде, а Dq определяется временем, которое пакет проводит в очередях маршрутизаторов, ожидая обслуживания. Например, для межконтинентального канала [6] протяженностью 5000 км задержка распространения сигнала составит 0.0167 с, в то время как задержка связанная с очередями в буферах маршрутизаторов может составлять несколько секунд в реальной системе. Для передачи мультимедиа информации очень важно чтобы значение задержки и ее дисперсия для индивидуальных пакетов были минимальными. Это требование выражается в требовании минимальности очередей в маршрутизаторах. Поскольку TCP в процессе передачи целиком заполняет очередь маршрутизатора, то за счет компонента Dq общая задержка в сети существенно возрастает. Поэтому в сетях, где величина задержка актуальна, помимо управления скоростью средствами протокола транспортного уровня необходимо использовать механизмы, расположенные в маршрутизаторах [16]. 1.9.2.1. Алгоритм RED Поскольку средствами одного протокола TCP обеспечить минимальность средней длины очередей в сетевых устройствах невозможно, то в схеме управления трафиком должны быть задействованы сами сетевые устройства. Для реализации такого управления используется алгоритм случайного раннего обнаружения (Random Early Detection - RED) [18]. Алгоритм RED применяется для предотвращения перегрузок в сетях передачи данных работающих по принципу коммутации пакетов. Маршрутизатор определяет близость состояния перегрузки, вычисляя среднюю длину очереди. Маршрутизатор оповещает соединения, проходящие через него, о состоянии перегрузки путем отбрасывания пакетов. Вероятность отбрасывания зависит от средней взвешенной длины очереди, пока ее значение находится в заданных пределах и становится равной единице при пересечении верхней границы. Маршрутизатор применяющий алгоритм RED позволяет удерживать низкой среднюю длину очереди, при этом допуская принятие в очередь всплески пакетов. В режиме перегрузки вероятность оповещения определенного транспортного соединения, путем отбрасывания или отметки пакета, с целью уменьшения окна контроля потока для этого соединения, пропорциональна доле этого соединения в общей пропускной способности канала. Алгоритм RED предназначен для работы с транспортным протоколом, который управляет своей пропускной способностью, реагируя на потери пакетов, которые протокол считает признаком перегрузки, снижением своей скорости передачи. RED не допускает дискриминации неравномерных потоков и приводит к глобальной синхронизации многих соединений. Однако применение алгоритма RED в маршрутизаторах усложняет их и увеличивает их стоимость. 1.9.3. Альтернативные схемы управления потоком 1.9.3.1. TCP VEGAS Vegas представляет собой улучшенную реализацию протокола TCP по сравнению с распространенными реализациями Tahoe и Reno. Улучшения, предложенные в системе Vegas [14, 15], затрагивают в основном механизм быстрой ретрансляции. В алгоритме Vegas используется более точный способ определения необходимости быстрой ретрансляции потерянных сегментов. Этот алгоритм использует значения временной метки в заголовке сегментов. Таким образом, Vegas лучше, чем TCP, реагирует на ситуации в которых происходит потеря более чем одного сегмента в пределах окна, и с которыми не может эффективно бороться стандартный механизм ускоренной ретрансляции [19, 20, 21]. Также в рамках этого механизма Vegas более точно управляет размером окна в процессе ретрансляции. Для реализации контроля перегрузки алгоритм Vegas сохраняет значение минимального RTT в переменной BaseRTT=min(BaseRTT, RTT). Ожидаемое значение пропускной способности определяется по формуле Expected=размер_окна/BaseRTT. Далее, реальная пропускная способность периодически вычисляется как количество байт переданных с момента отправки определенного сегмента и до прихода его подтверждения. Разность реальной и ожидаемой пропускной способности определяет выбор режима линейного увеличения или уменьшения окна. Поскольку основной алгоритм Vegas полностью взят от TCP, то все основные недостатки, присущие TCP, характерны и для TCP Vegas. 1.9.3.2. TRUMP Данный механизм разработан в докторской диссертации В.К. Тумей [22] и в него входит не только спецификация транспортного протокола, но и целая система управления потоком на сетевом уровне. Эта система включает в себя механизм измерения загрузки узлов с явной реверсивной обратной связью и собственный формат данных. Интересным аспектом системы TRUMP является то, что скорость отправки данных в сеть регулируется не скользящим окном, а значением разрешенной скорости, задаваемым сетевыми устройствами. К недостаткам системы нужно отнести тот факт, что системы с явной передачей контрольной информации существовали и ранее [23, 24, 25]. Попытки реально внедрить такие системы для сети Интернет не имели успеха, поскольку это потребовало бы введение дополнительных функций маршрутизаторов, в то время как TRUMP предусматривает не только существенное изменение сетевых устройств, но и полное отсутствие совместимости с архитектурой TCP/IP. 1.9.3.3. PP (Packet Pair Flow Control) Управление потоком по методу Packet Pair Flow Control [26] представляет собой оригинальную идею измерения доступной пропускной способности сети. Схема предназначена для сетей с виртуальными каналами, которые изолируют транспортные потоки при помощи диспетчера квотированного обслуживания (ДКО) очередей [27, 28, 29]. Мотивация для создания такой схемы управления потоками в том, что предоставление интегрированных сервисов становится доминирующим направлением в современной сетевой парадигме. Согласно ей сети должны одновременно обслуживать стабильные потоки с постоянной скоростью передачи данных одновременно с потоками, работа которых характеризуется всплесками и неравномерностью. Первый тип обменов должен получать обслуживание от сети с гарантированным качеством, а второй тип трафика использовать оставшиеся ресурсы. Это основная концепция построения сетей с интеграцией сервисов [30]. Для ее реализации, межсетевые устройства должны применять один из алгоритмов равноправного обслуживания очередей. Как правило это алгоритм взвешенной равноправной диспетчеризации WFQ [28]. Работа по PP в дополнение к механизму определения пропускной способности, описывает оценочную функцию для сглаживания полученных измерений, функцию управления, метод управления соединением, методы управления потоком и передачей. Устройство, где исполняется алгоритм ДКО, называют сервером выделения пропускной способности (СПС). В таком устройстве пакеты каждого отдельного транспортного потока помещаются в отдельную очередь на выходном интерфейсе. Каждая из этих очередей имеет тип FIFO и обслуживается диспетчером со скоростью R = Rb / N (6) Где Rb - скорость самого интерфейса, а N – количество очередей на нем. Некоторые очереди могут иметь приоритет по отношению к другим. На каждом таком сервере соединение обслуживается с некоторой скоростью независимо от других соединений. Все СПС на пути соединения пронумерованы 1,2,3,…,n. Получатель подтверждает каждый пакет. Время обслуживания на i-том сервере si (t ), а мгновенная скорость обслуживания тогда µ i = 1 / si (t ) (7) Время si (t ) есть интервал обслуживания всех остальных потоков, проходящих через данный интерфейс – период цикла обслуживания. Скорость отправки сегментов в сеть обозначена. Скорость наиболее узкого места в сети определена как sb (t ) = max(si (t ) | 0 i n) Где b – индекс ограничивающего СПС.

(8) µ b (t ) = 1 / sb (t ) есть скорость ограничивающего СПС, которая изменяется с изменением числа активных потоков в сети. Авторы моделируют эти изменения как происходящие через дискретные интервалы 1, 2, …, k, k+1, …. Если число активных потоков N ac велико, то можно ожидать, что N ac << N ac за один интервал, т.е. значение µ b (k ) близко к µ b ( k + 1). За счет этого определяется µ b (k + 1) = max(µ b (k ) + (k ),0) Где (k ) - случайная переменная.

(9) Отправляя данные в виде пар пакетов, в которых второй пакет мгновенно следует за первым и, измеряя временное расхождение в прибытии подтверждений, система PP определяет минимальную скорость на протяжении всего маршрута: µ b и вычисляет необходимую на новом шаге скорость передачи (k + 1) в соответствии с принципом сохранения длины очереди в ограничивающем СПС. В работе также доказывается независимость полученных измерений от всех СПС кроме ограничивающего. Алгоритм PP не подходит для использования в сетях TCP/IP, поскольку в таких сетях отсутствует логическая изоляция потоков на сетевом уровне. Однако PP вполне может найти применение в сетях ATM, при наличии раздельной буферизации каждого из виртуальных каналов. 1.9.3.4. NETBLT Протокол NETBLT [33, 34] разработан с цель предоставления пользователю сервиса аналогичного сервису протокола TCP, а именно надежной передачи большого объема информации с подтверждениями и контролем скорости потока. В протоколе NETBLT представлено несколько принципиально новых идей. Во-первых, скорость потока регулируется заданной получателем величиной скорости. Передача осуществляется из предварительно сформированных банков информации. После передачи каждого банка (которые могут передаваться независимо), получатель подтверждает корректно полученные данные или запрашивает выборочную ретрансляцию потерянных пакетов. Также в зависимости от наблюдаемого уровня потерь NETBLT устанавливает новую скорость передачи. Во-вторых, сама передача регулируется несколькими параметрами – частотой и длительностью всплесков, каждый из которых может состоять из нескольких пакетов. За счет этого повышается эффективность использования системных ресурсов, в частности уменьшается число прерываний используемых для диспетчеризации передачи. Этот подход можно применить и для протокола ARTCP. Таким образом, протокол NETBLT способен обеспечить хорошие результаты при работе по каналам, характеризующимся большим значением RTT*BW. Однако NETBLT не свободен и от недостатков присущих TCP, например оба протокола интерпретируют потерю пакета как признак перегрузки, что неверно в общем случае. 1.9.3.5. Tri-S Алгоритм Slow Start and Search (Tri-S) [35] основан на механизме замедленного старта протокола TCP. Авторы проанализировали недостатки замедленного старта и попытались устранить неприемлемо высокую амплитуду осцилляций размера окна, которая приводит к большому числу потерь и значительному увеличению компонента задержки связанного с буферизацией пакетов в сети Dq и к высокой дисперсии измерений времени RTT. Кроме того, авторы работы [35] показали, что схема управления потоком TCP позволяет обменам с меньшим числом промежуточных узлов (и соответственно меньшим средним значением RTT) в среднем использовать большую долю пропускной способности, чем потокам с большим RTT. В [35] предложено использовать так называемый нормализованный градиент пропускной способности (НГПС) и интерпретировать изменение в пропускной способности (ПС) как сигнал о перегрузке или наличии резерва ПС в сети. Алгоритм Tri-S вычисляет НГПС по формулам:

TG (WN ) = T (WN ) T (WN 1 ) WN WN 1 TG(WN ) TG(W1 ) (10) NTG(WN ) = (11) где TG (WN ) - ненормированный ГПС, W N - размер окна, NTG (WN ) - НГПС при значении окна W N, а T (WN ) -скорость, когда размер окна равен W N. Интервал значений НГПС: [0,1]. В сети с небольшой нагрузкой NTG 1, по мере приближения нагрузки к суммарной ПС сети, НГПС приближается к 0. Средняя скорость передачи данных вычисляется по времени обращения n-ного пакета:

TN (WN ) = WN RTTN (12) Сравнивая значения НГПС с двумя предельными значениями, алгоритм Tri-S принимает решение об уменьшении или увеличении размеров окна. По результатам моделирования схема Tri-S позволяет улучшить показатель справедливости деления ПС по сравнению с TCP. Однако выбор предельных значений оказывает сильнейшее влияние на стабильность системы. Кроме того, как и стандартный TCP, схема Tri-S интерпретирует потерю пакета как признак перегрузки. 1.9.3.6. DUAL Данный метод был предложен как способ устранения проблем с осцилляцией окна, наблюдаемых с алгоритмом замедленного старта [36]. DUAL использует изменение измеряемого RTT вместе с отслеживанием потерь пакетов для определения перегрузки. Поскольку D = DT + Dq, то RTTmin = 2 DT.10 В о время как RTTmax = DT + Dq = DT + Qmax / R (13) Минимальное RTT пропорционально величине задержки. Поскольку RTT равно сумме времени доставки Где Q max – максимальная длина очереди, а R – скорость обслуживания очереди. Алгоритм DUAL постоянно вычисляет минимальное и максимальное значение RTT и, сравнивая их с предельным значением RTTi увеличивает или уменьшает скорость передачи. RTTi = (1 ) RTTmin + RTTmax (14) <1. Предлагается использовать значение 0.5. От алгоритма медленного старта DUAL отличается тем, что с периодичностью 2RTT он сокращает значение окна на 7/8, если RTT > RTTi. Значение срабатывании ТПП. Проблема алгоритма DUAL в том, что если начальные значения RTT min различны для различных соединений, то они никогда не достигнут равного деления ПС канала между собой, поскольку соединение имеющее наименьшее RTT min будет позже остальных начинать сброс значения окна. 1.9.3.7. Выводы Каждый из этих методов обладает определенными недостатками и не применяется в стандартных протоколах. Главный недостаток Vegas, Tri-S, DUAL в том, что в них используется протокол TCP, который реагирует на потерю сегмента снижением скорости, а в отсутствии потерь линейно увеличивает нагрузку на сеть, приводя к переполнению буферов. Схема TRUMP предполагает расширение функциональности маршрутизаторов механизмом, уведомляющим источники о перегрузке в явном виде, что означает отход от парадигмы сетей с пакетной коммутацией. PP предлагает эффективный способ измерения загрузки сети, однако неприменимый для TCP/IP, поскольку предполагает работу в сети с виртуальными каналами на сетевом уровне. 1.9.4. Принципы AIMD и STA Большинство алгоритмов управления потоками различаются способом определения наступления состояния перегрузки и реагируют на изменения состояния сети путем аддитивного (линейного) увеличения нагрузки и мультипликативного сброса, в случае определения наступления перегрузки. В литературе такой подход получил название Addititve Increase and Multiplicative Decrease (AIMD). Обоснование применения принципа AIMD изложены в работе [2]. RTTi обновляется с каждым измерением RTT. Кроме того, минимальное и максимальное RTT устанавливаются в и 0, соответственно, при данных и времени возврата подтверждения, то коэффициент пропорциональности равен 2. Пусть загрузка сети измеряется через некоторые интервалы фиксированной длины, например среднее время DT. DT RTT / 2, когда сеть не перегружена. В этом случае модель сети проста: Li = N, где L – показатель загрузки (например, средняя длина очередей), а N – константа. Если же сеть подвержена перегрузке, то модель изменяется. Теперь Li = N + Li 1 (15) где определяет влияние трафика за прошлый период, а также последствия потерь, т.е. наличие в сети ретранслированных данных. Когда сеть находится в состоянии перегрузки велико и длина очередей растет экспоненциально, поскольку из Li Li 1 следует Ln = n L0. Вследствие этого система может стабилизоваться, только если источники трафика в сети могут уменьшать скорость его генерации также экспоненциально. Таким образом, получается, что при перегрузке размер окна W должен изменяться по закону: Wi = dWi 1 (16) где 0 < d < 1. Это и есть мультипликативный сброс, который превращается в экспоненциальный, если перегрузка продолжается в течение нескольких периодов обновления окна DT. В случае отсутствия перегрузки, сеть никак не сообщает соединениям о наличии дополнительных ресурсов, в связи с этим, в отсутствие сигналов о перегрузке, соединения должны увеличивать нагрузку, до тех пор, пока потеря пакет не сообщит о начале перегрузки. Экспоненциальный рост всегда приводит к новой перегрузке, поэтому автор [2, 44, 45] рекомендует линейный рост или аддитивное увеличение: Wi = Wi 1 + u, u << Wmax (17) где Wmax = DT BW - произведение задержки передачи и пропускной способности канала.

Pages:     || 2 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.