АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Управление перегрузкой TCP

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Управление перегрузкой TCP (англ. TCP congestion control) — совокупность методов и алгоритмов, реализованных в протоколе управления передачей данных (TCP, англ. Transmission Control Protocol), предназначенных для предотвращения, обнаружения и устранения перегрузки в сетях передачи данных. Главная задача управления перегрузкой TCP — обеспечение устойчивой и эффективной работы сети интернет путём регулирования объёма передаваемых данных и поддержания балансировки между скоростью передачи и доступной пропускной способностью канала[1]. В соответствии с принципом сквозного управления (англ. end-to-end principle), регулирование перегрузки в основном осуществляется конечными хостами, а не самой сетью. Существует множество вариантов и реализаций алгоритмов управления перегрузкой TCP, реализуемых в стеке протоколов различных операционных систем, подключаемых к Интернету.

Для предотвращения перегрузки TCP использует многоуровневую стратегию контроля загруженности. Для каждого соединения TCP поддерживает окно перегрузки (CWND, англ. Congestion Window), ограничивающее максимальное количество неподтверждённых пакетов в рамках одного соединения. Данная модель работает по схожему принципу с механизмом скользящего окна для управления потоком TCP.

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

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

Этот алгоритм рекомендуется для фазы «предотвращения перегрузки» в стандарте[2].

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

В TCP окно перегрузки (CWND, англ. congestion window) определяет, сколько байт данных может быть отправлено в каждый момент времени. Данный параметр поддерживается на стороне отправителя и используется для предотвращения перегрузки канала данных между отправителем и получателем. Окно перегрузки не стоит путать со скользящим окном, которое обеспечивает контроль потока относительно возможностей приёмника. Размер окна перегрузки определяется на основании оценки текущего уровня загруженности канала.

При установлении соединения CWND изначально устанавливается как небольшое кратное максимального размера сегмента (MSS, англ. max segment size). Дальнейшее изменение CWND происходит согласно принципу AIMD: если все сегменты доставляются без потерь и подтверждения приходят вовремя, к размеру окна прибавляется константа. Точный алгоритм может разниться.

Системный администратор может настроить максимальный размер окна или величину постоянной при аддитивном увеличении в рамках оптимизации TCP.

Передача данных также ограничивается размером окна приёма (receive window), который рекламируется приёмником. Таким образом, число передаваемых данных ограничивается минимумом между CWND и окном приёма.

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

Медленный старт (англ. slow start), описанный в RFC 5681[3], — часть стратегии управления перегрузкой в TCP, направленная на предотвращение превышения пропускной способности сети.

Алгоритм медленного старта начинается с малого значения CWND — 1, 2, 4 или 10 MSS[4]. С каждым подтверждением (ACK) размер окна увеличивается на 1 MSS, что фактически удваивает CWND за каждый круговой обход (RTT).

Передача ускоряется за счёт медленного старта, пока не случится потеря пакета, не достигнуто ограничение рекламируемого окна приёма (rwnd), либо не будет достигнут порог медленного старта (ssthresh), определяющий переключение на фазу предотвращения перегрузки.

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

При обнаружении потери TCP предполагает перегрузку и сокращает нагрузку на сеть. Конкретные меры зависят от используемого алгоритма.

Если потеря обнаружена по таймауту, ssthresh устанавливается не более половины объёма неподтверждённых данных или 2*MSS — выбирается большее значение.

TCP Tahoe
При потере — повторная передача, половина текущего CWND сохраняется как ssthresh, и медленный старт начинается заново с начального CWND.
TCP Reno
Выполняется быстрая повторная передача, половина CWND сохраняется как ssthresh и в качестве нового CWND, то есть медленный старт пропускается, сразу переходя к фазе предотвращения перегрузки (эта схема называется быстрое восстановление).

Медленный старт исходит из предположения, что все неподтверждённые сегменты — из-за перегруженности сети, что не всегда так (например, при неустойчивой связи на канальном уровне, как в беспроводных сетях).

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

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

Быстрая повторная передача (англ. fast retransmit) — усовершенствование TCP, позволяющее сократить задержку, связанную с ожиданием таймаута при потере сегмента. В обычном TCP потери распознаются по истечении таймера, но при получении трёх (и более) дубликатов подтверждений считается, что определённый сегмент утерян, и осуществляется немедленная повторная отправка.

Алгоритмы

Названия Reno и Tahoe — имена выпусков ОС BSD UNIX, в которых впервые были реализованы соответствующие алгоритмы управления перегрузкой (CCA, англ. congestion control algorithm). Классификация алгоритмов может строиться по:

  1. Типу и объёму обратной связи с сетью
  2. Возможности внедрения в существующем интернете
  3. Ориентированию на определённые характеристики (широкополосность, потери, справедливость, короткие потоки, переменность скоростей, скорость сходимости)
  4. Принципу справедливости

Некоторые известные алгоритмы:

Вариант Обратная связь Необходимые изменения Преимущества Справедливость
(New) Reno Потери Задержка
Vegas Задержка Отправитель Меньше потерь Пропорциональная
High Speed Потери Отправитель Высокая пропускная способность
BIC Потери Отправитель Высокая пропускная способность
CUBIC Потери Отправитель Высокая пропускная способность
C2TCP Потери/задержка Отправитель Минимальная задержка, высокая пропускная способность
NATCP[5] Мультибитовый сигнал Отправитель Оптимальная работа
Elastic-TCP Потери/задержка Отправитель Высокая пропускная способность и малая/большая задержка
Agile-TCP Потери Отправитель Высокая пропускная способность и малая задержка
H-TCP Потери Отправитель Высокая пропускная способность
FAST Задержка Отправитель Высокая пропускная способность Пропорциональная
Compound TCP Потери/задержка Отправитель Высокая пропускная способность Пропорциональная
Westwood Потери/задержка Отправитель Потеряные каналы
Jersey Потери/задержка Отправитель Потеряные каналы
BBR[6] Задержка Отправитель BLVC, Bufferbloat
CLAMP Мультибитовый сигнал Приёмник, маршрутизатор Перепад скоростей Макс-мин
TFRC Потери Отправитель, приёмник Без повторных передач Минимальная задержка
XCP Мультибитовый сигнал Отправитель, приёмник, маршрутизатор BLFC Макс-мин
VCP 2-битовый сигнал Отправитель, приёмник, маршрутизатор BLF Пропорциональная
MaxNet Мультибитовый сигнал Отправитель, приёмник, маршрутизатор BLFSC Макс-мин
JetMax Мультибитовый сигнал Отправитель, приёмник, маршрутизатор Высокая пропускная способность Макс-мин
RED Потери Маршрутизатор Снижение задержки
Prague[7] Однобитовый сигнал Отправитель, приёмник, маршрутизатор Малая задержка, малые потери, масштабируемая пропускная способность (L4S[8])
ECN Однобитовый сигнал Отправитель, приёмник, маршрутизатор Снижение потерь

TCP Tahoe и Reno

Алгоритмы TCP Tahoe и Reno получили названия по версиям ОС 4.3BSD, где они впервые появились (Tahoe для поддержки миникомпьютера CCI Power 6/32 «Tahoe», Reno — для очередного релиза). Алгоритм Tahoe стал широко распространяться с выпуском 4.3BSD Networking Release 1, а улучшения Reno были опубликованы в Networking Release 2 и 4.4BSD-Lite.

Оба алгоритма рассматривают как потерю пакетных данных истечение таймаута (RTO) и дублирующиеся ACK, но различаются реакцией на дубликаты ACK:

  • Tahoe: при получении трёх дубликатов ACK — выполняется быстрая повторная передача, порог медленного старта устанавливается в половину текущего CWND, CWND уменьшается до 1 MSS, режим медленного старта активируется заново[9].
  • Reno: при трёх дубликатах ACK выполняется быстрая повторная передача и сразу переход к фазе быстрого восстановления — CWND делится на два, ssthresh приравнивается к новому CWND, медленный старт опускается[10].

При истечении таймаута ACK оба алгоритма переходят в режим медленного старта с установкой CWND = 1 MSS.

TCP New Reno

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

Если ACK подтверждает только часть данных, означает возможную повторную потерю — тогда повторной передаче подвергается первый неподтверждённый сегмент. После таймаута New Reno записывает максимальный переданный порядковый номер и выходит из быстрого восстановления.

При нарушении порядка доставки более чем на 3 сегмента New Reno ошибочно начинает быструю передачу и добавляет лишние повторы.

New Reno показывает сопоставимую с SACK производительность при малых вероятностях ошибок и заметно превосходит Reno в условиях большого числа потерь[11].

TCP Vegas

Алгоритм TCP Vegas, предложенный Ларри Петерсоном и Лоренсом Брэкмо из Университета Аризоны, использует измерения задержки и таймауты отдельно для каждого пакета, а не только для последнего. Кроме того, Vegas применяет аддитивный рост окна перегрузки. В сравнительных тестах Vegas отличается самой равномерной работой окна перегрузки[12].

Vegas не получил широкого распространения, но использовался по умолчанию в альтернативной прошивке DD-WRT v24 SP2[13].

TCP Hybla

TCP Hybla[14][15] устраняет недостатки TCP на соединениях с высокой задержкой, например спутниковых.

TCP BIC

Подробнее
BIC TCP

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

TCP CUBIC

Подробнее
CUBIC TCP

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

Agile-SD TCP

Agile-SD — CCA для Linux, оптимизированный для сетей с малым BDP (локальные и волоконно-оптические сети), особенно при малом размере буфера[16].

TCP Westwood+

Westwood+ — модификация TCP Reno для большего пропускания в беспроводных и проводных сетях, основана на оценке полосы пропускания через анализ частоты приходящих ACK.

Compound TCP

Подробнее
Compound TCP

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

TCP Proportional Rate Reduction

TCP Proportional Rate Reduction (PRR)[17] — алгоритм для точного восстановления окна после перегрузки. В тестах Google PRR снижает среднюю задержку на 3-10 % и количество таймаутов на 5 %. Входит в ядро Linux с версии 3.2[18].

TCP BBR

Bottleneck Bandwidth and Round-trip propagation time (BBR) — алгоритм контроля перегрузки, разработанный в Google (2016). В отличие от большинства CCA, полагающихся на потери, BBR строит модель сети, оценивая максимальную пропускную способность и минимальную задержку[19]. Внедрение в YouTube увеличило пропускную способность на 4 % в среднем. BBR применяется в Linux TCP c версии 4.9, а также реализован для QUIC[20].

Отмечаются проблемы с несправедливым распределением полосы между BBR и другими потоками, такими как CUBIC[21].

BBRv2 и BBRv3 корректируют эти недостатки, внося данные о потерях пакетов и ECN (explicit congestion notification), а также реализуют дополнительную оптимизацию для дата-центров[22].

C2TCP

Cellular Controlled Delay TCP (C2TCP) — плагин, работающий поверх loss-based TCP (Reno, NewReno, CUBIC, BIC и др.), позволяющий серверам удовлетворять требованиям к крайне малой задержке для приложений вроде VR, видеозвонков, многопользовательских игр в высокодинамичных сотовых сетях (LTE, 5G).

В испытаниях NYU C2TCP демонстрирует в несколько раз меньшую задержку, чем BBR, CUBIC и Westwood.

Elastic-TCP

Elastic-TCP — Linux-алгоритм для облачной среды, повышающий использование полосы на сетях с высоким BDP. Он использует взвешенную функцию, учёт потерь и задержки и не требует ручной настройки параметров[23].

NATCP

NATCP (Network-Assisted TCP) — проект S. Abbasloo и др., нацеленный на максимальное использование возможностей сетей с мультидоступом (MEC). NATCP строит работу TCP с учётом заранее известных характеристик сети, используя внешнюю обратную связь о пропускной способности и минимальной задержке[24].

Прочие алгоритмы управления перегрузкой TCP

  • FAST TCP
  • Генерализованный FAST TCP
  • H-TCP
  • Data Center TCP
  • High Speed TCP
  • HSTCP-LP[25]
  • TCP-Illinois
  • TCP-LP
  • TCP SACK
  • Scalable TCP
  • TCP Veno[26]
  • Westwood
  • XCP[27]
  • YeAH-TCP[28]
  • TCP-FIT[29]
  • CANIT (Congestion Avoidance with Normalized Interval of Time)[30]
  • Неклассические регуляторы на базе нейросетей и генетических алгоритмов[31]
  • D-TCP[32]
  • NexGen D-TCP[33]
  • Copa[34]

До середины 2010-х годов наиболее распространён был алгоритм New Reno; поддержка SACK реализована почти во всех актуальных ОС и TCP-стеках. Большинство других — альтернативные предложения, находящиеся на стадии апробации. Ядро Linux использует по умолчанию: New Reno (до 2.6.8), BIC (2.6.8-2.6.18), CUBIC (с 2.6.19). FreeBSD переключилась на CUBIC с версии 14.X (ранее применялся New Reno)[35]. Возможен выбор других реализаций[36].

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

Пример «активной» схемы — TCP Interactive (iTCP), позволяющий приложениям реагировать на TCP-события и динамически менять поведение передачи[37]. Zeta-TCP оценивает перегрузку по потерям и задержке, применяет гибкое масштабирование окна и дополнительные методы для сокращения таймаутов и ускорения загрузки[38].

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

Контроллеры TCP можно классифицировать по степени осведомлённости о состоянии сети:[39]

  • Black box — алгоритмы, работающие только на бинарной обратной связи и не учитывающие параметры сети.
  • Grey box — используют, кроме признаков потерь, ещё и измерения RTT, контенцию потоков и т. д.
  • Green box — алгоритмы с прямым вычислением «честной доли» пропускной способности для каждого потока.

Black box

  • Highspeed-TCP[40]
  • BIC TCP
  • CUBIC TCP
  • AIMD-FC (улучшение AIMD с быстрой сходимостью)[41]
  • Binomial Mechanisms
  • SIMD Protocol
  • GAIMD

Grey box

  • TCP Vegas — использует оценку задержки в буфере, линейно увеличивает/уменьшает CWND.
  • FAST TCP — достигает т. ж. равновесия, но применяет пропорциональный контроль.
  • TCP BBR — оценивает задержку, использует экспоненциальное наращивание, периодически замедляется ради справедливости.
  • TCP Westwood
  • C2TCP
  • TFRC[42]
  • TCP-Real
  • TCP-Jersey

Green box

  • Bimodal Mechanism — механизм двукратного управления.
  • Сигнальные методы на маршрутизаторах
  • Network-Assisted Congestion Control
    • NATCP[5]
    • VCP с двубитовой ECN и собственным протоколом на стороне узла

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

  • Explicit Control Protocol (XCP) — пакеты содержат заголовок с полем обратной связи.
  • MaxNet — использует информацию о максимальной загруженности одного из маршрутизаторов[43].
  • JetMax

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

  • BIC применялся по умолчанию в ядрах с 2.6.8 по 2.6.18 (2004—2006)
  • CUBIC — с версии 2.6.19 (с ноября 2006)[44]
  • PRR используется для восстановления после потерь с версии 3.2 (2012)
  • BBRv1 доступен в Linux начиная с версии 4.9 (2016)[45]

Примечания

  1. ↑ M. Allman. Увеличение начального окна TCP (англ.). IETF (октябрь 2002). Дата обращения: 25 июня 2024. Архивировано 18 июля 2025 года.
  2. ↑ M. Allman. TCP Congestion Control (англ.). IETF (сентябрь 2009). doi:10.17487/RFC5681. Дата обращения: 25 июня 2024. Архивировано 17 октября 2025 года.
  3. ↑ Blanton, Ethan; Paxson, Vern; Allman, Mark (Сентябрь 2009). “TCP Congestion Control” [англ.]. IETF.
  4. ↑ Corbet, Jonathan Увеличение начального окна перегрузки TCP (англ.). LWN (9 февраля 2011). Дата обращения: 25 июня 2024. Архивировано 20 февраля 2011 года.
  5. ↑ 1 2 Abbasloo, Xu, Chao, Shi, 2019.
  6. ↑ Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Jacobson, Van (2016). “BBR: Конгестионное управление на основе перегрузки”. ACM Queue [англ.]. 14 (5): 20—53. DOI:10.1145/3012426.3022184.
  7. ↑ Schepper, Koen De; Tilmans, Olivier; Briscoe, Bob; Goel, Vidhi Prague Congestion Control (англ.). datatracker.ietf.org (24 июля 2024). Архивировано 3 августа 2025 года.
  8. ↑ L4S – низкая задержка, низкие потери и масштабируемая пропускная способность (англ.). www.nokia.com. Архивировано 1 декабря 2025 года.
  9. ↑ Kurose, James. Computer Networking: A Top-Down Approach : [англ.] / James Kurose, Keith Ross. — 4. — Addison Wesley, 2008. — P. 284. — ISBN 978-0-13-607967-5.
  10. ↑ Kurose, James. Computer Networking: A Top-Down Approach : [англ.] / James Kurose, Keith Ross. — 6. — Pearson, 2012. — P. 277. — ISBN 978-0-13-285620-1.
  11. ↑ VasanthiN., V. Evaluation of Protocols and Algorithms for Improving the Performance of TCP over Wireless/Wired Network // Computational Intelligence and Information Technology : [англ.] / V. VasanthiN., Ajith SinghM., Romen Kumar … [et al.]. — Springer, 2011. — Vol. 250. — P. 693–697. — ISBN 978-3-642-25733-9. — doi:10.1007/978-3-642-25734-6_120.
  12. ↑ Performance Analysis of TCP Congestion Control Algorithms (англ.). Дата обращения: 25 июня 2024. Архивировано 10 марта 2014 года.
  13. ↑ DD-WRT changelog (англ.). Дата обращения: 25 июня 2024. Архивировано 10 января 2008 года.
  14. ↑ Hybla home page (англ.). Дата обращения: 25 июня 2024. Архивировано 11 октября 2007 года.
  15. ↑ Caini, Carlo; Firrincieli, Rosario (2004). “TCP Hybla: a TCP enhancement for heterogeneous networks”. International Journal of Satellite Communications and Networking [англ.]. 22 (5): 547—566. DOI:10.1002/sat.799. ISSN 1542-0973.
  16. ↑ Alrshah, M.A.; Othman, M.; Ali, B.; Hanapi, Z.M. (Сентябрь 2015). “Agile-SD: A Linux-based TCP congestion control algorithm for supporting high-speed and short-distance networks”. Journal of Network and Computer Applications [англ.]. 55: 181—190. arXiv:1601.05908. DOI:10.1016/j.jnca.2015.05.011. S2CID 2645016.
  17. ↑ Пропорциональное уменьшение скорости для TCP (англ.). IETF (2013). doi:10.17487/RFC6937. Дата обращения: 25 июня 2024. Архивировано 13 октября 2025 года.
  18. ↑ Linux 3.2 — Linux Kernel Newbies (англ.). Дата обращения: 25 июня 2024. Архивировано 22 октября 2025 года.
  19. ↑ BBR: Конгестионное управление на основе перегрузки (англ.). Дата обращения: 25 июня 2024.
  20. ↑ BBR update (англ.). IETF. Архивировано 10 февраля 2025 года.
  21. ↑ TCP and BBR (англ.). Дата обращения: 25 июня 2024. Архивировано 27 августа 2025 года.
  22. ↑ BBRv3: Algorithm Bug Fixes and Public Internet Deployment (англ.) (26 июля 2023). Архивировано 14 марта 2025 года.
  23. ↑ Alrshah, M.A.; Al-Maqri, M.A.; Othman, M. (Июнь 2019). “Elastic-TCP: Flexible Congestion Control Algorithm to Adapt for High-BDP Networks”. IEEE Systems Journal [англ.]. 13 (2): 1336—1346. arXiv:1904.13105. DOI:10.1109/JSYST.2019.2896195.
  24. ↑ Abbasloo, Soheil GitHub – Soheil-ab/natcp (англ.) (3 июня 2019). Дата обращения: 25 июня 2024. Архивировано 15 января 2025 года.
  25. ↑ Rice Networks Group (англ.). Архивировано 24 февраля 2004 года.
  26. ↑ TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks (англ.). IEEE Journal on Selected Areas in Communication. Архивировано 31 января 2016 года.
  27. ↑ XCP @ ISI (англ.). Архивировано 24 февраля 2004 года.
  28. ↑ High speed TPC (англ.). csc.lsu.edu. Архивировано 28 апреля 2025 года.
  29. ↑ TCP-Fit (англ.). Дата обращения: 25 июня 2024. Архивировано 3 апреля 2011 года.
  30. ↑ Benaboud, H.; Berqia, A.; Mikou, N. (2002). “An analytical study of CANIT algorithm in TCP protocol”. ACM SIGMETRICS Performance Evaluation Review [англ.]. 30 (3): 20. DOI:10.1145/605521.605530. S2CID 6637174.
  31. ↑ Rouhani, Modjtaba. Nonlinear Neural Network Congestion Control Based on Genetic Algorithm for TCP/IP Networks // 2010 2nd International Conference on Computational Intelligence, Communication Systems and Networks : [англ.]. — 2010. — P. 1–6. — ISBN 978-1-4244-7837-8. — doi:10.1109/CICSyN.2010.21.
  32. ↑ Kanagarathinam, Madhan Raj. D-TCP: Dynamic TCP congestion control algorithm for next generation mobile networks // 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC) : [англ.] / Madhan Raj Kanagarathinam, Sukhdeep Singh, Irlanki Sandeep … [et al.]. — Январь 2018. — P. 1–6. — ISBN 978-1-5386-4790-5. — doi:10.1109/CCNC.2018.8319185.
  33. ↑ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Kim, Hanseok; Maheshwari, Mukesh Kumar; Hwang, Jaehyun; Roy, Abhishek; Saxena, Navrati (2020). “NexGen D-TCP: Next Generation Dynamic TCP Congestion Control Algorithm”. IEEE Access [англ.]. 8: 164482—164496. Bibcode:2020IEEEA...8p4482K. DOI:10.1109/ACCESS.2020.3022284. ISSN 2169-3536. S2CID 221846931.
  34. ↑ Arun, Venkat; Balakrishnan, Hari (2018). “Copa: Practical Delay-Based Congestion Control for the Internet”. 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18) [англ.]: 329—342. ISBN 978-1-939133-01-4.
  35. ↑ tcp: make CUBIC the default congestion control mechanism (англ.) (13 сентября 2022). Архивировано 30 апреля 2025 года.
  36. ↑ Summary of Five New TCP Congestion Control Algorithms Project (англ.) (8 марта 2011).
  37. ↑ iTCP — Interactive Transport Protocol — Medianet Lab, Kent State University (англ.). Архивировано 13 апреля 2004 года.
  38. ↑ Whitepaper: Zeta-TCP – Intelligent, Adaptive, Asymmetric TCP Acceleration (англ.). Дата обращения: 25 июня 2024. Архивировано 20 апреля 2019 года.
  39. ↑ Lefteris Mamatas; Tobias Harks; Vassilis Tsaoussidis (Январь 2007). “Approaches to Congestion Control in Packet Networks” (PDF). Journal of Internet Engineering [англ.]. 1 (1). Архивировано из оригинала (PDF) 2014-02-21.
  40. ↑ HighSpeed TCP (англ.). icir.org. Архивировано 2 августа 2002 года.
  41. ↑ AIMD-FC Homepage (англ.). neu.edu. Дата обращения: 25 июня 2024. Архивировано 13 января 2009 года.
  42. ↑ Equation-Based Congestion Control for Unicast Applications (англ.). icir.org. Архивировано 5 апреля 2002 года.
  43. ↑ MaxNet — Max-Min Fair, Stable Explicit Signalling Congestion Control (англ.). netlab.caltech.edu. Архивировано 7 сентября 2006 года.
  44. ↑ TCP Congestion Control: A Systems Approach. Peterson, Brakmo and Davie (англ.). Дата обращения: 25 июня 2024. Архивировано 3 июня 2025 года.
  45. ↑ Что такое congestion control в Linux TCP? (англ.). Bunny.net Academy. Дата обращения: 2 мая 2025.

Литература

Ссылки

Категории