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

Запишете го методот во записот

Резултат што вреди да се сочува го именува уредот, пристапната мрежа, излезот, мерниот сервер, насоката, бројот на текови и времетраењето. Без нив две бројки не можат да се споредат, а тикет што содржи една бројка е всушност расположение.

Чувајте ги и лошите извршувања. Серија во која еден излез секој пат предизвикува застој е далеку поинформативна од просек, а застоите се токму она што просеците го кријат.

Потоа тестирајте го она што навистина ви е важно. Ако целта е големо преземање, преземете ја датотеката. Ако целта е повик, мерете доцнење под оптоварување, а не пропусност во мирување, затоа што тунелот може добро да помине на тест за брзина и сепак да ја направи секоја средба нечујна.