Почему загрузка через VPN ограничена отдачей сервера

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

Число, которое вы прочитали, было не в том направлении

Загрузка к удалённому клиенту расходует пропускную способность на отдачу на серверном конце туннеля. Заявленные скорости загрузки сервера описывают противоположное направление и ничего не говорят об этом. Та же асимметрия переворачивается, когда клиент отдаёт, поэтому одно направление может казаться нормальным, пока другое непригодно.

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

Запишите путь как бюджет

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

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

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

Где плата действительно обходится вам дорого

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

Сравнивайте отдельные пути обработки, а не одно среднее по CPU. Умеренная общая нагрузка может скрывать одно насыщенное ядро, выполняющее всю работу на пакет, а тактовая частота не переносится между конструкциями процессоров как оценка производительности. Скорость пакетов важна так же, как пропускная способность, потому что маленькие пакеты стоят дороже за байт, чем большие. Измеряйте с теми размерами пакетов, которые ваша нагрузка действительно использует.

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

Рекомендации производителя по производительности разделяют пропускную способность доступа, CPU, обработку пакетов, транспорт и размер пакета на отдельные ограничения. Их стоит прочитать перед сменой шифра, потому что смена шифра редко сдвигает границу, которая никогда не была ограничением.

Измерьте, прежде чем менять шифр

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

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

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Храните направленные результаты рядом с наблюдениями конечной точки из того же запуска. Следующее изменение должно нацеливаться на измеренный потолок, а не на компонент, который выглядит наименьшим в спецификации.