Hned zpočátku musím ještě trochu okomentovat díl předchozí. Jsem velice rád, že se pod ním rozpoutala tak bohatá diskuse, a především mě těší to, že obsahovala mnoho doplňujících a upřesňujících informací. Ano, skutečně, ne vše, co jsem uvedl ve svém článku, bylo zcela přesné nebo úplné. To má v principu dva důvody. Za prvé, nechtěl jsem začátečníky zatěžovat přílišnými a zbytečnými detaily. Druhým důvodem je pak smutná skutečnost, že některé věci zkrátka neznám nebo znám jen povrchně. Programováním síťových serepetiček jsem se nikdy nezabýval, a proto dávám k dispozici pouze své praktické zkušenosti s dílky cizích lidí. Popis některých skutečností se pak může více či méně lišit od toho, jak vše původně myslel sám autor… :-(
Zkusme tentokrát začít přímo skriptem, který se však kvůli dlouhým řádkám nevejde do článku, proto jej naleznete ve zvláštním souboru.
Prvních několik řádků by mělo být s pomocí přečtení prvního článku snadno pochopitelných. Modifikace spočívají v užití možností shellu pro automatické dopočítávání šířky pásma. Všimněte si též, že jsem z řádku definujícího kořen odstranil parametr „default“. To úzce souvisí se změnou řádků pro značkování packetů pomocí iptables. V těch jsem totiž nahradil klíčové slovo POSTROUTING FORWARDem, čímž jsem dosáhl toho, že značkování se aplikuje pouze na routované packety. Z toho logicky vyplývá, že jakýkoliv jiný packet, který bude opouštět počítač na rozhraní eth0, musí být generován lokálně (pokud nevěříte, pozorně prostudujte sadu značkovacích příkazů. Pokud pak takový packet přijde na řadu, nevyhoví žádné z podmínek nadefinovaných u filtrů a „spadne“ někam mezi, kde na ně ovšem nejsou aplikována žádná omezení. Cesta je to sice nečistá, ale účinná (za vše se ještě omluvím na konci článku, nebojte). Elegantnějším řešením tohoto problému by mohlo (a mělo) být vytvoření zvláštní třídy s RATE třeba 100mbit, do níž bychom pak „házeli“ ty správné packety a vše by fungovalo mnohem čistěji. Teorie je krásná, ale praxe… …no škoda mluvit. :-( Pokud byste to zkusili, začne na vás jádro (jeho HTB část) křičet, že šířka pásma pro jednotlivé třídy je ve značné nerovnováze a že nemůže efektivně zaručit správnou funkci. Pokusy ukázaly, že jádro nelže a že takto napsaný traffic shaper se chová velmi podivně a je v podstatě k ničemu.
Dalším polo-řešením, které je k dispozici v mém skriptu, je i značkování packetů pomocí iptables v tabulce OUTPUT. To proto, že na routeru běží i transparentní proxy. Všechny požadavky zevnitř sítě ven do internetu na port 80 přesměruje na lokální port 3128, kde poslouchá squid, a ten pak sám stránku z internetu stáhne, nebo ji rovnou naservíruje z vlastní cache. Tím jsme si ale, jak už jsem psal minule, zadělali na pěkný problém. Co když se některý z uživatelů rozhodne stahovat pětisetmegový soubor přes HTTP (předpokládáme port 80)? Všechna data by pak šla pouze z programu běžícího na routeru, byla by tedy lokálně generovaná (odkud je vezme ten program, už je věc jiná) a neaplikovaly by se na ně žádné limity. Takový uživatel by pak byl, a je to opět i prakticky ověřeno a potvrzeno, schopen dokonale „obsadit“ linku. Proto zavádíme tuto „šaškárnu“ se značkováním i části lokálně generovaných packetů, aby byly správně zařazovány do patřičné třídy a tím pádem i omezovány. Polo-řešením jsem to celé pak nazval proto, že tím bohužel ztrácíme hlavní výhodu cachující proxy, tedy že je schopna poskytovat často nebo nedávno navštěvované stránky vysokou rychlostí. I když totiž, při našem způsobu nakládání s packety, budeme požadovat některou ze stránek, která se bude válet kdesi ve squidovských útrobách a mohla by k nám být tedy poslána teoretickou rychlostí 100mbit (může se samozřejměl lišit), dostaneme ji bohužel maximální rychlostí 64kbit (v našem případě, a to pouze tehdy, nestahujeme-li nic dalšího, propůjčování pásma mezi třídami jsme teď zanedbali). Ani po usilovném přemýšlení mě bohužel nenapadl žádný elegantní způsob, jak tento problém vyřešit, a proto jsem zatím „spokojen“ s tímto částečným řešením, které alespoň zaručí rovnost mezi uživateli.
Už mě začínají trochu pobolívat prstíky, takže jdeme do finále. :-) Na závěr článku jsem sliboval nějakou tu omluvu, tak tady je. Ze srdce se omlouvám za všechna polovičatá řešení, která jsem dnes nabídl, ale sám v tuto chvíli nevím o ničem lepším a mým záměrem bylo pomoci vám alespoň nějak. Každopádně zveřejněné nastavení (plus pár dalších složitostí) používám na svém routeru a bohatě pro domácí využití postačuje. Doufám, že se opět rozjede diskuse, která má řešení ještě vylepší. Alespoň do té minulé skutečně přispělo mnoho velmi zkušených a moudrých lidí (kteří mě znalostmi jistě převyšují). Mnoho lidí se mě též ptalo na časový plán dalších pokračování, ale jak můžete sami vidět, jsou mé časové dispozice velice mizerné, a proto mohu předem slíbit jen toliko, že se budu snažit… Zatím přeji: Shapování zdar!
ČLÁNKY DO MAILU