A dokumentumban vázolt módszernek működnie kell más Linux konfigurációkon belül is, de nem teszteltük máson, csak a következők alatt:
Red Hat Linux 7.3
2.4.18-5 Kernel teljes QoS támogatással (modulok: OK) és beleértve a következő kernel-foltokat (amik történetesen az újabbakban benne is lehetnek már):
HTB várakozósor - http://luxik.cdi.cz/~devik/qos/htb/
![]() | jelentették, hogy a 2.4.18-3 kernelverziót követően a Mandrake (8.1, 8.2) már a HTB-hez adott folttal szállítja a rendszert. |
IMQ eszköz - http://luxik.cdi.cz/~patrick/imq/
iptables v1.2.6a vagy későbbi (a Red Hat 7.3-mal szállított iptables verzióból hiányzik a "length" modul)
![]() | a dokumentum előző verzióiban olyan sávszélesség-kezelési módszert adtunk meg, ami magában foglalta a meglévő sch_prio várakozósor megfoltozását. Később úgy találtuk, hogy ez a folt teljesen felesleges. Ezen felül a jelen dokumentumban taglalt módszer jobb eredményt ad (bár a doksi írása idején 2 kernelfolt szükséges :) Szerencsés foltozást.) |
A dolgok egyszerűsítése érdekében, a dokumentumban az összes hálózati eszközre és beállításra vonatkozó hivatkozás a következő hálózati elrendezést tükrözi:
<-- 128kbit/s -------------- <-- 10Mbit --> Internet <--------------------> | ADSL modem | <-------------------- 1.5Mbit/s --> -------------- | | eth0 V ------------------------------ | | | Linux útválasztó (router) | | | ------------------------------ | .. | eth1..ethN | | V V Helyi hálózat |
A csomagok várakozási sorai (queue) olyan "edények", amik az adatokat tárolják a hálózati eszköz számára, amikor azokat nem lehet azonnal elküldeni. A legtöbb várakozósor egy FIFO ("ami elsőnek megy be, elsőnek megy ki") fegyelmezési rendszert, diszciplínát használ (röviden qdisc - a ford.), hacsak speciálisan másra nem állítják be. Ez azt jelenti, hogy amikor egy eszköz várakozósora teljesen tele van, a várakozási sorba utoljára került csomagot csak akkor továbbítja az eszköz, amikor az összes többit már elküldte.
ADSL csatlakozás esetén a sávszélesség aszimmetrikus, tipikusan 1.5Mbit/s a bejövő és 128kbit/s a kimenő ág teljesítménye. Bár ez a vonali sebesség, a Linux útválasztó PC és az ADSL modem közötti illesztő tipikusan 10Mbit/s vagy a feletti sebességet tud. Ha a helyi hálózat felé néző csatoló szintén 10Mbit/s sebességű, akkor tipikusan NEM LESZ várakozósor az útválasztónál, amikor a helyi hálózat küld csomagokat az Internet felé. Az eth0 eszközön keresztül olyan sebességgel mennek ki a csomagok, ahogy a helyi hálózatból érkeztek. Ehelyett viszont a csomagok beállnak a sorba az ADSL modemnél, mivel 10Mbit/s-el érkeznek, és csak 128 kbit/s-el mehetnek ki. Időlegesen a csomagok várakozósora a modemnél megtelhet, és minden további csomag, amit küldenek neki, csendben eldobásra kerül. A TCP protokollt úgy tervezték, hogy kezelje ezt, és be fogja állítani a küldési ablak (transmit window) méretét úgy, hogy teljesen kihasználja a rendelkezésre álló sávszélességet.
Amíg a várakozósorok a TCP-vel kombinálva a sávszélesség lehető legjobb kihasználását teszik lehetővé, a nagy FIFO sorok megemelik az interaktív forgalom lappangási idejét.
Egy másik, a FIFO-ra hasonlító várakozósor az n-sávos prioritásos sor. Ennél ahelyett, hogy csak egy várakozósort alakítanánk ki a bejövő csomagok számára, az n-sávos sornak n darab FIFO sora van, amibe a csomagokat az osztályozásuk alapján helyezzük be. Minden sornak van egy prioritása, és a csomagok mindig a legnagyobb prioritású, csomagokat tartalmazó sorból jönnek ki. Ezt a fegyelmezési szabályt alkalmazva az FTP csomagok egy alacsonyabb prioritású sorba helyezhetők, mint a telnet csomagjai, így még egy FTP feltöltés alatt is, egy darab telnet csomag is kijuthat a sorból és azonnal továbbküldésre kerülhet.
A dokumentumot átalakítottuk az új linuxos várakozósor, a Hierarchical Token Bucket (HTB) használatához. A HTB sor nagyban hasonlít a fent leírt n-sávos sorra, de megvan az a tulajdonsága, hogy képes minden osztályának forgalmát korlátozni. Ezen kívül képes arra, hogy forgalmi osztályokat alakítson ki más osztályok alatt, egy hierarchikus osztályokból álló rendszert létrehozva. A HTB teljes leírása meghaladja a dokumentum kereteit, de további információ található a http://www.lartc.org webhelyen.
Az ADSL modembe befelé érkező forgalom a kimenőhöz hasonló módon áll várakozósorba, azonban a sor a szolgáltatódnál helyezkedik el. Emiatt valószínűleg nincs közvetlen befolyásod arra, hogyan álljanak sorba a csomagok vagy melyik fajta forgalom kapjon megkülönböztetett kezelést. Az egyetlen mód a várakozási idő alacsonyan tartására itt az, hogy megbizonyosodsz, miszerint nem küldik az adatokat túl gyorsan számodra. Sajnos nincs mód az érkező csomagok sebességének közvetlen befolyásolására, de mivel a forgalmazás többsége valószínűleg TCP, van néhány módja a küldők lelassításának:
Szándékosan eldobni a bejövő csomagokat - a TCP protokollt úgy tervezték, hogy kihasználja a rendelkezésre álló teljes sávszélességet, miközben próbálja elkerülni a kapcsolaton belül a torlódást. Ez azt jelenti, hogy nagy mennyiségű adat küldésekor a TCP több és több adatot küld, amíg végül is egy csomag eldobásra kerül. A TCP érzékeli ezt, és csökkenti az átviteli ablak méretét. Ez a folyamat ismétlődik a kapcsolat alatt, így biztosítja az adatok lehető leggyorsabb átvitelét.
A meghirdetett vételi ablak manipulálása - A TCP forgalmazás alatt a fogadó oldal az ACK (elfogadás) csomagok folyamatos sorát küldi vissza. Az ACK csomagokban található az ablakméret meghirdetése, ami kifejezi annak a nem elfogadott adatnak a mennyiségét, amit a fogadó küldeni tud. A kimenő ACK csomagok ablakméretének babrálásával szándékosan lelassíthatjuk a küldőt. Ennek a folyamatszabályozásnak jelen pillanatban nincs (szabadon elérhető) megvalósítása Linuxon (de lehet, hogy dolgozom egyen!)
Előző | Tartalomjegyzék | Következő |
Bevezetés | Hogyan működik? |