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

Цели урока

• Понимать congestion collapse 1986: почему сеть с потерями входит в петлю обратной связи
• Знать четыре стадии классического алгоритма: slow start, congestion avoidance, fast retransmit, fast recovery
• Различать loss-based (Reno, Cubic) и model-based (BBR) алгоритмы
• Считать cwnd, rwnd, ssthresh и понимать какой ограничивает throughput сейчас
• Понимать почему BBR лучше для long fat networks и spotty Wi-Fi

В октябре 1986-го интернет пережил congestion collapse: канал LBL-Berkeley (всего 400 ярдов!) просел со 32 kbit/s до 40 bit/s, в 800 раз. Загрузка 100%, полезный трафик ~0: все слали повторы, повторы вызывали ещё повторы. В 1988-м Van Jacobson опубликовал SIGCOMM-статью с алгоритмами slow start и congestion avoidance - и интернет выжил.

• **Видеозвонки:** BBR помогает Zoom/Meet работать даже при потерях Wi-Fi
• **Загрузки:** Cubic эффективно использует гигабитные каналы
• **Игры:** Низкий cwnd = низкая задержка, но меньше throughput

Предварительные знания

• TCP: Flow Control

Зачем нужен Congestion Control

**Congestion Control** (контроль перегрузки) - механизм, не позволяющий отправителю перегружать сеть. В отличие от flow control (защита получателя), congestion control защищает роутеры и каналы связи между ними.

TCP использует **implicit feedback**: потеря пакета или рост задержки означают перегрузку. Явного сигнала от роутеров нет (в отличие от ECN). Отправитель сам делает выводы.

**Flow Control vs Congestion Control:** Flow control - rwnd (receive window) от получателя. Congestion control - cwnd (congestion window) у отправителя. Реальное окно = min(rwnd, cwnd).

Slow Start - медленный старт

**Slow Start** - начальная фаза TCP-соединения. Название обманчиво: рост экспоненциальный! Окно удваивается каждый RTT, пока не случится потеря или не достигнут порог (ssthresh).

**IW (Initial Window):** Раньше - 1 MSS. Сейчас RFC 6928 рекомендует IW=10 MSS (~14 КБ). Это ускоряет загрузку небольших веб-страниц, которые могут передаться за 1 RTT.

AIMD - Additive Increase, Multiplicative Decrease

**AIMD** - основной алгоритм congestion control после slow start. Additive Increase: окно растёт линейно (+1 MSS за RTT). Multiplicative Decrease: при потере окно уменьшается вдвое.

**Triple Duplicate ACK:** 3 одинаковых ACK подряд = Fast Retransmit + Fast Recovery. cwnd делится пополам, но не сбрасывается до 1. Timeout (более серьёзная проблема) сбрасывает cwnd до 1 и запускает Slow Start заново.

Congestion Window (cwnd)

**cwnd** (Congestion Window) - окно перегрузки, поддерживаемое отправителем. В отличие от rwnd (от получателя), cwnd - оценка состояния сети самим отправителем. Эффективное окно = min(cwnd, rwnd).

**ssthresh (Slow Start Threshold):** Граница между Slow Start и Congestion Avoidance. При потере: ssthresh = cwnd/2. Следующий Slow Start продолжится только до ssthresh.

Варианты TCP: Reno, Cubic, BBR

Классический AIMD (TCP Reno) - не единственный алгоритм. Современные варианты: **TCP Cubic** (Linux по умолчанию), **BBR** (Google) - оптимизированы для разных сценариев.

**BBR (Bottleneck Bandwidth and RTT):** Вместо реакции на потери, BBR строит модель сети: измеряет max bandwidth и min RTT. Поддерживает inflight = BDP. Работает лучше при случайных потерях (Wi-Fi).

Ключевые идеи

• **Congestion Control** - защита сети от перегрузки
• **Slow Start** - экспоненциальный рост cwnd до порога
• **AIMD** - линейный рост, мультипликативное снижение при потере
• **cwnd** - окно перегрузки; effective = min(cwnd, rwnd)

Связанные темы

Congestion control - сердце производительности TCP:

• TCP Flow Control — Другое ограничение - защита получателя
• QUIC — Congestion control на уровне приложения
• Buffer Bloat — Когда большие буферы ломают congestion signals

Вопросы для размышления

• Почему timeout хуже triple duplicate ACK?
• Как BBR определяет bandwidth без потерь?
• Почему два TCP-потока с разными RTT несправедливо делят канал?

Связанные уроки

• alg-20-greedy