ADSL s�vsz�less�g-gazd�lkod�s HOGYAN

Dan Singletary

dvsing@sonicspike.net

Verzi�t�rt�net
Verzi�: 1.3	2003.04.07	�tdolgozta: ds
A hivatkoz�sok r�sz hozz�ad�sa.
Verzi�: 1.2	2002.09.26	�tdolgozta: ds
Az �j levelez�list�ra mutat� hivatkoz�s hozz�ad�sa. Hozz�adva egy kis fejt�r� a fenntartott r�szhez az �j, tov�bbfejlesztett Linux QoS-hez, amit specifikusan a hamarosan kiadand� ADSL-hez fejlesztettek.
Verzi�: 1.1	2002.08.26	�tdolgozta: ds
N�h�ny jav�t�s (K�sz�net sokaknak, akik felh�vt�k r�juk a figyelmet!). Inform�ci�s kik�t�sek hozz�ad�sa a megval�s�t�si r�szhez.
Verzi�: 1.0	2002.08.21	�tdolgozta: ds
Jobb ellen�rz�s a s�vsz�less�g felett, t�bb te�ria, friss�tve a 2.4-es kernelekhez
Verzi�: 0.1	2001.08.06	�tdolgozta: ds
Els� kiad�s

A dokumentum le�rja, hogyan �ll�tsunk be egy Linux �tv�laszt�t, hogy hathat�sabban kezelje a kimen� forgalmat egy ADSL modemen vagy m�s olyan eszk�z�n, ami hasonl� s�vsz�less�g-tulajdons�gokkal rendelkezik (k�belmodem, ISDN stb.). Hangs�lyt fektett�nk az interakt�v forgalom v�rakoz�si, lappang�si idej�nek cs�kkent�s�re m�g akkor is, ha a felt�lt�si �s/vagy let�lt�si s�vsz�less�g teljesen tel�tett.

1. Bevezet�s

Jelen dokumentum c�lja, hogy aj�nljon egy m�dszert egy internethez kapcsol�d� ADSL (vagy k�bel) modemen kimen� forgalom kezel�s�hez. A probl�ma az, hogy a legt�bb ADSL vonalat lekorl�tozt�k 128kbs vagy e k�r�li adatfelt�lt�si sebess�gre. M�g s�lyosabb� teszi a probl�m�t a csomagok v�rakoz�si sora az ADSL modemen bel�l, ami ha tele van, 2 vagy 3 m�sodpercet is ig�nybe vesz, m�g ki�r�l. Ez egy�ttesen azt jelenti, hogy amikor a felt�lt�si s�vsz�less�g teljesen tel�tve van, a t�bbi csomagnak 3 m�sodpercet is ig�nybe vehet, am�g kijutnak az Internetre. Ez megb�n�thatja az interakt�v alkalmaz�sokat, mint a telnet vagy a t�bbszerepl�s j�t�kok.

1.1. A dokumentum �j verzi�i

Mindig megtal�lod a jelen dokumentum leg�jabb verzi�j�t a vil�gh�l�n a http://www.tldp.org webhelyen.

Az �j verzi�k ezen k�v�l k�l�nb�z� Linux WWW �s FTP szerverre is fel vannak t�ve, bele�rtve az LDP honlapj�t a http://www.tldp.org webhelyen.

1.6. Magyar ford�t�s

A magyar ford�t�st Sz�jj�rt� L�szl� k�sz�tette (2002.07.28). A lektor�l�st Daczi L�szl� v�gezte el (2002.09.05). A dokumentum legfrissebb v�ltozata megtal�lhat� a Magyar Linux Dokument�ci�s Projekt honlapj�n.

2. H�tt�r

2.1. El�zetesen sz�ks�ges dolgok

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.)

2.2. Elrendez�s

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

2.3. Csomagok v�rakoz�sorai

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.

2.3.1. A kimen� �g

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.

2.3.2. A bej�v� �g

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!)

3. Hogyan m�k�dik?

K�t alapvet� l�p�ssel optimaliz�lhatjuk a kifel� men� s�vsz�less�get. El�sz�r tal�lnunk kell egy m�dot arra, hogy megakad�lyozzuk az ADSL modemet a csomagok sorba �ll�t�s�ban, mivel nincs r�hat�sunk a v�rakoz�sor kezel�s�re. Ennek �rdek�ben visszafogjuk az �tv�laszt� �ltal az eth0-n kik�ld�tt adat mennyis�g�t, kicsit kevesebbre, mint a modem teljes kimen� s�vsz�less�ge. Ez azt eredm�nyezi, hogy az �tv�laszt� rakja v�rakoz�sorba a helyi h�l�zatr�l �rkez� csomagokat, amik gyorsabban �rkeznek, mint megengedett kik�ld�s�k.

A m�sodik l�p�s egy priorit�sos v�rakoz�sor-fegyelmi szab�ly fel�ll�t�sa az �tv�laszt�n. Meg fogunk val�s�tani egy olyan sort, amit be lehet �ll�tani �gy, hogy els�bbs�get adjon az interakt�v forgalomnak, mint a telnet vagy a t�bbszerepl�s j�t�kok.

A v�gs� l�p�s a t�zfal be�ll�t�sa, hogy az fwmark seg�ts�g�vel biztos�tsa a csomagok els�bbs�g�t.

3.1. A HTB alkalmaz�sa a kimen� forgalom visszafog�s�ra

B�r az �tv�laszt� �s a modem k�zti kapcsolat 10 Mbit/s sebess�g�, a modem csak 128 kbit/s sebess�ggel tud adatokat k�ldeni. Minden ezt a r�t�t meghalad� sebess�g� csomag v�rakoz�sorba �ll a modemn�l. Ez�rt egy ping csomag, amit az �tv�laszt�r�l k�ld�nk, azonnal elmehet a modemhez, de n�h�ny m�sodpercet vehet ig�nybe, am�g t�nylegesen kiker�l az Internetre, ha a modem v�rakoz�sora tartalmaz m�r valamennyi csomagot. Sajnos a legt�bb ADSL modem eset�ben nem adhatjuk meg a v�rakoz�sor kezel�s�nek m�dj�t illetve annak nagys�g�t. �gy el�sz�r a kimen� csomagokat �tir�ny�tjuk oda, ahol mindezt megtehetj�k.

Ezt a HTB sorral val�s�tjuk meg, �gy cs�kkentve az ADSL modemhez k�ld�tt csomagok sz�m�t. M�g ha a kifel� men� s�vsz�less�g�nk a 128kbit/s is lehetne, kicsivel ez al� korl�tozzuk le a csomagk�ld�s m�rt�k�t. Ha cs�kkenteni akarjuk a lappang�si id�t, BIZONYOSNAK kell lenn�nk, hogy soha egyetlen csomag sem �ll sorba a modemn�l. K�s�rletez�sek sor�n azt tal�ltam, hogy a kimen� forgalom k�r�lbel�l 90kbit/s-ra val� visszav�tel�vel a s�vsz�less�g majdnem 95%-�t tudom el�rni a HTB vez�rl�s n�lk�l. A HTB enged�lyez�s�vel enn�l a m�rt�kn�l kiv�dj�k, hogy a modem v�rakoz�sorba rakja a csomagokat.

3.2. Priorit�sos v�rakoz�sor kialak�t�sa HTB-vel

Megjegyz�s: az ebben a r�szben l�v� el�z� ig�nyek (eredetileg N-s�vos priorit�sos v�rakoz�sor kialak�t�s�nak h�vt�k) k�s�bb hib�snak tal�ltattak. LEHETETLEN volt a v�rakoz�sor k�l�nb�z� s�vjaiba tartoz� csomagok megjel�l�se csak a fwmark mez� �ltal, viszont ezt gyeng�n dokument�ltuk a dokumentum 0.1-es verzi�j�nak �r�sakor.

Enn�l a pontn�l m�g nem vesz�nk �szre semmi v�ltoz�st a teljes�tm�nyben. Puszt�n csak �thelyezz�k a FIFO sort az ADSL modemt�l az �tv�laszt�hoz. Val�j�ban, a Linux alap�rtelmez�sben be�ll�tott 100 csomag m�ret� FIFO sor�val, val�sz�n�leg m�g rosszabb� is tett�k a helyzet�nket! De nem sok�ig...

Minden szomsz�dos oszt�lynak adhatunk egy priorit�st a HTB soron bel�l. A k�l�nb�z� t�pus� forgalom k�l�nb�z� oszt�lyokba helyez�s�vel, majd ezen oszt�lyokhoz k�l�nb�z� priorit�sok csatol�s�val, vez�relhetj�k a csomagok v�rakoz�si sorb�l val� kiv�tel�t �s elk�ld�s�t. A HTB lehet�v� teszi ezt, mik�zben megakad�lyozza egy oszt�ly "ki�heztet�s�t", mivel megadhatjuk a minim�lisan garant�lt m�rt�ket minden oszt�ly sz�m�ra. Ezenfel�l a HTB megengedi azt is, hogy megadjuk egy oszt�lynak: haszn�lhatja m�sik oszt�lyok nem haszn�lt s�vsz�less�g�t, egy bizonyos fels� hat�rig.

Miut�n be�ll�tottuk az oszt�lyainkat, sz�r�ket helyez�nk el, hogy a forgalmat elhelyezz�k bel�j�k. T�bb �tja is van ennek, de az itt le�rt m�dszer az ismer�s iptables/ipchains-t haszn�lja a csomagok fwmark-al (t�zfal jel�l�se a csomagon) t�rt�n� megjel�l�s�re. A sz�r�k a csomagok fwmark-j�t figyelembe v�ve helyezik el a forgalmat a HTB sor oszt�lyaiba. Ezen a m�don k�pesek lesz�nk megfelel� szab�lyok fel�ll�t�s�ra az iptables-en bel�l, hogy bizonyos t�pus� forgalmat egy bizonyos oszt�lyba k�ldj�n.

3.3. A kimen� csomagok oszt�lyoz�sa iptables-szel

eredetileg a dokumentumban az ipchains-t haszn�ltuk a csomagok besorol�s�ra. Most az �jabb iptables-t haszn�ljuk.

Az utols� l�p�s ahhoz, hogy az �tv�laszt� els�bbs�get adjon az interakt�v forgalomnak - a t�zfal be�ll�t�sa: adjuk meg a forgalom besorol�s�nak m�dj�t. Ez a csomag fwmark mez�j�nek be�ll�t�s�val �rhet� el.

An�lk�l, hogy t�lzottan a r�szletekbe mer�ln�nk, �lljon itt az egyszer�s�tett le�r�sa annak, hogyan lehet a kimen� csomagokat 4 oszt�lyba sorolni �gy, hogy a legmagasabb priorit�s� lesz a 0x00:

Jel�lj�nk MINDEN csomagot 0x03-al. Ez alap�rtelmez�sben minden csomagot a legalacsonyabb priorit�s� sorba helyez el.
Jel�lj�k az ICMP csomagokat 0x00-al. Szeretn�nk, ha a ping mutatn� a legmagasabb priorit�s� csomagok v�rakoz�si idej�t.
Jel�lj�nk minden csomagot, aminek c�lportja 1024 vagy kisebb, 0x01-el. Ez els�bbs�get biztos�t az olyan rendszerszolg�ltat�soknak, mint a Telnet �s SSH. Az FTP portja szint�n ebbe a k�rbe esik, de az FTP adatforgalom a magasabb portokon helyezkedik el �s marad a 0x03 s�vban.
Jel�lj�nk minden csomagot, aminek a c�lportja 25 (SMTP), a 0x03-al. Ha valaki levelet fog k�ldeni egy nagy csatolt �llom�nnyal, nem akarjuk, hogy el�rassza az interakt�v forgalmat.
Jel�lj�nk minden csomagot, aminek c�lja egy t�bbszerepl�s j�t�k-szerver, 0x02-vel. Ez a j�t�kosoknak alacsony lappang�si id�t biztos�t, de megakad�lyozza, hogy elfoglalj�k az alacsony v�rakoz�st ig�nyl� rendszerszolg�ltat�sokat.
Jel�lj�nk minden "kicsi" csomagot 0x02-vel. A kimen� ACK csomagokat a befel� ir�nyul� let�lt�sekb�l azonnal ki kell k�lden�nk, hogy biztos�tsuk a megfelel� let�lt�seket. Ez az iptables "length" modulj�val lehets�ges.

Term�szetesen ezeket a k�v�nalmaknak megfelel�en �talak�thatod.

3.4. M�g n�h�ny fog�s...

K�t tov�bbi dolgot tehetsz a lappang�si id� jav�t�s�ra. El�sz�r is, a maxim�lis �tvihet� egys�g (MTU) m�ret�t kisebbre veheted, mint az alap�rtelmezett 1500 b�jt. Ennek a sz�mnak a cs�kkent�se egyben az �tlagos id�t is cs�kkenti, amit az els�bbs�get �lvez� csomagok elk�ld�s�re kell ford�tani, ha m�r egy teljes m�ret� alacsony priorit�s� csomag k�ld�se folyamatban van. Ennek az �rt�knek a cs�kkent�se kicsit cs�kkenti a teljes�tm�nyt is, mivel minden csomag legal�bb 40 b�jtnyi IP �s TCP fejl�c-inform�ci�t tartalmaz.

A m�sik dolog a jav�t�shoz, m�g alacsony priorit�s� forgalom eset�n is, hogy cs�kkented a v�rakoz�si sor m�ret�t az alap�rtelmezett 100-r�l, ami egy ADSL vonalon 10 m�sodperc alatt �r�l ki egy 1500 b�jtos MTU-t alapul v�ve.

3.5. Pr�b�lkoz�s a bej�v� forgalom visszafog�s�ra

A "k�zbens� v�rakoz�sor-eszk�z" (Intermediate Queuing Device, IMQ) haszn�lat�val az �sszes bej�v� csomagot ugyan�gy egy v�rakoz�soron futtathatjuk �t, mint amilyen m�don a kimen�ket is. A csomagok priorit�sa ebben az esetben j�val egyszer�bb. Mivel csak a bej�v� TCP forgalmat (pr�b�ljuk meg) vez�relni, az �sszes nem-TCP forgalmat a 0x00 oszt�lyba rakjuk, az �sszes TCP forgalmat pedig a 0x01 oszt�lyba. A "kis" TCP csomagokat szint�n a 0x00 oszt�lyba soroljuk, mert ezek nagy val�sz�n�s�ggel a m�r elk�ld�tt kimen� adatok ACK csomagjai. Egy standard FIFO sort �ll�tunk be a 0x00 oszt�lyhoz, illetve egy "v�letlenszer� korai eldob�s" (Random Early Drop, RED) v�r�sort a 0x01 oszt�lyhoz. A RED jobb a FIFO-n�l a TCP vez�rl�s�t tekintve, mert eldobja a csomagokat m�r a sor olyan t�lcsordul�sa el�tt, mikor megpr�b�lja lelass�tani a forgalmat az ellen�rz�s fenntart�sa �rdek�ben. Ezen k�v�l mindk�t oszt�lyt le fogjuk korl�tozni egy maxim�lis bej�v� forgalmi hat�rra, ami kisebb, mint a val�s, ADSL modemen bej�v� sebess�g.

3.5.1. Mi�rt nem olyan j� a bej�v� forgalom korl�toz�sa?

Korl�tozni szeretn�nk a bej�v� forgalmunkat, hogy elker�lj�k a v�rakoz�sor betel�s�t a szolg�ltat�n�l, ami n�ha 5 m�sodpernyi adat pufferel�s�t jelentheti. A probl�ma abban �ll, hogy jelenleg a bej�v� TCP forgalom korl�toz�s�nak egyetlen m�dja a teljesen j� csomagok eldob�l�sa. Ezek a csomagok m�r foglaltak n�mi s�vsz�less�get az ADSL modemen, csak a Linux g�p dobta el �ket abb�l a c�lb�l, hogy a j�v�beni csomagokat lelass�tsa. Ezek az eldobott csomagok id�nk�nt �jra elk�ld�sre ker�lnek, m�g t�bb s�vsz�less�get foglalva. Amikor korl�tozzuk a forgalmat, korl�tozzuk azon csomagok m�rt�k�t, amiket elfogadunk a h�l�zatunk sz�m�ra. Mivel az aktu�lis bej�v� adatr�ta valahol ef�l�tt van az eldobott csomagok miatt, a bej�v� �gunkat sokkal jobban le kell korl�toznunk az ADSL modem aktu�lis r�t�j�n�l, az alacsony lappang�si id� biztos�t�sa �rdek�ben. A gyakorlatban az �n 1.5Mbit/s bej�v� �gamat 700kbit/s-re kellett korl�toznom, hogy elfogadhat� szinten tartsam a lappang�st 5 egyidej� let�lt�sn�l. Min�l t�bb TCP folyamatod van, ann�l t�bb s�vsz�less�get vesztesz az eldobott csomagok miatt, �s ann�l kisebbre kell venned a korl�toz�s m�rt�k�t.

A bej�v� TCP forgalom ellen�rz�s�nek sokkal jobb m�dja a TCP ablak manipul�ci�ja, de ebben a pillanatban nincs (szabadon el�rhet�) megval�s�t�sa ennek Linuxra (amennyire �n tudom...).

4. Megval�s�t�s

Mindezen okfejt�s ut�n most m�r ideje, hogy megval�s�tsuk a s�vsz�less�g-gazd�lkod�st Linuxon.

4.1. Kik�t�sek

A DSL modemhez aktu�lisan k�ld�tt adatok m�rt�k�nek korl�toz�sa nem olyan egyszer�, mint amilyennek l�tszik. A legt�bb DSL modem igaz�b�l csak egy ethernet h�d, amik tov�bb�tj�k az adatokat oda-vissza a Linux g�p �s a szolg�ltat�n�l l�v� gateway k�z�tt. A legt�bb DSL modem ATM-et haszn�l adat�tviteli csatol�fel�letk�nt. Az ATM mindig 53 b�jtos cell�kban k�ldi az adatokat. Ezekb�l 5 b�jt a fejl�c inform�ci�, �s 48 b�jt marad az adatoknak. M�g ha csak 1 b�jt adatot k�ldesz is, a teljes 53 b�jt s�vsz�less�get foglal, mivel az ATM cell�k mindig 53 b�jt hossz�ak. Ez azt jelenti, hogy ha egy tipikus TCP ACK csomagot k�ldesz, ami 0 b�jt adatot + 20 b�jt TCP fejl�cet + 20 b�jt IP fejl�cet + 18 b�jt Ethernet fejl�cet tartalmaz. Val�j�ban, m�g ha a kik�ld�tt ethernet csomagnak csak 40 b�jtnyi "hasznos terhe" van is (TCP �s IP fejl�c), a legkisebb m�ret egy Ethernet csomagn�l 46 b�jtnyi adat, �gy a marad�k 6 b�jt 0-val t�lt�dik ki. Ez azt jelenti, hogy az Ethernet csomag plusz a fejl�c inform�ci�k aktu�lis hossza 18 + 46 = 64 b�jt. Az ATM-mel 64 b�jt �tk�ld�s�hez k�t ATM cell�t kell k�ldened, ami 106 b�jt s�vsz�less�get foglal. Vagyis minden TCP ACK csomagn�l 42 b�jt s�vsz�less�get vesztesz. Ez rendben van, ha a Linux figyelembe veszi a DSL modem �ltal haszn�lt csomag-be�gyaz�st, de ehelyett a Linux csak a TCP �s IP fejl�cet �s 14 b�jtos MAC c�met jegyzi (a Linux nem sz�molja a 4 b�jtos CRC-t, mivel ezt a hardver szint kezeli). A Linux nem sz�mol a 46 b�jtos minim�lis Ethernet csomagm�rettel, sem a fix m�ret� ATM cell�val.

Mindez azt jelenti, hogy a kimen� s�vsz�less�get valamivel kisebbre kell �ll�tani, mint a val�s kapacit�s (am�g nem tal�lunk egy csomag-id�z�t�t, ami jegyzi a k�l�nb�z� t�pus� csomag-be�gyaz�sokat). Azt tal�lhatod, hogy siker�lt egy j� �rt�kre be�ll�tani a s�vsz�less�get, de amikor egy nagy f�jlt t�ltesz le, a lappang�s felsz�kik 3 m�sodperc f�l�. Ez legval�sz�n�bben amiatt van, mivel a Linux rosszul sz�m�tja ki a bizonyos kis ACK csomagok �ltal ig�nyelt s�vsz�less�get.

N�h�ny h�napot dolgoztam ennek a probl�m�nak a megold�s�n, �s majdnem lez�rtam a dolgot egy olyan megold�ssal, amit hamarosan k�zreadok tov�bbi tesztel�sre. A megold�s egy felhaszn�l�i szint� v�rakoz�sor haszn�lat�t mutatja be a Linux QoS-e helyett a csomagok korl�toz�s�ra. Alapvet�en egy egyszer� HTB sort alkalmaztam, ami a Linux felhaszn�l�i szint� sorait haszn�lja. Ez a megold�s (eddig) k�pes volt a kimen� forgalom OLYAN J� korl�toz�s�ra, hogy m�g egy massz�v let�lt�s (t�bb sz�lon) �s ugyanilyen felt�lt�s (gnutella, t�bb sz�lon) alatt is, a lappang�s 400 ms CS�CS�RT�KET �rt csak el a n�vleges, forgalom n�lk�li 15 ms-hoz k�pest. Tov�bbi inform�ci��rt err�l a QoS m�dszerr�l, iratkozz fel a friss�t�sek levelez�list�j�ra vagy k�s�bb n�zd meg ennek a HOGYANnak a frissebb v�ltozatait.

4.2. Szkript: myshaper

A k�vetkez�kben egy �ltalam a Linux �tv�laszt�n a s�vsz�less�g korl�toz�s�ra haszn�lt szkript list�ja tal�lhat�. Ez t�bb, a dokumentumban foglalt koncepci�t is felhaszn�l. A kimen� forgalom a 7 t�pust�l f�gg� v�r�sor egyik�be ker�l. A bej�v� forgalom k�t sorba ker�l, a TCP csomagokat (alacsonyabb priorit�s�ak) el�bb eldobjuk, ha a bej�v� adatok a m�rt�k f�l�ttiek. A szkriptben megadott r�t�k �gy t�nik, j�l m�k�dnek az �n be�ll�t�somban, de az eredm�nyek v�ltozhatnak.

#!/bin/bash
#
# myshaper - DSL/kabelmodem kimeno forgalmanak szabalyozasa.
#            Az ADSL/Cable wondershaper (www.lartc.org) szkripten alapszik.
#
# Irta: Dan Singletary (8/7/02)
#
# FIGYELEM: a szkript feltetelezi,  hogy a kernelt megfoltoztuk a megfelelo HTB 
# sor �s  IMQ foltokkal,  amik hozzaferhetok  itt (megj.:  az ujabb kerneleknel 
# lehet, hogy nem kell folt):
#
#       http://luxik.cdi.cz/~devik/qos/htb/
#       http://luxik.cdi.cz/~patrick/imq/
#
# Konfiguracios beallitasok:
#  DEV    - ethX-re allitsuk, ami kapcsolodik a DSL/kabelmodemhez
#  RATEUP - allitsuk valamivel kisebbre, mint a modem kimeno savszelessege. 
#           Nekem 1500/128  DSL vonalam  van, es a  RATEUP=90 jol mukodik a 
#           128 kbps-os feltoltessel. De ahogy jonak latod.
#  RATEDN - allitsd valamivel kisebbre, mint a bejovo savszelesseg.
#
#
# Teoria az imq hasznalatarol a bejovo forgalom alakitasahoz:
#
#
# BEJOVO  TCP  KAPCSOLATOK  BEFOLYASOLASAT.  Ennek  ertelmeben  minden   nem-TCP
# forgalmat egy  magas prioritasu  osztalyba kell  sorolnunk, mivel  egy nem-TCP
# csomag eldobasa valoszinuleg a csomag  ujrakuldeset okozza. Ez semmi mast  nem
# jelent,  csak  a  savszelesseg  szuksegtelen  lefoglalasat,  hogy specifikusan
# valaszthatunk:  NEM  dobunk  el  bizonyos  tipusu  csomagokat, amiket magasabb
# prioritasu tarolokba  helyezunk el  (ssh, telnet  stb). Ez  azert van,  mert a
# csomagok  mindig  az  alacsonyabb  prioritasu  osztalybol  jonnek  elo azzal a
# kikotessel,  hogy  a  csomagok  meg  minden osztalybol egyforman egy minimalis
# mertekben jonnek ki (ebben a szkriptben minden tarolo legalabb a  tisztesseges
# 1/7 savszelessegnyivel A TCP csomag  eldobasa egy kapcsolaton belul a  fogadas
# alacsonyabb mertekehez vezet, a torlodas-elkerulo algoritmus miatt.
#
#     *  Semmit  nem  nyerunk  a  nem-TCP  csomagok  eldobasaval.  Valojaban, ha
#     fontosak  voltak,  ugyis  ujra  elkuldik  oket, igy megprobaljuk azt, hogy
#     sosem dobjuk el oket. Ez azt jelenti, hogy a telitett TCP kapcsolatok  nem
#     befolyasoljak  negativan  azokat  a  protokollokat,  amelyeknel  nincs   a
#     TCP-hez hasonlo beepitett ujrakuldes.
#     
#     * A TCP kapcsolatok lelassitasa  ugy, hogy a teljes bejovo  rata kevesebb,
#     mint az eszkoz  valos kapacitasa AZT  OKOZHATJA, hogy keves  vagy egyetlen
#     csomag   sem   all   varakozosorba   a   szolgaltatoi   oldalon    (DSLAM,
#     kabel-koncentrator  stb).   Mivel  ezek  a  sorok  kepesek  megtartani   4
#     masodpercnyi adatot 1500Kbps sebessegen  vagy 6 megabitnyi adatot,  ha egy
#     csomag sem all sorba, az alacsonyabb lappangast okoz.
#
# Kikotesek (kerdesfeltevesek a teszteles elott):
# * A bejovo forgalom ezen a modon valo korlatozasa gyenge TCP-teljes�tmenyt ad?
#	- Az elozetes valsz: nem! Ugy nez ki, hogy az ACK csomagok prioritasanak 
#	beallitasa (kicsi <64b) anelkul  maximaljuk a kimeno telesitmenyt,  hogy
#	nem  vesztunk  savszelesseget a mar meglevo ujrakuldott  csomagok miatt.

# Megjegyzes: a kovetkezo konfiguracio jol mukodik az en beallitasaimmal:
# 1.5M/128K ADSL a Pacific Bell Internet-en keresztul (SBC Global Services)

DEV=eth0
RATEUP=90
RATEDN=700  	# Figyeld meg, hogy ez jelntosen kisebb mint az 1500-as kapacitas.
		# Emiatt nem kell a bejovo  forgalom korlatozasaval torodnod, amig
		# nem hasznalhatunk  jobb megvalositast,  mint p�ld�ul a TCP ablak
		# manipulacioja.
# 
# konfiguracios beallitasok vege
#

if [ "$1" = "status" ]
then
        echo "[qdisc]"
        tc -s qdisc show dev $DEV
        tc -s qdisc show dev imq0
        echo "[class]"
        tc -s class show dev $DEV
        tc -s class show dev imq0
        echo "[filter]"
        tc -s filter show dev $DEV
        tc -s filter show dev imq0
        echo "[iptables]"
        iptables -t mangle -L MYSHAPER-OUT -v -x 2> /dev/null
        iptables -t mangle -L MYSHAPER-IN -v -x 2> /dev/null
        exit
fi

# Mindent visszaalitunk alapallapotba (torlunk)
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev imq0 root 2> /dev/null > /dev/null
iptables -t mangle -D POSTROUTING -o $DEV -j MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -D PREROUTING -i $DEV -j MYSHAPER-IN 2> /dev/null > /dev/null
iptables -t mangle -F MYSHAPER-IN 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-IN 2> /dev/null > /dev/null
ip link set imq0 down 2> /dev/null > /dev/null
rmmod imq 2> /dev/null > /dev/null

if [ "$1" = "stop" ] 
then 
        echo "Shaping removed on $DEV."
        exit
fi

###########################################################
#
# Kimeno korlatozas (a teljes savszelesseg RATEUP-ra allitva)

# a varakozosor meretet ugy allitjuk be, hogy kb. 2 mp lappangas legyen az alacsony
# prioritasu csomagoknal
ip link set dev $DEV qlen 30

# a kimeno eszkozon MTU-t allitunk. Az MTU csokkentese alacsonyabb lappangast 
# ad, de valamivel kisebb kimeno teljesitmenyt is az IP es TCP protokoll 
# felulvezerlese miatt

ip link set dev $DEV mtu 1000

# a HTB-t gyoker qdisc-nek allitjuk be
tc qdisc add dev $DEV root handle 1: htb default 26

# hozzaadjuk a fobb korlatozo osztalyokat
tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit

# hozzadjuk  az  alosztalyokat  -  garantaljuk  minden  osztalynak  LEGALABB   a
# "tisztesseges" osztozast  a savszelessegen.  Emiatt egy  osztalyt sem  fog egy
# masik kieheztetni.  Ezenkivul mindegyik  osztaly hasznalhatja  a rendelkezesre
# allo savszelesseget, ha a tobbi nem hasznalja.

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[$RATEUP/7]kbit ceil ${RATEUP}kbit prio 0
tc class add dev $DEV parent 1:1 classid 1:21 htb rate $[$RATEUP/7]kbit ceil ${RATEUP}kbit prio 1
tc class add dev $DEV parent 1:1 classid 1:22 htb rate $[$RATEUP/7]kbit ceil ${RATEUP}kbit prio 2
tc class add dev $DEV parent 1:1 classid 1:23 htb rate $[$RATEUP/7]kbit ceil ${RATEUP}kbit prio 3
tc class add dev $DEV parent 1:1 classid 1:24 htb rate $[$RATEUP/7]kbit ceil ${RATEUP}kbit prio 4
tc class add dev $DEV parent 1:1 classid 1:25 htb rate $[$RATEUP/7]kbit ceil ${RATEUP}kbit prio 5
tc class add dev $DEV parent 1:1 classid 1:26 htb rate $[$RATEUP/7]kbit ceil ${RATEUP}kbit prio 6


# az  alosztalyokhoz  qdisc-eket adunk - SFQ-t adunk  minden osztalyhoz. Az SFQ 
# biztositja,  hogy minden osztalyon  belul a kapcsolatokat (majdnem) egyenloen 
# kezeljuk.


tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 10
tc qdisc add dev $DEV parent 1:22 handle 22: sfq perturb 10
tc qdisc add dev $DEV parent 1:23 handle 23: sfq perturb 10
tc qdisc add dev $DEV parent 1:24 handle 24: sfq perturb 10
tc qdisc add dev $DEV parent 1:25 handle 25: sfq perturb 10
tc qdisc add dev $DEV parent 1:26 handle 26: sfq perturb 10

# az fwmark-kal  szurjuk osztalyokba a   forgalmat - itt  a csomagon  beallitott
# fwmark-nak megfeleloen iranyitjuk a forgalmat az osztalyokba (az fwmark-ot  az
# iptables  segitsegevel  kesobb  allitjuk  be).  Figyeld  meg,  hogy fentebb az
# alapertelmezett  prioritasu  osztalyt  1:26-ra  allitottuk,  igy  a nem jelolt
# csomagok (vagy a nem  ismert ID-ju csomagok) alapertelmezesben  az alacsonyabb
# prioritasu osztalyba mennek.

tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:22
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 23 fw flowid 1:23
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 24 fw flowid 1:24
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 25 fw flowid 1:25
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26

#
# a MYSHAPER-OUT lanc hozzadasa az  iptables "mangle" tablajahoz - ez beallitja 
# azt a tablat,	amit a csomagok szuresehez es megjelolesehez hasznalunk.

iptables -t mangle -N MYSHAPER-OUT
iptables -t mangle -I POSTROUTING -o $DEV -j MYSHAPER-OUT

# a fwmark ertekek  beallitasa a kulonbozo  tipusu forgalomhoz - a  fwmark-ot 20-26 
# kozottire allitjuk a kivant osztalynak megfeleloen. A 20 a legmagasabb prioritas.

iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 0:1024 -j MARK --set-mark 23 # Alapertek az 
# alacsony portokon zajlo forgalomhoz
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 0:1024 -j MARK --set-mark 23 # "" 
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 20 -j MARK --set-mark 26     # ftp-data port, alacsony prioritas
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 5190 -j MARK --set-mark 23   # aol instant messenger
iptables -t mangle -A MYSHAPER-OUT -p icmp -j MARK --set-mark 20               # ICMP (ping) - magas prioritas, baratok ismertetojegye
iptables -t mangle -A MYSHAPER-OUT -p udp -j MARK --set-mark 21                # DNS nevfeloldas (kis csomagok)
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport ssh -j MARK --set-mark 22    # secure shell
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport ssh -j MARK --set-mark 22    # secure shell
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport telnet -j MARK --set-mark 22 # telnet (ew...)
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport telnet -j MARK --set-mark 22 # telnet (ew...)
iptables -t mangle -A MYSHAPER-OUT -p ipv6-crypt -j MARK --set-mark 24         # IPSec - viszont nem tudjuk, mi a "hasznos teher"...
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport http -j MARK --set-mark 25   # helyi webszerver
iptables -t mangle -A MYSHAPER-OUT -p tcp -m length --length :64 -j MARK --set-mark 21 # kis csomagok (valoszinuleg csak ACK-k)
iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26      # redundans- jeloljunk minden nem jelolt csomagot 26-tal (alacsony prioritas)

# vegeztunk a kimeno korlatozassal
#
####################################################

echo "Outbound shaping added to $DEV.  Rate: ${RATEUP}Kbit/sec."

# tavolitsd el a megjegyzest a kovetkezo sor elol, ha csak kimeno forgalomszabalyozast akarsz
# exit

####################################################
#
# Bejovo korlatozas (a teljes savszelesseg RATEDN-re allitva)

# megnezzuk, hogy az imq modul betoltodott-e

modprobe imq numdevs=1

ip link set imq0 up

# a qdisc hozzadasa - alapertelmezett alcsony prioritasu 1:21-es osztaly

tc qdisc add dev imq0 handle 1: root htb default 21

# a fo korlatozo osztalyok hozzaadasa
tc class add dev imq0 parent 1: classid 1:1 htb rate ${RATEDN}kbit

# alosztalyok hozzaadasa - TCP forgalom a 21-ben, nem-TCP forgalom a 20-ban
#
tc class add dev imq0 parent 1:1 classid 1:20 htb rate $[$RATEDN/2]kbit ceil ${RATEDN}kbit prio 0
tc class add dev imq0 parent 1:1 classid 1:21 htb rate $[$RATEDN/2]kbit ceil ${RATEDN}kbit prio 1

# az alosztalyokhoz qdisc-eket  adunk - SFQ-t adunk minden osztalyhoz. Az SFQ 
# biztositja, hogy minden osztalyon belul a kapcsolatokat (majdnem) egyenloen 
# kezeljuk.

tc qdisc add dev imq0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev imq0 parent 1:21 handle 21: red limit 1000000 min 5000 max 100000 avpkt 1000 burst 50

# az fwmark-kal  szurjuk osztalyokba  a forgalmat  - itt  a csomagon  beallitott
# fwmark-nak megfeleloen iranyitjuk a forgalmat az osztalyokba (az fwmark-ot  az
# iptables  segitsegevel  kesobb  allitjuk  be).  Figyeld  meg,  hogy fentebb az
# alapertelmezett  prioritasu  osztalyt  1:21-re  allitottuk,  igy  a nem jelolt
# csomagok (vagy a nem  ismert ID-ju csomagok) alapertelmezesben  az alacsonyabb
# prioritasu osztalyba kerulnek.


tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21


# a MYSHAPER-IN lanc hozzadasa az iptables "mangle" tablajahoz - ez beallitja azt a tablat,
#		amit a csomagok szuresehez es megjelolesehez hasznalunk.

iptables -t mangle -N MYSHAPER-IN
iptables -t mangle -I PREROUTING -i $DEV -j MYSHAPER-IN

# a fwmark ertekek beallitasa a kulonbozo tipusu forgalomhoz - a fwmark-ot 20-26 kozottire
#		allitjuk a kivant osztalynak megfeleloen. A 20 a legmagasabb prioritas.


iptables -t mangle -A MYSHAPER-IN -p ! tcp -j MARK --set-mark 20              # A nem-tcp csomagokat a legnagyobb prioritasura allitja
iptables -t mangle -A MYSHAPER-IN -p tcp -m length --length :64 -j MARK --set-mark 20 # rovid TCP csomagok, valoszinuleg ACK-k
iptables -t mangle -A MYSHAPER-IN -p tcp --dport ssh -j MARK --set-mark 20    # secure shell
iptables -t mangle -A MYSHAPER-IN -p tcp --sport ssh -j MARK --set-mark 20    # secure shell
iptables -t mangle -A MYSHAPER-IN -p tcp --dport telnet -j MARK --set-mark 20 # telnet (ew...)
iptables -t mangle -A MYSHAPER-IN -p tcp --sport telnet -j MARK --set-mark 20 # telnet (ew...)
iptables -t mangle -A MYSHAPER-IN -m mark --mark 0 -j MARK --set-mark 21              # redundans- minden nem jelolt csomagot 21-el jelolunk (alacsony prioritas)

# vegul utasitjuk ezeket a csomagokat, hogy menjenek keresztul a fent beallitott imq0-on

iptables -t mangle -A MYSHAPER-IN -j IMQ

# vegeztunk a bejovo forgalommal
#
####################################################

echo "Inbound shaping added to $DEV.  Rate: ${RATEDN}Kbit/sec."

5. Az �j v�rakoz�sor tesztel�se

A legk�nnyebben azzal tesztelheted az �j be�ll�t�st, hogy tel�ted a felfel� ir�nyul� �gat alacsony priorit�s� forgalommal. Ez a priorit�sok be�ll�t�s�t�l f�gg. A p�lda kedv��rt, mondjuk a telnet �s a ping forgalmat helyezted magasabb priorit�sba (alacsonyabb fwmark), a t�bbi magasabb portot (amik FTP �tvitelhez stb. haszn�latosak) pedig alacsonyabba. Ha ind�tasz egy FTP felt�lt�st a kifel� men� s�vsz�less�g tel�t�s�re, csak a gateway fel� (a DSL vonal m�sik fel�n l�v�) men� ping id�k kis m�rt�k� n�veked�s�t tapasztalhatod, �sszehasonl�tva a priorit�sos v�r�sor n�lk�li �rt�kekkel. A 100 ms alatti ping id�k tipikusak att�l f�gg�en, hogyan �ll�tottad be a dolgokat. Az egy vagy k�t m�sodpercn�l nagyobb id�k val�sz�n�leg az jelzik, hogy nem m�k�dnek rendben a dolgok.

6. Rendben, m�k�dik! Hogyan tov�bb?

Most, hogy sikeresen elkezdt�l gazd�lkodni a s�vsz�less�geddel, elgondolkodhatsz azon, hogyan haszn�lod ki. V�g�l is, val�sz�n�leg fizetsz �rte!

Gnutella kliens haszn�lata �s F�JLJAID MEGOSZT�SA a h�l�zat teljes�tm�ny�nek kedvez�tlen befoly�sol�sa n�lk�l.
Web szervert futtathatsz an�lk�l, hogy a weblapok kiszolg�l�sa lelass�tan� a Quake partit.

7. Kapcsol�d� hivatkoz�sok

Bandwidth Controller for Windows - http://www.bandwidthcontroller.com
dsl_qos_queue - (b�ta) Linuxhoz. Nincs kernel-foltoz�s, �s jobb a teljes�tm�ny.