Prenos, ki se na pisarniški povezavi komaj premika, se skozi tunel včasih konča hitro, dodatno kapsuliranje pa naredi, da to izgleda nemogoče. Navidezni paradoks izhaja iz primerjanja napačnih stvari. Tunel doda delo in tudi spremeni po kateri omrežni poti gre promet, kateri naslov vidi cilj in včasih tudi, kateri strežnik sploh odgovori. Odločitev med obema potema zahteva, da te tri učinke ločimo pred kakršnim koli sklepom o hitrosti.

Tri stvari, ki jih tunel lahko spremeni

Prva je tranzit. Usmerjanje v internetu sledi politiki operaterja in poslovnim odnosom, ne izmerjeni zakasnitvi, zato lahko pot skozi ponudnika VPN prečka druga omrežja kot neposredna pot. Lahko se izogne preobremenjeni točki izmenjave ali pristane na tisti z boljšim peeringom, in prav tako zlahka je lahko slabše.

Druga je cilj. Sprememba izhodnega naslova pogosto spremeni odgovor DNS, omrežje vsebin pa vam lahko da drugo predpomnilnik ali regijo. Del izboljšanja potem pripada novemu strežniku, ne tunelu. Isto ime gostitelja lahko pristane na bližjem ali manj obremenjenem strežniku, ne da bi se na odjemalcu karkoli spremenilo.

Tretja je vedenje prenosa. Kapsuliranje spremeni dejansko velikost paketa, in tunel, ki se izogne izgubnemu vmesnemu odseku, lahko toku TCP dovoli povečati okno, namesto da bi se večkrat umaknil. Nobena od teh ni univerzalni mehanizem pospeševanja; vsaka je pogoj, ki ga je treba opazovati. Prav njihova ločitev spremeni zanimivost v dejstvo.

Česa ne more spremeniti

Nič v tunelu ne doda zmogljivosti povezavi med napravo in omrežjem. Nasičen kanal Wi-Fi, preobremenjena zadnja milja ali omejen mobilni paket omejujejo obe poti enako, in preizkus hitrosti skozi tunel ne more preseči te meje. Ista povezava nosi kapsulirane pakete, zato lahko kapsuliranje porablja zmogljivost, nikoli pa je ne ustvari. Spremeni se to, kam gredo paketi po tem, ko to povezavo zapustijo. Zato ima hiter rezultat tunela vedno razlago nad prvim skokom.

Omejitve na strani strežnika so enako brezbrižne. Če oddaljeni gostitelj streže počasi, boljša pot le učinkoviteje dostavi počasen odgovor, uporabnik pa še vedno čaka. Skupni vir pod obremenitvijo je v istem trenutku videti počasen na obeh poteh.

Primerjajte poti pravilno

Ohranite aplikacijo, smer, trajanje in sočasnost enake ter spreminjajte samo pot. Zaženite vsak preizkus več kot enkrat, ob istem času dneva, in zapišite izhodni naslov ter odgovor razreševalnika ob prepustnosti. Ena izvedba je vzorec in ne meritev, en sam hiter prenos pa je lahko zadetek v predpomnilniku, ki o poti ne pove nič. Zapišite pogoje pred rezultati, ker je številke pozneje težko razlagati.

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

Odgovor razreševalnika je podrobnost, ki jo večina primerjav izpusti, in pojasni „izboljšanja“, ki izginejo, ko vsilimo isti strežnik. Če se naslov med izvedbami razlikuje, je preizkus primerjal dva cilja in ne dveh poti. Navedite zakasnitev in izgubo ob prepustnosti, ker pot, ki je skupno hitrejša, a vsaki interaktivni zahtevi doda zamik, ni boljša za obremenitev, ki se je pritožila. Čas povratne poti je pomembnejši od množične hitrosti za vse, kar vpraša in čaka.

Kdaj je razliko vredno obdržati

Če odobren tunel zanesljivo izboljša določeno obremenitev, je to zakonita obratovalna izbira: dokumentirajte obremenitev, meritev in uporabljeni izhod. Uporaben zapis navede enega gostitelja, izhodni naslov, ki ga je ustvaril tunel, odgovor razreševalnika in iste številke z neposredne poti istega dne. To zadostuje, da naslednji inženir primerjavo ponovi, namesto da bi jo znova razpravljal. To še vedno ni dokaz, da ponudnik kaj omejuje, in se ne prenaša na druge aplikacije ali druge ure.

Hranite zapis meritve skupaj s konfiguracijo. Odgovori na naslednje vprašanje, ali izboljšanje še obstaja, in to je edini način, da ugotovite, ali se je spremenila pot ali obremenitev. Zapis brez datuma na to vprašanje ne more odgovoriti sploh.

Sorodni članki