Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Протокол управления передачей (TCP) использует алгоритм предотвращения перегрузки сети, который включает в себя различные аспекты схемы аддитивного увеличения / мультипликативного уменьшения (AIMD), наряду с другими схемами, включая медленный запуск и окно перегрузки , для предотвращения перегрузки. Алгоритм заторы-избегание TCP является главным основанием для контроля перегрузки в сети Интернет. [1] [2] [3] [4] Согласно сквозному принципу , контроль перегрузки в значительной степени является функцией интернет-хостов., а не сама сеть. Есть несколько вариантов и версий алгоритма , реализованного в протокольных стеков в операционных системах компьютеров, подключенных к Интернету .

Операция [ править ]

Чтобы избежать перегрузки , TCP использует многогранную стратегию управления перегрузкой. Для каждого соединения TCP поддерживает окно перегрузки , ограничивая общее количество неподтвержденных пакетов, которые могут передаваться из конца в конец. Это несколько аналогично скользящему окну TCP, используемому для управления потоком . TCP использует механизм, называемый медленным запуском [1], для увеличения окна перегрузки после инициализации соединения или после тайм-аута . Он начинается с окна, кратного максимальному размеру сегмента.(MSS) по размеру. Хотя начальная скорость низкая, скорость роста очень высокая; для каждого подтвержденного пакета окно перегрузки увеличивается на 1 MSS, так что окно перегрузки фактически удваивается за каждое время приема-передачи (RTT).

Когда окно перегрузки превышает порог медленного старта, ssthresh , [a] алгоритм переходит в новое состояние, называемое предотвращением перегрузки. В состоянии предотвращения перегрузки, пока получены не дублирующиеся ACK [b], окно перегрузки аддитивно увеличивается на один MSS за каждый цикл приема-передачи. Это соответствует описанному ниже алгоритму AIMD .

Окно перегрузки [ править ]

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

Когда соединение установлено, окно перегрузки, значение, поддерживаемое независимо на каждом хосте, устанавливается на небольшое кратное MSS, разрешенному для этого соединения. Дальнейшее отклонение в окне перегрузки продиктовано подходом аддитивного увеличения / мультипликативного уменьшения (AIMD). Это означает, что если все сегменты получены и подтверждения достигают отправителя вовремя, к размеру окна добавляется некоторая константа. Когда окно достигает ssthresh , окно перегрузки увеличивается линейно со скоростью 1 / (окно перегрузки) сегмента при каждом новом полученном подтверждении. Окно продолжает увеличиваться, пока не истечет время ожидания. По таймауту:

  1. Окно перегрузки сбрасывается до 1 MSS.
  2. ssthresh установлен на половину размера окна перегрузки до тайм-аута.
  3. запускается медленный старт .

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

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

Медленный старт [ править ]

«Медленный старт» перенаправляется сюда. Для японской манги см. « Медленный старт» (манга) .

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

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

Медленный запуск изначально начинается с размера окна перегрузки (CWND), равного 1, 2, 4 или 10 MSS. [5] [3] : 1 Значение размера окна перегрузки будет увеличиваться на единицу с каждым полученным подтверждением (ACK), эффективно удваивая размер окна за каждый цикл приема- передачи. [c] Скорость передачи будет увеличиваться алгоритмом медленного старта до тех пор, пока либо не будет обнаружена потеря, либо объявленное окно получателя (rwnd) не станет ограничивающим фактором, либо пока не будет достигнуто ssthresh . Если происходит событие потери, TCP предполагает, что это связано с перегрузкой сети, и предпринимает шаги для уменьшения предлагаемой нагрузки на сеть. Эти измерения зависят от точного используемого алгоритма предотвращения перегрузки TCP.

TCP Tahoe
Когда происходит потеря, отправляется быстрая повторная передача , половина текущего CWND сохраняется как ssthresh, а медленный запуск начинается снова с его начального CWND. Как только CWND достигает ssthresh , TCP переходит на алгоритм предотвращения перегрузки, где каждый новый ACK увеличивает CWND на MSS / CWND. Это приводит к линейному увеличению CWND.
TCP Reno
Отправляется быстрая повторная передача, половина текущего CWND сохраняется как ssthresh и как новый CWND, таким образом пропуская медленный старт и переходя непосредственно к алгоритму предотвращения перегрузки. Общий алгоритм здесь называется быстрым восстановлением.

По достижении ssthresh TCP переходит с алгоритма медленного старта на алгоритм линейного роста (предотвращение перегрузки). В этот момент окно увеличивается на 1 сегмент для каждого времени задержки приема-передачи (RTT).

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

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

Аддитивное увеличение / мультипликативное уменьшение [ править ]

Добавка увеличение / уменьшение мультипликативный алгоритм (AIMD) представляет собой алгоритм управления с обратной связью . AIMD сочетает линейный рост окна перегрузки с экспоненциальным сокращением при перегрузке. Множественные потоки, использующие управление перегрузкой AIMD, в конечном итоге сойдутся, чтобы использовать равные количества конкурирующего канала. [7]

Это алгоритм, описанный в RFC 5681 для состояния «предотвращения перегрузки». [8] 

Быстрая ретрансляция [ править ]

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

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

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

Алгоритмы [ править ]

Соглашение об именах для алгоритмов управления перегрузкой (CCA) могло появиться в статье 1996 года Кевина Фолла и Салли Флойд. [9] [ неудачная проверка ]

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

  1. тип и количество отзывов, полученных от сети
  2. возможность инкрементального развертывания в текущем Интернете
  3. аспект производительности, который он нацелен на улучшение: продуктовые сети с высокой пропускной способностью и задержкой (B); ссылки с потерями (L); справедливость (F); преимущество перед короткими потоками (S); ссылки с переменной ставкой (V); скорость сходимости (C)
  4. критерий справедливости, который он использует

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

ВариантОбратная связьНеобходимые измененияПреимуществаСправедливость
(Новое) РиноПотеря--Задерживать
ВегасЗадерживатьОтправительМеньше потерьПропорциональный
ВысокоскоростнойПотеряОтправительВысокая пропускная способность
BICПотеряОтправительВысокая пропускная способность
КУБИЧЕСКИЙПотеряОтправительВысокая пропускная способность
C2TCP [10] [11]Потеря / ЗадержкаОтправительСверхнизкая задержка и высокая пропускная способность
NATCP [12]Многобитовый сигналОтправительПочти оптимальная производительность
Эластичный TCPПотеря / ЗадержкаОтправительВысокая пропускная способность / короткие и большие расстояния
Agile-TCPПотеряОтправительВысокая пропускная способность / короткое расстояние
H-TCPПотеряОтправительВысокая пропускная способность
БЫСТРЫЙЗадерживатьОтправительВысокая пропускная способностьПропорциональный
Составной TCPПотеря / ЗадержкаОтправительВысокая пропускная способностьПропорциональный
WestwoodПотеря / ЗадержкаОтправительL
ДжерсиПотеря / ЗадержкаОтправительL
BBR [13]ЗадерживатьОтправительBLVC, Bufferbloat
ЗАЖИММногобитовый сигналПриемник, МаршрутизаторVМакс-мин
TFRCПотеряОтправитель, ПолучательНет повторной передачиМинимальная задержка
XCPМногобитовый сигналОтправитель, Получатель, МаршрутизаторBLFCМакс-мин
VCP2-битный сигналОтправитель, Получатель, МаршрутизаторBLFПропорциональный
MaxNetМногобитовый сигналОтправитель, Получатель, МаршрутизаторBLFSCМакс-мин
JetMaxМногобитовый сигналОтправитель, Получатель, МаршрутизаторВысокая пропускная способностьМакс-мин
КРАСНЫЙПотеряМаршрутизаторУменьшенная задержка
ECNОднобитовый сигналОтправитель, Получатель, МаршрутизаторСниженная потеря

TCP Тахо и Рино [ править ]

Алгоритмы TCP Tahoe и Reno были ретроспективно названы в честь версий или разновидностей операционной системы 4.3BSD, в которых каждый из них впервые появился (которые сами были названы в честь озера Тахо и близлежащего города Рино, штат Невада ). Алгоритм Tahoe впервые появился в 4.3BSD-Tahoe (который был создан для поддержки миникомпьютера CCI Power 6/32 «Tahoe» ), а позже стал доступным для лицензиатов, не имеющих лицензии AT&T, как часть 4.3BSD Networking Release 1; это обеспечило его широкое распространение и внедрение. В 4.3BSD-Reno были внесены улучшения, которые впоследствии были выпущены для широкой публики как Networking Release 2 и более поздняя версия 4.4BSD-Lite.

Хотя оба считают тайм-аут повторной передачи (RTO) и дублирующиеся ACK как события потери пакетов, поведение Tahoe и Reno различается в первую очередь тем, как они реагируют на дублирующиеся ACK:

  • Tahoe: если получены три дублирующих ACK (т. Е. Четыре ACK, подтверждающие один и тот же пакет, которые не совмещаются с данными и не изменяют объявленное окно получателя), Tahoe выполняет быструю повторную передачу, устанавливает порог медленного старта на половину текущей перегрузки. окно, уменьшает окно перегрузки до 1 MSS и сбрасывает в состояние медленного запуска. [14]
  • Reno: если получены три дублирующих ACK, Reno выполнит быструю повторную передачу и пропустит фазу медленного старта, вместо этого уменьшив вдвое окно перегрузки (вместо установки 1 MSS, как у Tahoe), установив порог медленного старта, равный новому окну перегрузки. , и войдите в фазу, называемую быстрым восстановлением . [15]

Как в Tahoe, так и в Reno, если время ожидания ACK истекло (время ожидания RTO), используется медленный запуск, и оба алгоритма сокращают окно перегрузки до 1 MSS.

TCP Vegas [ править ]

Основная статья: TCP Vegas

До середины 1990-х все установленные TCP тайм-ауты и измеренные задержки приема-передачи основывались только на последнем переданном пакете в буфере передачи. Исследователи из Университета Аризоны Ларри Петерсон и Лоуренс Бракмо представили протокол TCP Vegas (названный в честь Лас-Вегаса , крупнейшего города в Неваде), в котором устанавливались таймауты и измерялись задержки приема-передачи для каждого пакета в буфере передачи. Кроме того, TCP Vegas использует дополнительное увеличение окна перегрузки. В сравнительном исследовании различных TCP CCA , TCP Vegas оказался самым плавным, за ним следует TCP CUBIC. [16]

TCP Vegas не получил широкого распространения за пределами лаборатории Петерсона, но был выбран в качестве метода контроля перегрузки по умолчанию для прошивки DD-WRT v24 SP2. [17]

TCP New Reno [ править ]

TCP New Reno, определенный в RFC 6582 (который устарел предыдущие определения в RFC 3782 и RFC 2582 ), улучшает повторную передачу во время фазы быстрого восстановления TCP Reno. Во время быстрого восстановления, чтобы окно передачи оставалось полным, для каждого возвращаемого дублирующего ACK отправляется новый неотправленный пакет с конца окна перегрузки. Для каждого ACK, который частично продвигается в пространстве последовательности, отправитель предполагает, что ACK указывает на новую дыру, и отправляется следующий пакет после ACKed порядкового номера.   

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

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

New Reno работает так же хорошо, как SACK при низкой частоте ошибок пакетов и существенно превосходит Reno при высокой частоте ошибок. [18]

TCP Hybla [ править ]

TCP Hybla направлена ​​на устранение штрафов за TCP-соединения, которые включают наземные или спутниковые радиоканалы с высокой задержкой. Усовершенствования Hybla основаны на аналитической оценке динамики окна перегрузки. [19]

TCP BIC [ править ]

Основная статья: BIC TCP

Управление двоичным увеличением перегрузки (BIC) - это реализация TCP с оптимизированным CCA для высокоскоростных сетей с высокой задержкой, известных как длинные толстые сети . [20] BIC используется по умолчанию в ядрах Linux с 2.6.8 по 2.6.18. [ необходима цитата ]

TCP CUBIC [ править ]

Основная статья: CUBIC TCP

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

Agile-SD TCP [ править ]

Agile-SD - это CCA на базе Linux, разработанная для реального ядра Linux. Это алгоритм на стороне приемника, который использует подход, основанный на потерях, с использованием нового механизма, называемого фактором гибкости (AF). для увеличения использования полосы пропускания в высокоскоростных сетях и сетях на короткие расстояния (сети с низким BDP), таких как локальные сети или оптоволоконные сети, особенно когда размер применяемого буфера невелик. [21] Он был оценен путем сравнения его производительности с Compound-TCP (CCA по умолчанию в MS Windows) и CUBIC (по умолчанию для Linux) с использованием симулятора NS-2. Это улучшает общую производительность до 55% в терминах средней пропускной способности.

TCP Westwood + [ править ]

Основная статья: TCP Westwood plus

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

Составной TCP [ править ]

Основная статья: Составной TCP

Составной TCP - это реализация TCP от Microsoft, которая одновременно поддерживает два разных окна перегрузки с целью достижения хорошей производительности на LFN, не нарушая при этом справедливости . Он широко использовался в версиях Windows, начиная с Microsoft Windows Vista и Windows Server 2008, и был перенесен на более старые версии Microsoft Windows, а также на Linux .

Пропорциональное снижение скорости TCP [ править ]

TCP Proportional Rate Reduction (PRR) [22] - это алгоритм, разработанный для повышения точности данных, отправляемых во время восстановления. Алгоритм гарантирует, что размер окна после восстановления будет как можно ближе к порогу медленного старта. В тестах, проведенных Google , PRR привел к сокращению средней задержки на 3–10%, а таймауты восстановления были сокращены на 5%. [23] PRR доступен в ядрах Linux, начиная с версии 3.2. [24]

TCP BBR [ править ]

Пропускная способность узкого места и время распространения туда и обратно (BBR) - это CCA, разработанный в Google в 2016 году. [25] Хотя большинство CCA основаны на потерях, они полагаются на потерю пакетов для обнаружения перегрузки и более низких скоростей передачи, BBR, как TCP Vegas основан на модели. Алгоритм использует максимальную полосу пропускания и время приема-передачи, в течение которых сеть доставляет самые последние исходящие пакеты данных для построения модели сети. Каждое кумулятивное или выборочное подтверждение доставки пакета создает выборку скорости, которая записывает объем данных, доставленных за интервал времени между передачей пакета данных и подтверждением этого пакета. [26]По мере того, как производительность контроллеров сетевых интерфейсов увеличивается с мегабит в секунду до гигабит в секунду, задержка, связанная с буферным разносом вместо потери пакетов, становится более надежным маркером максимальной пропускной способности, делая основанные на модели CCA, которые обеспечивают более высокую пропускную способность и меньшую задержку, например BBR. , более надежная альтернатива более популярным алгоритмам, основанным на потерях, таким как TCP CUBIC .

BBR доступен для Linux TCP начиная с Linux 4.9. [27] Это также доступно для QUIC . [28]

BBR версии 1 (BBRv1) эффективен и быстр, но его справедливость по отношению к потокам, не относящимся к BBR, оспаривается. При внедрении на YouTube BBRv1 повысил пропускную способность сети в среднем на 4%, а в некоторых странах - до 14%. [29] В то время как презентация Google показывает, что BBRv1 хорошо сосуществует с CUBIC, [25] исследователи, такие как Джефф Хьюстон и Хок, Блесс и Зиттербарт, считают его несправедливым по отношению к другим потокам и не масштабируемым. [30] Хок и др. Также обнаружили «некоторые серьезные неотъемлемые проблемы, такие как увеличенные задержки в очередях, несправедливость и массовая потеря пакетов» в реализации BBR Linux 4.9. [31]

Сохейл Аббаслоо и др. (авторы C2TCP) показывают, что BBRv1 плохо работает в динамических средах, таких как сотовые сети. [10] [11] Они также показали, что BBR имеет проблему несправедливости. Например, когда поток CUBIC (который является реализацией TCP по умолчанию в Linux, Android и MacOS) сосуществует с потоком BBR в сети, поток BBR может доминировать над потоком CUBIC и получать от него всю полосу пропускания канала (см. Рисунок 18 в [10] ).

Версия 2 пытается решить проблему несправедливости при работе вместе с управлением перегрузками на основе потерь, таким как CUBIC. [32] В BBRv2 модель, используемая BBRv1, расширена за счет включения информации о потере пакетов и информации из явного уведомления о перегрузке (ECN). Хотя BBRv2 может иногда иметь более низкую пропускную способность, чем BBRv1, обычно считается, что он имеет лучшую производительность .

C2TCP [ править ]

Сотовая контролируемая задержка TCP (C2TCP) [10] [11] была мотивирована отсутствием гибкого сквозного подхода TCP, который может удовлетворить различные требования QoS для различных приложений, не требуя каких-либо изменений в сетевых устройствах. C2TCP нацелен на удовлетворение требований к сверхнизкой задержке и высокой пропускной способности приложений, таких как виртуальная реальность , видеоконференцсвязь , онлайн-игры , системы автомобильной связи и т. Д., В высокодинамичной среде, такой как современные сотовые сети LTE и будущие 5G . C2TCP работает как надстройкапомимо TCP с потерями (например, Reno, NewReno, CUBIC , BIC , ...), он требуется только для установки на стороне сервера и ограничивает среднюю задержку пакетов до желаемых задержек, установленных приложениями. .

Исследователи из Нью-Йоркского университета [33] показали, что C2TCP превосходит по задержке и изменению задержки различные современные схемы TCP. Например, они показали, что по сравнению с BBR, CUBIC и Westwood в среднем, C2TCP снижает среднюю задержку пакетов примерно на 250%, 900% и 700% соответственно в различных средах сотовой сети. [10]

Elastic-TCP [ править ]

Elastic-TCP был предложен в феврале 2019 года Mohamed A. Alrshah et al. [34]для увеличения использования полосы пропускания в сетях с высоким BDP для поддержки недавних приложений, таких как облачные вычисления, передача больших данных, IoT и т. д. Это CCA на базе Linux, разработанная для ядра Linux. Это алгоритм на стороне приемника, который использует подход, основанный на потерях и задержках, с использованием нового механизма, называемого функцией взвешивания, коррелированной с окном (WWF). Он имеет высокий уровень эластичности, позволяющий работать с различными сетевыми характеристиками без необходимости ручной настройки. Он был оценен путем сравнения его производительности с Compound-TCP (CCA по умолчанию в MS Windows), CUBIC (по умолчанию для Linux) и TCP-BBR (по умолчанию для Linux 4.9 от Google) с использованием симулятора NS-2 и испытательного стенда. Elastic-TCP значительно улучшает общую производительность с точки зрения средней пропускной способности, коэффициента потерь и задержки. [34]

NATCP / NACubic [ править ]

Недавно Soheil Abbasloo et. al. предложил NATCP (Network-Assisted TCP) [12] - противоречивый проект TCP, нацеленный на мобильные пограничные сети, такие как MEC . Ключевая идея NATCP состоит в том, что если бы характеристики сети были известны заранее, TCP был бы спроектирован лучше. Следовательно, NATCP использует доступные функции и свойства в текущих архитектурах сотовой связи на основе MEC, чтобы приблизить производительность TCP к оптимальной. NATCP использует внеполосную обратную связь от сети к серверам, расположенным поблизости. Обратная связь от сети, которая включает в себя пропускную способность канала сотового доступа и минимальное RTT сети, помогает серверам регулировать скорость отправки. Как показывают предварительные результаты, [12] [35]NATCP превосходит современные схемы TCP, достигая по крайней мере в 2 раза большей мощности (определяемой как пропускная способность / задержка). NATCP заменяет традиционную схему TCP у отправителя. [ необходима цитата ]

Чтобы решить проблему обратной совместимости, они предложили другую версию под названием NACubic. NACubic - это обратно совместимый дизайн, не требующий изменения TCP на подключенных узлах. NACubic использует полученную обратную связь и принудительно ограничивает окно перегрузки (CWND) и частоту стимуляции по мере необходимости. [12]

Другие алгоритмы предотвращения перегрузки TCP [ править ]

  • БЫСТРЫЙ TCP
  • Обобщенный FAST TCP [36]
  • H-TCP
  • Дата-центр TCP
  • Высокоскоростной TCP
  • HSTCP-LP [37]
  • TCP-Иллинойс
  • TCP-LP [37]
  • TCP SACK
  • Масштабируемый TCP
  • TCP Veno [38]
  • Westwood
  • XCP [39]
  • YeAH-TCP [40]
  • TCP-FIT [41]
  • Предотвращение перегрузки с нормализованным интервалом времени (CANIT) [42]
  • Нелинейное управление перегрузкой нейронной сети на основе генетического алгоритма для сетей TCP / IP [43]

TCP New Reno был наиболее часто используемым алгоритмом, поддержка SACK очень распространена и является расширением Reno / New Reno. Большинство других - это конкурирующие предложения, которые все еще нуждаются в оценке. Начиная с версии 2.6.8, ядро ​​Linux переключило реализацию по умолчанию с New Reno на BIC . Реализация по умолчанию была снова изменена на CUBIC в версии 2.6.19. FreeBSD использует New Reno в качестве алгоритма по умолчанию. Однако он поддерживает ряд других вариантов. [44]

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

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

Zeta-TCP обнаруживает перегрузки по показателям задержки и скорости потерь и применяет различные стратегии отсрочки окна перегрузки, основанные на вероятности перегрузок, чтобы максимизировать полезную пропускную способность . Он также имеет несколько других улучшений для точного обнаружения потерь пакетов, избегая повторной передачи с таймаутом повторной передачи; и ускорять / контролировать входящий (скачиваемый) трафик. [46]

Классификация по осведомленности о сети [ править ]

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

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

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

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

Черный ящик [ править ]

  • Высокоскоростной TCP [48]
  • BIC TCP (протокол управления двоичным увеличением перегрузки) использует вогнутое увеличение скорости источников после каждого события перегрузки до тех пор, пока окно не сравняется с окном перед событием, чтобы максимизировать время, в течение которого сеть полностью используется. После этого он агрессивно зондирует.
  • CUBIC TCP - менее агрессивная и более систематическая производная от BIC, в которой окно является кубической функцией времени с момента последнего события перегрузки, с точкой перегиба, установленной для окна до события.
  • AIMD-FC (аддитивное увеличение, мультипликативное уменьшение с быстрой сходимостью), усовершенствование AIMD. [49]
  • Биномиальные механизмы
  • SIMD протокол
  • GAIMD

Серый ящик [ править ]

  • TCP Vegas - оценивает задержку постановки в очередь и линейно увеличивает или уменьшает окно, чтобы в сети ставилось в очередь постоянное количество пакетов на поток. Вегас придерживается принципа пропорциональной справедливости.
  • FAST TCP - достигает того же равновесия, что и Vegas, но использует пропорциональное управление вместо линейного увеличения и намеренно уменьшает усиление по мере увеличения полосы пропускания с целью обеспечения стабильности.
  • TCP BBR - оценивает задержку в очереди, но использует экспоненциальное увеличение. Периодически намеренно замедляется для справедливости и уменьшения задержки.
  • TCP-Westwood (TCPW) - потеря приводит к тому, что окно сбрасывается до оценки отправителя произведения задержки полосы пропускания, которое является наименьшим измеренным RTT, умноженным на наблюдаемую скорость получения ACK. [50]
  • C2TCP [11] [10]
  • TFRC [51]
  • TCP-Real
  • TCP-Джерси

Зеленая рамка [ править ]

  • Бимодальный механизм - механизм предотвращения и контроля бимодальных перегрузок .
  • Методы сигнализации, реализуемые маршрутизаторами
    • Случайное раннее обнаружение (RED) случайным образом отбрасывает пакеты пропорционально размеру очереди маршрутизатора, вызывая мультипликативное уменьшение некоторых потоков.
    • Явное уведомление о перегрузке (ECN)
  • Контроль перегрузки с помощью сети
    • NATCP [12] - TCP с поддержкой сети использует внеполосную явную обратную связь, указывающую минимальное RTT сети и пропускную способность канала сотового доступа.
    • VCP - протокол управления перегрузкой с переменной структурой ( VCP ) использует два бита ECN для явной обратной связи о состоянии перегрузки в сети. Он также включает алгоритм на стороне конечного хоста.

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

  • Протокол явного управления (XCP) - пакеты XCP несут заголовок перегрузки с полем обратной связи, указывающий на увеличение или уменьшение окна перегрузки отправителя. Маршрутизаторы XCP явно устанавливают значение обратной связи для эффективности и справедливости. [52]
  • MaxNet - MaxNet использует одно поле заголовка, которое несет максимальный уровень перегрузки любого маршрутизатора на пути потока. Скорость устанавливается как функция от этой максимальной перегрузки, что приводит к максимальной и минимальной справедливости . [53]
  • JetMax - JetMax , как и MaxNet, также отвечает только на сигнал максимальной перегрузки, но также несет другие служебные поля.

Использование Linux [ править ]

  • BIC используется по умолчанию в ядрах Linux с 2.6.8 по 2.6.18. (Август 2004 г. - сентябрь 2006 г.)
  • CUBIC используется по умолчанию в ядрах Linux, начиная с версии 2.6.19. (Ноябрь 2006 г.)
  • PRR включен в ядра Linux для улучшения восстановления после потери, начиная с версии 3.2. (Январь 2012 г.)
  • BBR встроен в ядра Linux для управления перегрузкой на основе модели, начиная с версии 4.9. (Декабрь 2016 г.)

См. Также [ править ]

  • Протокол управления передачей §§ Контроль  перегрузки и разработка
  • Перегрузка сети § Смягчение
  • Фоновый транспорт с низкой дополнительной задержкой (LEDBAT)

Заметки [ править ]

  1. ^ В некоторых реализациях (например, Linux) начальный ssthresh большой, поэтому первый медленный старт обычно заканчивается после потери. Однако ssthresh обновляется в конце каждого медленного запуска и часто влияет на последующие медленные запуски, вызванные тайм-аутами.
  2. ^ Когда пакет потерян, вероятность получения дубликатов ACK очень высока. В этом случае также возможно, хотя и маловероятно, что поток только что подвергся экстремальному переупорядочению пакетов, что также вызовет дублирование ACK.
  3. ^ Даже если на самом деле получатель может задерживать свои ACK, обычно отправляя один ACK на каждые два получаемых сегмента [2]

Ссылки [ править ]

  1. ^ а б в Якобсон и Карелс 1988 .
  2. ^ a b W. Stevens (январь 1997 г.). Алгоритмы медленного запуска TCP, предотвращения перегрузки, быстрой повторной передачи и быстрого восстановления . DOI : 10,17487 / RFC2001 . RFC 2001 .
  3. ^ а б М. Оллман; С. Флойд; К. Партридж (октябрь 2002 г.). Увеличение начального окна TCP . DOI : 10,17487 / RFC3390 . RFC 3390 .
  4. ^ «Предотвращение перегрузки TCP, объясненное с помощью диаграммы последовательности» (PDF) . eventhelix.com .
  5. ↑ Корбет, Джонатан. «Увеличение начального окна перегрузки TCP» . LWN . Проверено 10 октября 2012 года .
  6. ^ Ник О'Нил. « Что делает ваш сайт медленным? Может быть, кнопка « Мне нравится »». AllFacebook , 10 ноября 2010 г. Проверено 12 сентября 2012 г.
  7. ^ Чиу, Дах-Мин; Радж Джайн (1989). «Анализ алгоритмов увеличения и уменьшения для предотвращения перегрузок в компьютерных сетях». Компьютерные сети и системы ISDN . 17 : 1–14. CiteSeerX 10.1.1.136.8108 . DOI : 10.1016 / 0169-7552 (89) 90019-6 . 
  8. ^ Allman, M .; Паксон, В. (сентябрь 2009 г.). Контроль перегрузки TCP . IETF . сек. 3.1. DOI : 10,17487 / RFC5681 . RFC 5681 . Проверено 4 марта 2021 года .
  9. ↑ Падение, Кевин; Салли Флойд (июль 1996 г.). «Сравнение Tahoe, Reno и SACK TCP на основе моделирования» (PDF) . Обзор компьютерных коммуникаций . 26 (3): 5–21. CiteSeerX 10.1.1.586.2403 . DOI : 10.1145 / 235160.235162 . S2CID 7459148 .   
  10. ^ a b c d e f Abbasloo, S .; Xu, Y .; Чао, HJ (2019). «C2TCP: гибкий сотовый TCP, отвечающий строгим требованиям к задержке». Журнал IEEE по избранным областям коммуникаций . 37 (4): 918–932. arXiv : 1810.13241 . DOI : 10.1109 / JSAC.2019.2898758 . ISSN 0733-8716 . S2CID 53107038 .  
  11. ^ a b c d Abbasloo, S .; Li, T .; Xu, Y .; Чао, HJ (май 2018 г.). «Сотовая контролируемая задержка TCP (C2TCP)». Сетевая конференция и семинары IFIP 2018 : 118–126. arXiv : 1807.02689 . Bibcode : 2018arXiv180702689A . DOI : 10.23919 / IFIPNetworking.2018.8696844 . ISBN 978-3-903176-08-9. S2CID  49650788 .
  12. ^ а б в г д Аббаслоо и др. 2019 .
  13. ^ Кардуэлл, Нил; Ченг, Ючунг; Ганн, С. Стивен; Еганех, Сохейл Хассас; Якобсон, Ван (2016). «BBR: Контроль перегрузки на основе перегрузки» . Очередь . 14 (5): 20–53. DOI : 10.1145 / 3012426.3022184 . Проверено 6 декабря +2016 .
  14. ^ Kurose & Ross 2008 , стр. 284.
  15. ^ Kurose & Ross 2012 , стр. 277.
  16. ^ «Анализ производительности алгоритмов контроля перегрузки TCP» (PDF) . Проверено 26 марта 2012 года .
  17. ^ "Журнал изменений DD-WRT" . Проверено 2 января 2012 года .
  18. ^ VasanthiN., V .; SinghM., Ajith; Кумар, Ромен; Хемалата, М. (2011). Дас, Вину V; Саккачан, Несси (ред.). «Оценка протоколов и алгоритмов повышения производительности TCP в беспроводной / проводной сети». Международная конференция по вычислительному интеллекту и информационным технологиям . Коммуникации в компьютерных и информационных науках. Springer. 250 : 693–697. DOI : 10.1007 / 978-3-642-25734-6_120 . ISBN 978-3-642-25733-9.
  19. ^ "Архивная копия" . Архивировано из оригинального 11 октября 2007 года . Проверено 4 марта 2007 года .CS1 maint: заархивированная копия как заголовок ( ссылка )
  20. ^ В., Якобсон; RT, Брейден. Расширения TCP для путей с большой задержкой . DOI : 10,17487 / RFC1072 . RFC 1072 .
  21. ^ Альршах, Массачусетс; Осман, М .; Али, Б .; Ханапи, З.М. (сентябрь 2015 г.). «Agile-SD: алгоритм управления перегрузкой TCP на базе Linux для поддержки высокоскоростных сетей и сетей на короткие расстояния». Журнал сетевых и компьютерных приложений . 55 : 181–190. DOI : 10.1016 / j.jnca.2015.05.011 . S2CID 2645016 . 
  22. ^ «Пропорциональное снижение скорости для TCP» . Проверено 6 июня 2014 .
  23. ↑ Корбет, Джонатан. «LPC: ускорение работы сети» . Проверено 6 июня 2014 .
  24. ^ "Linux 3.2 - новички в ядре Linux" . Проверено 6 июня 2014 .
  25. ^ a b «BBR: Контроль перегрузки на основе перегрузки» . Проверено 25 августа 2017 года .
  26. ^ «Оценка скорости доставки» . Проверено 25 августа 2017 года .
  27. ^ "Управление перегрузкой BBR [LWN.net]" . lwn.net .
  28. ^ "Обновление BBR" . datatracker.ietf.org .
  29. ^ «Контроль перегрузки TCP BBR приходит в GCP - ваш Интернет стал быстрее» . Проверено 25 августа 2017 года .
  30. ^ "TCP и BBR" (PDF) . Проверено 27 мая 2018 .
  31. ^ «Экспериментальная оценка контроля перегрузки BBR» (PDF) . Проверено 27 мая 2018 .
  32. ^ «Оценка производительности TCP BBRv2» . Проверено 12 января 2021 года .
  33. ^ "Сотовая контролируемая задержка TCP (C2TCP)" . wp.nyu.edu . Проверено 27 апреля 2019 года .
  34. ^ а б Альршах, Массачусетс; Аль-Макри, Массачусетс; Осман, М. (июнь 2019 г.). «Elastic-TCP: гибкий алгоритм управления перегрузкой для адаптации к сетям с высоким BDP» . Системный журнал IEEE . 13 (2): 1336–1346. arXiv : 1904.13105 . Bibcode : 2019ISysJ..13.1336A . DOI : 10.1109 / JSYST.2019.2896195 .
  35. ^ Abbasloo, Soheil (3 июня 2019 г.), GitHub - Soheil-ab / natcp , получено 5 августа 2019 г.
  36. ^ Юань, Цао; Тан, Ляньшэн; Андрей, Lachlan LH; Чжан, Вэй; Цукерман, Моше (5 сентября 2008 г.). «Обобщенная схема FAST TCP». Компьютерные коммуникации . 31 (14): 3242–3249. DOI : 10.1016 / j.comcom.2008.05.028 . ЛВП : 1959,3 / 44051 .
  37. ^ a b «Группа рисовых сетей» .
  38. ^ "TCP Veno: Расширение TCP для передачи по сетям беспроводного доступа" (PDF) . Журнал IEEE по избранным областям коммуникации.
  39. ^ "XCP @ ISI" .
  40. ^ "Высокоскоростной TPC" (PDF) . www.csc.lsu.edu .
  41. ^ "Архивная копия" . Архивировано из оригинала 3 апреля 2011 года . Проверено 5 марта 2011 года .CS1 maint: заархивированная копия как заголовок ( ссылка )
  42. ^ Benaboud, H .; Berqia, A .; Мику, Н. (2002). «Аналитическое исследование алгоритма CANIT в протоколе TCP». Обзор оценки эффективности ACM SIGMETRICS . 30 (3): 20. DOI : 10,1145 / 605521,605530 . S2CID 6637174 . 
  43. ^ Rouhani, Modjtaba (2010). «Управление перегрузкой нелинейной нейронной сети на основе генетического алгоритма для сетей TCP / IP». 2010 2-я Международная конференция по вычислительному интеллекту, коммуникационным системам и сетям . С. 1–6. DOI : 10.1109 / CICSyN.2010.21 . ISBN 978-1-4244-7837-8. S2CID  15126416 .
  44. ^ «Сводка проекта пяти новых алгоритмов управления перегрузкой TCP» .
  45. ^ "iTCP - Интерактивный транспортный протокол - лаборатория Medianet, Кентский государственный университет" .
  46. ^ «Технический документ: Zeta-TCP - Интеллектуальное, адаптивное, асимметричное ускорение TCP» (PDF) . Проверено 6 декабря 2019 .
  47. ^ Лефтерис Маматас; Тобиас Харкс; Василис Цауссидис (январь 2007 г.). «Подходы к контролю перегрузки в пакетных сетях» (PDF) . Журнал Интернет-инженерии . 1 (1). Архивировано из оригинального (PDF) 21 февраля 2014 года.
  48. ^ "HighSpeed ​​TCP" . www.icir.org .
  49. ^ "Домашняя страница AIMD-FC" . neu.edu . Архивировано из оригинального 13 января 2009 года . Проверено 13 марта 2016 .
  50. ^ «Добро пожаловать в лабораторию сетевых исследований» . www.cs.ucla.edu .
  51. ^ «Управление перегрузкой на основе уравнений для одноадресных приложений» . www.icir.org .
  52. ^ Katabi, Dina; Хэндли, Марк; Рорс, Чарли (2002). «Контроль перегрузки для продуктовых сетей с высокой пропускной способностью и задержкой» . Материалы конференции 2002 г. по приложениям, технологиям, архитектурам и протоколам для компьютерных коммуникаций - SIGCOMM '02 . Нью-Йорк, Нью-Йорк, США: ACM Press. DOI : 10.1145 / 633025.633035 . ISBN 1-58113-570-X.
  53. ^ "MaxNet - Max-Min Fair, стабильное явное управление перегрузкой сигнализации" . netlab.caltech.edu .

Источники [ править ]

  • Куроз, Джеймс ; Росс, Кит (2008). Компьютерные сети: подход сверху вниз (4-е изд.). Эддисон Уэсли. ISBN 978-0-13-607967-5.
  • Куроз, Джеймс ; Росс, Кейт (2012). Компьютерные сети: подход сверху вниз (6-е изд.). Пирсон. ISBN 978-0-13-285620-1.
  • Аббаслоо, Сохейл; Сюй, Ян; Чао, Х. Джонатон; Ши, Ханг; Kozat, Ulas C .; Е, Инхуа (2019). «На пути к оптимальной производительности с помощью сети {TCP} на Mobile Edge» . Рентон, Вашингтон: Ассоциация USENIX. Цитировать журнал требует |journal=( помощь )
  • Афанасьев, А .; Н. Тилли; П. Рейхер; Л. Клейнрок (2010). «Контроль перегрузки между хостами для TCP» (PDF) . Обзоры и учебные пособия по коммуникациям IEEE . 12 (3): 304–342. CiteSeerX  10.1.1.228.3080 . DOI : 10,1109 / SURV.2010.042710.00114 . S2CID  8638824 .
  • Якобсон, Ван ; Карелс, Майкл Дж. (Ноябрь 1988 г.). «Предотвращение и контроль перегрузок» (PDF) . Обзор компьютерных коммуникаций ACM SIGCOMM . 18 (4): 314–329. DOI : 10.1145 / 52325.52356 .

Внешние ссылки [ править ]

  • Подходы к контролю перегрузки в пакетных сетях (PDF) , заархивировано из оригинала (PDF) 21 февраля 2014 г.
  • Документы по контролю за перегрузкой
  • Домашняя страница TCP Vegas
  • Оллман, Марк; Паксон, Верн; Стивенс, В. Ричард (апрель 1999 г.). «Быстрая ретрансляция / быстрое восстановление» . Контроль перегрузки TCP . IETF . сек. 3.2. DOI : 10,17487 / RFC2581 . RFC 2581 . Проверено 1 мая 2010 года .
  • Алгоритмы обработки и предотвращения перегрузки  TCP - Руководство по TCP / IP