Почему VPN кажется медленным при загрузке: задержка в очереди

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

Пропускная способность и задержка — разные измерения

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

Обратите внимание и на направление под нагрузкой. Полный буфер загрузки может задерживать всё остальное, пока пропускная способность скачивания простаивает.

Измерьте время кругового обхода под нагрузкой

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

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

Первая команда снимает выборки времени кругового обхода, а вторая создаёт устойчивую загрузку без службы теста скорости. Базовая линия, которая остаётся ровной, а затем нагруженный прогон, поднимающийся на сотни миллисекунд, — вот искомый признак. Некоторые сети снижают приоритет ICMP, поэтому считайте ping подсказкой и подтверждайте собственным индикатором задержки приложения. Держите тест коротким на лимитированных каналах, потому что воспроизводимый контраст важнее долгого насыщения.

Перенесите очередь туда, где узкое место

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

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

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

Что меняет туннель и что он скрывает

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

Если задержка не следует за нагрузкой, перестаньте настраивать очереди и посмотрите в другое место: условия Wi-Fi, проблемы с размером пакета или один плохой путь выхода. Настройки очереди, применённые без измерения, лишь переносят загадку.