Может ли VPN быть быстрее прямого подключения?

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

Три вещи, которые туннель может изменить

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

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

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

Чего он изменить не может

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

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

Сравнивайте пути правильно

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

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

Ответ резолвера — та деталь, которую большинство сравнений опускает, и он объясняет «улучшения», исчезающие при принудительном выборе того же сервера. Если адрес различается между запусками, тест сравнил два назначения, а не два пути. Сообщайте задержку и потери рядом с пропускной способностью, потому что путь, более быстрый в целом, но добавляющий задержку каждому интерактивному запросу, не лучше для той нагрузки, которая жаловалась. Время кругового обхода важнее массовой скорости для всего, что спрашивает и ждёт.

Когда разницу стоит сохранить

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

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