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 Web browser Other user Applications Application protocols: HTTP,SMTP,FTP,DNS.. USER space Applications Application Programming Interface (API) Transport Network ICMP TCP IP UDP RIP OS kernel ARP Data Link RARP FDDI WAN technology LAN technology Ethernet 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. 165

3 DA = Destination Address ( cél cím) 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. 166

4 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. 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 167

5 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. 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 168

6 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. 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). 169

7 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.) 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. 170

8 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ímek adminisztrációját a NIC (Network Information Center) végzi. Ez a szervezet osztja ki a cím - tartományokat. 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. 32 bit Osztály A 0 Hálózat Hoszt tól ig B 10 Hálózat Hoszt tól ig C 110 Hálózat Hoszt tól ig D 1110 Többesküldési cím tól ig E Jővőbeni alkalmazásokhoz fenntartva tól ig 8.5. ábra IP címosztályok. 171

9 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. 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 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: Alhálózat IP cím Hálózat címe Hoszt cím "C" osztályú a cím Hoszt cím a külső hálózat számára A külső hálózat nem látja az alhálózati maszkot, csak a "C" osztályt ismeri fel!! Alhálózati maszk Decimálisan: Példa: alhálózati cím leválasztása a címből Az alhálózat címe: ÉS = ábra. Alhálózat címzése Figyeljük meg, hogy az alhálózati maszk eredményeként a címtartományt 8 részre tudtuk osztani.. 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 173

11 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. 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 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 8.7.ábra. IPv6 fejrész 174

12 175

13 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. 176

14 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: 32 bit 0 Source IP address Destination IP address Protocol(6) TCP segmenth lenght Pseudo header Source TCP port Destination TCP port Sequence number Acknowledgement number Hdr.l. Flags Window size Checksum Urgent pointer Options Data TCP header Flags URG ACK PSH RST SYN FIN 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: 177

15 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. 178

16 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. 32 bit 0 Source IP address Destination IP address Protocol(6) UDP segmenth lenght Pseudo header Source UDP port Destination UDP port UDP UDP Message lenght UDP Checksum header Data 8.9. á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. 179

17 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.) 180

18 Ú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: WAN Router Router1 Router d31.pte.hu geniusz.pte.hu k19.pte.hu ETHERNET1 ETHERNET ábra. Összekapcsolt C osztályú hálózatok 181

19 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?" Erre a magát felismerő címzett elküldi a fizikai címet, amit a kérdező eltárol és elküldi az üzenetet. 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. 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 182

20 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 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. 183

21 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. Általános Országok com int edu gov mil org.. hu de nl.. hp yale pte axelero tu-bs cs eng mit ktk cs adm bib ai mi-oktat k-229 ibr robots schoenw new golem á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: 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. 184

22 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: almos.pmmf.pte.hu IN CNAME almos.pte.hu PRT álnév egy IP-címhez 185

23 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 ; housed in Japan, operated by WIDE M.ROOT-SERVERS.NET A

24 8.3.3 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. Általános Országok com int edu gov mil org.. hu de nl.. hp yale pte axelero tu-bs cs eng mit ktk cs adm bib ai mi-oktat k-229 ibr robots schoenw new golem 8.13.á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 jelenti, hogy a bejegyzés attól a szervertől származik, amelyik a bejegyzést kezeli. A gyors-tárban lévő adat lehet elavult, ez az adat a diszkről származik. 187

25 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. Recursive Query root Name Server Iterative Query root Name Server 2(Q) 5(R) hu 4(R) 3(Q) hu 3(Q) 4(Rfr) Name Server pte.hu 1(Q) 6(R) bme.hu Name Server (authoritative) Name Server pte.hu 2(Rfr) 1(Q) 5(Q) bme.hu Name Server (authoritative) 6(R) andi.pte.hu peter.bme.hu andi.pte.hu peter.bme.hu ábra. Alapvető DNS lekérdezési formák 188

26 root Name Server ceg.hu NS (intermediate) Cache 3(Q) 4(Rfr) 5(Q) tu.de NS (intermediate) Cache Q= Query R= Response Rfr= Referral data base 8(R) data base 2(Q) 9(R) 6(Q) 7(R) Cache data base reszleg.ceg.hu NS (local NS) Cache data base cs.tu.de NS (authoritative) Cache data base 1(Q) 10(R) teve.reszleg.ceg.hu andi.cs.tu.de Kérdés: mi az IP címe az andi.cs.tu.de hosztnak? á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. 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. 189