Egy irodai hálózatban egyszerre utazik a telefonhívás, a videómegbeszélés, a vállalatirányítási rendszer forgalma, a böngészés, a frissítések letöltése és az éjszakai mentés. Amíg minden kapcsolaton van szabad kapacitás, ezek elférnek egymás mellett, és senkit nem érdekel, melyik csomag megy ki elsőként. A gond akkor kezdődik, amikor egy porton több adat érkezik, mint amennyit ki tud küldeni: a csomagok sorba állnak, egy részük késik, más részük elveszik.
A QoS (Quality of Service, szolgáltatásminőség) azoknak a beállításoknak az összessége, amelyek ilyenkor eldöntik, melyik forgalom várjon és melyik menjen előre.
Mikor számít a QoS, és mikor nem segít
A QoS a torlódás pillanatában dolgozik. Egy port kimenetén akkor alakul ki sor, amikor rövid idő alatt több csomag érkezik rá, mint amennyit a vonal sebessége elvisz. Ha egy porton soha nincs torlódás, a sorai üresek, minden csomag azonnal továbbmegy, és a QoS-beállításoknak ott nincs mire hatniuk.
Torlódás jellemzően három helyen keletkezik:
- Sebességváltásnál. Ahol a gyors belső hálózat egy lassabb kapcsolatba torkollik, például egy gigabites porton csatlakozó router mögött egy ennél jóval kisebb sebességre szerződött internetvonal fut, ott a többletnek várnia kell.
- Összefolyásnál. Sok hozzáférési port forgalma egyetlen felmenő ágon megy tovább. Egy mentés vagy egy nagy fájlmásolás rövid időre telítheti ezt az ágat akkor is, ha az átlagos kihasználtság alacsony. Az ilyen, ezredmásodpercekig tartó csúcsokat (microburst) a percenként mintavételezett forgalmi grafikonok el is rejtik.
- A vezeték nélküli hálózaton. A Wi-Fi-eszközök egy közös rádiócsatornán osztoznak, ezért egy alacsony adatsebességgel kapcsolódó, távoli kliens a többiek elől is elveszi az adási időt.
A torlódás hatását a felhasználó a forgalom fajtája szerint másként érzi. A hangforgalom folyamatos, kis csomagokból áll, a videó nagyobb, löketszerű csomagokból; mindkettőnél a túl későn érkező csomag ugyanolyan használhatatlan, mint az elveszett: a hívás szaggat, a kép kockásodik. Egy fájlletöltésnél a késés alig számít, az elveszett csomagot a TCP újraküldi, legfeljebb tovább tart a letöltés.
Sávszélességet viszont a QoS nem teremt. Ha egy vonal tartósan telített, a prioritás csak azt dönti el, melyik forgalom lassuljon: a fontos átjut, a többi akadozik vagy elakad. Ilyenkor a vonal bővítése vagy a forgalom csökkentése segít. Hibás kábelnél, duplex-eltérésnél vagy túlterhelt szervernél sem segít, mert ott a csomagvesztés oka nem a sorban állás. És csak azon az eszközön hat, ahol beállították: ha a torlódás olyan ponton keletkezik, amely a jelöléseket figyelmen kívül hagyja, a saját beállítások hiába jók.
Osztályozás és jelölés: DSCP
Mielőtt a hálózat bármit kezdhetne a forgalommal, el kell döntenie, melyik csomag melyik osztályba tartozik. Ez az osztályozás. Az eszköz nézheti a forrás- és célcímet, a portot, a protokollt, a VLAN-t vagy azt, hogy melyik interfészen érkezett a csomag, a fejlettebb eszközök a forgalomból magát az alkalmazást is felismerik. Mivel ez számításigényes, nem érdemes minden ugráson megismételni. Az eredményt a csomagba írják, és a további eszközök már csak ezt a jelölést olvassák.
Az IP-hálózatokban erre a Differentiated Services (DiffServ) architektúra szolgál (IETF RFC 2475, 1998). Az IP-fejléc egykori szolgáltatástípus-bájtjának felső hat bitje a DSCP (Differentiated Services Code Point, IETF RFC 2474, 1998), így 64 lehetséges érték van. A bájt maradék két bitje az ECN, a torlódás jelzésére szolgáló mező (IETF RFC 3168, 2001). A DiffServ egyetlen kapcsolatnak sem foglal le előre sávszélességet. Minden eszköz a jelölés alapján, a saját beállításai szerint kezeli a csomagot, és ezt a viselkedést nevezik ugrásonkénti kezelésnek (per-hop behavior, PHB).
A gyakorlatban néhány szabványos érték fordul elő a legtöbbször:
| Jelölés | DSCP-érték | Jelentés | Jellemző forgalom |
|---|---|---|---|
| EF | 46 | Expedited Forwarding: kis késleltetés, kis veszteség (IETF RFC 3246, 2002) | IP-telefon hangja |
| CS5 | 40 | Jelzés | Hívásfelépítés, például SIP |
| AF41 | 34 | Multimédiás konferencia | Videómegbeszélés |
| AF21 | 18 | Alacsony késleltetésű adat | Interaktív üzleti alkalmazás |
| CS2 | 16 | Üzemeltetés és felügyelet (OAM) | Hálózatmenedzsment |
| AF11 | 10 | Nagy áteresztőképességű adat | Fájlátvitel, szinkronizálás |
| DF (CS0) | 0 | Alapértelmezett, best effort | Minden más |
| LE | 1 | Lower Effort (IETF RFC 8622, 2019) | Mentés, frissítés, háttérforgalom |
Az AF-jelölések (Assured Forwarding, IETF RFC 2597, 1999) négy osztályt és osztályonként három eldobási elsőbbséget adnak. A második számjegy az eldobási elsőbbség: torlódáskor az AF13-mal jelölt csomag előbb esik ki, mint az AF11-es, pedig mindkettő ugyanabba a sorba tartozik. A CS-kódok (Class Selector) a régi IP-precedencia nyolc szintjével tartják a visszafelé kompatibilitást. Az osztályok és értékek ajánlott hozzárendelését az IETF RFC 4594 (2006) foglalja össze, tizenkét szolgáltatási osztállyal. Ez ajánlás, a saját hálózatban a jelölések jelentését a hálózat gazdája határozza meg. Ha viszont az értékek a szabványt követik, a telefonok és konferenciaeszközök gyári beállításai jellemzően illeszkednek hozzájuk.
Jelölés a 2. rétegben és a Wi-Fi-n
A kapcsolók egy része a kereteket a VLAN-címke három bites prioritási mezője (PCP, IEEE 802.1Q) alapján sorolja be. Ez nyolc szintet ad, de csak addig él, amíg a keret VLAN-címkés kapcsolaton halad, egy útválasztón áthaladva elveszik. A hálózaton végig megmaradó jelölés ezért a DSCP, a PCP-t a kapcsolók jellemzően ebből képezik.
A Wi-Fi-n a WMM (a Wi-Fi Alliance tanúsítása, amely az IEEE 802.11e kiegészítésen alapul) négy hozzáférési kategóriát használ: hang, videó, best effort és háttér. A magasabb kategória rövidebb várakozás után juthat adáshoz a rádiócsatornán. A DSCP-értékek és a Wi-Fi-kategóriák megfeleltetésére az IETF RFC 8325 (2018) ad ajánlást. Ha a vezeték nélküli rendszer ettől eltérően képez le, egy helyesen jelölt hívás is a best effort kategóriában utazhat a rádiós szakaszon.
Sorkezelés és ütemezés torlódáskor
Minden kimeneti portnak van egy vagy több sora, és egy ütemezője, amely eldönti, melyik sorból menjen ki a következő csomag. Egyetlen sornál a csomagok érkezési sorrendben távoznak (FIFO), és ha a sor megtelik, az újonnan érkezők elvesznek. Több sornál a jelölés dönti el, melyik csomag hová kerül, az ütemező szabályai pedig azt, hogy a sorok egymáshoz képest milyen eséllyel jutnak a vonalhoz.
Szigorú prioritás és súlyozott elosztás
A szigorú prioritású sorból mindig megy csomag, amikor van benne valami, a többi sor csak utána következik. A hangforgalomnak ez ideális, mert a csomagjai szinte sosem várnak. A veszélye az, hogy ha a prioritásos sorba túl sok forgalom kerül, a többi sor kiéhezik, vagyis egyáltalán nem jut a vonalhoz. Ezért a prioritásos sort mindig kerethez kell kötni: a keret fölötti forgalmat az eszköz eldobja. A keret nagyságát a várható egyidejű hívások számából érdemes kiszámolni, erre az utolsó szakasz ad példát.
A többi sor között az ütemező súlyok szerint osztja el a kapacitást. Erre több algoritmus létezik, például a súlyozott körforgásos (WRR), a súlyozott méltányos sorkezelés (WFQ) vagy a hiányszámlálós körforgás (DRR). Ha például a videókonferencia sora kétszer akkora súlyt kap, mint a háttérsor, torlódáskor nagyjából kétszer annyi adatot küldhet ki. Egy éppen üres sor kapacitását a többiek használják, így a súly a torlódás idejére garantált minimumot jelent, felső korlátot nem.
Mit dob el a sor, amikor megtelik
A legegyszerűbb eldobási mód a farokeldobás (tail drop): ha a sor tele van, minden új csomag elvész. Ilyenkor sok TCP-kapcsolat egyszerre veszít csomagot, egyszerre lassít, majd egyszerre gyorsít újra, és a vonal kihasználtsága hullámzik. A korai véletlenszerű eldobás (RED, S. Floyd és V. Jacobson, IEEE/ACM Transactions on Networking, 1993) ezt úgy kerüli el, hogy már a sor megtelése előtt, a sor hosszával növekvő valószínűséggel dob el egy-egy csomagot. A súlyozott változat az AF-osztályok eldobási elsőbbségét is figyelembe veszi.
A túl mély puffer is gondot okoz. Kevesebb csomagot dob el, viszont a benne várakozó csomagok késleltetése megnő, és ezt a hívásokban hallani lehet. A jelenség neve bufferbloat. Az IETF RFC 7567 (2015) ezért aktív sorkezelést ajánl, amely a sor hosszát tartósan alacsonyan tartja. Ilyen algoritmus a CoDel (IETF RFC 8289, 2018), amely a csomagok sorban töltött idejét figyeli, és az FQ-CoDel (IETF RFC 8290, 2018), amely ezt folyamonkénti méltányos elosztással kombinálja. Ha a küldő és a fogadó fél is kezeli az ECN-t, a sor eldobás helyett meg is jelölheti a csomagot, így a küldő csomagvesztés nélkül értesül a torlódásról.
Formázás és korlátozás a WAN-kapcsolaton
A telephelyeken a sor leggyakrabban a WAN- vagy internetkapcsolaton alakul ki, mert ez jellemzően lassabb a belső hálózat portjainál. A QoS ezért itt hat a legtöbbet.
Ha a router gigabites porton csatlakozik a szolgáltató eszközéhez, de a szerződés ennél kisebb sebességről szól, a router saját portján nem lesz torlódás. A csomagok teljes sebességgel kimennek, és a szolgáltató eszközén állnak sorba, amely a belső jelölésekről semmit nem tud. A router QoS-beállításai így életbe sem lépnek. A megoldás a formázás (shaping): a router a kimenő forgalmat kicsivel a szerződött sebesség alatt tartja, így a sor a saját eszközén keletkezik, és ott dolgozik az osztályok szerinti ütemezés. A formázó a keret fölötti csomagokat pufferben visszatartja, és később küldi el őket.
A korlátozás (policing) ugyanazzal a mérőeszközzel, egy tokenvödörrel méri a forgalmat, de a keret fölötti csomagot azonnal eldobja vagy alacsonyabb osztályba jelöli át. Késleltetést nem okoz, a TCP-forgalom átvitele viszont az eldobások miatt ingadozik. A szolgáltatók gyakran ezzel érvényesítik a szerződött sebességet. Az egy- és a kétsebességes háromszínű jelölést, amely a keretet túllépő csomagokat két fokozatban különbözteti meg, az IETF RFC 2697 és RFC 2698 (1999) írja le. A saját hálózatban a korlátozás a prioritásos sor keretének betartatására és egy-egy forgalomfajta, például a vendéghálózat felső határának érvényesítésére jó.
A bejövő irány
A kimenő forgalmat a saját eszköz szabályozza. A bejövő forgalom viszont a szolgáltató felől érkezik, és mire a routerhez ér, már átjutott a szűk keresztmetszeten. Amit a szolgáltató oldalán eldobtak, azon a router nem tud segíteni. Közvetett eszköz létezik: ha a router a bejövő forgalmat is a vonal sebessége alatt formázza, a TCP-küldők a késleltetésből és az eldobásokból érzékelik a torlódást, lassítanak, és a sor a saját eszközre kerül át. Ez a TCP-forgalomnál működik, egy hirtelen érkező UDP-áradattal szemben hatástalan.
Internet, MPLS és titkosított alagutak
Az interneten a DSCP-jelölés csak a saját hálózat határáig ér. A szolgáltatók a jelölést jellemzően nem veszik figyelembe, sokszor törlik vagy átírják. A hálózatok közötti DiffServ-együttműködésre az IETF RFC 8100 (2017) ad ajánlást, ez azonban a felek közötti megállapodást feltételez. MPLS-vonalnál a szolgáltató szerződésben vállalhat forgalmi osztályokat, és ilyenkor a belső jelöléseket a szolgáltató által megadott értékekre kell leképezni.
Titkosított IPsec-alagútnál az útközbeni eszközök csak a külső fejlécet látják, ezért a belső csomag DSCP-értékét át kell másolni a külső fejlécbe. Az IETF RFC 4301 (2005) egy további buktatóra is figyelmeztet. Ha egy biztonsági társításon (SA) különböző osztályú forgalom megy, és a fogadó ismétléses támadás elleni ablakot használ, a prioritás miatt később érkező, alacsonyabb osztályú csomagok kieshetnek az ablakból és elveszhetnek. Ezt osztályonként külön SA-val lehet elkerülni. Az SD-WAN a vonalminőség mérésével és az osztályonkénti útválasztással egészíti ki a QoS-t; a működéséről az SD-WAN-ról szóló cikk ír részletesen.
Bizalmi határ és újrajelölés
Ha a hálózat minden beérkező jelölést elfogad, bárki megjelölheti a saját forgalmát EF-fel. Egy rosszul beállított alkalmazás, egy szándékos visszaélés vagy egy fertőzött gép így a prioritásos sorba juthat, és mivel az kerethez kötött, a valódi hívások csomagjai is elveszhetnek. A bizalmi határ az a pont, ameddig a hálózat a jelöléseket hitelesnek tekinti. Az ezen kívülről érkező csomagokat a hálózat újraosztályozza.
Egy szokásos elrendezés:
- A hozzáférési kapcsoló portja alapértelmezésben nem bízik a jelölésben: a beérkező DSCP-t 0-ra írja át, vagy a saját osztályozási szabályai szerint jelöl.
- Az IP-telefonok és konferenciaeszközök portján a kapcsoló elfogadja a jelölést, ha az eszközt azonosította, például hálózati hozzáférés-vezérléssel vagy LLDP-MED-del (ANSI/TIA-1057, 2006), és a hangforgalom külön hang-VLAN-ban utazik. A telefon mögé csatlakoztatott számítógép jelöléseit a telefon maga is felülírhatja.
- A szerverek felé menő portokon csak az előre egyeztetett értékek maradnak meg.
- A kapcsolók közötti és a router felé menő felmenő ágakon a hálózat már a saját jelöléseire támaszkodik.
A számítógépen futó videóhívásoknál bonyolultabb a helyzet. Az operációs rendszerekben a jelölés központi házirendből vagy alkalmazásonként beállítható, de a számítógép felhasználói eszköz, amelynek a jelöléseiben a hálózat nem bízhat feltétel nélkül. Ezért a hozzáférési kapcsoló vagy a tűzfal a forgalmat ismert jellemzők, például célcímek, portok vagy alkalmazásfelismerés alapján jelöli újra, és a kliens saját jelölését csak akkor hagyja meg, ha az illik ezekhez.
Az újrajelölés a hálózat széleinél is visszatér. A szolgáltató felé menő vonalon a belső értékeket a szolgáltató által elfogadott néhány értékre kell leképezni. A kívülről érkező jelöléseket pedig érdemes nullázni vagy a saját sémához igazítani, mert különben egy idegen hálózatból érkező EF-jelölés is prioritást kapna a belső sorokban.
QoS-terv kevés forgalmi osztállyal
Az RFC 4594 tizenkét osztálya kiindulási katalógusnak jó. Egy telephelyi hálózatban általában négy-hat osztály is elég, és minél kevesebb van, annál könnyebb mindenhol egyformán beállítani, majd később ellenőrizni. Egy gyakori felosztás:
- Hang (EF): szigorú prioritás, kerethez kötve.
- Videókonferencia és hívásjelzés (AF41, CS5): saját sor, nagyobb súllyal.
- Üzleti alkalmazások (AF21): garantált részarány a vonalból.
- Alapértelmezett (DF): minden, amit nem soroltak máshová.
- Háttér (LE): mentés, frissítések, nagy szinkronizálás. Torlódáskor ez enged elsőként.
Az útválasztók a saját vezérlőforgalmukat, például az útválasztó protokollok üzeneteit (az RFC 4594 szerint a CS6 osztály), jellemzően belül is előnyben részesítik. A menedzsmentforgalom (SSH, SNMP, CS2) viszont beállítás nélkül többnyire az alapértelmezett sorba kerül, ezért érdemes neki saját osztályt adni, és kipróbálni, hogy egy telített vonalon is átjut-e, mert a távoli eléréssel együtt a hibaelhárítás lehetősége is elveszhet.
A hangsor keretének kiszámítása
Egy példa a keret becslésére. A G.711 kodek (ITU-T G.711, 1988) 64 kbit/s-mal kódolja a hangot. 20 ezredmásodperces csomagolásnál másodpercenként 50 csomag megy, mindegyikben 160 bájt hang és 40 bájt fejléc: 20 bájt IPv4, 8 bájt UDP és 12 bájt RTP (IETF RFC 3550, 2003). Ez irányonként 80 kbit/s az IP-rétegben. Ha egy telephelyen egyszerre tíz hívás futhat, a hangsor keretének legalább 800 kbit/s-nak kell lennie, és ehhez jön még a 2. rétegbeli keretezés és az esetleges alagút fejléceinek többlete. A tömörítőbb kodekek kevesebb sávszélességet igényelnek, a csomagonkénti fejléc viszont náluk arányaiban nagyobb.
Bevezetés és ellenőrzés
- Először a forgalmat kell megismerni. A folyamadatokból (IPFIX, IETF RFC 7011, 2013) látszik, melyik alkalmazás mennyit használ a WAN-vonalból, és mikor.
- A jelölési sémát egy táblázatban kell rögzíteni (osztály, DSCP-érték, sor, súly vagy keret), és minden eszközön ugyanazt kell alkalmazni. Ahol egy eszköz kimarad, ott a jelölés hatástalan.
- Az ellenőrzés a sorok számlálóiból indul: melyik sorban hány csomag esett el, és mikor. Ha a hangsorban van eldobás, vagy kicsi a keret, vagy oda nem való forgalom került a sorba.
- A felhasználók tapasztalatát a hívásminőségi mutatók (késleltetés, jitter, csomagvesztés) és a vonal kihasználtsága együtt mutatják meg.
Új alkalmazás, vonalváltás vagy új telefonrendszer bevezetésekor a jelöléseket és a sorokat újra át kell nézni, mert a forgalmi kép ilyenkor megváltozik.
Kapcsolódó szolgáltatás: SD-WAN →
