Prečo je sťahovanie cez VPN obmedzené odosielaním zo servera

Klient ukazuje rýchle sťahovanie, server sedí na optickom pripojení a prenos sa napriek tomu vlečie. Číslo, ktoré ľudia porovnávajú, je zvyčajne to vytlačené v klientskom balíku, zatiaľ čo paket najprv prechádza odchádzajúcim prístupovým spojom servera. Ten spoj je rozpočet, do ktorého sa prenos musí zmestiť. Na malom domácom pripojení je to najmenšie číslo na ceste.

Číslo, ktoré ste si prečítali, bolo v nesprávnom smere

Sťahovanie k vzdialenému klientovi spotrebúva odosielaciu kapacitu na serverovom konci tunela. Inzerované rýchlosti sťahovania servera opisujú opačný smer a o tomto nehovoria nič. Rovnaká asymetria sa obracia, keď klient odosiela, a preto jeden smer môže pôsobiť dobre, kým druhý je nepoužiteľný.

Réžia zapuzdrenia a akákoľvek konkurenčná prevádzka spotrebúvajú časť toho istého rozpočtu. Ani jedno z toho nie je viditeľné v rýchlostnom teste, ktorý meria iba klienta.

Zapíšte cestu ako rozpočet

Vymenujte každú hranicu, ktorú paket musí prekročiť, a každej dajte číslo v tej istej jednotke. Doručenie zo zdroja, spracovanie na serveri, odosielací spoj servera, medziľahlá cesta, sťahovací spoj klienta aj spracovanie na klientovi platia všetky. Použiteľná rýchlosť je najmenšia z nich mínus réžia a žiadne ladenie nad týmto stropom výsledok nemení. Zapíšte zoznam pred meraním, pretože vám povie, ktorému číslu neveriť.

Pri odosielacom spoji servera 20 Mbit/s a sťahovacom spoji klienta 100 Mbit/s server obmedzí prenos dávno predtým, než si to klient všimne. Réžia a akýkoľvek súbežný prenos uberú ďalší diel a nasýtený odosielací spoj tiež zdržiava potvrdenia, čo spomalí prenos TCP pod hrubý strop. Ani jeden z týchto dvoch javov sa v porovnaní balíkov neobjaví.

Držte megabity a megabajty oddelene a hovorte, či každý údaj meria prevádzku šifrovaného spoja alebo aplikačnú užitočnú záťaž. Miešanie týchto dvoch je najčastejší dôvod, prečo sa rozpočet zdanlivo nesčíta. Označte každý údaj jeho jednotkou a miestom merania.

Kde vás doska skutočne stojí

Hneď ako je prístupový spoj dosť veľký, hardvér koncového bodu sa stane viditeľným, a až vtedy záleží na procesore. Určite model, usporiadanie rozhraní a použitú implementáciu. Pozorovanie o zdieľanej zbernici rannej dosky neopisuje každú neskoršiu revíziu.

Porovnávajte jednotlivé cesty spracovania, nie jeden priemer CPU. Mierne celkové zaťaženie môže skryť jedno nasýtené jadro, ktoré robí všetku prácu na paket, a takt procesora sa medzi návrhmi procesorov neprenáša ako skóre výkonu. Rýchlosť paketov je rovnako dôležitá ako priepustnosť, pretože malé pakety stoja viac na bajt než veľké. Merajte s veľkosťami paketov, ktoré vaša záťaž skutočne používa.

Tepelné a výkonové limity tiež rozhodujú o trvalom správaní. Krátky výbuch môže vyzerať skvele, kým sa desaťminútový prenos spomaľuje, a preto je benchmark na niekoľko sekúnd zlým vodidlom pre nočnú zálohu.

Pokyny výrobcu k výkonu rozdeľujú prístupovú šírku pásma, CPU, spracovanie paketov, transport a veľkosť paketu do samostatných obmedzení. Oplatí sa ich prečítať pred zmenou šifry, pretože zmena šifry málokedy pohne hranicou, ktorá nikdy nebola obmedzením.

Zmerajte, kým zmeníte šifru

Spustite smerový test, ktorý hlási rýchlosť skutočne dosiahnutú tunelom, potom spustite ten istý test na surovom rozhraní na porovnanie. Rozdiel medzi týmito dvoma číslami je cena tunela a menší z oboch stropov vám povie, na ktorú hranicu útočiť.

Zachovajte bezpečnostnú politiku nedotknutú, kým porovnávate. Starý výsledok získaný so slabou šifrou alebo pretaktovanou doskou nie je plánom pre súčasné nasadenie.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Uložte smerové výsledky vedľa pozorovaní koncového bodu z toho istého behu. Ďalšia zmena by mala cieliť na zmeraný strop, nie na komponent, ktorý na údajovom liste vyzerá najmenší.