The Wonder Shaper

The Wonder Shaper er en veldig spesiell nettverk shaper script med en rekke funksjoner. Fungerer på Linux 2.4 og høyere.
Mål
Jeg forsøkte å skape den hellige gral:
* Opprettholde lav latency for interfactive trafikk til enhver tid.
Dette betyr at nedlasting eller laste opp filer ikke skal forstyrre SSH eller telnet. Disse er de viktigste tingene, er enda 200ms latency svak til å jobbe over.
* Tillat 'surfing' til fornuftige hastigheter mens opp eller nedlasting
Selv om http er "bulk" trafikk, bør annen trafikk ikke drukne det ut for mye.
* Sørg for at opplastinger ikke skade nedlastinger, og den andre veien rundt
Dette er en mye observert fenomen der oppstrøms trafikk rett og slett ødelegger nedlastingshastighet. Det viser seg at alt dette er mulig, på bekostning av en liten bit av båndbredde. Grunnen til at opplastinger, nedlastinger og ssh såre hverandre er tilstedeværelsen av store køer mange innenlandske periferienheter som kabel eller DSL-modemer.
Hvorfor det ikke fungerer godt som standard
Internett-leverandører vet at de er testet utelukkende på hvor fort folk kan laste ned. Foruten tilgjengelig båndbredde, er nedlastingshastigheten påvirkes sterkt av pakketap, som alvorlig hemmer TCP / IP-ytelse. Store køer kan bidra til å forhindre packetloss, og raskere nedlastinger. Så ISPer konfigurere store køer.
Disse store køer imidlertid skade interaktivitet. Et tastetrykk må først reise oppstrøms køen, som kan være sekunder (!) Lang og går til den eksterne verten. Det vises da, noe som fører til en pakke som kommer tilbake, som må da krysse nedstrøms køen, som ligger på din ISP, før det vises på skjermen.
Dette HOWTO lærer deg hvordan du kan mangle og behandle køen på mange måter, men dessverre ikke alle køene er tilgjengelig for oss. Køen over på ISP er helt off-limits, mens oppstrøms køen lever sannsynligvis inni kabelmodem eller DSL-enhet. Du kan eller ikke kan være i stand til å konfigurere den. Mest sannsynlig ikke.
Så, hva blir det neste? Som vi ikke kan kontrollere noen av disse køene, må de bli eliminert, og flyttet til Linux ruteren. Heldigvis er dette mulig.
Grense opplastingshastighet noe
Ved å begrense vår opplastingshastighet til noe mindre enn den virkelig tilgjengelige pris, er ingen køer bygget opp i vår modem. Køen er nå flyttet til Linux.
Grense nedlastingshastighet
Dette er litt mer komplisert som vi ikke kan virkelig påvirke hvor raskt internett skips oss data. Vi kan imidlertid slippe pakker som kommer inn for fort, noe som fører til TCP / IP til å bremse ned til bare hastigheten vi ønsker. Fordi vi ikke ønsker å slippe trafikk unødig, vi konfigurere en "burst" størrelse vi tillater høyere hastighet.
Nå, når vi har gjort dette, har vi eliminert nedstrøms køen helt (med unntak av korte perioder), og få muligheten til å administrere oppstrøms køen med all makt Linux tilbyr.
La interaktiv trafikk hoppe over køen
Hva som gjenstår er å sørge for interaktiv trafikk hopper til forsiden av oppstrøms køen. For å være sikker på at opplastinger ikke vondt nedlastinger, vi også flytte ACK-pakkene til forsiden av køen. Dette er hva som normalt fører til at enorme nedgangen observert ved generering bulk trafikk begge veier. De Takk for nedstrøms trafikk må konkurrere med oppstrøms trafikk, og bli forsinket i prosessen.
Vi flytter også andre små pakker til forsiden av køen - dette hjelper operativsystemer som ikke satt TOS biter, som alt fra Microsoft.
Tillate brukeren å spesifisere lavt prioritert trafikk (nytt i 1.1!)
Noen ganger vil du kanskje merke lav prioritet utgående trafikk sakker viktig trafikk. I så fall, kan følgende alternativer hjelpe deg:
NOPRIOHOSTSRC
Sett denne til vertene eller nettmasker i nettverket som skal ha lav prioritet
NOPRIOHOSTDST
Sett denne til vertene eller nettmasker på internett som skal ha lav prioritet
NOPRIOPORTSRC
Sett denne til kildeporter som skal ha lav prioritet. Hvis du har en uviktig webserver på trafikken, sett denne til 80
NOPRIOPORTDST
Sett denne til målportene som skal ha lav prioritet.
Se starten av wshaper og wshaper.htb
Resultater
Hvis vi gjør alt dette får vi følgende målinger ved hjelp av en utmerket ADSL-tilkobling fra XS4ALL i Nederland:
Baseline latency:
rundtur min / avg / max = 14,4 / 17,1 / 21,7 ms
Uten trafikk balsam, mens du laster ned:
rundtur min / avg / max = 560,9 / 573,6 / 586,4 ms
Uten trafikk balsam, mens opplasting:
rundtur min / avg / max = 2041,4 / 2332,1 / 2427,6 ms
Med balsam, under 220kbit / s opplasting:
rundtur min / avg / max = 15,7 / 51,8 / 79,9 ms
Med balsam, under 850kbit / s nedlasting:
rundtur min / avg / max = 20,4 / 46,9 / 74,0 ms
Når du laster opp, nedlastinger fortsette på ~ 80% av tilgjengelig hastighet. Opplastinger på rundt 90%. Ventetid hopper deretter til 850 ms, fortsatt å finne ut hvorfor.
Hva du kan forvente fra dette skriptet avhenger mye av den faktiske uplink hastighet. Når du laster opp i full fart, vil det alltid være en enkelt pakke forkant av tastetrykk. Det er den nedre grense for latency du kan oppnå - dele din MTU ved din oppstrømshastigheten å beregne. Typiske verdier vil være noe høyere enn det. Senk MTU for bedre effekter!
Et lite bord:
Uplink speed | Forventet ventetid grunn til å laste opp
--------------------------------------------------
32 | 234ms
64 | 117ms
128 | 58ms
256 | 29ms
Så for å beregne effektiv ventetid, ta en baseline måling (ping på en losses link), og slå opp nummeret i tabellen, og legge det til. Det er omtrent det beste du kan forvente. Dette tallet kommer fra en beregning som tar utgangspunkt i at din oppstrøms tastetrykk vil ha maksimalt en halv full størrelse pakke foran seg.
Dette koker ned til:
   MTU * 0,5 * 10
   -------------- + Baseline_latency
       kbit
Faktoren 10 ikke er helt riktig, men fungerer godt i praksis.
Kjernen
Hvis du kjører en fersk distribusjon, skal alt være ok. Du trenger 2.4 med QoS alternativer slått på.
Hvis du kompilere din egen kjerne, må den ha noen alternativer aktivert. Mest spesielt i nettverksalternativer menyen, QoS og / eller Fair Queueing, slår minst CBQ, PRIO, SFQ, Ingress, Traffic Policing, QoS støtte, Rate Estimator, QoS klassifikator, U32 klassifikator, fwmark klassifikator.
I praksis jeg (og de fleste distribusjoner) bare slå på alt.
Skript
Skriptet kommer i to versjoner, en som fungerer på standard kjerner og er implementert ved hjelp CBQ. Den andre bruker utmerket HTB qdisc som ikke er i standard kjerne. Den CBQ versjonen er mer testet enn HTB en!
Se 'wshaper' og 'wshaper.htb'.
Tuning
Disse skriptene trenger å vite den "ekte" frekvensen av din ISP-tilkoblingen. Dette er vanskelig å fastslå på forhånd som ulike Internett-leverandører bruker forskjellige typer biter den vises. Folk rapporterer suksess ved hjelp av følgende teknikk:
Anslå både oppstrøms og nedstrøms til halve hastigheten din ISP spesifiserer. Nå bekrefte om skriptet fungerer - sjekk interaktivitet under opplasting og mens du laster ned. Dette bør levere latency som beregnet ovenfor. Hvis ikke, sjekk om skriptet kjøres uten feil.
Nå sakte øke oppstrøms & nedstrøms tall i manuset til latency kommer tilbake. På denne måten kan du finne optimale verdier for tilkoblingen. Hvis du er fornøyd, kan du rapportere til meg slik at jeg kan lage en liste med tall som fungerer godt. Vennligst la meg vite hvilke ISP du bruker og navnet ditt abonnement, og de anerkjente spesifikasjoner, så jeg kan liste deg her og redde andre problemer.
Installasjon
Hvis du ringer inn, kan du kopiere manuset til /etc/ppp/ip-up.d og det vil bli kjørt ved hver tilkobling.
Hvis du ønsker å fjerne shaper fra et grensesnitt, kjøre 'wshaper stopp ". For å se statusinformasjon, kjøre 'wshaper status'.
KJENTE PROBLEMER
Hvis du får feil, legger en -x til første linje, som følger:
#! / Bin / bash -x
Og prøv igjen. Dette vil vise deg hvilken linje gir en feil. Før du kontakter meg, sørg for at du kjører en nyere versjon av iproute!
Nyere versjoner kan finnes på din Linux distributør, eller hvis du foretrekker å kompilere, her:
 ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz