A Wonder Shaper egy nagyon speciális hálózati formálója script egy csomó funkciók. Működik a Linux 2.4 és magasabb.
Célok
Megpróbáltam, hogy megteremtse a szent grál:
* Fenntartása alacsony késleltetés a interfactive forgalom minden alkalommal.
Ez azt jelenti, hogy a letöltés vagy a fájlok feltöltése ne zavarják SSH vagy akár telnet. Ezek a legfontosabb dolgok, még 200ms latency lassú dolgozni felett.
* Hagyja "szörfözés" elfogadható sebességgel, míg fel vagy letöltés
Annak ellenére, http van "ömlesztve" közlekedés, a forgalom többi nem fulladtam ki túl sokat.
* Győződjön meg arról feltöltések nem károsítják a letöltéseket és fordítva
Ez egy sokkal megfigyelhető jelenség, amikor upstream forgalom egyszerűen tönkreteszi a letöltési sebesség. Kiderül, hogy mindez lehetséges, a költségek egy apró kis sávszélességgel. Az ok, hogy a feltöltések, letöltések és ssh fáj egymást a jelenléte nagy sorok számos hazai hozzáférési eszközök, mint a kábel vagy DSL modem.
Miért nem működik jól alapértelmezés
Internet-szolgáltatók tudják, hogy azok viszonyítani kizárólag milyen gyorsan tölthetnek le. Emellett a rendelkezésre álló sávszélesség, letöltési sebesség jelentősen befolyásolta a packet loss, ami súlyosan hátráltatja a TCP / IP teljesítményét. Nagy sorok segíthet megelőzni csomagvesztése, és gyorsítsa fel letöltéseket. Tehát internetszolgáltatók konfigurálni nagy sorok.
Ezek a nagy sorok azonban károsítja az interaktivitás. A gombnyomás először utazik az upstream sorban, amely lehet másodperccel (!) Hosszú, és menjen el a távoli gépen. Ezután megjelenik, ami egy csomag jön vissza, amelyet azután áthalad a downstream sorban található az internetszolgáltató, mielőtt megjelenik a képernyőn.
Ez a HOGYAN bemutatja, hogyan mángorló és feldolgozza a sorban sok szempontból, de sajnos nem minden sorok elérhető számunkra. A várólista fölött az internetszolgáltató teljesen off-határértékek, míg az upstream sorban valószínűleg él benne a kábelmodem vagy DSL-eszköz. Lehet, vagy nem tudja beállítani azt. Valószínűleg nem.
Szóval, mi a következő lépés? Mivel nem tudjuk ellenőrizni, sem e sorokat, akkor meg kell szüntetni, és költözött a Linux router. Szerencsére ez lehetséges.
Limit feltöltési sebesség némileg
Korlátozásával a feltöltési sebesség valamivel kevesebb, mint a valóban elérhető sebesség, nincs sorban állás épülnek fel a modemet. A várólistát költözött Linux.
Limit letöltési sebesség
Ez kissé bonyolultabb, mint mi, nem igazán befolyásolja, hogy milyen gyorsan az interneten hajók velünk adatok. Tudjuk azonban a csomagokat, hogy jönnek a túl gyors, ami TCP / IP lassítani, hogy csak az arány akarunk. Mert nem akar dobni a forgalom feleslegesen, akkor konfigurálja a "tört" méretű megengedjük a nagyobb sebességgel.
Most, ha már megtette ezt, már megszűnt a downstream sorban teljesen (kivéve a rövid kitörések), és átveheti képes kezelni az upstream sorban minden erejét Linux kínál.
Hadd interaktív forgalom kihagyja a sorban
Mit kell még tenni, hogy győződjön meg arról, interaktív forgalom ugrik az első a sorban upstream. Annak érdekében, hogy feltöltések ne bántsd letöltések, mi is mozog ACK csomagokat az első a sorban. Ez az, amit általában okozza a hatalmas visszaesés figyelhető meg, amikor generál nagy forgalmat mindkét irányban. A KÖSZÖNETNYILVÁNÍTÁS a későbbi forgalom kell versenyeznie upstream forgalom, és késleltetett a folyamatban.
Azt is mozgatni más kisebb csomagokat az első a sorban - ez segít operációs rendszerek, amelyeket nem állít TOS bitek, mint mindent a Microsoft.
Engedjük, hogy a felhasználó megadja az alacsony prioritású forgalom (új 1.1!)
Néha azt tapasztalhatja alacsony prioritású OUTGOING forgalom lassítása fontos forgalmat. Ebben az esetben a következő lehetőségek segíthet:
NOPRIOHOSTSRC
Állítsd be a házigazdák vagy netmasks a hálózaton, hogy legyen alacsony prioritású
NOPRIOHOSTDST
Állítsd be a házigazdák vagy netmasks az interneten, hogy legyen alacsony prioritású
NOPRIOPORTSRC
Állítsd be a forrás portot kell alacsony prioritást. Ha van egy jelentéktelen webserver a forgalom, ezt állítsa 80
NOPRIOPORTDST
Állítsd be a cél portok, hogy legyen alacsony prioritást.
Lásd kezdete wshaper és wshaper.htb
Eredmények
Ha mindezt megkapjuk a következő méréseket kiváló ADSL kapcsolatot XS4ALL Hollandia:
Baseline látencia:
oda-vissza min / avg / max = 14,4 / 17,1 / 21,7 ms
Nélkül a forgalom kondicionáló, letöltése közben:
oda-vissza min / avg / max = 560,9 / 573,6 / 586,4 ms
Nélkül a forgalom kondicionáló, feltöltése közben:
oda-vissza min / avg / max = 2041,4 / 2332,1 / 2427,6 ms
A kondicionáló, közben 220kbit / s feltöltési:
oda-vissza min / avg / max = 15,7 / 51,8 / 79,9 ms
A kondicionáló, közben 850kbit / s letöltési:
oda-vissza min / avg / max = 20,4 / 46,9 / 74,0 ms
Amikor feltöltésével, letöltések végbemenni ~ 80% -a rendelkezésre álló sebességet. Feltöltések körül 90%. Látencia majd ugrik 850 ms, még mindig kitalálni, hogy miért.
Mit várhat az idei script sok függ a tényleges feltöltési sebesség. Amikor feltöltésével teljes sebességgel, mindig lesznek egy-egy csomagba megelőzve a billentyűleütés. Ez az alsó határ a látencia érhet el - osztja meg MTU által az upstream sebesség kiszámításához. Tipikus értékek valamivel magasabb lesz ennél. Engedje meg MTU jobb hatást!
A kis asztal:
Feltöltési sebesség | Várhatóan látencia miatt feltölteni
--------------------------------------------------
32 | 234ms
64 | 117ms
128 | 58ms
256 | 29ms
Így kell kiszámítani a tényleges várakozási idő, hogy egy alapmérést (ping egy terheletlen link), és nézz fel a számot a táblázatban, és adja hozzá. Ez körülbelül a legjobb számíthat. Ez a szám jön egy számítás, amely azt feltételezi, hogy a upstream gombnyomás lesz, legfeljebb a fele a teljes méretű csomag előtt is.
Ez attól függ, hogy:
mtu * 0,5 * 10
-------------- + Baseline_latency
kbit
A 10-szeres nem egészen helyes, de a gyakorlatban jól működik.
A kernel
Ha fut egy közelmúltbeli forgalmazás, mindent meg kell ok. Be kell 2.4 a QoS opció be van kapcsolva.
Ha fordíthatsz saját kernelt, akkor kell valamilyen lehetőséget engedélyezve. Leginkább, a hálózati beállítások menüben, QoS és / vagy Fair Queueing, viszont legalább CBQ, PRIO, SFQ, Ingress, közlekedésrendészeti, QoS támogatás, Rate becslő, a QoS, U32 osztályozó, fwmark osztályozó.
A gyakorlatban azt (és a legtöbb disztribúció), csak kapcsolja be mindent.
A szkriptek
A script kétféle változatban, amelyik működik standard kernelre és valósítjuk meg CBQ. A másik használ a kiváló HTB qdisc amely nem az alapértelmezett kernel. A CBQ verzió több tesztelték, mint a HTB egy!
Lásd "wshaper" és a "wshaper.htb".
Hangolás
Ezek a szkriptek kell tudni a "valódi" aránya az ISP-kapcsolat. Ez nehéz meghatározni előre a különböző internetszolgáltatók használnak különböző bitek tűnik. Az emberek jelenteni siker az alábbi módon:
Becsüljük mind a upstream és downstream a fele az arány az ISP Megadja. Most ellenőrizze, ha a script működik - ellenőrizze az interaktivitás feltöltése közben és a letöltés közben. Ez kellene valósítania a látencia a fentiek szerint kiszámított. Ha nem, ellenőrizze, hogy a script végre hiba nélkül.
Most lassan növelje az upstream és downstream számok a script, amíg a várakozási idő jön vissza. Így találhat optimális értékek a kapcsolat. Ha elégedett, kérjük jelezze nekem úgy tudom, hogy a fenti számok, hogy jól működik. Kérem, engedje meg, hogy melyik ISP használja a nevét, az előfizetés, és neves leírások, így tudok felsorolni itt, és mentse mások a baj.
Telepítés
Ha felhívod az, akkor másolja a forgatókönyvet, hogy /etc/ppp/ip-up.d és futni fog minden connect.
Ha azt szeretnénk, hogy távolítsa el a formálója egy csatoló, fuss "wshaper stop '. Ha látni állapotáról, fuss "wshaper állapot".
ISMERT PROBLÉMÁK
Ha hibaüzenetet kapsz, add egy -x, hogy az első sorban, az alábbiak szerint:
#! / Bin / bash -x
És próbálkozzon újra. Ez mutatja, hogy melyik vonalon hibát ad. Mielőtt kapcsolatba velem, győződjön meg arról, hogy fut egy újabb verziója a iproute!
Az újabb változatok megtalálható a Linux forgalmazó, vagy ha jobban összeállítása, itt:
ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz
Hozzászólás nem található