Как измерить bufferbloat на пути до своего сервера и что с ним делать со стороны хоста

MAATRIX

Бэкап на сервер стартует по расписанию — и через минуту пинг до него улетает с привычных 20-30 мс куда-то в район полусекунды, SSH-сессия начинает залипать на каждой букве, а видеозвонок через тот же канал рассыпается на слоги. Спидтест при этом показывает нормальную скорость, потерь пакетов вроде нет. Это классическая картина bufferbloat — избыточной буферизации где-то на пути между вами и сервером, — и у неё есть простой способ измерения без специальных инструментов: сравнить пинг в состоянии покоя канала с пингом во время параллельной закачки. Разберём саму методику применительно именно к своему серверу и честно поговорим о том, что из этого можно поправить со стороны хостинга, а что — нет.

Что такое bufferbloat в двух словах

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

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

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

Классический симптом: запустили бэкап — и деградировало всё остальное

Возьмём типичную ситуацию с собственным сервером. Вы администрируете VPS или выделенный сервер, регулярно подключаетесь по SSH, держите открытым мониторинг, иногда созваниваетесь через сервис, который проксируется через тот же канал. В какой-то момент вы (или cron) запускаете что-то объёмное — выгрузку бэкапа в удалённое хранилище, синхронизацию большого набора файлов, полную загрузку дампа базы данных на локальную машину.

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

Симптом узнаваемый: деградирует не сама закачка (она идёт на полной скорости) — деградирует вообще всё остальное, что делит с ней канал. Это и есть отпечаток bufferbloat: буфер где-то на пути, вместо того чтобы честно ограничить нагрузку, копит пакеты и добавляет задержку всем, кто пользуется этим каналом одновременно с закачкой.

Важно отделить это от простой перегрузки канала. Если бы канал был перегружен без раздутого буфера, лишние пакеты бы терялись, TCP видел бы потери и снижал скорость — очередь стабилизировалась бы на небольшом уровне, задержка выросла бы на единицы-десятки миллисекунд, а не в разы. Здесь же скорость закачки не падает, потерь нет (или почти нет) — а задержка растёт кратно. Это и есть диагностический признак именно bufferbloat, а не банальной нехватки полосы.

Метод измерения: пинг в покое против пинга под нагрузкой

Диагностика не требует ничего, кроме терминала и двух окон. Идея простая: измерить базовую задержку до сервера, когда канал свободен, затем — задержку до того же сервера во время параллельной закачки крупного файла, и сравнить разницу.

Шаг 1. Измерьте пинг в состоянии покоя. Убедитесь, что в данный момент никто (включая вас) не гоняет через канал ничего тяжёлого, и запустите:

ping -c 50 your-server-ip

Посмотрите на итоговую строку rtt min/avg/max/mdev — это ваша базовая (idle) задержка. Точное число зависит от провайдера и локации сервера — ориентируйтесь на собственное типичное значение, а не на абстрактную норму.

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

# выгрузка на сервер (нагружает исходящий канал у вас)
curl -T large_file.bin sftp://your-server-ip/path/

# или скачивание с сервера (нагружает входящий канал у вас)
curl -o /dev/null http://your-server-ip/large_file.bin

Файл должен быть достаточно большим, чтобы закачка шла минимум минуту-две — на маленьком файле канал не успеет прогреться и очередь не успеет заполниться до показательного состояния.

Шаг 3. Пока закачка идёт, повторите ping в третьем окне терминала:

ping -c 50 your-server-ip

Сравните итоговые avg из шага 1 и шага 3. Разница между пингом в покое и пингом под нагрузкой — это и есть ваш bufferbloat в миллисекундах на текущем маршруте. Для картины точнее, чем даёт усреднение, смотрите не только на avg, а на max и на разброс между запусками — bufferbloat часто проявляется не ровным ростом задержки, а скачками.

Стоит проверить оба направления отдельно — закачку на сервер и с сервера — потому что многие каналы асимметричны, и bufferbloat может проявляться заметно сильнее в одном направлении. Если есть возможность гонять mtr параллельно с закачкой, это позволяет увидеть не только итоговую деградацию, но и конкретный хоп на маршруте, где она нарастает — методика чтения mtr та же, что разобрана в статье как измерить реальный пинг до сервера: методика.

Условный ориентир для интерпретации разницы (именно ориентир, не строгая шкала — у вас будет своя картина в зависимости от канала и оборудования):

Как понять, на чьей стороне проблема

Сам по себе тест «пинг в покое против пинга под нагрузкой» показывает факт и масштаб проблемы, но не место её возникновения. Есть несколько практических приёмов сузить круг подозреваемых.

Повторите тест с разных точек. Если есть доступ ко второму серверу или VPS в другой сети, запустите ту же закачку с первого сервера на второй, одновременно измеряя ping между ними, и сравните с результатом теста «домашний канал — сервер». Если bufferbloat воспроизводится только когда одной из сторон выступает ваш домашний канал — проблема с высокой вероятностью в вашем роутере или модеме.

Проверьте, деградирует ли пинг до других адресов, а не только до сервера. Запустите закачку в сторону сервера, но параллельно пингуйте что-то ещё — например, публичный DNS-резолвер (1.1.1.1, 8.8.8.8). Если под нагрузкой деградирует пинг вообще ко всему — узкое место почти наверняка у вас, потому что весь исходящий трафик проходит через одно и то же локальное узкое место, прежде чем разойтись по разным маршрутам.

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

Держите в уме и промежуточные сети. Раздутый буфер теоретически может стоять на одном из транзитных узлов маршрута — но по опыту это редкий случай на магистральных сетях по сравнению с домашним оборудованием и оборудованием провайдера последней мили. Если оба конца при перекрёстных тестах выглядят чисто, а деградация всё равно воспроизводится на маршруте между ними, стоит смотреть в сторону промежуточной сети.

Что реально можно контролировать со стороны сервера и хостинга

Здесь стоит сказать честно: в подавляющем большинстве реальных случаев bufferbloat, который вы обнаружите тестом выше, окажется на стороне клиента — домашний роутер или модем провайдера последней мили, а не сервер. Дата-центровая инфраструктура и современные сетевые карты серверов в норме рассчитаны на большие объёмы трафика, и там грубый bufferbloat в духе «буфер на секунды трафика» — редкость по сравнению с бытовым оборудованием.

Но это не значит, что со стороны хостинга контролировать нечего. Есть два направления, где вклад в проблему реально возможен, если исходящие буфера сервера настроены небрежно или оставлены на дефолтных значениях, не соотнесённых с реальной ёмкостью канала.

Активное управление очередями (AQM) на исходящем канале сервера. Идея AQM (Active Queue Management) в общем виде та же, что и у домашнего SQM: вместо того чтобы позволять очереди на сетевом интерфейсе бесконтрольно расти, дисциплина управления очередью следит, сколько времени пакеты реально проводят в буфере, и начинает проактивно отбрасывать или помечать часть из них, когда задержка превышает разумный порог — тем самым возвращая отправителю (в том числе TCP-стеку самого сервера) сигнал «притормози», который иначе прячется в глубине буфера. На сервере это имеет смысл прежде всего тогда, когда он сам генерирует объёмный исходящий трафик — раздаёт большие файлы, гоняет бэкапы наружу, обслуживает media-стриминг — параллельно с интерактивным трафиком (SSH, API-ответы, VoIP-релей), который делит с ним один и тот же канал. Конкретный выбор дисциплины очереди и её параметров — вопрос вашей ОС, виртуализации и реальной нагрузки, и здесь намеренно не даётся универсальный рецепт команд: то, что подходит голому выделенному серверу с физической сетевой картой, может не подойти виртуальному интерфейсу на VPS, где буферизацией отчасти управляет ещё и гипервизор. Держите в голове саму идею — буфер должен быть управляемым, а не бесконечным — и разбирайтесь с реализацией под конкретную ОС и виртуализацию, а не копируйте чужую конфигурацию один в один.

Разумные размеры буферов сетевых интерфейсов. Отдельно от AQM стоит вопрос самого размера очереди на исходящем интерфейсе — на физическом сервере это параметры драйвера сетевой карты, на VPS — во многом то, что задано образом ОС и настройками виртуального адаптера. Слишком большой буфер «на всякий случай» без управляющего алгоритма поверх него — ровно та ситуация, которая и создаёт bufferbloat. Универсальной цифры здесь тоже нет: размер буфера имеет смысл соотносить с реальной пропускной способностью канала и профилем нагрузки конкретного сервера, а не выставлять «побольше» интуитивно.

Если на сервере уже есть конкуренция между объёмным фоновым трафиком и интерактивным пользовательским, а AQM кажется избыточно сложной темой для разового случая — часто быстрее решить проблему на уровне приоритизации и ограничения самого фонового трафика. Этот более практичный путь — traffic shaping конкретных инструментов — подробно разобран в статье «Шейпинг и приоритизация трафика на сервере»: там есть примеры с --bwlimit у rsync/curl и разведением задач по времени, которые снимают симптом bufferbloat со стороны сервера даже без погружения в AQM.

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