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

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

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

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

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

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

Окно перегрузки

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

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

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

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

Медленный старт и предотвращение перегрузок

«Медленный старт» перенаправляется сюда. Чтобы узнать о японской манге, см. Медленный старт (манга) .

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

Медленный старт начинается с начального значения cwnd, должно быть 2, 3 или 4 MSS. [7] Значение размера окна перегрузки может быть увеличено на 1 MSS с каждым полученным подтверждением (ACK), эффективно удваивая размер окна каждый RTT . [а] или меньше

Скорость передачи будет увеличиваться с помощью алгоритма медленного старта до тех пор, пока либо не будет обнаружена потеря пакета, либо объявленное окно получателя (rwnd) не станет ограничивающим фактором.

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

Если CWND достигает ssthresh , TCP переключается на алгоритм предотвращения перегрузки. Оно должно увеличиваться на 1 MSS для каждого RTT.

Распространенная формула заключается в том, что каждый новый ACK увеличивает CWND на MSS * MSS/CWND. Он почти линейный и обеспечивает приемлемое приближение

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

Когда отправитель TCP обнаруживает потерю сегмента с помощью таймера повторной передачи, а данный сегмент еще не был повторно отправлен с помощью таймера повторной передачи, значение ssthresh должно быть установлено не более

половина объема данных, которые были отправлены, но еще не подтверждены в совокупности. Или 2 * ПСС

TCP Тахо
Когда происходит потеря, отправляется повторная передача, половина текущего CWND сохраняется как ssthresh , и снова начинается медленный старт с исходного CWND.
ПТС Рино
Отправляется быстрая повторная передача , половина текущего CWND сохраняется как ssthresh и как новый CWND, таким образом, пропуская медленный старт и переходя непосредственно к алгоритму предотвращения перегрузки. Общий алгоритм здесь называется быстрым восстановлением.

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

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

Быстрая повторная передача

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

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

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

Алгоритмы

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

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

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

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

ВариантОбратная связьНеобходимые измененияПреимуществаСправедливость
(Новое) РеноПотеря——Задерживать
ВегасЗадерживатьОтправительМеньше потерьПропорциональный
ВысокоскоростнойПотеряОтправительВысокая пропускная способность
БИКПотеряОтправительВысокая пропускная способность
КУБИЧЕСКИЙПотеряОтправительВысокая пропускная способность
C2TCP [10] [11]Потеря/задержкаОтправительСверхнизкая задержка и высокая пропускная способность
НАТКП [12]Многобитный сигналОтправительПочти оптимальная производительность
Эластичный TCPПотеря/задержкаОтправительВысокая пропускная способность/короткая и междугородняя связь
Agile-TCPПотеряОтправительВысокая пропускная способность/короткое расстояние
H-TCPПотеряОтправительВысокая пропускная способность
БЫСТРЫЙЗадерживатьОтправительВысокая пропускная способностьПропорциональный
Соединение TCPПотеря/задержкаОтправительВысокая пропускная способностьПропорциональный
ВествудПотеря/задержкаОтправительл
ДжерсиПотеря/задержкаОтправительл
ББР [13]ЗадерживатьОтправительBLVC, буферный наполнитель
ЗАЖИММногобитный сигналПриемник, МаршрутизаторВМакс-мин
TFRCПотеряОтправитель, получательНет ретрансляцииМинимальная задержка
XCPМногобитный сигналОтправитель, получатель, маршрутизаторБЛФКМакс-мин
ВКП2-битный сигналОтправитель, получатель, маршрутизаторБЛФПропорциональный
МакснетМногобитный сигналОтправитель, получатель, маршрутизаторБЛФСКМакс-мин
ДжетМаксМногобитный сигналОтправитель, получатель, маршрутизаторВысокая пропускная способностьМакс-мин
КРАСНЫЙПотеряМаршрутизаторУменьшенная задержка
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), установив ssthresh равным новому окну перегрузки, и войти в фазу, называемую быстрым восстановлением . [15]

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

ПТС Нью Рино

TCP New Reno, определенный в RFC 6582 (который отменяет предыдущие определения в RFC 3782 и RFC 2582 ), улучшает повторную передачу на этапе быстрого восстановления TCP Reno.   

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

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

После повторной передачи вновь подтвержденные данные имеют два случая:

  • Полные подтверждения: ACK подтверждает все отправленные промежуточные сегменты, ssthresh не может быть изменен, cwnd может быть установлен на ssthresh
  • Частичные подтверждения: ACK не подтверждает все данные. Это означает, что может произойти еще одна потеря, повторите передачу первого неподтвержденного сегмента, если это разрешено.

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

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

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

TCP Вегас

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

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

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

TCP Гибла

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

TCP БИК

Основная статья: БИК ПТС

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

ПТС КУБИЧЕСКИЙ

Основная статья: КУБИЧЕСКИЙ 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 Вествуд+

Основная статья: TCP Westwood плюс

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

Соединение TCP

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

Составной TCP — это реализация Microsoft TCP, которая одновременно поддерживает два разных окна перегрузки с целью достижения хорошей производительности на 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 и получать от него всю пропускную способность канала (см. рисунок 16 в [10] ).

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

C2TCP

Cellular Controlled Delay 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]

Эластичный TCP

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

НАТКП

Сохейл Аббаслу и др. др. предложенный NATCP (Network-Assisted TCP) [12] спорный [ по мнению кого? ] Дизайн TCP, ориентированный на пограничные вычисления с множественным доступом(МЭК). Ключевая идея NATCP заключается в том, что если бы характеристики сети были известны заранее, протокол TCP был бы разработан по-другому. Таким образом, NATCP использует доступные функции и свойства современных сотовых архитектур на основе MEC, чтобы приблизить производительность TCP к оптимальной производительности. NATCP использует внеполосную обратную связь из сети на расположенные поблизости серверы. Обратная связь от сети, которая включает в себя пропускную способность канала сотового доступа и минимальное значение RTT сети, помогает серверам корректировать свои скорости отправки. Как показывают предварительные результаты, NATCP превосходит современные схемы TCP. [12] [35]

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

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

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

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

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

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

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

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

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

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

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

Черный ящик

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

Серая коробка

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

Зеленый ящик

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

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

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

Использование Linux

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

Смотрите также

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

Примечания

  1. ^ Даже если на самом деле получатель может задерживать свои ACK, обычно отправляя один ACK на каждые два сегмента, которые он получает [2]

использованная литература

  1. ^ Якобсон и Карелс 1988 .
  2. ^ a b В. Стивенс (январь 1997 г.). Алгоритмы медленного запуска TCP, предотвращения перегрузки, быстрой повторной передачи и быстрого восстановления . Дои : 10.17487 /RFC2001 . РФС 2001 .
  3. ^ М. Оллман; С. Флойд; К. Партридж (октябрь 2002 г.). Увеличение начального окна TCP . дои : 10.17487/RFC3390 . RFC 3390 .
  4. ^ «Предотвращение перегрузки TCP, объясненное с помощью диаграммы последовательности» (PDF) . www.eventhelix.com .
  5. ^ Чиу, Да-Мин; Радж Джайн (1989). «Анализ алгоритмов увеличения и уменьшения для предотвращения перегрузок в компьютерных сетях». Компьютерные сети и системы ISDN . 17 : 1–14. CiteSeerX 10.1.1.136.8108 . doi : 10.1016/0169-7552(89)90019-6 . 
  6. ^ Оллман, М .; Паксон, В. (сентябрь 2009 г.). Контроль перегрузки TCP . IETF . сек. 3.1. дои : 10.17487/RFC5681 . RFC 5681 . Проверено 4 марта 2021 г.
  7. ^ б Блэнтон , Итан; Паксон, Верн; Оллман, Марк (сентябрь 2009 г.). «Контроль перегрузки TCP» . {{cite journal}}: Журнал цитирования требует |journal=( помощь )
  8. ^ Ник О'Нил. « Что заставляет ваш сайт работать медленно? Может быть кнопка «Нравится »». AllFacebook , 10 ноября 2010 г. Проверено 12 сентября 2012 г.
  9. ^ Фолл, Кевин; Салли Флойд (июль 1996 г.). «Сравнения Tahoe, Reno и SACK TCP на основе моделирования» (PDF) . Обзор компьютерных коммуникаций . 26 (3): 5–21. CiteSeerX 10.1.1.586.2403 . дои : 10.1145/235160.235162 . S2CID 7459148 .   
  10. ^ a b c d e f Аббаслу, С .; Сюй, Ю .; Чао, HJ (2019). «C2TCP: гибкий сотовый TCP для удовлетворения строгих требований к задержке». Журнал IEEE по отдельным областям коммуникаций . 37 (4): 918–932. архив : 1810.13241 . doi : 10.1109/JSAC.2019.2898758 . ISSN 0733-8716 . S2CID 53107038 .  
  11. ^ a b c d Abbasloo, S .; Ли, Т .; Сюй, Ю .; Чао, HJ (май 2018 г.). «Управляемая сотовая связь с задержкой TCP (C2TCP)». Сетевая конференция и семинары ИФИП 2018 г .: 118–126. архив : 1807.02689 . Бибкод : 2018arXiv180702689A . doi : 10.23919/IFIPNetworking.2018.8696844 . ISBN 978-3-903176-08-9. S2CID  49650788 .
  12. ^ a b c d Abbasloo et al. 2019 .
  13. ^ Кардуэлл, Нил; Ченг, Ючунг; Ганн, К. Стивен; Йегане, Сохейл Хассас; Джейкобсон, Ван (2016). «BBR: управление перегрузкой на основе перегрузки» . Очередь . 14 (5): 20–53. дои : 10.1145/3012426.3022184 . Проверено 6 декабря 2016 г.
  14. ^ Куросе и Росс 2008 , с. 284.
  15. ^ Куросе и Росс 2012 , с. 277.
  16. ^ Васанти Н., В .; СингхМ., Аджит; Кумар, Ромен; Хемалата, М. (2011). Дас, Вину В.; Танкачан, Несси (ред.). «Оценка протоколов и алгоритмов для повышения производительности TCP в беспроводной / проводной сети». Международная конференция по вычислительному интеллекту и информационным технологиям . Коммуникации в области компьютерных и информационных наук. Спрингер. 250 : 693–697. doi : 10.1007/978-3-642-25734-6_120 . ISBN 978-3-642-25733-9.
  17. ^ «Анализ производительности алгоритмов управления перегрузкой TCP» (PDF) . Проверено 26 марта 2012 г.
  18. ^ "Журнал изменений DD-WRT" . Проверено 2 января 2012 г.
  19. ^ "Архивная копия" . Архивировано из оригинала 11 октября 2007 года . Проверено 4 марта 2007 г.{{cite web}}: CS1 maint: заархивированная копия как заголовок ( ссылка )
  20. ^ В., Якобсон; РТ, Брейден. Расширения TCP для путей с большой задержкой . дои : 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 г. {{cite journal}}: Журнал цитирования требует |journal=( помощь )
  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. архив : 1904.13105 . Бибкод : 2019ISysJ..13.1336A . doi : 10.1109/JSYST.2019.2896195 .
  35. ↑ Abbasloo , Soheil (3 июня 2019 г.), GitHub — Soheil-ab/natcp , получено 5 августа 2019 г.
  36. ^ Юань, Цао; Тан, Ляньшэн; Эндрю, Лахлан Л.Х.; Чжан, Вэй; Цукерман, Моше (6 июня 2008 г.). «Обобщенная схема FAST TCP» . Компьютерные коммуникации . 31 (14): 3242–3249. doi : 10.1016/j.comcom.2008.05.028 . hdl : 1959.3/44051 .
  37. ^ a b "Rice Networks Group" .
  38. ^ «TCP Veno: усовершенствование TCP для передачи по сетям беспроводного доступа» (PDF) . Журнал IEEE по отдельным областям коммуникации.
  39. ^ "XCP @ ISI" .
  40. ^ «Высокоскоростной TPC» (PDF) . www.csc.lsu.edu .
  41. ^ "Архивная копия" . Архивировано из оригинала 3 апреля 2011 года . Проверено 5 марта 2011 г.{{cite web}}: CS1 maint: заархивированная копия как заголовок ( ссылка )
  42. ^ Бенабуд, Х .; Беркия, А .; Микоу, Н. (2002). «Аналитическое исследование алгоритма CANIT в протоколе TCP». Обзор оценки производительности ACM SIGMETRICS . 30 (3): 20. doi : 10.1145/605521.605530 . S2CID 6637174 . 
  43. ^ Рухани, Моджтаба (2010). «Нелинейное управление перегрузкой нейронной сети на основе генетического алгоритма для сетей TCP / IP». 2010 2-я Международная конференция по вычислительному интеллекту, системам связи и сетям . стр. 1–6. doi : 10.1109/CICSyN.2010.21 . ISBN 978-1-4244-7837-8. S2CID  15126416 .
  44. ^ Канагаратинам, Мадхан Радж; Сингх, Сухдип; Сандип, Ирланки; Рой, Абхишек; Саксена, Наврати (январь 2018 г.). «D-TCP: алгоритм динамического управления перегрузкой TCP для мобильных сетей следующего поколения» . 15-я ежегодная конференция IEEE по сетям потребительских коммуникаций (CCNC), 2018 г .: 1–6. doi : 10.1109/CCNC.2018.8319185 .
  45. ^ Канагаратинам, Мадхан Радж; Сингх, Сухдип; Сандип, Ирланки; Ким, Хансок; Махешвари, Мукеш Кумар; Хван, Джэхён; Рой, Абхишек; Саксена, Наврати (2020). «NexGen D-TCP: алгоритм динамического управления перегрузкой TCP следующего поколения» . IEEE-доступ . 8 : 164482–164496. doi : 10.1109/ACCESS.2020.3022284 . ISSN 2169-3536 . 
  46. ^ «Резюме проекта пяти новых алгоритмов управления перегрузкой TCP» .
  47. ^ "iTCP - Интерактивный транспортный протокол - Лаборатория Medianet, Кентский государственный университет" .
  48. ^ «Технический документ: Zeta-TCP - интеллектуальное, адаптивное, асимметричное ускорение TCP» (PDF) . Проверено 6 декабря 2019 г. .
  49. ^ Лефтерис Маматас; Тобиас Харкс; Василис Цауссидис (январь 2007 г.). «Подходы к управлению перегрузками в пакетных сетях» (PDF) . Журнал интернет-инженерии . 1 (1). Архивировано из оригинала (PDF) 21 февраля 2014 г.
  50. ^ "Высокоскоростной TCP" . www.icir.org .
  51. ^ "Домашняя страница AIMD-FC" . neu.edu . Архивировано из оригинала 13 января 2009 года . Проверено 13 марта 2016 г.
  52. ^ «Добро пожаловать в лабораторию сетевых исследований» . www.cs.ucla.edu .
  53. ^ «Управление перегрузкой на основе уравнений для одноадресных приложений» . www.icir.org .
  54. ^ Катаби, Дина; Хэндли, Марк; Рорс, Чарли (2002). «Контроль перегрузки для сетей продуктов с высокой пропускной способностью и задержкой» . Материалы конференции 2002 г. по приложениям, технологиям, архитектурам и протоколам для компьютерных коммуникаций - SIGCOMM '02 . Нью-Йорк, Нью-Йорк, США: ACM Press: 89. doi : 10.1145/633025.633035 . ISBN 1-58113-570-Х.
  55. ^ "MaxNet - Max-Min Fair, стабильный контроль перегрузки с явной сигнализацией" . netlab.caltech.edu .

Источники

  • Куросе, Джеймс ; Росс, Кейт (2008). Компьютерные сети: нисходящий подход (4-е изд.). Эддисон Уэсли. ISBN 978-0-13-607967-5.
  • Куросе, Джеймс ; Росс, Кейт (2012). Компьютерные сети: нисходящий подход (6-е изд.). Пирсон. ISBN 978-0-13-285620-1.
  • Аббаслу, Сохейл; Сюй, Ян; Чао, Х. Джонатон; Ши, Ханг; Козат, Улас С .; Е, Инхуа (2019). «На пути к оптимальной производительности с TCP с поддержкой сети на Mobile Edge» . 2-й семинар USENIX по актуальным темам граничных вычислений (HotEdge 19) . Рентон, Вашингтон: Ассоциация USENIX.
  • Афанасьев, А .; Н. Тилли; П. Рейхер; Л. Клейнрок (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. дои : 10.1145/52325.52356 .

внешняя ссылка

  • Подходы к управлению перегрузками в пакетных сетях (PDF) , заархивировано из оригинала (PDF) 21 февраля 2014
  • Документы по контролю заторов
  • Домашняя страница TCP Vegas
  • Оллман, Марк; Паксон, Верн; Стивенс, В. Ричард (апрель 1999 г.). «Быстрая повторная передача/быстрое восстановление» . Контроль перегрузки TCP . IETF . сек. 3.2. дои : 10.17487/RFC2581 . RFC 2581 . Проверено 1 мая 2010 г.
  • Алгоритмы обработки перегрузок TCP и предотвращения перегрузок  — Руководство по TCP/IP
Получено с " https://en.wikipedia.org/w/index.php?title=TCP_congestion_control&oldid=1066067858 "
Contribute a better translation