Per què una descàrrega per VPN pot superar la vostra connexió directa
Una transferència que s’accelera pel túnel sol assenyalar un límit en un port. Tres comparacions controlades separen un modelador d’una acceleració real.
Connecteu el túnel, inicieu una descàrrega gran i avança aproximadament al doble de velocitat que el mateix fitxer sense ell. Sona a publicitat, però pot ser un mesurament autèntic en una línia domèstica. La causa habitual és un límit de velocitat lligat a un port: el túnel porta la transferència on el modelador no mira, i la capacitat real de la línia es mostra per primera vegada.
La qual cosa significa que el número interessant no és com de ràpid anava la VPN. És quanta línia no vau arribar a tenir mai, i per què.
Un límit que segueix el port, no la ruta
Un proveïdor d’accés pot limitar el cabal per subscriptor segons el protocol o el port de destinació, i el port 80 és un objectiu preferit perquè molta navegació ordinària l’utilitza. Sovint el límit no s’aplica des del primer paquet: la transferència comença a prop de la velocitat de la línia, esgota un marge de ràfega i després s’assenta en la xifra limitada. Els primers segons semblen sans i la resta de la transferència no.
Envieu els mateixos bytes per un altre port i el modelador del 80 no els veu mai. El túnel sembla superar la connexió directa tot i que ha afegit un salt, xifratge i les seves pròpies despeses. El que ha millorat no és el camí sinó l’absència d’una regla.
També és per això que l’efecte és tan consistent entre fitxers i destinacions. Si el límit és al port, tot el que viatja per aquell port es comporta igual, sigui quin sigui el tamany del fitxer i qui sigui l’amfitrió. Una destinació que atrau una regla diferent mostra una corba diferent, i aquesta diferència és diagnòstica per si sola.
Mesureu el planell, no el pic
El pic és la part menys informativa d’una transferència, perquè tota connexió sembla bona mentre s’omplen els seus buffers. Anoteu on s’estabilitza la velocitat i quant de temps hi roman.
curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/
Executeu la parella seguida al mateix equip, a la mateixa hora, contra amfitrions en xarxes comparables. Una mostra no demostra res; la forma de la corba en dos intents de cadascun és el que distingeix un marge de ràfega d’un límit estable. Apunteu on s’aplana la velocitat i no què va mostrar el primer segon, perquè la ràfega és precisament el que us dona un modelador abans de començar a limitar. Un planell tranquil que aguanta la resta de la transferència és la xifra que cal comparar.
Manteniu el fitxer ja comprimit perquè la compressió de transport no es pugui oferir com a explicació. Un PDF o un arxiu elimina aquesta variable i també impedeix que algú argumenti que el túnel ha comprimit la càrrega. Si totes dues transferències fan servir el mateix fitxer, l’única diferència que queda és el camí i el port. Anoteu l’eina i el port al costat de cada xifra, o el segon intent no serà comparable amb el primer.
Tres comparacions que aïllen la causa
Feu-les en ordre i atureu-vos quan el patró sigui clar, perquè cadascuna descarta una història diferent.
- Repetiu la mateixa descàrrega pel camí web ordinari i per una eina de transferència en un altre port, des d’un amfitrió amb capacitat comparable.
- Repetiu les dues amb un fitxer incompressible, perquè la compressió deixi de ser candidata.
- Si vos mateix executeu el servidor del túnel, torneu-lo a lligar al port 80, ajusteu el perfil del client perquè els dos extrems coincideixin i transferiu de nou. Si ara el túnel se situa a la velocitat web limitada, la restricció segueix el port i no la VPN.
El tercer pas és el decisiu, i també és el que la gent s’estalvia perquè requereix un canvi de configuració. Sense ell heu demostrat que dues coses difereixen, no que el port sigui la raó.
Què no pot sostenir aquest mesurament
No demostra que el túnel sigui més ràpid en general, ni que comprimeixi res, ni que altres ports de la línia no tinguin restriccions. Descriu aquesta transferència, en aquesta línia, en aquesta hora. Els límits es poden aplicar per sessió, per subscriptor o segons l’hora del dia, i poden canviar sense avís.
Tampoc no demostra que el camí directe estigui trencat. Un camí limitat encara funciona; està limitat a propòsit, i una política deliberada no és una avaria esperant reparació.
I de cap manera no justifica encaminar-ho tot pel túnel. Cada aplicació al port 80 continua limitada, mentre que tot el que desvieu ara depèn d’un salt extra i d’una manera de fallar extra.
Convertiu la troballa en una cosa accionable
Escriviu l’observació com un mesurament i no com un veredicte: les transferències grans pel port 80 s’assenten prop de la meitat de la velocitat que el mateix fitxer assoleix en un altre port, en aquestes hores, en aquesta línia, amb aquestes mostres adjuntes. Això és una sol·licitud de suport que algú pot investigar.
«La VPN és més ràpida» no ho és. Convida a una resposta sobre el cost del xifratge, i aquesta resposta és tècnicament correcta mentre no diu res d’útil a ningú. Adjunteu el nombre de mostres, l’hora i el port, perquè qui llegeixi pugui reproduir el patró.
Si decidiu continuar fent servir un altre port per a transferències grans, anoteu l’advertència als vostres registres: moure un oient al port 80 xoca amb qualsevol servidor web ja lligat allà, i la fallada resultant sembla un túnel trencat més que un conflicte de ports.