6. Szállítási réteg A szállítási réteg az OSI modell legbonyolultabb rétege. Fő célja, hogy megbízható, gazdaságos szolgálatot nyújtson a felette lévő rétegeknek. A szállítási réteg transzparens a felső rétegek számára. A szállítási réteg tipikus feladatai: forgalom szabályozás multiplexelés virtuális áramkörök felügyelete hibajavítás csomagképzés és csomagok visszaállítása a felsőbb rétegek számára. A forgalom szabályozás feladata, hogy az adó ne adjon több adatot, mint amit a vevő fogadni tud. A multiplexelés lehetővé teszi, hogy több alkalmazás használja ugyanazt a fizikai összeköttetést. Az összeköttetések nyalábolása pedig lehetővé teszi, hogy egy alkalmazás használjon több összeköttetést egy időben. (Pl.: ISDN két B csatornáját egy nagyobb sebességű kapcsolattá egyesítjük.) Változatos módszerek (ellenőrző összeg, CRC, újra adás) biztosítják, hogy a szállítási réteg ki tudja javítani az észlelt hibákat. A tényleges szolgáltatást végző elemeket szállítási funkcionális elemnek, vagy szállítási entitásnak nevezzük.ezek az elemek lehetnek az operációs rendszer magjának a részei, vagy önálló folyamatok. A szállítási rétegnek az ad további jelentőséget, ez a határ a szolgáltató (transport service provider), és a felhasználó (transport service user) között. Az alsó három réteg valamilyen módon egy szolgáltatóhoz kapcsolódik, és döntően hardver elemekben realizálódik. A felső rétegek a felhasználó kezében vannak, és alapvetően szoftver jellegűek. Az alsó négy réteget szokás együttesen adattovábbítónak, a felső hármat alkalmazásnak hívni. A szolgáltató által biztosított szolgálat nem mindig kielégítő minőségű. Ha az alsóbb rétegek nem nyújtanak kielégítő szolgálatot, akkor a szállítási rétegnek kell gondoskodni arról, hogy az általa nyújtott szolgálat minősége jobb legyen, mint amit az alatta lévő rétegek biztosítanak. 165
Ez a réteg határ abban az értelemben is, hogy elfedi az alhálózat tulajdonságait a felső rétegek elől. A viszonyréteg már nem tudhat arról, hogy alatta egy összeköttetés alapú, vagy összeköttetés mentes szolgálat működik. Ezt a szállítási réteg elfedi. 6.1. A szolgálat minősége ( Quality of Service ) A szolgálatok minőségét az OSI 3 csoportba sorolja: kívánt elfogadható elfogadhatatlan A minőségi kategóriák nem abszolút érvényűek. Az értékeket a felhasználóval kötött szerződéssel kell összevetni, és ennek alapján kell kategorizálni (ISO 8072). A minőséget az alábbi főbb paraméterek alapján határozzuk meg: Az összeköttetés létesítési késleltetés a kéréstől a megerősítésig eltelt idő. ( Nem a vonalak fizikai késleltetése! ) Az áteresztőképesség az időegység alatt átvitt felhasználói bájtok száma. ( Az oda és vissza irány különböző lehet, ezért mindkettőt meg kell adni. ) Az átviteli késleltetés a rendszer késleltetése a forrástól a célig. ( Oda/vissza különböző lehet,.) A megmaradó hibaarány a javítások és ellenőrzések ellenére megmaradó hibák aránya az összes átvitt bájthoz képest. A tartomány elég széles a gyakorlatban ( 10-3 - 10-14 -ig szinte bármi előfordulhat, a technológiától függően). A szállítási hiba valószínűsége azt adja meg, hogy időarányosan, vagy alkalomszámhoz viszonyítva mekkora a valószínűsége paraméterek szerződéses értéktartományból való kiesésének. Az összeköttetés lebontási késleltetés az az idő, ami az utolsó adat átvétele és az adatátviteli út bontása között eltelik. A felhasználó szempontjából azért jelentős, mert a legtöbb esetben a lebontásig számlázza az időt a szolgáltató. A védelem a szállítási réteg védelmének hatékonyságát jellemzi jelenti 3 fél behatolása ellen. 166
A prioritás a fontosabb összeköttetések kijelölésének lehetőségét biztosítja. A rugalmasság (resilence) annak a valószínűségét mutatja, hogy a hálózati réteg belső hibájából szakad meg az összeköttetés. Az opció egyeztetés folyamata az összeköttetés paramétereinek beállítására szolgál. A szállítási réteg a beállítani kívánt paraméterek egy részéről rögtön el tudja dönteni, hogy tudja-e teljesíteni ( a saját oldalon ), míg az ellenállomással egyeztetni kell. Általában a kérés tartalmaz egy kért és egy minimálisan elvárt értéket. Ha az ellenállomás a minimumot sem tudja tejesíteni, akkor az összeköttetést elutasítjuk. (Várunk 9600-64 bit/sec átviteli sebességet, de az ellenállomás csak 2400 bit/sec -t ajánl fel, akkor nem hozzuk létre az összeköttetést.) 6.2 Szállítási protkollok A szállítási protokoll feladatai: sorszámozás forgalomszabályozás hibakezelés Lényegében hasonlóak az adatkapcsolati rétegben megvalósított funkciókhoz. A különbség a működési környezetben van. Jóval bonyolultabb egy összeköttetés létrehozása és lebontása. A legnagyobb különbség az, hogy a szállítási rétegnek kezelni kell az alhálózat adattároló képességét. Az alhálózatban számos csomag lehet úton egyidőben. A datagram típusú átvitelnél a csomagok elveszhetnek kettőződhetnek hibásak lehetnek a hálózat végrehajthat egy spontán "Reset"-t (N-reset), ami a sorszámok elveszésével járhat. Könnyen beláthatjuk, hogy a szállítási protokollok bonyolultságát nagyban befolyásolja, hogy alatta mennyire megbízható szolgálat van. Ha az alhálózat hibátlan csomagokat sorrendhelyesen kézbesít, a rétegnek kevés feladata marad. 167
A szolgálatokat 3 osztályba sorolja az OSI : A Hibamentes szolgálat, N-reset nincs. (A jó minőségű LAN-ok megközelítik ezt az állapotot.) B Tökéletes csomagkézbesítés, N-reset előfordulhat C Megbízhatatlan szolgálat. (Elveszett, kettőzött csomagok, N-reset előfordul. ) Hálózataink nagy része ezt a szolgálatot nyújtja. A szolgálatokhoz különböző bonyolultságú protokollok tartoznak. A protokoll bonyolultsága a magasabb számok felé nő. 6.3. Összeköttetések címzése Amikor egy alkalmazási folyamat kapcsolatot akar létesíteni egy másik hoszton lévő párjával, akkor azt meg kell címezni. Ez a cím általánosan a TSAP cím. (A TCP/IP hálózatokban ez egy IP cím - port cím páros.) A feladata egyszerűnek tűnik, hiszen minden folyamatnak adhatunk egy címet, és a kérdés látszólag megoldott. A valóságban egy szerveren nagyon sok folyamat futhat. Ezek egy része szinte mindig fut, másik része ritkán. Ha egy folyamatot el akarunk érni, akkor a folyamatot el kell indítani, és a hozzá tartozó port-címet folyamatosan figyelnünk kell a szolgáltató gépen. Ritkán kért folyamatok esetén ez elfogadhatatlan erőforrás pazarlás. A másik probléma abból adódik, hogy nem ismerhetünk előre minden folyamatot, nem adhatunk neki címet, és így új szolgáltatást nem tudnánk beilleszteni. Nincs szükség az összes szolgáltatás előzetes definiálására, ha van egy olyan szolgáltatás, ami a létező többi szolgáltatás címét fogja visszaadni. Célszerűnek látszik egy olyan megoldás, ahol a címek egy része fix, a másik részét a hoszt szabadon definiálhatja. A folyamatokból is csak azokat indítjuk, melyekre szükség van. A portokból is csak néhányat figyel folyamatosan a hoszt. A kérést indító hoszt egy kezdeti összeköttetést létesítő protokollt használva fordul a szolgáltató géphez. A szolgáltató gépen (szerveren) egy folyamatszolgáltató (process server) fut, és a többi folyamat ügynökeként működik. Ha a felhasználó ehhez a folyamathoz fordul, akkor a process server elindítja a kért folyamatot, és visszaadja a TSAP címet, amin a szolgáltatás elérhető. Ez a módszer jól működik azoknál a folyamatoknál, melyeknek nem kell jelentős idő a létrehozásához. Vannak azonban folyamatok, melyeknek az indítása hosszabb időt igényel. (Egy állomány kiszolgálót nem lehet "röptében" elindítani.) Ezeket a 168
folyamatokat futtatjuk, de nem figyeljük a szolgáltatás portcímét. A futó folyamat címét adja vissza a katalógusszolgáltató (directory server). A directory server a szolgáltatás az ASCII fűzérként megadott nevéhez adja vissza a TSAP címet. A portok címkiosztását az IANA szervezet felügyeli. A port számok három csoportra oszlanak: közismert portok (Well Known Ports) 0-1023 regisztrált portok (Registrared Ports) 1024-49151 dinamikus/privát portok 49152-65535 A lista elérhető a http://www.iana.org/assignments/port-numbers címen. Eddig csak azzal foglalkoztunk, hogy egy szerveren belül hogyan érünk el egy szolgáltatást, de elkerültük azt a kérdést, hogy a szolgáltatás melyik szerveren elérhető, illetve melyik szervert akarjuk használni, ha több szerver is elérhető. Annak megtalálását, hogy a szolgáltatás melyik szerveren fut, a cím hierarchikus szerkezete biztosítja. A leggyakrabban használt TCP/IP hálózatokban az IP cím a hosztot, a TCP cím (port cím) a szolgáltatást azonosítja. Ez együttesen egy hierarchikus TSAP cím, ami megfelel az elvárásainknak. 6.4. Összeköttetés létesítése Az összeköttetés létesítése egyszerűnek látszó feladat. A valóságban az bonyolítja a helyzetet, hogy a hálózaton bolyongó csomagok miatt egy összeköttetés kérés többször is beérkezhet. A már lebontott összeköttetés után beérkező kérést a rendszer új összeköttetés kezdeményezésnek tekint. A már elvégzett feladathoz tartozó kéréseket azonban el kell utasítani, mert nem szeretnénk ugyanazt a tranzakciót kétszer, vagy többször elvégezni (kétszer átutalni ugyanazt a tételt a bankszámlánkról). A megoldás két gondolatra alapozható: Vezessük be az összeköttetések számozását. Ha a kezdeményező oldal sorszámozza az összeköttetéseket, akkor a később felbukkanó csomagban lévő sorszám alapján a kérés elutasítható. Korlátozzuk a csomag élettartamát, és azt a területet, amit bejárhat. Elláthatjuk a csomagot időbélyeggel, ami lehetővé teszi egy meghatározott élettartam után megsemmisítését. A csomagok így nem maradnak végtelen ideig a hálózatban. Egy korlátozott élettartam után biztosan nem 169
bukkanhatnak elő a hálózatból. Számolhatjuk a csomóponti átlépéseket, és meghatározott átlépés szám után megsemmisítjük a csomagot. A nyugtát azonos módon kezeljük, mint az egyéb csomagokat. Az összeköttetés létesítésének gyakorlati megoldása a "3-utas kézfogás". A kapcsolatfelvétel kezdetén elindítunk egy "Connection Reqvest " csomagot "x" sorszámmal. Az ellenállomás visszaküld (ha akar velünk társalogni) egy "Connection Confirm" csomagot "y" sorszámmal, és egy nyugtát 'x" sorszámmal. A kezdeményező így azonosíthatja a folyamatot, hogy ez valóban az "x" sorszámú kérésre érkezett válasz. Hoszt1 Connection Request sorszám:x Connection Confirm sorszám=y,nyugta=x DATA sorszám=x,nyugta=y xés y összeköttetés sorszámok Hoszt2 Connection Request sorszám:x Connection Confirm sorszám=y,nyugta=x 6.1.ábra. Összeköttetés létrehozása. Ezek után elkezdheti küldeni az adatokat, ahol minden csomag tartalmazza mind az "x", mind az "y" sorszámot. Így az ellenállomás is ellenőrizheti, hogy minden csomag tartalmazza-e az ő általa adott "y"-t. A sorszámok kiadásánál az állomások biztosak abban, hogy sem "x", sem "y" sorszámú csomag nincs már a hálózatban. A leírt módszer általában megfelelően működik. Problémát jelenthet, ha valamelyik állomást újra kell indítani, mert akkor elveszíthetjük a korábbi sorszámainkat, és esetleg a hálózaton még bolyongó csomaggal azonos sorszámút fognak kiadni. Problémát jelenthet a nyugtázó csomagok kettőződése, elveszése. A nyugtázó csomagokat ugyanúgy el kell távolítanunk az alhálózatból, mint az adatcsomagokat. A nyugtázó csomag esetleges elvesztése az összeköttetés lebontásakor jelentkezik súlyos nehézségként. A jelenség 2 hadsereg problémaként ismert az irodalomban. 170
KÉKEK A KÉKEK B PIROSAK 6.2.ábra. Két hadsereg probléma. Egy völgy két oldalán van a kék hadsereg két része, a völgyben a pirosak. A kék hadsereg bármelyik része támad, elveszti a csatát, ha ugyanakkor nem támad a másik oldal is. Az "A" jelű kék hadsereg üzenetet küld a "B" jelű oldalnak, hogy reggel 9-kor támadnak. Ekkor "A" nem tudja, hogy az üzenetet "B" megkapta vagy sem, tehát nem támadhat. "B" miután megkapta az üzenetet, nyugtázza, és visszaküld egy futárt "A"-hoz. Ha a futár megérkezett, "A" tudja, hogy az üzenete megérkezett. "B" azonban nem tudja, hogy a visszaigazolása megérkezett-e "A"-hoz, így nem támadhat biztonságosan. Ez a játék a végtelenségig folytatható. Az utolsó üzenet megérkezését soha nem tudjuk ellenőrizni. A "támadás" analóg kapcsolat bontással. "A" oldal elküld egy üzenetet, hogy nincs több adásra kész adata, bontható az összeköttetés. "B" erre vagy azt mondja, hogy neki sincs, bontható az összeköttetés, vagy kéri az összeköttetés fenntartását. Ha ez az üzenet elveszik, "A" nem tudja, hogy bonthat vagy sem. "B" szintén nem tudja, hogy a bontást engedélyező üzenete megérkezett-e, mert ha nem kap választ, akkor vagy üzenet, vagy annak nyugtája veszett el. Látható, hogy alapvetően két eset van. Ha "A" és "B" is visszakapta a bontási üzenet nyugtáját, akkor lebontják a kapcsolatot. A másik eset az, hogy ellenállomás egy ideje egyáltalán nem válaszol, vagy a nyugtát nem kapjuk vissza. A kapcsolatot valahogy mégis bontanunk kell. Ezért a bontást kezdeményező egy idő után, ha nem kap választ, bontja az összeköttetést. Ekkor a másik oldalon maradhat egy nyitott kapcsolat. Ezt a kapcsolatot szintén lebonthatjuk egy időzítéssel. Ha meghatározott ideig nem érkezik TPDU egy kapcsolaton, akkor lebontjuk. Ez a módszer megköveteli, hogy minden összeköttetéshez hozzárendeljünk egy időzítőt, amit minden TPDU beérkezése nulláz. 171
Ha folyamatosan fenn akarunk tartani egy összeköttetést, akkor üres TPDU-kat kell küldenünk, ha nincs adni való adatunk. Az összeköttetés esetleg felesleges, erőszakos bontása sokkal kevesebb gondot okoz, mintha végtelen ideig fenntartanánk egy nem használt összeköttetést. 172