WikiDer > Контроль перегрузки TCP

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

Операция

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

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

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

В 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]

Быстрая ретрансляция

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

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

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

Алгоритмы

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

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

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

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

ПТС Тахо и Рино

Алгоритмы 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 и сбрасывается в состояние медленного запуска.^[13]
• Reno: если получены три дублирующих ACK, Reno выполнит быструю повторную передачу и пропустит фазу медленного старта, вместо этого уменьшив вдвое окно перегрузки (вместо установки его на 1 MSS, как у Tahoe), установив порог медленного старта, равный новому окну перегрузки. , и войдите в фазу, называемую Быстрое выздоровление.^[14]

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

TCP Vegas

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

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

TCP Нью-Рино

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 при высокой частоте ошибок.^[17]

TCP Hybla

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

TCP BIC

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

TCP CUBIC

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

Agile-SD TCP

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

TCP Westwood +

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

Составной TCP

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

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

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

TCP BBR

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

При реализации в YouTubeBBR повысил пропускную способность сети в среднем на 4%, а в некоторых странах - до 14%.^[26] BBR также доступен для QUIC. Он доступен для Linux TCP, начиная с Linux 4.9.^[27][28]

BBR эффективен и быстр, но его справедливость по отношению к потокам, не относящимся к BBR, оспаривается. В то время как презентация Google показывает, что BBR хорошо сосуществует с CUBIC,^[24] такие исследователи, как Джефф Хьюстон и Хок, Блесс и Зиттербарт, считают, что это несправедливо по отношению к другим потокам и не масштабируется.^[29] Хок и др. Также обнаружили «некоторые серьезные неотъемлемые проблемы, такие как увеличенные задержки в очередях, несправедливость и массовая потеря пакетов» в реализации BBR Linux 4.9.^[30]

Сохейл Аббаслоо и др. (авторы C2TCP) показывают, что BBR плохо работает в динамических средах, таких как сотовые сети.^[9][10] Они также показали, что у BBR есть проблема несправедливости. Например, когда КУБИЧЕСКИЙ поток (по умолчанию TCP реализация в Linux, Android и MacOS) сосуществует с потоком BBR в сети, поток BBR может доминировать над потоком CUBIC и получать от него всю полосу пропускания канала (см. рисунок 18 в ^[9]).

C2TCP

Сотовая контролируемая задержка TCP (C2TCP)^[9][10] был мотивирован отсутствием гибкого сквозного подхода TCP, который может удовлетворить различные QoS требования различных приложений, не требуя каких-либо изменений в сетевых устройствах. C2TCP стремится удовлетворить сверхнизкие задержка и требования к высокой пропускной способности таких приложений, как виртуальная реальность, видео-конференция, онлайн-игры, системы автомобильной связии т. д. в очень динамичной среде, такой как текущая LTE и будущее 5G сотовые сети. C2TCP работает как добавить поверх TCP с потерями (например, Reno, NewReno, КУБИЧЕСКИЙ, BIC, ...) и ограничивает среднюю задержку пакетов желаемыми задержками, установленными приложениями.

Исследователи из NYU^[31] показал, что C2TCP превосходит по показателям задержки / джиттера различные современные схемы TCP. Например, они показали, что по сравнению с BBR, CUBIC и Westwood в среднем, C2TCP снижает среднюю задержку пакетов примерно на 250%, 900% и 700% соответственно в различных средах сотовой сети.^[9]

C2TCP требуется только для установки на стороне сервера.

Эластичный TCP

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

NATCP / NACubic

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

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

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

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

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

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

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

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

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

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

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

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

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

Черный ящик

• Высокоскоростной TCP^[46]
• BIC TCP (Протокол управления двоичным увеличением перегрузки) использует вогнутое увеличение частоты источников после каждого события перегрузки до тех пор, пока окно не сравняется с окном перед событием, чтобы максимизировать время, в течение которого сеть полностью используется. После этого он агрессивно зондирует.
• КУБИЧЕСКИЙ TCP - менее агрессивная и более систематическая производная BIC, в которой окно является кубической функцией времени с момента последнего события перегрузки, с точкой перегиба, установленной для окна до события.
• AIMD-FC (аддитивное увеличение мультипликативное уменьшение с быстрой сходимостью), усовершенствование AIMD.^[47]
• Биномиальные механизмы
• SIMD протокол
• GAIMD

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

• TCP Vegas - оценивает задержку постановки в очередь и линейно увеличивает или уменьшает окно так, чтобы постоянное количество пакетов на поток ставилось в очередь в сети. Вегас придерживается принципа пропорциональной справедливости.
• БЫСТРЫЙ TCP - достигает того же равновесия, что и Вегас, но использует пропорциональное управление вместо линейного увеличения и намеренно уменьшает усиление по мере увеличения полосы пропускания с целью обеспечения стабильности.
• TCP BBR - оценивает задержку в очереди, но использует экспоненциальное увеличение. Периодически намеренно замедляется для справедливости и уменьшения задержки.
• TCP-Westwood (TCPW) - потеря приводит к тому, что окно сбрасывается до оценки отправителя произведения задержки полосы пропускания, которое является наименьшим измеренным RTT, умноженным на наблюдаемую скорость получения ACK.^[48]
• C2TCP^[10][9]
• TFRC^[49]
• TCP-Real
• TCP-Джерси

Зеленая коробка

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

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

• Явный протокол управления (XCP) - маршрутизаторы XCP сигнализируют о явном увеличении и уменьшении окон перегрузки отправителя.
• MaxNet - MaxNet использует одно поле заголовка, которое несет максимальный уровень перегрузки любого маршрутизатора на пути потока. Скорость устанавливается в зависимости от максимальной загруженности, в результате чего макс-мин честность.^[50]
• JetMax – JetMax, как и MaxNet, также реагирует только на сигнал максимальной перегрузки, но также несет другие служебные поля.

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

• 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)

Примечания

Рекомендации

Источники

• Куроз, Джеймс; Росс, Кейт (2008). Компьютерные сети: подход сверху вниз (4-е изд.). Эддисон Уэсли. ISBN 978-0-13-607967-5.
• Куроз, Джеймс; Росс, Кейт (2012). Компьютерные сети: подход сверху вниз (6-е изд.). Пирсон. ISBN 978-0-13-285620-1.
• Аббаслоо, Сохейл; Сюй, Ян; Чао, Х. Джонатон; Ши, Ханг; Kozat, Ulas C .; Е, Инхуа (2019). «На пути к оптимальной производительности с помощью сети {TCP} на Mobile Edge». Рентон, Вашингтон: Ассоциация USENIX. Цитировать журнал требует | журнал = (помощь)
• Афанасьев, А .; Н. Тилли; П. Рейхер; Л. Клейнрок (2010). «Контроль перегрузки между хостами для TCP» (PDF). Обзоры и учебные пособия по коммуникациям IEEE. 12 (3): 304–342. CiteSeerX 10.1.1.228.3080. Дои: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