Wonder Shaper er et meget specielt netværk fræser script med en masse funktioner. Arbejder på Linux 2.4 og højere.
Mål
Jeg forsøgte at skabe den hellige gral:
* Opretholde lav latency til interfactive trafik på alle tidspunkter.
Det betyder, at downloade eller uploade filer ikke må forstyrre SSH eller endda telnet. Disse er de vigtigste ting, selv 200 ms latency er træg at arbejde over.
* Tillad "surfe" til rimelige hastigheder mens op eller downloading
Selvom http er "løs vægt" trafik, bør anden trafik ikke drukne det for meget.
* Sørg uploads ikke skader downloads, og den anden vej rundt
Dette er en meget observeret fænomen, hvor upstream trafik simpelthen ødelægger download hastighed. Det viser sig, at alt dette er muligt, på bekostning af en lille smule af båndbredde. Grunden til, at uploads, downloads og ssh såre hinanden er tilstedeværelsen af store køer i mange indenlandske adgang enheder som kabel- eller DSL-modem.
Hvorfor det ikke virker godt som standard
Internetudbydere ved, at de udelukkende er benchmarkes på, hvor hurtigt folk kan downloade. Udover tilgængelige båndbredde, er download hastighed påvirkes kraftigt af pakketab, som i alvorlig grad hæmmer TCP / IP performance. Store køer kan hjælpe med at forhindre packetloss, og fremskynde downloads. Så internetudbydere konfigurere store køer.
Disse store køer dog beskadige interaktivitet. En tastetryk skal først rejse upstream kø, som kan være sekunder (!) Lang og gå til din fjernbetjening vært. Det er derefter vises, hvilket fører til en pakke kommer tilbage, som så skal krydse nedstrøms kø, som ligger på din internetudbyder, før det vises på skærmen.
Denne HOWTO lærer dig, hvordan du mangle og behandle køen på mange måder, men desværre ikke alle køer er tilgængelige for os. Køen over på ISP er helt off-grænser, mens upstream kø sandsynligvis bor inde i din kabelmodem eller DSL-enhed. Du måske eller måske ikke være i stand til at konfigurere den. Sandsynligvis ikke.
Så hvad nu? Da vi ikke kan kontrollere nogen af disse køer, skal de fjernes, og flyttede til din Linux router. Heldigvis dette er muligt.
Begræns upload hastighed noget
Ved at begrænse vores upload hastighed til lidt mindre end de virkelig tilgængelige sats, ingen køer bygget op i vores modem. Køen er nu flyttet til Linux.
Begræns download hastighed
Det er lidt tricky, da vi ikke rigtig kan påvirke hvor hurtigt internettet skibe os data. Vi kan dog slippe pakker, der kommer i for hurtigt, hvilket medfører TCP / IP til at bremse ned til netop den kurs, vi ønsker. Fordi vi ikke ønsker at droppe trafikken unødigt, vi konfigurerer en "burst" størrelse tillader vi ved højere hastighed.
Nu, når vi har gjort dette, har vi fjernet den nedstrøms kø totalt (bortset fra korte byger), og få mulighed for at styre den opstrøms kø med al den kraft Linux tilbyder.
Lad interaktiv trafik springe køen
Hvad der mangler at blive gjort, er at sørge for interaktiv trafik hopper på forsiden af den opstrøms kø. For at sikre at uploads ikke skader downloads, vi også flytte ACK pakker til forrest i køen. Dette er, hvad der normalt forårsager enorme afmatning observeret, når genererer hovedparten trafik begge veje. De TAK for downstream trafik skal konkurrere med upstream trafik, og få forsinket i processen.
Vi flytter også andre små pakker til forsiden af køen - dette hjælper operativsystemer, som ikke fastsatte TOS bits, ligesom alt fra Microsoft.
Tillader brugeren at specificere lav prioritet trafik (nyt i 1.1!)
Nogle gange kan du opleve lav prioritet udgående trafik bremse vigtig trafik. I så fald kan følgende muligheder hjælpe dig:
NOPRIOHOSTSRC
Sæt denne til værter eller netmasker i dit netværk, der skal have lav prioritet
NOPRIOHOSTDST
Sæt denne til værter eller netmasker på internettet, der skal have lav prioritet
NOPRIOPORTSRC
Sæt denne til kildeporte, der skal have lav prioritet. Hvis du har en ubetydelig webserver på din trafik, skal du indstille dette til 80
NOPRIOPORTDST
Sæt denne til destination porte, der skal have lav prioritet.
Se starten af wshaper og wshaper.htb
Resultater
Hvis vi gør alt dette får vi følgende målinger ved hjælp af en fremragende ADSL-forbindelse fra XS4ALL i Holland:
Baseline latens:
tur min / avg / max = 14,4 / 17,1 / 21.7 ms
Uden trafik balsam, mens du henter:
tur min / avg / max = 560,9 / 573,6 / 586,4 ms
Uden trafik balsam, mens upload:
tur min / avg / max = 2041,4 / 2332,1 / 2427,6 ms
Med balsam, under 220kbit / s upload:
tur min / avg / max = 15,7 / 51,8 / 79,9 ms
Med balsam, under 850kbit / s overførsel:
tur min / avg / max = 20,4 / 46,9 / 74,0 ms
Når du uploader, downloads fortsætte på ~ 80% af den tilgængelige hastighed. Uploads på omkring 90%. Latency så springer til 850 ms, stadig at finde ud af hvorfor.
Hvad du kan forvente fra dette script afhænger meget af din faktiske uplink hastighed. Når du uploader ved fuld hastighed, vil der altid være en enkelt pakke foran dine tastetryk. Det er den nedre grænse for ventetid, du kan opnå - opdele din MTU ved din upstream hastighed til at beregne. Typiske værdier vil være noget højere end det. Sænk din MTU for bedre effekter!
En lille tabel:
Uplink hastighed | Forventet latenstid på grund uploade
--------------------------------------------------
32 | 234ms
64 | 117ms
128 | 58ms
256 | 29ms
Så for at beregne din effektive latency, tage en baseline måling (ping på en ubelastet link), og se op nummeret i tabellen, og tilføje den. Det er om det bedste, du kan forvente. Dette tal kommer fra en beregning, der antager, at din upstream tastetryk vil have højst en halv fuld størrelse pakke foran sig.
Dette kan koges ned til:
mtu * 0.5 * 10
-------------- + Baseline_latency
kbit
Faktoren 10 er ikke helt korrekt, men fungerer godt i praksis.
Din kerne
Hvis du kører en nylig distribution, bør alt være ok. Du har brug for 2.4 med QoS indstillinger tændt.
Hvis du kompilere din egen kerne, skal den have nogle muligheder aktivt. Mest bemærkelsesværdigt i menuen Netværk Options, QoS og / eller Fair Queueing, drej mindst CBQ, PRIO, SFQ, Ingress, Traffic Policing, QoS understøttelse, Rate Estimator, QoS klassificeringen, U32 klassificeringen, fwmark klassificeringen.
I praksis I (og de fleste distributioner) bare tænde alt.
Scripts
Scriptet kommer i to versioner, en der arbejder på standard kerner og implementeres ved hjælp af CBQ. Den anden bruger den fremragende HTB qdisc som ikke er i standard-kernen. Den CBQ version mere testet end HTB én!
Se 'wshaper "og" wshaper.htb «.
Tuning
Disse scripts skal kende den 'rigtige' på din internetudbyder forbindelse. Det er svært at afgøre på forhånd, da de forskellige internetudbydere anvender forskellige slags bits fremgår det. Mennesker rapport succes ved hjælp af følgende teknik:
Anslå både dine opstrøms og nedstrøms til halv sats dine ISP specificerer. Kontrollere nu, hvis scriptet fungerer - tjek interaktivitet under upload, og mens du downloader. Dette kan give latensen som beregnet ovenfor. Hvis ikke, kontrollere, om scriptet udføres uden fejl.
Nu langsomt øge opstrøms & downstream numre i scriptet indtil latency kommer tilbage. På denne måde kan du finde optimale værdier for din forbindelse. Hvis du er tilfreds, bedes du rapportere til mig, så jeg kan lave en liste over numre, der fungerer godt. Lad mig vide, hvilken internetudbyder du bruger, og navnet på dit abonnement, og dens ansete specifikationer, så jeg kan liste dig her og redde andre ulejlighed.
Installation
Hvis du ringer ind, kan du kopiere scriptet til /etc/ppp/ip-up.d, og det vil blive kørt ved hver tilslutning.
Hvis du ønsker at fjerne fræser fra en grænseflade, køre 'wshaper stop ". At se statusoplysninger, køre 'wshaper status ".
KENDTE PROBLEMER
Hvis du får fejl, tilføje en -x til den første linje, som følger:
#! / Bin / bash -x
Og prøv igen. Dette vil vise dig, hvilken linje giver en fejl. Før du kontakter mig, så sørg for, at du kører en nyere version af iproute!
Nyere versioner kan findes på din Linux-distributør, eller hvis du foretrækker at kompilere, her:
ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz
Kommentarer ikke fundet