Как работает TCP congestion control: Reno, Cubic, BBR простыми словами

Когда вы скачиваете файл или открываете сайт, данные передаются по сети не одним куском, а небольшими порциями — TCP-пакетами. Но возникает вопрос: с какой скоростью их отправлять? Если слишком быстро — сеть перегрузится и появятся потери. Если слишком медленно — канал используется неэффективно.

Этим и занимается TCP congestion control — механизм, который регулирует скорость передачи данных в зависимости от состояния сети.

Базовая идея

У TCP есть параметр congestion window (cwnd) — это окно, которое определяет, сколько данных можно отправить без подтверждения (ACK).

Принцип работы:

• сеть справляется → увеличиваем скорость
• появляются потери → уменьшаем скорость

Это называется AIMD (Additive Increase / Multiplicative Decrease):

• увеличение происходит постепенно
• уменьшение — резко

Как TCP понимает, что сеть перегружена

Есть несколько сигналов:

• потеря пакета (нет ACK)
• дублирующиеся ACK
• увеличение времени RTT

Главный сигнал в классических алгоритмах — именно потери.

TCP Reno

TCP Reno — один из классических алгоритмов.

Как он работает:

1. Slow start
   • cwnd растёт экспоненциально (очень быстро)
   • цель — быстро «нащупать» доступную пропускную способность
2. Congestion avoidance
   • рост становится линейным
   • более осторожное увеличение
3. При потере пакета
   • cwnd уменьшается в 2 раза
   • начинается восстановление

Плюсы:

• простой
• стабильный

Минусы:

• плохо работает на больших каналах с высокой задержкой
• потери используются как основной сигнал (это уже поздно)

TCP Cubic

Cubic — это современный стандарт в Linux.

Основная идея: рост окна зависит от времени, а не от количества ACK.

Как это выглядит:

• сначала рост быстрый
• затем замедляется
• потом снова ускоряется

График напоминает кубическую кривую (отсюда и название).

Что это даёт:

• лучшее использование высокоскоростных каналов
• меньше зависимость от RTT
• более стабильное поведение

При потере:

• окно уменьшается
• затем восстанавливается по своей кривой

Cubic агрессивнее Reno, но при этом эффективнее на современных сетях.

TCP BBR

BBR (Bottleneck Bandwidth and RTT) — совсем другой подход, разработанный Google.

Главная идея: не ждать потерь, а заранее оценивать состояние сети.

BBR измеряет:

• пропускную способность (bandwidth)
• задержку (RTT)

И на основе этого рассчитывает оптимальную скорость отправки.

В отличие от Reno и Cubic:

• не полагается на потери
• старается держать минимальную задержку

Как он работает:

1. Оценивает максимальную пропускную способность
2. Измеряет минимальный RTT
3. Поддерживает скорость на уровне bandwidth × RTT

Плюсы:

• высокая скорость
• низкая latency
• меньше потерь

Минусы:

• может быть агрессивным к другим алгоритмам
• не всегда предсказуем в смешанных сетях

Сравнение

Reno:

• простой и надёжный
• реагирует только на потери

Cubic:

• стандарт де-факто в Linux
• хорошо работает на быстрых сетях

BBR:

• ориентирован на latency и throughput
• использует модель сети, а не потери

Итог

TCP congestion control — это баланс между скоростью и стабильностью.

• Reno — старая, но понятная модель
• Cubic — оптимизирован для современных сетей
• BBR — попытка переосмыслить подход

Если упрощать:

• Reno — «увидел потерю → тормози»
• Cubic — «расти по умной кривой»
• BBR — «оцени сеть и держи оптимальную скорость»

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