Прикачувањето преку VPN е побавно од преземањето? Утврдете на која граница удирате

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

Три граници што изгледаат исто од лентата за напредок

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

Конкуренцијата е втората. Облачната синхронизација, фото библиотеките и агентите за ажурирање прикачуваат додека машината изгледа неактивна, а втор уред на истата линија го прави истото. Редот е третиот: заситен нагорен тек го турка интерактивниот сообраќај зад масивните податоци, па повиците се прекинуваат додека самиот пренос известува за здравиот напредок.

Мерете еден правец истовремено

Користете го истиот уред, истиот профил и истата дестинација, и никогаш не пуштајте ги двата правци истовремено, освен ако конкуренцијата не е токму тоа што сакате да го набљудувате. Паузирајте ги сопствените опционални преноси пред првото пуштање. Две пуштања со едно знаме меѓу нив го решаваат најголемиот дел.

iperf3 стандардно праќа од клиентот, па обичното пуштање го мери вашиот нагорен пат; -R ја превртува насоката и го мери преземањето. Пуштете ги со неколку минути разлика и забележете ги двата броја наместо да ги просечите:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

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

Одлучете според тоа каде се менува прикачувањето

Менувајте една променлива истовремено и гледајте кој правец се движи. Втора крајна точка на VPN што прикачува подобро укажува на таа точка или на рутата до неа. Истото бавно прикачување од втор уред на истата линија укажува на линијата. Друг уред на друга линија што е исто така бавен укажува на влезната политика на дестинацијата, која не можете да ја поправите локално.

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

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

Кога заглавеноста ја победува бавноста

Преносот што замрзнува на повторлива точка и потоа продолжува се однесува како проблем со MTU на патеката, а не како ограничување на брзината. Тунелот ја намалува употребливата носивост на пакет, а уредот што го отфрла добиеното ICMP порака го остава праќачот да погодува. Таа шема заслужува сопствен тест, бидејќи поправката се разликува од прилагодувањето на брзина. Стабилно низок број укажува на капацитет, додека изблик проследен со тишина укажува на носивост што патеката не може да ја носи.

Тестирајте ја патеката со носивост што не смее да се фрагментира, потоа споредете го MTU на интерфејсот на тунелот со вредноста што поминува:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Ако големата проба исчезне додека помала успее, стегнете го TCP MSS на тунелот наместо да го намалувате MTU на интерфејсот за секој протокол. Трајните заглавувања по таа точка и припаѓаат на складирањето или темпото на апликацијата што прима, а не на мрежната патека.

Што да смените и што да оставите

Сменете ги работите што ги контролирате: распоредите за позадински преноси, изборот на крајна точка и MSS за патека што се заглавува. Држете ја секоја промена повратна и ограничена на едно работно оптоварување. Оставете ги на мира работите за кои мерењето вели дека се во ред, вклучително и брзината на преземање што веќе одговара на линијата.

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