Почему два теста скорости VPN в одном туннеле не совпадают

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

Новый адрес выхода меняет назначение теста

Большинство тестовых сайтов выбирают измерительный сервер автоматически, и отчасти по тому, откуда будто бы приходит ваше подключение. Включите туннель, и ваша видимая страна меняется, значит, выбранный сервер меняется, и сравнение теперь охватывает два разных маршрута к двум разным хостам.

Результат вовсе не является измерением VPN. Это измерение вашего пути к серверу, который вы не выбирали, и разницей между двумя прогонами может управлять пиринг этого сервера, а не что-либо, что сделал туннель.

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

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

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

Медленный старт заканчивается уже после окончания большинства коротких тестов

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

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

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

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

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

Один поток и шесть потоков измеряют разные вещи

Один TCP-поток ограничен окном, которое он удерживает в полёте, а это примерно время кругового обхода, умноженное на скорость. На длинном маршруте это произведение превышает то, что использует один поток, поэтому одна загрузка занижает существующую пропускную способность. Шесть параллельных потоков закрывают этот зазор и дают большее число.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Оба числа верны. Число одного потока говорит, что сделает одна загрузка, а это обычно получает вкладка браузера. Параллельное число говорит, что маршрут может нести в целом, и это может использовать торрент или многочастная загрузка. Цитировать одно как другое — это способ без причины заменить здоровый туннель.

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

Шифрование стоит времени процессора, инкапсуляция стоит байтов

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

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

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

Эти три часто путают, потому что пользователи описывают их все как медленный VPN. Только первый реагирует на более мощную машину, только второй на меньший MTU, и только третий на управление очередями.

Запишите метод в протокол

Результат, который стоит сохранить, называет устройство, сеть доступа, выход, измерительный сервер, направление, число потоков и длительность. Без этого два числа нельзя сравнить, а заявка с одним числом на самом деле настроение.

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

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