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 . [а]

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

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

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:

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

TCP Нью-Рино

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

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

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

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

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

Проблема возникает в 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) — это реализация 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+ адаптивно устанавливает порог медленного запуска и окно перегрузки, которое учитывает оценку пропускной способности, доступной на момент возникновения перегрузки. По сравнению с Рино и Нью-Рино, Westwood+ значительно увеличивает пропускную способность беспроводных каналов и повышает справедливость в проводных сетях. [ нужна цитата ]

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

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

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

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

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

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

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

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

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

Черный ящик

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

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

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

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

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

Примечания

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

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

  1. ^ Джейкобсон и Карелс 1988.
  2. ^ аб У. Стивенс (январь 1997 г.). Алгоритмы медленного запуска TCP, предотвращения перегрузки, быстрой повторной передачи и быстрого восстановления. дои : 10.17487/RFC2001 . РФК 2001.
  3. ^ аб М. Оллман; С. Флойд; К. Партридж (октябрь 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. IETF . сек. 3.1. дои : 10.17487/RFC5681 . РФК 5681 . Проверено 4 марта 2021 г.
  7. ^ Блэнтон, Итан; Паксон, Верн; Оллман, Марк (сентябрь 2009 г.). «Контроль перегрузки TCP». IETF .
  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. ^ abcdef Аббаслу, С.; Сюй, Ю.; Чао, HJ (2019). «C2TCP: гибкий сотовый TCP, отвечающий строгим требованиям к задержке». Журнал IEEE по избранным областям коммуникаций . 37 (4): 918–932. arXiv : 1810.13241 . doi : 10.1109/JSAC.2019.2898758. ISSN  0733-8716. S2CID  53107038.
  12. ^ abcd Аббаслу, С.; Ли, Т.; Сюй, Ю.; Чао, 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. ^ abcd Аббаслу и др. 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. ^ ab «BBR: Управление перегрузкой на основе перегрузки» . Проверено 25 августа 2017 г.
  29. ^ Ченг, Ючунг; Кардвелл, Нил; Йегане, Сохейл Хассас; Джейкобсон, Ван (3 июля 2017 г.). «Оценка скорости доставки». IETF . Проверено 25 августа 2017 г.
  30. ^ «Контроль перегрузки TCP BBR теперь доступен в GCP - ваш Интернет стал быстрее» . Проверено 25 августа 2017 г.
  31. ^ «Контроль перегрузки BBR [LWN.net]» . lwn.net .
  32. ^ "Обновление BBR" . IETF .
  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. ^ «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. ^ ab "Группа Rice Networks".
  42. ^ «TCP Veno: усовершенствование TCP для передачи по сетям беспроводного доступа» (PDF) . Журнал IEEE по избранным областям коммуникации.
  43. ^ "XCP @ ISI" .
  44. ^ «Высокоскоростной TPC» (PDF) . www.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. дои : 10.1145/605521.605530. S2CID  6637174.
  47. ^ Рухани, Моджтаба (2010). «Управление перегрузкой нелинейных нейронных сетей на основе генетического алгоритма для сетей TCP/IP». 2010 2-я Международная конференция по вычислительному интеллекту, системам связи и сетям . стр. 1–6. doi : 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» . www.icir.org .
  57. ^ "Домашняя страница AIMD-FC" . neu.edu . Архивировано из оригинала 13 января 2009 года . Проверено 13 марта 2016 г.
  58. ^ «Добро пожаловать в лабораторию сетевых исследований» . www.cs.ucla.edu .
  59. ^ «Управление перегрузкой на основе уравнений для одноадресных приложений» . www.icir.org .
  60. ^ Катаби, Дина; Хэндли, Марк; Рорс, Чарли (2002). «Контроль перегрузки в сетях продуктов с высокой задержкой полосы пропускания». Материалы конференции 2002 года по приложениям, технологиям, архитектурам и протоколам компьютерной связи . Нью-Йорк, Нью-Йорк, США: ACM Press. п. 89. дои : 10.1145/633025.633035 . ISBN 1-58113-570-Х.
  61. ^ «MaxNet — Max-Min Fair, стабильный контроль перегрузки с явной сигнализацией» . netlab.caltech.edu .

Источники

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