Senki sem szereti, ha betöltéskor sokáig tart megnyitni egy weboldalt, és a fájlok letöltése nem olyan szinten történik, ahogyan szeretné. Bár a szolgáltatótól történő szolgáltatás megrendelésekor egyértelműen 20 vagy akár 100 Mb / s-ot jelzett, de a valóságban nem kapunk ilyen sebességet.
Ennek persze megvan a magyarázata. Először is, a rendszer körülbelül 20%-ot vesz igénybe igényeinek kielégítésére, másodszor pedig a böngésző választ kap a DNS-kiszolgálóktól, bár ez időbe telik.
Bármi is legyen, most kitaláljuk, hogyan növelhetjük többször az internet sebességét.
A QoS sebességkorlátozás letiltása
Általában 20%-os sebességkorlátozás van a rendszerben, bár ez mindenkinél eltérő lehet. Az internet sebességének növeléséhez ki kell kapcsolnia ezt a beállítást. Ehhez helyi csoportházirendeket fogunk használni. Sajnos ez a funkció csak a Windows Pro kiadásaiban érhető el.
Nyissa meg a „Futtatás” ablakot a kombináció használatával Win+Rés a megjelenő ablakba írja be a következő parancsot: gpedit.msc .
A megnyíló ablak bal oldalán lépjen a következő szakaszra: Számítógép konfiguráció – adminisztratív sablonok- Háló - QoS csomagütemező – Korlátozza a fenntartott sávszélességet.
Ott találjuk a "Sávszélesség korlátozása" elemet. Kattintson rá kétszer, és állítsa be a paramétert "Beleértve" majd írjon be egy számot “0” a "Sávszélesség-korlát" részben. Kattintson az Alkalmaz gombra.
Ahhoz, hogy megbizonyosodjon arról, hogy a hálózati eszköz együttműködik a QoS csomagütemezővel, nyissa meg a Hálózati és megosztási központot. Úgy érheti el, hogy a tálcán a Wi-Fi ikonra kattint, vagy jobb gombbal rákattint egy vezetékes kapcsolatra. A bal oldalon lépjen az „Adapterbeállítások módosítása” szakaszba. Kattintson a jobb gombbal a kapcsolatra, és válassza a "Tulajdonságok" lehetőséget. Legyen lehetőség QoS csomagütemező, pipával megjelölve.
QoS letiltása a rendszerleíró adatbázison keresztül
Ha a Windows-nak a PRO-tól eltérő verziója van, akkor ez az utasítás megfelelhet Önnek. Lépjen a rendszerleíró adatbázisba, ehhez a Win + R kombinációt használjuk, és írja be a parancsot regedit.
Menjünk a következő szakaszra:
| HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft |
Itt találjuk a részt ablakok, kattintson rá jobb gombbal, és hozzon létre egy új partíciót a névvel psched.
A létrehozott részre lépünk, és a jobb oldalon létrehozunk egy 32 bites DWORD paramétert a névvel NonBestEffortLimit. Ehhez a paraméterhez hozzárendeljük az értéket «0» .
Az elvégzett munka után indítsa újra a számítógépet.
Az internet sebességkorlátozásának letiltása a szoftverben
Előfordul, hogy internetet igénylő programok, például torrent kliensek használatakor vannak olyan sebességkorlátozó funkciók, amelyek aktívak lehetnek.
Vegyünk például egy torrent klienst. Ha jobb gombbal kattint az aktív letöltésre, akkor van egy elem "fogadási korlátozás". Mutassuk rá az egeret és nézzük. Az üzemmódnak aktívnak kell lennie. "Korlátlan".
Ugyanez más torrent kliensekkel is. Más típusú programokban ásnia kell, és valami hasonlót kell találnia.
Hogyan lehet növelni a DNS-gyorsítótárat a sebesség növelése érdekében?
Amint azt sokan tudják, a DNS-gyorsítótár lehetővé teszi a már meglátogatott erőforrások IP-címeinek tárolását, az újralátogatás pedig a DNS-gyorsítótárat használja, amely lehetővé teszi az oldalak sokkal gyorsabb megnyitását. A térfogata sajnos nem végtelen, de növelhető.
Megy! Nyomja meg a Win + R billentyűket, és írja be a parancsot a beállításjegyzékbe való belépéshez - regedit. Megnyílik egy ablak, ahol erre a bal oldali szakaszra kell lépnünk:
| HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNScache\Parameters |
A jobb oldalon jobb egérgombbal kell kattintani egy üres helyre, és létre kell hozni 4 "DWORD" paramétert, és ilyen nevet kell adni nekik - CacheHashTableBucketSize, CacheHashTableSize, MaxCacheEntryTtlLimit, MaxSOACacheEntryTtlLimit.
Mindegyiknek ezekkel az értékekkel kell rendelkeznie (mindegyik sorrendjében) - 1, 384, 64000 és 301.
Indítsa újra a számítógépet a munka sikeres befejezéséhez.
TCP automatikus hangolás - letiltása
A rendszerben van egy olyan funkció, amely miatt a weboldalak lassan töltődnek be, és ennek az az oka, hogy egyes szerverekkel nem túl jó a teljesítménye. Szóval csak kikapcsoljuk.
A feladat végrehajtásához meg kell nyitnunk egy emelt szintű parancssort, és ott futtassa a következő parancsot:
A böngészők turbómódja a webhely betöltésének felgyorsítása érdekében
Sok böngésző rendelkezik "Turbó mód" funkcióval, amely felgyorsítja az oldalak megnyitását. Eddig a következő népszerű böngészőkben érhető el: Opera és Yandex böngésző. Mások számára speciális bővítményeket tölthet le.
Az Operában ez a funkció a bal felső sarokban található "Opera" gombra kattintva engedélyezhető. Funkció keresése Opera Turboés aktiválja azt.
A Yandex böngészőben ez a funkció engedélyezve van a beállításokban - Speciális beállítások megjelenítése. A „Turbó” rész mellett helyezze el "Mindig bekapcsolva".
NameBench segédprogram az oldalbetöltés növelésére
Sok szolgáltató, különösen a kereskedelmi szolgáltató, mindig szeretne spórolni a berendezéseken. És amikor elkezd felkeresni egy webhelyet, a rendszer hozzáfér a DNS-kiszolgálókhoz (a szolgáltató berendezéseihez). Ha olcsó, akkor az oldal betöltési sebessége nagyon lassú lesz. A probléma megoldásához gyors DNS-kiszolgálókra van szükségünk, és a NameBench program segít megtalálni őket. Indítsa el a Benchmarkot. A program megkezdi a nagyszámú DNS-kiszolgáló tesztelését, és kiválasztja a leggyorsabbat.
Amikor a NameBench megtalálja a kívánt szervert, megmutatja annak IP-címét, amelyet meg kell adni a kapcsolati beállításokban.
Az útválasztó firmware-ének frissítése
Ez az utolsó pont, de nem kevésbé fontos. Ha olyan útválasztót használ, amelynek firmware-je nagyon elavult, akkor ne várjon tőle csodát. Keresse meg az interneten az útválasztó firmware-jét, és találjon utasításokat a telepítéshez, valamint a problémák elkerülése érdekében a régi mentéséhez.
Valójában ez az összes módszer, amely a Windows modern verzióiban használható. Bár lehet, hogy van még valami, és ha igen, akkor nem kerüljük meg.
A cikksorozat első részében arról beszéltem, hogy mit csinál a QoS, és mire használják. Ebben a részben a QoS működésének ismertetésével folytatom a beszélgetést. A cikk olvasása közben ügyeljen arra, hogy az itt közölt információk a Windows Server 2003 QoS betartatásán alapulnak, amely eltér a Windows 2000 Server QoS betartatásától.
forgalomkezelő API
A hálózati forgalom priorizálásának egyik fő problémája, hogy nem lehet prioritást adni a forgalomnak az azt létrehozó számítógép alapján. Gyakori, hogy egyetlen számítógépen több alkalmazás fut, és minden egyes alkalmazáshoz (és operációs rendszerhez) külön forgalmi áramlást hoznak létre. Amikor ez megtörténik, minden forgalmi áramlást külön-külön kell priorizálni. Végül is előfordulhat, hogy az egyik alkalmazásnak tartalék sávszélességre van szüksége, míg egy másik alkalmazás ideális a legjobb átvitelhez.
Itt jön képbe a Traffic Control API (Traffic Control Programming Interface). A Traffic Control API egy alkalmazásprogramozási felület, amely lehetővé teszi a QoS-beállítások alkalmazását az egyes csomagokra. A Traffic Control API úgy működik, hogy egyedi forgalmi folyamatokat határoz meg, és különféle QoS-vezérlési módszereket alkalmaz ezekre az áramlásokra.
A Traffic Control API első dolga az úgynevezett szűrőspecifikáció létrehozása. A szűrőspecifikáció lényegében egy szűrő, amely meghatározza, hogy mit jelent egy csomag egy adott adatfolyamhoz való tartozása. A filterspec által használt egyes attribútumok közé tartozik a csomag forrás- és cél IP-címe, valamint a portszám.
A szűrőspecifikáció meghatározása után az API lehetővé teszi egy folyamatspecifikáció létrehozását. A folyamatspec határozza meg a QoS paramétereket, amelyek a csomagok sorozatára vonatkoznak. A folyamatspec által meghatározott paraméterek egy része magában foglalja a bitsebességet (megengedett bitsebesség) és a szolgáltatás típusát.
A Traffic Control API által meghatározott harmadik fogalom az áramlási koncepció. A folyamat olyan csomagok egyszerű sorozata, amelyekre ugyanaz a folyamatspec vonatkozik. Egyszerűen fogalmazva, a szűrőspecifikáció határozza meg, hogy mely csomagok kerüljenek bele a folyamatspecifikációba. A folyamatspec határozza meg, hogy a csomagok feldolgozása magasabb prioritással történik-e, és az áramlás a folyamatspec hatálya alá tartozó csomagok tényleges átvitele. Az adatfolyamban lévő összes csomagot egyenlően kezeljük.
Meg kell említeni, hogy a Traffic Control API egyik előnye a Windows 2000-ben használt Generic QoS API-val szemben az aggregáció (összevonás) használatának lehetősége. Ha egy csomópont több alkalmazással rendelkezik, amelyek több adatfolyamot küldenek egy közös célállomásra, akkor ezek a csomagok egy közös adatfolyamba kombinálhatók. Ez akkor is működik, ha az alkalmazások eltérő portszámokat használnak, mindaddig, amíg a forrás és a cél IP-címe megegyezik.
Általános csomagosztályozó
Az előző részben beszéltem a flowspec, a filterspec és a flow kapcsolatáról. Fontos azonban megjegyezni, hogy a Traffic Control API csak egy alkalmazásprogramozási felület. Mint ilyen, feladata a forgalmi áramlások azonosítása és rangsorolása, nem pedig az áramlások létrehozása.
Az általános csomagosztályozó felelős az adatfolyamok létrehozásáért. Ahogy az utolsó szakaszból emlékszik, a folyamatspecifikációban meghatározott egyik attribútum a szolgáltatás típusa volt. A szolgáltatás típusa alapvetően meghatározza a szál prioritását. Az általános csomagosztályozó felelős a folyamspecifikációhoz rendelt szolgáltatástípus meghatározásáért, majd a kapcsolódó csomagokat a szolgáltatás típusának megfelelő sorba helyezi. Minden szál külön sorba kerül.
QoS csomagütemező
A harmadik QoS komponens, amelyet tudnia kell, a QoS csomagütemező. Egyszerűen fogalmazva, a QoS csomagütemező fő feladata a forgalom alakítása. Ehhez a csomagütemező különböző sorokból fogad csomagokat, majd ezeket a csomagokat prioritásokkal és áramlási sebességekkel jelöli meg.
Amint azt a cikksorozat első részében tárgyaltam, a QoS megfelelő működéséhez a csomagok forrása és a célállomás közötti különféle összetevőknek támogatniuk kell a QoS-t (azaz tisztában kell lenniük vele). Míg ezeknek az eszközöknek tudniuk kell kezelni a QoS-t, azt is tudniuk kell, hogyan kezeljék a normál forgalmat prioritások meghatározása nélkül. Ennek lehetővé tétele érdekében a QoS egy címkézésnek nevezett technológiát használ.
Valójában itt kétféle jelölés létezik. A QoS csomagütemező a 3. rétegű eszközök által felismert Diffserv jelölést és a 2. rétegű eszközök által felismert 802.1p jelölést használja.
A QoS csomagütemező konfigurálása
Mielőtt bemutatnám, hogyan működik a jelölés, meg kell jegyezni, hogy be kell állítania egy QoS csomagütemezőt, hogy minden működjön. A Windows Server 2003 rendszerben a QoS csomagütemező egy opcionális hálózati összetevő, akárcsak a Microsoft-hálózatok vagy a TCP/IP-protokoll kliense. A QoS Packet Scheduler engedélyezéséhez nyissa meg a kiszolgáló hálózati kapcsolatának tulajdonságait, és jelölje be a QoS csomagütemező melletti négyzetet az A. ábrán látható módon. Ha a QoS csomagütemező nem szerepel a listában, kattintson a Telepítés gombra, és kövesse az utasításokat.
A ábra: A QoS csomagütemezőt engedélyezni kell a QoS használatához
Egy másik dolog, amit tudnia kell a QoS csomagütemezőről, hogy a hálózati adapternek támogatnia kell a 802.1p címkézést, hogy megfelelően működjön. Az adapter ellenőrzéséhez kattintson a Konfigurálás gombra, az A ábra, és a Windows megjeleníti a hálózati adapter tulajdonságait. Ha megnézi a tulajdonságok oldalon a "Speciális" lapot, látni fogja a hálózati adapter által támogatott különféle tulajdonságokat.
Ha megnézi a B ábrát, láthatja, hogy a lista egyik tulajdonsága a 802.1Q/1P VLAN Tagging. Azt is látja, hogy ez a tulajdonság alapértelmezés szerint le van tiltva. A 802.1p címkézés engedélyezéséhez egyszerűen engedélyezze ezt a funkciót, majd kattintson az OK gombra.
B ábra: Engedélyeznie kell a 802.1Q/1P VLAN címkézést
Talán észrevette a B ábrán, hogy az engedélyezett tulajdonság a VLAN címkézéshez kapcsolódik, nem pedig a csomagcímkézéshez. Ennek az az oka, hogy a prioritásjelzőket a VLAN-címkék tartalmazzák. A 802.1Q szabvány VLAN-okat és VLAN-címkéket határoz meg. Ez a szabvány valójában három bitet foglal le a VLAN-csomagban, amelyeket a prioritási kód írására használnak. Sajnos a 802.1Q szabvány soha nem határozza meg, hogy melyek legyenek ezek a prioritási kódok.
A 802.1P a 802.1Q kiegészítéseként jött létre. A 802.1P prioritásjelölést határoz meg, amely VLAN-címkébe csomagolható. A harmadik részben elmondom, hogyan működik ez a két szabvány.
Következtetés
Ebben a cikkben a Windows Server 2003 QoS architektúrájának néhány alapvető fogalmát tárgyaljuk. A harmadik részben részletesebben kitérek arra, hogy a QoS csomagütemező hogyan jelöli meg a csomagokat. Arról is beszélek, hogyan működik a QoS alacsony sávszélességű hálózati környezetben.
Napjaink hálózatépítésének egyik legnépszerűbb területe a hang és videó konvergenciája a hagyományos adathálózatokon keresztül. Az egyik probléma az ilyen típusú konvergenciával, hogy a video és audio adatcsomagokat gyorsan és megbízhatóan, megszakítások és túl hosszú késések nélkül kell eljuttatni a címzetthez a megfelelő működés érdekében. Ugyanakkor az ilyen típusú forgalom nem zavarhatja a hagyományosabb adatcsomagok továbbítását.
A probléma egyik lehetséges megoldása a QoS. A QoS vagy a szolgáltatás minősége az adatcsomagok prioritásainak meghatározására szolgáló technológia. A QoS lehetővé teszi az időzítésre érzékeny csomagok magasabb prioritású küldését, mint a többi csomag.
A QoS ipari szabvány, nem pedig a Microsoft tulajdonában lévő szabvány. A Microsoft azonban először a Windows 2000 rendszerrel vezette be ezt a QoS szabványt. A QoS Microsoft verziója azóta sokat fejlődött, de még mindig megfelel az ipari szabványoknak.
A Windows XP Professional rendszerben a QoS elsősorban sávszélesség-foglalási mechanizmusként működik. Ha a QoS engedélyezve van, egy alkalmazás az egyes gépek hálózati adapterei által biztosított teljes hálózati sávszélesség 20%-át lefoglalhatja. Az alkalmazás által lefoglalt hálózati sávszélesség azonban konfigurálható. A harmadik részben megmutatom, hogyan lehet módosítani a lefoglalt sávszélesség mértékét.
A tartalék sávszélesség felhasználásának megtekintéséhez tegyük fel, hogy van egy videokonferencia-alkalmazása, amelynek elsőbbségi sávszélességre van szüksége a megfelelő működéshez. Feltételezve, hogy a QoS engedélyezve van ennél az alkalmazásnál, azt mondhatjuk, hogy a gép teljes sávszélességének 20%-át lefoglalja, így a sávszélesség 80%-át a többi hálózati forgalom számára hagyja.
A videokonferencia-alkalmazások kivételével minden alkalmazás a legjobb erőfeszítésnek nevezett technológiát használja. Ez azt jelenti, hogy a csomagok ugyanazzal az "első kézbesített csomagot szolgálják ki először" prioritással küldik el. Másrészt a videokonferencia-alkalmazások forgalma mindig elsőbbséget élvez a többi forgalommal szemben, de egy alkalmazás soha nem fogyaszthatja el a teljes sávszélesség 20%-ánál többet.
Azonban csak azért, mert a Windows XP fenntart bizonyos sávszélességet az elsőbbségi forgalom számára, ez nem jelenti azt, hogy a normál prioritású alkalmazások nem fogják tudni használni a tartalék sávszélességet. Bár a videokonferencia-alkalmazások számára előnyös a magasabb prioritású, lefoglalt sávszélesség, nagyon kicsi annak az esélye, hogy ezeket az alkalmazásokat folyamatosan használják. Ebben az esetben a Windows lehetővé teszi más alkalmazások számára, hogy a tartalék és nem lefoglalt sávszélességet használják a lehető legjobb szállítás érdekében, mindaddig, amíg azokat az alkalmazásokat, amelyek számára a hálózati sávszélesség egy része le van foglalva, ki nem használják.
Amint a videokonferencia-alkalmazás elindul, a Windows elkezdi kényszeríteni a visszaállítást. De még ebben az esetben sem abszolút a redundancia. Tegyük fel, hogy a Windows a hálózati sávszélesség 20%-át lefoglalta egy videokonferencia-alkalmazás számára, de ennek az alkalmazásnak nincs szüksége a teljes 20%-ra. Ezekben az esetekben a Windows lehetővé teszi más alkalmazások számára a fennmaradó sávszélesség használatát, de folyamatosan figyeli a magasabb prioritású alkalmazás igényeit. Ha egy alkalmazásnak nagyobb sávszélességre van szüksége, a sávszélesség legfeljebb 20%-ig lesz lefoglalva.
Mint mondtam, a QoS egy iparági szabvány, nem a Microsoft technológia. Mint ilyen, a QoS-t a Windows használja, de a Windows önmagában nem tudja elvégezni a munkát. A QoS működéséhez a küldő és a vevő közötti minden berendezésnek támogatnia kell a QoS-t. Ez azt jelenti, hogy a hálózati adaptereknek, kapcsolóknak, útválasztóknak és minden egyéb használt eszköznek ismernie kell a QoS-t, valamint a címzett és a küldő operációs rendszerét.
Ha kíváncsi, nem kell valami őrült egzotikus hálózati infrastruktúrát felállítania a QoS használatához. Az aszinkron átviteli mód (ATM) egy nagyszerű hálózati technológia a QoS használatához, mivel kapcsolatorientált technológia, azonban a QoS-t más technológiákkal is használhatja, mint például a Frame Relay, az Ethernet és még a Wi-Fi (802.11 x).
Az ok, amiért az ATM ilyen ideális választás a QoS számára, az az, hogy képes sávszélesség-foglalásra és erőforrások hardverszintű lefoglalására. Az ilyen típusú elosztás meghaladja az Ethernet és a hasonló hálózati technológiák lehetőségeit. Ez nem jelenti azt, hogy a QoS nem használható. Ez csak azt jelenti, hogy a QoS-t másként kell alkalmazni, mint egy ATM környezetben.
ATM környezetben az erőforrások azonnal, a fizikai eszközök szintjén kerülnek lefoglalásra. Mivel az Ethernet és a hasonló technológiák nem képesek ilyen módon lefoglalni az erőforrásokat, az ilyen típusú technológiák a prioritások meghatározásán alapulnak, nem pedig a valódi erőforrás-allokáción. Ez azt jelenti, hogy a sávszélesség lefoglalása az OSI modell magasabb szintjén történik. A sávszélesség lefoglalása után először a magasabb prioritású csomagok kerülnek továbbításra.
Az egyik szempont, amelyet figyelembe kell venni, ha a QoS-t Etherneten, Wi-Fi-n vagy más hasonló technológiákon keresztül kívánja alkalmazni, az az, hogy ezek a technológiák kapcsolat nélküliek. Ez azt jelenti, hogy a küldőnek nincs módja ellenőrizni a vevő állapotát vagy a küldő és a fogadó közötti hálózat állapotát. Ez viszont azt jelenti, hogy a feladó garantálhatja, hogy a magasabb prioritású csomagokat küldi el először, de nem tudja garantálni, hogy ezeket a csomagokat egy bizonyos időn belül kézbesítik. Másrészt a QoS képes ilyen garanciát nyújtani egy ATM hálózaton, mert az ATM kapcsolatorientált technológia.
Windows 2000 vs. Windows Server 2003
Korábban említettem, hogy a Microsoft először vezette be a QoS-t a Windows 2000 rendszerrel, és ez a QoS alkalmazás azóta jelentősen fejlődött. Ezért szeretnék egy kicsit beszélni a QoS közötti különbségekről a Windows 2000 és a Windows XP és a Windows Server 2003 között (amelyek nagyjából ugyanúgy használják ezt a szabványt).
A Windows 2000 rendszerben a QoS az Intserv architektúrán alapult, amelyet a Windows XP és a Windows Server 2003 nem támogat. A Microsoft azért döntött úgy, hogy nem használja ezt az architektúrát, mert az alapul szolgáló API-t nehéz volt használni, és az architektúra méretezési problémákkal küzdött.
Egyes szervezetek még mindig Windows 2000 rendszert használnak, ezért úgy gondoltam, adok egy kis hátteret a Windows 2000 QoS architektúrájának működéséről. A Windows 2000 az RSVP nevű protokollt használja a sávszélesség-erőforrások lefoglalására. Ha sávszélességet kér, a Windowsnak meg kell határoznia, hogy mikor lehet csomagokat továbbítani. Ehhez a Windows 2000 az SBM (Sunbelt Bandwidth manager) nevű jelprotokoll segítségével közli a küldővel, hogy készen áll a csomagok fogadására. Az Admission Control Service (ACS) ellenőrzi, hogy rendelkezésre áll-e a tényleges sávszélesség, majd engedélyezi vagy elutasítja a sávszélesség-kérést.
forgalomkezelő API
A hálózati forgalom priorizálásának egyik fő problémája, hogy nem lehet prioritást adni a forgalomnak az azt létrehozó számítógép alapján. Gyakori, hogy egyetlen számítógépen több alkalmazás fut, és minden egyes alkalmazáshoz (és operációs rendszerhez) külön forgalmi áramlást hoznak létre. Amikor ez megtörténik, minden forgalmi áramlást külön-külön kell priorizálni. Végül is előfordulhat, hogy az egyik alkalmazásnak tartalék sávszélességre van szüksége, míg egy másik alkalmazás ideális a legjobb átvitelhez.
Itt jön képbe a Traffic Control API (Traffic Control Programming Interface). A Traffic Control API egy olyan alkalmazásprogramozási felület, amely lehetővé teszi a QoS-beállítások alkalmazását az egyes csomagokra. A Traffic Control API úgy működik, hogy egyedi forgalmi folyamatokat határoz meg, és különféle QoS-vezérlési módszereket alkalmaz ezekre az áramlásokra.
A Traffic Control API első dolga az úgynevezett szűrőspecifikáció létrehozása. A szűrőspecifikáció lényegében egy szűrő, amely meghatározza, hogy mit jelent egy csomag egy adott adatfolyamhoz való tartozása. A filterspec által használt egyes attribútumok közé tartozik a csomag forrás- és cél IP-címe, valamint a portszám.
A szűrőspecifikáció meghatározása után az API lehetővé teszi egy folyamatspecifikáció létrehozását. A folyamatspec határozza meg a QoS paramétereket, amelyek a csomagok sorozatára vonatkoznak. A folyamatspec által meghatározott paraméterek egy része magában foglalja a bitsebességet (megengedett bitsebesség) és a szolgáltatás típusát.
A Traffic Control API által meghatározott harmadik fogalom az áramlási koncepció. A folyamat olyan csomagok egyszerű sorozata, amelyekre ugyanaz a folyamatspec vonatkozik. Egyszerűen fogalmazva, a szűrőspecifikáció határozza meg, hogy mely csomagok kerüljenek bele a folyamatspecifikációba. A folyamatspec határozza meg, hogy a csomagok feldolgozása magasabb prioritással történik-e, és az áramlás a folyamatspec hatálya alá tartozó csomagok tényleges átvitele. Az adatfolyamban lévő összes csomagot egyenlően kezeljük.
Meg kell említeni, hogy a Traffic Control API egyik előnye a Windows 2000-ben használt Generic QoS API-val szemben az aggregáció (összevonás) használatának lehetősége. Ha egy csomópont több alkalmazással rendelkezik, amelyek több adatfolyamot küldenek egy közös célállomásra, akkor ezek a csomagok egy közös adatfolyamba kombinálhatók. Ez akkor is működik, ha az alkalmazások eltérő portszámokat használnak, mindaddig, amíg a forrás és a cél IP-címe megegyezik.
Általános csomagosztályozó
Az előző részben beszéltem a flowspec, a filterspec és a flow kapcsolatáról. Fontos azonban megjegyezni, hogy a Traffic Control API csak egy alkalmazásprogramozási felület. Mint ilyen, feladata a forgalmi áramlások azonosítása és rangsorolása, nem pedig az áramlások létrehozása.
Az általános csomagosztályozó felelős az adatfolyamok létrehozásáért. Ahogy az utolsó szakaszból emlékszik, a folyamatspecifikációban meghatározott egyik attribútum a szolgáltatás típusa volt. A szolgáltatás típusa alapvetően meghatározza a szál prioritását. Az általános csomagosztályozó felelős a folyamspecifikációhoz rendelt szolgáltatástípus meghatározásáért, majd a kapcsolódó csomagokat a szolgáltatás típusának megfelelő sorba helyezi. Minden szál külön sorba kerül.
QoS csomagütemező
A harmadik QoS komponens, amelyet tudnia kell, a QoS csomagütemező. Egyszerűen fogalmazva, a QoS csomagütemező fő feladata a forgalom alakítása. Ehhez a csomagütemező különböző sorokból fogad csomagokat, majd ezeket a csomagokat prioritásokkal és áramlási sebességekkel jelöli meg.
Amint azt a cikksorozat első részében tárgyaltam, a QoS megfelelő működéséhez a csomagok forrása és a célállomás közötti különféle összetevőknek támogatniuk kell a QoS-t (azaz tisztában kell lenniük vele). Míg ezeknek az eszközöknek tudniuk kell kezelni a QoS-t, azt is tudniuk kell, hogyan kezeljék a normál forgalmat prioritások meghatározása nélkül. Ennek lehetővé tétele érdekében a QoS egy címkézésnek nevezett technológiát használ.
Valójában itt kétféle jelölés létezik. A QoS csomagütemező a 3. rétegű eszközök által felismert Diffserv jelölést és a 2. rétegű eszközök által felismert 802.1p jelölést használja.
A QoS csomagütemező konfigurálása
Mielőtt bemutatnám, hogyan működik a jelölés, meg kell jegyezni, hogy be kell állítania egy QoS csomagütemezőt, hogy minden működjön. A Windows Server 2003 rendszerben a QoS csomagütemező egy opcionális hálózati összetevő, akárcsak a Microsoft-hálózatok vagy a TCP/IP-protokoll kliense. A QoS Packet Scheduler engedélyezéséhez nyissa meg a kiszolgáló hálózati kapcsolatának tulajdonságait, és jelölje be a QoS csomagütemező melletti négyzetet az A. ábrán látható módon. Ha a QoS csomagütemező nem szerepel a listában, kattintson a Telepítés gombra, és kövesse az utasításokat.
A ábra: A QoS csomagütemezőt engedélyezni kell a QoS használatához
Egy másik dolog, amit tudnia kell a QoS csomagütemezőről, hogy a hálózati adapternek támogatnia kell a 802.1p címkézést, hogy megfelelően működjön. Az adapter ellenőrzéséhez kattintson a Konfigurálás gombra, az A ábra, és a Windows megjeleníti a hálózati adapter tulajdonságait. Ha megnézi a tulajdonságok oldalon a "Speciális" lapot, látni fogja a hálózati adapter által támogatott különféle tulajdonságokat.
Ha megnézi a B ábrát, láthatja, hogy a lista egyik tulajdonsága a 802.1Q/1P VLAN Tagging. Azt is látja, hogy ez a tulajdonság alapértelmezés szerint le van tiltva. A 802.1p címkézés engedélyezéséhez egyszerűen engedélyezze ezt a funkciót, majd kattintson az OK gombra.
B ábra: Engedélyeznie kell a 802.1Q/1P VLAN címkézést
Talán észrevette a B ábrán, hogy az engedélyezett tulajdonság a VLAN címkézéshez kapcsolódik, nem pedig a csomagcímkézéshez. Ennek az az oka, hogy a prioritásjelzőket a VLAN-címkék tartalmazzák. A 802.1Q szabvány VLAN-okat és VLAN-címkéket határoz meg. Ez a szabvány valójában három bitet foglal le a VLAN-csomagban, amelyeket a prioritási kód írására használnak. Sajnos a 802.1Q szabvány soha nem határozza meg, hogy melyek legyenek ezek a prioritási kódok.
A 802.1P a 802.1Q kiegészítéseként jött létre. A 802.1P prioritásjelölést határoz meg, amely VLAN-címkébe csomagolható.
802.1P jel
Ahogy az előző részben mondtam, a 802.1p jelzés az OSI modell második rétegében történik. Ezt a réteget fizikai eszközök, például kapcsolók használják. A 802.1p szabványt támogató 2. rétegű eszközök megtekinthetik a csomagokhoz rendelt prioritási jelöléseket, majd ezeket a csomagokat külön forgalmi osztályokba csoportosíthatják.
Ethernet-hálózatokon a prioritási címkézést a VLAN-címkék tartalmazzák. A VLAN-okat és a VLAN-címkéket a 802.1Q szabvány határozza meg, amely három bites prioritási mezőt határoz meg, de valójában nem határozza meg, hogyan kell ezt a prioritási mezőt használni. Itt jön képbe a 802.1P szabvány.
A 802.1P különféle prioritási osztályokat határoz meg, amelyek a 802.1Q szabvánnyal együtt használhatók. Végső soron a 802.1Q az adminisztrátorra bízza a prioritások megjelölését, így technikailag nem kell követnie a 802.1P irányelveit, de úgy tűnik, mindenki a 802.1P-t választja.
Bár a 802.1P szabványok használata a 2. réteg jelölésére valószínűleg csak elméletnek hangzik, valójában a csoportházirend-beállítások segítségével határozható meg. A 802.1P szabvány nyolc különböző prioritási osztályt biztosít (0 és 7 között). A magasabb prioritású csomagokat a magasabb kézbesítési prioritással rendelkező QoS kezeli.
Alapértelmezés szerint a Microsoft a következő prioritási jelöléseket rendeli hozzá:
De ahogy korábban említettem, ezeket a prioritásokat megváltoztathatja a különféle csoportházirend-beállítások módosításával. Ehhez nyissa meg a Csoportházirend-szerkesztőt, és lépjen a konzolfába a Számítógép konfigurációja\Felügyeleti sablonok\Hálózatok\QoS csomagütemező\Második szintű prioritási érték ágak mentén. Amint az A ábrán látható, vannak csoportházirend-beállítások, amelyek megfelelnek a fent felsorolt prioritási jelöléseknek. Bármelyik szolgáltatástípushoz hozzárendelheti saját prioritásjelölési szintjeit. Ne feledje azonban, hogy ezek a csoportházirend-beállítások csak a Windows XP, 2003 vagy Vista rendszert futtató gazdagépekre vonatkoznak.
A. ábra: A Csoportházirend-szerkesztővel testreszabhatja a második szintű prioritásjelölést.
Külön szolgáltatások
Amint azt egy korábbi cikkben kifejtettem, a QoS prioritásjelölést végez az OSI modell második és harmadik rétegében. Ez biztosítja, hogy a prioritásokat a csomagkézbesítési folyamat során végig figyelembe vegyék. Például a switchek az OSI modell 2. rétegében működnek, de az útválasztók általában a 3. rétegben működnek. Így, ha a csomagok csak 802.1p prioritásjelölést használnak, akkor a switch prioritásokat rendelne ezekhez a csomagokhoz, de ezeket a prioritásokat figyelmen kívül hagynák a hálózati útválasztók. Ennek megakadályozása érdekében a QoS a Differentiated Services protokollt (Diffserv) használja az OSI-modell harmadik rétegének forgalmának prioritásaihoz. A Diffserv jelöléseket az IP-csomagok fejlécei tartalmazzák TCP/IP használatával.
A Diffserv által használt architektúrát eredetileg az RFC 2475 határozta meg. Az RFC 2474 azonban számos architektúra-specifikációt átírt. Az RFC 2474 meghatározza a Diffserv architektúrát mind az IPv4, mind az IPv6 számára.
Az RFC 2474 IPv4 megvalósításának érdekessége, hogy bár a Diffserv-t teljesen újradefiniálták, még mindig visszafelé kompatibilis az eredeti RFC 2475 specifikációval. Ez azt jelenti, hogy a régebbi útválasztók, amelyek nem támogatják az újabb specifikációkat, felismerhetik a hozzárendelt prioritásokat.
A jelenlegi Diffserv alkalmazás TOS (Type of Service) oktetteket használ a Diffserv érték (ez az úgynevezett DSCP érték) tárolására. Ezen az oktetten belül az első hat bit tárolja a DSCP értéket, az utolsó két bit pedig nem használatos. Az ok, amiért ezek a jelölések visszafelé kompatibilisek az RFC 2475 specifikációval, az az, hogy az RFC 2475 ugyanazon oktett első három bitjét követelte meg az IP-szekvencia információban. Bár a DSCP értékek hat bitesek, az első három bit még mindig az IP-szekvenciát tükrözi.
A korábban bemutatott 802.1p jelöléshez hasonlóan a Diffserv prioritásokat különféle csoportházirend-beállításokon keresztül konfigurálhatja. Mielőtt bemutatnám, hogyan kell, bemutatom a Windows rendszeren használt szabványos Diffserv prioritásokat:
Talán észrevette, hogy a Diffserv prioritási jelölések teljesen más tartományt használnak, mint a 802.1P. A 0 és 7 közötti tartomány támogatása helyett a Diffserv a 0 és 63 közötti prioritásjelölési tartományt támogatja, ahol a nagyobb számok magasabb prioritásúak.
Ahogy korábban mondtam, a Windows lehetővé teszi a Diffserv prioritási jelölések meghatározását a csoportházirend-beállításokon keresztül. Ne feledje azonban, hogy néhány fejlettebb útválasztó saját Diffserv értéket rendel a csomagokhoz, függetlenül attól, hogy a Windows mit rendelt hozzá.
Ezt szem előtt tartva konfigurálhatja a Diffserv-prioritásjelölést, ha megnyitja a Csoportházirend-szerkesztőt, és megnyitja a konzolfát a Számítógép konfigurációja\Felügyeleti sablonok\Hálózat\QoS csomagütemező alatt.
Ha megnézi a B ábrát, észre fogja venni, hogy a QoS Packet Scheduler fül alatt két DSCP-vel kapcsolatos lap található. Ezen lapok egyike lehetővé teszi DSCP prioritási jelölések hozzárendelését a folyamspecifikációnak megfelelő csomagokhoz, a második pedig lehetővé teszi DSCP prioritási jelölések beállítását a nem megfelelő csomagokhoz. A tényleges opciók mindkét lapnál hasonlóak, amint az a C ábrán látható.
B ábra: A Windows külön kezeli a DSCP-prioritásjelöléseket a folyamatspecifikációnak megfelelő és nem megfelelő csomagok esetében.
C ábra: A DSCP prioritási jelöléseket manuálisan is hozzárendelheti a különböző szolgáltatástípusokhoz.
Egyéb csoportházirend-beállítások
Ha megnézi a B ábrát, észre fogja venni, hogy van három csoportházirend-beállítás, amelyekről nem beszéltem. Röviden szerettem volna megemlíteni, hogy mik ezek a lehetőségek, és mit tesznek azok számára, akiket érdekelhet.
A Limit Outstanding Packets paraméter lényegében egy szolgáltatási küszöbérték. Ha a kimenő csomagok száma elér egy bizonyos értéket, akkor a QoS megtagad minden további sávszélesség-kiosztást a hálózati adapter számára, amíg az érték a maximálisan megengedett küszöb alá nem esik.
A Foglalható sávszélesség korlátozása beállítás szabályozza a teljes sávszélesség azon százalékát, amelyet a QoS-kompatibilis alkalmazások lefoglalhatnak. Alapértelmezés szerint a QoS-kompatibilis alkalmazások a hálózati sávszélesség akár 80%-át is lefoglalhatják. Természetesen a QoS-alkalmazások által lefoglalt és jelenleg nem használt sávszélesség bármely részét más alkalmazások is használhatják.
A Set Timer Resolution paraméter szabályozza azt a minimális időegységet (mikromásodpercben), amelyet a QoS csomagütemező a csomagok ütemezésére használ. Lényegében ez a beállítás szabályozza azt a maximális gyakoriságot, amelyen a csomagok kézbesítési sorba helyezhetők.
QoS és modemek
A csaknem univerzális szélessávú technológia korában még a modemekről beszélni is furcsának tűnik. Azonban még mindig sok kisvállalkozás és otthoni felhasználó használja a modemet internetkapcsolati mechanizmusként. Nemrég még azt is láttam, hogy egy nagyvállalat modemekkel kommunikál a műholdas irodákkal, amelyek távoli helyeken találhatók, ahol nincs hozzáférés a szélessávú technológiához.
Természetesen a modemek használatának legnagyobb problémája az általuk kínált korlátozott sávszélesség. Kevésbé nyilvánvaló, de nem kevésbé fontos probléma, hogy a felhasználók általában nem változtatnak online viselkedésükön, amikor betárcsázós kapcsolatokat használnak. Természetesen előfordulhat, hogy a felhasználók nem érzik erősen a nagy fájlok letöltését, ha modemen keresztül csatlakoznak az internethez, de a felhasználói viselkedés többi része ugyanaz marad, mintha szélessávú kapcsolaton keresztül csatlakoznának.
A felhasználók általában nem aggódnak túl sokat amiatt, hogy a Microsoft Outlookot folyamatosan nyitva tartsák, vagy a háttérben fájlok letöltése közben böngésznek. Egyes felhasználók az azonnali üzenetküldő rendszert is folyamatosan nyitva tartják. Az ilyen típusú viselkedéssel az a probléma, hogy ezen alkalmazások vagy feladatok mindegyike bizonyos mennyiségű internetkapcsolat sávszélességét fogyasztja.
Ha látni szeretné, hogyan segíthet a QoS, nézzük meg, mi történik normál körülmények között, amikor nem használják a QoS-t. Általában az első internetes hozzáférést próbáló alkalmazás rendelkezik a legtöbb joggal a kapcsolat használatához. Ez nem azt jelenti, hogy más alkalmazások nem használhatják a kapcsolatot, hanem azt, hogy a Windows feltételezi, hogy más alkalmazások nem használják a kapcsolatot.
A kapcsolat létrehozása után a Windows elkezdi dinamikusan módosítani a TCP fogadási ablak méretét. A TCP fogadási ablak mérete az az adatmennyiség, amelyet el lehet küldeni, mielőtt az adatok fogadásának visszaigazolására várnánk. Minél nagyobb a TCP fogadási ablak mérete, a küldő annál több csomagot tud továbbítani, mielőtt megvárná a sikeres kézbesítés megerősítését.
A TCP fogadási ablak méretét gondosan be kell állítani. Ha a TCP fogadási ablaka túl kicsi, a hatékonyság is csorbát szenved, mivel a TCP nagyon gyakori nyugtázást igényel. Ha azonban a TCP fogadási ablaka túl nagy, akkor előfordulhat, hogy a gép túl sok adatot küld, mielőtt észrevenné, hogy probléma történt az átvitel során. Emiatt nagy mennyiségű adatot kell újraküldeni, ami szintén befolyásolja a hatékonyságot.
Amikor egy alkalmazás betárcsázós internetkapcsolatot kezd használni, a Windows dinamikusan módosítja a TCP fogadási ablak méretét a csomagok küldésekor. A Windows célja, hogy elérje azt az állandó állapotot, ahol a TCP fogadási ablak mérete optimálisan van beállítva.
Tegyük fel, hogy a felhasználó megnyit egy második alkalmazást, amelyhez szintén internetkapcsolat szükséges. Ezt követően a Windows elindítja a TCP lassú indítási algoritmusát, amely a TCP fogadási ablak méretének optimális értékre állításáért felelős algoritmus. A probléma az, hogy a TCP-t már használja a korábban elindított alkalmazás. Ez kétféleképpen érinti a második alkalmazást. Először is, a második alkalmazásnak sokkal tovább tart, amíg eléri az optimális TCP fogadási ablakméretet. Másodszor, a második alkalmazás adatsebessége mindig lassabb lesz, mint az előtte futó alkalmazás adatsebessége.
A jó hír az, hogy ezeket a problémákat elkerülheti Windows XP és Windows Server 2003 rendszeren a QOS Packet Scheduler egyszerű futtatásával. Ezt követően a QOS csomagütemező automatikusan a Deficit Round Robin nevű technológiát fogja használni, amikor a Windows lassú kapcsolati sebességet észlel.
A Deficit Round Robin úgy működik, hogy dinamikusan külön sorokat hoz létre minden egyes internet-hozzáférést igénylő alkalmazáshoz. A Windows ezeket a sorokat körkörös módon szolgálja ki, ami nagymértékben javítja az internet-hozzáférést igénylő összes alkalmazás hatékonyságát. Ha kíváncsi, a Deficit Round Robin a Windows 2000 Server rendszeren is elérhető, de nincs automatikusan engedélyezve.
Internetkapcsolat megosztása
A Windows XP és a Windows Server 2003 rendszerben a QoS az internetkapcsolat megosztását is megkönnyíti. Amint azt valószínűleg Ön is tudja, az internetkapcsolat megosztása a NAT-alapú útválasztó létrehozásának egyszerűsített változata. Az a számítógép, amelyhez az internetkapcsolat fizikailag kapcsolódik, útválasztóként és DHCP-kiszolgálóként működik a hálózat többi számítógépe számára, ezáltal hozzáférést biztosít számukra az internethez ezen a gazdagépen keresztül. Az internetkapcsolat megosztását általában csak kisméretű, peer-to-peer hálózatokban használják, amelyekben nincs tartományi infrastruktúra. A nagyobb hálózatok általában fizikai eszközútválasztókat vagy útválasztási és telefonos szolgáltatásokat használnak.
A fenti részben már elmagyaráztam, hogy a Windows hogyan állítja be dinamikusan a TCP fogadási ablak méretét. Ez a dinamikus beállítás azonban problémákat okozhat az internetkapcsolat megosztása során. Ennek az az oka, hogy a helyi hálózaton lévő számítógépek közötti kapcsolat általában viszonylag gyors. Ez a kapcsolat általában 100 Mb Ethernet vagy 802.11G vezeték nélküli kapcsolatból áll. Bár az ilyen típusú kapcsolatok messze nem a leggyorsabbak, sokkal gyorsabbak, mint az Egyesült Államokban elérhető legtöbb internetkapcsolat. Itt van a probléma.
Az ügyfélszámítógépnek az interneten keresztül kell kommunikálnia, de ezt közvetlenül nem tudja megtenni. Ehelyett egy internetkapcsolat-megosztó gazdagépet használ hozzáférési modulként. Amikor a Windows kiszámítja az optimális TCP-fogadási ablakméretet, azt a helyi gép és az internetkapcsolat-megosztó gép közötti kapcsolati sebesség alapján teszi. Problémás lehet a különbség aközött, hogy egy helyi gép mennyi adatot tud ténylegesen megszerezni az internetről, és aközött, amelyet az internetkapcsolat megosztási gazdagépéhez való kapcsolódási sebesség alapján vélt megszerezni. Pontosabban, a kapcsolat sebességének különbsége potenciálisan olyan helyzeteket okozhat, amikor az adatok biztonsági mentése egy lassú kapcsolathoz kapcsolódó sorba kerül.
Itt jön képbe a QoS. Ha telepíti a QOS csomagütemezőt az Internetkapcsolat megosztási gazdagépre, az Internetkapcsolat megosztása állomás érvényteleníti a TCP fogadási ablak méretét. Ez azt jelenti, hogy az Internetkapcsolat-megosztási gazdagép a helyi gazdagépek TCP-fogadási ablakának méretét ugyanarra az értékre állítja be, amely akkor lenne, ha közvetlenül az internethez kapcsolódnának. Ez kijavítja a hálózati kapcsolat sebességének eltéréséből adódó problémákat.
Következtetés
Ebben a cikksorozatban a QoS-ről beszéltem, és arról, hogyan használható a forgalom különböző típusú hálózati kapcsolatokon történő alakítására. Mint látható, a QoS sokkal hatékonyabbá teheti a hálózat működését azáltal, hogy a forgalmat úgy alakítja, hogy az kihasználja a hálózat legforgalmasabb pillanatait, és biztosítsa a magasabb prioritású forgalom gyors szállítását.
Brien Posey
A QoS mítosza
Nincs olyan ember, aki legalább egyszer ne olvasta volna el a Windows XP rendszerrel kapcsolatos GYIK-ot. És ha igen, akkor mindenki tudja, hogy létezik egy ilyen káros Quality of Service – röviden QoS. A rendszer konfigurálásakor erősen ajánlott kikapcsolni, mert alapból 20%-kal korlátozza a hálózati sávszélességet, és úgy tűnik, ez a probléma a Windows 2000-ben is fennáll.
Íme a sorok:
"K: Hogyan lehet teljesen letiltani a QoS (Quality of Service) szolgáltatást? Hogyan konfigurálható? Igaz, hogy korlátozza a hálózati sebességet?
V: Valóban, alapértelmezés szerint a Quality of Service a csatorna sávszélességének 20%-át fenntartja igényeinek (bármilyen - legalább 14400-as modem, legalább gigabites Ethernet). Sőt, még ha eltávolítja is a QoS Packet Scheduler szolgáltatást a Properties kapcsolatból, ez a csatorna nem szabadul fel. Itt felszabadíthatja a csatornát, vagy egyszerűen beállíthatja a QoS-t. Indítsa el a csoportházirend-kisalkalmazást (gpedit.msc). A Csoportházirendben megtaláljuk a Helyi számítógép házirendet, és kattintson az Adminisztrációs sablonokra. Válassza ki a Network - QoS Packet Sheduler elemet. Lefoglalható sávszélesség korlátozásának engedélyezése. Most csökkentse a sávszélesség-korlátot 20%-ról 0%-ra, vagy egyszerűen kapcsolja ki. Ha szükséges, itt más QoS paramétereket is beállíthat. Már csak a változtatások újraindítása maradt."
20% persze sok. A Microsoft valóban a Mazda. Az ilyen jellegű kijelentések a GYIK-től a GYIK-ig, fórumról fórumra, médiáról médiára vándorolnak, mindenféle "csípésben" használatosak - a Windows XP "konfigurálására" szolgáló programok (egyébként nyissa meg a "Csoportházirendek" és a "Helyi" Biztonsági szabályzatok", és a testreszabási lehetőségek gazdagsága szempontjából egyetlen "twikka" sem hasonlítható össze velük). Az ilyen megalapozatlan állításokat körültekintően kell kezelni, amit most meg fogunk tenni, szisztematikus megközelítést alkalmazva. Vagyis hivatalos elsődleges forrásokra támaszkodva alaposan áttanulmányozzuk a problémás kérdést.
Mi az a minőségi szolgáltatási hálózat?
Vegyük a hálózati rendszer alábbi egyszerűsített definícióját. Az alkalmazások futnak és futnak gazdagépeken, és kommunikálnak egymással. Az alkalmazások adatokat küldenek az operációs rendszernek a hálózaton keresztüli továbbítás céljából. Miután az adatokat átvitték az operációs rendszerbe, hálózati forgalommá válik.
A hálózati QoS azon támaszkodik, hogy a hálózat képes-e feldolgozni ezt a forgalmat oly módon, hogy garantáltan teljesítse egyes alkalmazások kéréseit. Ehhez olyan alapvető mechanizmusra van szükség a hálózati forgalom feldolgozására, amely képes azonosítani azt a forgalmat, amely jogosult speciális feldolgozásra, és jogosult e mechanizmusok ellenőrzésére.
A QoS funkcionalitást két hálózati szereplő kielégítésére tervezték: a hálózati alkalmazások és a hálózati rendszergazdák. Gyakran nem értenek egyet. A hálózati rendszergazda korlátozza az adott alkalmazás által használt erőforrásokat, miközben az alkalmazás megpróbál a lehető legtöbb hálózati erőforrást megragadni. Érdeklődésük összeegyeztethető, figyelembe véve, hogy a hálózati rendszergazda minden alkalmazással és felhasználóval szemben domináns szerepet tölt be.
Alapvető QoS paraméterek
A különböző alkalmazások eltérő követelményeket támasztanak a hálózati forgalom kezelésére. Az alkalmazások többé-kevésbé tolerálják a késéseket és a forgalomkieséseket. Ezek a követelmények a következő QoS-hez kapcsolódó paraméterekben találtak alkalmazásra:
Sávszélesség (sávszélesség) - az a sebesség, amellyel az alkalmazás által generált forgalmat továbbítani kell a hálózaton;
Késés – Az a késés, amelyet egy alkalmazás elvisel az adatcsomag kézbesítésében.
Jitter – a késleltetési idő módosítása.
Veszteség – az elveszett adatok százalékos aránya.
Ha végtelen hálózati erőforrás állna rendelkezésre, akkor az összes alkalmazásforgalmat a szükséges sebességgel, nulla késleltetéssel, nulla késleltetési változással és veszteséggel lehetne továbbítani. A hálózati erőforrások azonban nem korlátlanok.
A QoS-mechanizmus szabályozza a hálózati erőforrások elosztását az alkalmazásforgalom számára az átviteli követelmények teljesítése érdekében.
Alapvető QoS erőforrások és forgalomfeldolgozási mechanizmusok
A gazdagépeket összekapcsoló hálózatok számos hálózati eszközt használnak, beleértve a gazdagép hálózati adaptereket, útválasztókat, kapcsolókat és hubokat. Mindegyik rendelkezik hálózati interfésszel. Mindegyik hálózati interfész véges sebességgel képes fogadni és továbbítani a forgalmat. Ha a forgalom interfész felé történő továbbításának sebessége nagyobb, mint az interfész forgalma, torlódás lép fel.
A hálózati eszközök úgy tudják kezelni a torlódási állapotot, hogy sorba állítják a forgalmat az eszköz memóriájában (pufferében), amíg a torlódás el nem múlik. Más esetekben a hálózati eszközök csökkenthetik a forgalmat a torlódások enyhítése érdekében. Ennek eredményeként az alkalmazások időtúllépési változásokat tapasztalnak (mivel a forgalom az interfészeken sorban áll) vagy forgalomkiesés.
A hálózati interfészek azon képessége, hogy továbbítsák a forgalmat, és a rendelkezésre álló memória a forgalom tárolására a hálózati eszközökben (amíg a forgalmat tovább nem lehet továbbítani) az alapvető erőforrások, amelyek szükségesek az alkalmazások forgalmi áramlásainak QoS biztosításához.
QoS erőforrások kiosztása a hálózati eszközök között
A QoS-t támogató eszközök intelligensen használják a hálózati erőforrásokat a forgalom továbbítására. Vagyis a késleltetést jobban tűrő alkalmazások forgalmát sorba állítják (egy pufferben tárolják a memóriában), és a késleltetés szempontjából kritikus alkalmazások forgalmát továbbítják.
Ennek a feladatnak a végrehajtásához a hálózati eszköznek azonosítania kell a forgalmat a csomagok osztályozásával, valamint sorokkal és a kiszolgálásukra szolgáló mechanizmusokkal kell rendelkeznie.
Forgalomfeldolgozó mechanizmus
A forgalomfeldolgozási mechanizmus a következőket tartalmazza:
802.1p
Differenciált szolgáltatások ugrásonkénti viselkedések (diffserv PHB).
Integrált szolgáltatások (intserv).
ATM stb.
A legtöbb LAN IEEE 802 technológián alapul, beleértve az Ethernetet, a token-ringet stb. A 802.1p egy forgalomfeldolgozási mechanizmus, amely támogatja a QoS-t az ilyen hálózatokban.
A 802.1p meghatároz egy mezőt (2. réteg az OSI hálózati modellben) a 802-es csomagfejlécben, amely nyolc prioritási érték egyikét hordozhatja. Általában a gazdagépek vagy útválasztók, amikor forgalmat küldenek a helyi hálózatra, megjelölnek minden egyes elküldött csomagot, és egy bizonyos prioritási értéket rendelnek hozzá. A hálózati eszközöktől, például a kapcsolóktól, hidaktól és elosztóktól elvárás, hogy a csomagokat megfelelő módon dolgozzák fel sorbanállási mechanizmusok segítségével. A 802.1p hatóköre a helyi hálózatra (LAN) korlátozódik. Amint a csomag áthalad a LAN-on (OSI 3. rétegen keresztül), a 802.1p prioritás megszűnik.
A Diffserv egy 3. rétegű mechanizmus, amely az IP-csomagok 3. rétegbeli fejlécében határoz meg egy mezőt, amelyet diffserv codepoint-nak (DSCP) neveznek.
Az Intserv olyan szolgáltatások halmaza, amelyek meghatározzák a garantált szolgáltatást és a terhelést vezérlő szolgáltatást. A garantált szolgáltatás azt ígéri, hogy bizonyos mennyiségű forgalmat mérhető és korlátozott késleltetéssel szállít. A terhelést kezelő szolgáltatás vállalja, hogy egy bizonyos mennyiségű forgalmat "könnyű hálózati forgalom megjelenésével" szállít. Ezek mérhető szolgáltatások abban az értelemben, hogy meghatározott mennyiségű forgalom számára mérhető QoS-t biztosítanak.
Mivel az ATM viszonylag kis cellákra tördeli a csomagokat, nagyon alacsony késleltetést kínálhat. Ha egy csomagot sürgősen el kell küldeni, az ATM interfész mindig szabadon küldhető egy cella elküldéséhez szükséges ideig.
A QoS számos más összetett mechanizmussal rendelkezik, amelyek működésre késztetik ezt a technológiát. Csak egy fontos pontot jegyzünk meg: a QoS működéséhez támogatni kell ezt a technológiát és a megfelelő konfigurációt az átvitel során a kezdőponttól a végéig.
Az érthetőség kedvéért tekintse meg a 2. ábrát. egy.
A következőket fogadjuk el:
Minden útválasztó részt vesz a szükséges protokollok továbbításában.
Egy 64 Kb/s-ot igénylő QoS munkamenet indul az A és a B gazdagép között.
Egy másik, 64 Kbps-ot igénylő munkamenet indul az A és a D gazdagép között.
A séma egyszerűsítése érdekében feltételezzük, hogy az útválasztók úgy vannak beállítva, hogy le tudják foglalni az összes hálózati erőforrást.
Esetünkben egy 64 Kbps-os foglalási kérelem három útválasztót érne el az A és B gazdagép közötti adatútvonalon. Egy másik 64 Kbps-os foglalási kérelem három útválasztót érne el A és D gazdagép között. Az útválasztók teljesítenék ezeket az erőforrás-foglalási kéréseket, mert ne lépje túl a maximumot. Ha ehelyett a B és C gazdagépek egyidejűleg 64 Kbps-os QoS munkamenetet kezdeményeztek az A gazdagéppel, akkor az ezeket a gazdagépeket (B és C) kiszolgáló útválasztó megtagadná az egyik kapcsolatot.
Most tegyük fel, hogy a hálózati adminisztrátor letiltja a QoS feldolgozást a B, C, D, E gazdagépeket kiszolgáló alsó három útválasztón. Ebben az esetben a 128 Kbps-ig terjedő erőforráskéréseket a csatlakozásban részt vevő gazdagép helyétől függetlenül kielégítik. A minőségbiztosítás azonban alacsony lenne, mivel az egyik gazdagépre irányuló forgalom veszélyeztetné a másik gazdagép forgalmát. A QoS fenntartható, ha az upstream router minden kérést 64 Kbps-ra korlátozna, de ez a hálózati erőforrások nem hatékony felhasználását eredményezné.
Másrészt az összes hálózati kapcsolat sávszélessége 128 Kbps-ra növelhető. A megnövelt sávszélesség azonban csak akkor lesz felhasználva, ha a B és C (vagy D és E) gazdagép egyszerre kér erőforrásokat. Ha nem ez a helyzet, akkor a hálózati erőforrásokat ismét nem hatékonyan használják fel.
Microsoft QoS összetevők
A Windows 98 csak felhasználói szintű QoS összetevőket tartalmaz, beleértve:
Alkalmazási összetevők.
GQoS API (a Winsock 2 része).
QoS szolgáltató.
A Windows 2000/XP/2003 operációs rendszer mindent, amit fent leírtunk, és a következő összetevőket tartalmazza:
Resource Reservation Protocol Service Provider (Rsvpsp.dll) és RSVP Services (Rsvp.exe) és QoS ACS. Nem használt Windows XP, 2003 alatt.
Forgalomkezelés (Traffic.dll).
Általános csomagosztályozó (Msgpc.sys) A csomagosztályozó határozza meg azt a szolgáltatási osztályt, amelyhez a csomag tartozik. Ezzel a csomag a megfelelő sorba kerül. A sorokat a QoS Packet Scheduler kezeli.
QoS csomagütemező (Psched.sys). Megadja a QoS paramétereket egy adott adatfolyamhoz. A forgalom meghatározott prioritási értékkel van megjelölve. A QoS csomagütemező meghatározza az egyes csomagok sorba állítási ütemezését, és kezeli a sorba állított csomagok közötti versengési kérelmeket, amelyeknek párhuzamos hozzáférésre van szükségük a hálózathoz. 
A 2. ábra diagramja szemlélteti a protokollvermet, a Windows-összetevőket és azok interakcióját a gazdagépen. A Windows 2000 rendszerben használt, de a Windows XP/2003 rendszerben nem használt elemek nem jelennek meg az ábrán.
Az alkalmazások a verem tetején találhatók. Lehet, hogy ismerik a QoS-t, vagy nem. A QoS teljes erejének kihasználása érdekében a Microsoft általános QoS API-hívások használatát javasolja az alkalmazásokban. Ez különösen fontos a magas színvonalú szolgáltatási garanciát igénylő alkalmazások esetében. Egyes segédprogramok QoS meghívására használhatók olyan alkalmazások nevében, amelyek nem ismerik a QoS-t. A forgalomkezelő API-n keresztül dolgoznak. Például a NetMeeting a GQoS API-t használja. De az ilyen alkalmazásoknál a minőség nem garantált.
Utolsó köröm
A fenti elméleti pontok nem adnak egyértelmű választ arra a kérdésre, hogy hova megy a hírhedt 20% (amit, megjegyzem, még senki nem mért pontosan). A fentiek alapján ennek nem szabadna így lennie. Az ellenzők azonban új érvet hoznak fel: a QoS rendszer jó, de a megvalósítás ferde. Tehát 20% még mindig "kövér". Úgy tűnik, a szoftveróriást is belesütötték a problémába, hiszen már elég régóta cáfolta az ilyen kitalációkat.
Adjuk azonban át a szót a fejlesztőknek, és mutassunk be kiválasztott pontokat a „316666 – Windows XP szolgáltatásminőség (QoS) javításai és viselkedése” című cikkből irodalmi orosz nyelven:
"A hálózati sávszélesség száz százaléka elérhető az összes program számára történő kiosztásra, kivéve, ha egy program kifejezetten kér prioritási sávszélességet. Ez a "lefoglalt" sávszélesség más programok számára is elérhető, ha az azt kérő program nem küld adatokat.
A programok alapértelmezés szerint az alap csatlakozási sebesség 20%-át foglalhatják le minden egyes számítógépes interfészen. Ha a sávszélességet lefoglaló program nem küld elegendő adatot a teljes felhasználáshoz, akkor a lefoglalt sávszélesség fel nem használt része más adatfolyamok számára elérhető.
Különböző műszaki cikkekben és hírcsoportokban azt állították, hogy a Windows XP a rendelkezésre álló sávszélesség 20%-át mindig fenntartja a QoS számára. Ezek az állítások tévesek."
Ha most valaki még mindig "zabálja" a sávszélesség 20%-át, nos, azt tudom tanácsolni, hogy továbbra is használjon több különféle finomítást és ferde hálózati meghajtót. És nem lesz annyira "kövér".
Mindenki, QoS mítosz, haljon meg!
Jurij Trofimov,
