709.моделирование и анализ транспортных протоколов в информационных сетях монография

1

Министерство образования и науки Российской Федерации Ярославский государственный университет им. П.Г. Демидова

И.В. Алексеев, В.А. Соколов, Д.Ю. Чалый

МОДЕЛИРОВАНИЕ И АНАЛИЗ ТРАНСПОРТНЫХ ПРОТОКОЛОВ В ИНФОРМАЦИОННЫХ СЕТЯХ

Под редакцией В.А. Соколова

Ярославль 2004

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

2

ББК З 973.2 А 47 УДК 004.7.057.4

Рецензенты: кафедра прикладной математики и вычислительной техники Ярославского государственного технического университета;

доктор технических наук, профессор В.А. Курчидис.

А 47

Алексеев И.В., Соколов В.А., Чалый Д.Ю. Моделирование и анализ транспортных протоколов в информа-ционных сетях: Монография / И.В. Алексеев, В.А. Соколов, Ю.Д. Чалый; Яросл. гос. ун-т. – Ярославль, 2004. – 262 с. ISBN 5-8397-0358-3

В монографии представлен новый вариант транспортного протокола

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

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

ББК З 973.2 А 47 УДК 004.7.057.4

Работа поддержана грантом РФФИ № 03-01-00804.

ISBN 5-8397-0358-3 Ярославский государственный университет, 2004 И.В. Алексеев, В.А. Соколов, Д.Ю. Чалый, 2004


3

Предисловие

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

- скорость отправки ARTCP сегментов в сеть управ-ляется не размером окна передачи (как в TCP), а инди-видуальной задержкой каждого сегмента, при этом изменение скорости отправки потока выражается в изменении его скважности (межсегментного времен-ного интервала); - индикатором текущего состояния сети и, соответст-венно, наступления перегрузки служит не потеря па-кета, а изменение скважности потока сегментов, изме-ряемое получателем, а также изменение времени тран-зита сегментов, измеряемое отправителем; - функционирование ARTCP не зависит от потока подтверждений для синхронизации отправки новых сегментов в сеть.

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


4

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

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

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

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


5

сравнению с TCP средняя длина очереди и полное отсутствие потерь сегментов.

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

Авторы считают своим приятным долгом выразить бла-

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


6

Введение

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

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

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

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


7

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

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

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

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

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


8

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

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

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

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

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

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


9

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

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

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

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

Наряду с исследованием динамических характеристик важной задачей является обоснование корректности работы протокола TCP. Например, Беловин в работе [104] описывает ряд проблем, связанных с корректностью спецификации про-токола. Ряд ошибок начальной спецификации [4] был учтен при разработке обновленного стандарта протокола [5].

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


10

Формализм раскрашенных сетей Петри является хоро-шо развитым как с теоретической, так и с практической точек зрения. Раскрашенные сети Петри были использованы в ряде успешных проектов по исследованию свойств различных про-токолов. Например, Клаусен и Йенсен в работе [122] исполь-зовали этот формализм для оценки производительности сете-вых алгоритмов для высокоскоростных линий связи, в работе [123] те же авторы исследовали работу ATM-сетей. Наряду с анализом производительности, с помощью раскрашенных се-тей Петри проводилось исследование корректности протоко-лов. Биллингтон и Гордон в работе [130] использовали рас-крашенные сети Петри для анализа корректности специфика-ции протокола WAP (Wireless Application Protocol). Таким об-разом, раскрашенные сети Петри представляются весьма удобным формализмом для моделирования и анализа различ-ных свойств коммуникационных протоколов. Предлагаемая в книге модель протокола TCP является в некотором смысле универсальной, т. е. с ее помощью можно оценивать не толь-ко качественные (корректность исполнения), но также и ко-личественные (производительность) характеристики.


11

Часть 1. Транспортный протокол TCP и его модификация ARTCP

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

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

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

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

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


12

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

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

1.1. Системы протоколов Важнейшим компонентом сети являются коммуникаци-

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

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

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

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

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

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


13

Методы формального описания Существуют несколько методов для формального опи-

сания протоколов. Это языки SDL (Specification and Descrip-tion Language), Lotos и Estelle. Наиболее часто применяется язык SDL, который является стандартом ITU1

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

. Существуют две формы SDL – графическая и программная [55]. Естест-венно, что из всех компонентов протокола именно процедур-ные правила могут быть даны с помощью того или иного язы-ка формального описания.

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

- он должен быть логически связным; - он должен удовлетворять условию полноты; - этот набор должен быть легко реализуем (аппаратным

или программным образом).

Пять элементов протокола В дополнение к определению, данному выше, разработ-

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

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

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

протокола; -словарь допустимых сообщений;

1 International Telecommunications Union – международная организа-

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


14

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

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

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

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

Иерархии протоколов Принципы разработки и исследования любой сложной

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

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


15

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

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

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

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

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

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

данные верхнего уровня внутри своего формата сообщений (рис. 1).


16

Таким образом, на каждом уровне N-процедура, отправ-

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

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

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

Рис. 1. Пример инкапсуляции данных одного протокола

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


17

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

Сервисы и интерфейсы Предоставление сервисов верхним уровням является

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

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


18

На уровне N-1 от сообщения отделяется контрольная

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

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

IDU – формат блока данных на соответствующем интерфейсе; ICI – контрольная информация для

нижележащего уровня; PDU – сообщение, определенное протоколом соответствующего уровня; IDU – сообщение в формате интерфейса между уровнями; h – заголовок,

несущий контрольную информацию для протокола соответствующего уровня; Data – передаваемые данные


19

уровня N-1 (N-1 h). После этого получившаяся структура дан-ных передается на уровень N-2 для дальнейшей обработки.

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

Типы соединений Уровни иерархической архитектуры могут предостав-

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

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

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

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

Примитивы сервисов Сервис формально задается набором примитивов, опре-

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


20

Запрос Объект должен выполнить определенную задачу

Индикация Запрашивающий должен быть проинформирован о событии

Ответ Запрашивающий желает прореагировать на событие Подтверж-дение

Прибытие ответа на предыдущий запрос

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

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

CONNECT.indication – сигнал вызываемой стороне; CONNECT.response – применяется вызываемой сто-

роной для подтверждения/отмены установления соединения; CONNECT.confirm – сообщение вызывающей стороне

о приеме запроса на соединение; DATA.request – запрос на передачу данных; DATA.indication – сигнал о приеме данных; DISCONNECT.request – запрос на разъединение; DISCONNECT.indication – сигнал другой стороне о

разъединении.

Связь сервисов и протоколов Сервис – это набор примитивов (элементарных дейст-

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


21

1.2. Эталонные модели

Модель ISO OSI RM Международной организацией по стандартизации (ISO)

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

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

Физический уровень В задачу этого уровня входит корректная передача би-

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

Рис. 3. Эталонная модель взаимодействия открытых систем

(ЭМВОС). Уровни и направление передачи данных. Изображены также промежуточные системы канального

и сетевого уровней


22

Канальный уровень Этот уровень создает логический канал, не имеющий

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

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

Сетевой уровень Задачей сетевого уровня является управление работой

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


23

Транспортный уровень Транспортный уровень предоставляет (и скрывает от

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

Сеансовый уровень Этот уровень синхронизирует, открывает, закрывает се-

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

Уровень презентации Уровень презентации осуществляет кодирование дан-

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

Уровень приложения Этот уровень отличается от остальных тем, что его объ-

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


24

1.3. Модель TCP/IP В середине 1970-х годов американской военной иссле-

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

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

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


25

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

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


26

Сетевой протокол модели TCP/IP: протокол IP Протокол IP является единственным протоколом сете-

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

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

1.4. Транспортный уровень Транспортный уровень набора протоколов Интернета со-

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

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

Эволюция коммуникационных протоколов Рассмотрим процесс развития сетевых протоколов на

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


27

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

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

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


28

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

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

Транспортный уровень: роль и компоненты Транспортный уровень является центральным для всей

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

Сервис транспортного уровня Главная задача транспортного уровня заключается в пре-

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

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


29

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

Транспортные протоколы дают возможность предостав-

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

Рис. 6. Обмен данными на уровне транспортного протоко-

ла. Формат данных транспортного протокола TPDU


30

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

Рассмотрим, каким образом протокол TCP улучшает параметры сервиса по сравнению с сервисом сетевого уровня.

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

- потеря; - дублирование; - искажение порядка отправки. Протокол TCP полностью устраняет эти ошибки. С точки

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

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

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

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


31

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

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

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

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

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


32

терфейс Berkeley Sockets является промышленным стандар-том и используется в большинстве операционных систем.

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

Вызов SOCKET в случае успешного завершения воз-вращает дескриптор3

Примитив

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

Пояснение SOCKET Создать новую точку доступа к системе связи (ТДС) BIND Присвоить локальный адрес ТДС LISTEN Объявить о готовности к приему соединений, устано-

вить размер очереди ACCEPT Блокировать инициатора до поступления запроса на

соединение CONNECT Попытаться установить соединения SEND Передать данные RECEIVE Получить данные CLOSE Завершить сеанс связи

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

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

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


33

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

Характеристика среды исполнения Для того чтобы определить среду исполнения протокола

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

Сервисы сетевого уровня Доступ к сервисам сетевого уровня возможен на интер-

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

- сервисы не зависят от канальной технологии базовой сети;

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

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

Рассмотрим вкратце функционирование протокола IP и проанализируем его с точки зрения среды исполнения транс-портного протокола.


34

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

Закончив компоновку пакета, IP передает его в сеть на

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

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


35

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

Возникновение и коррекция ошибок Низкое соотношение энергии сигнала к энергии шума на

линии приводит к искажениям принимаемого сигнала и, как следствие, к высокой вероятности битовых ошибок на прием-нике. Ошибки канала передачи данных проявляются как:

- вставленные данные: данные, полученные приемни-ком, но никогда не передававшиеся отправителем;

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

- дублированные данные: данные, переданные едино-жды и полученные в нескольких экземплярах;

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

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

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

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


36

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

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

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

ление скоростью передачи данных. Физический уровень ответ-ствен за синхронизацию записи и сканирования среды переда-чи. Канальный уровень управляет скоростью передачи пакетов между двумя узлами, применяя схему управления потоком той или иной сложности, в зависимости от назначения – Xon/Xoff, Alternating Bit [42], Sliding Window [43] и т.п. Сетевой уровень также имеет примитивную схему управления потоком. Мар-шрутизатор в состоянии перегрузки может отправить своим топологическим соседям сообщение о наличии перегрузки при помощи протокола ICMP. Однако все алгоритмы канального и сетевого уровней осуществляют управление скоростью потока лишь локально. TCP как протокол транспортного уровня осу-ществляет управление потоком по всей длине логического ка-нала между передающей и принимающей системами.


37

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

Процедурные правила Сервис транспортного уровня реализуется транспортным

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

- адресация и мультиплексирование; - инициализация и закрытие связи; - буферизация и управление потоком.

Словарь транспортного протокола Словарь простейшего транспортного протокола, обес-

печивающего надежный канал связи и контроль скорости пе-редачи, должен позволять передавать следующие типы сооб-щений [1, 3]:

- данные (DATA); - подтверждения (ACK); - размер приемного окна (WND). Таким образом, минимальный словарь транспортного

протокола, обеспечивающего надежную связь, таков: V={DATA, ACK, WND}. Если рассматривать каждое на-правление полнодуплексного транспортного соединения раз-дельно, то данные передаются в направлении от отправителя к получателю, а подтверждения и обновления окна – в проти-воположном направлении.

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


38

общений в каждом TPDU. Реально в каждом сообщении объ-единяются все эти типы. Формат сообщений транспортного протокола таков: {DATA, SEQ}

{ACK, SEQ, WND}, где SEQ и WND – целые числа. Поскольку транспортные соединения рассчитаны на

двусторонний обмен сообщениями, то объединяются все поля в едином формате сообщения: {DATA, SEQ, ACK, SEQ, WND}.

Число SEQ во второй позиции нумерует передаваемые данные, а в третьей позиции – подтверждаемые данные.

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

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

Формат сегмента, как правило, следующий: заголовок фиксированной длины, выровненный на 32-битной границе, предшествует полю данных переменной длины. Более кон-кретная схема кодировки сегмента и детализация дополнитель-ных полей приведена в схеме заголовка TCP-сегмента (рис. 8).

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


39

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

Адресация Для установки связи с удаленным приложением требу-

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

Установка соединения Без способности БС к накоплению пакетов задача уста-

новления соединений свелась бы к двум действиям: послать запрос на соединение – дождаться положительного ответа на него. На самом же деле проблема значительно сложнее. Если БС перегружена и подтверждения не успевают прибыть к от-правителю вовремя, то и запросы на установление соединения могут быть отправлены несколько раз. Поскольку маршрутиза-ция каждого пакета происходит независимо, то существует ве-роятность задержки некоторых пакетов в течение более дли-тельного времени, чем других, и, соответственно, сбоев при ус-тановлении соединения. Единичная транзакция может, таким образом, случайно произойти более одного раза.


40

Используемый в архитектуре TCP/IP метод сочетает

идентификацию каждого пакета с требованием ограничения времени жизни пакетов в сети. Причем идентификация каждо-го пакета подразумевает наличие у него порядкового номера.

В реальности необходимо гарантировать, что не только сам пакет исчез из сети, но и все его подтверждения, поэтому используется промежуток времени Т, кратный максимальному времени жизни пакета. Если прошло время Т с момента от-правки пакета, то мы можем быть уверены, что ни сам пакет, ни его подтверждения не существуют в сети. Если опираться на такую предпосылку, то можно разработать надежный спо-соб безопасной установки соединения. Метод был впервые предложен в 1975 г. [37] и усовершенствован в 1978 г. [38]. Метод называется «трехсторонний обмен» (Three-Way Handshake). Этот метод не требует использования обеими сто-ронами одних и тех же номеров. Нормальная процедура уста-новки соединения показана на рис. 10 (часть А). Устройство А посылает запрос на соединение (CR) устройству В, указывая

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

с уровнем приложения и сетевым уровнем


41

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

Схема установки соединения, приведенная выше, при-

меняется транспортным протоколом TCP. Альтернативная схема надежной установки соединения в условиях наличия задержанных копий сообщений описана в [39].

Разрыв соединения Для закрытия транспортного соединения используется

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

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

Рис. 10. Установка соединения по методу тройного обмена.

Часть А – нормальная установка соединения, В – реакция на дубликат запроса,

С – реакция на дубликат запроса и данных


42

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

Если же соединение должно оставаться открытым в те-

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

Рис. 11. Сценарии разрыва соединения с использованием подтверждений и таймеров. Часть А – сценарий без ошибоч-

ных ситуаций. В, С и D – различные сценарии возникновения ошибок. Потерянный сегмент изображается звездочкой


43

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

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

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

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

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


44

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

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

1.5. Протокол TCP Как уже было сказано, семейство протоколов TCP/IP

включает в себя два протокола транспортного уровня: это TCP (Transmission Control Protocol) и UDP (User Datagram Protocol). UDP достаточно прост, по существу, это небольшое дополнение к IP, которое не использует виртуальный канал. TCP – это надежный протокол, который использует предвари-тельную установку виртуального канала и доставляет данные пользователя без ошибок. ТСР был специально разработан, чтобы обеспечивать надежную передачу байтового потока от отправителя к получателю через ненадежную БС. БС может


45

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

Формально протокол ТСР был определен в RFC 793 [4]. Со временем накопившиеся ошибки и недостатки были учте-ны и нашли выражение в требованиях к устройствам сети Ин-тернет в RFC 1122 [5]. В дальнейшем было проведено боль-шое количество исследований с протоколом. Часть модифи-каций стала стандартом, и новые спецификации протокола содержатся в RFC 1323 [6].

Каждое устройство, поддерживающее ТСР, содержит в себе объект протокола, который управляет ТСР-потоками и взаимодействует с уровнем IP. Этот объект принимает потоки данных от локальных процессов, разбивает их на сообщения определенной длины (сегменты) и передает сегмент на уро-вень IP для его передачи в виде отдельного IP-пакета. По прибытии на адресуемую машину информация из этих паке-тов передается ТСР-объекту, который реконструирует ориги-нальный байтовый поток и передает его пользовательской программе. Уровень IP не гарантирует доставку пакетов, по-этому ТСР должен отслеживать потерянные пакеты и осуще-ствлять повторную отправку. Пакеты могут прибывать в по-рядке, отличающемся от того порядка, в котором они были отправлены, поэтому задачей ТСР является также реконст-рукция порядка в битовом потоке. Для управления потоком и предотвращения перегрузок БС ТСР применяет механизм скользящего окна [43].

Модель обслуживания ТСР Доступ к сервису ТСР можно получить путем создания

на конечных машинах точек доступа (Sockets). Каждая такая точка имеет адрес, состоящий из IP адреса машины и 16-бит-ного номера, уникального в пределах устройства, идентифи-цирующего порт. ТСР-соединение устанавливается между двумя точками доступа, и пара транспортных адресов одно-значно идентифицирует соединение. Несколько соединений могут оканчиваться на одной точке доступа. Порты с номера-ми ниже 256 однозначно соответствуют набору конкретных


46

приложений. Порты с другими номерами выделяются прило-жениям динамически. Все ТСР-соединения полнодуплексные и имеют тип “точка-точка”. Соединение представляет собой неструктурированный байтовый поток, т. е. границы между сообщениями не сохраняются.

Когда приложение передает данные ТСР, протокол мо-жет либо сразу осуществить их отправку, либо накопить дос-таточное их количество в буфере. Если же приложению необ-ходимо послать информацию мгновенно, то оно может ис-пользовать флаг PUSH. Кроме того, существует возможность пересылать срочную информацию с использованием флага URGENT. Когда приложение устанавливает этот флаг, то ТСР передает все имеющиеся данные без промедления; кроме то-го, ТСР получателя генерирует прерывание для приложения, которому предназначается срочная информация, и указывает на положение ее в полученном потоке.

Каждый байт ТСР-соединения имеет уникальный 32-бит-ный порядковый номер. Эти номера используются не только для подтверждений, но и для механизма управления окном. Объекты ТСР обмениваются информацией в виде сегментов. Сегмент состоит из 20-байтного заголовка (плюс необязатель-ная часть) и нуля или более байтов данных (рис. 8). Протокол сам принимает решение относительно размера сегмента. Су-ществуют два ограничения размера сегмента. Первое: сегмент должен умещаться в пределах максимального размера поля по-лезной нагрузки IP – 216 байтов. Второе: каждая сетевая техно-логия имеет так называемую максимальную единицу передачи (Maximum Transfer Unit – MTU), в которую и должен уме-ститься полный IP-пакет, включающий в себя IP- и ТСР-заголовки и данные.

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


47

Формат заголовка ТСР Заголовок сегмента ТСР содержит следующие поля, по-

казанные на рис. 8. Порядковый номер идентифицирует первый байт дан-

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

Номер подтверждения – содержит порядковый номер следующего байта данных, который ожидается на прини-мающем устройстве.

Флаги – разнообразная контрольная информация: URG – срочные данные (указатель на срочные данные в

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

вильную информацию; PSH – получатель должен доставить данные приложе-

нию как можно скорее; RST – соединение должно быть закрыто; SYN – используется для установки соединения (запрос

на установку содержит SYN=1, ACK=0, ответ на этот сег-мент содержит SYN=1, ACK=1);

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

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

Управление соединением Установка соединения в ТСР использует процедуру

трехстороннего обмена. Для открытия соединения пассивная сторона исполняет примитивы LISTEN и ACCEPT, а другая открывает соединение в активном режиме, исполняя прими-тив CONNECT. Когда запрос на открытие соединения прибы-


48

вает к получателю, тот проверяет, есть ли процесс, зарегист-рированный для приема соединений по указанному порту. Если такой процесс существует, то соединение устанавлива-ется (рис. 12, часть A).

Хотя ТСР-соединения полнодуплексные, закрываются

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

Управление передачей Управление окном в ТСР не привязано напрямую к

подтверждениям (как во многих протоколах канального уров-ня). Упрощенный вариант схемы управления передачей при-веден в примере на рис. 13.

Рис. 12. Сценарии установки соединения TCP.

Часть А – нормальная процедура, часть В – установка соединения при столкновении запросов


49

Подтверждения, используемые протоколом TCP, явля-ются кумулятивными, т. е. каждое подтверждение соответст-вует последнему полученному в правильном порядке байту потока. Приход подтверждения с номером N означает, что все байты [0…N-1] были успешно доставлены получателю.

Управление окном и тактика подтверждений На ранних стадиях эксплуатации протокола было заме-

чено, что часто в сетях возникали перегрузки при очень низкой эффективности использовании ресурсов [8]. Были выявлены

Отправитель

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

данных Kb

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

данных Kb

Приложениевыполняет

чтение 2данных

KbМожно

отправитьеще 2 Kb

Отправительблокирован

Получатель

2 Kb данныхв буфере

3 данныхв буфере Kb


Буферпуст

2 данныхв буфереKb

2 данныхв буфереKb







Данные = 2 Kb, SEQ=0

Данные = 22048

Kb, SEQ=

Данные = 1 Kb, SEQ=4096

ACK = 2048

ACK = , WIN=04096

ACK = 5120, WIN=1024

ACK = , WIN=20484096

Рис. 13. Управление передачей данных и окном в TCP. Ось времени – сверху вниз


50

три независимые причины этого: приложение, вызывающее протокол для отправки незначительного количества информа-ции; обновление окна ТСР очень маленькими порциями, вызы-вающими ответные сегменты с малой полезной нагрузкой; сам протокол, посылающий слишком много подтверждений. Было предложено использовать так называемый алгоритм SWS [5] для решения проблемы с обновлением окна.

А. Алгоритм SWS у получателя совмещен с задержкой подтверждения и предписывает: обновление окна вместе с под-тверждением отправляется, только если освободившийся объ-ем буфера превосходит определенную долю общего буферного пространства (30 – 50%) или 2-3 максимальных размера сег-мента.

Б. Алгоритм SWS у отправителя предписывает: отправи-тель пытается приблизительно оценить размер буфера получа-теля, отслеживая максимальный размер окна, открываемого получателем на данном соединении max(SND.WND4). Исполь-зуемое окно, данные в пределах которого могут быть отправ-лены, вычисляется U=SND.UNA5+SND.WND–SND.NXT6

- есть возможность послать сегмент максимального размера min(D,U)≥Eff.snd.MSS

. Если D количество данных, буферизованных протоколом, но еще не отправленных, то ТСР отправляет данные, если:

7

- установлен флаг PUSH и [SND.NXT=SND.UNA] & PUSHED & D≤U [SND.NXT=SND.UNA] – условие, налагае-мое алгоритмом Nagle [3];

;

- как минимум, доля Fs от максимального окна может быть отправлена [SND.NXT=SND.UNA] & min(D,U)≥Fs*Max(SND.WND);

- установлен флаг PUSH и сработал таймер.

4 SND.WND – переменная в контрольном блоке каждого соединения.

SND.WND указывает на «правую» границу окна в потоке данных. 5 SND.UNA – переменная, указывающая на последний неподтвер-

жденный байт. 6 SND.NXT – переменная, содержащая указатель на следующий го-

товый к отправке байт данных. 7 Eff.SND.MSS – реальный размер сегмента ТСР.


51

В. Алгоритм Nagle эффективен, когда приложение пере-дает малые объемы информации. Согласно этому алгоритму, если есть неподтвержденные данные (SND.NXT>SND.UNA), то ТСР отправителя буферизирует данные без отправки, не-смотря на наличие флага PUSH, до момента, когда либо прихо-дит подтверждение, либо становится возможным отправить сегмент максимального размера. Существует также таймер, предотвращающий ситуацию взаимной блокировки.

Г. Алгоритм задержки подтверждений требует, чтобы подтверждение задерживалось не менее чем на 0.5 с. Под-тверждения задерживаются до тех пор, пока не возникнет возможность указать новое окно, иначе данные отправляются в противоположном направлении. Таймер генерирует безус-ловное подтверждение каждые 200 мс. Кроме того, каждый второй сегмент должен подтверждаться. Также сегменты, бу-феризованные у получателя (прибывшие в неправильной по-следовательности), генерируют подтверждение мгновенно для включения механизма быстрой ретрансляции.

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

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

Перегрузка сети может быть предотвращена с помощью использования принципа сохранения пакетов8

8 Принцип сохранения здесь применим к равновесному состоянию

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

[2]: если сеть загружена полностью, то не передавать следующий пакет


52

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

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

ТСР оперирует двумя окнами: одно определяет размер буфера отправителя, другое (CWND) является результатом по-пыток протокола определить пропускную способность сети на данном соединении. Для отправки данных используется минимальное из двух окон. Механизмы Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery [6] являются стан-дартом для современных реализаций ТСР.

Slow Start (замедленный запуск) применяется для по-степенного увеличения скорости передачи информации после открытия соединения или потери пакета. Изначально размер окна CWND устанавливается равным одному сегменту. После получения каждого подтверждения CWND увеличивается на размер одного сегмента. Алгоритм медленного запуска от-ключается, когда происходит потеря сегмента или достигает-ся верхняя граница окна получателя. Время, затрачиваемое для полного открытия окна

WRTTt 2log×= , (1)

где W – размер окна в сегментах. Congestion Avoidance (предотвращение перегрузки) ис-

пользуется для определения наличия дополнительной пропу-скной способности. Обычно этот алгоритм действует совмест-но с алгоритмом медленного старта. Для фиксации момента


53

перехода с медленного старта на предотвращение перегрузки используют переменную SSTHRESH. Эта переменная инициа-лизируется размером максимально возможного окна при от-крытии нового соединения. Медленный старт продолжается, пока значение CWND не достигнет SSTHRESH, после этого ре-жим роста CWND изменяется на линейный, а именно: для каж-дого подтверждения CWND увеличивается на значение 1/CWND.

Fast Retransmit (быстрая ретрансляция). Использует по-следовательное получение подтверждения одного и того же сегмента как признак потери, ретранслирует этот сегмент до срабатывания таймера ретрансляции.

Fast Recovery (быстрое восстановление). После срабаты-вания механизма быстрой ретрансляции ТСР переходит в ре-жим предотвращения перегрузки, а не медленного старта. Пос-ле прихода третьего дубликата подтверждения SSTHRESH ус-танавливается равной ½CWND и отсутствующий сегмент ре-транслируется, CWND устанавливается равным SSTHRESH+3 (количество сегментов, покинувших сеть). Затем на каждое подтверждение CWND увеличивается на размер одного сег-мента. Если размер CWND позволяет, передаются дополни-тельные сегменты. Когда приходит подтверждение, включаю-щее в себя ретранслированный сегмент, CWND устанавливает-ся равным SSTHRESH и ТСР переходит в режим предотвраще-ния перегрузки.

Описанные выше механизмы являются стандартной ча-стью протокола TCP, их применение регламентируется RFC 1323 [6].

Управление таймерами Объекты ТСР концептуально используют несколько

таймеров для выполнения своих функций. Наиболее важным из них является таймер повторной передачи (ТПП). ТПП пе-резапускается каждый раз при отправке сегмента. Если под-тверждение приема сегмента не приходит до срабатывания таймера, то этот сегмент ретранслируется.

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


54

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

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

MRTTRTT ×−+×= )1( αα , (2)

где α - весовой коэффициент, применимый к старому значе-нию (с типичным значением 7/8).

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


55

1.6. Свойство самоподобия сетевого трафика

Традиционная методология: системы массового обслуживания

Традиционной методологией, применяемой для изучения процессов, происходящих в территориально распределенных сетях с большим количеством пользователей, до недавнего времени являлась теория массового обслуживания [9].

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

λµλ−

=N , (3)

где µ - скорость обслуживающего прибора;

λµ −=

1T . (4)

Если же предполагается произвольное распределение длительностей обслуживания требований, то такая система массового обслуживания обозначается M/G/1 и среднее время


56

пребывания требования в обслуживающем приборе выража-ется формулой Поллачека – Хинчина:

)1(2

2

ρλ−

=XW ,

где W – математическое ожидание времени пребывания тре-бования в очереди, Xλµλρ == , если iX - длительность

обслуживания i-го требования, а )( 22XEX = – момент вто-

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

)1(2

2

ρλ−

+=XXT . (5)

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

Критика традиционных моделей трафика С развитием сети Интернет и появлением возможности

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


57

трафик протоколов SMTP, NNTP, что может приводить к гло-бальной синхронизации потоков в сети [92]. Такая ситуация является невозможной для пуассоновской модели, однако имеет место в реальности.

Итак, традиционный подход к моделированию трафика сети с коммутацией пакетов базируется полностью на пред-положении о неограниченности дисперсии процесса поступ-ления пакетов, что позволяет применять теоретический аппа-рат марковских цепей для анализа таких систем. Но развитие современных скоростных сетей передачи данных и мультиме-диа информации с выраженной гетерогенной физической и логической инфраструктурой и большим набором разнооб-разных сервисов и генерируемых ими потоков приводит к по-явлению существенно более сложных характеристик потоков. Тр афик в таких сетях имеет явно выраженный всплесковый характер, не сглаживаемый усреднением по длительным вре-менным промежуткам и большому числу потоков. Традици-онный подход к моделированию трафика изменялся путем разработки все более сложных стохастических моделей: Fluid Flow Models, Markov Modulated Poisson Processes, Markovian Arrival Processes, Batched Markovian Arival Processes и т.д. Основной целью разработки всех этих моделей являлось со-хранение возможности аналитического подхода к исследова-нию задач управления очередями и эффективностью системы. Однако авторы обзора [93] отмечают, что статистические свойства стохастических моделей не совпадают со свойства-ми экспериментальных данных по сетевому трафику. Причи-ной того, что стохастический анализ применялся в течение длительного времени, был недостаток эмпирических данных. Сейчас в экспериментальных данных и модельных экспери-ментах нет недостатка – получено большое количество набо-ров данных по трафику в территориально распределенных се-тях , в ЛВС, для р азличных технологий канального уровня и для разнообразных протоколов прикладного уровня, для TCP/IP и ATM сетей.

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


58

Анализ экспериментальных данных Исследование большого объема данных по трафику с

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

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

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

На настоящий момент, согласно авторам работы [93], не существует аналитического аппарата, применимого к процес-сам, характеризующимся свойством самоподобия.

Для того чтобы определить наличие характеристик са-моподобия у больших последовательностей результатов из-мерения трафика, применяются несколько статистических ме-тодов: R/S статистика, дисперсионно-временной анализ, ме-тод спектральных областей и другие [94].

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

В работе [95] даются принятые на сегодня определения и признаки самоподобных (монофрактальных) и мультифрак-тальных процессов следующим образом.


59

Определение. Процесс с непрерывным временем }),({ TttYY ∈= является самоподобным (с параметром са-

моподобия H), если он удовлетворяет условию: 10,0,),()( <≤>∀∈∀−

=HaTtatYatY Hd (6)

(равенство в том смысле, что два процесса имеют одинаковые распределения). Коэффициент H называется коэффициентом, или параметром, Херста и является мерой самоподобия.

Существуют также несколько признаков самоподобия. Признак 1. Пусть дана стационарная последователь-

ность }1,)({ ≥= iiXX и пусть

∑+−=

=km

mki

m iXm

kX1)1(

)( )(1)( , k = 1, 2, …, (7)

является соответствующей X агрегированной последователь-ностью с уровнем агрегирования m. Последовательность

)()( kX m получена путем разбиения исходной последователь-ности X на непересекающиеся блоки размера m и усреднени-ем по каждому блоку. Индекс k нумерует блоки. Если X явля-ется процессом приращения самоподобного процесса Y, оп-ределенного в (6), т. е. X(i)=Y(i+1)-Y(i), то для всех целочис-ленных m

)(1 mH XmX d −=

. (8)

Стационарная последовательность }1,{ ≥= iXX i явля-ется самоподобной в точности, если она удовлетворяет выра-жению (7) для всех уровней агрегирования m. Стационарная последовательность }1,{ ≥= iXX i считается асимптотиче-ски самоподобной, если условие (7) выполняется при

∞→m . Еще один признак самоподобия [95] дается через пове-

дение абсолютных моментов. Признак 2. Положим

qm

i

qmm iXm

EXEq ∑=

==1

)()( )(1||)(µ . (9)


60

Если X обладает свойством самоподобия, то )()( qmµ пропорционален )(qmβ , т. е. )](log[ )( qmµ линеен относитель-но ]log[m для фиксированных значений q:

)(]log[)()](log[ )( qCmqqm += βµ ; (10) )(qβ также линейна по отношению к q. Действительно, по-

скольку )()( 1)( iXmiX Hm d −

=, то )1()( −= Hqqβ . (11)

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

)(qβ должна удовлетворять условию (11). Стационарная по-следовательность не может быть точно или асимптотически самоподобной, если ее среднее значение отлично от нуля.

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

Признак 3. Неотрицательный процесс X(t) является мультифрактальным, если логарифмы абсолютных моментов масштабируются линейно с логарифмом значения уровня аг-регирования m. В отличие от самоподобного процесса здесь не налагается требований на линейность )(qβ относительно q. Самоподобные процессы, таким образом, являются част-ным случаем мультифрактальных.

Причина свойств самоподобия Интернет-трафика Причиной наличия свойства самоподобия, как показано

в работах [97, 98], является распределение ON периодов, имеющее тяжелый хвост (убывающий гиперболически).

Авторы [97] предлагают разделять объяснения причин самоподобия трафика в больших и малых временных диапа-зонах. Так, самоподобие LAN и WAN трафика в масштабах порядка секунды и более объясняется и математически дока-зывается в [98]. Однако для полного понимания динамики се-тевого трафика необходимо исследовать причины мульти-фрактальных характеристик трафика в масштабах менее од-ной секунды, в котором поведение трафика особенно дина-


61

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

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

i отправляет пакеты с постоянной скоростью в период ON и не отправляет пакетов вообще в период OFF. Такое поведение ЛВС было рассмотрено в [100] как обмены типа "запрос-ответ". С другой стороны, для территориально распределен-ных сетей, например сети Интернет, индивидуальные соеди-нения ассоциируются с сессиями, устанавливаемыми транс-портным протоколом типа TCP. Каждая такая сессия инициа-лизируется в некоторый случайный момент времени, осуще-ствляет передачу в течение некоторого времени с постоянной скоростью, а затем отключается. Каждая сессия обслуживает то или иное приложение, реализующее свой протокол при-кладного уровня, например FTP[DATA], TELNET, NNTP, SMTP, HTTP. Для периодов длиной до 1 часа было показано, что процесс инициализации сессий в сетях является пуассо-новским [91]. Для анализа трафика в большом временном масштабе только характеристики самих сессий важны для по-строения модели, в то время как индивидуальные процессы прибытия пакетов в рамках каждой сессии не рассматривают-ся. Для полного описания процесса счетчика общего трафика необходимо рассмотреть распределение длительностей сессий или ON/OFF периодов. Данные реальных наблюдений за по-токами в LAN и WAN [91 , 100] дают основание утверждать, что распределение длин ON/OFF периодов имеет бесконеч-ную дисперсию и тяжелый хвост.

Положительная случайная величина U с функцией рас-пределения F имеет распределение с тяжелым хвостом с ин-дексом хвоста α > 0, если выполняется:


62

α−≈−=> cyyFyUP )(1][ при ∞→y , (12) где с – положительная конечная константа, не зависящая от у. Выражение (12) описывает гиперболическое или степенное распределение, частным случаем которого является хорошо известное распределение Парето [91, 97]. В работе [98] дока-зывается тот факт, что распределение длительностей перио-дов ON/OFF, спадающее гиперболически или по степенному закону (выражение 13) при больших значениях количества потоков и длительном времени наблюдения, определяет на-личие свойства LRD суммарного потока с параметром Херста

2)3( α−=H . (13) Авторы доказали, что отклонение от среднего значения

представляет собой дробный гауссовский шум (Fractional Gaussian Noise) – классический пример в точности самопо-добного процесса. Таким образом, в больших временных масштабах (асимптотическое) самоподобие сетевого трафика является следствием свойств сессий обмена (ON/OFF перио-дов), а именно того, что длительности этих периодов имеют распределение с тяжелым хвостом. Поэтому в больших мас-штабах самоподобие трафика не зависит от инфраструктуры сети или ее протоколов, а определяется набором информаци-онных объектов, передаваемых по этой сети. Дальнейшее раз-витие этой гипотезы дано в [99], где показано, что причиной наличия тяжелых хвостов в распределении длительностей ON периодов является соответствующее распределение размеров объектов в WWW – доминантной информационной системы в сети Интернет. В [99] наблюдения за реальным http-трафиком и файлами отчета крупнейших WWW-серверов показывают наличие связи между гиперболическим распределением раз-меров информационных объектов WWW и гиперболическим распределением длительностей http-сессий, трафик которых составляет более половины всего Интернет-трафика (по ре-зультатам множества исследований). Таким образом, трафик с малым разрешением по времени адекватно моделируется са-моподобными или асимптотически самоподобными процес-сами согласно результатам [95, 97, 100].


63

Трафик с высоким разрешением по времени Возвращаясь к высокодинамичному поведению сетево-

го трафика в малых временных масштабах, авторы [97] ука-зывают на то, что причинами появления свойства LRD трафи-ка в этих условиях являются свойства самих транспортных протоколов, управляющих потоками. Поскольку эти алгорит-мы отвечают непосредственно за диспетчеризацию индивиду-альных пакетов в рамках отдельных соединений, то вызывае-мые ими выраженные локальные нерегулярности трафика не являются связанными с самоподобными свойствами трафика в более грубом временном масштабе. Так, при малом времен-ном разрешении Интернет-трафик наиболее качественно опи-сывается именно мультифрактальными процессами [96].

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

Методы определения меры самоподобия Для оценки меры самоподобия трафика ARTCP нами

применены два метода - метод R/S статистики и метод Aggregated Variance. Оба метода относятся к числу хорошо изученных и успешно применяются в целом ряде работ [94].

Метод R/S статистики Для последовательности }1,{ ≥= iXX i с частными

суммами ∑=

=n

iiXnY

1

)( и дисперсией

∑=

−=n

ii nYnXnnS

1

2222 )()1()1()( R/S статистика (Rescaled

Adjusted Range) определяется выражением:

−−−=

≤≤≤≤

))()(())()(()(

1)( minmax00

nYnttYnY

nttY

nSn

SR

ntnt .

(13) Поскольку для FGN выполняется свойство:

HH nCnSRE ~)]([ при ∞→n , (14)


64

то для определения коэффициента H по методу R/S применя-ется следующий алгоритм:

последовательность длиной N разбивается на K блоков размером KN , затем для каждого значения n вычисляется

),(),(

nkSnkR

i

i . ik начальный номер элемента последователь-

ности 1+= KiNki , i = 1, 2, …, но таких, что Nnki ≤+ . Та-ким образом, получаем для значений n < N/K K оценок

)()( nSnR , при этом по мере роста n число получаемых оце-нок для каждого n уменьшается.

Если построить график зависимости )],(),(log[ nkSnkR ii от ]log[n , то параметр H вычисляется

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

Метод Aggregated Variance Если исходную последовательность }1,{ ≥= iXX i

разбить на блоки размера m и произвести усреднение по каж-дому блоку k, то получим агрегатную последовательность:

∑+−=

=km

mki

m iXm

kX1)1(

)( )(1)( (15)

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

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

2/

1

)(/

1

2)()( )(1)]([1

−= ∑∑

==

mN

k

mmN

k

mm kXmN

kXmN

VarX . (16)


65

Повторяя эту процедуру для различных значений m (m<<N), можно построить график зависимости ]log[ )(mVarX от log[m]. По полученным точкам аппроксимируем прямую и по углу ее наклона определяем коэффициент H.

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

Общие принципы Управление потоками в коммуникационных сетях озна-

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

В состав протокола TCP входит большое число разнооб-разных механизмов, которые отвечают за различную функцио-нальность и находятся в определенном взаимодействии между собой в силу концептуально-необходимой связи или связи, воз-никшей при реализации. На рис. 14 приведена схема основных механизмов, входящих в состав самой распространенной реа-лизации протокола TCP – Reno в составе 4.4 BSD UNIX [64].

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

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


66

Изучение систем управления потоками и предотвраще-

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

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

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

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

в составе стандартного протокола TCP


67

Рис. 15. Зависимость характеристик сети

от нагрузки. Пропускная способность (вверху), время задержки

(в середине), мощность сети (внизу)

и объему передаваемой информации. С другой стороны, все физические ресурсы сети имеют ограниченную мощность и должны быть управляемыми для достижения оптимального общего использования многими сессиями обмена данными. Более формальное описание состояния перегрузки сети мож-но получить, рассмотрев производительность ее работы в за-висимости от нагрузки (рис. 15). Мерой производительности может служить мощность, определенная как

RTTWP /= . (17) После достижения

сетью насыщенного со-стояния (точка А) пропу-скная способность пере-стает расти, а время отве-та (RTT) продолжает, по-скольку происходит за-полнение буферов внутри сетевых устройств. Мощ-ность сети достигает пика в точке А – это оптималь-ный режим работы сети.

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


68

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

Управление задержкой сети Задержка данных при их передаче по сети состоит из

двух компонентов: qT DDD += , (18)

где TD есть время, затрачиваемое пакетом на прохождение по элементам физической инфраструктуры линии связи, зави-сящее лишь от скорости распространения электромагнитных волн в той или иной среде, а qD определяется временем, ко-торое пакет проводит в очередях маршрутизаторов, ожидая обслуживания. Например, для межконтинентального канала [6] протяженностью 5 000 км задержка распространения сиг-нала составит 0.0167 с, в то время как задержка, связанная с очередями в буферах маршрутизаторов, может составлять не-сколько секунд в реальной системе. Для передачи мультиме-диа информации очень важно, чтобы значение задержки и ее дисперсия для индивидуальных пакетов были минимальными. Это требование выражается в требовании минимальности очередей в маршрутизаторах.

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

Алгоритм RED Поскольку средствами одного протокола TCP обеспе-

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


69

зации такого управления используется алгоритм случайного раннего обнаружения (Random Early Detection – RED) [18].

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

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

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

Альтернативные схемы управления потоком

TCP VEGAS Vegas представляет собой улучшенную реализацию

протокола TCP по сравнению с распространенными реализа-циями Tahoe и Reno. Улучшения, предложенные в системе Vegas [14, 15], затрагивают в основном механизм быстрой ретрансляции. В алгоритме Vegas используется более точный способ определения необходимости быстрой ретрансляции


70

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

Таким образом, Vegas лучше, чем TCP, реагирует на си-туации, в которых происходит потеря более чем одного сегмен-та в пределах окна и с которыми не может эффективно бороть-ся стандартный механизм ускоренной ретрансляции [19 – 21]. Также в рамках этого механизма Vegas более точно управляет размером окна в процессе ретрансляции. Для реализации кон-троля перегрузки алгоритм Vegas сохраняет значение мини-мального RTT в переменной BaseRTT=min(BaseRTT, RTT). Ожидаемое значение пропускной способности опреде-ляется по формуле Expected=размер_окна/BaseRTT. Далее реальная пропускная способность периодически вы-числяется как количество байтов, переданных с момента от-правки определенного сегмента и до прихода его подтвер-ждения. Разность реальной и ожидаемой пропускной способ-ности определяет выбор режима линейного увеличения или уменьшения окна.

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

TRUMP Данный механизм разработан в докторской диссертации

Тумей [22], и в него входит не только спецификация транс-портного протокола, но и целая система управления потоком на сетевом уровне. Эта система включает в себя механизм из-мерения загрузки узлов с явной реверсивной обратной связью и собственный формат данных. Интересным аспектом систе-мы TRUMP является то, что скорость отправки данных в сеть регулируется не скользящим окном, а значением разрешенной скорости, задаваемым сетевыми устройствами. К недостаткам данной системы нужно отнести тот факт, что системы с явной передачей контрольной информации существовали и ранее [23 – 25]. Попытки реально внедрить такие системы для сети Интернет не имели успеха, поскольку это потребовало бы введения дополнительных функций маршрутизаторов, в то


71

время как TRUMP предусматривает не только существенное изменение сетевых устройств, но и полное отсутствие совмес-тимости с архитектурой TCP/IP.

PP (Packet Pair Flow Control) Управление потоком по методу Packet Pair Flow Control

[26] представляет собой оригинальную идею измерения дос-тупной пропускной способности сети. Схема предназначена для сетей с виртуальными каналами, которые изолируют транспортные потоки при помощи диспетчера квотированно-го обслуживания (ДКО) очередей [27 – 29]. Мотивация для создания такой схемы управления потоками в том, что пре-доставление интегрированных сервисов становится домини-рующим направлением в современной сетевой парадигме. Со-гласно ей сети должны одновременно обслуживать стабиль-ные потоки с постоянной скоростью передачи данных одно-временно с потоками, работа которых характеризуется вспле-сками и неравномерностью. Первый тип обменов должен по-лучать обслуживание от сети с гарантированным качеством, а второй тип трафика – использовать оставшиеся ресурсы. Это основная концепция построения сетей с интеграцией сервисов [30]. Для ее реализации межсетевые устройства должны при-менять один из алгоритмов равноправного обслуживания очередей. Как правило, это алгоритм взвешенной равноправ-ной диспетчеризации WFQ [28].

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

NRR b /= , (19)


72

где bR - скорость самого интерфейса, а N – количество оче-редей на нем. Некоторые очереди могут иметь приоритет по отношению к другим. На каждом таком сервере соединение обслуживается с некоторой скоростью независимо от других соединений. Все СПС на пути соединения пронумерованы числами 1, 2, 3, …, n. Получатель подтверждает каждый па-кет. Время обслуживания на i-том сервере обозначим )(tsi , а мгновенная скорость обслуживания тогда будет

)(/1 tsii =µ . (20) Время )(tsi есть интервал обслуживания всех осталь-

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

)0|)(max()( nitsts ib ≤≤= , (21) где b – индекс ограничивающего СПС.

)(/1)( tst bb =µ есть скорость ограничивающего СПС, которая изменяется с изменением числа активных потоков в сети. Авторы моделируют эти изменения как происходящие через дискретные интервалы 1, 2, …, k, k+1, … . Если число активных потоков acN велико, то можно ожидать, что

acac NN <<∆ за один интервал, т. е. значение )(kbµ близко к )1( +kbµ . За счет этого определяется

)0),()(max()1( kkk bb ωµµ +=+ , (22) где )(kω – случайная переменная.

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

bµ и вычисляет необходимую на новом шаге скорость пере-дачи )1( +kλ в соответствии с принципом сохранения длины очереди в ограничивающем СПС. В [26] также доказывается


73

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

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

NETBLT Протокол NETBLT [33, 34] разработан с целью предос-

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

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

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

Таким образом, протокол NETBLT способен обеспечить хорошие результаты при работе по каналам, характеризую-щимся большим значением RTT*BW. Однако NETBLT не сво-боден от недостатков, присущих TCP: например, оба прото-кола интерпретируют потерю пакета как признак перегрузки, что неверно в общем случае.


74

Tri-S Алгоритм Slow Start and Search (Tri-S) [35] основан на

механизме замедленного старта протокола TCP. Авторы про-анализировали недостатки замедленного старта и попытались устранить неприемлемо высокую амплитуду осцилляций раз-мера окна, которая приводит к большому числу потерь и зна-чительному увеличению связанного с буферизацией пакетов в сети компонента задержки qD и к высокой дисперсии изме-рений времени RTT. Кроме того, авторы работы [35] показа-ли, что схема управления потоком TCP позволяет обменам с меньшим числом промежуточных узлов (и, соответственно, меньшим средним значением RTT) в среднем использовать большую долю пропускной способности, чем потокам с большим RTT.

В [35] предложено использовать так называемый нор-мализованный градиент пропускной способности (НГПС) и интерпретировать изменение в пропускной способности (ПС) как сигнал о перегрузке или наличии резерва ПС в сети. Ал-горитм Tri-S вычисляет НГПС по формулам:

1

1)()()(−

−

−−

=NN

NNN WW

WTWTWTG (23)

)()()(

1WTGWTGWNTG N

N = (24)

где )( NWTG – ненормированный ГПС, NW – размер окна, )( NWNTG – НГПС при значении окна NW , а )( NWT –

скорость, когда размер окна равен NW . Интервал значений НГПС: [0,1]. В сети с небольшой нагрузкой 1≈NTG , по мере приближения нагрузки к суммарной ПС сети НГПС прибли-жается к 0. Средняя скорость передачи данных вычисляется по времени обращения n-го пакета:

N

NNN RTT

WWT =)( (25)


75

Сравнивая значения НГПС с двумя предельными значе-ниями, алгоритм Tri-S принимает решение об уменьшении или увеличении размеров окна.

По результатам моделирования схема Tri-S позволяет улучшить показатель справедливости деления ПС по сравне-нию с TCP. Однако выбор предельных значений оказывает сильнейшее влияние на стабильность системы. Кроме того, как и стандартный TCP, схема Tri-S интерпретирует потерю пакета как признак перегрузки.

DUAL Данный метод был предложен как способ устранения

проблем с осцилляцией окна, наблюдаемых с алгоритмом за-медленного старта [36]. DUAL использует изменение изме-ряемого RTT вместе с отслеживанием потерь пакетов для оп-ределения перегрузки.

Поскольку qT DDD += , то TDRTT 2min =9

RQDDDRTT TqT /maxmax +=+=

, в то время как

(26) где maxQ – максимальная длина очереди, а R – скорость об-служивания очереди. Алгоритм DUAL постоянно вычисляет минимальное и максимальное значения RTT и, сравнивая их с предельным значением iRTT , увеличивает или уменьшает скорость передачи.

maxmin)1( RTTRTTRTTi ×+×−= αα (27) где α <1( предлагается использовать значение 0.5).

От алгоритма медленного старта DUAL отличается тем, что с периодичностью 2RTT он сокращает значение окна на 7/8, если iRTTRTT > . Значение iRTT обновляется с каждым измерением RTT. Кроме того, минимальное и максимальное

9 Минимальное RTT пропорционально величине задержки. Посколь-

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


76

RTT устанавливаются в ∞ и 0 соответственно при срабаты-вании ТПП.

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

Выводы Каждый из этих методов обладает определенными не-

достатками и не применяется в стандартных протоколах. Главный недостаток Vegas, Tri-S, DUAL в том, что в них ис-пользуется протокол TCP, который реагирует на потерю сег-мента снижением скорости, а в отсутствие потерь линейно увеличивает нагрузку на сеть, приводя к переполнению буфе-ров. Схема TRUMP предполагает расширение функциональ-ности маршрутизаторов механизмом, уведомляющим источ-ники о перегрузке в явном виде, что означает отход от пара-дигмы сетей с пакетной коммутацией. PP предлагает эффек-тивный способ измерения загрузки сети, однако непримени-мый для TCP/IP, поскольку предполагает работу в сети с вир-туальными каналами на сетевом уровне.

Принципы AIMD и STA Большинство алгоритмов управления потоками разли-

чаются способом определения наступления состояния пере-грузки и реагируют на изменения состояния сети путем адди-тивного (линейного) увеличения нагрузки и мультипликатив-ного сброса в случае определения наступления перегрузки. В литературе такой подход получил название Addititve Increase and Multiplicative Decrease (AIMD). Обоснования применения принципа AIMD изложены в работе [2].

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

2/RTTDT ≈ , когда сеть не перегружена. В этом случае мо-


77

дель сети проста: NLi = , где L – показатель загрузки (на-пример, средняя длина очередей), а N – константа. Если же сеть подвержена перегрузке, то модель изменяется. Теперь

1−+= ii LNL γ , (28) где γ определяет влияние трафика за прошлый период, а также последствия потерь, т. е. наличие в сети ретранслиро-ванных данных. Когда сеть находится в состоянии перегруз-ки, γ велико и длина очередей растет экспоненциально, по-скольку из 1−≈ ii LL γ следует 0LL n

n γ= . Вследствие этого система может стабилизоваться, только если источники тра-фика в сети могут уменьшать скорость его генерации также экспоненциально. Таким образом, получается, что при пере-грузке размер окна W должен изменяться по закону:

1−= ii dWW , (29) где 0 < d < 1. Это и есть мультипликативный сброс, который превращается в экспоненциальный, если перегрузка продол-жается в течение нескольких периодов обновления окна TD .

В случае отсутствия перегрузки сеть никак не сообщает соединениям о наличии дополнительных ресурсов, в связи с этим в отсутствие сигналов о перегрузке соединения должны увеличивать нагрузку до тех пор, пока потеря пакета не со-общит о начале перегрузки. Экспоненциальный рост всегда приводит к новой перегрузке, поэтому автор [2, 44, 45] реко-мендует линейный рост или аддитивное увеличение:

uWW ii += −1 , maxWu << , (30) где BWDW T ×=max - произведение задержки передачи и пропускной способности канала.

1.8. Недостатки протокола TCP Из числа наиболее существенных недостатков протоко-

ла TCP в области управления потоками отметим следующие. К основному недостатку протокола TCP следует отне-

сти проблему не столько реализации протокола, сколько са-


78

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

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

В большинстве условий протокол TCP осуществляет отправку данных очень неравномерно. Фактически все дан-ные в пределах окна отправляются за небольшое время в виде всплеска пакетов [46]. Неравномерный режим отправки паке-тов приводит к повышению числа потерь. Поскольку средняя длина очередей в сетевых устройствах близка к максималь-ной, то вероятность потери сегментов в пределах всплеска повышается.

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


79

Это относится к таким асимметричным системам, как «спут-никовый/наземный каналы», «кабельный модем/коммути-руемое соединение».

Поскольку недостатки TCP широко известны, то мно-жество работ было посвящено созданию отдельного транс-портного протокола для асимметричных инфраструктур [51] или беспроводных сетей [47 – 50]. Большинство предлагае-мых протоколов не являются совместимыми с TCP и требуют наличия агентов-посредников транспортного уровня. Тем са-мым нарушается основной постулат Интернета, заключаю-щийся в то м, что сеть до лжна обеспечивать беспрепятствен-ную связь на транспортном уровне между непосредственны-ми участниками обмена. Также излишне усложняется вся структура сети.

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

Цель Итак, нашей задачей было создание нового механизма

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

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


80

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

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

кол ARTCP. Имеется сеть, в топологическую схему которой входят несколько узлов, два маршрутизатора и набор каналов, соединяющих узлы (рис. 16). На каждом узле исполняется объект протокола ARTCP. Узлы объединены в две локальные вычислительные сети (ЛВС), каждая из которых подключена к одному маршрутизатору. Маршрутизаторы связывают ло-кальные сети, передавая трафик по каналу с малой ПС и большим значением задержки.

Каждый из узлов в одной из ЛВС отправляет сегменты

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

Рис. 16. Формальная модель исследуемой сети. Стрелками указано направление передачи данных


81

ляет скорость передачи. Эта скорость задается алгоритмом управления потоком ARTCP. Предполагается, что источники потоков всегда имеют информацию для отправки. Источники и приемники трафика находятся в разных ЛВС. Приемники трафика ARTCP отправляют подтверждения в противополож-ном направлении в виде сегментов, не содержащих данных.

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

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

SBER)1(1 −− в зависимости от вероятности ошибки при пе-редаче.

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

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

- относительное число потерь сегментов (отношение числа потерянных к общему числу отправленных сег-ментов); - коэффициент использования пропускной способно-сти каналов

времяканаласкоростьбитовпринятыхчислоU×

=)_(__ (отношение


82

числа успешно принятых битов к максимально воз-можному их числу); - коэффициент равноправия разделения ресурсов

)()(1

22

1∑∑==

×=n

ii

n

ii bnbF , где ib есть доля пропускной

способности, занятая i-м соединением; - средняя длина очереди Q в маршрутизаторе R1.

Сравнение ARTCP и TCP будет производиться по этим основным характеристикам.

Приведенные выше характеристики протокола являют-ся стандартными и используются во многих исследованиях протоколов [73].

Сеть как самоорганизующаяся система Определение самоорганизующейся системы в смысле

Г. Хакена следующее: система с большим числом степеней свободы, под воздействием сложных внутренних сил перехо-дящая в состояние с существенно меньшим числом степеней свободы (параметрами порядка), называется самоорганизую-щейся [132]. Хаотическое поведение системы на уровне от-дельных компонентов приводит к детерминированному пове-дению ее средних величин.

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


83

Глава 2. Алгоритм ARTCP

Предлагаемый в данной книге новый протокол Adaptive Rate Transmission Control Protocol (ARTCP) заимствует некоторые ме-ханизмы от протокола TCP. В ARTCP полностью пересмотрен ал-горитм управления потоком, который и отличает его от TCP. Вме-сте с тем предлагаемый протокол может обеспечивать совмести-мость с TCP.

2.1. Особенности протокола ARTCP ARTCP отличается от стандартного TCP тем, что сегменты

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

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

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

10 Скважность – длительность межпакетных (сегментных) временных ин-

тервалов.

потока у получателя и изменения времени RTT. Потеря пакета никак не отражается на работе ARTCP, кроме осуществления ретрансляции потерянного пакета механиз-


84

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

Таким образом, по сравнению со своим предшественником ARTCP обладает следующими преимуществами:

подтверждений одних и тех же данных.

- ARTCP не требуется доводить сеть до состояния перегруз-ки, чтобы определить доступную долю ПС, поэтому исключены потери пакетов, связанные с этим процессом;

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

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

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

Эвристика в основе алгоритма ARTCP Анализ работ в области транспортных протоколов и, в част-

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

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

11 В TCP механизм ускоренной ретрансляции активируется получением трех дубликатов подтверждения.


85

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

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

Параметры и переменные Пусть t – временной интервал между последовательными

трансляциями пакетов. Задача функции диспетчеризации сегмен-тов в том, чтобы задерживать отправку очередного сегмента на время ts после начала передачи предыдущего сегмента. Пометим все переменные, относящиеся к отправителю, индексом s, а отно-сящиеся к получателю – индексом r. Итак, ts - временной интервал между моментами начала отправки в сеть сегмента i+1 и i-го, а tr - интервал между последовательно прибывшими к получателю сег-ментами.

Пусть скорость канала связи, непосредственно к которому подключен отправитель, lsR , тогда время, уходящее на отправку одного сегмента (с момента начала передачи до момента ее окон-чания), lsls RSt /= , где S – размер передаваемого сегмента. Оче-видно, что максимально возможная скорость потока


86

slss SRR minmax /τ== . (31) Минимальное значение межсегментного интервала в этом

случае будет lss t=minτ , когда пакеты отправляются в сеть без за-держек с максимальной скоростью канального уровня. Путем из-менения sτ в пределах [ min

sτ ,∞ ) ARTCP может контролировать скорость потока в пределах [ lsR , 0). Иллюстрация принципа управления скоростью приведена на рис. 18.

Задержка отправки готовых сегментов производится с по-мощью системного таймера. Например, для полного использова-ния ПС канала в 512 Кб/с при размере сегмента в 1 000 байтов ка-ждый сегмент необходимо отправлять с задержкой ts = 0.015625 с, чтобы скорость потока составила 64 пакета/с.

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

Таблица 1

Переменные и параметры модели ARTCP

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

Sτ Временной промежуток между последовательными трансля-циями сегментов (от первого бита до первого бита)

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

)(tRS Скорость потока, устанавливаемая отправителем

)(tRR Скорость потока, вычисляемая получателем

)(tRe Оценка доступной пропускной способности в момент t-RTT

SR' Первая производная скорости по времени (устанавливается отправителем)

peR

Значение оценки доступной пропускной способности в мо-мент i-1

CA Площадь области компенсации

SSGR Параметр экспоненциального роста SR' в режиме SS RTT Временной промежуток между моментом отправки сегмента

и моментом прихода его подтверждения


87

ERTT Взвешенное скользящее среднее RTT SmoothedRe Взвешенное скользящее среднее Re MaxERTT Максимальное значение сглаженного RTT MinERTT Минимальное значение сглаженного RTT MDFACTOR

Коэффициент, используемый при мультипликативном сни-жении )(tRS

amdsR

Значение скорости отправки данных непосредственно на выходе режима MD1

bmdsR

Значение скорости отправки данных непосредственно перед входом в режим MD1

amdeR

Значение оценки доступной пропускной способности в ре-жиме MD1

speedup Коэффициент, определяющий вероятность увеличения ско-рости в режиме FT

Slowdown Коэффициент, определяющий вероятность снижения скоро-сти в режиме FT

Midpoint Точка отсчета скорости на каждом шаге в режиме FT

ssR Взвешенное скользящее среднее значение sR K Коэффициент критерия осуществления перехода 6 BER Bit error ratio – резидентная вероятность инвертирования би-

та на линии minsR

Начальное минимальное значение скорости, с которого на-чинается рост в состоянии SS

Формат сообщения Формат сообщений, используемых ARTCP, может в точно-

сти совпадать с форматом пакета TCP (рис. 8). Стандарт TCP [4] предусматривает наличие дополнительных полей в заголовке сег-мента между стандартным заголовком и полем данных. ARTCP может передавать дополнительную информацию в этих полях, что будет гарантировать совместимость с TCP. Всего протокол ARTCP требует использования лишь двух новых полей: значения преды-дущего порядкового номера “PS” в направлении от отправителя к получателю и значения скважности “TI” в направлении от получа-теля к отправителю. Значение “TI” можно передавать в виде опции временной метки [6], а значение “TI” требует поля, позволяющего поместить порядковый номер сегмента.


88

2.2. Структурная схема ARTCP В протоколе ARTCP полностью переработаны все механиз-

мы управления потоком. Механизм коррекции ошибок передачи в ARTCP не влияет на скорость передачи. От TCP сохранены окон-ный механизм для управления загрузкой получателя, алгоритмы определения RTT и установки таймера ТПП. Признаком потери сегмента служит срабатывание ТПП или приход двух последова-тельных подтверждений одного сегмента. Алгоритм управления скоростью включает в себя функции диспетчеризации сегментов, измерения скорости и адаптации скорости (рис. 17). Далее рас-смотрим эти функции подробно.

В задачи функции диспетчеризации сегментов входит от-

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

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

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

Рис. 17. Функциональная схема механизма управления потоком ARTCP. Жирная стрелка вверху обозначает направление пере-

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


89

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

ARTCP использует два признака начала перегрузки сети, ко-гда средняя скорость прибытия запросов сравнивается со средней скоростью обслуживания и началом роста очереди: начало роста RTT и стабилизацию Rr (t) при увеличении Rs (t). Получатель ARTCP в сегментах с подтверждениями указывает значение ско-рости прибытия потока. Получая подтверждение сегмента спустя время RTT после его отправки, источник ARTCP получает инфор-мацию о значении скорости, с которой поток, содержащий этот сегмент, прибыл к получателю, и использует Rr (t) в качестве оцен-ки Re (t) ПС сети.

Диспетчеризация сегментов Диспетчер сегментов отправляет сегменты на линию через

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

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

жет быть выше скорости обслуживания потока на участке с наи-меньшей ПС, через который проходит соединение. Таким образом, зная скорость прибытия потока к получателю, можно определить доступную пропускную способность сети. Для корректного изме-рения скорости необходимо не учитывать выпавшие из потока по-терянные сегменты, а также сегменты, доставляемые сетью в из-мененном порядке. Для выполнения этого условия в поле “PS” ка-ждого отправляемого сегмента записывается порядковый номер (или смещение) от предыдущего сегмента.

Получив сегмент i, получатель вычисляет разницу текущего времени и времени прибытия предыдущего (j) сегмента tr и в слу-чае, если поле “PS” i-го сегмента содержит значение j, помещает Rr = S / tr в поле “TI” подтверждения следующего в противопо-ложном направлении (рис. 18). Получатель извлекает значение по-ля “TI” из получаемых подтверждений и использует его для управления скоростью передачи.


90

Функция адаптации Описание алгоритма работы функции адаптации, непосред-

ственно осуществляющего управление потоком ARTCP, было дано в работах [52 – 54, 76].

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

Работа ARTCP начинается с режима быстрого увеличения скорости, аналогичной механизму замедленного старта стандартно-го TCP, для максимально быстрого достижения соединением верх-него предела доступной пропускной способности. После того как верхний предел достигнут, алгоритм ARTCP переходит в режим точной настройки, в течение которой удерживает скорость на уров-не доступной ПС. В случае определения уменьшения доступной ПС ARTCP совершает мультипликативное снижение скорости, которое в случае продолжительного состояния перегрузки продолжается экспоненциально. Итак, адаптация скорости передачи потока про-токолом ARTCP происходит в пяти режимах (рис. 19).

Рис. 18. Диспетчеризация сегментов и измерение скорости потока

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

ветствует более длительное время передачи


91

Режим ускоренного старта (SS) имеет цель максимально бы-

стро увеличить скорость потока от минимального значения до зна-чения, равного или превосходящего ПС канала, сразу после ини-циализации соединения. Для этого скорость увеличивается экспо-ненциально:

SSGRtRRTTtR SS ×=+ )(')(' (32) )()(')()( 11 −− −×+= iiiSiSiS tttRtRtR (32а)

Рис. 19. Диаграмма режимов алгоритма адаптации протокола

ARTCP. Штриховые линии обозначают возможные переходы в состояние остановки системы


92

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

minRTTmin SEGSIZERs =

(33) Выход из режима SS происходит, когда

)()1()( RTTtRtR iSie −×−< ε . После реализации перехода 2 ал-горитм переходит в состояние мультипликативного сброса MD1.

Режим мультипликативного сброса (MD1) следует за режи-мом SS. После выхода из SS значение )(tRs будет превышать

)(tRe , поэтому в режиме MD1 скорость потока скачкообразно ус-танавливается заведомо ниже )(tRe :

))()(()()( 1 ieisieis tRtRMDFACTORtRtR −×−= − . (34) После снижения скорости алгоритм переходит в режим вос-

становления. Режим восстановления (REC) имеет целью, линейно увели-

чивая скорость, довести ее до уже известного значения ПС канала )(tRe , компенсируя возникшую в режиме SS перегрузку. В режи-

ме REC вычисляется значение площади области компенсации )( ic tA как площади фигуры, образованной значениями )(tRs над

прямой )( ie tR за время, пока )(tRs > )( ie tR в режиме SS, а имен-но значение площади области компенсации равно сумме площадей набора трапеций, образованных значениями )(tRs над прямой

)( ie tR . Площадь каждой трапеции

))(2)(')(2(2 ieiisisi

T tRttRtRtS −∆×−∆= (35)

где it∆ – время, в течение которого не происходило изменений значения )(' is tR .

+−∆−∆= )](2)(')(2[21)( 00 ieisisic tRtRttRttA

+−−−+ )]()(')(')(2[21

ieisis

is tRSSGR

tRRTTSSGR

tRtRRTT


93

+−−−+ )]()(')(')(2[21

22 ieisis

is tRSSGR

tRRTTSSGR

tRtRRTT …

Nis

ieNis

is

SSGRtR

tRSSGR

tRtR

)('

)]()(')([

21

2−−+

(36) где 0t∆ – промежуток времени между моментом it и моментом предыдущего изменения )(' tR s и N – индекс слагаемого, при ко-тором

)()(')( ieNis

is tRSSGR

tRtR >− (37)

Итак, первое слагаемое приведенной формулы есть площадь трапеции с высотой, меньшей RTT, последнее слагаемое – пло-щадь треугольника, слагаемые от 2 до N-1 – площади трапеций с высотой, равной RTT.

Например, в случае, приведенном на рис. 20, )( ic tA равна сумме площадей трапеции DCBE и треугольника ABE. Значение

0t∆ равно отрезку ED. Значение )( ic tA применяется для определения величины )(' is tR в состоянии восстановления REC. Идея заключается в том,

что из-за задержки информации о состоянии сети на время RTT в состоянии быстрого увеличения скорости отправки сегментов по-ток вызовет наполнение буферов сети. Пакеты будут накапливать-ся в сети в течение времени, когда скорость отправки сегментов превышает ПС сети (отрезок AD на рис. 20). Пребывание соедине-ния в состоянии восстановления необходимо для того, чтобы сеть справилась с возникшей до уменьшения скорости отправки пере-грузкой. Очевидно, что количество данных, накопившихся в буфе-рах сети, определяется площадью области )( ic tA , поэтому ско-рость отправки сегментов в состоянии REC должна быть снижена таким образом, чтобы площадь фигуры DFG была равна )( ic tA . Скорость в состоянии REC меняется линейно и определяется зна-чением


94

)(2)]()([

)('2

ic

isipeis tA

tRtRtR

−=

(38)

В состоянии REC скорость отправки данных возрастает ли-

нейно от значения, полученного в предшествующей стадии MD1, по закону

)(')( isamdsis tRtRtR ×+= . (39)

Выход из состояния REC (переход 4) осуществляется в том случае, когда

amdes RtR ≥)( . (40)

Режим тонкой настройки (FT) следует за режимом REC, в режиме FT скорость отправки данных медленно подстраивается под ПС канала. Отношение коэффициентов speedup и slowdown в состоянии FT определяет вероятность снижения или повышения скорости на каждом шаге. Коэффициент speedup, отвечающий за повышение скорости, обратно пропорционален скорости данного

Рис. 20. Зависимость скорости от времени в фазе грубой настрой-

ки ARTCP. Закрашенная область, состоящая из ABE и BCDE, есть площадь области компенсации и выражает объем данных,

накопившихся в буфере. Штриховая линия обозначает текущую оценку ПС сети протоколом ARTCP


95

соединения. Коэффициент slowdown, отвечающий за снижение скорости, пропорционален отношению измеряемого RTT к мини-мальному значению RTT. Значение speedup больше при меньших значениях )(tRs , что дает медленным соединениям преимущество для получения доступа к большей относительной доле ПС. Значе-ние slowdown одинаково для всех соединений и растет при росте RTT. Таким образом, вероятность повышения скорости для мед-ленных соединений больше, а вероятность снижения скорости одинакова для всех соединений. Выход из режима FT происходит в случае скачкообразного изменения измеряемого RTT.

В состоянии FT значения скорости передачи определяются по закону:

midpoint]2[midpoint)( ×××−×+= INTERVALslowdownspeedup

speedupslowdownRandtR is

, (41) где rand – равномерно распределенная случайная величина, гене-рируемая функцией drand48() с областью значений [0; 1]. После попадания в состояние FT (реализации перехода 4) значение midpoint устанавливается равным amd

eR , в дальнейшем значение

midpoint устанавливается равным ssR . Переменные speedup и slowdown определяют направление изменения скорости отправки данных в зависимости от изменения времени RTT.

Коэффициенты slowdown и speedup для использования в формуле (41) определяются следующим образом:

2]minRTT

1[ssR

Sspeedup×

+= (42)

где второе слагаемое представляет собой отношение минимально-го количества данных в транзите по соединению (S байтов за вре-мя RTT) к реальному их количеству (произведение минимального времени RTT на среднюю скорость отправки потока). Соответст-венно, рост реальной скорости потока выражается в уменьшении значения коэффициента speedup. Таким образом, при прочих рав-ных условиях вероятность роста RS для соединения с меньшей скоростью будет больше. За счет этого устраняется неравномер-ность использования ресурсов разными соединениями.

Коэффициент slowdown вычисляется следующим образом: если RTT>minERTT*(1+PRECISION),


96

то speedupERTTRTTslowdown ××= )min/(2 , иначе slowdown=1. (43)

Отношение speedup/slowdown определяет знак отклонения мгновенного значения скорости от среднего. Если speedup>slowdown, то отклонение от среднего значения для мгно-венного значения скорости будет положительным, т. е. скорость потока будет увеличиваться. В случае speedup<slowdown скорость потока будет снижаться. Также в состоянии FT максимальное от-клонение мгновенного значения скорости отправки пакетов от среднего за предыдущий период, согласно формуле (27), пропор-ционально среднему значению скорости. В связи с этим поток, со-вершая переход 4 в состоянии FT при большем значении оценки доступной ПС, приспосабливается к небольшим изменениям ПС более интенсивно.

Условием перехода из FT в режим мультипликативного сброса MD2 (переход 6) является:

)minmax( ERTTRTTFTKERTT −×> . (44)

Режим мультипликативного сброса (MD2) необходим для

быстрого снижения скорости при условии резкого роста RTT:

MDFACTORmidpomidpo ii ×= −1intint . (45)

После этого протокол переходит в состояние FT, реализуя переход 7. В том случае, если условие (44) продолжает оставаться истинным, мультипликативное уменьшение продолжается, по-скольку последовательность переходов 6 - 7 реализуется неодно-кратно, выражаясь в экспоненциальном уменьшении скорости пе-редачи данных.

Завершение работы протокола может произойти из любого состояния {SS, REC, FT} – переходы (8, 9, 10).

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


97

2.6. Совместимость с TCP Система, поддерживающая ARTCP, может быть также со-

вместима с TCP. Для этого инициатор соединения, поддерживаю-щий ARTCP, помещает в заголовке синхронизирующего пакета оп-цию “PS”. Наличие поля “PS” в заголовке SYN пакета должно включать механизм ARTCP получателя. Если такая возможность имеется, то получатель включает в сегмент SYN-ACK поле “TI”, ес-ли нет, то отсутствие опции “TI” в ответе получателя отключает ме-ханизм ARTCP у инициатора и дальнейший обмен происходит по протоколу TCP. Если же опция “TI” присутствует в ответе, то ини-циатор уверен, что и получатель задействовал механизм ARTCP.

2.7. Сравнение ARTCP и TCP на основе анализа алгоритма

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

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

Значения t в точках A, B, C обозначают моменты перехода в новый режим


98

Покажем, что протокол ARTCP не создает потерь сегментов,

если ε>R

Qmax , где maxQ – максимальная длина очереди, ε – пре-

дельное значение, используемое алгоритмом ARTCP, а R – ско-рость канала.

Действительно, потеря сегмента может произойти лишь в случае поступления очередного сегмента в очередь обслуживающе-го устройства, когда размер сегмента превышает разность Qmax - Q. Если D – сумма задержек передачи в каналах на пути от отправите-ля к получателю, то в предположении, что каналы в системе сим-метричны и трафик передается лишь в одном направлении, мини-мальное время minRTT определяется как 2D. В случае, если средняя скорость отправки потока RS превышает скорость R канала, обслу-живающего очередь, возникает очередь сегментов в маршрутизато-ре. Появление очереди длины Q приведет к увеличению времени RTT на величину Q/R. Однако для ARTCP, если разность RTT-minRTT превышает некоторое предельное значение e, вероятность снижения скорости отправки потока RS станет отличной от нуля и скорость потока будет снижаться, пока значение разрешенного пре-вышения RTT над minRTT не станет ниже предельного значения. Таким образом, выполняется неравенство: Q < e + R. Выбирая дос-таточно малое значение e, алгоритм ARTCP гарантирует, что длина очереди не превысит определенного значения, меньшего, чем мак-симальная длина очереди Q maxQ< . Для выполнения этого необ-

ходимо выбрать e так, чтобы R

Qmax<ε . Следовательно, при таком

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

Как следствие этого получаем, что при числе потоков, боль-шем 1, протокол ARTCP в отличие от TCP может быть настроен так, чтобы вообще не создавать потерь сегментов.

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


99

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

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

Сказанное выше можно сформулировать как Свойство ARTCP: В отличие от TCP, протокол ARTCP не

чувствителен к потерям сегментов.

2.8. Направления дальнейшего развития ARTCP Протокол ARTCP способен работать более эффективно и ка-

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

Асимметричные системы Поскольку в протоколе ARTCP устранена ACK-синхрониза-

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

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


100

также связать с получателем. Поскольку трудно добиться хорошей синхронизации системных часов получателя и отправителя, то по-лучатель может лишь замечать изменение времени передачи сег-ментов, если отправитель использует стандартное поле временной метки [6]. Если разность значений метки в потоке и системных ча-сов получателя изменяется, значит, изменяется и абсолютное зна-чение задержки. В этом случае получатель должен увеличить час-тоту подтверждений, чтобы отправитель мог среагировать на из-менение нагрузки в сети. Когда значения скорости прибытия пото-ка и задержки передачи не меняются, частота подтверждений мо-жет быть снова уменьшена.

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

Соединения с различными RTT Для соединений, обладающих различным временем RTT из-

за различий длин их маршрутов, среднее значение коэффициента F ограничивается некоторым числом, меньшим 1, как показано в ра-ботах [80 – 83]. Это верно как для ARTCP, так и для TCP. Чтобы достичь равноправия разделения ПС между ARTCP-потоками с разной длиной маршрута, необходимо устранить зависимость ко-эффициента speedup от минимального времени RTT. Этого резуль-тата можно достичь путем модификации алгоритма адаптации та-ким образом, чтобы в режиме FT полностью отказаться от исполь-зования измеренного RTT как индикатора перегрузки, используя лишь значения межсегментных интервалов потока.


101

Глава 3. Имитационная модель

Для исследования возможностей протокола и отработки его механизмов была разработана программная имитационная модель самого протокола и сетевых компонентов, в среде которых должен функционировать протокол ARTCP. Модель представляет собой набор компонентов, имитирующих реальные объекты в составе се-ти и объекты протоколов ARTCP и CBR (Constant Bit Rate). Изу-чаемая сеть может иметь топологическую схему достаточно боль-шой сложности, которая строится из необходимого числа экземп-ляров имеющихся классов.

Основными способами, позволяющими исследовать и вери-фицировать сложные сетевые протоколы, являются стенды для тестирования (экспериментальные сети), программные эмуляторы и системы автоматизированной верификации. Верификацию набо-ра процедурных правил протокола можно осуществлять с помо-щью программного перебора состояний конечного автомата (КА), представляющего протокол [56 – 58], например, в интерпретаторе языка PROMELA таком, как SPIN [3]. Однако верификация набора процедурных правил и изучение эффективности протокола пре-следуют различные цели и, соответственно, для них применяются различные инструменты. Верификация протокола означает приме-нение к его набору процедурных правил формального метода, ко-торый позволяет доказать, что этот набор или моделирующая его система конечных автоматов (с обменом данными) полна, не со-держит недостижимых состояний, свободна от статических и ди-намических блокировок. Верификация протокола не ставит зада-чей даже определение количественных характеристик его эффек-тивности, с точки зрения верификации важно лишь то, что про-грессивный обмен данными вообще происходит. Вследствие этого методы верификации построены на полном или частичном анализе достижимых состояний КА, представляющего протокол.

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


102

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

Одним из наиболее мощных эмуляторов протоколов по сво-им функциональным возможностям является программный ком-плекс NS (Network Simulator), входящий в состав системы VINT12 (Virtual Internetwork Testbed) [59 – 61]. Однако эта система, вслед-ствие крайней обширности области применения, является также очень требовательной к вычислительным ресурсам и не дает воз-можности эффективно работать с диспетчеризацией на уровне сегментов, поэтому для моделирования протокола ARTCP нами было разработано специальное программное обеспечение. Для по-строения данной программной модели (ПМ) были использованы методы объектного программирования и реализация на языке C++ [62, 63] в среде Digital UNIX13

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

.

3.1. Формат сообщения Сегменты протоколов моделируются следующей структурой

данных: struct artcp_segment_s {

int src, dst, port; // адрес отправителя, получателя, порт назначе-ния long int seq, psn;

12 Программное обеспечение комплекса VINT: Network Simulator и Net-

work Animator является проектом университета Беркли, США, и его можно полу-чить по адресу: http://www-mash.cs.berkeley.edu/ns/ns.html

13 Для разработки, отладки и использования модели применялся регио-нальный кластер научных вычислений, состоящий из Alpha-станций под управ-лением OS Digital UNIX.


http://www-mash.cs.berkeley.edu/ns/ns.html�

103

// порядковый номер сегмента, смещение от пре-дыдущего (поле PS) double psk; // скорость потока, при получении этого сегмен-та (поле TI) long int rcv_wnd; // окно, объявленное получателем, long int ack_trig, ack; // порядковый номер сегмента, вызвавшего это подтверждение, номер // подтверждения long int syn_ack; // подтверждаемый порядковый номер SYN-сегмента unsigned char flags; // управляющие флаги int hdr_size, payload_size; // размер заголовка, размер поля данных int link; // число ссылок на этот сегмент (для корректной работы с памятью) long int id; // уникальный в модели номер сегмента

}; Новые сегменты создаются внутри объектов протоколов

ARTCP или CBR. Все объекты топологии передают друг другу указатель на область памяти, содержащую соответствующий сег-мент, вместо копирования реальных данных. Кроме того, размеры заголовка сегмента и поля полезной нагрузки задаются в самой структуре данных, и все объекты определяют размер сегмента, ин-терпретируя значения этих полей. Поскольку ссылка на объект может одновременно содержаться во всех объектах, где реализо-вана буферизация: ARTCP, link, interface, то во избежание конфликтов счетчик ссылок хранит количество объектов, в буфе-рах которых находится ссылка на данный сегмент. Освобождение области памяти, содержащей сегмент, разрешено только в случае обнуления счетчика. За исключением полей “TI” и “PS” и служеб-ных полей link, id, все остальные поля сегмента соответствуют полям стандартного TCP-заголовка.

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


104

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

3.2. Объектная структура ПМ Для моделирования самого протокола ARTCP и среды его

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

- Объект протокола ARTCP - Объект протокола CBR -Конечная система (host) - Симплексный канал (link) - Маршрутизатор (router) - Интерфейс (interface) Все классы, описывающие топологические элементы сети:

конечную систему (host), канал (link), маршрутизатор (router), интерфейс (interface), – являются наследниками ба-зового класса element. Интерфейс каждого из этих классов опреде-ляется тремя важнейшими компонентами: прием сегмента - accept_packet(), запрос сервиса - get_service(), обра-ботка прерывания - proc_int(). Эти методы являются переоп-ределением виртуальных функций базового класса. Кроме того, каждый производный класс расширен дополнительными специфи-ческими для него методами. Посредством этих элементов интер-фейса моделируется передача данных в системе (рис. 22). Каждый из наследников класса element ссылается на элемент, с которым он связан топологически, по указателю на базовый класс.

Экземпляр каждого из приведенных классов использует вы-зов accept_packet() топологически привязанного к нему объ-екта для передачи ему сегмента. В зависимости от наличия ресур-сов метод вызываемого объекта может принять или не принять сегмент на обслуживание. Метод proc_int() каждого экземп-ляра вызывается из основной программы для обработки очереди и принятия решения об обслуживании очередного сегмента.


105

Объединение элементов сети в топологическую схему осу-

ществляется с помощью вызова специального метода attach_next() для каждого экземпляра всех классов. Напри-мер, для организации модели сети по простейшей схеме (рис. 23) требуется набор из 14 объектов (рис. 24).

Рис. 23. Пример простейшей топологической схемы 1, состоящей

из двух узлов и двух маршрутизаторов

Рис. 22. Иерархия объектов модели сети в ПМ.

Буквами A, G, P обозначены основные компоненты интерфейсов объектов. Штриховые линии указывают

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


106

Класс link: аспекты реализации Класс, моделирующий канал, получает значения пропускной

способности и задержки передачи при инициализации. Структура данных класса реализуется односвязной динамической очередью, в которую помещаются сегменты, принятые на обслуживание. По-сле начала обслуживания сегмента канал блокирует последующие запросы в течение времени t=S/R, где S – размер сегмента, а R – скорость канала, т. е. времени приема сегмента размера S в канал. В очереди канала сегмент задерживается в течение установленного времени задержки передачи. По истечении этого времени объект канала вызывает метод accept_packet() следующего объекта в топологической схеме сети. Если следующий объект отказывает в обслуживании сегмента, то этот сегмент отбрасывается. Для мо-делирования дуплексной связи применяются 2 экземпляра канала. Параметры каналов могут быть различными для моделирования асимметричных систем.

Рис. 24. Набор взаимодействующих объектов для топологической

схемы 1. Закрашенная область обозначает топологические эле-менты сети (каналы и маршрутизаторы)


107

Метод proc_int() всех экземпляров класса link вызыва-ется из главного цикла. Обработка прерывания переводит внут-ренний счетчик времени и вызывает передачу готового сегмента из канала следующему объекту топологии.

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

SBER)1(1 −− зна-

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

Класс router: аспекты реализации Структура класса router является сложной. В его состав

входят несколько экземпляров класса interface. При инициали-зации класса router ему передаются два параметра: количество интерфейсов и объем буферного пространства (максимальная длина очереди), одинаковый для всех интерфейсов. Объект маршрутиза-тора создает заданное количество экземпляров класса interface. Указатели на каждый интерфейс располагаются в специальном мас-сиве, проиндексированном по порядку создания интерфейсов. По-сле этого на конкретный интерфейс можно ссылаться как router.interface(Х), где Х – номер нужного интерфейса. Каждый интерфейс при инициализации получает указатель на соз-давший его объект класса router, по которому он может ссылать-ся на методы класса router для передачи сегментов в матрицу коммутации (обозначена в схемах как "поле коммутации").

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

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

применения алгоритмов коррекции ошибок.


108

со вторым полем таблицы маршрутизации дает номер выходного интерфейса для данного сегмента. При отсутствии совпадения с записями таблицы маршрутизации сегмент передается для рассыл-ки всем интерфейсам маршрутизатора, кроме того, с которого он был получен. Полученный от коммутирующей матрицы сегмент помещается в выходную очередь интерфейса, если свободное про-странство в ней SQQ ≥−max , в противном случае сегмент отбра-сывается. Очередь моделируется списком двойной связности, ди-намически выстраиваемом в памяти [63]. Очередь обслуживается со скоростью канала, к которому подключен интерфейс.

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

Таким образом, объект маршрутизатора моделирует совре-менное межсетевое устройство с неблокирующей коммутационной матрицей и буферизацией на выходе [67]. Возможно также расши-рение класса маршрутизатора алгоритмами RED и WFQ или CBQ [65, 66].

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

Класс host: аспекты реализации Класс host имеет в своем составе экземпляр класса ARTCP,

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

При отправке сегмента метод get_service() экземпляра класса host вызывается одним из протоколов. В случае приема


109

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

В случае приема сегмента от объекта канала метод accept_packet() передает протоколу указатель, определяемый по значению поля port заголовка сегмента. Сегменты, чей адрес назначения не совпадает с адресом данного экземпляра узла, от-брасываются.

Метод proc_int() класса host используется для передачи запроса на обработку прерывания объекту активного протокола.

Объект протокола CBR Протокол постоянной скорости передачи напрямую соответ-

ствует реальному режиму передачи данных с постоянной битовой скоростью, например CBR в ATM [68] или CES (Circuit Emulation Services) [69] в IP сетях. Корректное взаимодействие с таким ре-жимом передачи данных является актуальной задачей любого адаптивного транспортного протокола в современных сетях с ин-теграцией сервисов [30]. Именно поэтому протокол CBR включен в модель среды исполнения ARTCP. Протокол CBR генерирует сегменты и отправляет их в сеть с предустановленной скоростью

CBRR , т. е. временные промежутки между моментами начала после-довательных трансляций составляют CBRCBR RS /=τ . Подтверждения и, следовательно, ретрансляция сегментов и контроль скорости не реализуются протоколом CBR.

Объект протокола ARTCP Модель ARTCP реализует управление скоростью отправки

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


110

класса ARTCP таковы: Establish() – применяется для началь-ной синхронизации соединения, getarea() – вычисляет значе-ние области компенсации, accept_packet(), proc_int(), status() – запрашивает результат отправки сегмента узлом. Из них три последние являются открытыми и составляют интерфейс класса. В состав класса ARTCP входят два экземпляра класса Queue, которые реализуют приемный и передающий буфер и ме-тоды для манипуляции с ними.

Класс Queue Данный класс реализует схему стандартного управления по-

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

Обработка приема Сегмент, принятый узлом, передается объекту ARTCP. Ме-

тод accept_packet() принимает сегмент и обрабатывает его как подтверждение, если сегмент содержит поле подтверждения. Параметры ARTCP вычисляются, если установлено поле “TI” сег-мента. Если номер подтверждаемого сегмента образует непрерыв-ную последовательность с порядковыми номерами сегментов, на-ходящимися в очереди передачи, то вся последовательность, кроме подтверждаемого сегмента, удаляется из очереди. Например, если сегменты в очереди передачи {k, k+1, k+2, k+3, k+4, …} и узел по-лучает подтверждение {k+3}, то из очереди удаляются сегменты k, k+1, k+2.


111

Если сегмент содержит данные, то он помещается в прием-

ную очередь, после чего приемная очередь сканируется, из нее убираются (передаются пользователю) сегменты, полученные в непрерывной последовательности порядковых номеров. Затем ге-нерируется подтверждение следующего ожидаемого получателем сегмента, в поля которого заносятся следующие значения: ack – кумулятивное подтверждение, ack-trig – номер последнего по-лученного сегмента, adv_wnd – свободное пространство в очере-ди приема. Например, в очереди приема находятся сегменты {i+1, i+2, i+3}, после получения i-го сегмента и его записи в очередь из нее удаляются сегменты i, i+1, i+2, i+3 и значение кумулятивного подтверждения становится равным i+4. Прототип контрольного сегмента с подтверждением ставится на очередь к передаче.

Рис. 25. Концептуальная схема взаимодействия очередей приема и передачи с алгоритмом управления потоком в объекте прото-кола ARTCP. Прямые линии указывают направление потоков

данных, кривые – управляющей информации.


112

Обработка прерывания Метод proc_int(), принадлежащий экземпляру класса

узла, вызывает метод proc_int(о) активного протокола. Дан-ный метод обновляет значение внутреннего счетчика времени эк-земпляра объекта протокола, вычисляет текущую скорость пере-дачи потока по формулам (32), (32а) в состоянии SS, (38) и (39) в состоянии REC, (41) в состоянии FT.

Вычислив значение межсегментного интервала, метод proc_int() класса протокола ARTCP определяет, прошло ли это время с момента отправки предыдущего сегмента. Если да, то за-прашивается экземпляр очереди передачи на предмет наличия в ней готового к отправке сегмента. Сегмент для отправки берется из очереди или создается новый (в случае отсутствия готового сегмента в очереди), после чего в поля ack, ack_trig, adv_wnd заносятся значения из прототипа контрольного сегмента и сегмент передается объекту узла для передачи. Если передача успешна, то узел, вызывая метод status(), уведомляет об этом объект про-токола, который отмечает соответствующий сегмент как отправ-ленный и запускает ТПП для него.

Ускоренная ретрансляция Поддержка ускоренной ретрансляции сегментов также

включена в имитационную модель (ИМ). Для этого объект прото-кола ARTCP отслеживает поступление дублирующих подтвержде-ний. Если последовательно приходят два подтверждения одного и того же i-го сегмента, то ARTCP осуществляет ретрансляцию дан-ного сегмента вне зависимости от значения его ТПП. После осу-ществления ретрансляции алгоритм переходит в состояние, в ко-тором ускоренная ретрансляция не разрешена, и остается в этом состоянии, пока не придет хотя бы одно подтверждение следую-щего (i+1)-го сегмента.

Начальная синхронизация Начальное значение RTT необходимо для вычисления на-

чальной (минимальной) скорости работы соединения, равной S байтов за время RTT. Для осуществления этого измерения при от-крытии нового соединения объект протокола ARTCP реализует обмен сегментом специального типа с противоположной стороной.


113

При активации объект ARTCP попадает в "несинхронизированное" состояние. Сегмент, обозначенный как SYN (по наличию соответ-ствующего флага), отправляется от инициирующей стороны обме-на к получателю. Сегмент SYN несет порядковый номер, не влияющий на порядковые номера при обмене данными. Получа-тель сегмента SYN реагирует отправкой сегмента с установлен-ными флагами SYN, ACK, где поле ACK несет значение порядко-вого номера SYN-сегмента. Получение SYN, ACK-сегмента дает возможность отправителю измерить время RTT и переводит со-единение в состояние "синхронизации", после чего начинается об-мен данными. Наличие идентифицирующего SYN-сегмент поряд-кового номера дает возможность различить их возможные копии и правильно измерить время RTT. Синхронизация соединения мо-жет быть инициирована одновременно обеими сторонами. Для протокола TCP, например, начальная синхронизация имеет место при открытии соединения и имеет целью установить идентичные начальные значения переменных в контрольных блока обеих сто-рон соединения.

3.3. Главный цикл Главный цикл программы вызывает метод обработки преры-

вания proc_int() всех элементов топологии модели (host, link, router). В результате эмулируется ход внутренних часов каждого из объектов и моделируются процессы передачи данных. Также из главного цикла с конфигурируемой периодичностью вы-зываются процедуры, генерирующие отчеты.

3.4. Дуплексный режим Протокол ARTCP, как и TCP, способен осуществлять сим-

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


114

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

3.5. Трассировка модели

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

Каждый из объектов топологии, таких, как узел, канал и ин-терфейс маршрутизатора, при каждой операции с сегментом выво-дит запись в файл отчета. Формат этой записи таков: "{+|-|d|s|r}" time elem src"->"dst "{-|D}{-|A}{-|S}" size seq"/"ack " … " psn psk ack_trig adv_wnd link seq/syn_ack id . где:

+ прием в очередь, - из очереди, d отбрасывание, s отправка протоколом, r прием протоколом;

time время в секундах; elem идентификатор объекта, совершившего действие; src адрес отправителя сегмента; dst адрес получателя сегмента; флаги: D данные, A подтверждение, S синхронизация; size размер сегмента в байтах; seq порядковый номер; ack номер кумулятивного подтверждения; psn поле "PS"; psk поле "TI"; ack_trig номер сегмента, вызвавшего отправку подтвержде-

ния; adv_wnd размер окна получателя в байтах; link счетчик ссылок на область памяти; syn_ack номер подтверждаемого SYN-сегмента; id уникальный идентификатор каждого сегмента.

15 В англоязычной литературе такой способ передачи называется piggy

back.


115

Например, следующий фрагмент отчета представляет пере-дачу одного сегмента с данными и его подтверждения: s 0.6251 0 0->1 D- 1000 0/-1 ... 1 -1 -1 65536 2 0/-1 2 + 0.6357 6 0->1 D- 1000 0/-1 ... 1 -1 -1 65536 2 0/-1 2 + 0.6358 22 0->1 D- 1000 0/-1 ... 1 -1 -1 65536 3 0/-1 2 + 0.8608 11 0->1 D- 1000 0/-1 ... 1 -1 -1 65536 2 0/-1 2 + 0.8609 24 0->1 D- 1000 0/-1 ... 1 -1 -1 65536 3 0/-1 2 r 0.8717 1 0->1 D- 1000 0/-1 ... 1 -1 -1 65536 1 0/-1 2 + 0.8717 25 1->0 -A- 40 0/1 ... -1 -1 0 65536 1 0/1 4 s 0.8718 1 1->0 -A- 40 0/1 ... -1 -1 0 65536 1 0/1 4 + 0.8817 11 1->0 -A- 40 0/1 ... -1 -1 0 65536 1 0/1 4 + 0.8818 23 1->0 -A- 40 0/1 ... -1 -1 0 65536 2 0/1 4 + 0.9868 6 1->0 -A- 40 0/1 ... -1 -1 0 65536 1 0/1 4 + 0.9869 17 1->0 -A- 40 0/1 ... -1 -1 0 65536 2 0/1 4 r 0.9970 0 1->0 -A- 40 0/1 ... -1 -1 0 65536 0 0/1 4

С помощью информации отчета можно проследить путь каж-

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

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

Для первичной обработки результатов моделирования при-менялся специально разработанный набор сценариев на языке ко-мандного интерпретатора UNIX C-shell [70], а также ряд неболь-ших программ, осуществляющих статистическую обработку ре-зультатов модельного эксперимента. Результаты работы модели фильтруются и записываются в несколько файлов в виде строк с полями, разделенными символом табуляции для последующей ви-зуализации и статистической обработки.


116

3.6. Визуализация данных Для визуализации полученных при моделировании данных

применялась программа gnuplot16

В некоторых работах приводятся более сложные системы визуализации, например в [14, 15, 19]. В настоящей работе резуль-таты моделирования наиболее наглядно представляются следую-щими способами: зависимость скорости потока, порядкового но-мера передаваемого сегмента, времени RTT, средней длины очере-ди от времени (рис. 26 – 29).

версии 3.7 для OS UNIX. Как правило, визуализация работы протокола TCP производится с по-мощью графиков зависимости размера окна CWND от времени и зависимости последовательности передачи сегментов от времени, позволяющих визуально определить различные фазы работы про-токола. В подавляющем большинстве работ в области транспорт-ных протоколов применяется именно такая схема [87].

16 Программа gnuplot является широко используемым средством визуали-зации научных данных. Программа доступна по адресу http://www.cs.dartmoth. edu/gnuplot_info.html

Рис. 26. График зависимости скорости отправки потока

от времени. Sending rate – устанавливаемая скорость отправки, measured received rate – измеряемая скорость приема потока


http://www.cs.dartmoth.edu/gnuplot_info.html�

http://www.cs.dartmoth.edu/gnuplot_info.html�

117

Рис. 27. Зависимость порядковых номеров

отправляемых сегментов от времени. Sent segments – отправленные сегменты, received – полученные

Рис. 28. Зависимость RTT от времени.

Smoothed – сглаженное усреднением по окну, measured – мгновенное значение измерения RTT.


118

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

изменения скорости в зависимости от времени. Явно просматри-ваются режимы SS, MD1, REC и FT. В режиме FT, переход в кото-рый происходит примерно на 5-й секунде, имеют место спонтан-ные осцилляции значения скорости передачи. Сплошная линия – задаваемое значение sR , точки – измеряемое значение Re. Из срав-нения рис. 26 с рис. 21 хорошо заметно совпадение ожидаемого и реального поведения системы. Рис. 27 изображает эволюцию со-единения, sent segments соответствуют моментам отправки сегмен-тов, received segments – моментам приема сегментов соответствую-щих порядковых номеров. Оценка скорости по графику дает: меж-ду моментами t=20 и t=40 секунд было отправлено 150 1000-бай-товых сегментов, т. е. средняя скорость потока составляет 7.5 сег-мента/с. Это дает 93.75% использования ресурсов канала, посколь-ку моделируемая ПС канала равна 64 Кб/с.

Промежутки времени, когда задаваемая скорость потока пре-вышает реальную ПС сети, выражаются в пиках значения RTT (рис. 28).

Рис. 29. Зависимость порядковых номеров передаваемых

и принимаемых данных и подтверждений от времени


119

На рис. 29 динамика соединения приведена в масштабе 0-6 с, что более наглядно отражает процессы, происходящие при работе ARTCP. Отмечены моменты отправки сегментов (sent), приема (received), отправки подтверждения (ack sent) и приема подтвержде-ния (ack received). Следует отметить, что подтверждение всегда со-держит номер следующего ожидаемого получателем сегмента.


120

Глава 4. Результаты моделирования

4.1. Общая схема модельного эксперимента Описанная имитационная модель была построена для опре-

деления эффективности работы сети с алгоритмом ARTCP, а также для сравнения характеристик ARTCP и TCP. Модельные экспери-менты проводились в нескольких сценариях. Все сценарии укла-дываются в схему соединения двух ЛВС через канал с ограничен-ной ПС. Между двумя ЛВС предполагается один или более ARTCP потоков, а также может присутствовать CBR поток. Чис-ленными результатами экспериментов являются следующие пока-затели (стандартная характеристика протокола [73]):

- коэффициент использования ресурсов:

времяканаласкоростьбитовпринятыхчислоU×

=)_(__

; - коэффициент равноправия разделения пропускной способ-

ности:

)(

)(

1

2

2

1

∑

∑

=

=

×= n

ii

n

ii

bn

bF

, - ib – доля ПС, приходящаяся на i-e соединение, - среднее значение длины очереди Q, - среднее число отправленных и ретранслированных сегмен-

тов. Для получения средних значений показателей протокола в

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

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

На работу протокола транспортного уровня в сложной сети оказывает влияние огромное число факторов: это и все промежу-точные системы нижних уровней со своими алгоритмами и прото-колами, и пользователь транспортного уровня. Многоуровневая ар-


121

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

Помимо нижних уровней, на работу протокола влияет пове-дение его пользователя, каковым является приложение, исполняе-мое на данном узле. Мы рассматриваем ситуацию, когда нагрузка на транспортный уровень максимальна, т. е. источник всегда имеет данные для передачи, а получатель обрабатывает данные по мере поступления. Такая ситуация наиболее распространена в реально-сти. Практически во всех случаях информационных потоков, кро-ме удаленного доступа в диалоговом режиме, соединение транс-портного протокола открывается для передачи некоторого объема информации. Передача этого объема данных ведется с максималь-ной скоростью, после завершения обмена соединение прерывается. В процессе передачи транспортный протокол формирует сегменты максимального размера. Для разных маршрутов могут задаваться различные ограничения размера сегментов. Типичные значения, обусловленные наиболее распространенными технологиями пере-дачи, составляют 576, 1 000 и 1 500 байтов. В частности, трафик, обусловленный обращениями пользователей Ярославской регио-нальной сети к серверам WWW и FTP, расположенным за преде-лами Ярославской области, полностью состоит из сегментов раз-мером 1 000 байтов (кроме последнего сегмента в соединении). Этот трафик составляет более 95% суммарного трафика регио-нальной сети. Именно для такого трафика и предназначен ARTCP.

Основными характеристиками протокола, которые определя-ются посредством статистической обработки данных модельного эксперимента, являются: коэффициенты использования ПС (U), равноправия разделения ПС (F) и средняя длина очереди (Q). Нуж-но понять, зависят ли эти характеристики (и если зависят, то как) от следующих параметров сети: ПС, RTT, BER, число потоков.

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


122

адекватно соответствовать ситуации в реальных сетях. Так, на-пример, большинство каналов Ярославской региональной сети имеют ПС от 64 Кб/с до 2 Мб/с. Каналы коммутируемых соедине-ний в этой же сети имеют ПС от 28800 б/с до 56000 б/с. Пропуск-ная способность каналов ЛВС в подавляющем большинстве случа-ев равна 10 Мб/с. Используемые в модельном эксперименте значе-ния RTT характерны для соединений межрегионального типа, на-пример Ярославль – Москва. Значения BER соответствуют реаль-ным вероятностям битовых ошибок, характерных для спутнико-вых каналов.

План модельного эксперимента Поскольку протокол ARTCP является новым, то сначала

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

Сценарий 1. Сравнение функционирования реализации про-токола ARTCP в модели с ожидаемым поведением его алгоритма и наглядная иллюстрация работы соединения протокола ARTCP.

Сценарий 2. Изучение поведения основных характеристик протокола в зависимости от параметров моделируемой сети. Вы-деление набора параметров, оказывающих наибольшее влияние на поведение протокола.

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

Сценарий 3. Сравнение протоколов ARTCP и TCP при раз-личных значениях битовых ошибок передачи в канале.

Сценарий 4. Сравнение протоколов ARTCP и TCP по коэф-фициенту использования ПС при различных значениях числа по-токов.


123

Сценарий 5. Сравнение ARTCP и TCP по коэффициенту равноправия разделения ПС при различных значениях числа пото-ков.

Сценарий 6. Произведем сравнение ARTCP и TCP по сред-ней длине очереди при различных значениях числа потоков.

Сценарий 7. Рассмотрим детально взаимодействие одного потока ARTCP и CBR.

Сценарий 8. Рассмотрим детально взаимодействие двух ARTCP-потоков и CBR-потока.

Сценарий 9. Исследуем трафик протокола ARTCP на пред-мет наличия у него свойства самоподобия.

4.2. Сценарий 1: изолированный ARTCP

Задача Задачей моделирования по сценарию 1 является детальная

иллюстрация работы алгоритма протокола ARTCP в процессе адаптации к ПС канала. Проведем эксперименты при двух различ-ных значениях ПС каналов: 32 Кб/с и 128 Кб/с.

Топология Для исследования поведения протокола ARTCP в условиях,

свободных от влияния других транспортных потоков, используется топология, изображенная на рис. 30. Стрелкой указано направление передачи данных. Узел, отмеченный знаком S, является отправите-лем, узел R – получателем. Набор каналов 0, 1 моделирует дуплекс-ную коммутируемую ЛВС17

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

пользует только один узел. Это функциональный аналог сети IEEE802.3 [71].

или выделенный канал у отправителя, 2, 3 – соответственно, у получателя. Набор каналов 4, 5 моделирует канал типа точка-точка между двумя узлами территориальной сети.


124

Эксперимент 1: 32 Кб/с Параметры:

Параметр Значение ПС каналов 0, 1, 2, 3 10 Мб/с18 Задержка каналов 0, 1, 2, 3 0.01 с ПС каналов 4, 5 32 Кб/с Задержка каналов 4, 5 0.1 с Время моделирования 300 с Макс. размер очереди маршрутизатора 16 Кбайт BER 0

Результаты: Характеристика Значение Коэффициент использования ПС в состоянии FT 97.81% Средняя скорость потока 31302.64 б/с Число потерянных сегментов 0 Число переданных сегментов 1173 RTT (усреднение за время эксперимента) 0.614± 0.146 с. Минимальное RTT 0.519 с. Q (усреднение за время эксперимента) 459.833± 716.51

байт Иллюстрация функционирования протокола ARTCP в дан-

ных условиях приведена на рис. 31 – 34.

18 Приставка М означает: 610× , К: 310× .

Рис. 30. Топологическая схема 1

с одним потоком и парой конечных систем


125

Рис. 32. Зависимость среднего и мгновенного значения RTT от времени при скорости канала 32 Кб/с.

Рис. 31. Зависимость скорости потока от времени при скорости канала 32 Кб/с.


126

Рис. 33. Зависимость порядка передачи/приема сегментов от времени при скорости канала 32Кб/с. sent – отправленные,

received – принятые, dropped – потерянные сегменты

Рис. 34. Зависимость мгновенного значения длины очереди от времени


127

Эксперимент 2: 128 Кб/с Параметры:

Параметр Значение ПС каналов 0, 1, 2, 3 10 Мб/с Задержка каналов 0, 1, 2, 3 0.01 с ПС каналов 4, 5 128 Кб/с Задержка каналов 4, 5 0.1 с Время моделирования 300 с Максимальный размер очереди маршрутизатора

16 Кбайт

Результаты: Характеристика Значение Коэффициент использования ПС в состоянии FT 95.38% Средняя скорость потока 122285.64 б/с Число потерянных сегментов 0 Число переданных сегментов 4558 RTT 0.335± 0.048 с. Минимальное RTT 0.307 с. Q 452.667± 872.59

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

проиллюстрировано на рис. 35 – 38.

Рис. 35. Зависимость скорости потока от времени при скорости канала 128Кб/с.


128

Рис. 36. Зависимость среднего и мгновенного значения RTT от времени при скорости канала 128Кб/с.

Рис. 37. Зависимость порядка передачи/приема сегментов от времени при скорости канала 128 Кб/с.


129

Выводы Эксперименты в сценарии 1 показали, как изолированный

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

4.3. Сценарий 2: определение важнейших пара-метров сети Задача

Перед тем как переходить к дальнейшим экспериментам, определим характер зависимости основных характеристик прото-кола от параметров сети.

Основными характеристиками протокола, которые опреде-ляются посредством статистической обработки данных модельно-го эксперимента, являются коэффициенты U, F и ср едняя длина

Рис. 38. Зависимость мгновенного значения длины очереди от времени


130

очереди Q. Нужно понять, зависят ли эти характеристики (и если зависят, то как) от следующих параметров сети: ПС, число пото-ков, RTT, BER.

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

Коэффициент равноправия разделения ПС не должен зависеть от ПС канала, поскольку вероятность увеличения скорости потока ARTCP, в соответствии с его алгоритмом, определяется лишь его скоростью потока и разностью между минимальным и измеряемым RTT. Именно поэтому коэффициент F не должен зависеть от RTT.

Таким образом, необходимо провести эксперименты для полу-чения зависимостей характеристик ARTCP от ПС канала для разного числа соединений. По результатам экспериментов вычислим средние значения U, F, Q. Далее проверим, существует ли для этих коэффици-ентов зависимость от RTT. Влияние вероятности BER на характери-стики ARTCP будем изучать при сравнении ARTCP с TCP.

Топология Для проведения измерений при разных значениях числа по-

токов были произведены эксперименты на 10 вариантах сетевой топологии, содержащих от 2 до 20 узлов, между которыми соот-ветственно существовало от 1 до 10 одновременных потоков. Об-щая схема эксперимента приведена на рис. 39. Значение ПС кана-лов между маршрутизаторами R1 и R2 изменяется в пределах 64 Кб/с и 2048 Кб/с.

Параметры: Параметр Значение ПС каналов LAN 10 Мб/с Задержка каналов LAN 0.01 с ПС каналов WAN От 64 Кб/с до 2.048 Мб/с, шаг 32 Кб/с Задержка каналов WAN 0.1 с Длительность эксперимента 500 с Макс. размер очереди маршрутизатора

32 Кбайт

Число потоков ARTCP От 1 до 9 Число экспериментов 50 по каждому значению ПС


131

Проведено по 50 экспериментов с одним потоком ARTCP

для каждого значения ПС сети из диапазона 64 – 2048 Кб/с при шаге 32 Кб/с. Длительность каждого эксперимента в полученной серии из 3050 равна 300 с. По данным каждого эксперимента оп-ределены значения U, F, Q. Проведены такие же серии измерений для сети с 2, 3, …, 9 ARTCP потоками. На рис. 40, 41 приведены графики зависимости коэффициента U от ПС канала для 1, 2, … 9 потоков.

По графику можно сделать вывод, что в случае одного пото-ка ARTCP существует зависимость между U и ПС канала. Коэф-фициент использования ПС канала для одного ARTCP-потока снижается с ростом ПС. Однако даже при ПС канала, равной 2 Мб/с, эффективность использования ПС для ARTCP не меньше 0.825. Для двух потоков ARTCP снижение коэффициента U с рос-том ПС происходит медленнее и прекращается на значении U ≈ 0.925. Для большего числа ARTCP-потоков коэффициент U не па-дает с ростом ПС и приближается к единице для всего диапазона ПС с р остом числа потоков. Для числа потоков более 5 среднее значение коэффициента U не опускается ниже 0.95.

Рис. 39. Топологическая схема с 10 парами источник-получатель. Эксперимент 1: влияние ПС и числа потоков


132

Рис. 40. Зависимость коэффициента использования ПС от ПС канала для 1-го – 9-го потоков ARTCP

Рис. 41. Зависимость коэффициента использования ПС от ПС канала для 1-го и 5-го потоков. Отрезками обозначено 2σ


133

Падение эффективности использования сети с одним

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

Коэффициент равноправия разделения ресурсов для любого числа ARTCP-потоков не зависит от ПС сети и близок к единице (рис. 42). Средняя длина очереди Q зависит лишь от числа потоков и не зависит от ПС сети (рис. 47).

Итак, коэффициент использования ПС для нескольких одно-временных ARTCP-потоков близок к единице при всех значениях ПС сети от 64 Кб/с до 2.048 Мб/с.

Рис. 42. Зависимость коэффициента равноправия разделения ПС

от ПС канала. Для числа потоков от 1-го до 9-го


134

Эксперимент 2: влияние RTT Параметры:

Параметр Значение ПС каналов LAN 10 Мб/с Задержка каналов LAN 0.01 с ПС каналов WAN 54, 128, 256, 512 Кб/с Задержка каналов WAN От 0.01 до 0.33 с при шаге 0.02 с Длительность эксперимента 300 с Макс. размер очереди маршрутизатора 32 Кбайт Число потоков От 1 до 9 Число экспериментов По одному для каждого значе-

ния задержки

Проверим теперь наличие зависимости характеристик про-токола от значения RTT. Предполагаем, что ни один из параметров U, F и Q не зависит от RTT, поскольку алгоритм ARTCP предпола-гает зависимость лишь от разности текущего и минимального зна-чения RTT, а не от его абсолютного значения. Для проверки этой гипотезы проведем эксперимент длительностью 300 с для каждого из значений задержки передачи каналов WAN от 0.01 до 0.33 с ша-гом 0.02 для каждого из значений ПС: 64, 128, 256 и 512 Кб/с и каждого из 9 значений числа потоков. 36 средних значений U, по-лученных из 36 серий по 16 измерений, не отличаются от соответ-ствующих данному числу потоков и значению ПС результатов предыдущего эксперимента. Кроме того, в каждой из 36 серий не наблюдается зависимости U от RTT. Аналогичные измерения бы-ли проведены и для значений Q и F, которые также не обнаружили зависимости от RTT.

Выводы Таким образом, коэффициент использования ПС сети (U) за-

висит от ПС сети лишь для одного ARTCP-потока, при наличии более 5 ARTCP-потоков можно пренебречь зависимостью U от ПС. В этом случае при росте ПС значение U стабилизируется на величине тем более близкой к единице, чем больше число потоков. Кроме того, U не зависит от RTT соединения.

Коэффициент равноправия разделения ПС не зависит от RTT или числа потоков. Зависимость его от ПС сети очень слаба в изу-ченных пределах (64 – 2048 Кб/с), и ею можно пренебречь.


135

Средняя длина очереди Q зависит лишь от числа потоков. С ростом количества одновременных соединений Q медленно растет.

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

Сценарий 3: ARTCP и TCP в условиях ошибок передачи Задача

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

Задачей экспериментов в этом сценарии является сравнение коэффициента использования ПС протоколами ARTCP и TCP при разных значениях BER. Поскольку для более чем 5 потоков ARTCP область изменения коэффициента U мала, то будем проводить ис-следования при нескольких фиксированных значениях ПС канала.

Топология Для экспериментов по данному сценарию используется то-

пологическая схема с 10-ю парами “источник – получатель” (рис. 39). Протокол TCP моделируется на такой же топологии в ПО NS. Время задержки передачи на канале с наименьшей ПС со-ставляет 0.1 с в каждом направлении. Значения ПС канала фикси-рованы и составляют 256, 512 и 1024 Кб/с.

Эксперимент Параметры:

Параметр Значение ПС каналов LAN 10 Мб/с Задержка каналов LAN 0.01 с ПС каналов WAN 256, 512, 1024 Кб/с Задержка каналов WAN От 0.1 с Длительность эксперимента 500 с Максимальный размер очереди маршрутизатора 32 Кбайт Число потоков 10


136

Число экспериментов По 50 для каждого значения BER

BER [0,6 × 10-5] Определим значения суммарной скорости 10 ARTCP и 10

TCP-потоков, разделяющих общий канал (отдельно для каждого протокола) с ПС 256 Кб/с и значениями BER из промежутка [0,6 × 10-5]. По каждому значению BER проводим по 50 экспери-ментов длительностью 500 с. В приведенных ниже результатах ис-пользуется суммарная достигнутая всеми соединениями скорость потока. На графике зависимости скорости потоков от времени (рис. 43) ясно видно, что начиная со значения 1 × 10-5 скорость TCP резко снижается, а скорость ARTCP-потока остается близкой к максимальной скорости.

Рис. 43. Зависимость коэффициента использования ПС от вероятности битовых ошибок канала.

ПС канала равна 256 Кб/с.


137

Максимальная ПС в данном случае вычисляется как SBERПС )1( −× . Для обобщения результатов построим график зави-

симости U от BER. Такой график представлен на рис. 44. Прове-дем аналогичную серию экспериментов для ПС канала, равной 512 и 1024 Кб/с. Как и следовало ожидать, экспериментальные значе-ния зависимости U от ПС для других значений ПС канала практи-чески неотличимы от уже полученной зависимости при ПС = 256 Кб/с. Это происходит потому, что, как показано ранее, коэффициент U для большого числа ARTCP-потоков почти не за-висит от ПС канала.

Выводы Как видно на рис. 44, эффективность использования ПС ка-

нала протоколом ARTCP не зависит от вероятности битовых оши-бок на канале. На канале с вероятностью битовых ошибок, превы-шающей 5101 −× , протокол ARTCP существенно превосходит TCP по эффективности использования ПС.

Рис. 44. Зависимость коэффициента использования ПС от вероятности битовых ошибок канала


138

Сценарий 4: ARTCP и TCP - коэффициент использования Задача

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

Топология Для моделирования 1 – 9 потоков ARTCP будем проводить

эксперимент на топологических схемах, использованных в экспе-рименте 1 сценария 2.


Параметр Значение ПС каналов LAN 10 Мб/с Задержка каналов LAN 0.01 с ПС каналов WAN От 64 Кб/с до 2.048 Мб/с, шаг

32 Кб/с Задержка каналов WAN 0.1 с Длительность эксперимента 500 с Максимальный размер очереди маршрутизатора

32 Кбайт

Число потоков TCP От 1 до 9 Число экспериментов 50 по каждому значению ПС

Проведем серию измерений аналогично сценарию 2 – теперь

для протокола TCP. Значения коэффициента U для TCP проявляют выраженную тенденцию к снижению при росте числа потоков (рис. 45).

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


139

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

Сравнение рис. 45 и 40 показывает явное превосходство ARTCP перед TCP при росте числа потоков.

Выводы

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

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

Рис. 45. Зависимость коэффициента использования ПС от ПС сети для 1, 3, 5, 9 одновременных потоков TCP


140

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

Сценарий 5: ARTCP и TCP - коэффициент равноправия

) или увеличения вероятности отбрасывания данных (при использо-вании дисциплины RED) [79]. Ретрансляции отброшенных сегмен-тов приводят к уменьшению эффективности использования ресур-сов сети. В экспериментальной топологии данный эффект мини-мален, поскольку потерянные пакеты проходят лишь высокоско-ростной канал, соединяющий отправителя с первым маршрутиза-тором. Однако, как продемонстрировано в работе [78], для более сложной сети, в состав которой входят несколько перегруженных каналов, эффект ретрансляции пакетов существенно снижает эф-фективность использования ресурсов.

Задача Рассмотрим поведение коэффициента равноправия разделе-

ния ПС для протоколов TCP и ARTCP в зависимости от числа со-единений. Поведение коэффициента F для ARTCP было исследо-вано в экспериментах по сценарию 2. Было показано, что коэффи-циент F в случае ARTCP фактически не зависит от числа потоков и ПС канала. Необходимо определить поведение коэффициента F для протокола TCP. Как было показано в [80], коэффициент рав-ноправия разделения ПС для TCP не зависит от скорости канала. Поставим эксперимент для определения значения F при разном числе потоков TCP и фиксированном значении ПС.

Топология Для проведения эксперимента используется топологическая

схема, идентичная схеме эксперимента 2, однако значение ПС ка-нала фиксировано и равно 256 Кб/с.

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


141


Параметр Значение ПС каналов LAN 10 Мб/с Задержка каналов LAN 0.01 с ПС каналов WAN 256 Кб/с Задержка каналов WAN 0.1 с Длительность эксперимента 100 с Макс. размер очереди маршрутизатора 32 Кбайт Число потоков TCP От 1 до 9 Число экспериментов 100 по каждому значе-

нию числа потоков Для каждого из значений числа потоков от 1-го до 9-го про-

водим по 100 модельных экспериментов длительностью 100 с. По каждой из 9 серий определяем среднее значение коэффициента F (рис. 46) для каждого значения числа одновременных потоков.

Главным отличием здесь является то, что для ARTCP коэф-

фициент равноправия разделения ПС растет при росте числа со-единений, в то время как для TCP увеличение количества соедине-ний приводит к снижению равноправия разделения ПС.

Рис. 46. Зависимость коэффициента равноправия разделения ПС

от числа потоков ARTCP и TCP. Время измерения 100 с.


142

Выводы Соединения протокола ARTCP более равноправны между

собой, чем TCP, причем с ростом числа соединений для протокола TCP значение F снижается, а для ARTCP постоянно и близко к 1.

Сценарий 6: ARTCP и TCP – средняя длина очереди

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

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

Топология Для проведения эксперимента используется топологическая

схема, идентичная схеме эксперимента 2, однако значение ПС ка-нала фиксировано и равно 256 Кб/с.


Параметр Значение ПС каналов LAN 10 Мб/с Задержка каналов LAN 0.01 с ПС каналов WAN 256 Кб/с Задержка каналов WAN 0.1 с Длительность эксперимента 500 с Макс. размер очереди маршрутизатора 32 Кбайт Число потоков TCP От 1 до 9 Число экспериментов 100 по каждому значению

числа потоков


143

Для каждого числа потоков от 1 до 9 проводим 100 экспери-ментов длительностью 500 с. По данным 9 серий определим сред-ние значения длины очереди (рис. 47).

Протокол TCP определяет доступную пропускную способ-

ность сети, полностью насыщая ее трафиком и вызывая перепол-нение очередей в сетевых устройствах. Вследствие этого средняя длина очереди при моделировании TCP-потоков всегда макси-мальна (начиная с 5 активных соединений). Следствием этого яв-ляются постоянно происходящие потери пакетов, что проиллюст-рировано на рис. 49, в отличие от ARTCP, заполнение очередей для которого минимально и отсутствуют связанные с переполне-нием буфера потери пакетов (рис. 48).

Выводы В отличие от протокола TCP, который максимально запол-

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

Рис. 47. Зависимость средней длины очереди от числа соединений


144

Рис. 49. Последовательность передачи для 10 TCP-потоков при пропускной способности канала 256 Кб/с.

Рис. 48. Последовательность передачи для 10 ARTCP-потоков при пропускной способности канала 256 Кб/с.


145

Сценарий 7: 1 ARTCP и 1 CBR

Задача Рассмотрим взаимодействие одного ARTCP-потока с одним

CBR-потоком. Протокол ARTCP должен эффективно использовать оставшуюся от потока CBR пропускную способность сети. Работа соединения происходит в двух фазах: фаза, когда существует только один ARTCP-поток на канале, и фаза, когда включен CBR. Причем после включения CBR-потока ARTCP, занимавший ранее всю ПС, должен снизить скорость своего потока. В этом сценарии CBR-поток включается позже, чем ARTCP, поскольку нас интере-сует именно адаптация ARTCP к ПС канала после ее скачкообраз-ного понижения на величину скорости CBR ( CBRR ). Проверим, су-ществует ли зависимость между коэффициентом U и значением (ПС- CBRR ) при фиксированном значении ПС канала 256 Кб/с.

Топология Для проведения эксперимента в данном сценарии использу-

ется топологическая схема с двумя источниками и двумя получа-телями, приведенная на рис. 50.

Рис. 50. Элементы топологии 2


146


Параметр Значение ПС каналов LAN 10 Мб/с Задержка каналов LAN 0.01 с ПС каналов WAN 256 Кб/с Задержка каналов WAN 0.1 с Длительность эксперимента 500 с Максимальный размер очереди маршрутизатора 32 Кбайт Число потоков ARTCP 1 Число потоков CBR 1 Скорость потока CBR От 48 Кб/с до 208

Кб/с с шагом 16 Кб/с Число экспериментов 100 по каждому зна-

чению CBRR Момент запуска потока CBR

Выбирается из ин-тервала 90 – 110 с по случайному закону с равномерным рас-пределением

Момент остановки CBR Выбирается из ин-тервала 390 – 410 с по случайному закону с равномерным рас-пределением

Проводим по 100 измерений U для каждого значения CBR от

48 до 208 Кб/с с шагом 16 Кб/с. Полученные средние значения U по 100 измерений для каждого из значений разности ПС-RCBR фак-тически не зависят от (ПС-RCBR). Полученное значение U составля-ет 0.9726± 0.003 (рис. 51).

Поведение соединений в типичном эксперименте этого сце-нария проиллюстрировано на рис. 52 – 55.


147

Рис. 51. Значения коэффициента использования ПС протоколом ARTCP при различных значениях скорости протокола CBR.

ПС канала составляет 256 Кб/с.

Рис. 52. Зависимость скорости потока от времени


148

Рис. 54. Зависимость мгновенной длины очереди от времени

Рис. 53. Зависимость последовательности передачи данных

от времени


149

Выводы По результатам эксперимента в этом сценарии можно сде-

лать вывод о том, что протокол ARTCP качественно адаптируется к ПС канала, не занятой потоком CBR. В данных условиях не про-исходит потерь ни ARTCP-сегментов, ни сегментов CBR. Для фиксированных значений ПС канала скорость ARTCP в присутст-вии CBR практически не зависит от ПС- RCBR.

Сценарий 8: 2 ARTCP и 1 CBR

Задача Далее детально изучим взаимодействие двух ARTCP-

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

Рис. 55. Зависимость измеряемого RTT от времени


150

CBR-потока оба ARTCP-потока должны уменьшить свою скорость так, чтобы на долю каждого приходилась половина от разности ПС- CBRR . Задачей моделирования по сценарию 4 является провер-ка качества адаптации ARTCP к доступной доле пропускной спо-собности канала. Необходимо рассмотреть взаимодействие двух ARTCP-потоков до и после включения CBR.

Топология Для исследования аспектов взаимодействия потоков прото-

кола ARTCP в условиях наличия потока протокола CBR использу-ется топология, изображенная на рис. 56. Стрелкой указано на-правление передачи данных. Узлы, отмеченные знаком S, являют-ся источниками, узлы R – приемниками потоков.

Рис. 56. Элементы топологии 3


151


Параметр Значение ПС каналов LAN 10 Мб/с Задержка каналов LAN 0.01 с ПС каналов WAN 256 Кб/с Задержка каналов WAN 0.1 с Длительность эксперимента 500 с Максимальный размер очереди маршрутизатора 32 Кбайт Скорость потока CBR От 48 Кб/с до 208 Кб/с с шагом 16 Кб/с Число экспериментов 100 Число потоков ARTCP 2 Число потоков CBR 1 Скорость потока CBR Выбирается из интервала 50 – 200 Кб/с

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

Число экспериментов 100 по каждому значению RCBR Момент запуска потока CBR Выбирается из интервала 90 – 110 с по

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

Момент остановки CBR Выбирается из интервала 390 – 410 с по случайному закону с равномерным рас-пределением

Момент запуска второго ARTCP-потока

Выбирается из интервала 190 – 210 с по случайному закону с равномерным рас-пределением

Поскольку, как выяснилось в предыдущем сценарии, коэф-

фициент U не зависит от ПС-RCBR, то значения скорости CBR вы-бираем по случайному закону с равномерным распределением из промежутка 50 – 200 Кб/с. Выбираем 100 значений и для каждого проводим эксперимент длительностью 500 с. По случайному зако-ну с равномерным распределением выбираем и значения моментов запуска второго ARTCP-потока и CBR-потока из промежутков 90 – 110 и 190 – 210 с соответственно в каждом эксперименте.

Полученные результаты таковы: для двух ARTCP-потоков в присутствии CBR-потока U = 0.971 ± 0.023; для двух ARTCP-


152

потоков в отсутствие CBR-потока U = 0.971 ± 0.023; число поте-рянных сегментов во всех случаях равно нулю; для двух ARTCP-потоков в присутствии CBR-потока F = 0.989 ± 0.011; для двух ARTCP-потоков в отсутствие CBR-потока F = 0.97 ± 0.028.

График зависимости скорости соединений от времени при-веден на рис. 57, а график зависимости порядкового номера пере-даваемых сегментов от времени – на рис. 58. Для визуализации выбран типичный эксперимент данного сценария.

Рис. 57. Зависимость скорости ARTCP потоков

1 и 2 от времени


153

Выводы Таким образом, два ARTCP-потока хорошо адаптируются к

доступной ПС канала как на фоне CBR-потока, так и без него.

Сценарий 9: свойство самоподобия трафика ARTCP

Задача Основным методом анализа коммуникационных сетей явля-

ется теория систем массового обслуживания. Однако большинство результатов этой теории получено в предположении о конечности дисперсий как интервалов между поступлениями сегментов, так и длительностей их обслуживания. Экспериментальное изучение трафика в TCP/IP-сетях (В. Леланд и др.) показало, что такое предположение о конечности дисперсии неверно. В классических

Рис. 58. Зависимость последовательности передачи данных от времени


154

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

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

Для определения, обладает ли трафик свойством самоподо-бия, обычно вычисляется коэффициент Херста. Цель данного сце-нария – выявление свойства самоподобия ARTCP-трафика.

Топология Топологическая схема эксперимента представлена на рис.

39. Согласно схеме через территориальную сеть проходит трафик между двумя ЛВС – по 10 узлов в каждой. Данные снимаются с маршрутизатора R1. ПС каналов WAN составляет 512 Кб/с.

Эксперимент Для вычисления коэффициента Херста ARTCP-трафика был

проведен модельный эксперимент, результатом которого явилась серия из 147 036 измерений, суммирующих события прихода сег-ментов с данными на маршрутизатор R1 от 10 активных источни-ков за периоды 0.1с. Время моделирования составило 19 174 с, а общее число событий поступления сегментов с данными в мар-шрутизатор R1 – 1 208 031.

График фрагмента (9 000 – 12 000 с) исходной серии изме-рений приведен на рис. 59, а на рис. 60 изображен результат сгла-живания фрагмента последовательным применением wavelet sym8 декомпозиции уровня 10, отбрасывания коэффициентов разложе-ния, превышающих 150, и восстановления сигнала. Для wavelet-анализа применялась программа Matlab.


155

Рис. 59. Фрагмент полученной серии измерений

Рис. 60. Фрагмент серии измерений после сглаживания с применением wavelet sym8


156

Рис. 62. Результат применения метода aggregated variance

Рис. 61. Результат применения метода Rescaled adjusted range (R/S)


157

Полученная исходная серия подверглась статистической об-работке с применением методов R/S статистики (рис. 61) и aggregated variance (рис. 62). По результатам применения обоих методов был вычислен коэффициент Херста: по методу R/S он ра-вен 0.63, по методу aggregated variance – 0.65.

Для этого были разработаны программы на языке С, выпол-няющие вычисления по методам R/S и AVM достаточно быстро. Линейная аппроксимация по методу наименьших квадратов про-изводилась с помощью программы статистического анализа PSPP20

Таким образом, трафик ARTCP, как и другой сетевой трафик по Вилингеру и Таггу [95, 97], обладает свойством самоподобия. Использование метода имитационного моделирования протокола ARTCP является адекватным средством его исследования. Нали-чие свойства самоподобия у трафика, полученного на имитацион-ной модели, так же как и у трафика реальных сетей, указывает на то, что разработанная модель хорошо воспроизводит процессы, происходящие в реальных сетях.

.

Основные выводы В части I дано описание нового транспортного протокола

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

20 Программа статистической обработки распространяется под лицензией GNU, информация о ней доступна по адресу http://www.gnu.org/software/pspp/ pspp.html


158

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

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


159

Часть 2. Расширяемая модель транспортных протоколов

Глава 5. Раскрашенные сети Петри

Раскрашенные сети Петри являются хорошо развитым фор-мализмом, который использовался для моделирования и анализа различных протоколов, например, в работах [121, 130].

Раскрашенные сети Петри (CP-сети, CPN) были определены Куртом Йенсеном в 1979 году. Они являются графическим язы-ком, который может использоваться для спецификации, разработ-ки и анализа распределенных и параллельных систем. Йенсен в работе [114] сопоставляет обычные сети Петри и раскрашенные как низкоуровневый и высокоуровневый языки. Выразительная сила этих языков одна и та же, но высокоуровневый язык зачастую гораздо легче для использования и обеспечивает более компактное описание.

Раскрашенные сети Петри, как и обыкновенные, могут быть представлены в графической форме, которая базируется на соот-ветствующем математическом определении (см., например, [114]). Рассмотрим структуру и динамическое поведение CP-сетей на следующем примере.

5.1. Пример системы для моделирования Пусть требуется смоделировать систему простейшей биб-

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

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

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

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

теки. Мы здесь не рассматриваем сдачу книг читателями или взя-

тие зарезервированных книг, так как эта система необходима толь-


160

ко для демонстрации основных свойств и концепций CP-сетей. Сеть, моделирующая эту систему, показана на рис. 63.

5.2. Элементы теории раскрашенных сетей Петри

Раскрашенные сети Петри, как и обычные, представляют со-бой двудольный граф с двумя типами вершин: позициями и пере-ходами. Ориентированные дуги могут соединять только вершины разных типов. Мы будем ссылаться на дуги, которые идут от по-зиции к переходу, как на входящие дуги, а от перехода к позиции – как на исходящие дуги. Позиции, инцидентные входящим дугам, будем называть входными для перехода, а инцидентные выходя-щим дугам – выходными. На рис. 63 позиции представлены эллип-сами, переходы – прямоугольниками. Все вершины сети имеют определенное название. Так, изображенная на рис. 63 сеть содер-жит позиции Users и Employees и переходы Borrow и Hold.

Каждая позиция имеет ряд атрибутов. Тип (colorset) позиции определяет типы маркеров (фишек), которые могут быть туда по-

Readers

HoldBorrow

HoldedOut Available

EmployeesEMPLOYEE READER

BOOKSBOOKS BOOKS

[out<MaxBooks]

1`Librarian1`(Jack,0)++1`(Jill,4)

1`TCPBook++1ÌPBook

bookb ook

book book

1`Libr arian (nam

e, ou

t) (name, out)

(name,

newo

ut)

input(out);output(newout);action(out+1);

C

Declarationscolor BOOKS = with TCPBook | IPBook;color EMPLOYEE = with Librarian;color BooksBorrowed = int;color Name = with Jack | Jill;color READER = product Name*BooksBorrowed;val MaxBooks = 4;

var book:BOOKS;var name:Name;var out, newout:BooksBorrowed;

Рис. 63. Пример сети, моделирующей работу библиотеки


161

мещены. На рис. 63 и далее тип будет изображаться курсивом ря-дом с позицией. Типы, которые мы используем при определении позиций, задаются в блоке определений сети (на рис. 63 блок оп-ределений изображен как прямоугольник, содержащий надпись Declarations). Для нашей сети мы задали пять типов: ReaderName, BooksBorrowed, Reader, Employee и Books. Первые два задают со-ответственно имя читателя и количество взятых книг. Тип Reader является кортежем, первый элемент которого задает имя читателя, а второй представляет количество взятых читателем книг. Для ка-ждой позиции тип должен быть определен. Тип Books задается пе-речислением, как и тип ReaderName, и определяет названия книг.

Набор маркеров, помещенных в определенную позицию, об-разует разметку этой позиции. Например, позиция Users имеет разметку 1`(Jack, 0)++1`(Jill, 4). Эта разметка является начальной для данной позиции. Совокупность разметок всех пози-ций сети называется состоянием сети.

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

Переходы CP-сети могут иметь несколько атрибутов. Нам потребуются только два дополнительных атрибута, кроме имени: охранное выражение (на рис. 63 в квадратных скобках курсивом) и кодовый сегмент (на рис. 63 показан в виде пунктирного прямо-угольника с заглавной буквой C внутри). В охранных выражениях участвуют переменные, которые находятся на входящих дугах пе-рехода. Кодовый сегмент содержит три части: кортеж input, кото-рый определяет, какие переменные участвуют в качестве аргумен-тов в кодовом сегменте; кортеж output, который определяет, какие переменные являются результатом вычислений; раздел action, где находится код для вычислений. Охранные выражения и кодовые сегменты переходов используются при срабатывании раскрашен-ных сетей Петри.


162

5.3. Динамическое поведение раскрашенных сетей Петри

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

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

- охранное выражение перехода истинно при определенном наборе маркеров, удовлетворяющем условию 1.

Например, переход Borrow имеет три входные позиции: Em-ployees, Readers и Available. Входящая дуга из позиции Employees задает набор маркеров, которые должны содержаться в этой пози-ции – 1`Librarian. Входящая дуга из позиции Employees в ка-честве выражения имеет кортеж (name, out), в котором каждый элемент является переменной. Это требование означает, что каж-дая переменная из кортежа должна быть означена каким-то значе-нием. Существуют два корректных означивания этого кортежа: name означена как Jack и out означена как 0 или name означена как Jill и out означена как 4.

Переменные, которые участвуют в выражениях на дугах, инцидентных для перехода, являются локальными для перехода. Другими словами, можно сказать, что для каждого перехода созда-ется “своя копия” этих переменных.

Итак, первый пункт из условия срабатывания перехода вы-полнен (понятно, что существует корректное означивание пере-менной book). Чтобы сработать, охранное выражение out<MaxBooks должно быть истинным. Это возможно только тогда, когда пара (name, out) означена как (Jack, 0). Таким образом, переход Borrow может сработать при следующих означиваниях переменных на входных дугах (набор из всех означенных пере-менных, участвующих в выражениях на входных дугах, в сово-купности с переходом называется означивающим элементом): Borrow: {name=Jack, out=0, b=TCPBook} Borrow: {name=Jack, out=0, b=IPBook}

Также можно заметить, что переход Hold является активным для следующих означивающих элементов: Hold: {name=Jack, out=0, b=TCPBook} Hold: {name=Jack, out=0, b=IPBook}


163

Hold: {name=Jill, out=4, b=TCPBook} Hold: {name=Jill, out=4, b=IPBook}

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

Примером подобных означивающих элементов может слу-жить множество всех элементов перехода Borrow. Элементы, ко-торые не находятся в состоянии конфликта, могут срабатывать па-раллельно. Это в том числе элементы Borrow: {name=Jack, out=0, b=TCPBook} и Hold: {name=Jill, out=4, b=IPBook}.

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

входных позиций; - маркеры помещаются в выходные позиции в зависимости

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

5.4. Временные раскрашенные сети Петри Раскрашенные сети Петри могут быть расширены с помощью

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

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


164

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

5.5. Методы анализа раскрашенных сетей Петри Главное преимущество создания формальных моделей со-

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

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

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

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

Достижимость Если заданы два состояния A и B, можно узнать, существует

ли последовательность срабатываний, ведущая от состояния A к состоянию B.


165

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

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

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

Ограниченность Исследуя граф достижимых состояний, можно узнать коли-

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

Исследование графов достижимых состояний имеет два практических ограничения:

- множество достижимых состояний может быть слишком велико, чтобы храниться в памяти компьютера;

- значение множества достижимых состояний зависит от на-чального состояния.

Тем не менее построение даже неполных множеств дости-жимых состояний может существенно помочь в исследовании свойств моделируемой системы.

5.6. Система моделирования Design/CPN В предыдущих разделах были описаны основные концепции

раскрашенных сетей Петри. Этот раздел посвящен системе Design/CPN, которая предназначена для построения и анализа мо-делей в терминах этого формализма. Эта система представляет со-бой комплект различных средств для редактирования, выполнения и анализа CP-сетей. Опишем кратко компоненты системы, которые использовались в данной работе. Более подробную информацию можно получить в [118, 120, 126 – 129].

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


166

графические элементы (не являющиеся элементами сети) для улучшения внешнего вида модели.

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

– “совмещенные” позиции (fusion places). Возможно образо-вание одного “совмещенного” множества (fusion set) из нескольких позиций. При этом физически помещенные в одно такое множество позиции логически представляют одну позицию, т. е. если одна из позиций множества меняет разметку, то и остальные позиции этого множества меняют разметку на аналогичную. Для соединения под-сетей на различных страницах можно создать на этих страницах по-зиции и объединить их в одно “совмещенное множество”;

– подстановочные переходы (substitution transitions). Иерар-хическая структура модели может создаваться с помощью распо-ложения одной из подсетей на так называемой подстранице и соз-дания подстановочного перехода на странице более высокого уровня. При этом подстановочный переход эквивалентен подсети, расположенной на подстранице. Входящие и выходящие позиции подстановочного перехода называются соответственно входящими и выходящими сокетами. Подстраница содержит позиции, анало-гичные сокетам подстановочного перехода. Эти позиции называ-ются портами. Здесь можно заметить, что сокет и соответствую-щий ему порт содержатся в одном “совмещенном” множестве. Удаление иерархической структуры, заданной с помощью подста-новочных переходов, эквивалентно замене в подсети всех подста-новочных переходов, расположенных на соответствующих под-страницах.

Система Design/CPN широко использует язык CPN ML [101], который является диалектом языка SML [102, 103] (Standard ML). В частности, именно на языке CPN ML пишутся выражения на дугах, охранные выражения и объявляются типы. Различные объявления и выражения на рис. 63 написаны именно на этом язы-ке, хотя кодовые сегменты переходов пишутся на языке SML.


167

Графическое представление раскрашенной сети Петри для ее выполнения трансформируется в исполняемый SML-код модели. Пользователь может выбрать различные виды выполнения: инте-рактивное (при этом изменение разметки при срабатывании пере-ходов видно непосредственно на графе сети) или автоматическое (при этом сеть выполняется до наступления какого-то события, например срабатывания определенного количества переходов).

Исполняемый SML-код модели используется также для гене-рации частичного или полного множества достижимых состояний системы. Визуальный анализ множества достижимых состояний может быть затруднен, если это множество велико. Система Design/CPN строит это множество в памяти, а его анализ выполня-ется с помощью специальной библиотеки SML-функций (см. [126, 127]).


168

Глава 6. Моделируемые спецификации протоколов

Несмотря на то, что для протокола TCP существует стан-дартная спецификация [4, 5], соответствующие документы носят неформальный характер. Из-за этого возможны разночтения спе-цификаций (например, так уже случалось с трактовкой значения поля срочных данных в сегменте, отправляемом протоколом TCP). Другой недостаток неформальной природы спецификации состоит в том, что затруднен анализ протокола, так как невозможно ис-пользовать существующие автоматические средства для анализа свойств протокола. Формальная модель системы была бы также полезна в качестве эталона при разработке новых реализаций про-токола. С момента появления начальной спецификации был сделан ряд дополнений к протоколу, направленных как на исправление ошибок, так и на улучшение различных характеристик (в первую очередь, производительности). Таким образом, желательно, чтобы модель можно было бы модифицировать для представления новых версий протокола.

Большое число работ посвящено исследованию производи-тельности протокола TCP при различных условиях. Например, Кумар в работе [125] использовал стохастическую модель для ис-следования производительности различных версий протокола TCP, предполагая наличие потерь на беспроводной линии; Фолл и Флойд в работе [124] исследовали преимущества алгоритма выбо-рочных подтверждений по сравнению со стандартными алгорит-мами управления потоком.

Тем не менее задача поиска новых алгоритмов управления потоком является актуальной. Одним из новых предложенных ал-горитмов является адаптивный алгоритм управления потоком ARTCP, рассмотренный в первой части книги. Эффективность ра-боты этого алгоритма по сравнению со стандартным показана в работах [111, 113]. Во второй части книги обсуждается проблема построения формальной модели протоколов TCP и ARTCP и предлагается решение этой задачи.

Имеется ряд работ, посвященных исследованию корректно-сти работы протокола TCP. Например, Беловин в работе [104] опи-


169

сывает некоторые проблемы, связанные с корректностью специ-фикации протокола. Ряд ошибок начальной спецификации [4] был учтен при разработке обновленного стандарта протокола [5].

Формализм раскрашенных сетей Петри является хорошо развитым как с теоретической, так и с практической точек зрения. Так, раскрашенные сети Петри были использованы в ряде успеш-ных проектов по исследованию свойств различных протоколов. Например, Клаусен и Йенсен в работе [122] использовали этот формализм для оценки производительности сетевых алгоритмов для высокоскоростных линий связи, в работе [123] те же авторы исследовали работу ATM-сетей. Кроме анализа производительно-сти, с помощью раскрашенных сетей Петри проводилось исследо-вание корректности протоколов. Биллингтон и Гордон в работе [130] использовали раскрашенные сети Петри для анализа кор-ректности спецификации протокола WAP (Wireless Application Protocol). Таким образом, раскрашенные сети Петри являются дос-таточно привлекательным формализмом для моделирования и ана-лиза различных свойств коммуникационных протоколов.

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

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

6.1. Протокол TCP Протокол TCP является основным протоколом транспортно-

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


170

ные аспекты его работы. Базовая спецификация протокола была описана в RFC793 [4]. В ряде последующих документов были опи-саны исправления ошибок и различные дополнения к протоколу. К наиболее важным стоит отнести следующие: RFC1122 [5], в кото-ром разъясняются различные тонкие аспекты работы протокола и проводится работа над ошибками; RFC1323 [6], посвященный улучшению производительности протокола на путях с высоким произведением пропускной способности на задержку передачи); RFC2581 [106], где подробно описан используемый протоколом стандарт алгоритма управления потоком; RFC2018 [105], который вводит механизм выборочных подтверждений, направленный на улучшение производительности протокола при множественной потере сегментов; RFC2883 [107], рассматривающий усовершенст-вование механизма выборочных подтверждений для подтвержде-ния дублированных сегментов; RFC3042 [109], который вводит ал-горитм Limited Transmit, призванный усовершенствовать восста-новление TCP после потерь сегментов. Большинство из этих ново-введений было реализовано в ряде современных операционных систем, таких, как Linux, Windows98, Windows 2000 Server.

6.2. Интерфейс между протоколом TCP и пользовательскими процессами

Как было сказано ранее, пользователями сервиса, предостав-ляемого протоколом TCP, являются пользовательские процессы. Один из вариантов этого интерфейса рассмотрен в документе [4]. Существуют альтернативные подобные интерфейсы, например, интерфейс Berkeley Sockets [84, 85]. Мы будем рассматривать только интерфейс, описанный в начальной спецификации прото-кола [4].

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


171

Вызов OPEN – открытие соединения Перед тем как начинать процесс обмена данными с удален-

ным процессом, соединение необходимо установить. Данный вы-зов предназначен именно для этого и имеет следующий формат: OPEN(local port, foreign socket, active/passive) → local connection name;

В качестве параметров передаются: номер локального порта (local port), который однозначно определяет пользователь-ский процесс; адрес удаленного процесса – так называемый сокет (foreign socket), который состоит из IP-адреса удаленного хоста и номера порта, идентифицирующего удаленный процесс; режим открытия соединения – активный или пассивный. При ус-пешном открытии соединения процессу возвращается локальный идентификатор соединения (local connection name). Одним из способов определения локального идентификатора соединения может быть его задание как комбинации двух сокетов, идентифи-цирующих локальный и удаленный процесс.

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

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

Вызов CLOSE – закрытие соединения После того как пользовательский процесс решил, что он за-

кончил отправлять данные, он может закрыть соединение. Для этого он посылает протоколу вызов следующего формата: CLOSE(local connection name);


172

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

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

Вызов SEND – передача данных удаленной стороне со-единения

Этот вызов предназначен для отправления данных противо-положной стороне соединения. Он имеет следующий формат: SEND(local connection name, buffer addr, bytecount, PUSH, URG);

В качестве параметров вызову передаются: идентификатор соединения, по которому следует отправить данные (local connection name); указатель на буфер, содержащий данные (buffer addr); количество байтов в буфере для передачи уда-ленному концу (bytecount); флаги, которые указывают на ха-рактер данных в буфере.

Если было сделано несколько вызовов SEND, то протокол отправляет данные в порядке их поступления. Вызов SEND можно также отправлять еще не открытым соединениям. При этом снача-ла происходит активное открытие соединения, а уже потом от-правляются данные.

Установка флагов PUSH и URG влияет на характер отправле-ния данных протоколом и на действия получателя при приеме та-ких данных. Дело в том, что протокол отправляет данные не сразу после получения вызова SEND. Он имеет возможность сначала на-капливать данные, а потом их отправлять. Это имеет смысл, на-пример, в случае, если процесс отправляет данные часто и малень-кими порциями. Очевидно, что в этом случае вместо отправления нескольких небольших сегментов лучше подождать и отправить


173

один большой сегмент. Установка флагов действует на процесс фрагментации данных следующим образом. Если установлен флаг PUSH, то отправитель незамедлительно отправляет данные из бу-фера, как только у него появится возможность (учитывая, конечно, алгоритм Нагла [8] ), не ожидая, что от процесса-клиента придет больше данных. При установке флага URG протокол пытается доставить данные процессу-получателю как можно быстрее, ин-формируя удаленную сторону о наличии срочных данных. При рассмотрении алгоритмов работы протокола TCP мы подробнее рассмотрим действия протокола на установку этих флагов.

Самая простая реализация вызова SEND может позволять протоколу не возвращать управление вызывающему процессу до тех пор, пока протокол не отправит все данные из буфера. Однако эта реализация снижает производительность. Более корректная реализация предусматривает параллельное исполнение протокола и процесса-клиента.

Вызов RECEIVE – получение данных При приеме данных от удаленного конца протокол накапли-

вает их во внутреннем буфере. Для того чтобы передать данные из этого буфера процессу-получателю, существует вызов следующего формата: RECEIVE(local connection name, buffer addr, byte-count) → rcvd_bytecount, URG, PUSH;

В качестве параметров вызову RECEIVE передаются: ло-кальный идентификатор соединения (local connection na-me); указатель на буфер, куда нужно поместить данные (buffer addr); максимальное количество данных, которые можно помес-тить в буфер (bytecount). Вызовом возвращаются: количество байтов, реально помещенных в буфер (rcvd_bytecount); флаги PUSH и URG, если они были установлены протоколом-отправи-телем данных. Если соединение, которому адресован этот вызов, не было создано, возвращается сообщение об ошибке.

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


174

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

Вызов ABORT – прерывание соединения Пользователь должен иметь возможность оборвать соедине-

ние в любой момент. Для осуществления этого действия служит вызов, имеющий следующий формат: ABORT(local connection name);

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

Возврат протоколом сообщений пользовательскому процессу

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

6.3. Интерфейс между протоколами TCP и IP Протокол TCP использует сервис, предоставляемый прото-

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


175

Сегмент имеет сложную структуру, показанную на рис. 64.

Номера портов идентифицируют пользовательские процессы, уча-ствующие в обмене сегментами. Исходный порт задает адрес про-цесса-отправителя сегмента, а конечный порт определяет процесс-адресат сегмента. Каждый байт данных, отправляемых через со-единение, имеет уникальный 32-битный порядковый номер. Поле SEG.SEQ определяет номер первого байта данных в сегменте. По-ле SEG.ACK хранит значение номера байта, который отправитель данного сегмента подтверждает. Протокол TCP использует куму-лятивную стратегию подтверждений, т. е. подтверждаются все байты по SEG.ACK-1 включительно. Смещение поля данных ука-зывает, где заканчивается заголовок сегмента и начинаются дан-ные. Далее следуют 6 битов резерва, после которых идут различ-ные управляющие флаги. Стоит отметить, что флаги SYN и FIN имеют отдельные порядковые номера в последовательности пере-дачи. В поле SEG.WND содержится размер свободного буферного пространства у отправителя этого сегмента. Код циркулярного контроля содержит контрольную сумму, которая используется ме-ханизмом обнаружения ошибок. Значение указателя на срочные данные, прибавленное к значению поля SEG.SEQ, указывает на место расположения последнего байта срочных данных.

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

номер исходного порта16 бит

код циркулярного контроля16 бит

смещениеполя данных

4 битарезерв

бит6FIN

SYN

RST

PSH

ACK

URG

порядковый номер первого байта данных (32 бита

SEG.SEQ)

дополнительные опции (если есть), заполнитель до размера, кратного 32переменной длины

данныепеременной длины

номер подтверждаемого байта (32 бита

SEG.ACK)

номер конечного порта16 бит

размер окна (16 бит

SEG.WND)

указатель на срочные данные (16 бит

SEG.UP)

Рис. 64. Структура сегмента протокола TCP


176

низмы управления. Дополнительные опции могут иметь произ-вольный размер, но необходим заполнитель для объема, кратного 32 битам. После них расположены данные, которые также могут иметь произвольный размер. Мы рассмотрим конкретные опции подробнее, когда будем описывать отдельные алгоритмы работы протокола.

При отправлении сегмента протокол сам принимает решение о его размере. Существуют следующие ограничения на размеры дополнительных опций и данных. Согласно стандарту, размер по-ля дополнительных опций может быть максимум 40 байтов. Каж-дая сетевая технология имеет так называемую максимальную единицу передачи (Maximum Transmission Unit – MTU), в которую должен уместиться и IP-пакет, и сегмент TCP со своими заголов-ками и данными. Также нужно отметить, что протокол IP может отправить максимум 65 535 байтов в одном IP-пакете.

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

Далее мы рассмотрим различные аспекты работы протокола TCP.

6.4. Управление соединением В процессе работы протокол TCP управляет логическим со-

единением между процессом на одном хосте и удаленным процес-сом на другом. Чтобы поддерживать соединение в рабочем со-стоянии, протокол должен знать значения некоторых параметров. Спецификацией предполагается, что значения этих параметров хранятся в структуре, называемой контрольным блоком соедине-ния (Transmission Control Block – TCB). Спецификация не накла-дывает каких-то условий на формат этой структуры, но для работы TCB должен содержать значения локального и удаленного соке-


177

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

Рассмотрим сначала переменные, определяющие последова-тельность отправляемых данных:

SND.UNA – номер первого неподтвержденного байта; SND.NXT – номер следующего байта для передачи уда-

ленной стороне; SND.WND – оценка количества свободного буферного про-

странства на другой стороне соединения; SND.UP – номер последнего байта срочных данных. Переменные, отвечающие за прием данных: RCV.NXT - номер следующего ожидаемого байта данных; RCV.WND - количество свободного буферного пространства; RCV.UP - указатель на последний байт срочных данных. На рис. 65 представлено пространство номеров для отправ-

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

Каждый этап работы соединения характеризуется состояни-

ем. Таким образом, работая, соединение переходит из одного со-стояния в другое. Диаграмма переходов показана на рис. 66.

1 1 2 3SND.UNA RCV.NXT RCV.NXT+

RCV.WND

SND.NXT

SND.NXT+SND.WND

2 3 4

1. Номера подтверждённых байтов.2. Номера неподтверждённых байтов.3. Номера для следующей передачи.4. Номера для будущей передачи.

1. Номера полученных байтов.2. Номера байтов для следующего приёма.3. Номера байтов для будущего приёма.

Рис. 65. Пространство номеров для отправления (слева)

и получения (справа) данных


178

Условно все состояния можно разделить на три класса. К

первому классу можно отнести состояния, когда соединение от-крывается – это состояния SYN_SENT, LISTEN и SYN_RECEIVED. Ко второму классу можно отнести состояние, ко-гда возможен дуплексный обмен данными между сторонами, – это состояние ESTABLISHED. К третьему классу относятся состояния, когда происходит процесс закрытия соединения, – состояния CLOSE_WAIT, FIN_WAIT1, FIN_WAIT2, LAST_ACK, CLOSING и TIME_WAIT. Соединения, относящиеся к первому классу, еще называют несинхронизированными.

Остальные соединения называются синхронизированными. Состояние CLOSED является фиктивным, так как реально соедине-

FIN_WAIT1

FIN_WAIT2

CLOSING CLOSE_WAIT

TIME_WAIT LAST_ACK

ESTABLISHED

SYN_RECEIVED

получено: ACK

получено: FIN

отправлено: ACKполучено: FIN

получено: FIN, ACK


процесс закрыть:

отправлено: FINпроцесс

закрыть:

отправлено: ACK

получено: FIN




отправлено: FIN

процесс: закрыть

отправлено: FINп роц ес с

з акрыть

:

получено: SYN, ACK



SYN_SENT

LISTEN

CLOSED

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

активное открытиеотправлено: SYN

процесс: передача данных

получено: SYN

отправлено: SYN, ACK

отправлено: SYN, ACKполучено: SYN

получено: RST

Рис. 66. Диаграмма состояний TCP-соединения


179

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

Открытие логических соединений Согласно [4], для открытия соединений протокол TCP ис-

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

В первом случае одна сторона выступает в качестве инициа-тора создания логического соединения, а вторая ждет запроса на открытие соединения. В этом случае предпринимаются следую-щие шаги (на рис. 67 слева).

Запрашивающая, активная сторона (на рисунке – TCP A) на-

ходится в состоянии SYN_SENT и отправляет сегмент, который содержит: установленный флаг SYN; свой исходный номер после-довательности передачи (ISN – Initial Sequence Number); размер окна; специальные опции (например, опцию включения алгоритма выборочных подтверждений), в том числе опцию MSS, содержа-щую максимальный размер сегмента (MSS – Maximum Segment Size), который эта сторона может принять.

Пассивная сторона (на рисунке – TCP B), получив этот сег-мент, переходит из состояния LISTEN в состояние SYN_RECEIVED и отправляет сегмент, который содержит: установленный флаг SYN; подтверждение о приеме сегмента от удаленной стороны; свой ISN; свой размер окна; опции, включая свой MSS.

Получив этот сегмент, TCP A переходит из состояния SYN_SENT в состояние ESTABLISHED и отправляет сегмент, со-

TCP A TCP ATCP B TCP B

SYN_RECEIVED SYN_RECEIVEDSYN_RECEIVED

SYN_SENTSYN

SYN, ACK SYN, ACK

SYN

SYN ACK,

ACK

SYN

SYN_SENTSYN_SENTLISTEN

ESTABLISHED

ESTABLISHED ESTABLISHEDESTABLISHED Рис. 67. Открытие соединения: нормальный сценарий (слева)

и одновременное открытие (справа)


180

держащий подтверждение о приеме SYN-сегмента пассивной сто-роны. После приема последнего сегмента пассивная сторона пере-ходит в состояние ESTABLISHED.

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

- обе стороны посылают сегменты, идентичные описанным в пункте 1 обычного сценария;

- после приема этих сегментов обе стороны переходят из со-стояния SYN_SENT в состояние SYN_RECEIVED и посылают друг другу сегменты, описанные при рассмотрении нормального сцена-рия в п. 2;

- после получения последних сегментов стороны переходят в состояние ESTABLISHED.

Таким образом, цель установки соединения – переход обеих сторон в состояние ESTABLISHED – выполненв, и можно начи-нать процесс обмена данными. Однако так как сеть не надежна, сегмент, содержащий SYN, может быть потерян. Эта ситуация ис-правляется с помощью механизма повторной передачи SYN-сег-ментов (механизм повторной передачи рассматривается в п. 6.5). Стоит еще отметить, что после установки соединения максималь-ный размер сегментов, которые отправляются по этому соедине-нию, должен быть минимальным из размеров MSS обеих сторон. Если же размер MSS не отправлялся, то MSS считается равным 536 байтам.

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

три сегмента, то для того, чтобы разорвать – четыре. Это объясня-ется тем, что соединение может быть в наполовину закрытом со-стоянии. Так как соединение полнодуплексное (данные могут пе-редвигаться в каждом направлении независимо от другого направ-ления), каждое направление должно быть закрыто независимо от другого. Правило заключается в том, что каждая сторона должна послать в сегменте установленный флаг FIN, когда передача дан-ных завершена. Получение установленного FIN означает только


181

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

Можно сказать, что та сторона, которая первой закрывает соединение (отправляет первый FIN), осуществляет активное за-крытие, а другая сторона (которая приняла этот FIN) осуществля-ет пассивное закрытие. Оба случая рассмотрены на рис. 68.

6.5. Управление передачей Как известно, основная задача протокола TCP состоит в

обеспечении надежной передачи данных от одного конца соедине-ния другому.

Управление окном и тактика подтверждений Итак, главной задачей, стоящей перед протоколом TCP яв-

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

TCP A TCP ATCP B TCP B

ACK

FIN, ACK

ESTABLISHEDESTABLISHED ESTABLISHED ESTABLISHED

FIN_WAIT1 FIN_WAIT1 FIN_WAIT1

close close close

2MSL timeout 2MSL timeout 2MSL timeout

closeFIN_WAIT2 CLOSINGFIN, ACK FIN, ACK

ACK ACK

CLOSING

TIME_WAIT TIME_WAIT TIME_WAIT

LAST_ACK

CLOSE_WAIT

CLOSED

FIN, ACK

ACK

CLOSED CLOSED CLOSED Рис. 68. Закрытие логических соединений: нормальное развитие

событий (слева) и одновременное закрытие (справа)


182

бодного буферного пространства получателя. В зависимости от объема свободного буферного пространства получатель данных “открывает” окно, уведомляя, какой объем данных он готов при-нять. На ранних стадиях развития протокола было замечено, что в сетях могут возникать перегрузки при очень низком использова-нии ресурсов [8]. Были выявлены три причины этого: протокол, посылающий очень много подтверждений; приложения, вызы-вающие протокол для отправления небольшого количества ин-формации; обновление окна очень маленькими порциями. Чтобы устранить эти три причины неэффективной работы протокола бы-ли предложены следующие алгоритмы.

Согласно стандарту, описанному в [5] для подтверждения данных, получатель должен использовать алгоритм задержанных подтверждений (delayed acknowledgements). Этот алгоритм накла-дывает следующие условия на отправление подтверждений:

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

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

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

- генерируется немедленное подтверждение, если сегмент пришел вне своей очереди.

Кроме этого алгоритма, стандартом [5] предписывается ис-пользование алгоритма избегания “синдрома глупого окна” (Silly Window Syndrome avoidance algorithm – SWS avoidance algorithm). Алгоритм SWS предписывает получателю данных производить обновление окна, если выполняется следующее условие: reduction≥min(Fr×BufferSize, EffMSS), где Fr=1/2.

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

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


183

делах которого данные могут быть отправлены, равно U=SND. UNA+SND.WND-SND.NXT. В этом случае со стороны отправителя данных алгоритм SWS накладывает следующие условия на размер отправляемых сегментов:

- если min(D, U)≥EffMSS , то отправляется сегмент мак-симального размера;

- если данные пришли от пользовательского процесса с уста-новленным флагом PUSH и выполняется D≤U & [SND.NXT= SND.UNA], то отправляемый сегмент заключает D байтов данных;

- если min(D, U)≥Fs×MaxSndWnd & [SND.NXT= SND.UNA], то отправляется также D байтов данных (рекомендуе-мое значение Fs=1/2);

- если данные пришли с флагом PUSH и произошел перекры-вающий тайм-аут, то передаются имеющиеся данные;

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

Условия в квадратных скобках используются, когда для со-единения включен алгоритм Нагла (Nagle algorithm), описанный в [8]. Этот алгоритм особенно эффективен, когда пользовательский процесс передает информацию малыми порциями.

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

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

Основой для установки таймера повторной передачи являет-ся определение времени возврата (RTT – Round-Trip Time), соот-ветствующего данному соединению. Время возврата равно време-ни передачи пакета с данными от отправителя к получателю плюс время передачи подтверждения этих данных обратно. В процессе работы протокола это время (далее – просто RTT) может динамич-но изменяться. Более того, очень сложно, даже зная это время, точно установить тайм-аут повторной передачи (RTO –


184

Retransmission Time-Out). Установка RTO с как можно более точ-ным значением необходима для лучшей производительности про-токола. Если RTO слишком мало, то повторная передача произой-дет до прихода подтверждения и, тем самым, увеличится нагрузка сети. Если же RTO слишком велико, то некоторую часть времени канал будет использоваться неэффективно.

Стандарт для расчета значения таймера и установки тайм-аута описан в [108]. Согласно этому документу, эти величины под-считываются следующим образом. В контрольном блоке соедине-ния объявляются две переменные: SRTT (smoothed RTT – сгла-женное RTT) и RTTVAR (Round-Trip Time Variation).

Алгоритм функционирует следующим образом: - пока не было измерения RTT, RTO устанавливается рав-

ным 3 секундам; - как только сделано первое измерение RTT = R, производят

следующие операции: SRTT=R RTTVAR=R/2; - когда сделано некоторое по счету измерение RTT =R',

производят следующие вычисления: RTTVAR=(1-b)× RTTVAR+ b×|SRTT-R'|, b=1/4 SRTT=(1-a)×SRTT+a×R', a=1/8;

- значение RTO вычисляется после каждого пересчета зна-чений переменных SRTT и RTTVAR следующим образом: RTO=SRTT+k×RTTVAR, k=4;

- значение RTO округляется до 1 секунды, если оно было меньше;

- максимальное значение RTO может быть 60 секунд. Измерения RTT необходимо брать с учетом алгоритма Карна

[7], т. е. не учитывать измерения для повторно переданных сег-ментов.

Рассмотрим теперь, как необходимо управлять таймером по-вторной передачи. В документе RFC2988 [108] рекомендуется ис-пользовать следующий алгоритм:

- каждый раз при отправлении сегмента с данными (включая ретрансляции сегментов) проверять, запущен таймер или нет. Если нет, запускать его с текущим значением RTO;

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

- когда приходит подтверждение новых данных, перезапус-тить таймер с текущим значением RTO;


185

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

- передать самый первый сегмент из очереди ретрансляции; - значение RTO пересчитывается по следующей формуле:

RTO=RTO×2; - перезапустить таймер с текущим, пересчитанным значени-

ем RTO. Допускается инициализация SRTT и RTTVAR после несколь-

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

Другие таймеры, используемые протоколом TCP Кроме таймера повторной передачи, протокол TCP исполь-

зует устойчивый и 2MSL таймеры. Рассмотрим их назначение подробнее.

Устойчивый таймер устанавливается одним концом соеди-нения, когда у него есть данные, которые необходимо отправить, однако процесс передачи был приостановлен, так как другой конец соединения объявил окно нулевого размера. Подтверждение полу-чателя, возможно содержащее обновление окна, может быть поте-ряно в сети. В этом случае получатель будет ждать от отправителя данные (так как он послал отправителю уведомление о наличии свободного места), а отправитель будет ждать обновления окна, чтобы продолжить передачу. Чтобы выйти из подобного тупика, отправитель использует устойчивый таймер, с помощью которого осуществляется периодический опрос получателя на предмет, не был ли увеличен размер окна. Сегменты, которые посылает отпра-витель, называются пробами окна (window probes).

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

Таймер 2MSL используется при полном закрытии соедине-ния. Он запускается при переходе соединения в состояние TIME_WAIT. Это ожидание необходимо для того, чтобы быть уве-ренным, что в сети нет сегментов, принадлежащих соединению.


186

Управление потоком и предотвращение перегрузки сети Если скорость поступления данных в сеть превышает ско-

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

Стандарт протокола по управлению потоком описан в [106, 110]. Этот документ регламентирует использование четырех меха-низмов для управления потоком: замедленный старт (slow start), предотвращение перегрузки (congestion avoidance), быструю ретрансляцию (fast retransmit) и быстрое восстановление (fast recovery). Рассмотрим эти алгоритмы подробнее.

Для реализации этих алгоритмов в контрольный блок соеди-нения добавляются еще две переменные: CWND и SSTHRESH. В пер-вой переменой хранится результат попыток определить значение текущей пропускной способности сети. Вторая переменная служит своеобразным маркером, определяющим, какой механизм управле-ния потоком используется. Пусть SMSS представляет MSS отпра-вителя данных, тогда, согласно [110], начальное значение перемен-ной CWND вычисляется по следующей формуле: 4×SMSS, max(2×SMSS, 4380)).

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

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


187

рованных данных. Замедленный старт прекращает работу, когда CWND≥SSTHRESH или обнаружена перегрузка сети.

Алгоритм предотвращения перегрузки используется для оп-ределения дополнительной пропускной способности. Во время ра-боты этого алгоритма CWND должно увеличиваться на значение SMSS за время, равное RTT. Согласно [106], формула CWND= =CWND+SMSS×SMSS/CWND дает приемлемую аппроксимацию для соответствия этому принципу. Алгоритм предотвращения пере-грузки прекращает работу, когда обнаружена перегрузка сети.

При срабатывании таймера повторной передачи, т. е. когда ожидается, что сегмент потерян, значения переменных SSTHRESH и CWND пересчитываются следующим образом: SSTHRESH=max ((SND.NXT-SND.UNA)/2, 2×SMSS) и CWND=SMSS.

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

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

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

- потерянный сегмент ретранслируется, и CWND пересчиты-вается следующим образом: CWND=SSTHRESH+3×SMSS;

- для каждого нового пришедшего дублированного подтвер-ждения значение переменной CWND увеличивается на размер SMSS;

- новый сегмент может быть отправлен, если позволяют зна-чения CWND и объявленного окна получателя (SND.WND);

- когда приходит подтверждение новых данных, значение CWND устанавливается равным SSTHRESH.


188

6.6. Расширения протокола TCP

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

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

Для решения этой проблемы был предложен алгоритм выбо-рочных подтверждений (Selective Acknowledgements – SACK), который описывается в [105]. При установке соединения в SYN-сегментах отправ-ляется опция разрешения SACK (SACK-permitted option). С помощью этого механизма обе стороны догова-риваются о возможности использова-ния стратегии выборочных подтвер-ждений.

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

Опция SACK, определяющая n блоков, будет иметь размер 8×n+2 байтов. На опции стандартом протокола TCP выделяется максимум 40 байтов. Таким образом, можно задать максимум 4 блока. Однако авторами этого алгоритма предполагается исполь-зование опции SACK совместно с опцией временной метки, кото-

Левый край 1-го блока

Левый край -го блокаn

Правый край 1-го блока

Правый край -го блокаn

. ..

Тип=5 Длина

Рис. 69. Формат опции

SACK


189

рая занимает 10 байтов (плюс два байта дополнения). В этом слу-чае опция SACK может определить только 3 блока.

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

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

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

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

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

Дальнейшее развитие алгоритм выборочных подтверждений получил в [107]. Этот документ определяет использование выбо-рочных подтверждений для индикации о пришедших получателю дублированных сегментах. Первый блок опции SACK с индикаци-ей о пришедшем дублированном сегменте назовем D-SACK. В общих чертах построение опции SACK с учетом этого алгоритма сводится к следующему:

- блок D-SACK используется только для сообщения о при-шедших дублированных данных;

- каждый дубликат полученных данных отражается только в одном блоке D-SACK (т. е. если получатель отправляет два D-SACK-блока, это означает, что пришло два дубликата);


190

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

- если D-SACK-блок сообщает о пришедшей дублированной последовательности данных, левый край которой меньше SND.UNA, то второй SACK-блок должен задавать этот (возможно больший) блок данных;

- остальные блоки формируются, как это показано в [105].

Масштабирование окна Производительность протокола определяется не только сво-

бодной пропускной способностью сети, но и произведением про-пускной способности и времени возврата (можно назвать это про-изведение емкостью). Емкость пути определяет максимальное ко-личество данных, которое можно отправить по этому пути для достижения максимальной производительности, т. е. для достиже-ния максимальной производительности размер окна можно огра-ничить сверху емкостью пути. Если посмотреть на поле сегмента SEG.WND, то можно заметить, что его размер равен 16 битам. Та-ким образом, максимально можно задать окно размером 65 535 байтов. Очевидно, что могут существовать пути, емкость которых больше этого значения. Таким образом, при работе на этих путях невозможно добиться максимальной производительности при ис-пользовании стандартного метода задания размера окна. В [6] оп-ределяется механизм масштабирования окна, помогающий пре-одолеть это обстоятельство. В этом документе вводится новая оп-ция масштабирования окна, которая несет информацию о коэффи-циенте масштабирования. Данная опция отправляется только один раз – при установке соединения – и используется как для инициа-лизации алгоритма, так и как предложение удаленной стороне ис-пользовать масштабирование окон. Согласно [6], предполагается управлять масштабированием окон следующим образом:

- размеры всех окон рассматриваются как 32-битовые значе-ния;

- контрольный блок соединения расширяется двумя пере-менными Rcv.Wnd.Scale и Snd.Wnd.Scale, которые являют-ся масштабирующими коэффициентами соответственно для раз-мера окон приема и передачи;


191

- если протокол получает коэффициент масштабирования в SYN-сегменте, он должен отправить свой коэффициент Rcv.Wnd.Scale, даже если он равен единице;

- если в ответ на свой SYN-сегмент протокол не получает опции масштабирования окна, все масштабирующие коэффициен-ты обнуляются;

- при отправлении сегмента поле SEG.WND заполняется сле-дующим образом: SEG.WND=RCV.WND>>Rcv.Wnd.Scale;

- при получении сегмента и обработке его поля SEG.WND настоящее окно вычисляется так: SND.WND=SEG.WND<<Snd. Wnd.Scale (здесь мы используем << и >> для обозначения по-битового сдвига соответственно влево и вправо).

Опция временной метки Опция временной метки (timestamp option) вводится в [6].

Там же описан ряд алгоритмов, использующих эту опцию. Формат опции временной метки показан на рис. 70.

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

образной маркировки сегментов. Согласно спецификации [6], у каждой из сторон, составляющих соединение, есть так называемые “помечающие часы” (timestamp clock). При отправлении сегмента текущее значение этих часов помещается в поле TSVal, а послед-нее значение временной метки, пришедшей от удаленного конца, помещается в поле TSEcr. Естественно рассматривать помечаю-щие часы как монотонно возрастающую последовательность; бо-лее того, помечающие часы сторон, составляющих соединение, не синхронизированы. Спецификация [6] не указывает, с какой часто-той должны идти эти часы, однако рекомендует, чтобы они шли со скоростью 1…1000 тиков в секунду (в спецификации скорость ча-сов еще называется гранулярностью).

Рассмотрим теперь алгоритмы, которые, согласно [6], долж-ны быть реализованы с помощью опции временной метки. Первым

Тип=8 Длина=10 Значение метки(TSVal)

Эхо метки(TSEcr)

Рис. 70. Формат опции временной метки


192

рассмотрим алгоритм RTTM (Round-Trip Time Measurement) для измерения времени возврата. При использовании обычного метода подсчета RTO отправитель берет пробы RTT и пересчитывает па-раметры SRTT и RTTVAR по формулам, которые были описаны в п. 6.5. Однако если он будет брать пробы очень часто или очень редко, то это приведет к тому, что устанавливаемый тайм-аут по-вторной передачи не будет отражать истинное положение дел. Эта ситуация с большей вероятностью может проявиться на высоко-скоростных каналах. Обычно отправитель берет одну пробу за время RTT, однако опять же это не является оптимальным. Рассу-ждения на эту тему можно найти в [6].

Алгоритм RTTM упрощает забор проб RTT, более того, про-бы могут браться и для ретранслированных сегментов. Напомним, что при отправлении мы помечаем сегмент временной меткой, а получатель с подтверждением в получении этого сегмента отправ-ляет нам ее эхо. Тогда разница между текущим значением времен-ных часов и значением SEG.TSEcr, умноженная на грануляр-ность часов, дает нам точное измерение RTT. Это и есть механизм RTTM.

В целом алгоритм для обработки временных меток для син-хронизированного соединения, согласно [6], выглядит следующим образом:

- в контрольный блок соединения добавляются две новые переменные: TSRecent и LastACKSent. Первая переменная со-держит значение временной метки, которое нужно отразить. Во второй переменной хранится значение поля SEG.ACK последнего отправленного сегмента;

- если для очередного полученного сегмента выполняется условие SEG.SEQ≤LastACKSent<SEG.SEQ+SEG.LEN, то при-сваиваем значению переменной TSRecent значение SEG.TSVal. В противном случае значение SEG.TSVal игнорируется;

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

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

Рассмотрим теперь алгоритм PAWS (Protect Against Wrapped Sequence Numbers – защита от перехода номеров последовательно-сти через ноль). Основная идея этого алгоритма состоит в том, что


193

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

Значения временной метки, отправляемые в SYN-сегментах при установлении соединения, служат для инициализации алго-ритма. Сам алгоритм PAWS формулируется в виде следующих правил:

- если в очередном полученном сегменте есть опция времен-ной метки и выполняется условие SEG.TSVal<TSRecent, то пришедший сегмент является старым дубликатом и необходимо отправить подтверждение вида: <SEG.SEQ=SND.NXT> <SEG.ACK = RCV.NXT> <CTL=ACK>, отбросив сегмент;

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

- обработать сегмент, как это указано в [4]. Стоит отметить, что значение временной метки проверяется

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

Алгоритм Limited Transmit Еще одна оптимизация стандартного алгоритма управления

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


194

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

- позволяет размер открытого окна на удаленном конце со-единения;

- количество данных в транзите останется меньшим или рав-ным значению CWND плюс два сегмента.

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

6.7. Протокол ARTCP Протокол ARTCP (Adaptive Rate TCP) был предложен в ра-

ботах [111 – 113]. Этот протокол предлагает принципиально новый метод управления потоком, основанный на управлении скоростью передачи сегментов в сеть.

Этот протокол использует временные характеристики пото-ка такие, как время возврата и значение оценки пропускной спо-собности сети, в качестве аргументов. Как показано в [111], алго-ритм ARTCP имеет следующие преимущества по сравнению со стандартным алгоритмом управления потоком:

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

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

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

- алгоритм ARTCP допускает совместную с протоколом TCP реализацию.

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


195

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

В [111] обосновывается, что это значение, полученное от-правителем, будет являться оценкой свободной пропускной спо-собности сети. Для передачи значения оценки пропускной способ-ности в сегмент вводятся новые дополнительные опции, благодаря которым этот процесс возможен.

Адаптация скорости передачи потока протоколом ARTCP происходит в пяти режимах, показанных на рис. 71.

Ускоренныйстарт

Мультипликативныйсброс

Мультипликативныйсброс

Тонкаянастройка

Восстановление

Грубая настройка

СТАРТ СТОП

Рис. 71. Схема работы алгоритма ARTCP


196

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

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

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

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

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


197

Глава 7. Сетевые модели протоколов

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

7.1. Иерархическая структура модели Конструируемая модель состоит из набора страниц, иерар-

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

Как можно видеть на р ис. 7 2 , вся CP-сеть состоит из двух основных частей: части, которая моделирует обработку различных вызовов пользователя (страница TCPCallProcessor), и части, кото-рая отвечает за передачу и обработку полученных сегментов (страница TCPTransfer). Страница Timer2MSL моделирует работу 2MSL-тайм-аута.

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


198

Моделирование процесса передачи и обработки сегментов

моделируется с помощью подстраниц страницы TCPTransfer. Она содержит части, ответственные за передачу сегментов в сеть (под-страница TCPSender), обработку пришедших сегментов (подстра-ница TCPReceiver) и служебную подстраницу Scheduler.

Страница TCPSender содержит подстраницы, ответственные за моделирование передачи сегментов с данными (страница DataSend), передачи служебных сегментов-подтверждений или SYN-сегментов (страница ServiceSend) и повторную передачу сегментов (страница Retransmits).

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

TCPCallProcessor

OpenCall

AbortCall

SendCall

ReceiveCall

RespondCalls

CloseCall

TCPLayer Timer2MSL

TCPSender

TCPTransfer Scheduler

TCPReceiver

SYNProcessing

Preprocessing

Processing

DiscardSegment

ResetConnection

DataSend

Retransmits

ServiceSend

Рис. 72. Иерархия страниц модели


199

странице Preprocessing. Обычная обработка потока сегментов в порядке номеров последовательности передачи моделируется с помощью страницы Processing. Отбрасывание некорректных сег-ментов, адресатом которых является соединение, находящееся в состоянии CLOSED, моделируется с помощью страницы DiscardSegments. Страница ResetConnection используется для моделирования обработки полученных сегментов, которые сбра-сывают соединение.

Служебная страница Scheduler используется для моделиро-вания передачи сегментов с заданной скоростью. Эта страница ис-пользуется при моделировании протокола ARTCP.

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

7.2. Моделирование обработки вызовов пользователя

Страница OpenCall – создание соединения Страница OpenCall используется для обработки вызова поль-

зователя OPEN. Подсеть на этой подстранице используется для изъ-ятия вызова OPEN из очереди, находящейся в позиции UserCalls, и управления служебными структурами протокола. Для удобства вос-приятия мы разделили подсеть, расположенную на этой странице, на несколько частей. Рассмотрим эти части подробнее.

На рис. 73 изображена часть, отвечающая за моделирование обработки корректного вызова OPEN. Эта подсеть содержит пере-ходы Open и ForceActive. Первый переход моделирует обычный сценарий открытия соединения, которое находилось в закрытом состоянии, а с помощью второго моделируется активное открытие изначально пассивно открытого соединения.

Рассмотрим охранное выражение перехода Open – условие его активации. Он срабатывает, во-первых, если первым в списке UserCalls содержится вызов OPEN (это проверяется с помощью функции notopen), а во-вторых, если вызов корректный с точки зрения спецификации (проверяется с помощью функции checkopen).


200

CO

NLI

STH

OST

PARA

MS

USE

RRE

SPO

NSE

SC

TCB

USE

RCA

LLS

RET

RQ

UEU

E

TIM

ER2M

SL

RC

VCAL

LS

CO

NSE

GM

ENTS

SND

CALL

S

ACKT

IMER

CO

NBU

FFER

Forc

eAct

ive

Ope

n

Hos

tPar

ams

Dat

aBuf

fers

ACK

Tim

er

Send

Calls

RcvC

alls

Tim

er2M

SL

RetrQ

ueue

SegB

uffe

r

Conn

ectio

nsTC

BRe

spon

ses

Use

rCal

ls

[If n

otop

en(u

call)

then

fals

e el

seco

ncls

tate

(cls

t, uc

all)=

CLO

SED

and

also

chec

kope

n(uc

all,

clst)

=er

r_no

erro

r]

ucall

::uca

ll s

ucall

::uca

lls

ucall

s

(new

id(cl

s t),

1`(n

ewid

(clst

), IN

BUF

(Inpu

tBuf

fer.i

nitb

uf(h

par))

)++

1`(n

ewid

(clst

), O

UTB

UF

(Out

putB

uffe

r.ini

tbuf

))

HostP

arams.u

pdate

(hpa

r, tim

e())

hpar

addcon(c

lst, uc

all, h

par)

clst

clst, hpar, time())

createcon(getoc(ucall),

resp^ [openresp(newid(clst),

getoc(ucall))]

resp

ucall

s

ACKT

imer.

nilti

mer)

(newid(c

lst), nil)

(newid(clst), nil)

(newid(clst)

, nil)

(new

id(c

lst),

Timer2

MSL

.nilt

imer

)(n

ewid

(clst

, Ret

rque

ue.e

mpt

yque

ue)

tcb

newtcb

clst

updconlis

t(clst,

newtcb

)

hpar

HostP

aram

s.upd

ate(hp

ar, tim

e())

[if n

otop

en(u

call)

then

false

els

e co

ncls

tate

(cls

t, uc

all)=

LIST

EN a

ndal

soch

ecko

pen(

ucal

l, cl

st)=

err_

noer

ror]

input(ucall, tcb, hpar);

output(newtcb);

action

(opencon(ucall, tcb, hpar, time()));C

Ри

с. 7

3. М

одел

иров

ание

обр

абот

ки к

орре

ктно

го в

ызо

ва O

PEN


201

При срабатывании перехода Open происходят следующие действия. Во-первых, с помощью добавления маркеров в соответ-ствующие позиции создаются различные служебные структуры: очередь повторной передачи (позиция RetrQueue), 2MSL-таймер (позиция Timer2MSL), буферы вызовов (позиции RcvCalls и SendCalls) и данных (позиция DataBuffers), таймер для отправле-ния подтверждений (ACKTimer) и контрольный блок соединения (позиция TCB). При создании этих структур происходит выбор ло-кального идентификатора соединения с помощью функции newid. Во-вторых, происходит добавление элемента в маркер-список в позиции Responses, который содержит реакцию прото-кола на обработку вызова. В-третьих, происходит добавление от-крываемого соединения в маркер-список работающих соединений, находящийся в позиции Connections. В-четвертых, происходит обновление маркера в позиции HostParams. Это делается для об-новления значения ISN. Переход ForceActive срабатывает, только если поступивший вызов является корректным (проверяется также с помощью функции checkopen) и направлен соединению, нахо-дящемуся в состоянии LISTEN. При срабатывании этого перехода происходит следующее. Во-первых, обновление маркера, задаю-щего контрольный блок соединения (реализуется с помощью функции opencon в кодовом сегменте перехода). Во-вторых, об-новляется элемент списка в позиции Connections, соответствую-щий данному соединению. В-третьих, аналогично, как и при сра-батывании перехода Open, происходит обновление маркера в по-зиции HostParams.

Для обработки некорректных с точки зрения спецификации вызовов OPEN служит подсеть, изображенная на рис. 74. То, что получен некорректный вызов OPEN, моделируется с помощью ус-ловия checkopen(ucall, clst)≠err_noerror . При сраба-тывании перехода Error в список Responses добавляется реакция протокола на этот вызов, которая формируется с помощью функ-ции error.

Страница SendCall – передача данных протоколу Обработка входящего вызова SEND происходит с помощью

подсетей, изображенных на рис. 75 и 76. В оригинале эти подсети


202

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

Показанная на рисунке рис. 75 подсеть содержит переходы

AcceptData и ForceActive. Переход AcceptData используется для принятия вызова для обслуживания. Этот переход срабатывает, если протоколом получен корректный вызов SEND (проверяется с помощью функции checksend) и соединение, которому предна-значен вызов, не находится в состоянии LISTEN. При этом дан-ные, связанные с вызовом, помещаются в буфер для последующей передачи (обновляется значение маркера в позиции DataBuffers) и сам вызов помещается в буфер вызовов, находящийся в позиции SendCalls. Обновление маркера контрольного блока соединения необходимо для моделирования передачи срочных данных.

Переход ForceActive моделирует обработку вызова SEND для соединений, находящихся в состоянии LISTEN. При срабаты-вании этого перехода совершаются практически те же действия, что и при срабатывании перехода ForceActive на странице OpenCall, описанной в предыдущем разделе. Единственным отли-чием является помещение вызова в буфер SendCalls и связанных с ним данных в буфер для передаваемых данных.

USERCALLS

USERRESPONSES

CONLIST

UserCalls

Connections

Responses

Errorucall::ucalls

ucalls

clst

resp

res ^^p[

checkopen(ucall, clst))]

error(getclid(c st,lucall), ucall,

[if notopen(ucall) then false elsecheckopen(ucall, clst)<>err_noerror]

Рис. 74. Моделирование обработки некорректного вызова OPEN


203

USE

RCA

LLS

CTC

BC

ON

BUFF

ER

HO

STPA

RAM

SC

ON

LIST

SND

CALL

S

Acc

eptD

ata

Forc

eAct

ive

Hos

tPar

ams

Conn

ectio

ns

Send

Calls

Dat

aBuf

fers

TCB

Use

rCal

ls

ucall

::uca

lls

ucall

::uca

lls

ucall

s

newtcb

tcb

ucall

s

(cnid,

scall

s)

(cnid

, add

send

(scall

s, uc

all, tc

b))

(cnid,

OUTBUF obuf)

(cnid, OUTBUF

(addodata(obu

f, ucal

l)))

hpar

Hos

tPar

ams.u

pdate

(hpa

r, tim

e())

(cnid,

scall

s)

(cnid

, add

send

(scal l

s, uc

all, n

ewtcb

))

clst

updc

onlis

t (cl st

, new

tcb)

tcbsendd

ata(ge

tsc(ucall

), tcb)

(cnid,

OUTBUF obuf)

(cnid, OUTBUF

(addodata(obuf

, ucall)

))

[if n

otse

nd(u

call)

then

fals

e el

se

TCB.

Id(tc

b)=

cnid

and

also

TC

B.St

ate(

tcb)

<>L

ISTE

N

anda

lso

chec

ksen

d(uc

all,

tcb,

obu

f)=er

r_no

erro

r]

Use

rCal

l.Loc

alC

on(u

call)

=cn

id

input(ucall, tcb, hpar);

output(newtcb);

action

(opencon(ucall, tcb, hpar, time()));C

[if n

otse

nd(u

call)

then

fals

e el

se U

serC

all.L

ocal

Con

(uca

ll)=

cnid

anda

lso

TCB.

Id(tc

b)=

cnid

and

also

TC

B.St

ate(

tcb)

=LI

STEN

anda

lso

chec

ksen

d(uc

all,

tcb,

obu

f)=er

r_no

erro

r]

Ри

с. 7

5. О

браб

отка

кор

рект

ного

вы

зова

SE

ND


204

Подсеть, изображенная на рис. 75, используется для обра-

ботки некорректных вызовов SEND. Если соединение закрывается либо не существует, то вызов SEND не может быть обработан. Этот случай моделируется с помощью перехода Error. Идентифи-цировать подобное закрывающееся соединение помогает его со-стояние. Случай, когда соединение находится в состоянии, позво-ляющем передавать сегменты с данными, но вызов CLOSE уже был получен, моделируется с помощью перехода BufferError. По-лучение вызова CLOSE определяется наличием в буфере для от-правляемых данных символа FIN. Данное условие определяется с помощью функции OutputBuffer.finqueued. Стоит отме-тить, что охранные выражения были построены таким образом, чтобы исключить возможность одновременной активации перехо-дов Error и BufferError. При срабатывании обоих переходов в спи-сок Responses добавляется реакция протокола на обработку оши-бочного вызова.

USERCALLS

CTCB CONBUFFER

CONLIST

USERRESPONSES

DataBuffers

Connection

Responses

BufferError

Error

UserCalls

TCB

tcb

(cnid, OUTBUF obuf)

resp

resp

ucall::ucalls

ucall::ucallsucalls

ucalls

clst

resp^^[error(UserCall.LocalCon(ucal )l ,

ucall, errsend(ucall, clst))]

resp^^[error(cnid, ucall, err_conclosing)]

[if notsend(ucall) then false elseerrsend(ucall, clst)<>err_noerror]

[if errsend(ucall) then false elseUserCall.LocalCon(ucall)=cnid andalso TCB.Id(tcb)=cnid andalso TCPStates.<=(SYN_RECEIVED, TCP.State(tcb))andalso TCP.States.<=(TCB.State(tcb), CLOSE_WAIT)

andalso OutputBuffer.finqueued(obuf)]

Рис. 76. Обработка некорректного вызова SEND


205

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

работки входящего вызова RECEIVE. Рассмотрим составляющие ее логические части. Моделирование обработки пришедшего кор-ректного вызова RECEIVE происходит с помощью подсети, изо-браженной на рис. 77. По приходу корректного вызова возможны две ситуации. Если протокол имеет в буфере достаточное количе-ство данных для удовлетворения запроса пользователя, то необхо-димо передать эти данные вызову сразу. Если же данных недоста-точно, то необходимо задержать вызов до прихода достаточного количества данных от удаленного конца соединения. Первый слу-чай моделируется с помощью перехода Satisfy. Переход QueueCall моделирует второй случай обработки вызова. Переход Satisfy срабатывает, если:

• все буферизованные вызовы RECEIVE были обработа-ны (тем самым соблюдается последовательность получения и об-работки вызовов), что моделируется с помощью условия rcalls=nil;

• вызов имеет корректный формат и адресован соедине-нию, которое может его обработать (проверка моделируется с по-мощью функции checkrcv);

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

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

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


206

USE

RCA

LLS

CTC

BC

ON

BUFF

ER

USE

RRE

SPO

NSE

S

RC

VCAL

LS

Que

ueCa

ll

Satis

fy

Resp

onse

s

RcvC

alls

Dat

aBuf

fers

TCB

Use

rCal

ls

ucall

::uca

lls

ucall

::uca

lls

ucall

s

rcvdat

a(getr

c(ucal

l), tcb, ibuf)

tcbtcb

ucall

s

(cnid, INBUF i

buf)

(cnid

, rcall

s)

(cnid

, add

receiv

e(rca

lls, g

etrc(u

call))

)

(cnid,

INBUF ibuf)

(cnid, I

NBUF

(remrcvdata(ibuf,

getrc(

ucall))

))

(cnid,

rcall

s)

resp

resp

^^[rc

vres

p(cn

id, g

etrc(u

call)

,

ibuf

, TCB

.rcvu

rg(tc

b))]

[if n

otrc

v(uc

all)

then

fals

e el

se U

serC

all.L

ocal

Con

(uca

ll)=

TCB.

Id(tc

b) a

ndal

so T

CB.Id

(tcb)

=cn

idan

dalso

che

ckrc

v(uc

all,

tcb,

ibuf

)=er

r_no

erro

r an

dals

o (T

CPS

tate

s.<

(TCB

.Sta

te(tc

b), E

STAB

LISH

ED) o

rels

e(if

TC

B.St

ate(

tcb)

=ES

TABL

ISH

ED o

rels

e TC

B.St

ate(

tcb)

=FI

N_W

AIT1

ore

lse

TCB.

Stat

e(tc

b)=

FIN

_WAI

T2 th

en

Inpu

tBuf

fer.b

uffe

red(

ibuf

)<Re

ceiv

e.by

teco

unt(g

etrc

(uca

ll)) a

ndal

so

not(I

nput

Buffe

r.pus

hsee

n(ib

uf, R

ecei

ve.b

ytec

ount

(get

rc(u

call)

))) e

lse

false

)]

[if n

otrc

v(uc

all)

then

fals

e el

se U

serC

all.L

ocal

Con

(uca

ll)=

TCB.

Id(tc

b) a

ndal

so

TCB.

Id(tc

b)=

cnid

and

also

che

ckrc

v(uc

all,

tcb,

ibuf

)=er

r_no

erro

r an

dals

o ((T

CPS

tate

s.<=

(EST

ABLI

SHED

, TC

B.St

ate(

tcb)

) and

also

TCPS

tate

s.<=

(TC

B.St

ate(

tcb)

, FIN

_WAI

T2))

and

also

rcal

ls=ni

l and

also

(Inp

utBu

ffer.b

uffe

red(

ibuf

)>=

Rece

ive.

byte

coun

t(get

rc(u

call)

) ore

lse

Inpu

tBuf

fer.p

ushs

een(

ibuf

, Rec

eive

.byt

ecou

nt(g

etrc

(uca

ll)))

)) o

rels

e(I

nput

Buffe

r.buf

fere

d(ib

uf)>

0 an

dalso

TCB

.Sta

te(tc

b)=

CLO

SE_W

AIT)

)]

Ри

с. 7

7. М

одел

иров

ание

обр

абот

ки к

орре

ктно

го в

ызо

ва R

EC

EIV

E


207

Если адресатом вызова RECEIVE является соединение, ко-торое не может его обработать, то для моделирования использует-ся подсеть, изображенная на рис. 78. Если вызов поступил соеди-нению, которое либо находится в закрытом состоянии, либо не имеет данных и не может ни при каких обстоятельствах принять вызов от удаленной стороны, то срабатывает переход RcvError1. Если же соединение находится в состоянии CLOSE_WAIT, то вы-зов RECEIVE является некорректным, если в буфере нет данных. Этот случай моделируется с помощью перехода RcvError2. При срабатывании обоих переходов ответ на пришедший вызов добав-ляется в список, содержащийся в позиции Responses.

Страница CloseCall – закрытие соединения Подсеть CloseCall, отвечающую за моделирование обработ-

ки вызова CLOSE, для удобства восприятия мы разделили на три части. Рассмотрим эти части подробнее.

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

USERCALLS

RCVCALLS

CTCB

CONBUFFER

CONLIST

USERRESPONSES

TCB

DataBuffers

Connection

Responses

RcvError2

RcvError1

UserCalls

RcvCalls

tcb(cnid,

rcalls)

(cnid, INBUF ibuf)

resp

resp

ucall::ucalls

ucall::ucallsucalls

ucalls

clst

resp^^[error(UserCall.LocalCon(ucal )l ,

ucall, errrcv(ucall, clst))]

resp^^[error(cnid, ucall,

checkrcv(ucall, tcb, ibuf))]

[if notrcv(ucall) then false elseerrrcv(ucall, clst)<>err_noerror]

[if notrcv(ucall) then false else UserCall.LocalCon(ucall)=TCB.Id(tcb)

andalso TCB.Id(tcb)=cnid andalso TCB.State(tcb)=CLOSE_WAIT

andalso rcalls=nil andalso checkrcv(ucall, tcb, ibuf)<>err_noerror]

Рис. 78. Моделирование обработки некорректного вызова

RECEIVE


208

исходит с помощью подсети, показанной на рис. 79. Эта подсеть имеет один переход Process, который срабатывает следующим об-разом. Во-первых, обновляется значение маркера контрольного блока соединения, являющегося адресатом вызова. Обновление происходит согласно спецификации протокола. Также соответст-вующим образом обновляется значение маркера-списка в позиции Connections, представляющего все работающие соединения. Во-вторых, в буфер для отправляемых данных, представленный мар-кером в позиции DataBuffers, добавляется символ FIN, указы-вающий на конец данных для передачи. В-третьих, вызов CLOSE добавляется в буфер, представленный маркером в позиции SendCalls. Стоит отметить, что переход Process не будет срабаты-вать, если пришел еще один вызов CLOSE.

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

CLOSE, показана на рис. 80. Эта подсеть имеет переходы BufferError и Error. Переход BufferError используется для модели-рования обработки повторных вызовов CLOSE. В этом случае в ответ на вызов генерируется сообщение об ошибке, которое до-бавляется в маркер-список в позиции Responses. Для обработки остальных ошибочных ситуаций используется переход Error. С помощью него происходит обработка безадресных вызовов или вызовов, которые не могут быть обработаны согласно специфика-ции протокола. Определение вида ошибки происходит с помощью

CONBUFFER

SNDCALLSCTCB

CONLIST

USERCALLS

TCB

Connections

SendCalls

DataBuffers

UserCalls Processucall::ucalls

ucalls

clst

(cnid,

OUTBUF

(cn

id, OUTBUF ob

uf)

(OutputBuff

er.addf

in(

obuf)

))

(cnid, scalls)

(cnid, addsend(scalls, ucall, tcb))

upd conlist (clst , newtcb)

tcbnewt

cb

input(tcb);output(newtcb);action(closecon(tcb));

C

[if notclose(ucall) then false else TCB.Id(tcb)=cnidandalso UserCall.LocalCon(ucall)=TCB.Id(tcb)

andalso checkclose(ucall, TCB.State(txb))=err_noerrorandalso TCP.States.>=(SYN_RECEIVED, TCB.State(tcb))

andalso TCP.States.<=(TCB.State(tcb), CLOSE_WAIT)andalso not(OutputBuffer.finqueued(obuf))]

Рис. 79. Обработка корректного вызова CLOSE для

синхронизированных соединений


209

функции checkclose. При срабатывании перехода Error также генерируется сообщение об ошибке, как и при срабатывании пере-хода BufferError.

Если вызов CLOSE поступил соединениям, находящимся в

несинхронизированных состояниях SYN_SENT или LISTEN, то такие соединения сбрасываются. Моделирование подобной обра-ботки вызова показано на рис. 81. При срабатывании перехода CloseNSync происходят следующие действия: из соответствующих позиций удаляются все маркеры, моделирующие служебные структуры соединения; маркер-список из позиции Connections обновляется таким образом, что в нем убирается элемент, соответ-ствующий закрываемому соединению; все буферизованные вызо-вы пользователя получают отклик о том, что соединение сбрасы-вается (моделируется с помощью добавления в маркер-список в позиции Responses соответствующих значений).

Страница AbortCall – сброс соединения Подсети, составляющие сеть на странице AbortCall, которая

моделирует обработку вызова ABORT, показаны на рис. 82 и 83. Рассмотрим их подробнее.

Вызов ABORT является некорректным лишь в том случае, если он поступил соединению, находящемуся в состоянии CLOSED. Переход Error, показанный на рис. 82, срабатывает имен-но в этом случае.

USERCALLSUSERRESPONSES

Responses

CONBUFFERDataBuffers

CONLISTConnections

UserCalls

BufferError

Error

ucall::ucalls

ucallsucall::ucalls

resp^^[error(UserCall.LocalCon(ucall),

(cnid, OUTBUF obuf)

resp

resp

clst

ucalls

ucall, err_conclosing)]

resp^^[error(getclid(clst,ucall), ucall,

checkclose(ucall,con stcl ate(clst,ucall))]

[if notclose(ucall) then false elseUserCall.LocalCon(ucall)=cnid andalso

OutputBuffer.finqueued(obuf)]

[if notclose(ucall) then false elsecheckclose(ucall, conclstate(clst,ucall))<>err_noerror]

Рис. 80. Модель обработки некорректного вызова CLOSE


210

RET

RQ

UEU

E

SND

CALL

SR

CVC

ALLS

CO

NBU

FFER

CO

NSE

GM

ENTS

TIM

ER2M

SLAC

KTIM

ER

CTC

B

USE

RRE

SPO

NSE

S

CO

NLI

ST

USE

RCA

LLS

Tim

er2M

SLA

CKTi

mer

RetrQ

ueue

TCB

SegB

uffe

rD

ataB

uffe

rs

RcvC

alls

Send

Calls

Resp

onse

s

Conn

ectio

ns

Use

rCal

ls

Clos

eNSy

nc

(сn i

d , rc

alls)

resp^

^snd

erro

rs(c

nid,

sca l

ls, e r

r_cl

osi n

g)

resp

(cnid,

rq)@

ignore

(cnid, t2msl)@ignore

(cnid, atimer)@ignore

tcb

clst

remco

n(cls

t, cn

id)

ucal

ls

(сnid, rcalls)

1(сnid,

OUTB

UF obuf)

(сnid, scalls)

(сnid,

sbuf

)1(сn

id, IN

BUF i

buf)++

^^rc

verro

rs(c

nid,

rcall

s, e r

r_cl

o sin

g)^^

[clo

sere

sp(c

nid,

get

cc(u

c al l)

)]

[if n

otcl

ose(

ucal

l) th

en fa

lse e

lse

TCB.

Id(tc

b)=

cnid

anda

lso

Use

rCal

l.Loc

alCo

n(uc

all)=

TCB.

Id(tc

b)an

dals

o ch

eckc

lose

(uca

ll, T

CB.S

tate

(tcb)

)=er

r_no

erro

ran

dalso

TCP

Stat

es.<

=(T

CB.

Stat

e(tc

b), S

YN_S

ENT)

]

Ри

с. 8

1. О

браб

отка

вы

зова

CL

OSE

, адр

есов

анно

го н

есин

хрон

изир

ован

ым

сое

дине

ниям


211

Если от пользовательского процесса получен корректный

вызов ABORT, то соединение должно быть сброшено. Моделиро-вание этого события показано на рис. 83. Срабатывание перехода Abort аналогично срабатыванию перехода CloseNSync на странице CloseCall (см. ниже в части, посвященной обработке вызова CLOSE) лишь с тем различием, что при сбросе соединения необхо-димо отправлять специальным образом отформатированный сег-мент, если соединение находится в синхронизированном состоя-нии (за исключением соединений в состоянии CLOSING, LAST_ACK или TIME_WAIT). Это делается путем добавления к маркеру-списку в позиции SegOut датаграммы, содержащей этот сегмент.

Страница RespondCalls – обработка буферизованных вызовов

Если протокол не может обработать сразу какой-то вызов и передать результат обработки пользовательскому процессу (на-пример, вызовы SEND или RECEIVE), о н по мещает его в буфер. Протокол ждет, пока условия не станут благоприятными для обра-ботки вызова. Например, для вызова RECEIVE это значит, что придет достаточное количество данных от удаленного конца со-единения. Для определения, наступили такие условия или нет и

USERCALLS

USERRESPONSES

CONLIST

UserCalls

Connections

Responses

Errorucall::ucalls

ucalls

clst

resp

res ^^p[

checkabort(ucall,conclstate(clst,ucall)))]

error(UserCall.Lolca Con(ucall), ucall,

[if notabort(ucall) then false elsecheckabort(ucall, conclstate(clst,ucall))<>err_noerror]

Рис. 82. Обработка некорректного вызова ABORT


212

может ли вызов быть обработан, предназначена подсеть RespondCalls. Здесь эта подсеть разделена на две части. Рассмот-рим их подробнее.

В описываемой модели существует единственный вызов, ко-

торый ориентирован на получение данных от удаленной стороны соединения – это вызов RECEIVE. Как мы уже рассматривали ра-нее, этот вызов может быть буферизован до прихода достаточного количества данных от удаленной стороны. После того как необхо-димое количество данных получено, протокол может обработать этот вызов. Моделирование подобной обработки показано на рис. 84. Показанная на этом рисунке подсеть моделирует как нор-мальную обработку вызова, так и возврат откликов об ошибках.

Переход Receive используется для моделирования передачи накопленных протоколом данных буферизованному вызову. При этом к списку откликов, находящемуся в позиции Responses, до-бавляется соответствующим образом сформированная реакция протокола на обработку очередного вызова. Из буфера для прини-маемых от удаленной стороны данных, моделируемого маркером в позиции DataBuffers, изымается переданное пользователю коли-чество данных. Также мы обновляем значение маркера контроль-ного блока соединения, если возможно обновить окно приема RCV.WND.

RETRQUEUE

SNDCALLSRCVCALLS

CONBUFFER CONSEGMENTS

TIMER2MSLACKTIMER

CTCB

IPDATAGRAMS

USERRESPONSESCONLIST

USERCALLS

Timer2MSLACKTimer

RetrQueueTCB

SegBufferDataBuffers

RcvCalls SendCalls

Responses

SegOut

Connections

UserCalls

Abort

(сnid, rcalls)

r se p^^snderrors(cnid, scalls, err_conreset)resp

solst(cnid,

rq)@

ignore

(cni

d, t 2

msl)

@ig

nore

( cnid, atime r)@

ignore

tcb

clstremcon(clst, cnid)

ucalls

(сnid,

rcall

s)

1`(сnid, O

UTBUF obu

f)

(сnid , scalls)

(сnid, sbuf )1 (сnid,

INBUF ib

uf)++

^^Rcverrors(cnid, rcalls, err_conreset)

^^[abortresp(cnid, getac(ucall))]

[if notabort(ucall) then false else TCB.Id(tcb)=cnidandalso UserCall.LocalCon(ucall)=TCB.Id(tcb)

andalso checkabort(ucall, TCB.State(tcb))=err_noerror]solst^âbortseg(tcb)

Рис. 83. Обработка корректного вызова ABORT


213

Переход RcvError используется для моделирования передачи

ошибочных откликов пользовательскому процессу, инициировав-шему вызов. Это необходимо в том случае, если от процесса по-ступили вызовы, которые не могут быть обработаны, так как уда-ленный конец соединения сообщил об окончании передачи со сво-ей стороны. При срабатывании RcvError ошибочный отклик до-бавляется к маркеру-списку в позиции Responses.

Если некоторый вызов передал протоколу данные для пере-дачи другому концу соединения, то, чтобы быть уверенным, что данные были переданы, необходимо дождаться подтверждения об успешной передаче от удаленной стороны. После этого вызов, ориентированный на отправление данных, может считаться обра-ботанным. Для моделирования такой задержанной обработки ис-пользуется подсеть, показанная на рис. 85.

Эта подсеть содержит всего один переход Send, который срабатывает, когда от удаленной стороны было получено под-тверждение о приеме ассоциированных с буферизованным вызо-вом данных. Для вызова CLOSE таким подтверждением будет под-тверждение о приеме FIN-сегмента.

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

RCVCALLSCTCB CONBUFFER

USERRESPONSES

RcvError

Receive

ResponsesDataBuffersTCBRcvCalls

(cnid, rcalls)

(cnid, rcx::rc

alls)

(cnid, nil)

rcvdat

a(rcx

, tcb,

ibuf)

tcb

tcb

(cnid, rcalls)

(cnid,

INBUF i

buf)

resp

resp^^[rcverro

rs(cnid, rca

lls, err_

conclosing

)]

(cnid, INBUF ibuf)

(cnid, INBUF

(remrcvdata(ibuf, rcx)))

resp

[TCB.Id(tcb)=cnid andalso (TCPStates.<=(CLOSING, TCB.State(tcb))orelse (TCP.State(tcb)=CLOSE_WAIT andalso InputBuffer.buffered(ibuf)=0))]

[TCB.Id(tcb)=cnid andalso (InputBuffer.buffered(ibuf)>=Receive.bytecount(rcx)orelse InputBuffer.pushseen(ibuf, Receive.bytecount(rcx)) orelse(TCB.State(tcb)=CLOSE_WAIT andalso InputBuffer.buffered(ibuf)>0))

resp^^[rcvresp(cnid, rcx, ibuf, TCB.rcvurg(tcb))]

Рис. 84. Обработка буферизованных вызовов, ориентированных

на получение данных


214

7.3. Моделирование передачи сегментов в сеть

Страница DataSend – передача сегментов с данными Сеть, расположенная на странице DataSend, показана на

рис. 86. Эта сеть моделирует следующие важные аспекты работы протокола TCP:

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

- передача FIN-сегментов, сигнализирующих о завершении передачи данных;

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

Как видно на рис. 86, подсеть содержит всего один переход SendData. Этот переход срабатывает, если:

- протокол уже обработал все пришедшие сегменты (моде-лируется с помощью функции nextseg в охранном выражении перехода и выражения 1`nil на дуге, инцидентной позиции SegIn);

- алгоритмы скользящего окна и управления потоком позво-ляют отправить новую порцию данных (это количество определя-ется с помощью функции accnum);

SNDCALLS

USERRESPONSES

CTCB

SendCalls

TCB

Responses

Send(cnid, scx::scalls)

(cnid, scalls)

tcb

resp

resp^^[bufsndresp(cnid, scx)]

[TCB.Id(tcb)=cnid andalso scallacked(scx, tcb)]

Рис. 85. Обработка буферизованных вызовов, ориентирован-

ных на получение подтверждений


215

CO

NBU

FFER

IPD

ATAG

RAM

SC

ON

SEG

MEN

TS

ACKT

IMER

IPD

ATAG

RAM

S

SCH

EDAT

AGR

AM

RET

RQ

UEU

E

CO

NLI

ST

CTC

B

Dat

aBuf

fers

ToSc

hedu

leSe

ndD

ata

SegO

ut

RetrQ

ueue

Conn

ectio

ns

TCB

SegI

nSe

gBuf

fer

ACK

Tim

er

1nil

clst

tcb

(cnid, atimer)@ignore

(cni

d, OU

TBUF

obu

f)

(cnid, sbuf)

(cni

d, OU

TBUF

new

obuf

)

updc

onlis

t(clst

, new

tcb)

newtcb

(cnid, ACKTimer.niltime)r (c

nid,

newr

q)@

+TCB

.rto(

tcb)

solst

if m

ust d

elays

eg(tc

b, ne

wseg

, t ime()

)

then

solst

else

[toip

(tcb,

news

eg)]

(cnid,

rq)@

ignor

e

if m

ustd

elays

eg(tc

b, ne

wseg

, tim

e())

then

1`[to

ip(tc

b, n

ewse

g)] e

lse em

pty)

@+s

egde

lay(

tcb,

new

seg,

tim

e())

[TC

B.Id

(tcb)

=cn

id a

ndal

so a

ccnu

m(tc

b, o

buf)>

0 an

dals

o(if

sbuf

=ni

l the

n tr

ue e

lse

not(n

exts

eg(h

d(sb

uf),t

cb)))

]

input(tcb, obuf, rq);

output(newseg, newtcb, newrq, newobuf);

action

let

val nseg = Segment.data(tcb, obuf, time());

val ntcb = TCB.segsent(tcb, nseg, time();

val nrq = Retrqueue.add(rq, nseg, TCB.rto(tcb), time());

val nobuf = OutputBuffer.remdata(obuf, accnum(tcb, obuf));

in(nseg, ntcb, nrq, nobuf)

end;

C

Ри

с. 8

6. М

одел

иров

ание

пер

едач

и се

гмен

тов

с да

нны

ми


216

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

При срабатывании перехода SendData значения некоторых маркеров, помещаемых в позиции, определяются в кодовом сег-менте перехода. Там определяется формат отправляемого сегмента (равен значению nseg в кодовом сегменте), новое значение кон-трольного блока соединения (равно значению ntcb), очередь по-вторной передачи (равна значению nrq) и буфер для передавае-мых данных (равен значению nobuf). Вычисление этих значений происходит в соответствии со спецификацией протокола. При сра-батывании перехода вычисленные значения различных служебных структур используются для определения маркеров, помещаемых в соответствующие этим структурам позиции. Можно видеть, что маркеру, помещаемому в позицию RetrQueue, также ставится временная метка, равная текущему значению RTO. Необходимо отметить, что мы сбрасываем таймер для отправления подтвер-ждений (позиция ACKTimer), так как необходимое подтверждение несет передаваемый сегмент.

Рассмотрим теперь позиции SegOut и ToSchedule, куда по-мещается отправляемый протоколом сегмент. Значение самого сегмента хранится в переменной newseg. С помощью функции toip мы формируем датаграмму, которая помещается в одну из рассматриваемых позиций. Это определяется значением функции mustdelayseg. Эта функция возвращает значение «истина», ес-ли работающее соединение использует алгоритм управления пото-ком, оперирующий скоростью передачи данных, и значение «ложь» – в противном случае, когда предполагается, что алгоритм управления потоком отправляет сегменты один за другим – очере-дью. Видно, что в первом случае сформированная датаграмма по-мещается в позицию ToSchedule, где ей добавляется временная метка, значение которой определяется текущей скоростью переда-чи данных. Во втором случае сформированная датаграмма добав-ляется в конец списка датаграмм на отправление, который нахо-дится в позиции SegOut.


217

Страница ServiceSend – передача служебных сегментов Сеть, расположенная на странице ServiceSend (рис. 87), ис-

пользуется для передачи различных служебных сегментов – под-тверждений и SYN-сегментов для установки соединений. Для этой цели сеть содержит переходы SendACK и SendSYN. Рассмотрим эти переходы более подробно.

Основная задача перехода SendACK состоит в том, чтобы сформировать и передать сегмент, содержащий подтверждение полученных данных. Для срабатывания перехода необходимо, чтобы выполнялись следующие условия:

- количество полученных, но еще не подтвержденных сег-ментов, было больше нуля (моделируется с помощью условия TCPTimer.getdata(atimer)>0);

- протокол уже обработал все пришедшие сегменты (моде-лируется аналогично, как и в предыдущем пункте);

- протокол не может отправить сегмент с данными, который бы содержал подтверждение (моделируется с помощью условия accnum(tcb, obuf)=0).

При срабатывании перехода происходит обновление значе-ния маркера контрольного блока соединения (можно видеть, что обновление производится при помощи той же функции, как и при отправлении сегмента с данными). Также мы сбрасываем таймер для отправления подтверждений, моделируемый маркером в пози-ции ACKTimer. Сформированный с помощью функции Segment.ack сегмент мы заключаем в датаграмму и добавляем в конец списка, находящегося в позиции SegOut.

Рассмотрим теперь переход SendSYN, который отвечает за моделирование передачи SYN-сегментов. Основная задача этого перехода состоит в том, чтобы сформировать SYN-сегмент (это делается с помощью функции Segment.syn в кодовом сегменте перехода) и добавить его в список для отправляемых сегментов, моделируемый маркером в позиции SegOut. Переход SendSYN может сработать, если соединение находится в состояниях SYN_SENT или SYN_RECEIVED и SYN-сегмент не был передан удаленному концу соединения. Это определяется в охранном вы-ражении перехода.


218

IPD

ATAG

RAM

S

CTC

B

CO

NSE

GM

ENTS

CO

NBU

FFER

IPD

ATAG

RAM

S

RET

RQ

UEU

E

ACKT

IMER

Send

SYN

Send

ACK

RetrQ

ueue

SegO

ut

AC

KTi

mer

TCB

SegB

uffe

r

Dat

aBuf

fers

SegI

n

(cnid

, rq)

(cnid,

atim

er)

(cni

d, n

ewrq

)@+T

CB.rto

(tcb)

tcb

TCB.segsen

t(tcb,

news

eg, t

ime(

))

tcb

TCB .

segs

ent(t

cb, n

ewseg

, time())

(cnid,

ACK

Time

r.ni lt

imer

)

[TC

B.Id

(tcb)

=cn

id a

ndal

soTC

PTim

er.g

etda

ta(a

timer

)>0

anda

lso

(if s

buf=

nil t

hen

true

else

no

t(nex

tseg

(hd(

sbuf

), tc

b)))

and

also

accn

um(tc

b, o

buf)=

0][T

CB.

Id(tc

b)=

cnid

and

also

rq=R

etrq

ueue

.em

ptyq

ueue

and

also

(TC

B.St

ate(

tcb)

=SY

N_SE

NT

orel

seTC

B.St

ate(

tcb)

=SY

N_R

ECEI

VED

)]

solst

solst

solst^^[t

oip(tc

b, ne

wseg

)]so

lst^

[toip(

tcb, ne

wseg)]

1`ni

l

(cnid, OUTBUF obuf)

(cnid, sbuf)

input(tcb);

output(newseg);

action

(Segment.ack(tcb, time()));

input(tcb);

output(newseg, newrq);

action

let

val nseg = Segment.syn(tcb, time());

in(nseg,

);

end;

Retrqueue.add(rq, nseg,TCB.rto(tcb), time())

C

C

Ри

с. 8

7. М

одел

иров

ание

пер

едач

и сл

ужеб

ных

сегм

енто

в


219

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

Страница Retransmits – повторная передача сегментов Сеть, расположенная на странице Retransmits, показана на

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

Эта сеть содержит переходы FastRetransmit и Retransmit. Обычная повторная передача по истечении тайм-аута моделирует-ся с помощью перехода Retransmit. Этот переход становится ак-тивным, если:

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

- алгоритм управления потоком позволяет отправить по-вторно передаваемый сегмент (условие моделируется с помощью функции TCB.cantransmit);

- сработал таймер повторной передачи. Таймер подобной передачи срабатывает, если: маркер в позиции RetrQueue может участвовать в срабатываниях из-за того, что значение временной метки маркера меньше или равно значению глобальных часов мо-дели; тайм-аут повторной передачи установлен (проверяется с по-мощью функции TCPTimer.started).

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


220

SCH

EDAT

AGR

AM

CTC

B

RET

RQ

UEU

E

CO

NBU

FFER

IPD

ATAG

RAM

S

IPD

ATAG

RAM

S

Retra

nsm

itFa

stRet

rans

mit

RetrQ

ueue

ToSc

hedu

le

SegO

ut

TCB

SegI

n

SegB

uffe

r(c

nid,

sbuf

)

1`ni

l

(cni

d, sb

uf)

1`ni

l

tcbtcb so

lstso

lst

TCB.fa

stretr

ansm

it(tcb

, new

seg,

tim

e())

T CB.

retr a

n sm

it(tcb

, new

seg, ti

me())

(cnid,

rq)@

igno

re

(cnid, newrq)@+TCPTimer.

remain

der(n

ewrq

, tim

e())

(сnid,

rq

)

(cni

d, n

e wrq

)@+T

CPTi

mer.re

mainder(newrq, time())

solst^

^[if T

CB.ra

tectrl

(tcb)

then

nil

solst

^[if

TCB.

ratec

trl(tc

b) the

n nil

else t

oip(tc

b, ne

wseg

)]els

e toi

p(tcb

, new

seg)]

(if TCB.ratectrl(tcb) th

en 1 toi

p(tcb

, new

seg)

els e

em

pty)

(if T

CB.ra

tectr

l(tcb

) the

n 1`to

ip(tcb

, newseg) else empty)

@+segdela

y(tcb

, new

seg,

time(

))@

+seg

delay

(tcb, n

ewseg, time())

[TC

B.Id

(tcb)

=cn

id a

ndal

so

TCB.

frtr

igge

r(tc

b) a

ndal

so

TCB.

cant

rans

mit(

tcb)

and

also

if sb

uf=

nil t

hen

true

els

e no

t(nex

tseg

(hd(

sbuf

), tc

b))]

[TC

B.Id

(tcb)

=cn

id a

ndal

so

TCPT

imer

.sta

rted

(rq)

and

also

TC

B.ca

ntra

nsm

it(tc

b) a

ndal

soif

sbuf

=ni

l the

n tr

ue e

lse

not(n

exts

eg(h

d(sb

uf),

tcb)

)]

Ри

с. 8

8. М

одел

иров

ание

пов

торн

ой п

еред

ачи

поте

рянн

ых

сегм

енто

в


221

Основная функция перехода FastRetransmit состоит в моде-лировании механизма быстрой ретрансляции. Условия срабатыва-ния этого перехода очень похожи на условия срабатывания пере-хода Retransmit с тем различием, что мы игнорируем временную метку маркера очереди повторной передачи и для определения ус-ловия необходимости быстрой ретрансляции сегмента с помощью функции frtrigger. При срабатывании перехода FastRetransmit c помощью функции TCB.fastretransmit происходит пересчет значения маркера, представляющего кон-трольный блок соединения (позиция TCB). Также стоит отметить, что мы не перезапускаем таймер повторной передачи и устанавли-ваем временную метку у маркера в позиции RetrQueue такой же, какой она была до срабатывания перехода. В остальном срабаты-вание перехода FastRetransmit похоже на срабатывание перехода Retransmit.

Страница Scheduler – передача сегментов c заданной скоростью

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

После того как маркер, моделирующий сегмент, попадает в позицию ToSchedule, могут сработать переходы, расположенные на странице Scheduler. На этой странице расположены переходы Transmit и Reject (рис. 89).

Переход Transmit может сработать, когда глобальное время больше или равно временной метке маркера в позиции ToSchedule. Напомним, что если при передаче маркер, представ-ляющий сегмент, попадает в позицию ToSchedule, то ему добав-ляется временная метка. Значение этой метки зависит от текущей скорости передачи данных. Итак, после срабатывания этого пере-хода обновляется значение маркера, представляющего контроль-ный блок соединения. Также помещаемый в позицию SegOut сег-


222

мент обновляется. Например, обновляется значение поля времен-ной метки (если для соединения включено использование этого механизма), поля подтверждений.

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

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

7.4. Моделирование обработки пришедших сег-ментов

Страница SYNProcessing – обработка SYN-сегментов Страница SYNProcessing используется для моделирования

обработки SYN-сегментов, которые предназначены для установки соединения. Сеть, расположенная на этой странице, показана на рис. 90.

SCHEDATAGRAM

CONLIST

CTCB IPDATAGRAMS

Connections

SegOutTCB ToSchedule

Transmit

Reject

sisi

clst

solst

TCB.segtran

smitted(tcb

, SEG.getseg(si), t

ime())

tcb

solst ^[toip(tcb, Segment.upddsopt

(tcb, SEG.getseg(si), time())]

[SEG.srcsocks(si)=TCB.Sockets(tcb)]

[srcdg2id(clst, si)=0]

Рис. 89. Моделирование передачи сегментов в сеть с заданной скоростью


223

IPD

ATAG

RAM

S

RET

RQ

UEU

EAC

KTIM

ER

CTC

BC

ON

LIST

HO

STPA

RAM

S

CO

NSE

GM

ENTS

Act

iveO

pen

Pass

iveO

pen

Hos

tPar

ams

SegB

uffe

rCo

nnec

tions

TCB

SegI

n RetrQ

ueue

ACK

Tim

er

si::si

lst

si::si

lst

silst

getisn

(newtcb

, hpar, tim

e())

tcb

silst

(cnid,

sbuf

)

clst

updconlist(clst

, newtcb

)

(cnid,

sbuf

)

hpar

Hos

tPar

ams.u

pdate

(hpa

r, tim

e())

tcb

newtcb

clst

updconlist(clst

, newtcb

)

(cni

d, rq

)@ig

nore

(cnid

, new

rq)@

+

TCPT

imer.

remain

der(n

ewrq,

time()

)

(cnid

, atim

er)@

igno

re

(cni

d, n e

watim

er)

[if T

CB.

Id(tc

b)=c

nid

anda

lso sb

uf=

nil a

ndal

soTC

B.Id

(tcb)

=be

stm

atch

(cls

t, si

) the

ndr

aftp

roc(

tcb,

si, R

etrq

ueue

.em

ptyq

ueue

)<>N

ON

Eel

se fa

lse]

[if T

CB.

Id(tc

b)=

dg2i

d(cl

st, s

i) an

dalso

TC

B.Id

(tcb)

=cn

id

anda

lso

sbuf

=nil

anda

lso

TCB.

Stat

e(tc

b)=

SYN

_SEN

T th

endr

aftp

roc(

tcb,

si,

rq)<

>N

ONE

else

fals

e]

input(tcb, si);

output(newtcb);

action

(valOf(segproc(tcb, si,

Retrqueue.emptyqueue, time())));

input(tcb, si, rq, atimer);

output(newtcb, newrq, newatimer);

action

let

val ntcb = segproc(tcb, si, rq, time());

val nseg = SEG.getseg(si);

val nrq = ackrq(rq, tcb, ntcb, nseg, time());

val natimer = ACKTimer.newunaseg(atimer, time());

in(valOf(ntcb), nrq, natimer);

end;

C

C

Ри

с. 9

0. М

одел

иров

ание

обр

абот

ки S

YN

-сег

мен

тов


224

Сеть содержит переходы PassiveOpen и ActiveOpen. Пере-ход PassiveOpen используется для установления локальных со-единений, которые ждут от удаленного конца приглашения на от-крытие (т. е. были открыты в пассивном режиме). Этот переход становится активным при выполнении следующих условий:

- датаграмма имеет адресатом соединение, находящееся в состоянии LISTEN (моделируется с помощью функции bestmatch);

- сегмент, инкапсулированный в датаграмму, не сбрасывает соединение (моделируется с помощью функции draftproc).

Заметим, что, так как на удаленный сокет не накладывается условие полной спецификации для пассивно открытых соедине-ний, функция bestmatch выбирает из существующих соедине-ний наиболее точно соответствующее пришедшей датаграмме. Ес-ли соединений, в равной степени соответствующих датаграмме, несколько, то выбирается одно из них. При срабатывании перехода PassiveOpen происходит обновление маркера контрольного блока соединения (позиция TCB): например, если удаленный сокет был не задан, его значение заполняется исходя из значений IP-адреса и порта отправителя датаграммы. Также в соответствии со специфи-кацией протокола выбирается ISN соединение. Для этого исполь-зуется функция getisn. Поскольку обновляется контрольный блок соединения, необходимо изменить соответствующий ему элемент в списке, который содержится в позиции Connections. Также мы обновляем значение маркера в позиции HostParams аналогично, как и при активном открытии соединений посредст-вом вызова OPEN.

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

- датаграмма имеет адресатом соединение, находящееся в состоянии SYN_SENT (в частности, идентификатор контрольного блока соединения-адресата определяется с помощью функции dg2id);


225

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

Переход ActiveOpen используется как при одновременном, так и при нормальном открытии соединений. В обоих случаях зна-чение маркера контрольного блока соединения определяется с по-мощью функции segproc в кодовом сегменте перехода. Также мы обновляем значение маркера-списка в позиции Connections. Значение маркера-очереди повторной передачи в позиции RetrQueue обновляется с помощью функции ackrq в кодовом сегменте перехода. Стоит отметить, что если производится одно-временное открытие, то функция ackrq не убирает отправленный SYN-сегмент из очереди. Значение маркера-таймера для отправле-ния подтверждений обновляется следующим образом. В случае нормального открытия соединения мы устанавливаем таймер зна-чением, как будто он уже сработал и существуют неподтвержден-ные сегменты. В этом случае, если нет данных для отправки, гене-рируется немедленное подтверждение, отправление которого мо-делируется с помощью сети на странице ServiceSend. В случае одновременного открытия таймер не изменяется и как был сбро-шенным, так и остается.

Страница Preprocessing – предварительная обработка сегментов

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

Как видно на рис. 91, на странице Preprocessing расположен всего один переход Preprocess. Для активизации перехода необ-ходимо, чтобы существовало соединение, являющееся адресатом датаграммы, причем чтобы оно находилось либо в синхронизиро-ванном состоянии, либо вело к сбросу соединения, находящегося в состоянии SYN_SENT. Пара сокетов соединения-адресата вычис-ляется с помощью функции dstsocks.


226

Рассмотрим действия, которые происходят при срабатыва-

нии перехода Preprocess. Как уже упоминалось, одной из функ-ций этого перехода является отбрасывание заведомо некорректных сегментов. Аналогичное действие, описываемое в спецификации протокола, называется начальной обработкой сегмента (initial segment processing). При этом отбрасываются сегменты, либо не укладывающиеся в открытое окно, либо не удовлетворяющие ал-горитму PAWS (конечно, если для соединения включена опция

CO

NSE

GM

ENTS

ACKT

IMER

CTC

B

IPD

ATAG

RAM

S

IPD

ATAG

RAM

S

TCB

SegO

ut

AC

KTi

mer

SegB

uffe

r

SegI

nPr

epro

cess

si::si

l st

silst

solst

(cnid,

if ne

wdgms=nil

then

(cnid,

sbuf)

places

eg(sb

uf, SE

G.gets

eg(si))

else sb

uf)

(cnid,

newati

mer)@

+

(cnid,

atim

er)@ign

ore

solst newdgms^ dupacktcb

newtcbinput(tcb, si);

output(newtcb, newdgms, dupack);

action

let

val ntcb = valOf(segpreproc(tcb ,si, time());

val sr = segpreresp(tcb, si, time());

val da = sr=nil andalso needupack(tcb, si);

val dseg = if da then [toip(tcb, Segment.ack(tcb, time()))] else nil;

val ntcb = if da then TCB.segsent(ntcb, SEG.getseg(hd(dseg)), time())

else ntcb;

in(ntcb, sr, dseg)

end;

C

TCPTimer.rem

ainder

(newati

mer, tim

e())

[TC

B.So

cket

s(tc

b)=

SEG.

dsts

ocks

(si)

anda

lso

TCB.

Id(tc

b)=

cnid

anda

lso (T

CPS

tate

s.<=

(SYN

_REC

EIVE

D, T

CB.

Stat

e(tc

b)) o

relse

(if

TCB

.Sta

te(tc

b)=

SYN

_SEN

T an

dals

o ne

xtse

g(SE

G.ge

tseg

(si),

tcb)

then

dra

ftpro

c(tc

b, si

, Ret

rQue

ue.e

mpt

yque

ue)=

NO

NE

else

fals

e)]

Ри

с. 9

1. М

одел

иров

ание

нач

альн

ой о

браб

отки

сег

мен

тов


227

временной метки). Если сегмент не проходит тестов на стадии на-чальной обработки, то отправителю данного сегмента отправляет-ся специальным образом отформатированное подтверждение. При срабатывании перехода Preprocess это подтверждение строится с помощью функции segpreresp в кодовом сегменте перехода. Кроме того, если сегмент прибыл вне своей последовательности передачи, то необходимо немедленно отправить дублированное подтверждение, что делается путем определения соответствующе-го значения переменной dupack. Таким образом, добавляя к мар-керу-списку в позиции SegOut необходимые для передачи ответ-ные сегменты, моделируем ответ на полученный сегмент согласно спецификации протокола.

Если пришел корректный сегмент (даже если он получен вне своей очередности), то мы его помещаем в буфер соединения-адресата, моделируемый маркером в позиции SegBuffer. При этом функция placeseg для очередного полученного сегмента опре-деляет его положение в буфере в зависимости от значения поля SEG.SEQ, пытаясь отсортировать полученные сегменты по воз-растанию.

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

Так как ряд алгоритмов (например, PAWS или ARTCP) тре-буют обновления контрольного блока соединения после начальной обработки сегмента, это моделируется с помощью функции segpreproc в кодовом сегменте перехода.

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

для моделирования обработки пришедших сегментов. Как можно видеть на рис. 92, сеть содержит всего один пе-

реход Process. Для активации этого перехода необходимо, чтобы были выполнены следующие условия:

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


228

SEG.SEQ≤RCV.NXT (выполнение этого условия моделируется функцией nextseg);

- этот сегмент не сбрасывает соединение (моделируется ус-ловием draftproc(…)≠NONE).

Если эти условия выполнены, то переход Process может сра-

ботать. При срабатывании этого перехода обрабатываемый сег-мент «обрезается» с помощью функции TCB.tailor так, чтобы он помещался в открытом окне получателя. После этого мы уже имеем дело с идеализированным сегментом, обработка которого показана в спецификации [4]. После этого пересчитываются зна-чения служебных структур протокола. Значение маркера кон-трольного блока соединения пересчитывается с помощью функции segproc. Мы обновляем также соответствующий соединению элемент в списке работающих соединений (маркер в позиции

Connections

SegOut

Timer2MSL

ACKTimer

RetrQueue

SegBuffer

Responses

DataBuffers

Process

TCB

CONBUFFER

CONSEGMENTS

RETRQUEUE

USERRESPONSES CTCB

ACKTIMER

CONLIST

TIMER2MSL

IPDATAGRAMS

resp

(cnid, newatimer)@

+

(cnid, a

timer)@ignore

newt

cbtcb

updconlist(clst, newtcb)

clst(cnid, newt2msl)@+

(cnid, t2msl)@ignore

solst^^rdgms

solst(cnid

, sbu

f)(cn

id, ts

::sbu

f)

(cnid, ne

wrq) @+

(rqid, rq)@ignore

(cnid, INBUF newbuf)

(cnid, INBUF ibuf)

resp^û rgsignal(tcb, SOME newtcb)

[if TCB.Id(tcb)=cnid andalso nextseg(ts, tcb) thendraftproc(tcb, seg2dgram(TCB.tailor(tcb, ts), tcb), rq)<>NONE

else false]

input(tcb, ts, rq, ibuf, atimer, t2msl);output(newtcb, newrq, newibuf, newatimer, newt2msl, newdgms);actionletval nseg = TCB.tailor(tcb, ts);val nsdg = seg2dgram(nseg, tcb);val ntcb = valOf(segproc(tcb, nsdg, rq, time()));val nrq = ackrq(rq, tcb, SOME ntcb, nseg);val nibuf = addsegdata(ibuf, tcb, SOME ntcb, nseg);val natimer = updacktimer(atimer, tcb, ntcb, time());val n2msl = if TCB.State(ntcb)=TIME_WAIT then Timer2MSL.start(t2msl, time()) else t2msl;

in(ntcb, nrq, nibuf, natimer, n2msl, ndgms)end;

val ndgms = segresp(tcb, nsdg, rq, time());

C

TCPTimer.remainder(n

ewrq, time())

TCPTimer.remainder(newt2msl, time())

TCPTimer.remainder(n

ewatimer,

time()

)

Рис. 92. Моделирование обработки полученных сегментов


229

Connections). В буфер для поступающих данных (маркер в пози-ции DataBuffers) помещаются данные, присоединенные к сегмен-ту. Если с сегментом были получены какие-то новые данные, то функция updacktimer обновляет значение маркера-таймера для отправления подтверждений в позиции ACKTimer. В случае, если соединение переходит в состояние TIME_WAIT (либо уже там на-ходится), необходимо перезапустить 2MSL-таймер. Если сегмент был не совсем корректный и необходимо отправить удаленному концу в ответ специально отформатированные сегменты, то опре-делить, какие сегменты необходимо отправлять, можно с помо-щью функции segresp. Необходимо отметить, что здесь не отправ-ляется необходимое подтверждение полученных данных (это дела-ется на странице ServiceSend). Если полученный сегмент под-тверждает получение каких-то сегментов, то они могут быть уда-лены из очереди повторной передачи. Это делается с помощью об-новления маркера-очереди повторной передачи в позиции RetrQueue посредством функции ackrq.

Страница DiscardSegment – обработка некорректных сегментов

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

Эта сеть имеет всего один переход ClosedDiscard. Этот пе-реход активизируется, если невозможно определить идентифика-тор соединения-адресата сегмента (моделируется с помощью ус-ловия dg2id(…)=0). В результате срабатывания к списку отправ-ляемых датаграмм (маркер в позиции SegOut) добавляется ответ-ная датаграмма, отформатированная с помощью функции SegProc.closedresp.


230

Страница ResetConnection – сброс соединений Существуют ситуации, когда при обработке полученного

сегмента соединение должно быть сброшено. Это может случить-ся, если, например, у сегмента установлен флаг RST. Для модели-рования подобной ситуации предназначена сеть, расположенная на странице ResetConnection.

Как видно на рис. 94, сеть содержит переходы RstPassive и RstConnection. Рассмотрим эти переходы подробнее.

Переход RstPassive служит для моделирования сброса со-единений, находящихся в состоянии SYN_RECEIVED, которые из-начально были открыты в пассивном режиме. Если остальные со-единения при сбросе просто переходят в состояние CLOSED, то та-кие соединения переходят в свое первоначальное состояние – LISTEN. При срабатывании перехода маркер "контрольный блок соединения" обновляется с помощью функции segproc. Мы об-новляем также список работающих соединений (маркер в позиции Connections). При сбросе соединения нам необходимо инициали-зировать все таймеры и очистить очередь повторной передачи.

IPDATAGRAMS

IPDATAGRAMS

CONLIST

SegIn

Connections

SegOut

ClosedDiscardsi::silst

silst

clst

solst

solst^^[SegProc.closedresp(si)]

[dg2id(clst, si)=0]

Рис. 93. Моделирование обработки сегментов, адресатом

которых является соединение в состоянии CLOSED


231

CTC

BAC

KTIM

ERR

ETR

QU

EUE

CO

NLI

STC

ON

SEG

MEN

TS

IPD

ATAG

RAM

S

TIM

ER2M

SL

SND

CALL

SR

CVC

ALLS

CO

NBU

FFER

USE

RRE

SPO

NSE

S

RstP

assiv

e

RstC

onne

ctio

n

AC

KTi

mer

Dat

aBuf

fers

Resp

onse

s

Send

Calls

RcvC

alls

Tim

er2M

SL

SegO

ut

TCB

Conn

ectio

nsRe

trQue

ueSe

gBuf

fer

(cnid,

ts::s

buf)

(cnid,

ts::s

buf)

(cnid,

atim

er)@

ignor

e

tcb

(cnid, rq)@ignore

(cnid,

nil)

(cnid, rcalls)

(cnid,

t2ms

l)@ign

ore

solst

^[se

gres

p(tcb

, seg

2dgr

am(ts

, tcb

) ,clst

updconlist(clst, newtcb)

tcb

newtcb

(cnid,

atim

er)@

ignor

e

(cnid,

ACK

Timer.

niltim

er)

[if T

CB.

Id(tc

b)<

>cn

id o

rels

e TC

B.St

ate(

tcb)

<>

SYN

_REC

EIVE

D th

en fa

lse

else

(cas

e dr

aftp

roc(

tcb,

seg

2dgr

am(ts

, tcb

), rq

) of

NO

NE =

> fa

lse

|SO

ME

nt =

> T

CB.S

tate

(nt)=

LIST

EN)]

input(tcb, ts, rq);

output(newtcb);

action

(valOf(segproc(tcb, seg2dgram(ts, tcb),

rq, time())));

C

rq, t

ime(

))]

solst

(cnid, sc

alls)

1`(c

nid, I

NBUF

ibuf)

++

1`(c

nid, O

UTBU

F obu

f)

resp

resp

^^[s

igna

lres

p(cn

id, s

gn_c

onr e

f us e

d)]

^^[s

nder

rors

(cni

d, s

c alls

, er r

_ co n

res e

t )]^^

[rcve

rrors

(cni

d, rc

a lls,

err_

con r

e set

)]clst

remcon(clst, cnid)

(cnid, rq)@ignore

(cnid, Retrqueue.emptyqueue)

[if T

CB.

Id(tc

b)<

>cn

id th

en fa

lse

else

draf

tpro

c(tc

b, s

eg2d

gram

(ts, t

cb),

rq)=

NO

NE]

Ри

с. 9

4. М

одел

иров

ание

сбр

оса

соед

инен

ий


232

Переход RstConnection служит для моделирования полного сброса соединения. Вообще сброс может быть произведен не толь-ко тогда, когда от удаленной стороны получен RST-сегмент, но и, например, когда пришел SYN-сегмент соединению, находящемуся в синхронизированном состоянии. Переход RstConnection активизи-руется, если после обработки сегмента контрольный блок соедине-ния отсутствует. Это моделируется с помощью условия draftproc(…)=NONE. При срабатывании перехода мы производим те же действия, что и при обработке вызова пользователя ABORT с той разницей, что в ответ не отправляется никакого сегмента.

7.5. Типы позиций Здесь мы рассмотрим типы, которые были использованы при

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

Этот подход описан на сайте [120]. Схематично он изобра-жен на следующем примере: (* Определение SML-типа *) type smltype = ...; (* Функция сравнивает два значения *) val lt_smltype : (smltype * smltype) -> bool; (* Функция возвращает произвольное значение *) val ran_smltype : unit -> smltype; (* Функция образует строковое представление значения *) val mkstcol_smltype : smltype -> string; (* Определение типа для раскрашенных сетей Петри *) color smlcolor = smltype with (lt_smltype, ran_smltype, mkstcol_smltype);

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


233

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

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

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

7.6. Моделирование сетевых компонент Здесь мы рассмотрим подсети, которые были использованы

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

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

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

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


234

пользуемая емкость канала хранятся в позиции LinkParams. Сам «буфер» канала, где содержатся сегменты, находящиеся в транзите, моделируется с помощью позиции LinkResource. Рассмотрим, как эта подсеть выполняется.

Смысл выполнения этой подсети состоит в том, чтобы за-

брать очередную датаграмму из списка в позиции Incoming и «пе-редать» ее, добавив к списку в позиции Outgoing. Для помещения датаграммы в буфер канала используется переход TransmitToLink. При срабатывании этого перехода датаграмма добавляется в буфер канала LinkResource, при этом временная метка маркера в этой позиции устанавливается равной времени прибытия следующего сегмента из канала. Маркер в позиции CanAccept обновляется та-ким образом, что его временная метка становится равной времени окончания трансляции датаграммы в канал. Таким образом, пере-ход TransmitToLink будет гарантированно неактивным в течение этого времени. Маркер в позиции LinkParams обновляется затем, чтобы обновить используемую емкость канала. Если емкости ка-нала недостаточно для передачи очередной датаграммы, то проис-

IPDATAGRAMS

IPDATAGRAMS

LINKBUFFERLINKPARAMS

UNIT

TransmitToLink

RcvFromLink

LinkParams

CanAccept

LinkResource

Outgoing

Incomingsilst

si::silst

lb@ignore

lp

lp

1`()@+

lb

newlb@+Link.nextout(newlb, time())

newlb@+Link.nextout(newlb, time())

solst

solst^^[so]

Link.transtime(lp, si)

1`()

Link.placed(lp, si)

Link.removed

(lp, so

)

1`nil

[lb<>nil]

[Link.canplace(lp, si)]

input(lb, lp, si);output(newlb);action(Link.placeseg(lb, lp, si, time()));

input(lb, lp);output(newlb, so);action(Link.popped(lb), Link.pop(lb));

C

C

Рис. 95. Модель симплексного канала связи


235

ходит ожидание, пока канал не освободится. Если передаваемая датаграмма не может быть передана по каналу из-за того, что ем-кость канала меньше, чем ее размер, она разбивается на части (фрагментируется). Фрагментирование происходит только тогда, когда канал полностью свободен.

Если настало время покинуть канал для очередного сегмен-та, то срабатывает переход RcvFromLink. Этот сегмент добавляет-ся к списку датаграмм, покинувших канал (моделируется с помо-щью маркера в позиции Outgoing).

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

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

Мы здесь рассмотрим модель маршрутизатора, который ис-пользуется далее в примере. Граф сети, моделирующей маршрути-затор, показан на рис. 96.

Точка подключения первого канала связи, через которую прибывают датаграммы в маршрутизатор, моделируется с помощью позиции In1. Аналогично для второго канала связи, только модели-рование происходит с помощью позиции In2. Точка подключения первого канала связи, через которую происходит передача дата-грамм в канал, моделируется с помощью позиции Out1}. Для второ-го канала связи используется позиция Out2. Рассмотрим переходы данный сети, параллельно изучая остальные позиции этой сети.


236

RO

UTE

DAT

AGR

AMS

RO

UTE

RTA

BLE

RO

UTE

RBU

FFER

RO

UTE

DAT

AGR

AMS

IPD

ATAG

RAM

SIP

DAT

AGR

AMS

IPD

ATAG

RAM

SIP

DAT

AGR

AMS

Tabl

e

Buffe

rsO

utgo

ing

Out

1

Out

2

Accept1

Transmit1 Transmit2

Accept2

Routing

Inco

min

g

In1

In1

HS

si::si

lst

silst

si::si

lst

silst

rdgl

strd

glst^

^[(1

, si)]

rdgl

st^^[

(2, s

i)]rd

glst

1`ni

l

1`ni

l

[so]

[so]

(1, so)::r

dglst

(1, ro

uterbu

f)

rdglst rdg

lst

(2, so)::r

dglst

(2, ro

uterbuf)

(2, Router.dg

free(

(2, Router.dg

free(

routerbuf

, so

))

routerbuf

, so

))

Ри

с. 9

6. М

одел

иров

ание

мар

шру

тиза

тора


237

Переход Accept1 добавляет очередную полученную дата-грамму к списку в позиции Incoming, предварительно поместив ее в кортеж, где первый элемент определяет канал, по которому по-ступила эта датаграмма. Действия перехода Accept2 рассматрива-ются аналогично. Далее срабатывает подстановочный переход Routing, цель которого состоит в помещении датаграммы в тот буфер канала, по которому она должна быть отправлена. Подсеть, которую представляет переход Routing, мы рассмотрим позднее. После того как переход Routing сработал, датаграмма помещается в список в позиции Outgoing, соответствующей номеру канала, куда она должна быть отправлена, а затем срабатывает переход Transmit1 или Transmit2.

Рассмотрим теперь подсеть, моделирующую собственно маршрутизационный механизм. Эта подсеть, на которую ссылает-ся переход Routing, показана на рис. 97. Она содержит переходы Accept, Discard и Transmit.

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

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

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


238

RO

UTE

DAT

AGR

AMS

RO

UTE

DAT

AGR

AMS

RO

UTE

RTA

BLE

RO

UTE

RBU

FFER

Out

Transmit

Buffe

rsTa

ble

Disc

ard

Acc

ept

In

(rport

, si)::r

dglst

rdglst

rdglst(rp

ort, si

)::rdglst

rtablertable

(rbifa

ce, r

outer

buf)

(rbifa

ce, ro

uterbu

f)

(rbifa

ce, n

ewro

uterb

uf)

(rbifa

ce, r

oute

r bu f

)

(rbifa

ce,

Rou

et r.re

m(ro

uterb

uf))

rdgl

st

r dg l

st^^[

(rbifa

ce,

Rou t

e r.ge

t(rou

terbu

f)] )

[rbi

face

=Rou

ter.o

utpo

rt((r

port,

si),

rtab

le)

anda

lso

Rout

er.e

noug

hspa

ce(r

oute

rbuf

, si)]

[rbi

face

=Rou

ter.o

utpo

rt((r

port,

si),

rtab

le)

anda

lso

not(R

oute

r.eno

ughs

pace

(rou

terb

uf, s

i))]

[not

(Rou

ter.e

mpt

ybuf

(rou

terb

uf))

and

also

not(R

oute

r.por

tlock

ed(r

bifa

ce, r

dgls

t))]

input(routerbuf, si);

output(newrouterbuf);

action

(Router.add(routerbuf, si));C

Рис.

97.

Мод

елир

ован

ие м

арш

рути

заци

онно

го м

ехан

изм

а


239

7.7. Модификация модели История развития протокола TCP показывает, что в прото-

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

Здесь представлена смешанная модель протоколов TCP/ARTCP, т. е. она может работать и как про то ко л TCP, и как протокол ARTCP. Однако в процессе разработки была сначала создана модель протокола TCP, а потом последняя была модифи-цирована для представления в том числе и протокола ARTCP. Большая часть изменений при трансформации модели пришлась именно на код модели. Графовая структура модели тоже претерпе-ла изменения, но это объясняется тем, что протокол ARTCP явля-ется не просто модификацией TCP, а совершенно новым протоко-лом, который управляет соединением с использованием принци-пиально нового алгоритма.

При проведении трансформации модели мы лишь добавили страницу Scheduler, которая отвечает за отправление сегментов в сеть с заданной скоростью, и «подключили» ее к модели. Это было сделано добавлением специальной позиции ToSchedule к модели протокола на страницу TCPDataTransfer. После этого мы объяви-ли ее как сокет, и был создан соответствующий этой позиции порт на странице TCPSender. Таким образом у нас появилось «совме-щенное» множество, логически представляющее одну позицию. После этого с помощью создания соответствующих портов на страницах DataSend и Retransmits мы определили данную пози-цию (логически и физически расширили «совмещенное» множест-во позиций) и на этих страницах. Далее нам пришлось лишь отре-дактировать выражения на дугах от переходов к позиции SegOut таким образом, что при использовании алгоритма управления ско-ростью потока маркер, представляющий отправляемый сегмент, помещался бы в позицию ToSchedule, а в противном случае – в по-зицию SegOut.


240

Вообще, хорошая организация функций, которые использу-ются в выражениях на дугах, значительно облегчает решение зада-чи модификации модели. Конечно, большинство функций имеют достаточно простую структуру, но среди них выделяется функция procseg, которая отвечает за обработку пришедших сегментов. Цель данной функции состоит в изменении контрольного блока соединения в зависимости от значения полученного сегмента. Большая часть спецификации [4] описывает работу именно этой функции, причем алгоритм вычисления довольно сложен. Напри-мер, в операционной системе Linux (версия ядра 2.0.34) функция, аналогичная этой, состоит из порядка 630 строк довольно запутан-ного кода. Чтобы каким-то образом упорядочить структуру функ-ции procseg мы разбили обработку каждого сегмента на стадии. Каждая стадия реализована как переменная, которая имеет тип-запись, содержащий следующие поля:

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

- функцию Process, которая является функцией-обработчиком сегмента на данной стадии;

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

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

Введение этого типа, который определяет абстрактную ста-дию, позволяет составить общий алгоритм обработки сегментов, независимый от реализации какой-то стадии. Так как мы имеем дело с набором стадий, а язык SML не имеет средств для работы с циклами, общий алгоритм был реализован рекурсивным методом. Ниже показан SML-код, который реализует этот алгоритм: fun procstages(SegProc.Stage {Predicate=pred, Process=proc, NextStage=nextstage,..., tcb, idg, rq, curtime)= let

val {Segment=seg,... = idg; val predval = pred(tcb, seg, curtime); val newtcb = if predval then

proc(tcb, idg, rq, curtime) else NONE; val ntcb = if predval then newtcb

else SOME tcb;


241

val ns = if predval andalso newtcb=NONE then NONE else nextstage(tcb, ntcb, predval);

in case ns of

NONE => ntcb | _ => if newtcb=NONE andalso predval

then NONE else procstages(valOf(ns), va-lOf(ntcb), idg, rq, curtime)

end Основная идея представленного алгоритма состоит в сле-

дующем. В качестве аргументов передаются собственно стадия и некоторые управляющие структуры работы протокола: контроль-ный блок соединения (tcb), датаграмма, содержащая обрабаты-ваемый сегмент (idg), очередь повторной передачи (rq) и теку-щее время (curtime). Сначала мы вычисляем значение предиката (функция pred). В зависимости от значения предиката мы вычис-ляем новое значение контрольного блока соединения с помощью функции-обработчика сегмента, которое хранится как значение newtcb. Важным вычислением является определение следующей стадии для обработки сегмента (хранится как значение ns). Далее расположено основное тело функции. Там в зависимости от того, надо ли продолжать обработку сегмента или нет, в первом случае происходит рекурсивный вызов функции procstages либо про-исходит выход из рекурсии и возвращается результат. Функция procseg, упоминавшаяся ранее, для вычисления результата ис-пользует функцию procstages.

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

7.8. Выводы В главе 7 показан способ построения оригинальной модели в

терминах раскрашенных сетей Петри, которая отвечает современ-ным стандартам протокола TCP. Модель была построена таким образом, что она же представляет еще и протокол ARTCP. Необ-ходимо отметить, что возможно моделирование одновременной


242

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

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

Если посмотреть на структуру модели, то можно заметить, что если убрать иерархические конструкции, которые используют-ся для разбиения модели на логические части, то полученная сеть будет состоять из небольшого количества позиций и переходов. В системе Design/CPN было проведено удаление иерархических кон-струкций и была получена раскрашенная сеть Петри на одной странице, эквивалентная модели. Эта сеть содержит 15 позиций и 35 переходов. Мы не приводим здесь эту сеть, так как ее невоз-можно изобразить в приемлемом качестве. Основная причина со-стоит в том, что сеть содержит большое количество дуг (более 200). Однако, несмотря на небольшой размер сети, автоматические методы являются необходимыми для проведения эффективного анализа модели.


243

Глава 8. Экспериментальные данные

В этой главе мы рассмотрим некоторые подходы, которые могут быть применены к нашей модели для анализа свойств транспортных протоколов. Настоящая работа не претендует на полноту исследования различных свойств протокола TCP, поэтому мы лишь проиллюстрируем методы, которые могут быть примене-ны для анализа свойств модели. Исследование модели производи-лось с помощью пакета Design/CPN. Здесь мы рассмотрим пример, который использовался для демонстрации работы модели в [131].

8.1. Пример Для исследования свойств протоколов необходимо постро-

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

Поясним систему, показанную на рис. 98. Эта система со-

стоит из отправителя (Sender) и получателя данных (Receiver). Промежуточной системой в информационном обмене между от-правителем и получателем является маршрутизатор (Router). Каж-дый канал в точке подключения к маршрутизатору имеет буфер конечного размера (в нашей системе объем этого буфера равен 32 000 байтов). В этот буфер помещаются данные, которые долж-ны быть переданы по каналу. Объем буфера для каждого подклю-чения одинаков. Каждый канал характеризуется шириной полосы пропускания (для левого канала она равна 10Мбит/сек) и значени-ем задержки передачи (для левого канала она равна 3 мс). Первая

RouterSender Receiver

32000 bytes buffer

1,544 Mbit/sec3 ms 60 ms

10 Mbit/sec

Рис. 98. Использовавшаяся в экпериментах

сетевая инфраструктура


244

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

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

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

Таким образом, каждый компонент сети представляет собой макропереход, содержащий подсеть, моделирующую данный ком-понент. Рассмотрим последовательность действий, необходимую чтобы связать эти макропереходы. Например, у нас есть макропере-ход, представляющий отправителя, - Sender и переход, представ-ляющий канал связи. При моделировании передачи сегментов про-токолом используется позиция SegOut, а прием сегментов модели-руется с помощью позиции SegIn. Мы создаем две дополнительные позиции-сокеты для этого перехода, для которых портами будут яв-ляться эти позиции. Тем самым мы «выносим» их «за границы» пе-рехода. Далее мы задаем эти две дополнительные позиции как соке-ты для канала. Сокет, который соответствует позиции SegOut, бу-дет иметь соответствующий порт в сети, моделирующей канал, причем эта позиция-порт моделирует прием сегментов в канал. Да-лее проводим аналогичное задание для сокета, соответствующего позиции SegIn, причем соответствующая ему позиция-порт в кана-ле будет моделировать получение данных из канала. В целом со-единение других компонент сети производится аналогично.

8.2. Верификация протоколов Существует одно основное условие корректности протоко-

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


245

Пусть отправитель пытается передать 30 000 байтов данных получателю (пользовательский процесс при этом не устанавливает флаг PUSH). Получатель имеет буфер для входящих данных, равный 16 384 байтам. Размер передаваемого по этому соединению сегмен-та равен 1 000 байтов. Пользовательский процесс со стороны полу-чателя совершает два вызова RECEIVE для получения данных, каж-дый из которых запрашивает 16 300 байтов. Ожидаемым терми-нальным состоянием такой системы является состояние, когда от-правитель передал все данные, а получатель подтвердил их прием и передал пользовательскому процессу со своей стороны.

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

Sender Receiver30000 bytes

of dataAcknowledged = 0

Acknowledged = 1000

Acknowledged = 16000

16384 bytesfree

15384 bytesfree

384 bytesfree

29000 bytesof data

Data = 1000 bytes

Data = 1000 bytes

Data = 1000 bytes

14000 bytesof data

time

Acknowledgement of 1000 bytes

Acknowledgement of 1000 bytes

Рис. 99. Процесс передачи данных


246

Максимальное количество данных не может быть отправле-но, так как получатель объявляет окно передачи, которое равно 384 байтам. Определенная доля окна не может быть отправлена по той же причине. Условия, которые должны проверяться, когда мы передаем данные с флагом PUSH, не выполняются, так как мы не устанавливаем этот флаг на отправляемых данных. Пробы окна не могут быть отправлены, так как отправитель объявляет окно нену-левого размера.

Эта тупиковая ситуация была обнаружена с помощью вы-полнения модели в системе Design/CPN. Характер этой ситуации был изучен с помощью построения полного множества достижи-мых состояний системы. Это множество состоит из 794 состояний, причем единственным тупиковым состоянием является описанное. Таким образом, можно утверждать, что протокол в процессе вы-полнения гарантированно достигнет этого тупикового состояния и, как следствие, передача будет остановлена. Данное множество достижимых состояний не содержит более никаких ошибочных с точки зрения корректности частей (бесконечных циклов и т.п.).

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

- все переданные отправителем данные подтверждены; - объявленное получателем окно меньше или равно MSS; - количество буферизованных отправителем данных меньше

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

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

8.3. Анализ производительности протоколов Различные виды характеристик производительности могут

быть исследованы с помощью выполнения модели. Система Design/CPN позволяет строить графики для представления резуль-татов в наглядном виде. В приводимом примере отправитель пы-тается передать 250 000 байтов получателю. Максимальный раз-мер каждого сегмента равен 1 000 байтов. Размер буфера получа-теля равен 60 000 байтов.


247

На рис. 100 показаны графики, представляющие различные проведенные измерения. Слева показаны графики для протокола TCP, справа - для протокола ARTCP. Первая пара графиков пока-зывает процесс передачи сегментов отправителем. Вторая пара по-казывает процесс приема получателем подтверждений. Каждый прямоугольник в каждой из этих двух пар графиков символизиру-ет один сегмент. Третья пара графиков рассматривает использова-ние протоколами сетевого ресурса – буфера маршрутизатора. Про-токол заканчивает передачу данных, если получено подтвержде-ние о приеме последнего байта данных. На второй паре графиков видно, что стандартному протоколу TCP требуется примерно 5,5 с для передачи требуемого объема информации, а протокол ARTCP справляется с передачей такого же объема примерно за 3,5 с.

Рис. 100. Производительность протоколов TCP (слева) и ARTCP (справа)


248

При более подробном рассмотрении этих графиков можно заметить, что при использовании стандартного механизма управ-ления потоком буфер маршрутизатора переполняется и, как след-ствие, происходит отбрасывание пришедших к маршрутизатору сегментов. В процессе работы стандартного механизма управления потоком теряются три сегмента (повторную передачу этих сегмен-тов можно увидеть на первой паре графиков – там, где виден зна-чительный «разрыв» между передачами сегментов). Первый по-вторно передается с помощью механизма быстрой ретрансляции (это можно увидеть, если посмотреть на вторую пару графиков – там видно, что перед получением соответствующего подтвержде-ния отправителем была принята серия одинаковых дублированных подтверждений). Для повторной передачи остальных сегментов используется таймер повторной передачи. Из-за случившихся по-терь протокол TCP и проигрывает протоколу ARTCP в скорости передачи информации.

8.4. Выводы В этой главе приведены примеры того, как могут быть ис-

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


249

Заключение

Транспортные протоколы играют важную роль в управлении трафиком как в глобальных сетях, таких, как Интернет, так и в ло-кальных и корпоративных сетях. Согласно [1], около 95% всех пе-реданных байтов и 85 – 95% всех переданных пакетов в Интернете передаются с помощью протокола TCP (Transmission Control Protocol). Этот протокол – основной протокол транспортного уровня в архитектуре TCP/IP. Главной задачей этого протокола яв-ляется обеспечение надежной передачи данных через ненадежную среду передачи. Протокол TCP обеспечивает управление потоком между конечными системами. С момента своей начальной публи-кации [16] протокол претерпел ряд изменений, целью большинства которых было улучшение механизма управления потоком.

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

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

Предложен метод, который позволяет легко адаптировать модель для представления новых версий протокола TCP, причем получаемая в результате модель может быть использована для ис-следования как качественных (корректность), так и количествен-ных (производительность) характеристик протокола. Для анализа приведенной в книге модели использовался широко известный па-кет Design/CPN.


250

Литература 1. Tanenbaum A.S. Computer Networks. Third edition, Prentice-

Hall, New Jersey, 1996. 2. Jacobson V. Congestion Avoidance and Control // ACM SIG-

COMM'88. 1988. 3. Holzmann G. Design and Validation of Computer Protocols.

Prentice Hall, New Jersey, 1991. 4. Postel J. Transmission Control Protocol // RFC793 (STD7).

1981. 5. Braden R. T. Requirements for Internet Hosts – Communication

Layers // RFC1122. 1989. 6. Jacobson V., Braden R., Borman D. TCP Extensions for High

Performance // RFC1323. 1992. 7. Karn P., Partridge C. Estimating Round-trip Times in Reliable

Transport Protocols // ACM SIGCOMM'87. 1987. 8. Nagle J. Congestion Control in IP/TCP Networks. // ARPANET

Working Group Requests for Comment (RFC-896), DDN Network In-formation Center, SRI International, Menlo Park, CA. 1984.

9. Бертсекас Д., Галлагер Р. Сети передачи данных: Пер. с англ. М., 1989.

10. George F., Young G. SNA Flow Control: Architecture and Im-plementation // IBM System Journal. 1982. Vol. 21. №. 2. P. 179 – 210.

11. Digital Equipment Corporation. DECnet Digital Network Ar-chitecture [phase IV] General Description // Order AA-N149A-TC, Digital Equipment Corporation. 1982.

12. Postel J. B., Sunshine C. A., and Cohen D. The ARPA Internet Protocol // Computer Networks. 1981. Vol. 5. № 4. P. 171 – 261.

13. Yang C., Reddy A. A Taxonomy for Congestion Control Algo-rithms in Packet Switching Networks // IEEE Network Magazine. 1995. Vol. 9. № 5.

14. Brakmo L., O'Malley S., Peterson L. TCP Vegas: New Tech-niques for Congestion Detection and Avoidance // ACM SIGCOMM. 1994. P. 24 – 35.

15. Brakmo L., Peterson L. TCP Vegas: End to End Congestion Avoidance on a Global Internet // IEEE Journal on Selected Areas in Communications. 1995. 13(8).


251

16. Lefelhocz C., Lyles B., Shenker S., Zhang L. Congestion Con-trol for Best-Effort Service: Why We Need a New Paradigm // IEEE Network. 1996. Vol. 10. № 1.

17. Braden B., Clark D., Crowfort J., Deering S., Estrin D. Rec-ommendations in Queue Management and Congestion Avoidance in the Internet // RFC 2309. 1998.

18. Floyd S., Jacobson V. Random Early Detection gateways for Congestion Avoidance // IEEE/ACM Transactions on Networking. 1993. Vol.1. № 4. Р. 397 – 413.

19. Brakmo L., Peterson L. Performance Problems in BSD4.4 TCP // ACM Computer Communications Review. 1995. 25(5). Р. 69 – 86.

20. Caceres R., Danzig P., Jamin S., Mitzel D. Characteristics of Wide-Area TCP/IP Conversations // ACM SIGCOMM’91. 1991.

21. Fall K., Floyd S. Simulation-based Comparisons of Tahoe, Re-no, and SACK TCP // Computer Communications Review. 1996. July.

22. Tomey C. Rate-Based Congestion Control Framework for Con-nectionless Packet-Switched Networks // Doctor of Philosophy Thesis. University of New South Wales Australian Defense Force Academy. 1997.

23. Benmohamed L., Meerkov S. M. Feedback Control of Conges-tion in Packet Switched Networks: The Case of a Single Congested Node // IEEE Transactions on Networking. 1993. Vol. 1. № 6. Р. 693 – 707.

24. Charney A. An Algorithm for Rate Allocation in a Packet-Switched Network with Feedback // M.Sc. thesis. Department of EECS. MIT. 1994.

25. Ramakrishnan K., Jain R. A Binary Feedback Scheme for Con-gestion Avoidance in Computer Networks // ACM Transactions on Computer Systems. 1990. Vol. 8. № 2. Р. 158– 181.

26. Keshav S. The Packet Pair Flow Control Protocol // ICSI Tech. Rept. TR-91-028. Computer Science Division, Department of EECS, University of California, Berkeley and International Computer Science Institute. Berkeley, CA. 1991. May.

27. Bennett J., Zhang H. Hierarchical Packet Fair Queuing Algo-rithms // ACM SIGCOMM'96. 1996. Aug.

28. Demers A., Keshav S., Shenker S. Analysis and Simulation of a Fair Queuing Algorithm // ACM SIGCOMM’89. 1989. Р. 3 – 12.


252

29. Floyd S., Jacobson V. Link Sharing and Resource Management Models for Packet Networks // IEEE/ACM Transactions on Network-ing. 1995. 3(4).

30. Алексеев И.В. Интегрированные услуги нового поколения Internet // Сети. 1999. № 10. С. 102 – 108.

31. Geria M. Kleinrock L. Congestion Control in Interconnected LANs // IEEE Network. 1988. Vol. 2. № 1.

32. Floyd S. TCP and Explicit Congestion Notification // Computer Communications Review. 1994. 24(5). Р. 10 – 23.

33. Clark D., Lambert M., Zhang L. NETBLT: A High Throughput Transport Protocol // ACM SIGCOMM '88. 1988. Р. 306 – 312.

34. Clark D., Lambert M., Zhang L. NETBLT: A Bulk Data Trans-fer Protocol // RFC 969. 1987.

35. Wang Z., Crowcroft J. A New Congestion Control Scheme: Slow Start and Search (Tri-S) // ACM Computer Communications Re-view. 1991. Vol. 21. Р. 32 – 34.

36. Wang Z., Crowcroft J. Eliminating periodic packet losses in the 4.3-Tahoe BSD TCP congestion control algorithm // ACM computer communications review. 1992. Vol. 22. Р. 9 – 16.

37. Selecting Sequence Number. // SIGCOMM/SIGOPS Interpro-cess Commun. Workshop. ACM. 1975. Р. 11 – 23.

38. Sunshine C., Dalal Y. Connection Management in Transport Protocols. // Computer Networks. 1978. Vol. 2. Р. 454 – 473.

39. Watson R. Timer-Based Mechanisms in Reliable Transport Protocol Connection Management // Computer Networks. 1981. Vol. 5. Р. 47 – 56.

40. End-to-End Arguments in System Design // ACM Trans. on Computer Systems. 1984. Vol. 2. Р. 277 – 288.

41. Deering S., Hinden R. Internet Protocol Version 6 (IPv6) Speci-fication // RFC 2460. 1998.

42. Bartlett К., Scantlebury R., Wilkinson P. A note on reliable full-duplex transmission over half-duplex lines // Comm. of the ACM. 1969. Vol. 12. № 5. Р. 260 – 265.

43. Cerf V., Kahn R. A protocol for packet network intercommuni-cation // IEEE Trans. on communications. 1974. Vol. COM-22, № 5. Р. 637 – 648.

44. Chiu D., Jain R. Networks With Connectionless Network Layer; Part III: Analysis Of The Increase And Decrease Algorithms


253

// Tech. Rep. DEC-TR-509. Digital Equipment Corporation, Stanford, CA. 1987.

45. Wang Z. Routing And Congestion Control In Datagram Net-works // Doctor Of Philosophy Thesis. University College London. London UK. 1992.

46. Padhye J., Firoiu V., Towsley D., Kurose J. Modelling TCP throughput: a simple model and its empirical validation // ACM SIG-COMM’98. 1998.

47. Johnson D., Maltz D. Protocols for Adaptive Wireless and Mobile Networking // IEEE Personal Communications. 1996. February. Р. 34 – 42.

48. Eckhardt D., Steenkiste P. Measurement and Analysis of the Er-ror Characteristics of an In-Building Wireless Network // Proc. of ACM SIGCOMM '96. 1996. Р. 243 – 254.

49. Cáceres R., Iftode L. Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments // IEEE Jour-nal of Selected Areas in Communication. 1995. 13(5). Р. 850 – 857.

50. Balakrishnan H., Padmanabhan V.N., Seshan S., Katz R.H. A Comparison of Mechanisms for Improving TCP Performance over Wireless Links // Proc. of ACM SIGCOMM. 1996. Р. 256 – 269.

51. Balakrishnan H., Padmanabhan V.N., Katz R.H. The Effects of Asymmetry on TCP Performance // Proc. Of ACM/IEEE International Conf. on Mobile Computing and Networking. 1997. September.

52. Alekseev I.V., Sokolov V.A. Compensation Mechanism for Adaptive Rate TCP // 1-St International IEEE/Popov Seminar “Internet: Technologies A and Services”. 1999. October. P. 68 – 75.

53. Алексеев И.В., Соколов В.А. Протокол TCP с адаптацией скорости // Моделирование и анализ информационных систем. 1999. Т. 6, №1. С. 4 – 12.

54. Алексеев И.В. Математическая модель протокола TCP с адаптацией скорости // Моделирование и анализ информационных систем. 1999. Т. 6, № 2. С. 51 – 53.

55. Гольдштейн Б. Протоколы сети доступа. М., 1999. 56. Holzmann C. A Theory for Protocol Validation // IEEE Trans-

actions on Computers. 1982. Vol. C-31, № 8. Р. 730 – 738. 57. Holzmann C. Tracing Protocols // AT&T Technical Journal.

1985. Vol. 64. Р. 2413 – 2434.


254

58. An Improved Protocol Reachability Analysis Technique // Software, Practice and Experience. 1988. Vol. 18, №. 2. Р. 137 – 161.

59. Bajaj S., Breslau L., Estrin D., Fall K., Floyd S. Improving Si-mulation for Network Research // Technical Report 99-702. University of Southern California. 1999. March.

60. Estrin D., Handley M., Heidemann J., McCanne S., Xu Y., Yu H. Network Visualization with the VINT Network Animator Nam // Technical Report 99-703. University of Southern California. 1999. March.

61. K. Fall Network Emulation in the Vint/NS Simulator // Proc. of ISCC’99. 1999.

62. Stroustrup B. The C++ Programming Language. Addison-Wesley. Third edition. 1997.

63. Schildt H. C the Complete Reference // McGraw-Hill, Berkeley CA. Second edition. 1987.

64. McKusick M., Bostic K., Karels M., Osterman J. The Design and Implementation of the 4.4 BSD Operating System. Addison-Wesley, 1996.

65. Floyd S., Jacobson V. Link-sharing and Resource Management Models for Packet Networks // IEEE/ACM Transactions on Network-ing. 1995. Vol. 3, № 4. Р. 365 – 386.

66. Wakeman I., Ghosh A., Crowcroft J., Jacobson V., Floyd S. Implementing Real Time Packet Forwarding Policies using Streams. // Usenix 1995 Technical Conference. 1995. January.

67. Keshav S., Sharma R. Issues and Trends in Router Design // Department of computer science, Cornell University. 1998.

68. Ginsburg D. ATM: Solutions for Enterprise Internetworking. Addison Wesley Longman Limited. UK. 1996.

69. C. Nicoll Overview: Multiservice Networking // Packet. Cisco Systems Inc. 1999. January.

70. Unix Unleashed. SAMS Publishing. Indiannapolis. 1994. 71. Miller M. Internetworking. M&T Books, New York, 1991. 72. Allman M., Glover D., Sanchez L. Enhancing TCP over Satel-

lite Channels using Standard Mechanisms // RFC 2488. 1999. 73. Chiu D., Jain R. Analysis of the Increase and Decrease Algo-

rithms for Congestion Avoidance in Computer Networks // Computer Networks and ISDN Systems. 1989. Vol. 17. Р. 1 – 14.


255

74. Bach M. J. THE DESIGN OF THE UNIX OPERATING SYS-TEM. Prentice Hall, NJ, 1986.

75. Nemeth E., Snyder G., Seebass S., Hein T. UNIX System Ad-ministration Handbook. Prentice Hall PTR. NJ. Second edition. 1995.

76. Алексеев И. В. Модель и анализ транспортного протокола ARTCP // Электронный журнал "Исследовано в России". 2000. № 27. С. 395 – 404. http://zhurnal.mipt.rssi.ru/articles/2000/027.pdf

77. Balakrishnan H., Seshan S., Amir E., Katz R. Improving TCP/IP Performance over Wireless Networks // Proc. Mobicom'95. 1995. June.

78. Floyd S. Connections with Multiple Congested Gateways in Packet Switched Networks, Part 1: One-Way Traffic // ACM Computer Communications Review. 1991. 21 (5). Р. 30 – 47.

79. Morris R. TCP Behavior with Many Flows // IEEE Interna-tional Conference on Network Protocols. US. 1997. October.

80. Henderson T., Sahouria E., McCanne S., Katz R. On Improving the Fairness of TCP Congestion Avoidance // Proc. IEEE Globecom '98. 1998.

81. Bonald T. Comparison of TCP Reno and TCP Vegas via Fluid Approximation // Rapport de recherche N. 3563. INSTITUT NA-TIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTO-MATIQUE. 1998.

82. Altman E., Bolot J., Nain P., Elouadghiri D., Erramdani M., Brown P., Collange D. Performance Modelling of TCP/IP in Wide-Area Network // Rapport de recherche N. 3142. INSTITUT NATION-AL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATI-QUE. 1997.

83. Lakshman T., Madhow U. The Performance of TCP/IP for Networks with High Bandwidth-delay Product and Random Loss // IEEE/ACM Transactions on Networking. 1997. June.

84. Comer D. Internetworking with TCP/IP, Vol. II: Design Im-plementation and Internals. Prentice Hall, NJ. 1994.

85. Comer D. Internetworking with TCP/IP, Vol. III: Client - Serv-er Programming and Applications. Prentice Hall, NJ. 1994.

86. Stevens R. Advanced Programming in the UNIX Environment. Addison-Wesley. 1992.


256

87. Shepard T. TCP Packet Trace Analysis // Masters of Science Thesis. Massachusetts institute of Technology. MIT/LCS/TR-494. 1991. February.

88. Frost V., Melamed B. Traffic modelling for telecommunica-tions networks // IEEE Communications Magazine. 1994. 32(2). Р. 70 – 80.

89. Leland W., Taqqu M., Willinger W., Wilson D. On the Self-Similar Nature of Ethernet Traffic (Extended Version) // IEEE/ACM Transactions on Networking. 1994. 2(1). Р. 1 – 15.

90. Gusella R. A Measurement Study of Diskless Workstations Traffic on an Ethernet // IEEE Trans. on Communications. 1990. 38(9). Р. 1557 – 1568.

91. Paxson V., Floyd S. Wide-Area Traffic: The Failure of Poisson Modelling // IEEE/ACM Transactions on Networking. 1995. 3(3). Р. 226 – 244.

92. Floyd S., Jacobson V. The Synchronization of Periodic Routing Messages // IEEE/ACM Transactions on Networking. 1994. 2(2). Р. 122 – 136.

93. Willinger W., Taqqu M., Erramili A. A Bibliographical Guide to Self-Similar Traffic and Performance Modeling for Modern High-Speed Networks // Stochastic Networks: Theory and Applications, Cla-rendon Press (Oxford University Press). Oxford. 1996. Р. 339 – 366.

94. Taqqu M., Teverovsky V., Willinger W. Estimators for long-range dependence: an empirical study // Fractals. 1995. Vol. 3, №. 4. Р. 785 – 788.

95. Taqqu M., Teverovsky V., Willinger W. Is network traffic self-similar or multifractal? // Fractals. 1997. № 5. Р. 63 – 73.

96. Riedi R., Vehel J. TCP traffic is multifractal: a numerical study // INRIA research report 3129. 1997. March.

97. Riedi R., Willinger W. Towards an Improved Understanding of Network Traffic Dynamics // Рreprint chapter from the book "Self-similar Network Traffic and Performance Evaluation". 1999.

98. Taqqu M., Willinger W., Sherman R. Proof of Fundamental Re-sult in Self-Similar Traffic Modelling // Computer Communications Review. 1997. № 27. Р. 5-23.

99. Crovella M., Taqqu M., Bestavros A. Heavy-Tailed Probability Distributions in the World Wide Web // Рreprint chapter from the book


257

"A Practical Guide to Heavy Tails: Statistical Techniques and Applica-tions". Alder R., Feldman R., Taqqu M. Birkhauser. Boston, US. 1998.

100. Willinger W., Taqqu M., Sherman R., Wilson D. Self-similarity through high variability: Statistical analysis of Ethernet LAN traffic at source level // IEEE/ACM Transactions of Networking. 1997. № 5. Р. 71 – 86.

101. Christensen S., Haagh T.B. Design/CPN Overview of CPN ML Syntax. Version 3.0. - Department of Computer Science, Aarhus University, Aarhus, Denmark. 1996.

102. Milner R., Tofte M., Harper R. The Definition of Standard ML (Revisited). MIT Press, 1997.

103. Standard ML of New Jersey, Bell Labs, World Wide Web.} http://cm.bell-labs.com/cm/cs/what/smlnj.

104. Bellovin S.M. Security Problems in the TCP/IP Protocol Suite // Computer Communication Review. 1989. Vol.19, № 2. Р. 32 – 48.

105. Mathis M., Mahdavi J., Floyd S., Romanow A. TCP Selective Acknowledgement Option. RFC2018. 1996.

106. Allman M., Paxson V., Stevens W.: TCP Congestion Control. RFC2581. 1999.

107. Floyd S., Mahdavi J., Mathis M., Podolsky M. An Extension to the Selective Acknowledgement (SACK) Option for TCP. RFC2883. 2000.

108. Paxson V., Allman M. Computing TCP's Retransmission Ti-mer. RFC2988. 2000.

109. Allman M., Balakrishnan H., Floyd S. Enhancing TCP's Loss Recovery Using Limited Transmit. RFC3042. 2001.

110. Allman M., Floyd S., Partridge C. Increasing TCP's Initial Window. RFC3390. 2002.

111. Алексеев И.В. Адаптивная схема управления потоком для транспортного протокола в сетях с коммутацией пакетов: Дис. … канд. физ.-мат. наук. Ярославль, 2000.

112. Alekseev I.V., Sokolov V.A. ARTCP: Efficient Algorithm for Transport Protocol for Packet Switched Networks // In Proceedings of Parallel Computer Technologies'2001. Lecture Notes in Computer Science. Vol. 2127. Springer-Verlag, 2001.Р. 159 – 174.

113. Alekseev I.V., Sokolov V.A. Modelling and Traffic Analysis of the Adaptive Rate Transport Protocol // Future Generation Computer Systems. Number 6, Vol.18. - NH Elsevier, 2002. Р. 813 – 827.


http://cm.bell-labs.com/cm/cs/what/smlnj�

258

114. Jensen K. Coloured Petri Nets. Basic Concepts, Analysis Me-thods and Practical Use. Vol. 1. Basic Concepts // Monographs in Theoretical Computer Science. Springer-Verlag. 1992.

115. Jensen K. Coloured Petri Nets. Basic Concepts, Analysis Me-thods and Practical Use. Vol. 2. Analysis Methods // Monographs in Theoretical Computer Science. Springer-Verlag. 1995.

116. Jensen K. Coloured Petri Nets. Basic Concepts, Analysis Me-thods and Practical Use. Vol. 1. Practical Use // Monographs in Theo-retical Computer Science. Springer-Verlag. 1997.

117. High-Level Petri Nets. / Jensen, K., Rozenberg, G., (ред.). Springer-Verlag. 1991.

118. Christensen S., Jorgensen J.B., Kristensen L.M. Design/CPN - A Computer Tool for Coloured Petri Nets // In: Brinksma, E. (ред.): Proceedings of TACAS'97. Lecture Notes in Computer Science, Vol. 1217. Springer-Verlag, 1997. Р. 209 – 223.

119. World of Coloured Petri Nets. University of Aarhus, Comput-er Science Department, World-Wide Web. http://www.daimi.aau. dk/CPnets.

120. Design/CPN Online. World-Wide Web. http://www.daimi.au. dk /designCPN/.

121. de Figueiredo J.C.A., Kristensen L.M. Using Coloured Petri Nets to Investigate Behavioural and Performance Issues of TCP Proto-cols // In: Jensen, K. (ed.): Proceedings of the Second Workshop on Practical Use of Coloured Petri Nets and Design/CPN. 1999. Р. 21 – 40.

122. Clausen H., Jensen P.R. Validation and Performance Analysis of Network Algorithms by Coloured Petri Nets // In: Proceedings of PNPM'93. IEEE Computer Society Press, 1993. Р. 280 – 289.

123. Clausen H., Jensen P.R. Analysis of Usage Parameter Control Algorithm for ATM Networks // In: Tohme, S. and Casada, A. (ред.): Broadband Communications II (C-24). Elsevier Science Publishers, 1994. Р. 297 – 310.

124. Fall K., Floyd S. Simulation-Based Comparisons of Tahoe, Reno, and SACK TCP // Computer Communication Review. 26(3):5-21. 1996.

125. Kumar A. Comparative Performance Analysis of Versions of TCP in a Local Network with a Lossy Link // IEEE/ACM Transactions on Networking. 1998. Vol. 6(4). Р. 485 – 498.


http://www.daimi.aau.dk/CPnets�

http://www.daimi.aau.dk/CPnets�

http://www.daimi.au.dk/designCPN/�

http://www.daimi.au.dk/designCPN/�

259

126. Jensen K., Christensen S., Kristensen L.M. Design/CPN Oc-currence Graph Manual, Version 3.0. - Department of Computer Science, Aarhus University, Aarhus, Denmark. 1996.

127. Jorgensen J.B., Kristensen L.M. Design/CPN OE/OS Graph Manual, Version 1.0. - Department of Computer Science, Aarhus Uni-versity, Aarhus, Denmark. 1996.

128. Lindstrom B., Wells L. Design/CPN Performance Tool Ma-nual, Version 1.0. - Department of Computer Science, Aarhus Universi-ty, Aarhus, Denmark. 1999.

129. Design/CPN Reference Manual for X-Windows, Version 2.0. - Meta Software Corporation, Cambridge, MA. 1993.

130. Gordon S., Billington J. Analysing the WAP Class 2 Wireless Transaction Protocol Using Coloured Petri Nets // In Proceedings of the 21st International Conference on Application and Theory of Petri Nets. Lecture Notes in Computer Science. Vol. 1825. Springer-Verlag, 2000. Р. 207 – 226.

131. Chaly D. Ju., Sokolov Valery A. An Extensible Coloured Petri Net Model of a Transport Protocol for Packet Switched Networks // In Proceedings of Parallel Computer Technologies'2003. Lecture Notes in Computer Science. Springer-Verlag, 2003.

132. Хакен Г. Синергетика. М., 1980.


260

Оглавление Предисловие ............................................................................................... 3Введение ...................................................................................................... 6

ЧАСТЬ 1. ТРАНСПОРТНЫЙ ПРОТОКОЛ TCP И ЕГО МОДИФИКАЦИЯ ARTCP ............................................ 11Глава 1. Коммуникационные транспортные протоколы ................ 11

1.1. Системы протоколов ..................................................................... 121.2. Эталонные модели ........................................................................ 211.3. Модель TCP/IP ............................................................................... 241.4. Транспортный уровень ................................................................. 261.5. Протокол TCP ................................................................................ 441.6. Свойство самоподобия сетевого трафика ................................... 551.7. Управление потоками в коммуникационных системах ............. 651.8. Недостатки протокола TCP .......................................................... 771.9. Основные характеристики транспортного протокола ............... 81

Глава 2. Алгоритм ARTCP ................................................................... 832.1. Особенности протокола ARTCP .................................................. 832.2. Структурная схема ARTCP .......................................................... 882.6. Совместимость с TCP ................................................................... 972.7. Сравнение ARTCP и TCP на основе анализа алгоритма ........... 972.8. Направления дальнейшего развития ARTCP .............................. 99

Глава 3. Имитационная модель ......................................................... 1013.1. Формат сообщения ...................................................................... 1023.2. Объектная структура ПМ ........................................................... 1043.3. Главный цикл ............................................................................... 1133.4. Дуплексный режим ..................................................................... 1133.5. Трассировка модели .................................................................... 1143.6. Визуализация данных ................................................................. 116

Глава 4. Результаты моделирования ................................................ 1204.1. Общая схема модельного эксперимента ................................... 1204.2. Сценарий 1: изолированный ARTCP ......................................... 1234.3. Сценарий 2: определение важнейших параметров сети .......... 129 Сценарий 3: ARTCP и TCP в условиях ошибок передачи ....... 135 Сценарий 4: ARTCP и TCP – коэффициент использования .... 138 Сценарий 5: ARTCP и TCP – коэффициент равноправия ........ 140 Сценарий 6: ARTCP и TCP – средняя длина очереди ............. 142 Сценарий 7: 1 ARTCP и 1 CBR .................................................. 145 Сценарий 8: 2 ARTCP и 1 CBR .................................................. 149 Сценарий 9: свойство самоподобия трафика ARTCP .............. 153


261

ЧАСТЬ 2. РАСШИРЯЕМАЯ МОДЕЛЬ ТРАНСПОРТНЫХ ПРОТОКОЛОВ ........................... 159Глава 5. Раскрашенные сети Петри ................................................. 159

5.1. Пример системы для моделирования ........................................ 1595.2. Элементы теории раскрашенных сетей Петри ......................... 1605.3. Динамическое поведение раскрашенных сетей Петри ............ 1625.4. Временные раскрашенные сети Петри ...................................... 1635.5. Методы анализа раскрашенных сетей Петри ........................... 1645.6. Система моделирования Design/CPN ........................................ 165

Глава 6. Моделируемые спецификации протоколов ..................... 1686.1. Протокол TCP .............................................................................. 1696.2. Интерфейс между протоколом TCP и пользовательскими процессами .......................................................................................... 1706.3. Интерфейс между протоколами TCP и IP ................................. 1746.4. Управление соединением ........................................................... 1766.5. Управление передачей ................................................................ 1816.6. Расширения протокола TCP ....................................................... 1886.7. Протокол ARTCP ........................................................................ 194

Глава 7. Сетевые модели протоколов ............................................... 1977.1. Иерархическая структура модели .............................................. 1977.2. Моделирование обработки вызовов пользователя ................... 1997.3. Моделирование передачи сегментов в сеть .............................. 2147.4. Моделирование обработки пришедших сегментов .................. 2227.5. Типы позиций .............................................................................. 2327.6. Моделирование сетевых компонент .......................................... 2337.7. Модификация модели ................................................................. 2397.8. Выводы ......................................................................................... 241

Глава 8. Экспериментальные данные ............................................... 2438.1. Пример ......................................................................................... 2438.2. Верификация протоколов ........................................................... 2448.3. Анализ производительности протоколов .................................. 2468.4. Выводы ......................................................................................... 248

Заключение ............................................................................................ 249


262

Научное издание

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

Чалый Дмитрий Юрьевич

Моделирование и анализ транспортных протоколов в информационных сетях

Редактор, корректор В.Н. Чулкова Компьютерная верстка И.Н. Ивановой

Подписано в печать 29.12.2004 г. Формат 60×84/16. Бумага тип. Усл. печ. л. 11,85. Уч.-изд. л. 9,0.

Тираж 500 экз. Заказ .

Оригинал-макет подготовлен в редакционно-издательском отделе ЯрГУ.

Типография Ярославского государсвтенного

технического университета.

150000 г. Ярославль, ул. Советская, 14а.


263


264

[if notrcv errrcv(uca


Documents

709.моделирование и анализ транспортных протоколов в информационных сетях монография