Bufferbloat: почему скачивание убивает ваш звонок

MAATRIX

Запускаете загрузку большого файла или обновление системы — и через минуту видеозвонок начинает заикаться, голос собеседника рассыпается на слоги, а курсор в игре двигается рывками. При этом спидтест показывает, что канал не забит: скорость скачивания на месте, потерь пакетов вроде нет. Это не совпадение и не глюк роутера — это bufferbloat, и у него есть конкретная техническая причина, а не «интернет плохой».

Что такое bufferbloat и почему это не то же самое, что перегрузка канала

Перегрузка канала — это когда вы пытаетесь прогнать через него больше данных, чем он физически пропускает, и часть трафика теряется или очередь растёт пропорционально превышению. Bufferbloat — другая история: канал загружен ровно настолько, насколько может, пакеты не теряются, но задержка (latency) вырастает в разы, а то и на порядок, потому что где-то на пути стоит буфер, который вместо того чтобы отбрасывать лишние пакеты, копит их про запас.

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

Термин ввёл в оборот Джим Геттис (Jim Gettys) в 2010 году, когда обнаружил, что его домашний интернет не может нормально работать с VoIP при любой параллельной закачке — и что проблема системная, а не в его конкретном оборудовании. С тех пор bufferbloat изучен достаточно хорошо: есть проект bufferbloat.net, документация, тесты и готовые решения — но на подавляющем большинстве домашних роутеров и провайдерского оборудования (кабельных и DSL-модемов, LTE/5G-модемов) проблема как была, так и осталась не решена «из коробки».

Механика: как буфер копит пакеты вместо того чтобы их дропать

Возьмём типичную ситуацию: у вас канал 100 Мбит/с на скачивание, вы начинаете торрент или обновление Windows, которое старается забрать всю доступную полосу. Операционная система и торрент-клиент отправляют/принимают пакеты настолько быстро, насколько позволяет TCP-окно, и на входе в узкое место — обычно это порт вашего модема или маршрутизатора провайдера — скапливается очередь.

Если бы буфер на этом узком месте был маленьким, лишние пакеты просто отбрасывались бы (drop tail на переполненной короткой очереди), TCP-стек получателя увидел бы потерю, отправитель уменьшил бы окно — и очередь стабилизировалась бы на небольшом уровне, добавляя единицы-десятки миллисекунд задержки. Именно так задумана классическая модель TCP: потеря пакета — это сигнал «притормози».

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

Важный нюанс: сама по себе полоса пропускания не проседает — вы всё ещё можете качать файл на полной скорости. Проблема исключительно в задержке (latency) и джиттере (разбросе задержки), причём именно в те моменты, когда канал загружен «под завязку» в одном направлении. Отсюда и характерный симптом: обычный пинг в холостом режиме — 10-20 мс, а стоит запустить закачку — тот же пинг улетает в сотни миллисекунд или секунды. Подробнее о том, чем задержка отличается от полосы пропускания и почему хороший пинг не гарантирует быстрый сайт, разбирали в статье «Ping хороший, а сайт медленный: задержка и полоса».

Почему TCP не спасает от этой ситуации сам

Логичный вопрос: если TCP умеет реагировать на перегрузку, почему он не реагирует на bufferbloat? Ответ в том, на какой сигнал TCP настроен реагировать. Классические алгоритмы управления перегрузкой (Reno, CUBIC — то, что годами использовалось по умолчанию в Linux и Windows) снижают скорость отправки в ответ на потерю пакета или явное уведомление о перегрузке (ECN). Если буфер достаточно большой, чтобы вместить весь трафик, который вы пытаетесь протолкнуть, пакеты просто не теряются — они успешно доставляются, просто с большой задержкой.

С точки зрения отправителя всё выглядит хорошо: подтверждения (ACK) приходят, потерь нет, значит можно слать быстрее или хотя бы не снижать скорость. TCP видит только один явный сигнал «стоп» — потерю пакета — а задержку в буфере он не воспринимает как проблему, если явно не настроен на это (алгоритмы вроде BBR или Vegas отчасти реагируют на рост RTT, но это не универсальное решение и не отменяет проблему для остального трафика в той же очереди). В итоге закачка продолжает удерживать буфер заполненным до тех пор, пока не закончится сама или пока пользователь не остановит её вручную — а всё это время любой другой пакет, включая голосовой трафик и игровые команды, стоит в очереди позади.

Здесь и кроется разница с «просто перегруженным каналом»: без раздутых буферов система быстро находит равновесие с приемлемой задержкой, потому что механизм «потеря → снижение скорости» работает как задумано. При bufferbloat этот механизм молчит, потому что буфер прячет от TCP сам факт перегрузки, откладывая расплату в виде задержки, а не пропускной способности.

Как проверить, есть ли у вас bufferbloat

Диагностика бытового bufferbloat не требует специальных инструментов — есть готовые онлайн-тесты, которые измеряют задержку в состоянии покоя и задержку под нагрузкой (обычно одновременно с загрузкой и выгрузкой канала на максимум), а затем сравнивают их. Список актуальных тестов и материалы по теме собраны на сайте проекта bufferbloat.net — там же есть и объяснение методики измерений, если хотите разобраться глубже, чем позволяет формат этой статьи.

Смысл теста простой: он измеряет базовый пинг (idle latency), затем запускает параллельную закачку/выгрузку, которая старается насытить канал, и в этот момент продолжает мерить задержку (loaded latency). Разница между этими двумя цифрами — и есть ваш bufferbloat в миллисекундах. Условно ориентируются на такую грубую шкалу (это именно ориентир для интерпретации результата теста, а не измеренные вами числа):

Если хотите проверить механику руками, а не доверять готовому тесту: откройте терминал и запустите непрерывный ping до любого стабильного адреса (например, до вашего же VPS или до 1.1.1.1), а в другом окне запустите параллельно закачку крупного файла на полной скорости. Разница между пингом в состоянии покоя и пингом во время закачки — это и есть буферизованная задержка. Про методику измерения реального пинга до сервера, включая типичные ошибки замера, есть отдельный разбор — «Как измерить реальный пинг до сервера: методика». Если задержка растёт, а при этом начинают появляться и потери пакетов — это уже не чистый bufferbloat, а смешанная картина, и стоит заглянуть в материал «Packet loss на VPN: как диагностировать», чтобы разделить эти две причины.

Стоит проверить обе стороны канала отдельно — многие домашние подключения асимметричны (upload заметно уже download), и bufferbloat на исходящем канале обычно даёт о себе знать в первую очередь через голосовые звонки и запись видео, потому что именно исходящий поток аудио/видео упирается в узкое место на вашей стороне.

SQM, CAKE и fq_codel: как это лечится

Раз проблема в том, что буфер слишком большой и «слепой» (не различает типы трафика и не управляет своей длиной), решение — либо уменьшить буфер, либо сделать его «умным». На практике для домашних и малых офисных сетей эта задача решается набором технологий, объединённых под общим названием SQM (Smart Queue Management):

• fq_codel (Fair Queuing + Controlled Delay) — алгоритм управления очередью, который делает две вещи одновременно: во-первых, следит за тем, сколько времени пакеты реально проводят в очереди, и начинает активно отбрасывать (или помечать через ECN) часть пакетов, если задержка превышает целевой порог — тем самым он «возвращает» TCP тот самый сигнал о перегрузке, который прятал большой тупой буфер. Во-вторых, он честно разделяет потоки (flows) друг от друга, чтобы одно агрессивное TCP-соединение (например, торрент, который держит десятки параллельных потоков) не вытесняло из очереди единичный пакет голосового звонка или DNS-запроса.
• CAKE (Common Applications Kept Enhanced) — развитие идей fq_codel, изначально разработанное внутри проекта bufferbloat как «всё в одном»: помимо честной очереди и контроля задержки, CAKE умеет автоматически учитывать накладные расходы канала (overhead от инкапсуляции PPPoE, DOCSIS, ATM и так далее), делать базовую приоритизацию трафика по типу (интерактивный/объёмный) и работать в обе стороны канала. На практике CAKE сегодня — это тот вариант, который рекомендуют настраивать в первую очередь, если оборудование его поддерживает.
• SQM — это не отдельный алгоритм, а общее название функции на роутере, которая объединяет ограничение скорости (shaping) чуть ниже реальной пропускной способности канала с одним из умных алгоритмов очереди (обычно cake или fq_codel). Смысл ограничения скорости именно на вашей стороне принципиален: управлять очередью можно только там, где вы контролируете буфер. Модем провайдера — черный ящик с неизвестным и обычно раздутым буфером, повлиять на который вы не можете. А вот если задать на своём роутере скорость исходящего/входящего трафика чуть ниже (условно, на 5-15% меньше) реальной пропускной способности канала, то узким местом станет уже ваш роутер с управляемой очередью — а не модем провайдера с непредсказуемым буфером.

Именно поэтому простое «включить QoS» без ограничения скорости часто не помогает: если пакеты упираются в буфер модема, а не в буфер роутера, вся приоритизация на роутере проходит впустую — очередь, которая реально копит задержку, находится дальше по цепочке и вашему QoS не подчиняется.

Как включить SQM на своём роутере

Проще всего это делается на прошивках с открытым исходным кодом, где SQM реализован как готовый пакет, а не набор ручных правил tc. Общий принцип одинаков для разных платформ:

OpenWrt — установить пакет luci-app-sqm (или sqm-scripts без веб-интерфейса), затем в разделе SQM указать:

• интерфейс, на котором применяется шейпинг (обычно WAN-интерфейс);
• скорость download и upload в кбит/с — именно ту, что чуть ниже реально измеренной скорости канала, а не тарифную «до»;
• алгоритм очереди — cake как вариант по умолчанию для большинства случаев;
• при использовании PPPoE или кабельного/DOCSIS-подключения отдельно указывается overhead и тип инкапсуляции — сам CAKE умеет считать это через готовые пресеты (docsis, pppoe-vdsl и т.п.), и в большинстве случаев проще выбрать подходящий пресет, чем вбивать число вручную.

OPNsense/pfSense — оба поддерживают formatting трафика через собственные Traffic Shaper/Limiter модули; в OPNsense есть отдельный плагин Shaper с поддержкой очередей на базе fq_codel/cake, в pfSense аналогичная функциональность доступна через Limiters с очередями CoDel. Настройка сложнее, чем в OpenWrt (нет единого мастера SQM), но принцип тот же: ограничить скорость на границе и назначить умную очередь.

Домашние роутеры потребительского класса (Keenetic, ASUS, TP-Link и подобные со stock-прошивкой) в большинстве случаев либо вообще не имеют SQM, либо предлагают под именем «QoS» упрощённую приоритизацию по портам/приложениям без управления самой очередью и без анти-bufferbloat алгоритма — это лучше, чем ничего, но не решает проблему полностью. Если оборудование позволяет прошивку OpenWrt (список поддерживаемых устройств есть на сайте проекта) — это самый предсказуемый путь получить полноценный SQM.

Практический момент, который часто упускают: правильный SQM почти всегда требует занижения заявленной скорости канала на роутере — вы сознательно жертвуете 5-15% максимальной пропускной способности ради стабильной низкой задержки. Это осознанный компромисс: пиковая скорость закачки чуть ниже, зато звонок не рвётся, даже когда параллельно кто-то в доме качает обновление. Если вы подключаетесь к своему серверу по VPN, задержка внутри WireGuard/OpenVPN сама по себе не растёт из-за домашних буферов, но общий пинг до сервера всё равно складывается из вашего домашнего участка сети плюс маршрута до сервера — разбор джиттера для голоса и игр отдельно описан в материале «Джиттер и VPN для голосовой связи и игр».

Частые вопросы