Proč je stahování přes VPN omezeno odesíláním ze serveru

Klient ukazuje rychlé stahování, server sedí na optickém připojení a přenos přesto leze. Číslo, které lidé srovnávají, je obvykle to vytištěné v klientském tarifu, zatímco paket nejdřív projde odchozím přístupovým spojem serveru. Ten spoj je rozpočet, do kterého se přenos musí vejít. Na malém domácím připojení je to nejmenší číslo na cestě.

Číslo, které jste si přečetli, bylo ve špatném směru

Stahování k vzdálenému klientovi spotřebovává odesílací kapacitu na serverovém konci tunelu. Inzerované serverové rychlosti stahování popisují opačný směr a o tomto neříkají nic. Stejná asymetrie se obrací, když klient odesílá, a proto jeden směr může působit dobře, zatímco druhý je nepoužitelný.

Režie zapouzdření a jakýkoli konkurenční provoz spotřebovávají část stejného rozpočtu. Ani jedno není vidět v rychlostním testu, který měří jen klienta.

Zapište cestu jako rozpočet

Vyjmenujte každou hranici, kterou paket musí překonat, a každé dejte číslo ve stejné jednotce. Doručení od zdroje, zpracování na serveru, odesílací spoj serveru, mezilehlá cesta, stahovací spoj klienta i zpracování na klientovi platí všechny. Použitelná rychlost je nejmenší z nich mínus režie a žádné ladění nad tímto stropem výsledek nemění. Zapište seznam před měřením, protože vám řekne, kterému číslu nevěřit.

Při odesílacím spoji serveru 20 Mbit/s a stahovacím spoji klienta 100 Mbit/s server omezí přenos dávno předtím, než si toho klient všimne. Režie a jakýkoli souběžný přenos ukrojí další díl a nasycený odesílací spoj také zpožďuje potvrzení, což zpomalí přenos TCP pod hrubý strop. Ani jeden z těchto dvou jevů se v porovnání tarifů neobjeví.

Držte megabity a megabajty odděleně a říkejte, zda každý údaj měří provoz šifrovaného spoje, nebo aplikační užitečné zatížení. Míchání těchto dvou je nejčastější důvod, proč se rozpočet zdánlivě nesečte. Označte každý údaj jednotkou a místem měření.

Kde vás deska skutečně stojí

Jakmile je přístupový spoj dost velký, hardware koncového bodu se stane viditelným, a teprve tehdy záleží na procesoru. Určete model, uspořádání rozhraní a použitou implementaci. Pozorování o sdílené sběrnici rané desky nepopisuje každou pozdější revizi.

Porovnávejte jednotlivé cesty zpracování, ne jeden průměr CPU. Mírné celkové zatížení může skrýt jedno nasycené jádro, které dělá všechnu práci na paket, a takt procesoru se mezi návrhy procesorů nepřenáší jako skóre výkonu. Rychlost paketů je stejně důležitá jako propustnost, protože malé pakety stojí na bajt víc než velké. Měřte s velikostmi paketů, které vaše zátěž skutečně používá.

Tepelné a výkonové limity také rozhodují o trvalém chování. Krátký výbuch může vypadat skvěle, zatímco desetiminutový přenos se throttluje, a proto je benchmark na několik sekund špatným vodítkem pro noční zálohu.

Pokyny výrobce k výkonu rozdělují přístupovou šířku pásma, CPU, zpracování paketů, transport a velikost paketu do samostatných omezení. Vyplatí se je přečíst před změnou šifry, protože změna šifry málokdy pohne hranicí, která nikdy nebyla limitem.

Změřte, než změníte šifru

Spusťte směrový test, který hlásí rychlost skutečně dosaženou tunelem, pak spusťte stejný test na surovém rozhraní pro srovnání. Rozdíl mezi těmito dvěma čísly je cena tunelu a menší z obou stropů vám řekne, na kterou hranici útočit.

Zachovejte bezpečnostní politiku nedotčenou, dokud porovnáváte. Starý výsledek získaný se slabou šifrou nebo přetaktovanou deskou není plán pro současné nasazení.

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

Uložte směrové výsledky vedle pozorování koncového bodu ze stejného běhu. Další změna by měla cílit na změřený strop, ne na komponentu, která na datovém listu vypadá nejmenší.