Kin in VPN flugger wêze as de direkte ferbining?

In oerdracht dy't op 'e kantoarferbining krûpt, einiget soms fluch troch de tunnel, en de ekstra ynkapseling lit dat ûnmooglik lykje. De skynbere paradoks komt fan it fergelykjen fan 'e ferkearde dingen. De tunnel foeget wurk ta, en feroaret ek hokker netwurkpaad it ferkear folget, hokker adres de bestimming sjocht en soms hokker tsjinner oft der antwurdet. In beslút tusken de twa rûtes freget om dy trije effekten te skieden foar elke konklúzje oer snelheid.

Trije dingen dy't de tunnel feroarje kin

It earste is transit. Ynternet-routing folget belied fan 'e operator en saaklike relaasjes, net mjitten latency, dus it paad fia in VPN-oanbieder kin oare netwurken kruse as de direkte rûte. It kin in oerlêstich útwikselpunt mije of op ien mei better peering lâne, en it kin like maklik minner wêze.

It twadde is de bestimming. In feroaring fan útgeand adres feroaret faak it DNS-antwurd, en in ynhâldnetwurk kin jo in oare cache of regio jaan. In part fan 'e ferbettering heart dan ta de nije tsjinner ynstee fan de tunnel. Deselde hostnamme kin op in tichterby of minder belêste tsjinner lâne sûnder dat der oan 'e klant wat feroaret.

It trêde is transportehearhing. Ynkapseling feroaret de effektive pakketgrutte, en in tunnel dy't in ferliesrike midsegmint mije, kin in TCP-stream syn finster groeie litte ynstee fan hieltiten werom te fallen. Gjin fan dizze is in universeel fersnellingsmeganisme; elk is in betingst dy't waarnommen wurde moat. It skieden derfan is wat nijsgjirrigens ta feit makket.

Wat it net feroarje kin

Neat yn 'e tunnel foeget kapasiteit ta oan 'e skeakel tusken it apparaat en it netwurk. In fersêde Wi-Fi-kanaal, in oerlêste lêste myl of in beheind mobyl abonnemint beheine beide paden itselde, en in snelheidstest troch de tunnel kin dat plafon net oertreffe. Deselde skeakel draacht de ynkapsele pakketten, dus ynkapseling kin kapasiteit ferbrûke mar nea meitsje. Wat feroaret is wêr't de pakketten geane nei't se dy skeakel ferlitten. Dêrom hat in fluch tunnelresultaat altyd in ferklearring boppe de earste hop.

Grinszen oan 'e tsjinnerskant binne like ûnferskillich. As de fiere host stadich tsjinnet, leveret in better paad allinnich it stadige antwurd effisjinter, en de brûker wachtet noch. In dielde oarsprong ûnder lêst liket op itselde momint op beide paden stadich.

Fergelykje de paden goed

Hâld de applikaasje, rjochting, doer en paralleliteit identyk, en feroarje allinnich it paad. Rin elk test mear as ien kear, op itselde tiidstip fan 'e dei, en notearje it útgeande adres en it antwurd fan 'e resolvers njonken de trochfier. Ien run is in stekproef en gjin mjitting, en ien flugge download kin in cache-treffer wêze dy't neat oer de rûte seit. Skriuw de betingsten foar de resultaten del, want de sifers binne letter min te ynterpretearjen.

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

It antwurd fan 'e resolvers is it detail dat de measte fergelikingen weilitte, en it ferklearret de “ferbetterings” dy't ferdwine as deselde tsjinner twongen wurdt. As it adres tusken runs ferskilt, hat de test twa bestimmingen fergelike ynstee fan twa paden. Rapportearje latency en ferlies njonken de trochfier, want in paad dat yn totaal flugger is mar oan elk ynteraktyf fersyk fertraging taheakket is net better foar de wurklêst dy't klage. Omgongstiid is wichtiger as massale snelheid foar alles wat freget en wachtet.

Wannear't it ferskil it wurdich is om te hâlden

As in goedkarde tunnel in spesifike wurklêst betrouber ferbetteret, is dat in legitime operasjonele kar: dokumintearje de wurklêst, de mjitting en de brûkte útgong. In brûkber record neamt ien host, it útgeande adres dat de tunnel oplevere, it antwurd fan 'e resolvers, en deselde sifers fan it direkte paad op deselde dei. Dat is genôch foar de folgjende yngenieur om de fergeliking te werheljen ynstee fan it op 'e nij te bepraten. It is noch altyd gjin bewiis dat de oanbieder eat beheint, en it draacht net oer op oare applikaasjes of oare oeren.

Bewarje it mjittingsrecord by de konfiguraasje. It beantwurdet de folgjende fraach oft de ferbettering noch bestiet, en dat is de iennichste manier om te witten oft it paad of de wurklêst feroare is. In record sûnder datum kin dy fraach hielendal net beantwurdzje.