Het Wonder Shaper is een heel speciaal netwerk shaper script met veel functies. Werkt op Linux 2.4 en hoger.
Doelen
Ik heb geprobeerd om de heilige graal te maken:
* Handhaving van lage latency voor interfactive verkeer te allen tijde.
Dit betekent dat het downloaden of uploaden van bestanden niet SSH of telnet moeten verstoren. Dit zijn de belangrijkste dingen, zelfs 200ms latency is traag om over te werken.
* Laat 'surfen' tegen redelijke snelheid, terwijl up of downloaden
Hoewel http is 'bulk' verkeer, mag het overige verkeer niet overstemmen het uit te veel.
* Zorg ervoor dat upload niet downloads schaden, en andersom
Dit is een veel waargenomen fenomeen waarbij upstream het verkeer gewoon vernietigt download snelheid. Het blijkt dat dit alles mogelijk, ten koste van een klein beetje bandbreedte. De reden dat de uploads, downloads en ssh kwetsen elkaar is de aanwezigheid van grote wachtrijen in vele binnenlandse toegang apparaten zoals kabel of DSL-modems.
Waarom het werkt niet goed standaard
ISP's weten dat ze uitsluitend worden vergeleken over hoe snel mensen kunnen downloaden. Naast de beschikbare bandbreedte, is download snelheid sterk beïnvloed door packet loss, die TCP / IP prestaties ernstig belemmert. Grote wachtrijen kan helpen packetloss voorkomen en te versnellen downloads. Dus ISPs configureren grote wachtrijen.
Deze grote wachtrijen interactiviteit beschadigen echter. Een druk op de knop moet eerst reizen de upstream wachtrij, die kunnen worden seconden (!) Lang en ga naar je remote host. Vervolgens wordt getoond, die leidt tot een pakket terug, dat dan moet doorkruisen de stroomafwaartse rij, gelegen binnen ISP, voordat het op het scherm weergegeven.
Deze HOWTO leert je hoe je mangel en verwerken van de wachtrij op vele manieren, maar helaas, niet alle wachtrijen toegankelijk zijn voor ons. De wachtrij over bij de ISP is volledig off-limieten, terwijl de upstream wachtrij waarschijnlijk leeft in je kabelmodem of DSL-apparaat. Je kan wel of niet in staat zijn om het te configureren. Waarschijnlijk niet.
Dus, wat nu? Omdat we niet kunnen controleren een van deze wachtrijen, moeten ze worden geëlimineerd, en verhuisde naar je Linux router. Gelukkig is dit mogelijk.
Limiet uploadsnelheid enigszins
Door de beperking van onze uploadsnelheid iets minder dan de werkelijk beschikbare snelheid worden geen wachtrijen opgebouwd in modem. De wachtrij wordt nu verplaatst naar Linux.
Limiet downloadsnelheid
Dit is iets lastiger als we kunnen niet echt invloed op hoe snel het internet schepen ons data. We kunnen echter dalen pakketten die komen te snel, waardoor TCP / IP te vertragen tot slechts het tarief we willen. Omdat we niet willen het verkeer onnodig vallen, we configureren van een 'burst' grootte we toestaan dat bij hogere snelheid.
Nu, als we dit hebben gedaan, hebben we de downstream wachtrij volledig geëlimineerd (behalve voor korte uitbarstingen), en krijgen de mogelijkheid om de upstream-wachtrij beheren met alle macht Linux biedt.
Laat interactieve verkeer sla de wachtrij
Wat nog gedaan moet worden is om ervoor te zorgen dat interactieve verkeer springt naar de voorkant van de upstream wachtrij. Om ervoor te zorgen dat de upload niet downloads pijn doen, gaan we ook ACK pakketten naar de voorkant van de wachtrij. Dit is wat normaal oorzaken van de enorme vertraging waargenomen bij het genereren van bulk verkeer in beide richtingen. De Dankwoord voor downstream verkeer moet concurreren met upstream verkeer en raken vertraagde in het proces.
We gaan ook andere kleine pakketten naar de voorkant van de wachtrij - dit helpt besturingssystemen die niet ingesteld TOS bits, zoals alles van Microsoft.
Laat de gebruiker toe om verkeer van lage prioriteit te geven (nieuw in 1.1!)
Soms kunt u een lage prioriteit uitgaand verkeer opmerken vertragen belangrijk verkeersknooppunt. In dat geval kan de volgende opties die u kunnen helpen:
NOPRIOHOSTSRC
Stel deze op hosts of netmasks in uw netwerk dat lage prioriteit zou moeten hebben
NOPRIOHOSTDST
Stel deze op hosts of netmaskers op het internet die lage prioriteit zou moeten hebben
NOPRIOPORTSRC
Stel deze in op de bron poorten die lage prioriteit zou moeten hebben. Als u een onbelangrijke webserver op uw verkeer, zet u dit op 80
NOPRIOPORTDST
Zet dit op bestemming poorten die lage prioriteit zou moeten hebben.
Zie het begin van wshaper en wshaper.htb
Resultaten
Als we dit alles krijgen we de volgende metingen met behulp van een goede ADSL-verbinding van XS4ALL in Nederland:
Baseline latency:
round-trip min / gem / max = 14.4 / 17.1 / 21.7 ms
Zonder verkeer conditioner, tijdens het downloaden:
round-trip min / gem / max = 560,9 / 573,6 / 586,4 ms
Zonder verkeer conditioner, tijdens het uploaden:
round-trip min / gem / max = 2041,4 / 2332,1 / 2427,6 ms
Met conditioner, tijdens 220kbit / s upload:
round-trip min / gem / max = 15,7 / 51,8 / 79,9 ms
Met conditioner, tijdens 850kbit / s download:
round-trip min / gem / max = 20,4 / 46,9 / 74,0 ms
Bij het uploaden, downloads gaan bij ~ 80% van de beschikbare snelheid. Upload op ongeveer 90%. Wachttijd springt dan naar 850 ms, nog uitzoeken waarom.
Wat je kunt verwachten van dit script hangt sterk af van uw werkelijke uplink snelheid. Bij het uploaden op volle snelheid, zal er altijd een enkel pakket te zijn voorsprong op uw aanslag. Dat is de ondergrens voor de latentie kan bereiken - onderverdelen MTU door uw upstreamsnelheid te berekenen. Typische waarden wat hoger zijn dan dat. Verlaag uw MTU voor een beter effect!
Een kleine tafel:
Uplink snelheid | Verwachte latency vanwege uploaden
--------------------------------------------------
32 | 234ms
64 | 117ms
128 | 58ms
256 | 29ms
Dus om uw effectieve latency te berekenen, neem een nulmeting (ping op een onbelaste link), en zoek het nummer in de tabel, en voeg deze toe. Dat is ongeveer het beste wat je kan verwachten. Dit aantal komt uit een berekening die ervan uitgaat dat je stroomopwaarts toetsaanslag vooruit zal hebben hooguit een half full sized pakket.
Dit komt neer op:
mtu * 0,5 * 10
-------------- + Baseline_latency
kbit
De factor 10 is niet helemaal correct, maar werkt goed in de praktijk.
Uw kernel
Als je een recente distributie uitvoert, moet alles ok. U moet 2.4 met QoS opties ingeschakeld.
Als u uw eigen kernel te compileren, moet het enkele opties ingeschakeld. Het meest opvallend is, in het menu Networking Options, QoS en / of Fair Queueing, draaien tenminste CBQ, PRIO, SFQ, Ingress, Traffic Policing, QoS-ondersteuning, Rate Estimator, QoS classifier, U32 classifier, fwmark classifier.
In de praktijk, ik (en de meeste distributies) slaat gewoon op alles.
De scripts
Het script komt in twee versies, één die werkt op standaard kernels en wordt geïmplementeerd met behulp van CBQ. De andere gebruikt onberispelijke HTB qdisc die niet in de standaard kernel. De CBQ versie is meer getest dan de HTB een!
Zie 'wshaper' en 'wshaper.htb'.
Stemming
Deze scripts nodig hebt om de 'echte' snelheid van uw ISP-verbinding kennen. Dit is moeilijk om te bepalen upfront als verschillende ISP's maken gebruik van verschillende soorten stukjes lijkt het. Mensen melden succes met de volgende techniek:
Schat zowel uw upstream en downstream op de helft van het tarief van uw ISP specificeert. Nu controleren of het script werkt - controleer interactiviteit tijdens het uploaden en tijdens het downloaden. Dit zou de latentie leveren zoals hierboven berekend. Zo niet, controleer dan of het script uitgevoerd zonder fouten.
Nu langzaam de upstream en downstream-nummers in het script tot de latency terugkomt. Deze manier kunt u optimale waarden voor uw verbinding te vinden. Als u tevreden bent, meldt u zich bij mij, dus ik een lijst van nummers die goed werken kan maken. Laat het me weten welke provider u gebruikt en de naam van uw abonnement, en zijn befaamde specificaties, dus ik kan u hier een lijst van en op te slaan anderen de moeite.
Installatie
Als u kiest, kunt u het script om /etc/ppp/ip-up.d kopiëren en het zal bij elke verbinding worden uitgevoerd.
Als u wilt de shaper van een interface te verwijderen, run 'wshaper stop'. Om statusinformatie, lopen 'wshaper status "te zien.
BEKENDE PROBLEMEN
Als je fouten krijgt, voeg een -x naar de eerste regel, als volgt:
#! / Bin / bash -x
En probeer het opnieuw. Dit zal u laten zien welke lijn een fout geeft. Voordat u contact met mij, zorg ervoor dat u werkt met een recente versie van iproute!
Recente versies zijn te vinden op uw Linux-distributeur, of als u liever compileren, hier:
ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz
Reacties niet gevonden