Az "Internet" napjainkban nem egy technológia a sok közül, hanem önálló életre kelt, a társadalmat befolyásoló eszköz.

Átírás

1 8. Internet Az "Internet" napjainkban nem egy technológia a sok közül, hanem önálló életre kelt, a társadalmat befolyásoló eszköz. A technológiai cél: egymástól eltérő fizikai architectúrájú hálózatok összekapcsolása annak érdekében, hogy a hálózatban szereplő gépek egymással kommunikálni tudjanak 8.1 ábra. Eltérő technológiák kapcsolódása az Interneten. Az Internet alapvetően a TCP/IP rétegmodellre épül. A hivatkozási modell rétegeit, és szerepüket más hivatkozási modellekhez képest az 1. fejezet 1.10 és 1.11 ábrán szemléltettük. Az egyes rétegekben működő protokollok áttekintését 8.2 ábrán láthatjuk. A protokollok listája nem teljes, csak néhány jellegzetes elemet tartalmaz. 164

2 8.1. A működés modellje 8.2.ábra. TCP/IP protocol stack A hálózatban egyedi, egymástól független "csomagok" haladnak, melyeknek a célhoz vezető útvonalát a csomagban lévő cím alapján keressük. Nem biztos, hogy van ilyen útvonal, vagy ha létezik, akkor biztosan megtaláljuk meghatározott időn belül! A hálózat csomópontjain "routerek" vannak, melyek táblázatokat (Routing tables) tartanak fenn a célokhoz vezető útvonalakról. Belátható, hogy elegendő azoknak a szomszédos csomópontoknak a tárolása, ami a célhoz vezet, nem kell a teljes útvonalat tárolni. Ha egy routernek 4 "lába" van, akkor egy beérkező csomag a 3 kimenet valamelyikén továbbítható. Csak azt kell eldöntenünk, hogy melyiken a 3 közül. A további útvonal meghatározása a következő router feladata. DA = Destination Address ( cél cím) 165

3 SA = Source Address ( forrás cím) 8.3 ábra. Routerek a hálózatban A 8.3 ábrán az x című állomás küld csomagot az y címűnek. A csomagok fejléce tartalmazza yx-et. A routerek az "y" címhez tárolják azoknak a szomszédaiknak a címét, melyeken keresztül "y" a legkedvezőbben elérhető. (Legkevesebb ugrás, legkisebb költség, legrövidebb idő, stb.) A szolgáltatás datagram jellegű: A csomagok ezért elveszhetnek többszöröződhetnek beérkezési sorrendjük megváltozhat A biztonságos átvitelről a felettes rétegeknek kell gondoskodni Az Internet protokolljai A nagy hálózatok összekapcsolásának valódi alapja az Internet Protocol (IP). Eleve a különböző hálózatok összekapcsolására tervezték. Optimális továbbítást biztosít a datagramok számára a forrásgéptől a célgépig. Az alkalmazás a szállítási rétegnek adja át az adatokat. A szállítási réteg max. 64kbyte hosszú darabokra tördeli az üzenetet. Az üzeneteket a hálózati réteg esetleg tovább darabolva továbbítja. A célgépen a hálózati réteg visszaállítja a datagramot, és átadja a szállítási rétegnek. A szállítási réteg protokoll vermeket tart fenn a különböző protokolloknak. Általában négyféle protokoll vermet tartanak fenn az operációs rendszerek. 166

4 Ha az útvonal más jellegű hálózaton is áthalad, akkor az alagút típusú átvitelt használhatjuk (Pl. SNA hálózatokban). A csomagot tartalmazó keretet beburkoljuk egy az adott hálózaton használatos keretbe, az alagút végén pedig kicsomagoljuk. Hasonló a folyamat ahhoz, ahogy a gépkocsikat berakjuk vasúti kocsikba az alagút előtt, az alagút után pedig az autók saját erőforrásaikkal haladnak tovább Ipv4 protokoll Hálózataink jelenleg ezt a protokollt használják ábra. Ipv4 csomagformátum A mezők jelentése: Version (Verzió) Biztosítja, hogy a régebbi verzióval működő gépek csomagjait is megfelelően dolgozzuk fel az átmeneti időszakban. Az átmeneti idő, míg az új verzió elterjed, éveket is jelenthet. IHL - fejrész hossza 32 bites szavakban adja meg a fejrész hosszát. Legkisebb értéke 5. Maximális értéke 15. Ez a fejrész hosszát 60 bájtra korlátozza. Az opciós mező így legfeljebb 40 bájt lehet. Néhány opcióhoz ez túl kicsi. (Lásd: opciók) Type of service - szolgálat típusa lehetővé teszi, hogy a hoszt megadja az általa kért szolgálat jellegét. 167

5 A sebesség és megbízhatóság különböző kombinációit adhatjuk meg. 1 tulajdonsághoz 1 bit tartozik. Pl. hangátvitelnél a sebesség, fájl átvitelnél a megbízhatóság lehet a fontos. Ha a bitenkénti értelmezés helyett a kombináció számértékét adjuk meg, akkor az alábbi táblázat írja le a szolgáltatásokat: TOS mező értékei: Ø normál szolgála 1 minimális költség 2 maximális megbízhatóság 3 maximális átbocsátás 4 minimális késleltetés Precedence mező Ø-7 értékkel jelöli a csomag fontosságát. Ø a legalacsonyabb prioritás 7 a legmagasabb prioritást jelöli, a hálózati vezérlő csomagok szintje. Flags 3 bitet tartalmaz Az első bit használaton kívüli. A Don't fragment annak a jelzésére szolgál, hogy a csomag nem darabolható. Ennek a jelzőnek a beállítása veszélyeket is hordoz. Ha a routerek nem tudnak olyan méretű csomagokat továbbítani, mint amit küldünk, akkor "az útvonal nem létezik" jelzéssel leállhat az adatforgalom. Egy másik lehetőség, hogy a rövidebb csomagok továbbítására alkalmas rendszerszakaszon mégis feldaraboljuk a csomagot, továbbítjuk, és a szakasz végén helyreállítjuk. A lényeg az, hogy nem a célállomásra bízzuk a darabok összeállítását, hanem a szakasz végén lévő routerre. A szakasz után a csomag olyan, mintha nem daraboltuk volna fel. A célállomás a fel nem darabolható csomagok egymás közötti sorrendjével foglalkozik csak. M - More fragments bit azt jelzi, hogy a feldarabolt csomagnak nem ez az utolsó darabja. Ha megkaptuk azt a darabot, ahol M=Ø, akkor tudjuk, hogy ez az utolsó, és ismerjük a "Fragment offset" értékét. Ennek birtokában ellenőrizhető, hogy minden darab megérkezett-e. 168

6 Fragment offset (Darabeltolás) megadja, hogy a darab hova tartozik a datagramban. A címzésre 13 bit áll rendelkezésre, így a teljes datagram címezhetősége érdekében az eltolást 8 bájtos egységekben adja meg. A 8192 *8 bájt 1-el több mint amit a teljes hossz (Total length) le tud írni. Identification mező szolgál a datagram azonosítására. Egy datagram minden darabja ugyanazt az azonosítót tartalmazza. Ez teszi lehetővé, hogy a cél - hoszt azonosítsa az egy datagramhoz tartozó darabokat. Time to live mező a darab maximális élettartamát adja meg másodpercekben. A 8 bit maximum 255 másodpercet jelent. A számláló értékét minden másodpercben, illetve minden routeren való áthaladáskor csökkentjük 1-el. A routerek sokszor eltérnek ettől a szabálytól, és csak az áthaladáskor csökkentik a számlálót, az időt figyelmen kívül hagyják. Az indok az, hogy a pufferben tárolt adatokra nehézkes a megvalósítás. Az adatokon túl tárolnunk kellene a pufferbe való elhelyezés időpontját is. A csomagjaink tehát nem maradnak végtelen ideig a hálózatban. Az élettartam mező kezdőértéke beállítható. Általában közötti érték a szokásos. Gyors hálózatokban 10 körüli érték megadása is indokolt lehet, hogy ne fordulhasson elő az élettartamon belül két azonos sorszám. "Protocol" mező A hálózati réteg összeállítja a datagramot, és a protokoll mezőben meghatározott szállítási folyamatnak adja át. A folyamat általában TCP vagy UDP, de más is lehet. A protokollok számozása egységes, az RFC 1700 definiálja. Header checksum (fejrész ellenőrző összege). Csak a fejrészt ellenőrzi, a tartalmat nem. Képzése rendkívül egyszerű. 1-es komplemens módon összeadjuk a beérkező fél-szavakat (16 bit), és képezzük az eredmény 1-es komplemensét. Az ellenőrző összeget minden routeren újra kell számolni, mert az élettartam mező mindig megváltozik. Source Address, Destination address Forrás és cél címe 32 biten. (Az IP címek szerkezetét, és címfeloldást lásd később.) 169

7 Options mező 0-40 bájt hosszú lehet. Eddig 5 opciót definiáltak. A biztonság opció az információ titkosságának fokára utal. Használata gyakorlatban nem célszerű, mert felhívja a figyelmet a fontos információra. Eredményesebb álcázás, ha a fontos adatok eltűnnek a lényegtelenek tömegében. Szigorú forrás általi forgalomirányítás IP címek sorozataként megadja a teljes útvonalat Laza forrás általi forgalomirányítás lényegében az útvonal irányát jelöli ki. (Az információ bizonyos országokon ne haladjon át, ne hagyja el az országot, stb) Útvonal feljegyzése opció főként a routerek üzemeltetőinek fontos..lehetővé teszi a hibák felderítését.(miért ment USA-n keresztül a szomszéd épületbe címzett üzenet?) A mai körülmények között sokszor kevés a 40 bájt az útvonal tárolására. Az időbélyeg opció az IP cím mellé egy 32 bites időbélyeget is feljegyez. Főként a router algoritmusok hibakeresésénél hasznos eszköz IP címzési rendszer A címzési módokat az RFC791 (1981) írja le. Az Ipv4 cím két részből áll: hálózati cím + hoszt cím. Egy hoszt egyszerre több hálózathoz is csatlakozhat. Ekkor minden hálózatban külön IP címe van. A címet megjeleníthetjük binárisan, vagy decimális formában. Szokásos az u.n. "Dotted decimal" formátum. A 32 bit 4 bájtnak felel meg. Minden bájt decimális értékét írjuk ki, pontokkal elválasztva. Pl.: Az egy hálózatba tartozó gépek száma igen tág határok között változhat, ezért cím - osztályokat alakítottak ki. A címosztályoknak az információ továbbítása során is fontos szerepe van. A címek adminisztrációját korábban a NIC (Network Information Center) végezte. A 2009-ben elfogadott módosítások (pl. díj ellenében tetszőleges zárótag alkalmazható 170

8 a címben) nehezen kezelhető helyzetet hoztak létre. Jelenleg (2010) Magyarországon a HUNGARNET jogosult címtartományok engedélyezésére. A címtartomány korlátozottsága miatt (mindössze 32 bit, és ez sem osztható ki maradéktalanul) belátható időn belül szükség lesz a módosítására az Internet rohamos terjedése miatt. Számos javaslat született a megoldásra, és van szabvány javaslat is (Ipv6), de az áttérés jelentős költségei miatt egyelőre várat magára az áttörés. Valószínű, hogy az Ipv4 világban Ipv6 szigetek jönnek létre, melyeket a meglévő kapcsolatokon keresztül alagút jelleggel kapcsolnak össze mindaddig, míg az Ipv6 általánossá válik Címosztályok az Ipv4-ben A címosztály a cím bitje alapján határozható meg ábra IP címosztályok. A címek egy része speciális célokra foglalt. A címmel indul minden hoszt, majd a hálózati paraméterek betöltése után többet nem használja. A 127.xx.yy.zz címek a visszacsatolások címzésére vannak fenntartva. A a hoszt saját maga. 171

9 A helyi adatszórást jelent. Az adatszórás csak az alhálózaton belülre szól. Egy távolabbi hálózatban is végezhetünk adatszórást, ha egy helyes hálózati cím mögé csupa 1-eket írunk. Hálózati cím A helyi alhálózatunkban egy hosztot úgy is megcímezhetünk, hogy nem adjuk meg a teljes címet, csak az alhálózaton belüli hoszt címet hoszt cím Egy HOST-ot egyértelműen azonosít az IP cím. Ha ez igaz, akkor mi szükség van a címosztályokra? Egyszerűsíti és gyorsítja a csomagok irányítását. A helyi hálózatból kilépve az eszközök csak a célhálózat elérésével foglalkoznak. A hoszt cím célhálózaton belüli értelmezésére csak a fogadóoldali router után van szükség. A címnek a hálózati cím része a címosztályt jelző bitek alapján leválasztható, és a csomagirányításhoz csak ezt a részt kell használni Alhálózatok. A nagyszámú géppel rendelkező felhasználó hamar szembe kerül azzal a problémával, hogy a NIC-től szeretne egy összefüggő címtartományt kapni, ugynakkor ezt a címtartományt szeretné kisebb, külön-külön managelhető tartományra bontani. A hálózati cím és a hoszt cím szétválasztására alkalmas eszköz a netmaszk. A netmaszk a hálózati cím-pozíciókban 1-et, a hoszt - cím helyén Ø-kat tartalmaz. A címosztály meghatározza, hogy a hálózati cím hány bites. Kívülről csak a hálózat címezhető,az alhálózatunk nem, mert a továbbított csomagokban nincs benn a netmaszk. A helyi hálózatunkban azonban valamennyi eszköz tartalmazza a netmaszk-ot, és így kiderül, hogy a csomag melyik alhálózatnak szól. A hoszt címeket egy EXOR művelettel választhatjuk le a teljes címből. (teljes cím) EXOR (netmaszk) = (hoszt cím) 172

10 Példaként hozzunk létre alhálózatot egy C osztályú címen belül. Az alhálózat max. 32 gépet tartalmaz. A címtartomány legyen: ábra. Alhálózat címzése Az alhálózati maszkot valójában a router használja. A kérdés az, hogy egy bejövő üzenetet melyik kimenetre továbbítja az eszköz. Ha C osztályú címünket 8 db 32 címet tartalmazó részre osztottuk, mint a példánkban, akkor ez azt jelenti, hogy a bejövő üzeneteket 8 alhálózati szegmens felé tudjuk irányítani. A maszkban az utolsó nyolc bit Ennek decimális értéke 224. A maszk hatására az 1-es portra kerülnek 0-31 végződésű címek, a 2-es portra végződésű címek, és így tovább. A router kimenetén a teljes cím információ megjelenik. A maszk azt dönti el, hogy melyik kimenetre kerül a csomag. Az alhálózatból érkező csomag esetén a router azt tudja eldönteni, hogy a célcím az alhálazaton belül, vagy kívül van. Ha célcím az alhálózaton belül van, akkor routernek nincs tennivalója, nem továbbítja a csomagot. Ha nem az adott alhálózathoz tartozó forráscímet tartalmazó csomagot kap, azt szintén nem továbbítja. 173

11 Ha a tartományt csak 2 részre szeretnénk osztani, akkor a HOST címből egy bitet kell csak elvennünk. A maszk utolsó 8 bitje ekkor A teljes maszk decimálisan A címtartományok részekre osztásának a B osztályú címeknél van igazán jelentősége. Egy nagyvállalat a B osztályú címtartományát szabadon oszthatja fel, változtathatja anélkül, hogy a NIC-hez kellene fordulnia Az IP új generációja: IPv6 A fejlesztés céljai: Nagyszámú hoszt támogatása (>10 12 ) Forgalomirányító táblázatok méretének csökkentése Protokollok egyszerűsítése, gyorsabb feldolgozás a routereken Hitelesség és titkosság biztosítása Jobb alkalmazkodás a szolgáltatás típusához, valós idejű adatok jobb kezelése Többesküldés lehetősége, hatósugarak megadásának lehetősége Mozgó hosztok jobb támogatása IPv4 és IPv6 együttélésének biztosítása hosszabb távon is. A fejlesztés között folyt intenzíven. A javaslatban az eredeti megnevezése Simple Internet Protocol Plus volt. Az IPv6 jelölést azért kapta, mert az IPv5 már foglalt volt egy kísérleti fejlesztés számára. 174

12 Az IPv6 nem kompatíbilis az IPv4-el, de a protokollok legnagyobb részével igen (TCP, UDP, ICMP, IGMP, OSFP, BGP és DNS). A hálózat vezérlésével és a névfeloldással kapcsolatos protokollok tehát kompatibilisek. Az IPv6 magyarországi mérföldkövei ( Idézet Wikipedia szócikkből) A BME Folyamatszabályozási Tanszékén már 1997-ben folytak kutatások a IPv6 hálózatok kiépítésének tesztelésére. A NIIF által üzemeltetett és fejlesztett felsőoktatási és kutatói hálózaton ben kezdődtek meg az IPv6-os kísérletek és 2005 óta szolgáltatásként elérhető az IPv6 az egyetemek, kutatóintézetek és közgyűjtemények számára. Az Externet május 19-én zárta le a közel egy éves tesztidőszakot és azóta nyújtja rendes szolgáltatásként az IPv6-ot. A Magyar Telekom november 2-án kezdte meg hálózatában az IPv6 nyilvános tesztelését. [5][6] A Magyar Telekom június 3-án kapcsolta be az IPv6 hálózatát. Az IPv6 előnyei a végfelhasználó számára Az IPv6 amellett, hogy a jelenlegi dinamikus IP-cím kiosztás helyett minden végfelhasználó kaphat egy fix IP-címet, a biztonság terén is hoz újításokat a jelenleg használt IPv4-hez képest. A 128 bites címtartomány több ezer milliárd eszköz számára biztosíthat IP-címet, így gyakorlatilag kimeríthetetlen a kapacitása. Lefordítva ezt a háztartásokra, az otthonokban minden internetképes eszköz önálló IP-címet kaphat, így azok zavar nélkül kommunikálhatnak egymással. Ha az eszközök az internethez kapcsolódnak, akár a fűtőberendezéseket vagy a mosógépet is bekapcsolhatjuk mobiltelefonunkon keresztül. Sokan magát az IPv6-ot tekintik killer application -nek, mint ami megteremti a hálózatcentrikus világ létrehozásának lehetőségét. Ideális esetben az IPv6 használata a végfelhasználó számára láthatatlan marad. Az egyetlen változás, hogy az internetezés egyes esetekben egyszerűbbé válhat, illetve megjelennek majd olyan szolgáltatások/alkalmazások melyek IPv4 alapon csak igen bonyolult módon lennének nyújthatóak. Az IPv6 a végfelhasználó szempontjából egy ajtó, mely megteremti a lehetőséget a változásra. Éppen úgy, mint ahogyan anno a vezetékes világban a DSL, vagy a mobil világában a 3G megjelenése indított el egy-egy kommunikációs forradalmat. 175

13 IPv6 szabványok és migrációs stratégiák [szerkesztés] Az IPv6-ra vonatkozó, annak alapvető működését rögzítő szabványok az IETF szervezetében születnek. [10] Ugyanakkor érdemes nyomon követni más szabványosítási szervezetek munkáját is, hiszen fontos irányelveket fogalmaznak meg például a Broadband Forum (BBF) munkacsoportjai, melyek a meglévő szabványokon alapuló szolgáltatói környezet tekintetében rögzítenek ajánlásokat. [11] Az IPv6-bevezetési megoldások tekintetében számos eltérő a szabványosítás különböző fázisában lévő metódus látott napvilágot (pl. 6to4, 6rd, DS-lite, Softwire, Carrier Grade NAT, stb.). Az egyes megoldásoknak természetesen eltérő előnyei ill. hátrányai vannak, így folyamatos vitatémát biztosítanak a szakértők számára. Egyetértés van azonban a tekintetében, hogy a felhasználók számára egyidejűleg kell mind IPv4, mind IPv6 kapcsolódást biztosítani. Az ilyen megoldást nevezik dual-stack elérésnek. A dual-stack [12] megoldás egyik fő előnye, hogy nincs szükség IPv4 és IPv6 hálózati átjárók létrehozására, melyek segítségével a csak egyik vagy másik verziót támogató végpontok kommunikálni tudnának egymással Az IPv6 föbb tulajdonságai: 128 bitre növelt címtartomány. Új címzési séma. Hatékonyabb és flexibilisebb csomagformátum, egyszerűbb fejrész A továbbfejlesztés lehetősége az opcionális fejrészek bevezetésével A biztonsági mechanizmusok beépültek a protokollba (hitelesítés, titkosítás) Névfeloldás és a csoportmenedzsment része a protokollnak Az ARP (Address Resolution Protocol) és az IGMP (Internet Group Management Protocol) kikerült a rendszerből. Szolgáltatások a jobb támogatása 176

14 8.7.ábra. IPv6 fejrész A verzió mező az IPv4-nél mindig 4, az IPv6-nál mindig 6. A prioritás mezőben a 0-7 értékek olyan alkalmazásokhoz tartoznak, melyek képesek lassítani egy esetleges torlódásnál. A 8-15 értékek real-time folyamatokhoz tartoznak. Ezek az alkalmazások akkor sem lassítanak, ha minden csomag elvész. (Élő beszéd, mozgókép). Az alkalmazás szintjén természetesen más a helyzet. Egy videó átvitelnél esetleg tudom rontani a képpontok számát, a színmélységet, a képváltások számát, stb. Ez azonban nem a hálózat feladata, és nem is tudja befolyásolni. Mindkét csoporton belül az alacsonyabb szám alacsonyabb prioritást jelent. A folyamatcímke címke a virtuális áramkörök előnyei próbálja becsempészni a datagram típusú rendszerekbe. Az összeköttetést a forrás és célcím, valamint a folyamatcímke együttesen azonosítja. Ez lehetővé teszi, hogy több folyamat legyen aktív egy időben két IP cím között. Az egyes címkékhez különleges elbánást is rendelhetünk a routerekben, ami hasonló hatású lehet, mint a virtuális áramkörök létrehozása. Az adatmező hossza a tényleges adatmező hosszát jelöli, nem számolják bele a 40 byte hosszú fejrészt ( IPv4-nél bele számít!). A következő fejrész azt mutatja, hogy milyen további opcionális fejrészek vannak a csomagban, ha vannak. Az opcionális fejrész bevezetése tette lehetővé a kötelező fejrész jelentős egyszerűsítését. A kiegészítő fejrészek az átugrási opciókra forgalomirányításra darbolásra 177

15 hitelesítésre titkosítottságra cél opciókra vonatkozhatnak. Az átugrás korlát itt valóban az ugrások számát jelöli, nem tartalmaz időt. A címek 16 byte, azaz 128 bit hosszúságúak. A címmező rossz kihasználása esetén is belátható ideig elég a címtartomány. Az IPv6 - ból kimaradt az ellenőrzőösszeg, ami jelentősen csökkenti a routerek terhelését, és a felettes rétegeket sem terheli túlságosan az ellenőrzés a mai, viszonylag megbízható fizikai réteg felett. 178

16 Az Internet szállítási protokolljai TCP - Transmission Control Protocol A protokollt kezdettől fogva sok hálózat összekapcsolására tervezték. Feltételezték, hogy az adattovábbítás megbízhatatlan, és a közbenső csomópontok meghibásodhatnak, megsemmisülhetnek. A modellt TCP/IP néven 1974-ben definiálták. A TCP összeköttetés orientált protokoll. Alapvetően a korábban tárgyalt 3-utas kézfogás módszerét használja. Feltételezi, hogy az alatta lévő hálózat megbízhatatlan (OSI terminológia szerint C-osztályú) összeköttetést nyújt, és a TCP feladata, hogy a csomagok hibátlanságát és helyes sorrendjét biztosítsa. A TCP tartalmaz nyugtázást, így azokon a hálózatokon, ahol jelentős a késleltetés, az adatkapcsolati rétegben valamilyen csúszóablakos protokollt használnak a hatásfok javítása érdekében. A TCP az IP hálózati protokoll ( IPv 4 vagy IPv 6 ) felett fut, használja a szolgáltatásait. Az IP felett azonban más protokollok is használatosak ( UDP, ICMP, ). A TCP tetszőleges hosszúságú adatokat fogad az alkalmazásoktól. Ezeket max. 64 kbyte hosszú darabokra (szegmensekre) tördeli. A darabokat független datagramként továbbítja a hálózaton. A kommunikáció alapvetően "szegmensekben " történik. Egy szegmensnek a TCP fejrésszel együtt bele kell férni az IP bájtos adatmezejébe. A hálózatban lévő eszközök (router, gateway) a maximális hosszt tovább korlátozzák. A szegmensek hossza általában jóval rövidebb a maximális 64 kbyte-nál, néhány ezer bájt szokott lenni. A szegmens hossza valójában a hálózatban átvihető leghosszabb adategységhez (Maximum Transfer Unit) illeszkedik. Előfordulhat, hogy a hálózat különböző részein ez eltérő, és egy szakaszán az MTU rövidebb, mint a szegmens hossza. Ilyen esetben feldaraboljuk a szegmenst, és minden darabot önálló IP csomagként továbbítunk. A rövidebb szegmensekhez kapcsolódó IP fejrészek jelentős többletterhet jelentenek a hálózatnak. A TCP-ben minden byte-nak sorszáma van. A 32 bájtos sorszám elegendően nagy ahhoz, hogy a kettőződést elkerüljük a többszörös beérkezések esetén. A körülfordulási idő 100 Mbit/sec sebességű hálózaton is nagyobb mint 6 perc. 179

17 A TCP fejrész a valóságban kiegészül még egy pszeudofejrésszel. A pszeudofejrész az IP-hez tartozó adatokat tartalmaz. A szerepe az, hogy a tévesen továbbított csomagok könnyebben detektálhatók legyenek. A TCP szegmens fejrésze: 8.8. ábra. TCP fejrész felépítése A forrásport (source port) és a célport (destination port) szolgáltatásokat azonosítanak. Minden hoszt részben szabadon dönt a portok és a szolgáltatások összerendeléséről, amint azt a szállítási réteg tárgyalásánál már láttuk. Egy portszám és az IP cím együtt alkotja a 48 bites TSAP címet. A TCP bájtonként sorszámoz. A sorszám (sequence number) a szegmens első bájtjának sorszáma. A nyugtaszám (acknowledgement) mező a következő várt bájt (az utolsó helyesen vett sorszáma + 1) sorszámát tartalmazza. A TCP fejrész hossz (TCP header lenght) megadja, hogy hány 32 bites szóból áll a fejrész ( a pszeudofejrész nélkül). A fejrész hossza az opciók miatt változik, így meg kell adnunk a hosszát, hogy az adatmező kezdete ismert legyen. Ezt követi egy 6 bites használaton kívüli rész, majd a jelzőbitek (flags) következnek. Flags: 180

18 URG = 1 ha használunk sürgősségi mutatót. A sürgősségi mutató a sürgős rész helyét jelöli a sorszám mezőhöz képest. Az URG szerepe hasonló, mint a megszakításé a programok futása közben. ACK = 1 értéke azt jelzi, hogy a szegmens nyugtát tartalmaz. Ha az értéke 0, akkor a nyugtamező figyelmen kívül hagyható. PSH = 1 (PUSH) azt kéri a vevőtől, hogy az adatokat pufferelés nélkül továbbítsa az alkalmazásnak. RST = 1 Restart. Ha az összeköttetés összeomlott, vagy valami más rendellenesség történt, akkor tartalmaz a szegmens RST=1-et. Ha ilyet veszünk, fel kell készülni valami rendkívüli esemény kezelésére. SYN bit-nek az összeköttetés felépítésekor van szerepe. Valójában az ACK-val együttesen van értelme. Ha SYN=1, ACK=0 akkor ez valójában egy CONNECTION REQVEST kérés. A SYN=1, ACK=1 a CONNECTION ACCEPTED-nek felel meg. FIN bit az összeköttetés bontására szolgál. Az ablakméret (windows size) mező azt jelzi, hogy a nyugtában szereplő bájttal kezdődően hány bájtot küldhetünk el. Az ablakméret a csúszóablakos protokollnál tárgyaltaknak felel meg. Ez egy változó méretű csúszó ablak. A Ø hossz is értelmezett. Azt jelenti, hogy a vevő az adás felfüggesztését kéri. Az ellenőrzőösszeg (Checksum) számításába a pszeudofejrész, a fejrész és az adatmezők is beleszámítanak. Az ellenőrző összeg képzése 16 bites 1-es komplemens összeadással történik. Az adatmezőt, ha nem páros számú bájtot tartalmaz, páros számúra egészítjük ki. A kapott összeg 1-es komplemensét véve kapjuk az ellenőrző összeget. A vevő oldalon elvégezve az összeadást a teljes szegmensre 0-t kell kapnunk. Az opciók (Options) mezőt elsősorban a vevő által elfogadható legnagyobb TCP adatmező méretének meghatározására szokták használni. A nagy sebességű és nagy késleltetésű vonalakon a 64 Kbyte nem elegendően nagy ablak. Egy műholdas csatornában (50Mbit/sec) a 64 Kbyte továbbítása 10 msec körüli időt vesz igénybe. A vonali késleltetés minimálisan 2*270 msec a nyugta megérkezéséig. A hatásfok tehát katasztrófális. A hatásfok javítható lenne az ablak hosszának növelésével. Javaslatok vannak a nagyobb (legfeljebb 2 30 ) méretű ablak használatára. A legtöbb TCP implementáció ma már megengedi és támogatja a nagyméretű szegmensek átvitelét. 181

19 UDP (User Datagram Protocol) Az UDP az Internet összeköttetés nélküli szállítási protokollja. IP datagramok küldését teszi lehetővé összeköttetés létesítése nélkül. Jóval egyszerűbb mint a TCP. Használata ott célszerű, ahol egy kérésre egyetlen válasz érkezik, és a nyugtázásnak nincs jelentősége. Pl.: ha elküldünk egy ARP kérést (lásd 8.2.5), felesleges nyugtázni, mert ha megkaptuk a választ, akkor a nyugta nélkül is biztos, hogy a kérés célba érkezett. Ha nem, akkor egy időzítés lejárta után a kérés újbóli elküldése az egyetlen lehetséges lépés, tehát a nyugta itt is felesleges. Az összeköttetés lebontása és felépítése elmarad, a fejléc is lényegesen egyszerűbb ábra.udp csomag felépítése A pszeudofejrész az ellenőrző összeg számításakor beleszámít a fejrészbe. Az UDP szegmens hossz a fejrész és az adatrész együttes hosszát adja meg. A forrás és a célport a hosztokon belül azonosítja a végpontokat (szolgáltatásokat). Az UDP-t az RFC 768-ban találjuk meg részletesen. 182

20 Az Internet vezérlő protokolljai ICMP Az ICMP (Internet Control Message Protocol) Internet vezérlőüzenet protokoll az Internet felügyeletét szolgálja. Összesen mintegy tucatnyi üzenetet definiáltak. Az üzeneteket főként routerek hozzák létre. A visszhang és időbélyeg kérést indíthatja egy hoszt is. A fontosabb ICMP üzenetek: DESTINATION UNREACHABLE Cél elérhetetlen TIME EXCEEDED Időtúllépés PARAMETER PROBLEM Paraméter probléma SOURCE QUENCH Forrás lefojtás REDIRECT Újrairányítás ECHO REQUEST Viszhang kérés TIMESTAMP REQUEST Időbélyeg kérés ábra. ICMP üzenetek A CÉL ELÉRHETETLEN üzenet akkor keletkezik, ha a router nem találja a célt, vagy ha olyan üzenetet kapott, ahol áll a DF bit, és a hálózat nem tud akkora csomagot kezelni, mint a beérkezett. IDŐTÚLLÉPÉS üzenetet akkor küld a router, ha a csomag élettartam mezője elérte a nullát. (Torlódás van, hurokba került a csomag, túl alacsony a beállított élettatam). PARAMÉTER PROBLÉMA üzenet az IP fejrész hibáját jelzi. Rendszerint valamelyik router szoftver hibája okozza. FORRÁSLEFOJTÁS üzenetet a túl sok csomagot küldő hosztok kapnak, hogy lassítsanak. Az új forgalomirányító algoritmusok nem használják. (A forgalomszabályozás a szállítási rétegben történik.) 183

21 ÚJRAIRÁNYÍTÁS üzenetet akkor küld a router, ha a csomag rosszul irányítottnak tűnik. (Teljesen rossz földrajzi irány.) VISSZHANG KÉRÉS és VISSZHANG VÁLASZ üzenetek egy hoszt elérhetőségének tesztelésére használhatók. Az IDŐBÉLYEG KÉRÉS és IDŐBÉLYEG VÁLASZ üzenet a hoszt elérhetőségén túl a hálózat teljesítményét is méri. Az üzenet érkezési ideje és a válasz indulási ideje is szerepel a válaszban. Az ICMP teljes definíciója az RFC 792-ben található. ARP (Adress Resolution Protocol) Minden Internetre csatlakozó gépnek van legalább egy IP címe. Az IP cím logikai cím, amit az interface hardvere nem ért meg. Az IP címeket le kell fordítanunk az adatkapcsolati réteg számára érthető fizikai címekre. Az összerendelést elvileg megoldhatnánk táblázatokkal is, de a gyakorlat számára ez túl nehézkes megoldás, és nem követi a hálózat változásait. (Bekapcsolnak, kikapcsolnak gépeket, hálózati szegmenseket,) A másik nehézség abból adódik, hogy távoli hálózatokban lévő gépeket is meg akarunk szólítani, amelyeknek a fizikai címét nem ismerjük A megoldást nézzük meg egy egyszerű hálózaton: 8.11.ábra. Összekapcsolt C osztályú hálózatok 184

22 Fel kell tételeznünk, hogy a küldő ismeri a cél címét. A cím egy hierarchikusan felépített szöveges elem, pl.: geniusz.pte.hu A névhez a "Domain Name System" (körzetnév kezelő rendszer) fogja visszaadni az IP címet. A példánkban őt. (A DNS rendszer ismertetése a 8.3. fejezetben.) A küldő gép az IP cím ismeretében kiadhat az alhálózatra egy adatszórást: "kié a cím?" Az adatszórás természetesen ETHERNET szintű, tehát fizikai cím szerinti adatszórás. A kérés tartalmazza a kérdező gép fizikai címét is. A magát felismerő címzett eltárolja a kérő fizikai címét, majd elküldi a saját fizikai címét a kérdezőnek (a kérésből ismeri annak a fizikai címét) amit a kérdező eltárol és elküldi az üzenetet. Látnunk kell, hogy az ETHERNET alhálózatban a keretek csak fizikai címekre küldhetők. A kérdés és válasz lebonyolítását végző protokoll az ARP. A protokollt az RFC 826 definiálja. Valamivel bonyolultabb a helyzet akkor, ha a küldő és a címzett nem ugyanabban az alhálózatban van. A küldő például a d31.pte.hu. Ekkor a küldő miután visszakapta az IP címet, látja, hogy a cél egy távolabbi hálózatban van. Ekkor az adatkeretet elküldi egy az alhálózaton belüli fix ETHERNET címre, a routernek az alhálózathoz csatlakozó fizikai címére. Minden, az alhálózaton kívülre címzett üzenetet ide kell küldenünk (Default router). Az IP hálózat feladata, hogy eljuttassa a megfelelő alhálózatig a csomagot. Az alhálózaton belül az ottani router fogja megkeresni a fizikai címet, és továbbítani a keretet. A hálózat minden eleme tart fenn táblázatokat, melybe a címfeloldással kapcsolatos adatokat bejegyzi. Az adatok gyors-tárba kerülnek és egy ideig megőrződnek. Ez a módszer csökkenti a hálózati forgalmat, és gyorsítja a címek megtalálását. RARP (Reverse Addres Resolution Protocol) Szükség lehet a korábban tárgyalt ARP fordítottjára is. Fizikai címhez kereshetünk IP címet. Egy diszk nélküli állomás indulásakor adatszórással megkérdezi, hogy az állomás fizikai címéhez ki tud egy IP címet. A RARP szerver kikeresi a táblázatából az IP címet, és elküldi az ismert fizikai címre. 185

23 A RARP csupa 1-ből álló címet tud csak adatszóráskor megadni, tehát az adatszórás lokális. A kérést a routerek nem továbbítják. Emiatt minden alhálózaton kell lenni egy RARP szervernek. Nem biztos, hogy minden alhálózatban van szerver, és ha nincs, a megoldás nem működik. A probléma megkerülésére használják a BOOTP protokollt. Ez UDP üzeneteket használ, amit a routerek továbbítanak, és nem szükséges minden hálózati szegmensben egy RARP szerver. A RARP definícióját az RFC 903, a BOOTP részleteit az RFC 951 írja le DNS (Domain Name System) Körzeti névkezelő rendszer. A hálózati eszközök bináris címeket ismernek. A legtöbb ember számára az értelmes nevek, vagy rövidítések is sokkal jobban megjegyezhetők, mint a bináris címek. Szükség van tehát a kétféle ábrázolásmód kölcsönös megfeleltetésére. Maguk a nevek is gondot okoznak, hiszen az azonos nevek okozta konfliktusok csak valamilyen központi nyilvántartással, vagy hierarchikus rendszerrel oldhatók meg. A hierarchikus megoldás nagyszámú cím esetén nyilvánvalóan egyszerűbb, és működőképesebb megoldás. Egy tipikusan hierarchikus cím a lakcímünk is. A legtöbb faluban, városban van Petőfi utca. Ennek ellenére könnyen kiválaszthatjuk, hogy melyikről van szó, ha szerepel a helység neve is a címzésben. Az egyes elemeket ponttal elválasztva az alábbi alakja lehetne a címnek: név.házszám.utca.város.ország Hasonló az Internet címzése is, a DNS névtér DNS névtér Az Internet a lehetséges címek halmazát néhány száz elsődleges körzetre (domain) bontja. Minden körzet további alkörzetekre bontható, egészen addig, míg a fa leveleiként eljutunk a hosztokig. A legfelső szinten lévő elsődleges körzetek kétfélék lehetnek: általános körzetek országok 186

24 Az általános körzeteket az USA-n belül használják a különböző szervezetek megkülönböztetésére. Ilyenek a com (kereskedelem), edu (oktatási intézmények), mil (USA fegyveres erői), org (non-profit szervezetek), stb. A felosztást az ISO 3166 tartalmazza. A körzetek egy névtelen gyökérhez kapcsolódnak. A hierarchikus felépítésből adódóan névkonfliktusok földrajzilag kis területen, egy alkörzeten belül fordulhatnak elő, és ott könnyen megoldhatók ábra. DNS névtér A körzetnevekben a kisbetűs és nagybetűs írásmód között nincs különbség. A névkomponensek maximális hossza 63 karakter. A teljes útvonalnév rövidebb vagy egyenlő 255 karakterrel. Minden körzet maga ellenőrzi az alatta lévő körzeteket, így elkerülhető egy végtelen méretű központi nyilvántartás létrehozása. Egy új körzet létrehozását az a körzet engedélyezheti, ahova tartozni fog. Az elnevezések a szervezeti hierarchiához igazodnak, nem követik a hálózat fizikai felépítését Erőforrás nyilvántartás A név-ip cím megfeleltetésen túl is van szükség adatokra az Internet üzemeltetéséhez. Minden körzethez tartozik egy erőforrás rekord halmaz. Szélsőséges esetben az erőforrás bejegyzés lehet egyetlen IP cím, ha egyetlen gép van a körzetben, de számos más bejegyzés is létezhet. Egy általános erőforrás rekord: 187

25 Körzet_név Élettartam Osztály Típus Érték Az erőforrás rekordok ASC II formátumban tárolja a Domain Name Server. A Körzet_név azt a körzetet jelenti, amihez a rekord tartozik. A legtöbb esetben egy körzethez sok rekord tartozik. Az adatbázisban a zóna ( több körzet, részletesebben fejezet) adatai szerepelnek, és a körzet_név az elsődleges kulcs. Az Élettartam mező a bejegyzés stabilitására utal. A legmagasabb érték 86400, ami egy nap másodpercekben kifejezve. Azt mutatja, hogy az adott rekord meddig marad a cache-tárban. Az instabil bejegyzések rövid ideig maradnak a cache-tárban. A "rövid idő" 60 másodperc körüli értéket jelent. Az Osztály a hálózattípusokat különbözteti meg. Az Internethez tartozó információknál, tehát majdnem mindig "IN". A Típus mező az információ jellegére utal. A legfontosabb típusok: SOA a lista kezdete A zónához tartozó névsorról tárol információkat, az adminisztrátor címét, egy egyedi sorozatszámot, jelzőket és időzítők értékeit adja meg. Az A(ddres) egy 32 bites IP cím egy hoszthoz. MX tartalmazza a körzethez tartozó levelek fogadására alkalmas gépek nevét. A név előtt egy sorszám van, ami a kézbesítési sorrendet jelöli. Elsőnek az 1-es számú gépnek próbálja meg az e.-mail-ek továbbítását. Ha nem működik, akkor a 2-es számú gépnek, és így tovább, amíg van levelező szerver a listán. NS névszerver rekord A névfeloldás működéséhez minden DNS adatbázis tárol az összes elsődleges körzet DNS szerveréhez egy rekordot, és további névszerverek adatait is tárolhatja. A névfeloldás részletesebb vizsgálatánál látni fogjuk ennek szerepét. CNAME bejegyzések álneveket takarnak. Ha megváltozik a körzetnevünk, akkor célszerű a régi nevet álnévként megadni. Korábban a PTE-en belül használtuk a PMMF alkörzetet is. Ha megadjuk a CNAME rekordot, akkor a régi nevén is meg fogják találni a hosztot. Például: 188

26 almos.pmmf.pte.hu IN CNAME almos.pte.hu PRT álnév egy IP-címhez HINFO hoszt leírás. A számítógép típusára és az operációs rendszerre utal. TXT szöveges leírás. A számítógépek nem használják, csak az emberek számára teszi olvasmányosabbá az állományt. Érték mező tartalmazhat számot, vagy ASCII karakterláncot. Néhány példa a bejegyzésekre: Az atlas.pte.hu egy szerver, a K_32401 pedig egy munkaállomás. Ez egy részlet az adatbázisból.... atlas.pte.hu IN HINFO IBM UNIX atlas.pte.hu IN A atlas.pte.hu IN MX atlas.pte.hu K_32401.pte.hu IN A IN MX atlas.pte.hu IN HINFO IBM windows A K_32401 gép bejegyzéséből látszik, hogy közvetlenül nem fogad leveleket, a létrehozott levelező fiókoknak szóló üzenetek az atlas.pte.hu gépen fognak tárolódni. Az elsődleges körzetek adatai nem szerepelnek az adatbázisban. Ezeket egy konfigurációs fájl tartalmazza, ami a DNS szerver indításakor betöltődik a gyorsító tárba. A fájl szerkezete hasonló, mint az egyéb erőforrás bejegyzések. $ORIGIN server.root. ( ) NS A.ROOT-SERVERS.NET NS B.ROOT-SERVERS.NET NS C.ROOT-SERVERS.NET.. ; formerly NS.INTERNIC.NET A.ROOT-SERVERS.NET A ; formerly NS1.ISI.EDU B.ROOT-SERVERS.NET A

27 . ; housed in Japan, operated by WIDE M.ROOT-SERVERS.NET A Név szerverek (Domain Name Servers) Tisztán logikailag az egész névtérnek egyetlen DNS szervere is lehetne, ahol a teljes adatbázist tároljuk. Ez a megoldás sem a hálózati forgalom, sem a biztonság, sem az adminisztráció szempontjából nem elfogadható. A névteret ezért egymást át nem fedő zónákra osztják. Egy zónában több név szerver van a megbízhatóság növelése érdekében. A zónában egy elsődleges, és egy vagy több másodlagos név szerver van. A másodlagos név szerverek másolatai a primer név szervernek. Módosításokat csak a primer név szerveren lehet végrehajtani. A módosítások automatikusan másolódnak a másodlagos szerverekre. Szerepük a terhelés megosztása, és a biztonság növelése. Egy a zónához tartozó név szerver lehet a zónán kívül is. A zónahatárok kijelölése a zóna adminisztrátortól függ. A terheléselosztás és a menedzselés szempontjai a meghatározók ábra. DNS névtér egy része a zónák jelölésével A példánk pte.hu részletében a pte zóna ellátja a ktk-t is. A "mit" azonban önálló név szervert üzemeltet. (A példák csak az elvet szemléltetik, nem hitlesek!) Ha egy címfeloldó szeretne tudni valamit egy körzetnévről, akkor elküldi a kérdést egy helyi név szervernek. Ha a körzet az adott szerverhez tartozik, akkor az visszaküldi a hiteles erőforrás bejegyzéseket. A hiteles bejegyzés (authoritative record) azt 190

28 jelenti, hogy a bejegyzés attól a szervertől származik, amelyik a bejegyzést kezeli. Egy a gyors-tárban lévő adat lehet elavult is, de ez az adat biztosan meg fog egyezni a diszken tárolt adattal, hiteles. A kérdések azonban távoli körzetekre is irányulhatnak, és ekkor a folyamat bonyolultabb. A lekérdezés alapvető típusai a ábrán láthatók. A rekurzív lekérdezéses módszernél a szerver ha nem rendelkezik megfelelő információval a célról, továbbadja egy másik szervernek, amíg eléri a hiteles bejegyzést. A példában andi.pte.hu fordul a lokális szerverhez, az a "hu" elsődleges körzet szerveréhez. A "hu" ismeri a bme.hu címét, és ez a szerver hitelesen tárolja a peter.bme.hu címét, visszakapjuk a hiteles bejegyzést a peter.bme.hu gépről. Az iteratív lekérdezésnél ha a lokális keresés sikertelen, akkor annak a szervernek a címét kapjuk vissza, ahol a legközelebb próbálkozhatunk. Ennél a módszernél az andi.pte.hu elsőnek a "hu" szerver címét kapja vissza. A hu szervertől megkapja a bme.hu címét, ami rendelkezik a peter.bme.hu hiteles bejegyzésével ábra. Alapvető DNS lekérdezési formák 191

29 8.15. ábra. Rekurzív és interaktív keresés együttes használata Távoli címek keresésénél a két módszer kombinációja hatékony (8.15.ábra). A teve.reszleg.ceg.hu hosztról keressük andi-t, egy német egyetem informatikai tanszékén. A cím: andi.cs.tu.de. Rekurzív kereséssel jutunk el egy root szerverhez. A ceg.hu szerver ismeri a de primer körzet név szerverének címét (betöltötte a konfigurációs fájlból), ahonnan megkapja a tu.de szerver címét (interaktív keresés). A tu.de rekurzívan megkeresi a cs.tu.de szervert, ahonnan megkapja a hiteles bejegyzést, és visszaküldi a cég.hu szervernek, ahonnan eljut a teve.reszleg.ceg.hu gépig. Ha végiggondoljuk a keresés lépéseit, belátható, hogy ezzel a módszerrel terheljük legkevésbé a nagy forgalmú nemzetközi hálózatot. A keresési típusok beállítása a Name Server-t üzemeltető adminisztrátor feladata. Belátható, hogy a jó konfiguráció jelentősen gyorsíthatja a rendszer működését, vagy egy ügyetlenebb beállítás jelentős erőforrásokat köthet le. 192