20080128Traffic shaping
Avagy magyarul forgalomformálás. Ezen (a felhasználók számára) piszkos húzással az internetszolgáltatók (angolul ISP-k) szoktak élni. Nagy vonalakban arról szól, hogy a torrent – mivel most divat – nagyon nagy sávszélességet eszik az internet egészéből, és ez elveszi a sávszélességet a “rendes” böngészőktől. Ez a forgalom a teljes forgalom majdnem 60-80%-a. Ezt azzal próbálják kompenzálni, hogy kiszűrik a torrent (és egyéb p2p) forgalmat a fogadott csomagok közül, és késleltetik azok célbaérését. Általában egyszerű dolguk van, mert az átlagfelhasználó nem állítgat portokat, nem titkosítja az adatcsatornáit, így könnyű kiszúrni az “illegális” adatforgalmát. Ha ilyen bolyt talál a rendszerük, ahol sokan torrenteznek, és emellett még más forgalom is van, akkor a garantált sebesség kárára csökkentik a torrentes forgalmat. Ergo a torrent lassulni fog, hogy a nem P2P forgalom sebessége konstans maradhasson.
Sokan sokfélét mondanak, mivel és hogyan érdemes tölteni, mit érdemes beállítani. Ezekhez a véleményekhez szeretnék egyet hozzáadni, hátha valakinek épp ez fog segíteni, és sikerül levennie a szolgáltatója válláról a csomagjai válogatásának nyűgös feladatát. 
Az elsődleges prioritás az UDP és a TCP portot átállítani az alapértelmezett 6881-ről valami nagyobbra, mondjuk a 49125-65535-ös tartományban egy tetszőleges számra. Vagy pedig beállíthatjuk, hogy random portot adjon meg a kliens minden indításkor. Ha routerünk van, ez kicsit macerásabb, mert ugye a NAT port forwarding-ot is át kell állítgatni minden egyes portváltásnál, úgyhogy a random portot routernél hanyagolhatjuk. A következő a P2P protokoll titkosítása, amit a különböző kliensek protocol encryption beállításával tehetünk aktívvá. Titkosíthatjuk csak a küldött adatok fejléceit, de ezt könnyű kiszűrni. Vigyázni kell, hogy így a nem titkosított, vagy nem RC4-el titkosító klienssel rendelkező peer-eket kizárhatjuk, emiatt érdemes a legacy bejövőket aktívon hagyni. A következő lépés a lazy_bitfield aktiválása. Ezt a frissebb kliensek már tudják, és annyit tesz, hogy a szolgáltató komplett bitfield blokkolását és lezárását kerüli. Mégpedig úgy, hogy mindig kamu félkész bitfield-et küld, és a HAVE-eken keresztül küldi a peer-eknek a completed üzeneteket.
Tudnék ajánlani alternatív klienseket is, de míg az Azureus (most már Vuze) rengeteg prociidőt eszik a java platformja miatt, ezért ez emiatt nem ajánlott, addig a Deluge túl instabil winfos alatt, és ezért bukó. Az µTorrent elfogadottan kis hely- és prociigényű, tudja a titkosítást, a port átállítást és a lazy bitfield-et. Az én voksom rajta van.
Természetesen tudjuk optimalizálni a gépünkre beérkező adatfolyamot, egy cFosSpeed nevű programmal. A rövid ismertetőjét itt találhatjátok, mert témába is vág, és ez is egyfajta traffic shaping, csak ez felhasználóoldali. A programért külön köszönet illeti Mad-R-t. Köszönöm!
Amikor letöltünk egy file-t az internetről az valójában nem csak a letöltési, hanem a feltöltési águnkat is igénybe veszi. Hogyan lehet ez? Egyszerű: a letöltésre kiválasztott file nem egy darabban érkezik meg hozzánk, hanem csomagokra bontva. De amíg ezek a csomagok eljutnak a küldő féltől hozzánk, addig számos dolog történhet velük: pl. elvesznek, megsérülnek stb. Többek között ezért vannak az ún. ACK (ACKnowledgment) csomagok. Amikor 1-1 adatcsomag/csomagcsoport megérkezik hozzánk, erről a küldő fél értesül az ACK csomagok révén. Tehát, amikor letöltünk, akkor fel is töltünk, hiszen informálnunk kell a küldő felet, hogy rendben megérkeztek-e a csomagok.
Mit jelent ez a gyakorlatban?
Nagyjából annyit, hogy egy 2Mbit-es letöltési ágú kapcsolatnál a maximális letöltés közben (kb. 270KB/s) legalább 7, de általában 8-10KB/s feltöltést is elhasználunk, illetve elhasználnak az ACK csomagok. Tehát 270KB/s letöltésre jut 8-10KB/s feltöltés. Ellene nem tehetünk semmit, ilyen a protokoll.
Ez alapvetően nem lenne baj, de a kutya ott van elásva, hogy a legtöbb otthoni internet-csomagnak a relatív nagy letöltési ágára szinte nevetségesen kevés feltöltési sávszélesség jut. Így a fenti példánál maradva a maximális letöltéssel elhasználtunk a feltöltési ~24KB/s-ból 10-et. Ez sajnos elég nagy érvágás, de van még egy dolog: amikor pl. file-cserélő hálózatot használunk, akkor a letöltés mellett feltöltések is vannak. Ezek viszont sokkal inkább kikezdik a vonalunkat, mint a letöltések. Miért? Egyszerű: amikor mi küldünk csomagokat (feltöltünk) nekünk is vissza kell kapnunk az ACK csomagokat, de erre ott a relatív nagy keresztmetszetű letöltési águnk. Viszont, amikor letöltünk, akkor a már amúgy is agyonterhelt és kis keresztmetszetű feltöltési ágon kellene kijutniuk a csomagoknak.Tehát akkor hogyan segít a cFosSpeed?
Úgy, hogy a dinamikus átvitelkezelő mechanizmusával (dynamic traffic shaping) folyamatosan figyeli, hogy mekkora letöltésre mekkora feltöltés jut, és csak akkora feltöltési sebességet enged, amennyi mellett még “megállás” nélkül vissza tudnak menni a letöltésünk ACK csomagjai. Így a letöltés folyamatosan a lehető leggyorsabb lesz, és mellette a feltöltési águnkból megmaradt összes sávszélességet is hasznosítani tudjuk, pl. torrentnél visszaosztásra, DC++-nál pedig feltöltésre.
Alapvetően a file-cserélő hálózatoknál elég ritka, hogy ki tudjuk használni a teljes letöltési águnkat, ami azért a megabitek korában már nem akkora szívfájdalom. Viszont így már kevesebb ACK-t kell küldenünk, ami azt jelenti, hogy egy 2Mbit-es kapcsolat esetén 130-150KB/s letöltés mellett ~20KB/s-mal tudunk visszaosztani, ami már egy jó eredmény, de még fontosabb, hogy miután a letöltéssel készen vagyunk, a feltöltés maximalizálódik, így nem kell állandóan a kliensünkben matatni, hogy most hány K-ra korlátozzak, vagy ha a letöltés elkészül, akkor meg pocsékba megy egy jelentős feltöltési sávszélesség stb. Így sokkal kényelmesebben sokkal többet tudunk a letöltések mellett feltölteni, és nem kell ecsetelnem, hogy ez milyen jó dolog.
Természetesen a szolgáltatóoldali fékezésen ez a program sem tud effektíve segíteni, de a meglévő sávszélességet effektíven optimalizálni tudja. Ezért egy próbát megér, hátha. Kipróbálható még egy patch, ami a TCPIP.SYS file-ban található maximális 10 letöltést 50-re (vagy tetszőleges mértékűre) állítja.
Az Azureus Wiki oldalán található egy lista, ahol a forgalomfékező internetszolgáltatók szégyenfala található. A lista természetesen bővíthető, miután beajánlkoztunk az irc csatornájukon. (irc.freenode.net #azureus-wiki csatorna)
A wikipédián talált szócikkek szépen vezetik le, hogy miért nem kellene a szolgáltatóknak leszabályozni a felhasználóit, korlátozni a nethasználatukat.
A Torrentfreak.com oldalon mindenki megtalálhatja a kedvenc torrentprogramjának sávszélességre való optimalizálását, titkosítását, és egyéb finombeállításokat. Sőt, kezdőknek mindenféle trackeroldalakat is linkelnek.
Én az UPC-nél vagyok, és itt korlátoznak, de rendesen. A teljes 640 kbyte-os sávszélességből mindössze 80-100 kbyte-tal jött le a tesztfile, pedig vagy tízezren seed-elték. Csákányi László barátom a DiGi-nél van, és nála előfordulnak 1,1 megabyte-os letöltések is. Neki 10 megabites kapcsolata van, nekem 5. Nála nincs korlát, amit át kellene ugrani.
Lazán kapcsolódó posztok:
10 hozzászólás
Nem kérek hozzászólást.
Loading ...
Bejegyzések
Mondjuk egy 10-20 megás e-book letöltésekor ez ugye nem annyira fájdalmas veszteség… aki pedig, nos, illegális játékon él és dvd ripeken, tudjon rá, hogy némelyeknek ez nem fog tetszeni, és megpróbálnak keresztbe tenni.
Milyen kár, hogy ennyivel lassabban tudnak letölteni azok, akik felzabálják a “a teljes forgalom majdnem 60-80%-át” azok elől, akik csak böngésznének, vagy ecet; pl. előlem.
Ezt mondta exer — 20080128 16:15 magasságában.
az ecetet nem értem. a vicc az egészben, hogy a upc hálózata elbírná a mostani felhasználók gigabites töltögetéseit. üvegszálas cucc van. így már kicsit árnyaltabb a dolog, nem? amúgy nem tudom, miért aggódsz, te tré online-on vagy.
Ezt mondta bachterman — 20080128 16:27 magasságában.
Aki 4-5 megabiten netel az valószínű, hogy nem csak az indexet nézegeti. Én sem azért fizettem rá elő
Köszi az írást, mostmár tiszta hogy micsinál ez a céfos cucc
Ezt mondta lemegyek — 20080128 19:21 magasságában.
szerintem meg épp ez lenne a normális. online rádiót hallgatva böngészni, letölteni, akár két embernek is.
zsindexet meg csakazért sem nézegetek.
Ezt mondta bachterman — 20080128 19:35 magasságában.
ecetre itt most a mindenmást, sztrímes vackokat, méleket, satöbbit értettem. és nem szolgáltatóoldali leterhelésre gondoltam, hanem ami a gerincen megy, teccikérteni
pl. itt tirpákhonban mikor a fősuli kolijában az lett a policy, hogy külső dc hubra kirúgás terhe mellett nem javallott felkúszni, hirtelen kolin kívül is élvezhetőbb lett a net. titkolt büszkeséggel mondom, hogy csak a 3-as koli adatforgalomban odavágta a full bme-t 
néha vagyok tréon. nézd csak meg az előző, mostani kommentemnél az ip-t a ripe.net-en!
Ezt mondta exer — 20080128 20:37 magasságában.
szerintem mindenkinek joga van azt csinálni az adott szolgáltatással, amit akar vele. természetesen a szerződés keretén belül. de ha a szerződésben nincs benne ez a korlátozás, akkor milyen jogon bábáskodik a felhasználója felett? az artisjus, riaa és más fasszopó jogvédő szervezetek lobbizását érzem emögött az ügymenet mögött…
a koliban azért ne warezkodjunk. azt tudtad-e, hogy a victor hugo napi 42 gigájából durván 40 giga p2p?
mostani ip: auch! a vodafon…
)
(teljesen más tészta, de ideírom, hogy lesz február felé a hashashin’s creed-ből pc verzió is
Ezt mondta bachterman — 20080128 20:46 magasságában.
victor hugo aszittem nem írt 42 gigányit
szoktam amúgy lenni harmadik isp-ről is – mikor hova magyek, hehe -, de azt majd ne írd már ki 
(assassinkodást lehet, hogy meg fogom venni, de egyelőre úgy néztem, hogy ps kontrollerrel az igazi, én meg pc-n bill+egérrel játszom, ez egy elv; majd kiderül, hogyan oldják meg. de köszi a jelzést
)
Ezt mondta exer — 20080128 21:54 magasságában.
tessék megnézni a 20070910.-ei hírt. 50 GBps aggregált adatforgalom.
Ezt mondta bachterman — 20080129 13:24 magasságában.
el kéne bugázni a catalyst switchet, és elinni az árát
Ezt mondta exer — 20080129 13:43 magasságában.
és kinek adnád el? nekik?
Ezt mondta bachterman — 20080129 17:14 magasságában.