Nothing Special   »   [go: up one dir, main page]

Spring til indhold

Servicekvalitet (datanet)

Fra Wikipedia, den frie encyklopædi
(Omdirigeret fra QoS)

I telekommunikation og datanet, kan traffic engineering's termen servicekvalitet (eng. Quality of Service, QoS) betyde to beslægtede, men forskellige ting:

  1. I kredsløbskoblet datanet (eng. Circuit-Switched Network, CSN) er QoS sandsynligheden for at kunne indlede et kald til et andet stykke dataterminaludstyr.
  2. I pakkekoblede datanet (eng. Packet-Switched Network, PSN) er QoS opfyldelse af en given trafikkontrakt (eng. Service Level Agreement, SLA). I mange tilfælde anvendes QoS uformelt om sandsynligheden for, at en datapakke fuldfører sin rejse mellem to givne dataterminaludstyr i et datanet.

Problemer i pakkekoblede datanet

[redigér | rediger kildetekst]
  • Pakketab (eng. packet drop) – Netudstyr taber pakker, når deres portkøer løber over (eng. buffer tail drop). Det sker pga. fysiske eller logiske flaskehalse i datanettet. F.eks. når:
    • netudstyr ikke kan formidle/processere datapakkerne hurtigt nok. Dette forårsager overløb af en indgående portkø.
    • netudstyr ikke kan afsætte datapakkerne hurtigt nok. Dette forårsager overløb af en udgående portkø.
  • Pakkedubletter – Nogle gange kan samme datapakke blive sendt flere gange, i henhold til en forbindelsesorienteret datanetprotokol. Derfor er pakkedubletter mulige.
  • Pakkefejl – Pakker kan blive sendt til en forkert destination eller blive udsat for datafejl – bitfejl.
  • Pakkerækkefølge (eng. packet order) – Routere vælger en datapakkes videre vej. Routere kan bl.a. registrere, når naboroutere bliver utilgængelige og vil så sende datapakker andre veje, hvis det er muligt.
    • Da datapakkerne kan rejse forskellige veje hænder det ofte at pakke modtagelsesrækkefølgen er forskellig fra afsendelsesrækkefølgen.
    • Når der opstår pakkefejl eller pakketab, vil forbindelsesorienterede flows genfremsende pakker. Disse ankommer ude af trit med de oprindelige nabopakker.
  • Pakkeforsinkelse (eng. packet delay) – Følgende bidrager til forsinkelse:
    • Signalets udbredelseshastighed trådløst gennem atmosfæren, ledninger eller optiske fibre. Udbredelseshastigheden i TP-kabler er ca. 0,79 og i optiske fibre ca. 2/3 af lysets hastighed. Den trådløse overførsel gennem atmosfæren sker tilnærmelsesvist med lysets hastighed (dog angives dets hastighed som regel som såkaldt "vakuumhastighed"). Denne forsinkelse bliver dog betydende, når signalet sendes over store afstande.
    • portkø fyldningsgrad og længde.
    • Hvor hurtigt et stykke netudstyr er om at beslutte videre pakke vej og overføre datapakken fra en indgående (eng. ingress) portkø til den udgående (eng. egress) portkø.
    • Hvilken vej en datapakke er rejst gennem netværket.
    • Når der opstår pakkefejl eller pakketab, vil forbindelsesorienterede flows genfremsende pakker. Disse ankommer ude af trit med de oprindelige nabopakker.
  • Pakkeforsinkelsesvariation (eng. packet jitter) – Følgende bidrager til pakkeforsinkelsesvariation:
    • Varierende portkø fyldningsgrad.
    • Variationer i et stykke netudstyrs beslutningstid og datapakke overførselstid, fra en indgående (eng. ingress) portkø til den udgående (eng. egress) portkø.
    • Variationer i veje datapakkerne rejser gennem netværket.
    • Når der opstår pakkefejl eller pakketab, vil forbindelsesorienterede flows genfremsende pakker. Disse ankommer ude af trit med de oprindelige nabopakker.

Forbindelsesorienterede flows, f.eks. TCP, måler på/registrerer pakke fejl, tab, forsinkelse og justerer sendehastigheden efter forholdende.

Midler til QoS i pakkekoblede datanet

[redigér | rediger kildetekst]

Netudstyr, som understøtter DiffServ og evt. IntServ, kaldes multilayer netudstyr. En switch som understøtter DiffServ og evt. IntServ kaldes en multilayer switch.

Egenskaber som sænker QoS

[redigér | rediger kildetekst]

Følgende egenskaber må til nød anvendes på slutporte (eng. end ports), men ikke på server, backbone og andre porte, som formidler mange samtidige flows.

  • halv dupleks (eng. half duplex) – link kollisionerne forårsager forsinkelsesvariationer (eng. jitter), fordi pakkerne forsinkes for hver kollision med backoff-tiden.
  • portkø "flow"-control IEEE 802.3x.

"Flow"-control IEEE 802.3x er ikke er en flow control, men derimod en kø-kontrol. Eksempel på et IEEE 802.3x problem: "head of Line"-blocking. Mange af dagens switche har IEEE 802.3x slået til som standard – selv på uplink/backbone porte.

Citat fra Network World, 09/13/99, 'Flow control feedback' Arkiveret 10. marts 2005 hos Wayback Machine: "...Hewlett-Packard points out that quality of service is a better way to handle potential congestion, and Cabletron and Nortel note that QoS features can't operate properly if a switch sends [IEEE 802.3x] pause frames...."

I følge citatet tyder det på, at QoS og IEEE 802.3x er inkompatible.

En ethernet dataforbindelse med 100 Mbit/s fuld dupleks i stedet for 100 Mbit/s halv dupleks kan øge den effektive hastighed fra ca. 60-100 Mbit/s for halv dupleks til 200 Mbit/s (100 Mbit/s sende + 100 Mbit/s modtage).

Eksempler på anvendelse af trafikklassificering og "båndbreddegaranti"

[redigér | rediger kildetekst]

Trafikklassificering er nødvendig hvor der er trafik flaskehalse. Hvem har gigabit WAN (ADSL, modem) eller en trådløs gigabit forbindelse? – ikke mange. TCP/IP vil bruge al tilgængelig båndbredde, indtil TCP udsættes for pakketab eller mærkbar tidsforsinkelse – men TCP/IP ved intet om skrøbelig interaktiv trafik! – sådan blev TCP designet og TCP er en særdeles succesfuld protokol. Den interaktive trafik påvirkes mærkbart. Her er eksempler på praktiske trafik politik implementationer:

lartc.org: The Wonder Shaper Comment: Traffic shaping are used with traffic class bandwidth garanties and traffic classification (Her kunne DiffServ standarden benyttes).
Citat: "...

Results
Before, without wondershaper, while uploading:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms
After, with wondershaper, during [traffic shaped] 220kbit/s upload:
round-trip min/avg/max = 15.7/51.8/79.9 ms
Goals
I attempted to create the holy grail:
  • Maintain low latency for interfactive traffic at all times
This means that downloading or uploading files should not disturb SSH or even telnet. These are the most important things, even 200ms latency is sluggish to work over.
  • Allow 'surfing' at reasonable speeds while up or downloading
Even though http is 'bulk' traffic, other traffic should not drown it out too much.
  • Make sure uploads don't harm downloads, and the other way around
This is a much observed phenomenon where upstream traffic simply destroys download speed. It turns out that all this is possible, at the cost of a tiny bit of bandwidth...."

Endnu et eksempel

[redigér | rediger kildetekst]
  • ADSL Bandwidth Management HOWTO Arkiveret 20. december 2003 hos Wayback Machine Citat: "...If you initiate an FTP upload to saturate upstream bandwidth, you should only notice your ping times to the gateway (on the other side of the DSL line) increasing by a small amount compared to what it would increase to with no priority queuing...."

Eksterne henvisninger

[redigér | rediger kildetekst]

Lag 7 firewall/traffic shaper

[redigér | rediger kildetekst]
  • Freeware, open source: Linux firewall-program: netfilter/iptables project homepage. The netfilter/iptables project. Kernet 2.6 iptables er en firewall med udvidelig NAT protokolunderstøttelse.
    • Application Layer Packet Classifier for Linux Citat: "...This is a classifier for the Linux kernel's Netfilter subsystem that identifies packets based on application layer data (OSI layer 7). This means that it can classify packets as HTTP, FTP, Gnucleus, eDonkey2000, etc, regardless of port. Our classifier complements existing ones that match on route, port numbers and so on..."