A vállalati hálózatokban egyre elterjedtebbek a következő alkalmazások: Voice-over-IP (VoIP), Customer Relationship Management (CRM), Enterprise Resource Planning (ERP). Az Internet szolgáltatók (ISP) szembesülnek azzal a kötelezettséggel, hogy biztosítaniuk kell a szigorú szolgáltatási szinteket (SLA). Továbbá a tipikus SLA paraméterek (Throughput, Latency, Jitter, Frame Loss) csak az IP rétegig fedik le a hálózati teljesítményt és nem tükrözik feltétlenül a végfelhasználói megelégedettséget (End User Experience). Hogyan képesek a szolgáltatók biztosítani azt, hogy a felhasználók legtöbb alkalmazása megkapja az igényelt teljes sávszélességet?

Transmission Control Protocol

A TCP egyike a TCP/IP protokoll család komponenseinek. Kapcsolatorientált és végponttól végpontig terjedő kommunikációs szolgáltatást nyújt az alkalmazások és az IP réteg között. Megbízható és garantált szállítási mechanizmust biztosít a nem valós idejű alkalmazások számára (pl.: az FTP, SMTP, stb.). A kapcsolatorientált kifejezés azt jelenti, hogy az adatátvitel résztvevőinek TCP kapcsolatot kell kiépíteniük az adatcserét megelőzően.

A TCP működése

A TCP elsődleges feladata megbízható szolgáltatás biztosítása a kommunikációban résztvevő állomások számára. Ez kihívást jelent egy olyan hálózaton, mint az Internet. Ezt az akadályt küzdi le az adatfolyam vezérlés, amely az egyes szegmensek közötti integritást biztosítja, továbbá a torlódásvezérlés, amely lehetővé teszi a fogadó állomás számára a küldő által továbbított adatok mennyiségi korlátozását. A TCP ehhez a következőkkel járul még hozzá:

Adatátvitel

A TCP az adatbyte-kat folyamatos jelfolyam formájában képes továbbítani mindkét irányban a kommunikáció szereplői között, miközben azokat becsomagolja un. TCP szegmensekbe és átadja az IP rétegnek. A TCP képes eldönteni, mikor kell blokkolni és mikor kell továbbítani az adatot.

Megbízhatóság

A TCP képes helyreállítani a sérült, elveszett, duplikált, vagy a sorrendből kiesett adatot, mivel sorszámot (sequence number) használ minden egyes elküldött adategységben és annak sikerességét a fogadó oldaláról érkező pozitív visszajelzéshez (positive acknowledgement) köti. Jelzése: ACK. Ha az ACK nem érkezik meg meghatározott idő alatt (timeout interval), az adatot ismételten elküldi. Ezen túlmenően a fogadó állomás sorszámot használ a szegmensek összerakásához, visszaállítja a megfelelő sorrendet és megszüntetni a duplikációt. Az ellenőrző összeg (checksum) biztosítja annak észlelését, hogy a szegmens sérült-e vagy sem.

Folyamatvezérlés

A fogadó állomás az un. ablakmérettel (window size) jelzi a küldő számára a feldolgozni képes adatmennyiséget. Ez egy byte-ban értelmezett mennyiség. A sorszámozás és az ablakozási technika nagymértékben hasonlít az óraállításhoz, hiszen a küldő mindig a legutóbbi visszajelzéshez igazítja a paramétert. A sorszám folyamatosan növekszik, majd visszatér a 0-hoz, amennyiben eléri a maximális értékét.

Multiplexálás

Egy állomás több TCP kommunikációt is fenntarthat egy időben. A kapcsolati azonosító (network socket) egyedileg azonosítja az összes kapcsolatot méghozzá un. port azonosítók használatával. Következésképpen több kapcsolati azonosító is használható ugyanahhoz az adatcseréhez, így jelentősen csökkenthető a magas hálózati késleltetés és az ablakozáshoz szükséges buffer limitációja.

Kapcsolattartás

A megbízhatóság és a folyamatvezérlés jól működő mechanizmusok, mivel a státusz információk adatfolyamonként rendelkezésre állnak. A státusz információinak együttese (socketek, sorozatszámok, ablakméretek) egyedileg azonosítja a kapcsolatban résztvevők (küldő és fogadó) logikai kapcsolatait.

A végpontok közötti TCP kommunikáció több lépésből áll:

  1. Kapcsolat felépítés a végpontok között (három-utas kézfogás)
  2. Megbízható adattovábbítás, amely garantálja a hibamentességet, illetve újraküldi a megsérült, elveszett adategységet.
  3. Sorba állítja, illetve kiszűri a duplikált adategységeket
  4. Biztosítja a folyamatvezérlést az ablakméret állításával

Alább egy példa TCP folyamatvezérlésre. Az ábrán jól látszik az „A” és „B” állomások közötti kommunikáció folyamata, habár a TCP képes kezelni a full-duplex kapcsolatokat, illetve a konkurens adattovábbítást mindkét irányban.

TCP throughput

Tisztán elméleti szempontból a maximális mennyiségű adat, amely kitöltheti az összeköttetést vagy a puffert. Ehhez a küldőnek és a fogadónak szüksége van egy maximum átvitelre a TCP kapcsolat számára, ami úgy ismert, mint Bandwith-delay product (BDP). Ez vonatkozik a nem visszaigazolt adatmennyiségre egy adott időszakban, amit a TCP-nek kezelnie kell annak érdekében, hogy az összeköttetést kitöltse. Az adatkapcsolati kapacitás és a visszatérési késleltetés (Roundtrip delay) szorzata.

BDP vagy Capacity (bits) = Bandtwith (bit/sec) x Roundtrip Time (seconds)

Ahogyan a képletből is látszik a késleltetés (RTT) hatással van az elméleti TCP sávszélességre. Ezen túlmenően a BDP – másik nevén az LFN (long fat network) vagy játékosan csak elefánt – az egyik fő problémája a TCP kapcsolatnak, mivel a protokoll csak akkor tudja elérni az optimális throughput értéket, amikor a küldő nagy mennyiségű adatot továbbít, mielőtt az elfogadásra kerülne. Ha a küldendő adatmennyiség nem éri el a maximumát, akkor a link kihasználtsága sem éri el a várt hatékonyságot.

A TCP throughput teszt fontossága

A TCP alkalmazás adatokat szállít megbízható módon és megfelelő sorrendben a végpontok között, miközben az overhead következtében megnő a késleltetés.

A részletek ismertetése nélkül bizonyos TCP protokoll paraméterek beállításával befolyásolható az eszköz átviteli kapacitása, ami hatékony hálózati kihasználtságot eredményez. Ezek a paraméterek:

  • ablakméret
  • szegmens mérete
  • újraküldési késleltetés

Továbbá a kétirányú késleltetés (RTT) és a keretvesztés a legfontosabb tényezői a TCP működésének.

Természetesen egyéb a TCP protokolltól független tényezők is hatással vannak az adatküldésre. Ilyenek például a TCP stack további rétegeinek implementációi, a számítógép (szerver/kliens) teljesítménye, ami az adott alkalmazást futtatja.

TCP teszt módszerek

A szolgáltatók tipikusan a 2. és 3. rétegbeli teszt eljárásokat alkalmazznak adatszolgáltatás vagy mobil felhordó hálózat telepítése és hibakeresés során, mint pl.: ITU-T Y.1564. EXFO ezt a szabványos mérési eljárást EtherSAM néven implementálta mérési megoldásaiban. Képes több típusú szolgáltatás együttes futtatására, mialatt ellenőrzi a hálózati eszközök konfigurációját. Továbbá ellenőrzi a kulcs SLA paramétereket és a szolgáltatás minőségét garantáló QoS beállítások alkalmasságát, melyek priorizálják a különböző adatforgalmakat. Ezen eljárással a valós környezetnek megfelelő állapotot lehet kialakítani, miközben lerövidül a telepítés és a hibakeresés időszükséglete.

Tökéletes eljárás hálózati teljesítmény értékelésére. A mérhető paraméterek, mint throughput, keretvesztés, késleltetés és jitter átfogó képet adnak a hálózat minőségéről, az SLA teljesüléséről. Ez az eljárás ideális megoldás szolgáltatások telepítésére, a hálózati konfiguráció helyességének ellenőrzésére, mielőtt a tervezett alkalmazások elérhetővé válnának a felhasználók számára. A legtöbb szolgáltató számára ez elegendő megoldás, mivel csak a szolgáltatás átadási pontig vállalnak felelősséget. Az Y.1564 egy általános képet ad a hálózati teljesítményről a TCP alapú alkalmazások tekintetében. Nem minősíti a szolgáltatást végfelhasználói szemszögből. Ehhez szükséges még a TCP throughput mérése is.

A felhasználók hajlamosak a számítógépek által futtatott alkalmazások vagy egyéb szoftveres megoldások segítségével generált TCP forgalom alapján meghatározni a TCP throughput értékét. az utóbbi megoldás viszont félrevezető, arra a következtetésre juthat a végfelhasználó, hogy a szolgáltatója által biztosított sávszélesség értéket soha nem közelíti meg a mért érték. Az operációs rendszerek között is van különbség. Vannak közöttük zárt TCP/IP stacket használók szabványos ablakozási technikával, melynek maximális értéke 65 535 byte. A szoftveres megoldások hatékonysága függ a számítógép teljesítményétől is. A gyengébb hardverrel rosszabb mérési eredményt kaphat, ami hibás képet festhet a hálózati teljesítményről.

RFC 6349

Az RFC 6349 egy praktikus ajánlás a végpontok közötti TCP throughput mérésére a menedzselt IP hálózatokban. A mérés eredménye a TCP folyamat stabil állapotában elérhető elméleti áteresztőképesség. Az ajánlás feltételezi, hogy az IP hálózat megfelelő TCP működéssel bír, az IP állomások és azokon futó alkalmazások hatékony működésre képesek a sávszélesség felső határáig. Ennek eredményeként a TCP throughput még nem értelmezhető a TCP kapcsolat tranziens fázisában, mint pl.: a Slow Start folyamat során.

A TCP throughput meghatározása három részterületre bontható a mérés során:

  • MTU meghatározása (Path MTU detection): Az adategység maximális méretének meghatározása az adott adatátviteli útvonalra. Ez fontos a fregmentáció elkerülése érdekében. A legegyszerűbb módja az ICMP lehet, de legtöbb esetben ennek használatát tiltják az intézményi tűzfalak. Éppen ezért az MTU pontos méretének meghatározásához alkalmazható az RFC 4821 ajánlásban leírt megoldás.
  • Valós körülfordulási idő (RTT – Real roundtrip time): A valós körülfordulási idő (kétirányú késleltetés) ismerete szükséges a TCP ablakméret meghatározásához, ami a TCP throughput teszt során kerül felhasználásra.
  • TCP throughput: Maga a teszt eljárás, ami a becsült ablakmérettel és MTU-val dolgozik.

Az RFC 6349 egy teoretikus megoldás, ami a következő szempontok figyelembevételével alkalmazható:

A tesztet el kell végezni különböző időintervallumokban, különböző időpontokban a nap folyamán a minél jobb TCP throughput érdekében, mivel az eljárás nem támogatja a hosszú idejű tesztelést (fájlátvitelt használ).

A TCP throughput mérés eredménye nem értelmezhető azokban a hálózatokban, ahol eleve magas a csomagvesztés (nagyobb, mint 5%), és/vagy a jitter (150ms).

JPerf

A JPerf egy olyan tesztalkalmazás, ami képes TCP és UDP adatfolyamok generálásával TCP throughput mérésre. Szerver-kliens modellre épül, ahol a szerver a generátor és a kliens a válaszadó. Képes mérni a throughput, késleltetés és átlagos időtartam értékét, de nem határozza meg az ablakméretet.

A JPerf egy szoftveres megoldás, C++-ban fejlesztették, az operációs rendszer TCP/IP stack megoldását használja, az arra jellemző ablakmérettel, aminek a maximális értéke 65 535 byte. Ez negatívan befolyásolja a TCP throughput értékének meghatározását. Továbbá a teszteljárás az OSI modell mind a 7 rétegét használja, így jelentős overhead-del kell számolni.

Egy hozzávetőleges TCP throughput érték meghatározásához használható, de nem egy méréstechnikai megoldás, ami pontos értéket képes szolgáltatni. Minden egyéb teszteljárás, ami a JPerf-en alapul, örökli a fentebb említett hátrányokat.

EXacTCP

A TCP Reno szerinti EXacTCP, ami az RFC 793/1122/1323/2581 ajánlásokon alapszik és használható TCP throuhput mérésre, mivel az RFC 6349 ajánlásra épül. Ez a TCP teszteljárás képes pontosan meghatározni a TCP paramétereket: TCP throughput, RTT és ablakméret, köszönhetően annak, hogy ez egy hardver alapú megoldás, amely nem az adott operációs rendszer, illetve számítógép képességeitől függ.

A TCP throughput mérése a TCP ablakméret skálázódásán (window scale ) alapszik az RFC 1323 szerint. Ennek a lényege, hogy egyetlen adatfolyammal képes meghatározni a TCP throughput, az RTT és az ablakméret értékét. Következésképpen, ez az egy adatfolyam kitölti a teljes rendelkezésre álló sávszélességet TCP forgalommal, szemben egy valós alkalmazással, ami talán erre a fent említett korlátok miatt nem képes.

A mérési eljárás alkalmazása sokkal könnyebb, mint a szoftver alapú megoldásoké, mivel nem kell különféle adatfolyamokat és TCP portokat beállítani. Az eredményesség szempontjából nézve a kérdést, a felhasználónak nem kell átlagolni több mérés eredményét azt vizsgálva, hogy pontosan mire képes az adott áramkör. Csak egy TCP adatfolyamra épül a mérés. Ha a hálózat minőségét leíró paraméterek (keretvesztés, körbefordulási idő, stb.) nem változnak, akkor a TCP throughput mérés eredménye is ugyanaz lesz.

Összefoglalás

Összefoglalva, a TCP protokollt használják elsősorban a nem valósidejű alkalmazások adatforgalmának lebonyolítására. Mivel a protokollt megbízható átvitelre tervezték, ezért hatással van a késleltetésre és a link kapacitásának kihasználására.

A felhasználók mindenféle méretben és formában futtatnak TCP alapú alkalmazásokat a hálózaton. Nagy kihívás a szolgáltatók számára, hogy a megfelelő környezetet biztosítsák ügyfeleik alkalmazásai számára.

Azok a teszt eljárások, amelyek a szolgáltatások bevezetésére és a hibaelhárításra lettek kifejlesztve (pl.: Y.1564), viszonylag nagy az időszükségletük és csak átfogó képet adnak a TCP alapú alkalmazások teljesítőképességéről.

Egyetlen módja az optimális TCP átvitel tesztelésének, ami kiküszöböli a TCP protokoll hiányosságait, nevezetesen az RFC 6349. Az EXacTCP az egyetlen szabványos TCP throughput mérési megoldás, ami pontos és all-inclusive eredményt ad egyetlen tesztben.

 

Ha hasznosnak találod az oldalt, oszd meg másokkal is