Uploadul prin VPN mai lent decât descărcarea? Stabiliți ce limită întâlniți

Majoritatea liniilor de acces sunt asimetrice, așa că un tunel încarcă de obicei mai lent decât descarcă, iar acesta este răspunsul așteptat, nu o defecțiune. Întrebarea interesantă este dacă uploadul este limitat de linie, de altceva ce o folosește deja sau de un flux care se blochează în loc să curgă constant. Aceste trei produc aceeași plângere și necesită muncă diferită.

Trei limite care arată identic din bara de progres

Capacitatea este prima și este o proprietate a produsului de acces, nu a tunelului. Un uplink de câțiva megabiți este normal pe fibră rezidențială și pe multe abonamente mobile, iar costul criptării este mic față de această diferență. Encapsularea adaugă și ea octeți la fiecare pachet, ceea ce reduce debitul util în ambele direcții și nu doar într-una, așa că singură nu poate explica o asimetrie mare.

Contenția este a doua. Sincronizarea în cloud, bibliotecile foto și agenții de actualizare încarcă în timp ce mașina pare inactivă, iar un al doilea dispozitiv pe aceeași linie face la fel. Coada este a treia: un uplink saturat împinge traficul interactiv în spatele datelor masive, așa că apelurile cad în timp ce transferul în sine raportează un progres sănătos.

Măsurați o singură direcție o dată

Folosiți același dispozitiv, același profil și aceeași destinație și nu rulați niciodată ambele direcții simultan, decât dacă contenția este exact ceea ce doriți să observați. Întrerupeți-vă propriile transferuri opționale înainte de prima rulare. Două rulări cu un comutator între ele rezolvă cea mai mare parte.

iperf3 trimite de la client în mod implicit, așa că rularea simplă măsoară calea de upload; -R inversează direcția și măsoară descărcarea. Rulați-le la câteva minute distanță și notați ambele numere în loc să faceți media:

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

Dacă numărul de upload este o fracțiune mică din cel de descărcare și rămâne stabil între rulări, forma corespunde unei linii de acces asimetrice și tunelul nu este povestea. Dacă uploadul oscilează între rulări sau se prăbușește după zece secunde, continuați să citiți.

Decideți după locul în care se schimbă uploadul

Schimbați o variabilă o dată și urmăriți care direcție se mișcă. Un al doilea punct final VPN care încarcă mai bine indică acel punct sau ruta spre el. Același upload lent de la un al doilea dispozitiv pe aceeași linie indică linia. Un alt dispozitiv pe altă linie, care este și el lent, indică politica de intrare a destinației, pe care nu o puteți remedia local.

Notați octeții pe secundă și timpul scurs pentru aceeași încărcare, nu un singur scor de viteză. Un client de backup și un test de viteză folosesc destinații și concurență diferite, așa că compararea numerelor lor nu răspunde la nimic. Dacă cererile mici sunt în regulă și doar transferurile mari se târăsc, limita probabil nu este deloc lățimea de bandă.

Pentru utilizarea zilnică, limitarea unui upload din fundal sau programarea lui în afara orelor de ședințe ajută adesea mai mult decât orice setare a tunelului. Judecați această schimbare după încărcarea combinată: un backup care se termină mai târziu dar nu mai strică apelurile este de obicei schimbul mai bun.

Când blocarea învinge lentoarea

Un transfer care îngheață într-un punct repetabil și apoi continuă se comportă ca o problemă de MTU a căii, nu ca o limită de viteză. Tunelul reduce încărcătura utilă pe pachet, iar un dispozitiv care aruncă mesajul ICMP rezultat lasă expeditorul să ghicească. Acel model merită propriul test, pentru că repararea diferă de reglarea unei viteze. Un număr mic și stabil indică capacitatea, în timp ce o explozie urmată de liniște indică o încărcătură pe care calea nu o poate duce.

Testați calea cu o încărcătură care nu trebuie fragmentată, apoi comparați MTU-ul interfeței tunelului cu valoarea care trece:

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

Dacă sonda mare dispare în timp ce una mică reușește, strângeți TCP MSS pe tunel în loc să coborâți MTU-ul interfeței pentru fiecare protocol. Blocajele persistente după acel punct aparțin stocării sau ritmului aplicației receptoare, nu căii de rețea.

Ce să schimbați și ce să lăsați

Schimbați lucrurile pe care le controlați: programele transferurilor din fundal, alegerea punctului final și MSS pentru o cale care se blochează. Păstrați fiecare schimbare reversibilă și limitată la o singură încărcare. Lăsați în pace lucrurile despre care măsurătoarea spune că sunt în regulă, inclusiv o viteză de descărcare care se potrivește deja cu linia.

Notați numerele înainte și după împreună cu profilul, punctul final și ora din zi, pentru că o problemă de upload care se mută cu punctul final este o chestiune de rutare, iar una care se mută cu dispozitivul este locală. Acel registru este ceea ce transformă o plângere vagă într-o decizie și costă două rulări ale aceleiași comenzi.