Bufferbloat и перегрузка

Кто-то в команде на видеозвонке, и голос постоянно прерывается — но speed test показывает 300 Мбит/с, зелёный. В это время в фоне идёт резервное копирование в облако. Пропускная способность в норме. Задержка — нет. У этого есть название.

Буфер, который съел вашу задержку

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

Граница интернета — кабельные модемы DOCSIS, LTE-модемы, домашние роутеры — это место, где быстрая сторона (гигабитная LAN) встречается с медленной (тарифный аплинк). Это узкое место, и вендоры перестарались с буферами именно там. Модем может держать 100–500 мс буферизованных данных. При насыщении каждый пакет, стоящий за полной очередью резервной копии, ждёт полную глубину этого буфера.

Симптом узнаётся мгновенно, как только знаешь о нём: idle ping — 20 мс, кто-то начинает загрузку, и ping растёт до 300–500 мс. Throughput выглядит отлично — канал полностью загружен — но каждый интерактивный пакет (DNS-запрос, SYN, видеокадр) стоит за bulk-передачей. Звонки прерываются, игры лагают, страницы зависают — и всё это пока speed test зелёный.

Почему TCP нуждается в отбрасывании пакетов

Глубинная причина — несоответствие между буферами и управлением перегрузкой. Потерь-ориентированный TCP — CUBIC, стандарт Linux годами — не имеет другого способа узнать, что канал заполнен. Он продолжает увеличивать окно передачи до тех пор, пока пакет не отбрасывается, воспринимает потерю как «труба полна» и откатывается.

Правильно настроенный буфер отбрасывает пакет рано, когда очередь ещё мелкая, так что TCP получает сигнал перегрузки при ещё низкой задержке. Огромный буфер поглощает пакет вместо этого. TCP не видит потери, предполагает, что есть место, и отправляет ещё данных — которые гигантский буфер тоже поглощает. Окно раздувается, пока буфер не заполняется полностью, на сотни миллисекунд. Вендоры думали, что «никогда не терять пакеты» — безопасный выбор. Это прямо противоположно истине: скрывая сигнал перегрузки, избыточная буферизация гарантирует глубокую очередь.

Почему это продолжается

Bufferbloat известен с 1980-х годов, но он везде до сих пор. Три причины:

1. Неверный стимул. Вендоры воспринимали отбрасывание пакетов как дефект и перестарались с буферами, чтобы «избегать потерь» — неверное исправление, потому что потеря и есть сигнал.
2. Невидимая метрика. Домашние пользователи измеряют throughput, не задержку под нагрузкой. Speed test работает на иначе-простаивающем канале и никогда не видит bloat. Проблема проявляется только когда интерактивное приложение борется с bulk-передачей.
3. Задержка развёртывания. Исправление поставляется в прошивке. Нужен роутер с Smart Queue Management (SQM), а много операторского оборудования никогда не получает это обновление.

Само исправление несложное.

Active Queue Management

Active Queue Management (AQM) — в маркетинге Smart Queue Management на домашних роутерах — отбрасывает или ECN-маркирует пакеты рано и честно, до того как очередь вырастает, восстанавливая сигнал перегрузки, который нужен TCP.

• fq_codel (RFC 8290) — flow-queued CoDel. CoDel («Controlled Delay») отслеживает время ожидания пакетов в очереди, не их количество; как только время ожидания превышает цель (~5 мс) слишком долго, начинается отбрасывание. Flow-queue разделяет потоки на отдельные подочереди, чтобы один bulk-upload не заглушал latency-sensitive поток.
• PIE (RFC 8033) — Proportional Integral controller Enhanced. Оценивает задержку очереди и отбрасывает с вероятностью, настроенной на удержание задержки около цели. PIE — это AQM, обязательный для DOCSIS 3.1, поэтому он в современных кабельных модемах.
• CAKE — Common Applications Kept Enhanced. fq_codel плюс встроенное формирование полосы, честность per-host и компенсация framing DOCSIS/ATM. Его обычно выбирают в домашних роутер-проектах (OpenWrt).

Общая идея: ограничивать задержку очереди, не длину очереди. При полном насыщении канал с CAKE или fq_codel держит ping ниже ~30 мс вместо раздувания до 500 мс.

Когда проблема не в буфере: BBR vs CUBIC

Управление перегрузкой также ломается на путях с большим RTT, и там ответ — другой алгоритм, а не другая очередь.

LEO-спутник (Starlink, орбита ~550 км, ~50–60 мс RTT) ведёт себя как наземный канал — потерь-ориентированный CUBIC работает нормально. GEO-спутник (~36 000 км орбита, ~600 мс RTT) — нет. При петле обратной связи 600 мс к тому времени, как сигнал о потере возвращается к отправителю, несколько полных окон уже переданы. Потерь-ориентированное управление реагирует слишком поздно; CUBIC разгоняется медленно и никогда не заполняет канал — он голодает.

BBR (Bottleneck Bandwidth and Round-trip propagation time) полностью обходит потери. Он активно зондирует пропускную способность и минимальный RTT пути, строит модель узкого места и ведёт отправки по этой модели. Поскольку он не ждёт потери, задержка обратной связи в 600 мс больше не калечит его, и BBR восстанавливает большую часть ёмкости GEO-канала. Та же независимость от потерь делает BBR сильным на любом потерявшем пути — сотовая связь, перегруженный Wi-Fi.

Эти два аспекта встречаются у сотовой вышки: мобильные операторы развёртывают AQM в стиле CAKE на радиоячейке, чтобы буфер для пользователей, делящих одну ячейку, оставался дисциплинированным. Паттерн для запоминания: BBR + AQM + маленькие буферы выигрывает на high-latency или lossy путях; CUBIC + разумно настроенный буфер нормален на наземных проводных каналах.