Jak na sdílení pásma aka (traffic) shaping

Sdílením pásma (dale jen shaping) se rozumí přidělení určité maximální rychlosti některým datovým tokům tekoucím přes router. Sepsal bych několik heslovitých poznámek, ostatní se dá dobře najít v dokumentaci (především v LARTC):

* Vlastní shaping se provádí pomocí tzv. Queueing Discipline, zkráceně qdisc. Tyto se definují pomocí příkazu tc (zkratka od traffic control). Tyto qdiscy se nastavují pro každou síťovou kartu zvlášť, na každé síťové kartě jich může být hodně a různě uspořádaných.

* Příkaz tc má poměrně složitou syntaxi a pro začátečníka není moc vhodný (nekamenovat, můj názor). Proto je dobré používát různé skripty, které shaping nastaví podle zadaného konfig. souboru (např. cbq.init, htb.init)

* Pozornosti doporučuju qdisc HTB (Hierarchical Token Bucket) a SFQ (Stochastic Fair Queuing). Zatímco první slouží k (hierarchickému) rozdělení pásma mezi datové taky, druhý slouží k rovnoměrnému a spravedlivému rozdělení toku mezi několik spojení. Např: pomocí HTB se rozdělí pásmo mezi uživatele A,B a C a pomocí SFQ se každému uživateli zajistí spravedlivé rozdělení jeho pásma mezi všechny jeho spojení

* HTB uspořádává třídy do stromu, v kořeni je celé síťové rozhraní, dál je to na vás. Jednotlivé sourozenecké uzly si navíc mezi sebou mohou půjčovat nevyužité pásmo. Na každém listu je pak potřeba pověsit nějaký qdisc, který zajistí rozdělení pásma přiděleného od HTB dané třídě mezi spojení, které ve třídě jsou. Většinou to bývá SFQ, případně FIFO.

* Všechno popsané v minulém odkazu za vás nastaví htb.init, stačí mu jen předhodit několik konfiguračních souborů.

* Pokud se na daném rozhraní provádí i NAT, je potřeba si uvědomit, že packety prochází shapingem až po provedení NATu, takže přicházíme o interni zdrojovou adresu u odeslaných packetů a nemůžeme tedy podle ní přímo rozlišovat provoz. Provoz je dobré rozlišovat pomocí FWMARK, které si ve firewallu pomocí iptables -j MARK můžeme nastavit jak chceme (a případně je můžeme využít i třeba pro statistiky přenosu)

* Shaping se z principu dá provádět pouze na odchozím interface (na příchozím rozhraní se musí data přijímat takovou rychlostí, jakou je vysílající strana posílá). Toto je poměrně často nemožné (provider vám většinou provoz shapeovat nebude a i kdyby chtěl, tak pokud používáte NAT, tak z principu provider nemůže mít k dispozici dostatek informací). Většina používaných protokolů má naštěstí nějakou detekci rychlosti, takže je možné pomocí shapeování na odchozím interface do LOKÁLNÍ sítě nepřímo rychlost posílání omezovat. Při dodržení některých pravidel to funguje i docela spolehlivě. Především není možné moc dobře používat půjčování nevyužitého pásma, protože může dojít k situaci, kdy u providera packety z jedné třídy hlavičkami umlátí packety z druhé třídy. Příklad: Máme dvě lokální třídy A (max 1Mbit/s) a B (max 1Mbit/s). Celkem máme linku 1,5Mbit/s. Obě třídy chtějí využít maximální rychlosti, takže u providera "čeká" na doručení 2Mbit/s packetů. Protože linka má jen 1,5Mbit/s musí se proto router u providera rozhodovat, které packety pošle. Pokud není poměr packetů z obou tříd vyrovananý (jedna má např. hodně malých packetů a druhá málo velkých), tak na náš router přijde například 0,9MBit/s z jedné třídy a 0,6Mbit/s z druhé třídy. Router si ověšem myslí, že druhá třída nevyužívá plně svoje pásmo a proto "volné" pásmo přidělí první třídě. Takže místo aby se obě třídy spravedlivě rozdělily 0,7 vs 0,7, tak budou hodnoty různě oscilovat. Dále samozřejmě není možné shapeovat provoz určený pro router.

* Je dobré udělat speciální třídu pro malé packety (iptables -m length), cca do 80-100B a ty pouštět prioritně. Zrychlí se tak odezva SSH, pošty a spol. Je to velice vhodné i pro síťové hry. Také se tak upřednostní potvrzovací packety, takže se vyřeší známý problém DC++, kdy velké packety odchozích spojení (cca 1500B) vůbec nepustily k lince malé potvrzující packety pro příchozí data a download tak klesl třeba na 20%.

* Není jednoduché shapeovat služby jako DC++ a spol., protože používají různá čísla portů. Nejúčinější řešení je použít moduly pro iptables, které tyto spojení poznají (většinou ale jen úvodní packet) a rozšíření Connection Marking (řeší problém poznávání, které packety patří do spojení, které jsme podle úvodního packetu označili jako např. DC).

* Do modemu se většinou doporučuje posílát o pár procent menší datový tok, než kolik máme od providera. Efektivně se tak z činnosti vyřadí buffer modemu, který je poměrně hloupý, a náš router získá lepší kontrolu nad řízením toku linky.

* Papír a tužka nejsou nepřátelé a pěkný diagrámek často pomůže rozmyslet situaci a/nebo vyřešit problém.

Dokument vytvořil: Radek Hladik, 9.12.2005 23:23 | Poslední úprava: Käyttäjä 11133, 24.4.2007 21:23 | Historie změn | Zobrazeno: 2386×