stringtranslate.com

Контроль перегрузки 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) 1, 2, 4 или 10 MSS. [8] [3] : 1  Значение размера окна перегрузки может быть увеличено на 1 MSS с каждым полученным подтверждением (ACK), что фактически удваивает размер окна за каждый RTT . [a]

Скорость передачи данных будет увеличиваться алгоритмом медленного старта до тех пор, пока не будет обнаружена потеря пакета, объявленное окно получателя (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); справедливость (F); преимущество коротких потоков (S); каналы с переменной скоростью (V); скорость сходимости (C)
  4. критерий справедливости, который он использует

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

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 и Reno, если время ожидания ACK истекло (время ожидания RTO), используется медленный старт, и оба алгоритма сокращают окно перегрузки до 1 MSS. [ необходима цитата ]

TCP Нью-Рино

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

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

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

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

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

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

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

TCP Вегас

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

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

TCP-Хибла

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

TCP-код BIC

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

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 Вествуд+

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

Соединение TCP

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

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

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

TCP-BBR

Bottleneck Bandwidth and Round-trip propagation time (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

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

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

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

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

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

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

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

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

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

Черный ящик

Серый ящик

Зеленый ящик

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

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

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

Примечания

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

Ссылки

  1. ^ Якобсон и Карелс 1988.
  2. ^ ab W. Stevens (январь 1997 г.). Медленный старт TCP, предотвращение перегрузки, быстрая повторная передача и алгоритмы быстрого восстановления. doi : 10.17487/RFC2001 . RFC 2001.
  3. ^ ab M. Allman; S. Floyd; C. Partridge (октябрь 2002 г.). Увеличение начального окна TCP. doi : 10.17487/RFC3390 . RFC 3390.
  4. ^ «Избежание перегрузки TCP с помощью диаграммы последовательности» (PDF) . eventhelix.com .
  5. ^ Чиу, Да-Мин; Радж Джейн (1989). «Анализ алгоритмов увеличения и уменьшения для предотвращения перегрузки в компьютерных сетях». Компьютерные сети и системы ISDN . 17 : 1–14. CiteSeerX 10.1.1.136.8108 . doi :10.1016/0169-7552(89)90019-6. 
  6. ^ Allman, M.; Paxson, V. (сентябрь 2009 г.). Управление перегрузкой TCP. Internet Engineering Task Force . sec. 3.1. doi : 10.17487/RFC5681 . RFC 5681. Получено 4 марта 2021 г.
  7. ^ Блэнтон, Итан; Пэксон, Верн; Оллман, Марк (сентябрь 2009 г.). «Управление перегрузкой TCP». Internet Engineering Task Force. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  8. ^ Корбет, Джонатан. "Увеличение начального окна перегрузки TCP". LWN . Получено 10 октября 2012 г.
  9. ^ Ник О'Нил. «Что замедляет работу вашего сайта? Возможно, это кнопка «Нравится»». AllFacebook , 10 ноября 2010 г. Получено 12 сентября 2012 г.
  10. ^ Fall, Kevin; Sally Floyd (июль 1996 г.). "Сравнение Tahoe, Reno и SACK TCP на основе моделирования" (PDF) . Computer Communications Review . 26 (3): 5–21. CiteSeerX 10.1.1.586.2403 . doi :10.1145/235160.235162. S2CID  7459148. 
  11. ^ abcdef Аббаслоо, С.; Сюй, И.; Чао, Х. Дж. (2019). «C2TCP: гибкий сотовый TCP для удовлетворения строгих требований к задержке». Журнал IEEE по избранным областям в коммуникациях . 37 (4): 918–932. arXiv : 1810.13241 . doi : 10.1109/JSAC.2019.2898758. ISSN  0733-8716. S2CID  53107038.
  12. ^ abcd Abbasloo, S.; Li, T.; Xu, Y.; Chao, HJ (май 2018 г.). «Cellular Controlled Delay TCP (C2TCP)». Конференция IFIP по сетевому взаимодействию 2018 г. (IFIP Networking) и семинары . стр. 118–126. arXiv : 1807.02689 . Bibcode :2018arXiv180702689A. doi :10.23919/IFIPNetworking.2018.8696844. ISBN 978-3-903176-08-9. S2CID  49650788.
  13. ^ abcd Аббаслоо и др. 2019.
  14. ^ Кардвелл, Нил; Ченг, Юйчунг; Ганн, К. Стивен; Йеганех, Сохейл Хассас; Якобсон, Ван (2016). «BBR: Управление перегрузкой на основе перегрузки». Очередь . 14 (5): 20–53. doi : 10.1145/3012426.3022184 .
  15. ^ Куроуз и Росс 2008, стр. 284.
  16. ^ Куроуз и Росс 2012, стр. 277.
  17. ^ Васанти Н., В.; Сингх М., Аджит; Кумар, Ромен; Хемалата, М. (2011). «Оценка протоколов и алгоритмов для повышения производительности TCP в беспроводной/проводной сети». В Das, Vinu V; Thankachan, Nessy (ред.). Вычислительный интеллект и информационные технологии . Коммуникации в области компьютерных и информационных наук. Том 250. Springer. С. 693–697. doi :10.1007/978-3-642-25734-6_120. ISBN 978-3-642-25733-9.
  18. ^ "Анализ производительности алгоритмов управления перегрузкой TCP" (PDF) . Получено 26 марта 2012 г.
  19. ^ "DD-WRT changelog" . Получено 2 января 2012 г. .
  20. ^ "Hybla home page". Архивировано из оригинала 11 октября 2007 года . Получено 4 марта 2007 года .
  21. ^ Caini, Carlo; Firrincieli, Rosario (2004). «TCP Hybla: расширение TCP для гетерогенных сетей». International Journal of Satellite Communications and Networking . 22 (5): 547–566. doi :10.1002/sat.799. ISSN  1542-0973. S2CID  2360535.
  22. ^ Caini, C.; Firrincieli, R.; Lacamera, D. (2009). «Сравнительная оценка производительности вариантов TCP в спутниковых средах». Международная конференция IEEE по коммуникациям 2009 г. , стр. 1–5. doi :10.1109/ICC.2009.5198834. S2CID  8352762.
  23. ^ V., Jacobson; RT, Braden. Расширения TCP для путей с большой задержкой. doi : 10.17487/RFC1072 . RFC 1072.
  24. ^ Alrshah, MA; Othman, M.; Ali, B.; Hanapi, ZM (сентябрь 2015 г.). «Agile-SD: алгоритм управления перегрузкой TCP на базе Linux для поддержки высокоскоростных сетей и сетей на короткие расстояния». Journal of Network and Computer Applications . 55 : 181–190. arXiv : 1601.05908 . doi : 10.1016/j.jnca.2015.05.011. S2CID  2645016.
  25. ^ Матис, М.; Дуккипати, Н.; Ченг, И. (2013). Пропорциональное снижение скорости для TCP. doi : 10.17487/RFC6937 . RFC 6937.
  26. ^ Корбет, Джонатан. "LPC: Making the net go faster" . Получено 6 июня 2014 г. .
  27. ^ "Linux 3.2 – Linux Kernel Newbies" . Получено 6 июня 2014 г. .
  28. ^ ab "BBR: Congestion-Based Congestion Control" . Получено 25 августа 2017 г. .
  29. ^ Ченг, Юйчунг; Кардвелл, Нил; Йеганех, Сохейл Хассас; Якобсон, Ван (3 июля 2017 г.). «Оценка скорости доставки». Internet Engineering Task Force . Получено 25 августа 2017 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  30. ^ "Управление перегрузкой TCP BBR приходит в GCP – ваш Интернет стал быстрее" . Получено 25 августа 2017 г.
  31. ^ "Управление перегрузкой BBR [LWN.net]". lwn.net .
  32. ^ "Обновление BBR". Internet Engineering Task Force.
  33. ^ "TCP и BBR" (PDF) . Получено 27 мая 2018 г.
  34. ^ "Экспериментальная оценка контроля перегрузки BBR" (PDF) . Получено 27 мая 2018 г.
  35. ^ "Оценка производительности TCP BBRv2" . Получено 12 января 2021 г.
  36. ^ ab Команда Google TCP BBR; Команда Google QUIC BBR (26 июля 2023 г.). BBRv3: Исправления ошибок алгоритма и развертывание публичного Интернета. IETF 117: Сан-Франциско.
  37. ^ "Cellular Controlled Delay TCP (C2TCP)". wp.nyu.edu . Получено 27 апреля 2019 г. .
  38. ^ Alrshah, MA; Al-Maqri, MA; Othman, M. (июнь 2019 г.). «Elastic-TCP: гибкий алгоритм управления перегрузкой для адаптации к сетям с высоким BDP». IEEE Systems Journal . 13 (2): 1336–1346. arXiv : 1904.13105 . Bibcode : 2019ISysJ..13.1336A. doi : 10.1109/JSYST.2019.2896195 .
  39. ↑ Аббаслу, Сохейл (3 июня 2019 г.), GitHub – Soheil-ab/natcp , получено 5 августа 2019 г.
  40. ^ Юань, Цао; Тан, Ляньшэн; Эндрю, Лаклан LH; Чжан, Вэй; Цукерман, Моше (6 июня 2008 г.). «Обобщенная схема FAST TCP». Computer Communications . 31 (14): 3242–3249. doi :10.1016/j.comcom.2008.05.028. hdl : 1959.3/44051 . S2CID  17988768.
  41. ^ ab "Rice Networks Group".
  42. ^ "TCP Veno: Улучшение TCP для передачи по сетям беспроводного доступа" (PDF) . Журнал IEEE по избранным областям в области связи.
  43. ^ "XCP @ ISI".
  44. ^ "Высокоскоростной TPC" (PDF) . csc.lsu.edu .
  45. ^ "Архивная копия". Архивировано из оригинала 3 апреля 2011 года . Получено 5 марта 2011 года .{{cite web}}: CS1 maint: archived copy as title (link)
  46. ^ Бенабуд, Х.; Беркиа, А.; Мику, Н. (2002). «Аналитическое исследование алгоритма CANIT в протоколе TCP». Обзор оценки производительности ACM SIGMETRICS . 30 (3): 20. doi :10.1145/605521.605530. S2CID  6637174.
  47. ^ Rouhani, Modjtaba (2010). "Нелинейное управление перегрузкой нейронной сети на основе генетического алгоритма для сетей TCP/IP". 2010 2-я Международная конференция по вычислительному интеллекту, системам связи и сетям . С. 1–6. doi :10.1109/CICSyN.2010.21. ISBN 978-1-4244-7837-8. S2CID  15126416.
  48. ^ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Roy, Abhishek; Saxena, Navrati (январь 2018 г.). "D-TCP: Динамический алгоритм управления перегрузкой TCP для мобильных сетей следующего поколения". 2018 15-я ежегодная конференция IEEE по коммуникациям и сетевым технологиям для потребителей (CCNC) . стр. 1–6. doi :10.1109/CCNC.2018.8319185. ISBN 978-1-5386-4790-5. S2CID  3991163.
  49. ^ Канагаратинам, Мадхан Радж; Сингх, Сукхдип; Сандип, Ирланди; Ким, Хансок; Махешвари, Мукеш Кумар; Хванг, Джэхён; Рой, Абхишек; Саксена, Наврати (2020). «NexGen D-TCP: Динамический алгоритм управления перегрузкой TCP следующего поколения». IEEE Access . 8 : 164482–164496. Bibcode : 2020IEEEA...8p4482K. doi : 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. ^ "Whitepaper: Zeta-TCP – интеллектуальное, адаптивное, асимметричное ускорение TCP" (PDF) . Получено 6 декабря 2019 г.
  55. ^ Лефтерис Маматас; Тобиас Харкс; Василис Цауссидис (январь 2007 г.). «Подходы к контролю перегрузки в пакетных сетях» (PDF) . Журнал Internet Engineering . 1 (1). Архивировано из оригинала (PDF) 21 февраля 2014 г.
  56. ^ "Высокоскоростной TCP". icir.org .
  57. ^ "AIMD-FC Homepage". neu.edu . Архивировано из оригинала 13 января 2009 . Получено 13 марта 2016 .
  58. ^ «Добро пожаловать в Лабораторию сетевых исследований». cs.ucla.edu .
  59. ^ «Управление перегрузкой на основе уравнений для приложений одноадресной передачи». icir.org .
  60. ^ Katabi, Dina; Handley, Mark; Rohrs, Charlie (2002). "Congestion control for high band-delay product networks". Труды конференции 2002 года по приложениям, технологиям, архитектурам и протоколам для компьютерных коммуникаций . Нью-Йорк, Нью-Йорк, США: ACM Press. стр. 89. doi : 10.1145/633025.633035 . ISBN 1-58113-570-X.
  61. ^ "MaxNet — Max-Min Fair, Stable Explicit Signalling Congestion Control". netlab.caltech.edu .
  62. ^ "TCP Congestion Control: A Systems Approach. Peterson, Brakmo and Davie" . Получено 17 мая 2024 г.

Источники

Внешние ссылки