Bufferbloat: почему WiFi тормозит, хотя скорость высокая

Гигабитное подключение, превращающееся в слайд-шоу, как только кто-то начинает загрузку, — это не парадокс. Это самая распространённая проблема домашних сетей, у неё есть название — bufferbloat, — и она не имеет никакого отношения к тому, сколько пропускной способности вы оплачиваете.

Что такое bufferbloat на самом деле

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

TCP, протокол, стоящий почти за всем, что вы делаете в сети, узнаёт, с какой скоростью отправлять данные, только наблюдая за признаками перегрузки сети. Традиционно таким признаком служит потерянный пакет: очередь заполнена, что-то отбрасывается, отправитель снижает скорость. Слишком большая очередь задерживает этот сигнал вместо того, чтобы его подать. Пакеты продолжают накапливаться вместо того, чтобы теряться, TCP продолжает разгоняться, потому что никто не сказал ему остановиться, и каждый пакет — включая пакет вашего звонка, вашей игры, вашего DNS-запроса — теперь должен ждать за очередью, которая может тянуться секундами. Соединение не медленное. Оно просто стоит в очень длинной очереди.

Почему это проявляется только под нагрузкой

У простаивающего соединения очередь пуста, поэтому его задержка выглядит отлично — 15, 20, 30 миллисекунд, ровно столько, сколько должно стоить расстояние до сервера. Запустите крупную загрузку в фоне, и та же самая связь может подскочить до 500мс, 1000мс, иногда больше, потому что теперь перед вашими пакетами стоит целая очередь чужих. Именно поэтому bufferbloat так легко пропустить при обычном тесте скорости: простая цифра загрузки/отдачи никогда не подвергает канал той устойчивой двусторонней нагрузке, которую создаёт реальное использование, поэтому очередь по-настоящему никогда не заполняется.

Число, которое действительно важно, — это не задержка в покое и не задержка под нагрузкой сами по себе, а разница между ними. Соединение с 40мс в покое и 60мс под нагрузкой (разница 20мс) в целом в порядке. Соединение с 15мс в покое и 900мс под нагрузкой (разница 885мс) сильно перегружено, даже если минуту назад его показатель в покое выглядел идеально.

Как заметить это за 30 секунд

Запустите тест скорости, который измеряет задержку и в покое, и под нагрузкой — Speed Test этого сайта делает именно это, и делает это намеренно. Наблюдайте за задержкой под нагрузкой, пока идут фазы загрузки и отдачи. Если она остаётся в пределах 20-30мс от показателя в покое — всё чисто. Если она взлетает до нескольких сотен миллисекунд — это bufferbloat, и теперь у вас есть число, чтобы сравнить его до и после любого решения.

Что действительно помогает

Настоящее решение — более умная очередь на устройстве, которое контролирует узкое место — почти всегда это ваш роутер, иногда модем или ONT провайдера, если он сам управляет своими очередями. Современные алгоритмы управления очередями, fq_codel и его преемник cake, активно управляют глубиной очереди вместо того, чтобы позволять ей расти бесконтрольно: они держат ровно столько буфера, сколько нужно, чтобы сгладить всплески, и не больше, и дают конкурирующим потокам (вашему звонку, вашей загрузке, вашей игре) честные очереди вместо обслуживания в порядке поступления. Большинство роутеров с OpenWrt и всё больше заводских прошивок предлагают это как «Smart Queue Management» или «SQM» — включить эту функцию обычно самая эффективная настройка во всём роутере.

Есть и вторая, менее очевидная часть, которая важна не меньше: SQM работает только тогда, когда знает реальный потолок вашего канала. Установка ограничения скорости чуть ниже вашей реальной скорости линии — роутеры с SQM обычно прямо запрашивают это, что-то вроде 90-95% от измеренной скорости в каждом направлении — переносит очередь с неподконтрольного вам оборудования провайдера на ваш собственный роутер, где умное управление очередями действительно может работать. Без этого ограничения самая большая очередь на пути может оказаться внутри устройства, которое вы не контролируете и не можете настроить, и никакая настройка на стороне роутера до неё не дотянется.

Что не помогает

Более быстрый тариф не помогает. Это тот миф, который призвано развеять это руководство: переход с 300 Мбит/с на гигабит не уменьшает завышенную очередь, он лишь позволяет этой очереди заполняться быстрее. Множество гигабитных соединений перегружены сильнее, чем множество соединений на 100 Мбит/с, потому что bufferbloat — это проблема управления очередями, а не пропускной способности — вы можете проверить это сами, запустив тест задержки под нагрузкой на быстром соединении с выключенным SQM и всё равно увидев разницу. Платить за большую скорость, чтобы исправить bufferbloat, — всё равно что расширять дорогу, чтобы починить неправильно настроенный светофор: это не касается настоящей причины, а на некоторых роутерах более быстрый тариф даже ухудшает математику очереди вместо того, чтобы улучшить её, потому что роутеру теперь приходится буферизовать больше данных в секунду, прежде чем SQM — если он вообще включён — успеет их обработать.

Ещё одно место, где это прячется: очередь вашего собственного роутера, а не только провайдера

Стоит точно назвать, где обычно живёт завышенная очередь, потому что «где-то в сети» — это не то, на что можно повлиять. Чаще всего это сам роутер или модем сразу за ним — устройство, ближайшее к настоящему узкому месту, которым для большинства домашних подключений является WAN-канал, а не WiFi. Роутер без всякого управления очередями с готовностью будет буферизовать мегабайты данных, которые у него нет никакой надежды отправить за разумное время, потому что ничто не говорит ему иначе. Именно поэтому mesh-система или репитер сами по себе редко решают проблему bufferbloat: эти устройства находятся на стороне WiFi сети, ниже настоящего узкого места, и чистый WiFi-скачок перед перегруженной очередью WAN всё равно остаётся перегруженным соединением.

Почему это самый большой фактор в вашем Sygnal Score

Sygnal Score взвешивает шесть измерений, и bufferbloat — измеренный именно так, как описано выше, как разница между задержкой под нагрузкой и задержкой в покое, — стоит 250 из 1000 общих баллов, больше, чем любой другой отдельный блок. Полный балл при разнице в 20мс или меньше, ноль баллов при 400мс и выше, с линейным спадом между ними. Такой вес выбран намеренно: соединение, показывающее огромные цифры загрузки и отдачи, но разваливающееся, как только его действительно используют — для звонка, игры, чего угодно в реальном времени, — не является хорошим соединением, а оценка, построенная только на пропускной способности, всё равно назвала бы его хорошим. Bufferbloat — это то место, где быстрая, но сломанная линия оказывается разоблачена.