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

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

То есть интересное число — не то, насколько быстрым был VPN. А то, сколько своей линии вы никогда не получали, и почему.

Ограничение, которое следует за портом, а не за маршрутом

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

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

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

Измеряйте плато, а не пик

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

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

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

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

Три сравнения, которые изолируют причину

Пройдите их по порядку и остановитесь, как только картина станет ясной, потому что каждое исключает свою историю.

1. Повторите то же скачивание обычным веб-путём и инструментом передачи на другом порту, с узла сопоставимой ёмкости.
2. Повторите оба с несжимаемым файлом, чтобы сжатие перестало быть кандидатом.
3. Если вы сами управляете сервером туннеля, перепривяжите его к порту 80, поправьте профиль клиента, чтобы оба конца договорились, и передайте снова. Если туннель теперь стоит на ограниченной веб-скорости, ограничение следует за портом, а не за VPN.

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

Чего это измерение не может подтвердить

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

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

И уж точно не оправдывает маршрутизацию всего через туннель. Каждое приложение на порту 80 остаётся ограниченным, а всё, что вы перенаправите, теперь зависит от лишнего перехода и лишнего режима отказа.

Превратите находку в нечто выполнимое

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

«VPN быстрее» — это не так. Это приглашает ответ про накладные расходы шифрования, и такой ответ технически верен, но никому не сообщает ничего полезного. Приложите число проб, час и порт, чтобы читатель мог воспроизвести картину.

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