✖


Jump to content

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

(Перенаправлено с 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-соединению также контролируется использованием окна приема , объявленного получателем. Отправитель может отправлять данные меньше, чем его собственное окно перегрузки и окно приема .

Медленный старт

[ редактировать ]

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

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

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

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

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

Когда отправитель TCP обнаруживает потерю сегмента с помощью таймера повторной передачи и данный сегмент еще не был отправлен повторно, значение ssthresh должно быть установлено не более чем на половину объема данных, которые были отправлены, но еще не подтверждены совокупно, или 2 * MSS , в зависимости от того, какое значение больше.

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

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

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

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

[ редактировать ]

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

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

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

Алгоритмы

[ редактировать ]

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

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

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

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

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

И в Тахо, и в Рено, если время ожидания ACK (таймаут RTO) истекает, используется медленный старт, и оба алгоритма уменьшают окно перегрузки до 1 MSS. [ нужна ссылка ]

TCP Нью-Рино

[ редактировать ]

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

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

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

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

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

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

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

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

TCP Вегас

[ редактировать ]
Основная статья: TCP Вегас

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

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

TCP Хибла

[ редактировать ]

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

TCP БИК

[ редактировать ]
Основная статья: БИК TCP

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

TCP КУБИК

[ редактировать ]
Основная статья: КУБИЧЕСКИЙ TCP

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

Agile-SD TCP

[ редактировать ]

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

TCP Вествуд+

[ редактировать ]
Основная статья: TCP Westwood plus

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

Соединение TCP

[ редактировать ]
Основная статья: Соединение TCP

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

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

[ редактировать ]

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

TCP ББР

[ редактировать ]

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

При внедрении на YouTube BBRv1 позволил повысить пропускную способность сети в среднем на 4 %, а в некоторых странах — до 14 %. [30] BBR доступен для Linux TCP начиная с Linux 4.9. [31] Он также доступен для QUIC . [32]

Справедливость BBR версии 1 (BBRv1) для потоков, отличных от BBR, оспаривается. Хотя презентация Google показывает, что BBRv1 хорошо сосуществует с CUBIC, [28] такие исследователи, как Джефф Хьюстон и Хок, Блесс и Зиттербарт, сочли это несправедливым по отношению к другим потокам и не поддающимся масштабированию. [33] Хок и др. также обнаружил «некоторые серьезные внутренние проблемы, такие как увеличение задержек в очередях, несправедливость и массовые потери пакетов» в реализации BBR в Linux 4.9. [34] Сохейл Аббаслу и др. (авторы C2TCP) показывают, что BBRv1 не очень хорошо работает в динамических средах, таких как сотовые сети. [11] [12] Они также показали, что у BBR есть проблема несправедливости. Например, когда поток CUBIC по умолчанию (который является реализацией TCP в Linux, Android и MacOS) сосуществует с потоком BBR в сети, поток BBR может доминировать над потоком CUBIC и получать от него всю пропускную способность канала (см. рисунок). 16 дюймов [11] ).

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

Версия 3 (BBRv3) исправляет две ошибки в BBRv2 (преждевременное завершение проверки полосы пропускания, конвергенция полосы пропускания) и выполняет некоторую настройку производительности. Существует также вариант, называемый BBR.Swift, оптимизированный для внутренних каналов обработки данных: он использует network_RTT (исключая задержку приемника) в качестве основного сигнала управления перегрузкой. [36]

C2TCP

[ редактировать ]

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

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

Эластичный 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 значительно улучшает общую производительность с точки зрения средней пропускной способности, коэффициента потерь и задержки. [38]

НАТКП

[ редактировать ]

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

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

[ редактировать ]

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

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

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

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

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

[ редактировать ]

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

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

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

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

Черный ящик

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

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

[ редактировать ]
  • TCP Vegas – оценивает задержку в очереди и линейно увеличивает или уменьшает окно, чтобы в сети в очереди стояло постоянное количество пакетов на каждый поток. Вегас реализует пропорциональную справедливость.
  • FAST TCP – обеспечивает то же равновесие, что и Vegas, но использует пропорциональное управление вместо линейного увеличения и намеренно уменьшает усиление по мере увеличения пропускной способности с целью обеспечения стабильности.
  • TCP BBR – оценивает задержку в очереди, но использует экспоненциальное увеличение. Намеренно периодически замедляется для справедливости и уменьшения задержки.
  • TCP-Westwood (TCPW) – потеря приводит к сбросу окна до оценки отправителя произведения задержки полосы пропускания (наименьшее измеренное RTT, умноженное на наблюдаемую скорость получения ACK). [58]
  • C2TCP [12] [11]
  • ТФРК [59]
  • TCP-Реал
  • TCP-Джерси

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

[ редактировать ]

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

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

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

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

См. также

[ редактировать ]

Примечания

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

Ссылки

[ редактировать ]
  1. ^ Джейкобсон и Карел 1988 .
  2. ^ Jump up to: а б У. Стивенс (январь 1997 г.). Алгоритмы медленного запуска TCP, предотвращения перегрузки, быстрой повторной передачи и быстрого восстановления . дои : 10.17487/RFC2001 . РФК 2001 .
  3. ^ Jump up to: а б М. Оллман; С. Флойд; К. Партридж (октябрь 2002 г.). Увеличение начального окна TCP . дои : 10.17487/RFC3390 . РФК 3390 .
  4. ^ «Предотвращение перегрузки TCP, объяснение с помощью диаграммы последовательности» (PDF) . eventelix.com .
  5. ^ Чиу, Да-Минг; Радж Джайн (1989). «Анализ алгоритмов увеличения и уменьшения перегрузок в компьютерных сетях». Компьютерные сети и системы ISDN . 17 : 1–14. CiteSeerX   10.1.1.136.8108 . дои : 10.1016/0169-7552(89)90019-6 .
  6. ^ Оллман, М.; Паксон, В. (сентябрь 2009 г.). Контроль перегрузки TCP . Рабочая группа по интернет-инжинирингу . сек. 3.1. дои : 10.17487/RFC5681 . РФК 5681 . Проверено 4 марта 2021 г.
  7. ^ Блэнтон, Итан; Паксон, Верн; Оллман, Марк (сентябрь 2009 г.). «Контроль перегрузки TCP» . Рабочая группа по интернет-инжинирингу. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  8. ^ Корбет, Джонатан. «Увеличение начального окна перегрузки TCP» . ЛВН . Проверено 10 октября 2012 г.
  9. ^ Ник О'Нил. « Что замедляет работу вашего сайта? Может быть кнопка «Нравится »». AllFacebook , 10 ноября 2010 г. Проверено 12 сентября 2012 г.
  10. ^ Фолл, Кевин; Салли Флойд (июль 1996 г.). «Сравнение Tahoe, Reno и SACK TCP на основе моделирования» (PDF) . Обзор компьютерных коммуникаций . 26 (3): 5–21. CiteSeerX   10.1.1.586.2403 . дои : 10.1145/235160.235162 . S2CID   7459148 .
  11. ^ Jump up to: а б с д и ж Аббаслу, С.; Сюй, Ю.; Чао, HJ (2019). «C2TCP: гибкий сотовый TCP, отвечающий строгим требованиям к задержке». Журнал IEEE по избранным областям коммуникаций . 37 (4): 918–932. arXiv : 1810.13241 . дои : 10.1109/JSAC.2019.2898758 . ISSN   0733-8716 . S2CID   53107038 .
  12. ^ Jump up to: а б с д Аббаслу, С.; Ли, Т.; Сюй, Ю.; Чао, HJ (май 2018 г.). «TCP с управляемой сотовой задержкой (C2TCP)». Сетевая конференция IFIP 2018 (Сеть IFIP) и семинары . стр. 118–126. arXiv : 1807.02689 . Бибкод : 2018arXiv180702689A . doi : 10.23919/IFIPNetworking.2018.8696844 . ISBN  978-3-903176-08-9 . S2CID   49650788 .
  13. ^ Jump up to: а б с д Аббаслу и др. 2019 .
  14. ^ Кардвелл, Нил; Ченг, Ючунг; Ганн, К. Стивен; Йегане, Сохейл Хассас; Джейкобсон, Ван (2016). «BBR: управление перегрузкой на основе перегрузки» . Очередь . 14 (5): 20–53. дои : 10.1145/3012426.3022184 .
  15. ^ Куросе и Росс 2008 , стр. 284.
  16. ^ Куросе и Росс 2012 , стр. 277.
  17. ^ Васанти Н., В.; Сингх М., Аджит; Кумар, Ромен; Хемалата, М. (2011). «Оценка протоколов и алгоритмов повышения производительности TCP в беспроводной/проводной сети». В Дасе, Вину В; Сакачан, Несси (ред.). Вычислительный интеллект и информационные технологии . Коммуникации в компьютерной и информатике. Том. 250. Спрингер. стр. 693–697. дои : 10.1007/978-3-642-25734-6_120 . ISBN  978-3-642-25733-9 .
  18. ^ «Анализ производительности алгоритмов управления перегрузкой TCP» (PDF) . Проверено 26 марта 2012 г.
  19. ^ «Журнал изменений DD-WRT» . Проверено 2 января 2012 г.
  20. ^ «Домашняя страница Хиблы» . Архивировано из оригинала 11 октября 2007 года . Проверено 4 марта 2007 г.
  21. ^ Каини, Карло; Фирринчели, Росарио (2004). «TCP Hybla: усовершенствование TCP для гетерогенных сетей» . Международный журнал спутниковой связи и сетей . 22 (5): 547–566. дои : 10.1002/сб.799 . ISSN   1542-0973 . S2CID   2360535 .
  22. ^ Каини, К.; Фирринчели, Р.; Лакамера, Д. (2009). «Сравнительная оценка производительности вариантов TCP в спутниковой среде» . Международная конференция IEEE по коммуникациям , 2009 г. стр. 1–5. дои : 10.1109/ICC.2009.5198834 . S2CID   8352762 .
  23. ^ В., Джейкобсон; RT, Брейден. Расширения TCP для путей с большой задержкой . дои : 10.17487/RFC1072 . РФК 1072 .
  24. ^ Альршах, Массачусетс; Отман, М.; Али, Б.; Ханапи, ЗМ (сентябрь 2015 г.). «Agile-SD: алгоритм управления перегрузкой TCP на базе Linux для поддержки высокоскоростных сетей на короткие расстояния». Журнал сетевых и компьютерных приложений . 55 : 181–190. arXiv : 1601.05908 . дои : 10.1016/j.jnca.2015.05.011 . S2CID   2645016 .
  25. ^ Матис, М.; Дуккипати, Н.; Ченг, Ю. (2013). Пропорциональное снижение скорости для TCP . дои : 10.17487/RFC6937 . РФК 6937 .
  26. ^ Корбет, Джонатан. «LPC: Ускорение работы сети» . Проверено 6 июня 2014 г.
  27. ^ «Linux 3.2 – новички в ядре Linux» . Проверено 6 июня 2014 г.
  28. ^ Jump up to: а б «BBR: управление перегрузкой на основе перегрузки» . Проверено 25 августа 2017 г.
  29. ^ Ченг, Ючунг; Кардвелл, Нил; Йегане, Сохейл Хассас; Джейкобсон, Ван (3 июля 2017 г.). «Оценка скорости доставки» . Рабочая группа по интернет-инжинирингу . Проверено 25 августа 2017 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  30. ^ «Контроль перегрузки TCP BBR теперь доступен в GCP — ваш Интернет стал быстрее» . Проверено 25 августа 2017 г.
  31. ^ «Контроль перегрузки BBR [LWN.net]» . lwn.net .
  32. ^ «Обновление ББР» . Рабочая группа по интернет-инжинирингу.
  33. ^ «TCP и BBR» (PDF) . Проверено 27 мая 2018 г.
  34. ^ «Экспериментальная оценка контроля перегрузки BBR» (PDF) . Проверено 27 мая 2018 г.
  35. ^ «Оценка производительности TCP BBRv2» . Проверено 12 января 2021 г.
  36. ^ Jump up to: а б команда Google TCP BBR; Команда Google QUIC BBR (26 июля 2023 г.). BBRv3: исправления ошибок алгоритма и общедоступное развертывание в Интернете . IETF 117: Сан-Франциско.
  37. ^ «TCP с управляемой сотовой задержкой (C2TCP)» . wp.nyu.edu . Проверено 27 апреля 2019 г.
  38. ^ Альршах, Массачусетс; Аль-Макри, Массачусетс; Отман, М. (июнь 2019 г.). «Elastic-TCP: гибкий алгоритм управления перегрузкой для адаптации к сетям с высоким BDP» . Системный журнал IEEE . 13 (2): 1336–1346. arXiv : 1904.13105 . Бибкод : 2019ISysJ..13.1336A . дои : 10.1109/JSYST.2019.2896195 .
  39. ^ Аббаслу, Сохейл (3 июня 2019 г.), GitHub – Soheil-ab/natcp , получено 5 августа 2019 г.
  40. ^ Юань, Цао; Тан, Ляньшэн; Эндрю, Лахлан Л.Х.; Чжан, Вэй; Цукерман, Моше (6 июня 2008 г.). «Обобщенная схема FAST TCP» . Компьютерные коммуникации . 31 (14): 3242–3249. дои : 10.1016/j.comcom.2008.05.028 . hdl : 1959.3/44051 . S2CID   17988768 .
  41. ^ Jump up to: а б «Группа Райс Нетворкс» .
  42. ^ «TCP Veno: усовершенствование TCP для передачи по сетям беспроводного доступа» (PDF) . Журнал IEEE по избранным областям коммуникации.
  43. ^ «XCP@ISI» .
  44. ^ «Высокоскоростной ТПК» (PDF) . csc.lsu.edu .
  45. ^ «Архивная копия» . Архивировано из оригинала 3 апреля 2011 года . Проверено 5 марта 2011 г. {{cite web}}: CS1 maint: архивная копия в заголовке ( ссылка )
  46. ^ Бенабуд, Х.; Беркиа, А.; Микоу, Н. (2002). «Аналитическое исследование алгоритма CANIT в протоколе TCP». Обзор оценки производительности ACM SIGMETRICS . 30 (3): 20. дои : 10.1145/605521.605530 . S2CID   6637174 .
  47. ^ Рухани, Моджтаба (2010). «Управление перегрузкой нелинейных нейронных сетей на основе генетического алгоритма для сетей TCP/IP». 2010 2-я Международная конференция по вычислительному интеллекту, системам связи и сетям . стр. 1–6. дои : 10.1109/CICSyN.2010.21 . ISBN  978-1-4244-7837-8 . S2CID   15126416 .
  48. ^ Канагаратинам, Мадхан Радж; Сингх, Сухдип; Сандип, Ирланки; Рой, Абхишек; Саксена, Наврати (январь 2018 г.). «D-TCP: алгоритм динамического управления перегрузкой TCP для мобильных сетей следующего поколения» . 2018 15-я Ежегодная конференция IEEE по потребительским коммуникациям и сетям (CCNC) . стр. 1–6. дои : 10.1109/CCNC.2018.8319185 . ISBN  978-1-5386-4790-5 . S2CID   3991163 .
  49. ^ Канагаратинам, Мадхан Радж; Сингх, Сухдип; Сандип, Ирланки; Ким, Хансок; Махешвари, Мукеш Кумар; Хван, Джэхён; Рой, Абхишек; Саксена, Наврати (2020). «NexGen D-TCP: алгоритм динамического управления перегрузкой TCP следующего поколения» . Доступ IEEE . 8 : 164482–164496. Бибкод : 2020IEEA...8p4482K . дои : 10.1109/ACCESS.2020.3022284 . ISSN   2169-3536 . S2CID   221846931 .
  50. ^ Арун, Венкат; Балакришнан, Хари (2018). «Copa: Практическое управление перегрузкой Интернета на основе задержек» . 15-й симпозиум USENIX по проектированию и внедрению сетевых систем (NSDI 18) : 329–342. ISBN  978-1-939133-01-4 .
  51. ^ «tcp: сделать CUBIC механизмом управления перегрузкой по умолчанию» . 13 сентября 2022 г.
  52. ^ «Краткое описание проекта пяти новых алгоритмов управления перегрузкой TCP» . 8 марта 2011 г.
  53. ^ «iTCP — интерактивный транспортный протокол — лаборатория Medianet, Кентский государственный университет» .
  54. ^ «Информационный документ: Zeta-TCP — интеллектуальное, адаптивное, асимметричное ускорение TCP» (PDF) . Проверено 6 декабря 2019 г.
  55. ^ Лефтерис Маматас; Тобиас Харкс; Василис Цауссидис (январь 2007 г.). «Подходы к контролю перегрузки в пакетных сетях» (PDF) . Журнал интернет-инженерии . 1 (1). Архивировано из оригинала (PDF) 21 февраля 2014 года.
  56. ^ «Высокоскоростной TCP» . ICIR.org .
  57. ^ «Домашняя страница AIMD-FC» . neu.edu . Архивировано из оригинала 13 января 2009 года . Проверено 13 марта 2016 г.
  58. ^ «Добро пожаловать в Лабораторию сетевых исследований» . cs.ucla.edu .
  59. ^ «Управление перегрузкой на основе уравнений для одноадресных приложений» . ICIR.org .
  60. ^ Катаби, Дина; Хэндли, Марк; Рорс, Чарли (2002). «Контроль перегрузки в сетях продуктов с высокой задержкой полосы пропускания». Материалы конференции 2002 года по приложениям, технологиям, архитектурам и протоколам компьютерной связи . Нью-Йорк, Нью-Йорк, США: ACM Press. п. 89. дои : 10.1145/633025.633035 . ISBN  1-58113-570-Х .
  61. ^ «MaxNet — Max-Min Fair, стабильное управление перегрузкой с явной сигнализацией» . netlab.caltech.edu .
  62. ^ «Контроль перегрузки TCP: системный подход. Петерсон, Бракмо и Дэви» . Проверено 17 мая 2024 г.

Источники

[ редактировать ]
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=TCP_congestion_control&oldid=1237385844#TCP_New_Reno"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: d372e3e0d51bf3c3c789a6d4208ee699__1722253440
URL1:https://arc.ask3.ru/arc/aa/d3/99/d372e3e0d51bf3c3c789a6d4208ee699.html
Заголовок, (Title) документа по адресу, URL1:
TCP congestion control - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)