Скорость высокая, а звонки и игры начинают лагать при любой передаче? Обычно виноват bufferbloat — задержка от раздутых буферов, а не нехватка скорости.
Соединение может показывать отличную скорость загрузки и всё равно становиться невыносимым в тот момент, когда кто-то запускает большую выгрузку или начинает скачиваться обновление игры: голос в звонке становится роботизированным, игры дёргаются, страницы зависают. Дело тут редко в пропускной способности. Обычно это bufferbloat: слишком большие буферы в вашем роутере, модеме или оборудовании провайдера копят пакеты в очереди вместо того, чтобы их отбрасывать, и добавляют задержку, которая проявляется только когда канал занят. Разберёмся, откуда она берётся и как её убрать.
Ключевые выводы
- Bufferbloat — это лишняя задержка из-за раздутых буферов, а не нехватка пропускной способности: скорость по тарифу может быть в полном порядке, а соединение всё равно будет тормозить под нагрузкой.
- Пока канал простаивает, проблему не видно. Быстрый пинг покажет отличный результат — задержка появляется только тогда, когда загрузка или выгрузка забивает канал полностью.
- Задержка под нагрузкой может быть на порядок выше, чем без неё. В опубликованном APNIC тесте домашнего подключения пинг вырос с нескольких миллисекунд почти до 300 мс, как только канал забился.
- Стандартное решение — активное управление очередью (AQM), а конкретно FQ-CoDel: большинство современных роутеров и прошивок на базе OpenWrt умеют включать его без замены оборудования.
- За один прогон теста скорости это не поймать — пинг измеряется до того, как пойдут данные. Сначала нагрузите канал, потом замерьте ещё раз и сравните.
Что такое bufferbloat?
Роутеры и модемы держат небольшую очередь — буфер, — чтобы на мгновение придержать пакеты, когда данные приходят быстрее, чем исходящий канал успевает их отправлять. Это нормально и необходимо. Проблема начинается, когда буфер сделан намного больше, чем нужно: вместо того чтобы коротко сгладить всплеск, раздутый буфер позволяет пакетам копиться сотнями миллисекунд, прежде чем их отправят, — устройство скорее поставит пакет в очередь, чем отбросит его. Как пишет сетевой блог APNIC, интуитивно кажется, что низкая производительность означает нехватку пропускной способности, тогда как настоящая причина очень часто — именно эта лишняя задержка в слишком глубоком буфере.
Термин ввёл около 2010 года инженер Джим Геттис: он выяснил, что загадочные тормоза домашних сетей идут от потребительских роутеров и модемов, буферы которых рассчитывали под бенчмарки пропускной способности, а не под отзывчивость. Буфер побольше действительно может дать чуть более высокую пиковую цифру в отдельном тесте, но платой становится вот что: любой пакет, вставший в очередь за большой передачей, вынужден ждать своей очереди. Это ожидание и есть bufferbloat.
Пинг без нагрузки и пинг под нагрузкой
Bufferbloat прячется от обычного тестирования именно потому, что проявляется только под нагрузкой. Пропингуйте роутер, когда в сети больше ничего не происходит, и вы увидите чистое низкое значение — это пинг без нагрузки, замер пустой очереди. Запустите одновременно большую выгрузку или загрузку и замерьте снова — получите пинг под нагрузкой: реальную задержку пакета, которому теперь приходится ждать позади всего, что уже стоит в очереди.
Разрыв между этими двумя числами — и есть вся суть, и он совсем не маленький. В упомянутой выше статье APNIC автор снимал пинг до удалённого сервера, параллельно запустив выгрузку и загрузку: первые пять секунд задержка держалась на нескольких миллисекундах, а как только пошли передачи — выросла почти до 300 мс. Треть секунды на один-единственный обмен пакетами: с таким видеозвонок уже не работает. Пропускная способность при этом не менялась вообще — просто каждый пакет теперь стоял в очереди, которая наконец-то пригодилась.
Именно поэтому отраслевые измерения сместились в сторону отслеживания задержки под нагрузкой, а не только пинга в простое: и задержка без нагрузки, и «сырая» скорость на соединении с bufferbloat выглядят прилично, так что ни та ни другая не предсказывают, каким это соединение окажется в реальном использовании.
Из-за чего это происходит
Bufferbloat — это не один баг, а сочетание щедрых буферов по умолчанию с тем, как ведёт себя большинство передач:
- Слишком большие очереди по умолчанию. Домашние роутеры, кабельные модемы, DSL-модемы и оптические ONT часто настроены так, чтобы вообще никогда не терять пакет в бенчмарке пропускной способности, — а это прямо противоположно тому, что нужно для низкой задержки.
- Управление перегрузкой по потерям. Многие передачи (большие загрузки, облачная синхронизация, крупные выгрузки) наращивают скорость отправки, пока пакет реально не потеряется. При глубоком буфере потеря не случится, пока очередь не заполнится почти целиком, — то есть буфер успевает забиться до отказа прежде, чем отправитель сбавит темп.
- Раздувается то направление, которое загружено. Большая выгрузка забивает исходящую очередь (ваш исходящий трафик ждёт), большая загрузка — очередь на стороне провайдера или модема. Любого из двух хватит, чтобы всё остальное на соединении начало тормозить.
- Оборудование провайдера, а не только ваш собственный роутер, может нести ровно те же раздутые буферы — поэтому bufferbloat иногда никуда не девается даже после замены домашнего роутера.
Как это лечится: активное управление очередью и FQ-CoDel
Лечится это не тарифом пожирнее, а управлением очередью вместо простого её наращивания. Активное управление очередью (AQM) само решает, когда отбросить или пометить пакет, до того как очередь разрастётся, — в отличие от традиционного «отбрасывания с хвоста», когда пакеты начинают теряться только после того, как буфер уже забит под завязку.
Современный стандарт — FQ-CoDel (Fair Queuing with Controlled Delay, справедливое распределение по очередям с контролируемой задержкой), стандартизированный как экспериментальный алгоритм в RFC 8290. Он делает две вещи сразу.
CoDel смотрит не на то, сколько пакетов лежит в очереди, а на то, сколько времени каждый пакет в ней реально проводит. Как только это время держится выше небольшого целевого значения (по умолчанию 5 мс) дольше короткого интервала наблюдения (по умолчанию 100 мс), алгоритм начинает отбрасывать пакеты — сигнал отправителям сбавить темп, — и очередь остаётся мелкой вместо того, чтобы разрастаться. Справедливое распределение, в свою очередь, раскладывает трафик по множеству отдельных очередей на каждый поток (по умолчанию их 1024) и обслуживает их по кругу, так что одна массивная передача не может задавить всё, что стоит за ней. Благодаря этой связке одна большая загрузка больше не обязана рушить видеозвонок на том же соединении.
Нового оборудования для этого не нужно. Большинство роутеров на OpenWrt, а также всё больше штатных прошивок провайдеров и производителей, дают эту настройку под именем Smart Queue Management (SQM) или похожего переключателя «исправить bufferbloat» — обычно с выбором между fq_codel и cake, более новой доработкой, которая объединяет шейпер и управление очередью в один настроенный пакет.
Чаще всего ошибаются именно в настройке скорости. Указывайте скорость приёма и отдачи чуть ниже реально измеренной: так вы намеренно делаете узким местом свой собственный роутер, и очередь собирается в том единственном устройстве, чьей дисциплиной очереди вы управляете, а не внутри оборудования провайдера, до которого вам не дотянуться. Особенно это важно для входящего направления, где контроль неизбежно косвенный: пришедший пакет уже не «отправить обратно», и единственный рычаг — отбрасывать или помечать пакеты, чтобы отправители на той стороне сбавили темп. Будьте готовы отдать за это часть пиковой скорости (в том тесте APNIC — около 10%) и проверьте, хватает ли роутеру процессора, чтобы шейпить на скорости вашего канала: AQM даётся не бесплатно.
Как проверить bufferbloat дома
За один прогон теста скорости это не увидеть: тест меряет пинг до того, как начнёт гонять данные, — то есть ровно тогда, когда очередь пуста. Весь фокус в том, чтобы сначала занять канал, а мерить потом. Хватит двух прогонов:
- Снимите базовые значения без нагрузки. Когда в сети больше ничего не происходит, запустите тест скорости сети BrowserInsight и запишите «Задержку» и «Джиттер», а заодно скорости загрузки и выгрузки.
- Забейте канал — и держите его забитым. Запустите передачу, которая не закончится через минуту: большую выгрузку файла или облачный бэкап, скачивание обновления игры или просто тест скорости на втором устройстве в той же сети. Быстрее всего проблему вскрывает выгрузка — скорость отдачи обычно меньше из двух.
- Прогоните тест скорости ещё раз, пока эта передача идёт. Тест снимает задержку в самом начале прогона, поэтому канал должен быть нагружен ещё до того, как вы нажмёте «Начать тест». Полученные «Задержка» и «Джиттер» — это и есть ваши значения под нагрузкой.
- Сравните. Если задержка под нагрузкой в разы выше — десятки миллисекунд превратились в сотни, — это bufferbloat, и джиттер обычно подрастает вместе с ней. Соединение с нормальным управлением очередью держит оба замера близко друг к другу даже под полной нагрузкой.
О том, что означают сами значения без нагрузки, читайте в разборе пропускной способности, задержки и джиттера. А если замеры скачут от прогона к прогону, статья почему результаты теста скорости постоянно меняются разбирает другие частые причины — чтобы вы не приняли обычный разброс за bufferbloat.
Часто задаваемые вопросы
Решит ли проблему более быстрый тариф?
Нет. Bufferbloat — это проблема очереди и задержки, а не ёмкости канала. Более быстрый тариф может даже ухудшить дело: роутер, настроенный на старую, меньшую скорость, позволит скопиться ещё большему всплеску данных, прежде чем сработает его собственный шейпер. Помогает починка управления очередью (AQM/FQ-CoDel), а не размер тарифа.
Bufferbloat — это вина провайдера или моего роутера?
Может быть и то, и другое, а может и оба сразу. Потребительские роутеры сплошь и рядом приезжают с раздутыми буферами по умолчанию, но модем или ONT от провайдера — и оборудование выше по цепочке — могут страдать тем же самым. Замер задержки под нагрузкой через свой роутер покажет, лечится ли это локально (включить SQM) или вопрос нужно поднимать с провайдером.
Почему звонки и игры страдают, даже когда выгружаю не я?
Любая забитая очередь на общем пути влияет на каждый проходящий через неё поток, а не только на ту передачу, что заполнила буфер. Если кто-то другой в вашей сети начал большую загрузку или ваше же устройство запустило фоновый бэкап, очередь забьётся точно так же — и ваш звонок или игра, которым задержка важнее пропускной способности, получат удар первыми.
Можно ли починить bufferbloat без покупки нового оборудования?
Часто да. Многие уже имеющиеся роутеры, особенно на OpenWrt или похожей сторонней прошивке, поддерживают Smart Queue Management / FQ-CoDel как настройку, которую достаточно включить. А вот там, где штатная прошивка её не даёт, новое (или перепрошитое) оборудование действительно становится практичным решением.
Заключение
Быстрая цифра загрузки и ощущение тормозящего соединения друг другу не противоречат — это и есть почерк bufferbloat: раздутые буферы копят пакеты в очереди вместо того, чтобы вовремя их доставлять, стоит каналу оказаться занятым. Пинг без нагрузки прячет это полностью; показать проблему может только замер под нагрузкой. Решение — не добавка пропускной способности, а активное управление очередью, в первую очередь FQ-CoDel, которое сегодня умеет включать большинство роутеров. Проверьте задержку без нагрузки и под нагрузкой на своём соединении: если разрыв велик, чинить нужно очередь, а не апгрейдить тариф.
Рекомендуем также прочитать:
