Tartalom. Szállítási réteg

Átírás

1 1

2 Tartalom Szállítási réteg o Bevezető o Szállítási szolgálati primitívek o Címzés o Nyalábolás o TCP modell o TCP fejrész o TCP összeköttetés létesítés o TCP összeköttetés lebontás o TCP ablakkezelés 2

3 Tartalom Szállítási réteg o TCP torlódáskezelés o TCP időzítéskezelés o UDP o UDP fejrész o UDP szolgáltatás 3

4 Szállítási réteg 4

5 Bevezető A szállítási réteg célja az, hogy hatékony, megbízható és gazdaságos szolgálatot nyújtson felhasználóinak, az alkalmazási rétegben futó folyamatoknak Szállítási entitás (transport entity): hardver és/vagy szoftver elem, amely a munkát végzi. Mi a fő különbség a hálózati és a szállítási réteg között? A szállítási réteg kódja teljes egészében a felhasználók gépein fut, szemben a hálózati réteggel, ami nagyrészt a routereken, a routereket pedig a szolgáltató üzemelteti. Az alkalmazások programozói egy szabványos primitívkészletre írhatják a kódot, és az így megírt programok a hálózatok széles skáláján működnek. 5

6 Bevezető 6

7 Szállítási szolgálati primitívek Sok alkalmazás (ezzel együtt programozó) használja a szállítási primitíveket, ezért a szállítási szolgálatnak kényelmesnek és könnyen használhatónak kell lennie Minden szállítási szolgálat egyedi interfésszel rendelkezik amelyen a felhasználók hozzáférnek a szolgálathoz. Primitívek pl: listen, connect, send, receive TPDU (Transport Protocol Data Unit - szállítási protokoll adategység) 7

8 Címzés Amikor egy alkalmazási folyamat (vagyis egy felhasználó) egy távoli alkalmazási folyamattal akar összeköttetést létrehozni, meg kell jelölnie, hogy melyik folyamattal akar kapcsolatba lépni. Kinek kell elküldeni az egyes üzeneteket? Külön szállítási címeket definiálunk az egyes folyamatok részére, amelyeken várhatják az összeköttetési kéréseket: portok (általános elnevezésük: TSAP Transport Service Access Point, a hálózati rétegben pedig: NSAP, az interneten ez az IP cím) 8

9 Címzés Szállítási összeköttetés 9

10 Címzés Honnan tudja az 1. hoszt alkalmazási folyamata hogy pl.a pontosidőszerver az 1522 TSAP-hez csatlakozik? Az időszerver már évek óta az 1522-es NSAP-hez csatlakozik, és ezt a hálózat minden felhasználója megtanulta stabil TSAP Ahelyett, hogy az összes lehetséges szerver egy jólismert TSAP-t figyelne, minden olyan gépnek van egy különleges folyamatszervere (process server), amely szolgálatokat akar felkínálni a távoli felhasználóknak. A folyamatszerver a kevésbé sűrűn használt szerverek megbízottjaként működik. Olyan esetekben amikor a szolgáltatások a folyamatszolgáltatótól függetlenül léteznek (például egy állómányszolgáltató hardveren), hogy a felhasználó egy adott szolgáltatás nevéhez tartozó TSAP-címet megtudja, összeköttetést létesít a névszolgáltatóval (ami a jól ismert TSAP-címén várakozik). A felhasználó üzenetet küld a kért szolgáltatás nevével, mire a névszolgáltató visszaküldi annak TSAP-címét. A felhasználó ezután megszünteti az összeköttetést a névszolgáltatóval, és újat létesít a kívánt szolgáltatással. 10

11 Nyalábolás Ha például egy hoszton csak egyetlen hálózati cím áll rendelkezésre, akkor azon a gépen minden szállítási összeköttetésnek azt kell használnia. A beérkező TPDU-kat melyik folyamatnak kell továbbítani? feltöltési multiplexelés (upward multiplexing) 11

12 TCP modell A helyi folyamatoktól kapott felhasználói adatfolyamokat a TCP-entitás 64 KB-ot meg nem haladó méretű darabokra szedi szét a gyakorlatban sokszor 1460 adatbájtos darabokra, mert így az IP- és TCP-fejrészekkel együtt is beleférnek egy Ethernet-keretbe. Az egyes darabokat önálló IP-datagramokban küldi el Az 1024 alatti portokat jól ismert portoknak (well-known port) hívják, és a megszokott szolgáltatások részére vannak fenntartva. Az egyes hosztok a definiált jól ismert portok kivételével bárhogyan kioszthatják a portjaikat. 12

13 TCP modell A TCP-összeköttetésen nem üzenetfolyamok, hanem bájtfolyamok áramlanak Amikor egy alkalmazás adatot ad át a TCP-nek, a TCP dönti el, hogy azonnal elküldi azt vagy puffereli egy ideig, hogy így nagyobb adatmennyiséget küldhessen el egyszerre. Összegyűjtheti több írási utasítás adatait egyetlen szegmensbe, de egy írás adatait is eloszthatja több szegmensbe Urgent data (sürgős adat) jelzéssel kapott adatot a TCP azonnal továbbítja. A TCP-entitások egy csúszóablakos protokoll-változatot használnak: nyugta: a vevő TCP-entitás visszaküld egy olyan szegmenst (adatokkal tele, ha van elküldendő adat, egyébként üresen), amelyben a következőnek várt szegmens sorszámával visszaigazolja az adást. ha a küldő oldalon az időzítő a nyugta vétele előtt lejár, akkor a küldő újra elküldi a szegmenst 13

14 TCP fejrész 14

15 TCP összeköttetés létesítés Az egyik fél (szerver) passzívan várakozik a bejövő kérésekre a LISTEN és ACCEPT primitívek végrehajtásával. A másik oldal, melyet kliensnek hívunk, végrehajtja a CONNECT primitívet A CONNECT primitív elküld egy TCP-szegmenst SYN =1 és ACK=0 értékkel, majd választ vár Amikor a szegmens megérkezik a rendeltetési helyre, az ottani TCP-entitás ellenőrzi, hogy létezik-e egy folyamat, amely a célport mezőben meghatározott porton végrehajtotta a LISTEN primitívet. Ha nem, RST=1 válasszal elutasítja az összeköttetés-kérést. Ha valamilyen folyamat figyeli a megadott portot, akkor az megkapja a beérkező TCP-szegmenst, és rajta múlik, hogy elfogadja-e vagy visszautasítja az összeköttetést. Ha elfogadja, egy nyugtázó szegmenst küld vissza. 15

16 TCP összeköttetés létesítés 16

17 TCP összeköttetés lebontás Egy összeköttetés bontásához bármelyik fél küldhet egy FIN =1 értékű TCPszegmenst, amivel jelzi, hogy nem szándékozik több adatot küldeni. Amint a FIN nyugtája megérkezik, az az irány lezárul. A másik irányban azonban ettől függetlenül korlátlanul folyhat adatátvitel. Amikor mindkét irányt lezárták, az összeköttetés befejeződött. Az első ACK és a második FIN elhelyezhető ugyanabban a szegmensben is, így összesen csak háromra van szükség. Ha egy FIN-re nem érkezik válasz két csomag-élettartamnyi idő alatt, a FIN küldője bontja az összeköttetést. A másik fél végül észreveszi, hogy már senki sem figyel rá, az általa indított időzítő is lejár. 17

18 TCP összeköttetés lebontás 18

19 TCP ablakkezelés Az ablakkezelés nem kötődik olyan szorosan a nyugtázáshoz, mint a legtöbb adatkapcsolati protokollban. Példa: 19

20 TCP ablakkezelés Amikor az ablakméret 0 bájt, a küldő normális esetben nem küldhet szegmenst, azonban van két kivétel. a sürgős adatot továbbíthatja a küldő elküldhet egy egybájtos szegmenst, melyben arra kéri a vevőt, hogy közölje vele a következő várt bájt sorszámát és az ablakméretet holtpont elkerülése végett, ha véletlen ablakméretközlő szegmens elveszett A küldő nem köteles azonnal továbbítani az alkalmazástól kapott adatot. A vevő sem köteles azonnal nyugtázni a beérkezett szegmenseket. Amikor sok kicsi adat küldése történik, és mind külön szegmensben van, akkor nagy a pazarlás. Erre megoldás Nagle algoritmus: amikor a küldőhöz bájtonként érkezik az adat, csak az elsőt továbbítja, a többit addig puffereli, amíg az elküldött bájt nyugtája meg nem érkezik. Valós idejű alkalmazásoknál nem jó. 20

21 TCP torlódáskezelés Addig nem indít egy új csomagot a hálózatban, amíg egy régi el nem hagyja azt (tehát célba ér). A TCP az ablakméret dinamikus változtatásával próbálja ez a célt elérni. Az összes TCP-algoritmus feltételezi, hogy időtúllépés torlódás miatt következik be ezért azt figyeli, hogy észlelje a torlódást. Az Internet megoldása: két potenciális probléma létezik - a hálózat kapacitása és a vevő kapacitása -, melyeket külön kell kezelni. Ennek érdekében minden adó két ablakot használ: az egyik ablakot a vevő szabályozza, a másik pedig a torlódási ablak (congestion window). A ténylegesen továbbítható bájtok száma a két ablak értékének minimuma. A torlódási ablakot először a legnagyobb szegmens méretre állítja a küldő, majd próbálja növelni (exponenciálisan) lassú kezdés (slow start) 21

22 TCP torlódáskezelés 22

23 TCP időzítéskezelés Ismétlési időzítő (retransmission timer) Milyen hosszú ideig fusson az időzítő? A szállítási rétegben nehéz a körülfordulási időt kiszámítani. Adatkapcsolati réteg (layer 2) Szállítási réteg (layer 4) 23

24 TCP időzítéskezelés Ismétlési időzítő (retransmission timer) Megoldás: dinamikus algoritmus, amely a teljesítőképesség mérése alapján állandóan változtatja az időintervallumot. RTT Round Trip Time. Egy szegmens mért körülfordulási ideje: RTT RTT i = α RTTi-1 + (1-α) rtti RTO Retransmission Timeout Jacobson algoritmus: RTOi = RTTi MDEVi-1 24

25 TCP időzítéskezelés Folytatódó időzítő (persistence timer) holtpont elkerülése végett, ha esetleg elveszik az ablakfrissítés Életben tartó időzítő (keepalive timer) Amikor egy összeköttetés már régóta tétlen, az életben tartó időzítő lejár, és ennek hatására a TCP ellenőrzi, hogy partnere még mindig működik-e. Ha a távoli entitás nem válaszol, az összeköttetés befejeződik. Time-Wait (2MSL maximum segment lifetime) a másik féllel való összeköttetés bontás után indítja az összeköttetés csak lejárta után bontódik, és ezután lehet a portot újrahasználni így biztos minden csomag vagy megérkezett vagy elutasították (nem lapol át a másik összeköttetésbe) 25

26 UDP User Datagram Protocol - felhasználói datagram protokoll összeköttetés nélküli protokoll A folyamatok a BIND vagy más hasonló primitív használatával kapcsolódhatnak rá egy portra Amikor egy UDP-szegmens megérkezik, akkor az adatmezejét a szállítási entitás kézbesíti a címzett portra kapcsolódó folyamatnak. Az UDP használatának tulajdonképpen az a legnagyobb előnye a nyers IP használatával szemben, hogy a fejrészben megtalálható a feladó és a címzett portszáma is. 26

27 UDP fejrész 27

28 UDP szolgáltatás Amit nem csinál: forgalomszabályozás hibakezelés újraküldés rossz szegmens vétele esetén Amire képes: biztosít egy interfészt az IP-protokoll használatához egyszerre több folyamatot képes demultiplexelni A kliens rövid kérdései és a szerver rövid válaszai (pl. DNS Domain Name System - körzeti névkezelő rendszer) olyan terület ahol az UDP hasznos. 28