De ce o descărcare prin VPN poate învinge conexiunea directă

Conectați tunelul, porniți o descărcare mare și veți vedea că merge cu aproximativ dublul vitezei pe care același fișier o atingea fără el. Sună ca reclamă, dar poate fi o măsurătoare reală pe o linie de acasă. Cauza obișnuită este o limită de viteză legată de un singur port: tunelul duce transferul acolo unde modelatorul nu se uită, iar capacitatea reală a liniei apare pentru prima dată.

Ceea ce înseamnă că numărul interesant nu este cât de rapid a fost VPN-ul. Ci cât din linia dumneavoastră nu primeați niciodată, și de ce.

O limită care urmează portul, nu ruta

Un furnizor de acces poate limita debitul pe abonat după protocol sau port de destinație, iar portul 80 este o țintă preferată pentru că o mare parte din navigarea obișnuită îl folosește. Limita nu se aplică adesea de la primul pachet: transferul începe aproape de viteza liniei, consumă o cotă de rafală și apoi se așază la valoarea limitată. Primele secunde par sănătoase, restul transferului nu.

Trimiteți aceiași octeți pe alt port și modelatorul de pe 80 nu îi vede niciodată. Tunelul pare să învingă conexiunea directă deși a adăugat un salt, criptare și propriile costuri. Nu s-a îmbunătățit ruta, ci absența unei reguli.

De aceea efectul este atât de constant între fișiere și destinații. Dacă limita este pe port, tot ce trece prin acel port se comportă la fel, oricare ar fi dimensiunea fișierului și oricine ar fi gazda. O destinație care atrage altă regulă arată altă curbă, iar acea diferență este diagnostică în sine.

Măsurați platoul, nu vârful

Vârful este partea cea mai puțin informativă a unui transfer, pentru că fiecare conexiune arată bine cât timp i se umplu bufferele. Notați unde se așază viteza și cât rămâne acolo.

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

Rulați perechea unul după altul pe aceeași mașină, la aceeași oră, către gazde din rețele comparabile. O singură probă nu dovedește nimic; forma curbei pe două rulări ale fiecăruia este ce distinge o cotă de rafală de o limită stabilă. Notați unde viteza se aplatizează, nu ce a arătat prima secundă, pentru că rafala este exact ce vă dă un modelator înainte de a începe să limiteze. Un platou calm care rezistă până la finalul transferului este numărul de comparat.

Țineți fișierul deja comprimat ca să nu poată fi oferită compresia de transport drept explicație. Un PDF sau o arhivă elimină acea variabilă și împiedică pe oricine să susțină că tunelul a comprimat conținutul. Dacă ambele transferuri folosesc același fișier, singura diferență rămasă este ruta și portul. Notați unealta și portul lângă fiecare cifră, altfel a doua rulare nu este comparabilă cu prima.

Trei comparații care izolează cauza

Parcurgeți-le în ordine și opriți-vă imediat ce modelul este clar, pentru că fiecare exclude altă poveste.

1. Repetați aceeași descărcare pe calea web obișnuită și printr-o unealtă de transfer pe alt port, de pe o gazdă cu capacitate comparabilă.
2. Repetați ambele cu un fișier necomprimabil, pentru ca compresia să înceteze a fi candidat.
3. Dacă administrați singuri serverul tunelului, legați-l din nou la portul 80, ajustați profilul clientului ca ambele capete să fie de acord și transferați din nou. Dacă tunelul stă acum la viteza web limitată, restricția urmează portul, nu VPN-ul.

Al treilea pas este cel decisiv și este și cel pe care oamenii îl sar pentru că cere o modificare de configurație. Fără el ați arătat că două lucruri diferă, nu că portul este cauza.

Ce nu poate susține această măsurătoare

Nu arată că tunelul este mai rapid în general, că ar comprima ceva sau că alte porturi de pe linie sunt nelimitate. Descrie acest transfer, pe această linie, la această oră. Limitele pot fi aplicate pe sesiune, pe abonat sau după ora din zi, și se pot schimba fără anunț.

Nici nu dovedește că ruta directă este stricată. O rută limitată funcționează în continuare; este limitată intenționat, iar o politică deliberată nu este o defecțiune care așteaptă reparare.

Și cu siguranță nu justifică dirijarea tuturor lucrurilor prin tunel. Fiecare aplicație de pe portul 80 rămâne limitată, în timp ce tot ce deviați depinde acum de un salt în plus și de un mod de eșec în plus.

Transformați constatarea în ceva aplicabil

Scrieți observația ca măsurătoare și nu ca verdict: transferurile mari pe portul 80 se așază aproape de jumătatea vitezei pe care același fișier o atinge pe alt port, la aceste ore, pe această linie, cu aceste probe atașate. Aceasta este o cerere de suport pe care cineva o poate investiga.

«VPN-ul este mai rapid» nu este. Invită un răspuns despre costul criptării, iar acel răspuns este corect tehnic în timp ce nu spune nimănui nimic util. Atașați numărul de probe, ora și portul, ca cititorul să poată reproduce modelul.

Dacă decideți să continuați să folosiți alt port pentru transferuri mari, notați rezerva în propriile evidențe: mutarea unui ascultător pe portul 80 intră în conflict cu orice server web deja legat acolo, iar defecțiunea rezultată arată ca un tunel stricat, nu ca un conflict de porturi.