Протокол TCP как средство распределенного управления инфраструктурой сетей передачи данных: история и перспективы развития

Протокол TCP как средство распределенного управления инфраструктурой сетей передачи данных: история и перспективы развития

1. Начальный этап развития средств распределенного управления

Впервые парадигма распределенного управления сетями коммутации пакетов, получившая сегодня массовое распространение, была описана в 1974 году (В. Серф, К. Кан) [1] и реализовывалась единым модулем Transmission Control Programm, который объединял в себе функции контроля соединений на уровне точка-точка и обеспечивал передачу датаграмм между отдельными узлами сети. Однако объем и сложность функций, которые должен был выполнять этот модуль, быстро росли, поэтому модуль был разделен на две части. Одна часть выполняла функции по трансляции датаграмм между форматами локальных сетей и их передаче на сетевом уровне – протокол IP (Internet Protocol), вторая часть контролировала соединение на уровне точка-точка – протокол TCP (Transmission Control Protocol) [2].

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

На ее верхнем прикладном уровне расположены несколько десятков протоколов, соответствующих современным приложениям (например, http – протокол передачи страниц гипертекста, smtp – протокол передачи электронной почты, ftp протокол передачи файлов и др.), на нижних уровнях иерархии расположены протоколы организации локальных сетей и протоколы физического уровня, описывающие алгоритмы разделения и использования непосредственных носителей сигнала (например, протоколы семейства IEEE 802.11). Однако, на транспортном уровне используются два протокола – TCP и UDP (User Datagramm Protocol) [3], которые контролируют соединения на уровне точка–точка, то есть на всем сетевом маршруте от отправителя к получателю. Если протокол UDP выполняет ограниченный набор функций, то протокол TCP реализует широкий ряд алгоритмов и является, по существу, единственным программным комплексом, который реализует функции распределенного управления ресурсами сетевой инфраструктуры, контролируя их загрузку, справедливость разделения ресурсов между соединениями, поддерживает связность сети и предоставляет гарантии доставки данных класса best effort.

Первый этап развития протокола TCP после выделения его в отдельный модуль начался в середине 80-х годов, когда в 1984 году впервые был предсказан, а в октябре 1986 впервые наблюдался так называемый коллапс перегрузки (congestion collapse) [4]. А именно, наблюдалось явление, когда в сети NSF-net полезная пропускная способность соединения снизилась с 32Kbit/s до 40bit/s при полностью исправном оборудовании. Соединение было установлено между ЭВМ, расположенными в LBL и UC Berkley на расстоянии пятисот метров, и управлялось реализацией TCP операционной системы (OC) Free BSD версии 4.3. Причина деградации пропускной способности состояла в том, что из-за перегрузки магистрального маршрутизатора некоторые TCPсегменты были потеряны. Затем эти сегменты в рамках механизма контроля доставки были отправлены повторно вместе с новыми порциями данных, которые в свою очередь также были потеряны на маршрутизаторе. Таким образом, сеть заполнилась повторно передаваемыми потерянными данными, которые также в свою очередь терялись, при этом каналы связи были полностью загружены, магистральный маршрутизатор перегружен, но новые данные не поступали в сеть.

Для решения этой проблемы В. Якобсоном [4] были предложены ряд методов и алгоритмов, которые в дальнейшем стали известны под общим названием контроль перегрузки (Congestion Control). Наиболее значимыми среди них были алгоритм медленного старта, который зондировал предел доступных ресурсов сетевого маршрута, и алгоритм предотвращения перегрузки. Также были усовершенствованы методы оценки характеристик времени кругового оборота (ВКО, англоязычный термин Round Trip Time или RTT) и разработан метод идентификации потерянных данных в условиях, когда сведения об их потере, отправленные получателем, также были утеряны на сетевом маршруте. Именно в этой работе была высказана идея о наличии обратной связи между поведением отправителя данных и пропускной способностью соединения и предложено считать потерю данных сигналом обратной связи, характеризующим состояние сетевого маршрута. Все эти предложения были реализованы в 1988 году в новой версии протокола TCP, SunOS версии 4.1.3,4.1.4 (Tahoe).

Однако в ходе эксплуатации версии TCP Tahoe возникла необходимость увеличить ее пропускную способность, так как после идентификации потери данных протокол прекращал передачу данных, используя алгоритм случайной отсрочки, затем снова входил в алгоритм медленного старта для зондирования нового предела доступных ресурсов сети. В рамках дальнейшего развития алгоритмов контроля перегрузки в 1990 году в очередном выпуске ОС BSD 4.3 впервые была реализована новая версия алгоритма предотвращения перегрузки, которую сегодня принято называть TCP Reno (М. Алман, В. Паксон, У. Стивенс) [5].

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

Следующая модификация также была направлена на повышение производительности алгоритма предотвращения перегрузки и определяла «событие потерь», как потери нескольких сегментов данных, идентифицированных в течение одного раунда отправителя, то есть при одном и том же размере скользящего окна. Протокол TCP Reno, в случае групповых потерь уменьшал размер скользящего окна в 2n раз, где n – число потерянных в раунде сегментов TCP. Теперь при обнаружении «события потерь» размер скользящего окна всегда уменьшался только в два раза. (С. Флойд, Т. Хендерсон). Новый протокол получил название NewReno [6].

Необходимо отметить, что параллельно с развитием алгоритмов распределенного управления шло развитие алгоритмов идентификации и повторной отправки потерянных данных. Так в первых версиях TCP использовались кумулятивные подтверждения, в которых получатель сообщал отправителю наибольший номер непрерывной последовательности сегментов. Недостаток этого подхода состоит в том, что отправитель не может получить сведения о данных, успешно доставленных после разрыва последовательности, вследствие чего вынужден повторно отправлять все сегменты, номера которых больше последнего подтвержденного. В 1996 году [7] впервые был предложен механизм выборочных подтверждений SACK (Selective acknowlegement), который также повысил производительность протокола и позволил несколько сократить нагрузку на сеть. Этот механизм реализован как опция, начиная с версии Reno и до настоящего времени. Алгоритмы повторной отправки данных также развивались, преследуя при этом две основные цели: сохранять производительность протокола с одной стороны и поддерживать целостность доставляемых данных с другой. Здесь нужно отметить алгоритмы быстрой повторной передачи и быстрого восстановления.

Все перечисленных выше алгоритмы и механизмы не только эффективно функционировали, но и поддерживали связность и целостность глобальной сети в условиях ее экспоненциального роста в течение, практически, двух десятилетий. В частности, RFC2581, содержащий описание основных элементов TCP Reno, имел статус действующего стандарта Интернет с 1999 до 2009 года, когда был заменен стандартом RFC5681 [8]. Последний наследует все ключевые парадигмы и методы [5], но предоставляет большую свободу разработчикам реализаций.

Параллельно с основной линией стандартных протоколов популярность получила версия TCP Vegas 1994 (Л. Бракмо, Л. Петерсон), которая не имеет статус стандарта, однако была реализована в некоторых операционных системах, включая последние версии ОС Linux. Сохраняя основную идеологию: зондирование доступного уровня мощности с последующим предотвращением перегрузки, алгоритмы TCP Vegas в качестве сигналов обратной связи использовали не факт потери данных, а результаты анализа последовательности значений времени кругового оборота, наблюдаемого отправителем [9]. Авторами протокола предполагалось, что рост времени кругового оборота происходит за счет увеличения задержек в очередях маршрутизаторов и, следовательно, означает приближение перегрузки сети. Таким образом, TCP Vegas идентифицировал перегрузку раньше, чем происходила потеря, и заранее снижал размер скользящего окна, используя аддитивный, а не мультипликативный метод. Кроме того, чтобы избежать осцилляций пропускной способности, свойственных TCP Reno, протокол строил оценки максимально доступной пропускной способности маршрута, которую и поддерживал через размер скользящего окна. Такая оценка строилась на основании минимального ВКО, наблюдаемого отправителем, и, следовательно, на загруженных маршрутах была завышенной. Кроме этого Vegas проигрывал конкуренцию Reno, так как, разделяя с Reno общий сетевой маршрут, определял перегрузку раньше и снижал пропускную способность, после чего Reno захватывал освободившуюся мощность. Однако достоинства TCP Vegas и ряд высказанных его авторами идей способствую продолжению исследований в этом направлении.

2. Развитие сетей пакетной коммутации в СССР

В СССР работы по исследованию и разработке сетей пакетной коммутации были начаты в середине 60-х годов в НИИ 101, в дальнейшем НИИ АА им. академика В.С. Семенихина. В 1967 году в НИИ AA начались активные работы [10] по разработке распределенной телекоммуникационной системы обмена данными (СОД) для автоматизированной системы управления АСУ 65с1. Базовые концепции того времени для таких систем предполагали жесткую иерархию, элементы которой должны были быть явно ассоциированы с иерархией элементов командной системы управления. Однако предполагаемые масштаб системы и диверсификация ее технологической и элементной базы, а также высокие требования к времени доставки, достоверности и уровню защиты данных делали ее весьма дорогой, громоздкой и ненадежной в рамках традиционного подхода.

Главным конструктором системы 65с1 В.В. Конашевым и И.А. Мизиным (в то время – заместителем Главного конструктора, в дальнейшем главным конструктором СОД) было решено создавать систему на основе пакетной коммутации, где сообщение разбивается на части, которые независимо доставляются получателю. Это решение было поддержано директором НИИ АА В.С. Семенихиным, а также начальником войск связи МО СССР маршалом А.И. Беловым.

В дальнейшем группой под руководством И. А. Мизина были разработаны теоретические основы таких сетей и успешно реализованы на практике в масштабной системе СОД – одной из ключевых подсистем командной системы боевого управления (КСБУ) стратегического звена управления Вооруженными Силами (В 1979 г. утвержден акт государственных испытаний системы, в 1985 г. она была поставлена на боевое дежурство). В 1983 г. специальным постановлением Правительства СССР была утверждена комплексная программа работ по созданию Автоматизированной системы управления всеми Вооруженными Силами страны – АСУ ВС СССР. Генеральным конструктором системы был определен академик В.С. Семенихин, а с 1997 г. академик И.А. Мизин.

В ходе работ по разработке СОД были получены важные теоретические результаты [11] по построению сетей пакетной коммутации, разработаны методы и алгоритмы, многие из которых предвосхитили направления дальнейшего развития сетей передачи данных и предсказали ряд современных проблем их развития. Ввиду секретности разработок эти результаты, к сожалению, своевременно не получили широкую известность. В частности, уже в работе [11], опубликованной в 1986 году, высказана идея о наличии обратной связи между поведением сетевых потоков и методами управления в сети: «...решение зависит от потоков сети, а потоки, в свою, очередь, зависят от принимаемого решения» [11, стр. 336]. В этой же работе обсуждаются проблема слабого заполнения широкополосных каналов в сети ARPA и вопрос о важности динамических алгоритмов маршрутизации, ставшие весьма актуальными в настоящее время.

Транспортный уровень системы СОД имеет много общих черт с транспортным уровнем принятой в настоящее время модели OSI. А именно: общее назначение и набор функций транспортных протоколов, контроль соединения на уровне точка–точка, контроль доставки данных, контроль последовательности и ряд других. Функции транспортного уровня обеспечивались транспортным протоколом магистральной сети (ТПМ), который в свою очередь разделялся на три модуля: протокол управления сеансом обмена, межконцевой протокол и протокол выдачи в драйвер. Эти три модуля обеспечивали установление соединения, разбиение данных на сегменты-письма, слежение за номерами последовательности, отправку квитанций-подтверждений, определение потерь данных по номерам последовательности подтверждений, контроль тайм-аута. Как и TCP протокол ТПМ использовал тройное рукопожатие для установления соединений, синхронизацию с буфером получателя, аналог механизма скользящего окна.

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

3. Современные проблемы и направления развития методов распределенного управления

В основе перечисленных выше версий протокола TCP лежало несколько фундаментальных идей, а именно: носителями сигнала являются высоконадежные стационарные каналы в некотором смысле однородные по уровню производительности, факт доставки данных более важен, чем скорость и порядок их доставки, потеря данных почти наверное происходит в результате перегрузки сетевой инфраструктуры, высокая задержка в сети означает большие очереди маршрутизаторов, идеология best effort – сеть предпринимает «наилучшее усилие» для доставки данных, однако не гарантирует ни сам факт доставки, ни ее параметры. На этапе развития интернет в 90-x годах 20-го века и нулевых годах 21-го эти фундаментальные идеи соответствовали природе сетевой инфраструктуры и требованиям наиболее популярных интернет-приложений. Однако дальнейшее развитие сети привело к диверсификации как приложений, так и самих носителей сигнала, что сделало неактуальными некоторые из перечисленных выше фундаментальных идей. Разберем эти проблемы более подробно.

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

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

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

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

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

TCP CUBIC [12] реализован в ядре ОС Linux, начиная с версии 2.6.19. Основное отличие от версии NewReno – период роста скользящего окна. Здесь версия CUBIC использует не линейную, а кубическую функцию в алгоритме предотвращения перегрузки. При этом в точке перегиба размер скользящего окна должен быть равен величине окна, при которой была идентифицирована потеря данных. Таким образом, протокол быстрее восстанавливает производительность после потери данных. Полином третьей степени построен таким образом, что размер скользящего окна возрастает как функция времени, прошедшего с последнего события потери данных и не зависит от длительности раундов, определяемой ВКО. Эта версия является модификацией версии BIC, которая использовалась по умолчанию в ядре ОС Linux с 2004 года вплоть до версии 2.6.18 включительно, однако по результатам экспериментального анализа была признана излишне агрессивной и, как таковая, подавляла транспортные потоки, контролируемые другими версиями протокола. Версия предназначена для широкополосных сетей с большими задержками, имеющими высокие значения коэффициента BDP (Bandwidth Delay Product).

High Speed TCP (HSTCP) [13] предназначен для широкополосных сетей – более 1Gbit/s, с большим временем кругового оборота – более 100ms, предложен С. Флойд в 2003 г. Он использует обобщенный алгоритм предотвращения насыщения, в котором коэффициенты линейного роста и степенного убывания определяются как выпуклая функция текущего размера скользящего окна. Если размер скользящего окна достигает некоторой верхней границы, протокол переходит на стандартную схему. Этот прием используют большинство версий, ориентированных на высокоскоростные сети. В частности версия CUBIC, начиная с некоторого значения, так же заменяет кубическую функцию роста на стандартную линейную.

Scalable TCP (STCP) [14] предложен Т. Келли также в 2003 году. Основная цель разработки этой версии – добиться, чтобы время восстановления потерянных данных было постоянным и не зависело от текущего размера скользящего окна. Для этого используются значения размера скользящего окна большие, чем у основного стандарта.

H-TCP [15], подобно версии CUBIC, использует время, прошедшее с момента последнего события потери данных, как аргумент полиномиальной функции второй степени для вычисления текущего размера скользящего окна. Для вычисления коэффициента степенного убывания эта версия использует функцию времени кругового оборота, предполагая, что последнее отражает задержки в очередях маршрутизаторов на сетевом маршруте. Таким образом, коэффициент убывания окна при потерях данных должен быть пропорционален размеру очереди. Протокол предложен институтом Гамильтона (Ирландия) в 2004 году, он также предназначен для сетей с высоким значением BDP.

TCP Hybla был разработан в 2003–2004 годах [16] в университете Болоньи (Италия) с целью улучшить эффективность работы TCP на сетевых маршрутах, содержащих спутниковые каналы, которые порождают большие значения времени кругового оборота. Версия TCP Hybla является еще одной попыткой устранить так называемый диспаритет времени кругового оборота. Стандартные версии TCP фактические используют дискретное время, единицы которого определяются периодом ВКО. Поэтому TCP соединения при равном уровне потерь будут показывать абсолютные значения пропускной способности тем большие, чем меньше время кругового оборота. Такой подход оправдан в стационарных сетях, где большие ВКО, как правило, означают рост задержек в очередях маршрутизаторов, но оказывается неверным при наличии в сетевом маршруте спутниковых, беспроводных и широкополосных каналов. Протокол TCP Hybla использует специальный коэффициент для расчета скользящего окна в алгоритме медленного старта и в алгоритме предотвращения перегрузок, что позволяет устранить зависимость пропускной способности от ВКО. При этом спутниковый канал будет демонстрировать пропускную способность, равную некоторому идеальному стационарному каналу с меньшим ВКО. На маршрутах с ВКО меньшим, чем ВКО идеального маршрута, TCP Hybla ведет себя так же как TCP Reno.

TCP Westwood [17] оценивает доступную пропускную способность сетевого маршрута на стороне отправителя, идентифицируя скорость поступления подтверждений получателя. В дальнейшем это значение присваивается переменной ssthresh [5]. Этот механизм может быть эффективным в беспроводных сетях, когда потери происходят вследствие сбоя канала передачи данных, а не вследствие перегрузки маршрутизаторов.

TCP Veno [18] сочетает принципы управления версий Reno и Vegas. В частности, этот протокол определяет размер скользящего окна, следуя стандартной схеме, однако использует анализ задержек, принятый версией Vegas, чтобы идентифицировать случайные потери данных на каналах связи. Если отправителем обнаружено событие потерь, однако величина задержки в очередях, оцениваемая на основании величины соответствующего ВКО, остается ниже заданного предела, TCP Veno предполагает, что имела место случайная потеря данных и уменьшает размер скользящего окна не вдвое, как это делает Reno, а на лишь 20%. Последнее свойство предполагает использование этой версии протокола TCP в беспроводных сетях и на сетевых маршрутах, содержащих ненадежные каналы связи.

Отметим также версию TCP-Illinois, которая, подобно протоколу H-TCP, использует динамическую функцию для определения параметров алгоритма предотвращения перегрузки, протокол TCP-LP (Low Priority), предназначенный для потоков с низким приоритетом и протокол TCP-YeAH [19] (Yet Another Highspeed TCP), который использует смешанный подход (анализ задержек и уровня потерь одновременно) для управления размером скользящего окна, пытаясь достигнуть высокой производительности, устойчивости к потерям данных, справедливого разделения элементов инфраструктуры с потоками под управлением версии Reno и избежать диспаритета ВКО. Протокол Compound TCP (CTCP) также для широкополосных сетей, был разработан корпорацией Microsoft и реализован для версий ОС Windows Vista и Windows Server 2008 г.

Таким образом, за прошедшие 40 лет именно протокол TCP с одной стороны сохранил свое место в стеке протоколов, с другой стороны весьма интенсивно развивался, включив в себя новые алгоритмы для решения актуальных задач управления. Реализации в рамках TCP алгоритмов контроля перегрузок (Congestion Control) и сегодня обеспечивают устойчивую работу Интернет. Однако диверсификация носителей сигнала породила новые проблемы распределенного управления, которые, фактически, на сегодняшний день остаются открытыми. Специализированные версии TCP, перечисленные выше, не обладают универсальными качествами стандарта [5], имеют экспериментальный статус и их использование требует дополнительного анализа и творческих усилий администраторов сетей. Поэтому в настоящее время продолжаются интенсивные исследования по разработке нового поколения транспортных протоколов.

Проблемы, связанные с требованиями, которые выставляют к вероятностно-временным характеристикам соединений мультимедийные потоки, также являются открытыми. В настоящее время для их поддержки на транспортном уровне, в основном, используется протокол UDP (User Datagramm Protocol). Этот протокол был зафиксирован в качестве стандарта в 1980 году [3] и сохраняет этот статус до настоящего времени. Протокол UDP обладает малым набором ограниченных функций, не контролирует доставку и целостность данных, не дает гарантий надежности работы соединения. Именно поэтому он может использоваться для голосовых и видеопотоков, систем реального времени, которые не чувствительны к потерям. В отличие от протокола TCP, приложения, основанные на UDP, не имеют эффективных механизмов контроля и предотвращения перегрузок и в силу этого несут потенциальную угрозу для стабильности фрагментов сети и Интернет в целом, при условии их интенсивного использования.

Заключение

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

В 90-x годах прошлого века доля потоков данных, контролируемых протоколом TCP на уровне точка-точка, составляла 95%. В настоящее время эта доля снизилась за счет мультимедийных потоков, которые на транспортном уровне чаще контролируются протоколом UDP. Однако ввиду отсутствия в UDP эффективных средств контроля перегрузок, проблема распределённого управления сетью, передающей мультимедийные потоки, остается открытой. Диверсификация носителей сигнала также предъявляет новые требования к работе транспортного уровня сети. Поэтому в настоящее время продолжаются интенсивные исследования по разработке нового поколения транспортных протоколов.

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

Список литературы

  1. Vinton G. Cerf, Robert E. Kahn. "A Protocol for Packet Network Intercommunication". IEEE Transactions on Communications 22 (5): 637–648, 1974.
  2. Transmission Control Protocol. Под редакцией J. Postel, 1981, RFC 793.
  3. J. Postel, User Datagram Protocol, 1980. RFC 768.
  4. V. Jacobson. Congestion Avoidance and Control. In Proceedings of the SIGCOMM ’88 Symposium, pp 314–32, Aug. 1988.
  5. M. Allman, V. Paxson, W. Stevens. TCP Congestion Control, 1999, RFC 2581.
  6. S. Floyd, T. Hendersin. The NewReno Modification to TCP’s Fast Recovery Algorithm, 1999, RFC 2582.
  7. M. Mathis, J. Mahdavi,S. Floyd,A. Romanow. TCP Selective Acknowledgment Options, 1996, RFC 2018.
  8. M. Allman, V. Paxson, E. Blanton. TCP Congestion Control, 2009, RFC 5681.
  9. L. Brakmo L. Peterson. TCP Vegas: End to End Congestion Avoidance on a Global Internet. // IEEE Journal on Selected Areas in Communication, Vol 13, No. 8 (October 1995) pp. 1465-1480.
  10. Игорь Александрович Мизин – ученый, конструктор, человек. Под редакцией академика И. А. Соколова. М.: ИПИ РАН. 2010.
  11. И. А. Мизин, В. А. Богатырев, А. П. Кулешов. Сети коммутации пакетов. М.: Радио и связь. 1986.
  12. S. Ha, I. Rhee, L. Xu. Cubic: a new tcp-friendly high-speed tcp variant. // SIGOPS Oper. Syst. Rev., 42(5), pp. 64–74, July, 2008.
  13. Floyd, S. HighSpeed TCP for Large Congestion Windows, 2003, RFC 3649 (Experimental), 2003.
  14. Kelly, T. Scalable TCP: Improving performance in highspeed wide area networks. ACM SIGCOMM Computer Communica tion Review 33, 2 (April 2003), 83–91.
  15. Shorten, R. N., Leith, D. J. H-TCP: TCP for high-speed and long-distance networks. In Proceedings of the Second PFLDNet Workshop (Argonne, Illinois, February 2004).
  16. Caini, C., Firrincieli, R. TCP hybla: a TCP enhancement for heterogeneous networks. // International Journal of Satellite Communication and Networking 22, 5 (September 2004), 547–566.
  17. Casetti, C., Gerla, M., Mascolo, S., Sanadidi, M. Y., Wang, R. TCP Westwood: Bandwidth estimation for enhanced transport over wireless links. In Proceedings of the 7th Annual International Conference on Mobile Computing and Networking, MobiCom ’01, pp. 287–297, New York, NY, USA, 2001. ACM.
  18. Fu, C. P., and Liew, S. C. TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks. // IEEE Journal of Selected Areas in Communications, Vol. 21(2), pp. 216 – 228.
  19. A. Baiocchi, A. P. Castellani, F. Vacirca. Yeah-tcp: Yet another highspeed tcp. In 5th International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet), March 2007. 

Об авторе: Петрозаводский государственный университет
Петрозаводск, Россия
olbgvl@cs.karelia.ru
Материалы международной конференции Sorucom 2014 (13-17 октября 2014)
Помещена в музей с разрешения авторов 28 ноября 2014