Защо два теста за скорост на 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, и само третото реагира на управление на опашките.

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

Резултат, който си заслужава да се запази, назовава устройството, мрежата за достъп, изхода, измервателния сървър, посоката, броя потоци и продължителността. Без тях две числа не могат да се сравнят, а тикет с едно число всъщност е настроение.

Пазете и лошите пускания. Серия, в която един изход всеки път дава застой, е много по-информативна от средна стойност, а застоите са точно това, което средните стойности скриват.

После тествайте нещото, което наистина ви интересува. Ако целта е голямо изтегляне, изтеглете файла. Ако целта е разговор, измервайте латентност под натоварване, а не пропускателна способност в покой, защото един тунел може да се представи добре в тест за скорост и пак да направи всяка среща нечуваема.