Чому 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, проблеми з розміром пакета або один поганий шлях виходу. Налаштування черги, застосовані без вимірювання, лише переносять загадку.