Wonder Shaper je velmi zvláštní síť Shaper skript s mnoha funkcemi. Práce na Linuxu 2.4 a vyšší.
Cíle
Snažil jsem se vytvořit svatý grál:
* Udržovat nízkou latenci pro interfactive provozu za všech okolností.
To znamená, že stahování nebo nahrávání souborů by neměla rušit SSH nebo dokonce telnet. To jsou nejdůležitější věci, dokonce i 200 ms latence je pomalý pracovat přes.
* Povolit "surfování" na rozumné rychlosti, zatímco nahoru nebo stahování
I když http je "hromadné" provoz, by další provoz není utopit ho příliš mnoho.
* Ujistěte se, že obrázky nepoškozují stahování, a naopak
To je hodně pozorovat jev, kdy proti proudu provoz jednoduše zničí rychlost stahování. Ukazuje se, že to vše je možné, za cenu trošku šířky pásma. Důvod, že obrázky, stahování a ssh bolet přicházejí do styku, je přítomnost velkých front v mnoha tuzemských přístupových zařízení, jako je kabelové nebo DSL modemů.
Proč to nefunguje dobře ve výchozím nastavení
Poskytovatelé internetových služeb vědí, že jsou porovnány pouze na tom, jak rychle se lidé mohou stáhnout. Kromě toho dostupné šířky pásma, rychlost stahování je ovlivněna těžce ztráty paketů, které vážně brání výkonu TCP / IP. Velké fronty může pomoci zabránit packetloss, a urychlit stahování. Takže ISP konfigurovat velké fronty.
Tyto velké fronty se však poškodit interaktivitu. Úhoz musí nejprve cestovat proti proudu fronty, který může být sekund (!) Dlouho a jděte do svého vzdáleného hostitele. To je pak zobrazen, což vede k paketu vrací, který pak musí procházet následnému fronty, která se nachází u vašeho ISP, před tím, než se objeví na obrazovce.
Tento HOWTO vás naučí, jak se mandl a zpracovat fronty v mnoha ohledech, ale bohužel, ne všechny fronty jsou přístupné pro nás. Fronta přes u ISP je zcela uzavřený, zatímco proti proudu fronta pravděpodobně žije uvnitř vašeho kabelového modemu nebo DSL modemu. Můžete může, ale nemusí být schopen ji konfigurovat. Pravděpodobně ne.
Takže, co dál? Protože nemůžeme kontrolovat ani z těchto front, musí být odstraněny, a přestěhoval se do vašeho systému Linux routeru. Naštěstí je to možné.
Limit rychlost uploadu poněkud
Omezením naši rychlost uploadu na o něco méně, než je skutečně možné ceny, žádné fronty jsou postaveny v naší modemu. Fronta je nyní přesunut na Linuxu.
Limit rychlost stahování
To je o něco složitější, protože nemůžeme opravdu ovlivnit, jak rychle se Internet americké lodě dat. My však mohou klesnout pakety, které přicházejí v příliš rychle, což způsobí, že TCP / IP zpomalit na pouhých míry chceme. Protože nechceme klesnout provozu zbytečně, jsme nakonfigurovat "roztržení" velikosti necháme při vyšší rychlosti.
Nyní, jakmile jsme to udělali, jsme eliminovat následnému fronty zcela (kromě krátkých dávkách), a získat schopnost řídit upstream frontu se vší silou Linux nabízí.
Ať interaktivní provoz přeskočit fronty
Co je ještě třeba udělat, je, aby se ujistil, interaktivní komunikace přejde na přední straně proti proudu fronty. Ujistěte se, že obrázky nebolí ke stažení, my také přesunout ACK pakety do fronty. To je to, co obvykle způsobuje obrovské zpomalení pozorované při generování hromadné dopravy v obou směrech. V Poděkování pro následné provoz musí soutěžit s provozem proti proudu, a dostat zpožděním v tomto procesu.
Také jsme přesunout další malé balíčky na začátek fronty - to pomáhá operační systémy, které nejsou stanovené TOS bity, stejně jako všechno od společnosti Microsoft.
Umožňuje uživateli zadat nízkou prioritou provoz (nové v 1.1!)
Někdy můžete si všimnout nízkou prioritou odchozí provoz zpomaluje důležitou provoz. V takovém případě, může tyto možnosti vám pomůže:
NOPRIOHOSTSRC
Nastavte na počítače nebo síťové masky netmasks ve vaší síti, které by měla mít nízkou prioritou
NOPRIOHOSTDST
Nastavte na počítače nebo síťové masky netmasks na internetu, že by měl mít nízkou prioritu
NOPRIOPORTSRC
Nastavte na zdrojové porty, které by měl mít nízkou prioritu. Pokud máte nedůležitou webserver na vašem provozu, nastavte na 80 ° C
NOPRIOPORTDST
Nastavte na cílové porty, které by měl mít nízkou prioritu.
Podívejte se na začátek wshaper a wshaper.htb
Výsledky
Pokud se nám to všechno dostaneme následující měření pomocí vynikající ADSL připojení z xs4all v Nizozemsku:
Baseline latency:
round-trip min / avg / max = 14,4 / 17,1 / 21,7 ms
Bez dopravy kondicionér, zatímco stahování:
round-trip min / avg / max = 560,9 / 573,6 / 586,4 ms
Bez dopravy kondicionér, zatímco nahrávání:
round-trip min / avg / max = 2041,4 / 2332,1 / 2427,6 ms
S kondicionér, během 220kbit / s upload:
round-trip min / avg / max = 15,7 / 51,8 / 79,9 ms
S kondicionér, během 850kbit / s download:
round-trip min / avg / max = 20,4 / 46,9 / 74,0 ms
Při nahrávání, stahování pokračovat na ~ 80% dostupného rychlosti. Nahrávání na zhruba 90%. Latence pak skočí na 850 ms, stále ještě zjišťuje, proč.
Co můžete očekávat od tohoto skriptu, závisí hodně na vaší aktuální rychlost uplinku. Při nahrávání v plné rychlosti, tam bude vždy jeden balíček náskok před stiskem klávesy. To je spodní hranice na latenci můžete dosáhnout - rozdělit svůj MTU vaší předcházející rychlosti pro výpočet. Typické hodnoty bude o něco vyšší, než je. Snižte MTU pro lepší efekty!
Malý stůl:
Rychlost Uplink | Očekávané zpoždění kvůli nahrát
--------------------------------------------------
32 | 234ms
64 | 117ms
128 | 58ms
256 | 29ms
Takže vypočítat efektivní latenci, se základní měření (ping na nezatížené odkaz), a vyhledat číslo v tabulce, a přidejte jej. To je asi nejlepší, co můžete očekávat. Toto číslo vychází z výpočtu, který předpokládá, že váš upstream klávesy bude mít nejvýše polovina plné velikosti paketu před ním.
To se scvrkává na:
mtu * 0,5 * 10
-------------- + Baseline_latency
kbit
Faktor 10 není zcela správné, ale dobře funguje v praxi.
Váš kernel
Pokud spustíte nedávnou distribuci, všechno by mělo být v pořádku. Musíte 2.4 s možností QoS zapnutý.
Pokud si sestavit své vlastní jádro, musí mít nějaké možnosti povoleny. Nejvíce pozoruhodně, v menu Možnosti sítě, QoS a / nebo Fair Queueing, otočte alespoň CBQ, PRIO, SFQ, Ingress, Traffic Policing, podpora QoS, Rate Odhadce, QoS klasifikátor, U32 klasifikátor, fwmark klasifikátor.
V praxi jsem se (a většina distribucí), stačí zapnout všechno.
Tyto skripty
Skript přichází ve dvou verzích, jeden, který pracuje na standardních jádrech a je implementován pomocí CBQ. Ten druhý používá vynikající HTB qdisc, který není ve výchozím jádře. Verze CBQ je více zkouší, než HTB jedné!
Viz "wshaper 'a' wshaper.htb".
Ladění
Tyto skripty potřebovat znát "skutečná" rychlost vašeho ISP připojení. To je těžké stanovit předem, protože různé ISP používají různé druhy bity se objeví. Lidé hlásí úspěch pomocí následující techniky:
Odhadněte jak vaše proti proudu a po proudu při poloviční rychlosti vašeho ISP specifikuje. Nyní ověřte, zda je skript funguje - zkontrolujte interaktivitu při nahrávání i při stahování. To by mělo přinést latenci podle výše uvedeného výpočtu. Pokud ne, zkontrolujte, zda skript spuštěn bez chyb.
Nyní pomalu zvyšovat počty upstream & downstream ve skriptu, dokud zpoždění vrátí. Tímto způsobem můžete najít optimální hodnoty pro připojení. Pokud jste spokojeni, oznamte mi, abych mohl vytvořit seznam čísel, které fungují dobře. Prosím, dejte mi vědět, jaký ISP používáte a název vašeho předplatného, a jeho reputací specifikace, takže můžu vypsat tě tady a ušetřete ostatním námahu.
Instalace
Máte-li vytočit, můžete zkopírovat skript /etc/ppp/ip-up.d a bude běžet na každém připojení.
Chcete-li odstranit shaper z rozhraní, spusťte "wshaper zastavení". Chcete-li zobrazit informace o stavu, spusťte "wshaper stavu".
Známé problémy
Pokud se dostanete chyby, přidejte -x do prvního řádku, takto:
#! / Bin / bash -x
A zkuste to znovu. To vám ukáže, která linka dává chybu. Než se obrátíte na mě, ujistěte se, že používáte nejnovější verzi iproute!
Poslední verze lze nalézt na vašem Linux distributora, nebo pokud dáváte přednost kompilaci, zde:
ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz
Komentáře nebyl nalezen