Una transferència que s'arrossega per la connexió de l'oficina de vegades s'acaba de pressa a través del túnel, i l'encapsulament extra fa que això sembli impossible. La paradoxa aparent ve de comparar les coses equivocades. El túnel afegeix feina, i també canvia quin camí de xarxa segueix el trànsit, quina adreça veu la destinació i de vegades quin servidor respon. Decidir entre les dues rutes requereix separar aquests tres efectes abans de qualsevol conclusió sobre la velocitat.

Tres coses que el túnel pot canviar

La primera és el trànsit. L'encaminament d'Internet segueix la política de l'operador i les relacions comercials, no la latència mesurada, així que el camí a través d'un proveïdor de VPN pot travessar xarxes diferents de la ruta directa. Pot evitar un intercanvi congestionat o arribar a un de millor peering, i igual de fàcilment pot ser pitjor.

La segona és la destinació. Un canvi d'adreça de sortida sovint canvia la resposta DNS, i una xarxa de continguts et pot donar una altra memòria cau o una altra regió. Llavors part de la millora pertany al servidor nou i no al túnel. El mateix nom d'amfitrió pot anar a un servidor més proper o menys carregat sense que canviï res al client.

La tercera és el comportament del transport. L'encapsulament canvia la mida efectiva del paquet, i un túnel que evita un segment mitjà amb pèrdues pot deixar que un flux TCP faci créixer la seva finestra en lloc de retrocedir una i una altra vegada. Cap d'aquestes coses no és un mecanisme universal d'acceleració; cadascuna és una condició que cal observar. Separar-les és el que converteix una curiositat en un fet.

Què no pot canviar

Res del túnel no afegeix capacitat a l'enllaç entre el dispositiu i la xarxa. Un canal Wi-Fi saturat, una última milla congestionada o un pla mòbil limitat limiten les dues rutes de la mateixa manera, i una prova de velocitat a través del túnel no pot superar aquest sostre. El mateix enllaç transporta els paquets encapsulats, així que l'encapsulament pot gastar capacitat però mai no la crea. El que canvia és on van els paquets després de sortir d'aquell enllaç. Per això un resultat ràpid del túnel sempre té una explicació aigües amunt del primer salt.

Els límits del costat del servidor són igual d'indiferents. Si l'amfitrió remot serveix a poc a poc, un camí millor només lliura la resposta lenta amb més eficiència, i l'usuari encara espera. Un origen compartit sota càrrega es veu lent per les dues rutes en el mateix moment.

Compareu els camins correctament

Mantingueu l'aplicació, la direcció, la durada i la concurrència idèntiques, i canvieu només el camí. Executeu cada prova més d'una vegada, a la mateixa hora del dia, i anoteu l'adreça de sortida i la resposta del resolutor al costat del rendiment. Una execució és una mostra i no un mesurament, i una baixada ràpida pot ser un encert de memòria cau que no diu res sobre la ruta. Escriviu les condicions abans dels resultats, perquè després els números són difícils d'interpretar.

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

La resposta del resolutor és el detall que la majoria de comparacions ometen, i explica les “millores” que desapareixen quan es força el mateix servidor. Si l'adreça difereix entre execucions, la prova ha comparat dues destinacions i no dos camins. Informeu de la latència i la pèrdua al costat del rendiment, perquè un camí que és més ràpid en conjunt però afegeix retard a cada petició interactiva no és millor per a la càrrega de treball que es va queixar. El temps d'anada i tornada importa més que la velocitat massiva per a qualsevol cosa que pregunta i espera.

Quan la diferència val la pena de conservar

Si un túnel aprovat millora de manera fiable una càrrega de treball concreta, és una elecció operativa legítima: documenteu la càrrega, el mesurament i la sortida utilitzada. Un registre útil anomena un sol amfitrió, l'adreça de sortida que el túnel va produir, la resposta del resolutor i les mateixes xifres del camí directe el mateix dia. Això és suficient perquè el següent enginyer repeteixi la comparació en lloc de tornar-la a discutir. Encara no és prova que el proveïdor limiti res, i no es trasllada a altres aplicacions ni a altres hores.

Guardeu el registre del mesurament amb la configuració. Respon la pregunta següent sobre si la millora encara existeix, que és l'única manera de saber si va canviar el camí o la càrrega de treball. Un registre sense data no pot respondre aquesta pregunta de cap manera.

Articles relacionats