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: • • •
2
Csomag sorrend cserék; Csomag vesztések; Csomag többszöröződések.
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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. 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. 8
IPTV alapok
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. 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. 9
IPTV alapok
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
IPTV alapok
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
IPTV alapok
TCP – Transmission Control Protocol TCP keret felépítése 8 bit
8 bit
8 bit
8 bit
Source Port
Destination Port Sequence Number
Acknowledgement Number Data
Fenntartott
Control bitek
Offset
bitek (6)
( 6 bit )
Window
(4) Checksum
Urgent Pointer
Options
Padding Data
12
IPTV alapok
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
IPTV alapok
TCP – Transmission Control Protocol 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. 14
IPTV alapok
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
IPTV alapok
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
IPTV alapok
TCP – Transmission Control Protocol A „Control” biteket (6 bit) a következő elnevezésű bitek alkotják: • • • • • •
17
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
IPTV alapok
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
IPTV alapok
TCP – Transmission Control Protocol 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. 19
IPTV alapok
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
IPTV alapok
TCP – Transmission Control Protocol TCP kapcsolatfelvétel úgynevezett háromutas kézfogással („Three-way handshake”) történik:
21
IPTV alapok
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
IPTV alapok
TCP – Transmission Control Protocol TCP kapcsolat bontási példa (az ‚A’ kezdeményezi a bontást):
23
IPTV alapok
TCP – Transmission Control Protocol TCP állapotok és a köztük lévő átmenetek:
24
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
Valós idejű (real-time) adatok szállítása ITU G.1020 hatóköre:
33
IPTV alapok
Valós idejű (real-time) adatok szállítása
Késleltetési idő komponensek:
34
IPTV alapok
Valós idejű (real-time) adatok szállítása
Csomagvesztések:
35
•
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. IPTV alapok
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
IPTV alapok
RTP – Real-time Transport Protocol RTP csomag: V M
P
X
CC PT
SQ (2 byte) TStamp (4 byte) SSRC (4 byte) CSRC list (4 byte) Hasznos adat illetve helykitöltő (Padding)
37
IPTV alapok
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
IPTV alapok
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
IPTV alapok
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
IPTV alapok
RTP – Real-time Transport Protocol 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. 41
IPTV alapok
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
IPTV alapok
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
IPTV alapok
Köszönöm a Megtisztelő figyelmet! Dr. Wührl Tibor Ph.D.
[email protected]
44
IPTV alapok
