Dr. Wührl Tibor Ph.D. MsC 05 Ea Szállítási protokollok - Bevezetés
Szállítási protokollok szükségessége A 3. réteg feladat az volt, hogy az adatcsomagok a megfelelő hálózati végpontra eljussanak. A kapcsolás a csomagban található IP cím vagy címke (MPLS) alapján történt, a kapcsolást pedig a router eszközök végezték. Mit nem tud az IP? (nem is feladata!) Nem tudja, hogy egy adott gépen milyen alkalmazások futnak, és mely adatokat mely alkalmazásokhoz kell irányítani; Az IP kapcsolás a nem megbízható átviteli módszerek közé sorolt, előfordulhatnak: Csomag sorrend cserék; Csomag vesztések; Csomag többszöröződések. 2
Szállítási protokollok szükségessége A szállítási protokollok (4. réteg) feladatai: El kell különíteniük a különböző alkalmazások adatfolyamait; A csomag sorrend helyreállítása; Duplikált csomagok kiszűrése; Elveszett csomagok újrakérése/ újraküldése. 3
Szállítási protokollok szükségessége Az egy végpontra megérkező ömlesztett csomagok a portcímek alapján választhatók szét, hogy mely alkalmazás dolgozza fel azt. A port azonosítók 16 biten ábrázolt számok. A port címek hasonlíthatók egy telefonszám (mint az IP cím analógiája) mögött működő mellékek azonosítójához. A port címeket három csoportba (kategóriába) soroljuk: well-known portok, melyek fixen egy adott szolgáltatáshoz tartoznak; registered portok; dynamic/private portok. 4
UDP-User Datagram Protocol Az UDP-t elsősorban rövid üzenetek célba juttatására szolgáló protokoll (RFC 768), ott használjuk, ahol fontos szempont a gyorsaság. Az UDP nem garantálja a csomag megérkezését! 5
UDP-User Datagram Protocol Az UDP úgynevezett connectionless protokoll, így az ezzel küldött csomagok a hálózatban duplikálódhatnak, el is veszhetnek, és a csomag érkezési sorrend sem minden esetben egyezik a csomag küldési sorrenddel. Sok esetben a gyorsaság fontosabb annál, mint a csomagvesztés kiküszöbölése! Gondoljunk a real-time alkalmazásokra! 6
UDP-User Datagram Protocol UDP fejléc Source port address (2 byte) Destination port address (2 byte) Length (2 byte) Checksumm (2 byte) Data 7
UDP-User Datagram Protocol Az UDP szegmens IP csomagban utazik. Beazonosítása úgy történik, hogy az IP fejlécben a Protocol mező a 7-es azonosítót (UDP) szállítja. 8 A Source port address 16 bites és a küldő, forrásalkalmazás (source) portjának száma. A Destination port address 16 bites és a fogadó alkalmazás portjának sorszámát hordozza.
UDP-User Datagram Protocol A Length mező 16 bites. Az UDP csomag payloadjának hossza változó lehet, az aktuális hosszt itt kell megadni. A hossz indikátor magába foglalja a fejléc hosszát is! A legrövidebb UDP csomag hossza (amely payload-ot nem tartalmaz) 8 byte. 9 A Checksum mező 2 byte méretű, segítségével a csomag tartalmának megsérülése fedezhető fel. Használata opcionális. Abban az esetben, ha az ellenőrző összeg nem kerül kiszámításra, akkor ezt a mezőt 0-nak kell hagyni.
TCP Transmission Control Protocol A TCP feladata részben ugyan az, mint az UDP-jé, vagyis a különböző alkalmazások adatfolyamait el kell különítenie. Ezen felül az elveszett, megsérült, duplikálódott, nem helyes sorrendben érkezett csomagokat is érzékelnie kell és az ilyen problémákat is ki kell küszöbölje! A TCP-t az RFC793 ajánlás rögzíti. 10
TCP Transmission Control Protocol A felsorolt problémák elhárítása úgy lehetséges, hogy minden egyes kiküldött byte-ot számolunk (a TCP egy byte orientált protokoll), és a fogadó oldalnak pozitív nyugtázást kell adnia a beérkezett byte-ról. Az elveszett, vagy sérülés miatt elveszett csomagok újraküldése oldja meg a hibajavítást. A TCP kapcsolat orientált eljárás. 11
TCP Transmission Control Protocol TCP keret felépítése 8 bit 8 bit 8 bit 8 bit Data Offset (4) Source Port Destination Port Sequence Number Acknowledgement Number Fenntartott Control bitek Window bitek (6) ( 6 bit ) Checksum Options Data Urgent Pointer Padding 12
TCP Transmission Control Protocol A TCP keretet egy IP csomag szállítja (vagyis az IP datagram egy TCP csomag), és ekkor az IP fejléc Protocol mezőben 6 érték áll. A TCP keret Source Port elnevezésű mezője a forrás port sorszámát (16 bit) hordozza. A Destination Port mezőben a cél port sorszám (16 bit) található. A Port azonosító feladata a végponton működő küldő- és a fogadó alkalmazás azonosítása, ennek segítségével válik lehetővé az, hogy egy végponton egy időben több különböző alkalmazás is képes legyen adatokat küldeni és fogadni. 13
TCP Transmission Control Protocol 14 A Sequence Number mező 32 bites, mely ebben a csomagban elküldött első oktet sorszámát hordozza, kivéve, ha a SYN Control bit 1 ben áll, mert ekkor a Sequence Number egy kezdeti értéket (ISN Initial Sequence Number) jelöl. Ebben az esetben az első adat oktet sorszáma ISN+1. Az ISN generálása során a végpont egy 32 bites számlálót üzemeltet, amelyet minden 4µs-ban megnövel. Új ISN esetén a számláló aktuális értékét használják, így garantálható hogy közel öt óra időtartamon belül ne ismétlődjön meg egy korábbi érték.
TCP Transmission Control Protocol Az Acknowledgement Number mező 32 bites és feladata a fogadott adatok nyugtázása. Abban az esetben, ha ez a mező egy visszanyugtázott Sequence Number -t tartalmaz, akkor az ACK bit 1 értéken áll. 15
TCP Transmission Control Protocol A Data Offset 4 bites mező, mely a TCP Header végét mutatja (vagyis a TCP által hordozott adatmező elejét). Ez azért szükséges, mert a TCP Header hosszúsága az Option mező miatt változhat. A Data Offset biteket hat további, fejlesztésekhez fenntartott bit követi, melyek értéke 0. 16
TCP Transmission Control Protocol A Control biteket (6 bit) a következő elnevezésű bitek alkotják: URG - Urgent Pointer field significant ACK - Acknowledgment field significant PSH - Push Function RST - Reset the connection SYN - Synchronize sequence numbers FIN - No more data from sender 17
TCP Transmission Control Protocol A Window mező 16 bitből áll, segítségével jelezhetjük a fogadó eszköz rendelkezésére álló buffer méretét, vagyis itt adhatjuk meg a fogadni kész maximális adatmennyiség méretét. Jelentősége a csúszó ablakos (sliding window) nyugtázásnál van. A csúszó ablakos nyugtázás azt jelenti, hogy az adó oldalnak nem kell megvárnia azt, hogy az elküldött TCP csomagra megérkezzen a pozitív nyugta, mert ez nagyon lelassítaná a kommunikációt. E helyett az adó eszköz több csomagot küldhet el a célállomás felé (maximum annyit, amennyit a Window mező engedélyezett). 18
TCP Transmission Control Protocol 19 A Window folytatás Amint a nyugta megérkezik az egyik csomagra, az ablak továbbcsúszik és ismét további üzenetek elküldésére van lehetőség. Másik használati célja a torlódásvezérlés. Abban az esetben, ha a fogadó eszköz valamilyen okból nem tud éppen adatot fogadni (éppen kifogyott a szükséges erőforrásból), akkor egy 0 méretű Window mezővel ideiglenesen leállíthatja az adatok küldését, majd ha ismét képes adatokat fogadni, akkor egy újabb csomaggal ismét engedélyezheti a küldést.
TCP Transmission Control Protocol A Checksum mező 16 bites, mely értéke, a header és a text minden egyes 16 bites szavának egyes komplemenséből képzett összeg. Az Urgent Pointer mező kizárólag akkor értelmezett, ha az URG bit 1 - ben áll. Ezen a 16 biten adható meg egy eltolási érték, mely a datagramban szereplő sürgős adatokra mutat. Sürgős adat lehet például egy megszakítási üzenet. 20
TCP Transmission Control Protocol TCP kapcsolatfelvétel úgynevezett háromutas kézfogással ( Three-way handshake ) történik: 21
TCP Transmission Control Protocol A kapcsolat felvétel során a SYN bit 1 volt. A kapcsolat során a SYN bit a továbbiakban 0 értéken fog állni, hiszen az adatküldések során a Sequence Number mező az átküldött okteteknek megfelelően inkrementálódik. A kapcsolat bontás folyamata úgy indul, hogy a bontani kívánó állomás a TCP fejléc FIN bitjét 1 -be állítja. A másik fél ezt nyugtázza (ACK-val), azonban nem feltétlenül szükséges, hogy a másik fél is küldjön bontási kérelmet. 22
TCP Transmission Control Protocol TCP kapcsolat bontási példa (az A kezdeményezi a bontást): 23
TCP Transmission Control Protocol TCP állapotok és a köztük lévő átmenetek: 24
TCP Transmission Control Protocol CLOSED = Nincs nyitott, vagy függő kapcsolat; LISTEN = Bejövő kapcsolatra vár; SYN RCVD = Kapcsolatfelvételi kérés hatására a kapcsolatfelvétel indul; SYN SENT = Kapcsolatfelvétel kezdeményezés indult; ESTABLISHED = Kapcsolat állapot (Adatátviteli állapot); FIN WAIT1 = Az alkalmazás a kapcsolat bontását kezdeményezte; FIN WAIT2 = A másik fél egyetért a kapcsolat bontással; TIME WAIT = Várakozás a csomagok kihalására; CLOSING = Szimultán kapcsolatbontási kísérlet; CLOSE WAIT = Másik oldalról a kapcsolatbontást kezdeményezték; LAST ACK = Utolsó ACK-ra vár. 25
Valós idejű (real-time) adatok szállítása A csomagkapcsolt hálózatokat elsősorban adatok továbbítására találták ki, és fejlesztették. Az egyre nagyobb kapacitású és teljesítőképességű hálózat csábítóan hat, hogy multimédiás tartalmakat is küldjünk rajta, illetve töltsünk le magunknak. Amíg a multimédiás tartalom lejátszása nem valós időben történik, addig nincs is igazán nagy probléma, de ha valós idejű alkalmazásokról van szó, át kell értékelni a lehetőségeket! 26
Valós idejű (real-time) adatok szállítása Számba kell venni a következőket: Egy csomagokra bontott digitális jelfolyam vételéről van szó, ahol az egyes információ egységek a csomagkapcsolt hálózaton a továbbítás közben sérülhetnek, valamint különböző késleltetést szenvedhetnek el. Előfordulhat olyan helyzet is, hogy a változó késleltetések és természetesen a más útvonal miatt a vétel helyén a csomagok sorrendje felcserélődik. 27
Valós idejű (real-time) adatok szállítása A végfelhasználó multimédia QoS kategóriákat az ITU-T G.1010 ajánlás definiálja, mely a végfelhasználó (előfizető) szemszögéből nyolc különböző kategóriát különböztet meg. A kategória meghatározása az információ felhasználási helyén előálló adatvesztés és az erre vonatkozó tolerancia, valamint a késleltetési idő alapján történik. 28
Valós idejű (real-time) adatok szállítása Néhány fogalom: Késleltetés (Delay) Késleltetés változás (Delay variation / Jitter) Információvesztés (Information loss) A késleltetés fogalom alatt definíciószerűen azt az időt értjük, mely a szolgáltatás igénybevétele során a felhasználói kéréstől a kért információ vételéig telik el. 29
Valós idejű (real-time) adatok szállítása A csomagokra bontott adat esetében a késleltetés változása kiemelt fontosságú jellemző (transzport réteg vonatkozásában). A fogalom alatt az egyes csomagok késleltetés (megérkezési idejének) változását értjük. Olyan szolgáltatások esetén, melyek a késleltetés tekintetében magas toleranciával rendelkeznek, vagyis nagy késleltetést képesek elviselni, a késleltetés változás alkalmasan megválasztott puffereléssel kiküszöbölhető. A pufferelés természetesen a konstans késleltetést növeli meg, ami a pufferelés mértékétől függ. 30
Valós idejű (real-time) adatok szállítása Az információvesztés közvetlen hatással van a végfelhasználónál megjelenő információra, ami lehet hang, kép, videó vagy adat. Vesztett információnak számít a valós idejű alkalmazások esetén a cél végponthoz későn megérkezett csomag is! 31
Valós idejű (real-time) adatok szállítása Minőségi jellemzők határértékeinek szemléltetése ITU G.1010 ajánlás szerint: 32
Valós idejű (real-time) adatok szállítása ITU G.1020 hatóköre: 33
Valós idejű (real-time) adatok szállítása Késleltetési idő komponensek: 34
Valós idejű (real-time) adatok szállítása Csomagvesztések: Eldobásra kerül minden olyan csomag, mely UDP ellenőrző összeg hibát jelez (ha nem nulla a CRC mező). Eldobásra kerül minden olyan csomag, mely késleltetése nagyobb, mint a hálózat minimum késleltetése plusz a fix hosszúságú de-jittering buffer tároló képessége. Továbbítás során a hálózatban elveszett csomagok. 35
RTP Real-time Transport Protocol Az RTP és RTCP protokoll páros az OSI szállítási (Transport) rétegében kapott helyet. Az RTP-t az RFC 1889, míg az RTCP-t az RFC 3550 definiálja. Az RTP valós idejű adatok átvitelére alkotott eljárás, akár TCP, akár UDP szegmensben is utazhat. Támogatja az IP-multicast (többesadás) megoldásokat is. 36
RTP Real-time Transport Protocol RTP csomag: M V P X CC PT SQ (2 byte) TStamp (4 byte) SSRC (4 byte) CSRC list (4 byte) Hasznos adat illetve helykitöltő (Padding) 37
RTP Real-time Transport Protocol A V mező 2 bit hosszúságú ( Version ), a protokoll verziószám jelölésére szolgál, jelenleg az RTP 2-es verzió használatos. A P egybites ( Padding ). Ez a bit jelzi, hogy a csomag payload helytöltő padding byteokat is tartalmaz. Az X mező szintén egy bitből áll, jelentése Extension. Ez a bit lehetőséget biztosít az RTP fejléc opcionális kibővítésére. 38
RTP Real-time Transport Protocol A CC mező 4 bites (CSRC Count). Az RTP csomagban előforduló CSRC azonosítók számát adja meg. A CSRC azonosítók az RTP fejlécben, annak CSRC mezőjében (32 bit) találhatóak. Az M egybites ( Marker ). Ennek a bitnek az aktuális jelentése a profiltól függ. Használható a felsőbb rétegek határvonalainak megjelölésére, vagy extra payload megjelölésre. Számos alkalmazásban ez a bit nem használatos. 39
RTP Real-time Transport Protocol A PT (Payload Type) mező, mely 7 bitből áll a payload típus és a média típus azonosítására szolgál. Az SQ 16 bites mező (SeQuence number). Ez a sorszám minden egyes keret küldése során inkrementálódik (modulo 65536 módszerrel). A vevő ezen szám alapján képes felderíteni az esetleges csomagvesztést. Az adás megkezdésekor ez a szám egy véletlen szám. 40
RTP Real-time Transport Protocol 41 A TStamp (Timestamp) 32 bitből áll. Ez a szám reprezentálja az RTP csomag payload első byte-hoz tartozó mintavételi pillanatot. Erre az értékre alapozottan képes a vevő a vett adatokból (burst jellegű) helyreállítani a mintavételi ütemezésnek megfelelő folyamatos digitális jelfolyamot. Az egyes alkalmazások esetén a mintavételi frekvencia egymástól eltérő, melynek azonosítása a payload formátum specifikációban szerepel.
RTP Real-time Transport Protocol Az SSRC (Syncronization Source) mező 32 bites. Tartalma egy véletlen számként generált azonosító, melynek feladata az RTP adatfolyam eredetének azonosítása. Az CSRC (Contributing Source list) mező szintén 32 bitből áll. A listában maximum 15 azonosító szerepelhet. Azt, hogy ebben a listában ténylegesen hány azonosító található, a CC mező száma adja meg. 42
RTCP (Real TimeControl Protocol) Az RTCP az RTP komplemens protokollja (RFC 3550). Elsődleges feladata, hogy visszacsatolást adjon a küldő félnek az átvitel minőségéről. Ezzel a funkcióval lehetőség nyílik az átvitel- és torlódásvezérlésre, melyeket más transzport rétegbeli protokollok hajtanak végre. 43
Köszönöm a Megtisztelő figyelmet! Dr. Wührl Tibor Ph.D. wuhrl.tibor@kvk.uni-obuda.hu 44