You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
8. <strong>Internet</strong><br />
Az "<strong>Internet</strong>" napjainkban nem egy technológia a sok közül, hanem önálló életre kelt,<br />
a társadalmat befolyásoló eszköz.<br />
A technológiai cél: egymástól eltérő fizikai architectúrájú hálózatok összekapcsolása<br />
annak érdekében, hogy a hálózatban szereplő gépek egymással kommunikálni<br />
tudjanak<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
8.1 ábra. Eltérő technológiák kapcsolódása az <strong>Internet</strong>en.<br />
Az <strong>Internet</strong> alapvetően a TCP/IP rétegmodellre épül. A hivatkozási modell rétegeit ,<br />
és szerepüket más hivatkozási modellekhez képest az 1. fejezet 1.10 és 1.11 ábrán<br />
szemléltettük. Az egyes rétegekben működő protokollok áttekintését 8.2 ábrán<br />
láthatjuk. A protokollok listája nem teljes, csak néhány jellegzetes elemet tartalmaz.<br />
164
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
Application protocols:<br />
HTTP,SMTP,FTP,DNS..<br />
Applications<br />
Transport<br />
Network<br />
Data Link<br />
Web browser<br />
e-Mail<br />
Other user<br />
Applications<br />
Application Programming Interface (API)<br />
ICMP<br />
ARP RARP<br />
8.1. A működés modellje<br />
FDDI<br />
TCP UDP<br />
IP<br />
WAN<br />
technology<br />
8.2.ábra. TCP/IP protocol stack<br />
RIP<br />
LAN<br />
technology Ethernet<br />
USER<br />
space<br />
OS<br />
kernel<br />
A hálózatban egyedi, egymástól független "csomagok" haladnak, melyeknek a célhoz<br />
vezető útvonalát a csomagban lévő cím alapján keressük. Nem biztos, hogy van<br />
ilyen útvonal, vagy ha létezik, akkor biztosan megtaláljuk meghatározott időn belül!<br />
A hálózat csomópontjain "routerek" vannak, melyek táblázatokat (Routing tables)<br />
tartanak fenn a célokhoz vezető útvonalakról. Belátható, hogy elegendő azoknak a<br />
szomszédos csomópontoknak a tárolása, ami a célhoz vezet, nem kell a teljes<br />
útvonalat tárolni.<br />
Ha egy routernek 4 "lába" van, akkor egy beérkező csomag a 3 kimenet<br />
valamelyikén továbbítható. Csak azt kell eldöntenünk , hogy melyiken a 3 közül.<br />
A további útvonal meghatározása a következő router feladata.<br />
165
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
8.3 ábra. Routerek a hálózatban<br />
DA = Destination Address ( cél cím)<br />
SA = Source Address ( forrás cím)<br />
A 8.3 ábrán az x című állomás küld csomagot az y címűnek. A csomagok fejléce<br />
tartalmazza yx-et.<br />
A routerek az "y" címhez tárolják azoknak a szomszédaiknak a címét, melyeken<br />
keresztül "y" a legkedvezőbben elérhető. (Legkevesebb ugrás, legkisebb költség,<br />
legrövidebb idő, stb.)<br />
A szolgáltatás datagram jellegű:<br />
A csomagok ezért<br />
elveszhetnek<br />
többszöröződhetnek<br />
beérkezési sorrendjük megváltozhat<br />
A biztonságos átvitelről a felettes rétegeknek kell gondoskodni.<br />
8.2. Az <strong>Internet</strong> protokolljai<br />
A nagy hálózatok összekapcsolásának valódi alapja az <strong>Internet</strong> Protocol (IP).<br />
Eleve a különböző hálózatok összekapcsolására tervezték. Optimális továbbítást<br />
biztosít a datagramok számára a forrásgéptől a célgépig.<br />
166
Az alkalmazás a szállítási rétegnek adja át az adatokat. A szállítási réteg max.<br />
64kbyte hosszú darabokra tördeli az üzenetet. Az üzeneteket a hálózati réteg<br />
esetleg tovább darabolva továbbítja.<br />
A célgépen a hálózati réteg visszaállítja a datagramot, és átadja a szállítási rétegnek.<br />
A szállítási réteg protokoll vermeket tart fenn a különböző protokolloknak. Általában<br />
négyféle protokoll vermet tartanak fenn az operációs rendszerek.<br />
Ha az útvonal más jellegű hálózaton is áthalad, akkor az alagút típusú átvitelt<br />
használhatjuk (Pl. SNA hálózatokban). A csomagot tartalmazó keretet beburkoljuk<br />
egy az adott hálózaton használatos keretbe, az alagút végén pedig kicsomagoljuk.<br />
Hasonló a folyamat ahhoz, ahogy a gépkocsikat berakjuk vasúti kocsikba az alagút<br />
előtt, az alagút után pedig az autók saját erőforrásaikkal haladnak tovább.<br />
8.2.1 Ipv4 protokoll<br />
Hálózataink jelenleg ezt a protokollt használják.<br />
A mezők jelentése:<br />
Version (Verzió)<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
8.4. ábra. Ipv4 csomagformátum<br />
Biztosítja, hogy a régebbi verzióval működő gépek csomagjait is megfelelően<br />
dolgozzuk fel az átmeneti időszakban. Az átmeneti idő, míg az új verzió elterjed,<br />
éveket is jelenthet.<br />
IHL - fejrész hossza<br />
167
32 bites szavakban adja meg a fejrész hosszát. Legkisebb értéke 5. Maximális értéke<br />
15. Ez a fejrész hosszát 60 bájtra korlátozza.<br />
Az opciós mező így legfeljebb 40 bájt lehet.<br />
Néhány opcióhoz ez túl kicsi. (Lásd: opciók)<br />
Type of service - szolgálat típusa lehetővé teszi, hogy a hoszt megadja az általa kért<br />
szolgálat jellegét.<br />
A sebesség és megbízhatóság különböző kombinációit adhatjuk meg. 1<br />
tulajdonsághoz 1 bit tartozik. Pl. hangátvitelnél a sebesség, fájl átvitelnél a<br />
megbízhatóság lehet a fontos. Ha a bitenkénti értelmezés helyett a kombináció<br />
számértékét adjuk meg, akkor az alábbi táblázat írja le a szolgáltatásokat:<br />
TOS mező értékei: Ø normál szolgála<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
1 minimális költség<br />
2 maximális megbízhatóság<br />
3 maximális átbocsátás<br />
4 minimális késleltetés<br />
Precedence mező Ø-7 értékkel jelöli a csomag fontosságát.<br />
Ø a legalacsonyabb prioritás<br />
7 a legmagasabb prioritást jelöli, a hálózati vezérlő csomagok szintje.<br />
Flags 3 bitet tartalmaz<br />
Az első bit használaton kívüli.<br />
A „Don't fragment” annak a jelzésére szolgál, hogy a csomag nem darabolható.<br />
Ennek a jelzőnek a beállítása veszélyeket is hordoz. Ha a routerek nem tudnak olyan<br />
méretű csomagokat továbbítani, mint amit küldünk, akkor "az útvonal nem létezik"<br />
jelzéssel leállhat az adatforgalom.<br />
Egy másik lehetőség, hogy a rövidebb csomagok továbbítására alkalmas rendszer-<br />
szakaszon mégis feldaraboljuk a csomagot, továbbítjuk, és a szakasz végén<br />
helyreállítjuk. A lényeg az, hogy nem a célállomásra bízzuk a darabok összeállítását,<br />
hanem a szakasz végén lévő routerre. A szakasz után a csomag olyan, mintha nem<br />
168
daraboltuk volna fel. A célállomás a fel nem darabolható csomagok egymás közötti<br />
sorrendjével foglalkozik csak.<br />
M - More fragments bit azt jelzi, hogy a feldarabolt csomagnak nem ez az utolsó<br />
darabja. Ha megkaptuk azt a darabot, ahol M=Ø, akkor tudjuk, hogy ez az utolsó, és<br />
ismerjük a "Fragment offset" értékét. Ennek birtokában ellenőrizhető, hogy minden<br />
darab megérkezett-e.<br />
Fragment offset (Darabeltolás) megadja, hogy a darab hova tartozik a datagramban.<br />
A címzésre 13 bit áll rendelkezésre, így a teljes datagram címezhetősége érdekében<br />
az eltolást 8 bájtos egységekben adja meg. A 8192 *8 bájt 1-el több mint amit a<br />
teljes hossz (Total length) le tud írni.<br />
Identification mező szolgál a datagram azonosítására. Egy datagram minden darabja<br />
ugyanazt az azonosítót tartalmazza. Ez teszi lehetővé, hogy a cél - hoszt azonosítsa<br />
az egy datagramhoz tartozó darabokat.<br />
Time to live mező a darab maximális élettartamát adja meg másodpercekben. A 8 bit<br />
maximum 255 másodpercet jelent. A számláló értékét minden másodpercben, illetve<br />
minden routeren való áthaladáskor csökkentjük 1-el. A routerek sokszor eltérnek ettől<br />
a szabálytól, és csak az áthaladáskor csökkentik a számlálót, az időt figyelmen kívül<br />
hagyják. Az indok az, hogy a pufferben tárolt adatokra nehézkes a megvalósítás. Az<br />
adatokon túl tárolnunk kellene a pufferbe való elhelyezés időpontját is.<br />
A csomagjaink tehát nem maradnak végtelen ideig a hálózatban.<br />
Az élettartam mező kezdőértéke beállítható. Általában 40 - 50 közötti érték a<br />
szokásos. Gyors hálózatokban 10 körüli érték megadása is indokolt lehet, hogy ne<br />
fordulhasson elő az élettartamon belül két azonos sorszám.<br />
"Protocol" mező<br />
A hálózati réteg összeállítja a datagramot, és a protokoll mezőben meghatározott<br />
szállítási folyamatnak adja át. A folyamat általában TCP vagy UDP, de más is lehet.<br />
A protokollok számozása egységes, az RFC 1700 definiálja.<br />
Header checksum (fejrész ellenőrző összege).<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
169
Csak a fejrészt ellenőrzi, a tartalmat nem. Képzése rendkívül egyszerű. 1-es<br />
komplemens módon összeadjuk a beérkező fél-szavakat (16 bit), és képezzük az<br />
eredmény 1-es komplemensét.<br />
Az ellenőrző összeget minden routeren újra kell számolni, mert az élettartam mező<br />
mindig megváltozik.<br />
Source Address, Destination address<br />
Forrás és cél címe 32 biten. (Az IP címek szerkezetét, és címfeloldást lásd később.)<br />
Options mező 0 - 40 bájt hosszú lehet.<br />
Eddig 5 opciót definiáltak.<br />
A biztonság opció az információ titkosságának fokára utal. Használata<br />
gyakorlatban nem célszerű, mert felhívja a figyelmet a fontos információra.<br />
Eredményesebb álcázás, ha a fontos adatok eltűnnek a lényegtelenek<br />
tömegében.<br />
Szigorú forrás általi forgalomirányítás IP címek sorozataként megadja a teljes<br />
útvonalat<br />
Laza forrás általi forgalomirányítás lényegében az útvonal irányát jelöli ki. (Az<br />
információ bizonyos országokon ne haladjon át, ne hagyja el az országot, stb)<br />
Útvonal feljegyzése opció főként a routerek üzemeltetőinek fontos. .Lehetővé<br />
teszi a hibák felderítését.(Miért ment USA-n keresztül a szomszéd épületbe<br />
címzett üzenet?) A mai körülmények között sokszor kevés a 40 bájt az útvonal<br />
tárolására.<br />
Az időbélyeg opció az IP cím mellé egy 32 bites időbélyeget is feljegyez. Főként<br />
a router algoritmusok hibakeresésénél hasznos eszköz.<br />
8.2.2. IP címzési rendszer<br />
A címzési módokat az RFC791 (1981) írja le.<br />
Az Ipv4 cím két részből áll:<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
hálózati cím + hoszt cím.<br />
Egy hoszt egyszerre több hálózathoz is csatlakozhat. Ekkor minden hálózatban<br />
külön IP címe van.<br />
A címet megjeleníthetjük binárisan, vagy decimális formában.<br />
170
Szokásos az u.n. "Dotted decimal" formátum. A 32 bit 4 bájtnak felel meg. Minden<br />
bájt decimális értékét írjuk ki, pontokkal elválasztva.<br />
Pl.: 193. 221. 15. 179<br />
Az egy hálózatba tartozó gépek száma igen tág határok között változhat, ezért cím -<br />
osztályokat alakítottak ki. A címosztályoknak az információ továbbítása során is<br />
fontos szerepe van.<br />
A címek adminisztrációját korábban a NIC (Network Information Center) végezte. A<br />
2009-ben elfogadott módosítások (pl. díj ellenében tetszőleges zárótag alkalmazható<br />
a címben) nehezen kezelhető helyzetet hoztak létre. Jelenleg (2010)<br />
Magyarországon a HUNGARNET jogosult címtartományok engedélyezésére.<br />
A címtartomány korlátozottsága miatt (mindössze 32 bit, és ez sem osztható ki<br />
maradéktalanul) belátható időn belül szükség lesz a módosítására az <strong>Internet</strong><br />
rohamos terjedése miatt. Számos javaslat született a megoldásra , és van szabvány<br />
javaslat is (Ipv6), de az áttérés jelentős költségei miatt egyelőre várat magára az<br />
áttörés. Valószínű, hogy az Ipv4 világban Ipv6 szigetek jönnek létre, melyeket a<br />
meglévő kapcsolatokon keresztül alagút jelleggel kapcsolnak össze mindaddig, míg<br />
az Ipv6 általánossá válik.<br />
8.2.3. Címosztályok az Ipv4-ben<br />
A címosztály a cím 1.-5. bitje alapján határozható meg.<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
32 bit<br />
Osztály<br />
A<br />
0 Hálózat<br />
Hoszt<br />
1.0.0.0-tól<br />
127.255.255.255-ig<br />
B 128.0.0.0-tól<br />
10 Hálózat Hoszt<br />
191.255.255.255-ig<br />
C 192.0.0.0-tól<br />
110<br />
Hálózat<br />
Hoszt<br />
223.255.255.255-ig<br />
D 224.0.0.0-tól<br />
1110<br />
Többesküldési cím<br />
239.255.255.255-ig<br />
E 240.0.0.0-tól<br />
11110 Jővőbeni alkalmazásokhoz fenntartva<br />
255.255.255.255-ig<br />
171
A címek egy része speciális célokra foglalt.<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
8.5. ábra IP címosztályok.<br />
A 0.0.0.0 címmel indul minden hoszt, majd a hálózati paraméterek betöltése után<br />
többet nem használja.<br />
A 127.xx.yy.zz címek a visszacsatolások címzésére vannak fenntartva. A 127.0.0.1 a<br />
hoszt saját maga.<br />
A 255.255.255.255 helyi adatszórást jelent. Az adatszórás csak az alhálózaton<br />
belülre szól.<br />
Egy távolabbi hálózatban is végezhetünk adatszórást, ha egy helyes hálózati cím<br />
mögé csupa 1-eket írunk.<br />
Hálózati cím + 11….11<br />
A helyi alhálózatunkban egy hosztot úgy is megcímezhetünk, hogy nem adjuk meg a<br />
teljes címet, csak az alhálózaton belüli hoszt címet.<br />
0000…00 + hoszt cím<br />
Egy HOST-ot egyértelműen azonosít az IP cím. Ha ez igaz, akkor mi szükség van a<br />
címosztályokra? Egyszerűsíti és gyorsítja a csomagok irányítását. A helyi hálózatból<br />
kilépve az eszközök csak a célhálózat elérésével foglalkoznak. A hoszt cím<br />
célhálózaton belüli értelmezésére csak a fogadóoldali router után van szükség. A<br />
címnek a hálózati cím része a címosztályt jelző bitek alapján leválasztható, és a<br />
csomagirányításhoz csak ezt a részt kell használni.<br />
8.2.4. Alhálózatok .<br />
A nagyszámú géppel rendelkező felhasználó hamar szembe kerül azzal a<br />
problémával, hogy a NIC-től szeretne egy összefüggő címtartományt kapni,<br />
ugynakkor ezt a címtartományt szeretné kisebb, külön-külön managelhető<br />
tartományra bontani.<br />
A hálózati cím és a hoszt cím szétválasztására alkalmas eszköz a netmaszk.<br />
A netmaszk a hálózati cím-pozíciókban 1-et, a hoszt - cím helyén Ø-kat<br />
tartalmaz.<br />
172
A címosztály meghatározza, hogy a hálózati cím hány bites. Kívülről csak a<br />
hálózat címezhető,az alhálózatunk nem , mert a továbbított csomagokban nincs<br />
benn a netmaszk. A helyi hálózatunkban azonban valamennyi eszköz tartalmazza<br />
a netmaszk-ot, és így kiderül, hogy a csomag melyik alhálózatnak szól.<br />
A hoszt címeket egy EXOR művelettel választhatjuk le a teljes címből.<br />
(teljes cím) EXOR (netmaszk) = (hoszt cím)<br />
Példaként hozzunk létre alhálózatot egy C osztályú címen belül . Az alhálózat<br />
max. 32 gépet tartalmaz.<br />
A címtartomány legyen: 193.221.15.32 - 193.221.15.63<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
Alhálózat<br />
IP cím Hálózat címe Hoszt cím<br />
193.221.15.32 110 00001 11011101 00001111 001 00000<br />
193.221.15.63 110 00001 11011101 00001111 001 11111<br />
"C" osztályú a cím Hoszt cím a külső hálózat számára<br />
A külső hálózat nem látja az alhálózati maszkot, csak a "C" osztályt ismeri fel!!<br />
Alhálózati maszk 11111111 11111111 11111111 111 00000<br />
Decimálisan: 255.255.255.224<br />
Példa: alhálózati cím leválasztása a 193.221.15.41 címből<br />
Az alhálózat címe: 193.221.15.32<br />
110 00001 11011101 00001111 001 01001<br />
ÉS<br />
11111111 11111111 11111111 111 00000<br />
=<br />
110 00001 11011101 00001111 001 00000<br />
8.6. ábra. Alhálózat címzése<br />
Az alhálózati maszkot valójában a router használja. A kérdés az, hogy egy bejövő<br />
üzenetet melyik kimenetre továbbítja az eszköz. Ha C osztályú címünket 8 db 32<br />
címet tartalmazó részre osztottuk, mint a példánkban, akkor ez azt jelenti, hogy a<br />
bejövő üzeneteket 8 alhálózati szegmens felé tudjuk irányítani. A maszkban az<br />
utolsó nyolc bit 1110 0000. Ennek decimális értéke 224 . A maszk hatására az 1-es<br />
portra kerülnek 0-31 végződésű címek, a 2-es portra 32-63 végződésű címek, és így<br />
tovább. A router kimenetén a teljes cím információ megjelenik. A maszk azt dönti el,<br />
173
hogy melyik kimenetre kerül a csomag. Az alhálózatból érkező csomag esetén a<br />
router azt tudja eldönteni , hogy a célcím az alhálazaton belül, vagy kívül van. Ha<br />
célcím az alhálózaton belül van, akkor routernek nincs tennivalója, nem továbbítja a<br />
csomagot. Ha nem az adott alhálózathoz tartozó forráscímet tartalmazó csomagot<br />
kap, azt szintén nem továbbítja.<br />
Maszk 255.255.255.224 11111111 11111111 11111111 111 00000<br />
Cím ÉS 193.225.11.15 11000001 11011101 00001111 000 01111<br />
11000001 11011101 00001111 000 00000<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
A csomagot az 1-es portra továbbítja<br />
Maszk 255.255.255.224 11111111 11111111 11111111 111 00000<br />
Cím ÉS 193.225.11. 36 11000001 11011101 00001111 001 00100<br />
11000001 11011101 00001111 001 00000<br />
A csomagot az 2-es portra továbbítja<br />
Maszk 255.255.255.224 11111111 11111111 11111111 111 00000<br />
Cím ÉS 193.225.11.152 11000001 11011101 00001111 100 11000<br />
11000001 11011101 00001111 100 00000<br />
A csomagot az 5-ös portra továbbítja<br />
Ha a tartományt csak 2 részre szeretnénk osztani, akkor a HOST címből egy bitet<br />
kell csak elvennünk.<br />
A maszk utolsó 8 bitje ekkor 1000 0000. A teljes maszk decimálisan<br />
255.255.255.128.<br />
A címtartományok részekre osztásának a B osztályú címeknél van igazán<br />
jelentősége. Egy nagyvállalat a B osztályú címtartományát szabadon oszthatja fel,<br />
változtathatja anélkül, hogy a NIC-hez kellene fordulnia.<br />
8.2.5. Az IP új generációja: IPv6<br />
A fejlesztés céljai:<br />
Nagyszámú hoszt támogatása (>10 12 )<br />
Forgalomirányító táblázatok méretének csökkentése<br />
Protokollok egyszerűsítése, gyorsabb feldolgozás a routereken<br />
Hitelesség és titkosság biztosítása<br />
Jobb alkalmazkodás a szolgáltatás típusához , valós idejű adatok jobb<br />
kezelése<br />
Többesküldés lehetősége, hatósugarak megadásának lehetősége<br />
Mozgó hosztok jobb támogatása<br />
174
IPv4 és IPv6 együttélésének biztosítása hosszabb távon is.<br />
A fejlesztés 1992-1997 között folyt intenzíven. A javaslatban az eredeti<br />
megnevezése „Simple <strong>Internet</strong> Protocol Plus” volt. Az IPv6 jelölést azért kapta, mert<br />
az IPv5 már foglalt volt egy kísérleti fejlesztés számára.<br />
Az IPv6 nem kompatíbilis az IPv4-el, de a protokollok legnagyobb részével igen<br />
(TCP, UDP, ICMP, IGMP, OSFP, BGP és DNS). A hálózat vezérlésével és a<br />
névfeloldással kapcsolatos protokollok tehát kompatibilisek.<br />
Az IPv6 föbb tulajdonságai:<br />
128 bitre növelt címtartomány. Új címzési séma.<br />
Hatékonyabb és flexibilisebb csomagformátum, egyszerűbb fejrész<br />
A továbbfejlesztés lehetősége az opcionális fejrészek bevezetésével<br />
A biztonsági mechanizmusok beépültek a protokollba (hitelesítés, titkosítás)<br />
Névfeloldás és a csoportmenedzsment része a protokollnak<br />
Az ARP (Address Resolution Protocol) és az IGMP (<strong>Internet</strong> Group<br />
Management Protocol) kikerült a rendszerből.<br />
Szolgáltatások a jobb támogatása<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
32 bit<br />
verzió prioritás folyamatcímke<br />
Adat mező hossza Következő fejrész Átugrás korlát<br />
Forrás címe (16 byte)<br />
Cél címe (16 byte)<br />
8.7.ábra. IPv6 fejrész<br />
175
A verzió mező az IPv4-nél mindig 4, az IPv6-nál mindig 6.<br />
A prioritás mezőben a 0-7 értékek olyan alkalmazásokhoz tartoznak, melyek képesek<br />
lassítani egy esetleges torlódásnál. A 8-15 értékek real-time folyamatokhoz<br />
tartoznak. Ezek az alkalmazások akkor sem lassítanak, ha minden csomag elvész.<br />
(Élő beszéd, mozgókép). Az alkalmazás szintjén természetesen más a helyzet. Egy<br />
videó átvitelnél esetleg tudom rontani a képpontok számát, a színmélységet, a<br />
képváltások számát, stb. Ez azonban nem a hálózat feladata, és nem is tudja<br />
befolyásolni. Mindkét csoporton belül az alacsonyabb szám alacsonyabb prioritást<br />
jelent.<br />
A folyamatcímke címke a virtuális áramkörök előnyei próbálja „becsempészni” a<br />
datagram típusú rendszerekbe. Az összeköttetést a forrás és célcím, valamint a<br />
folyamatcímke együttesen azonosítja. Ez lehetővé teszi, hogy több folyamat legyen<br />
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<br />
rendelhetünk a routerekben , ami hasonló hatású lehet, mint a virtuális áramkörök<br />
létrehozása.<br />
Az adatmező hossza a tényleges adatmező hosszát jelöli, nem számolják bele a 40<br />
byte hosszú fejrészt ( IPv4-nél bele számít!).<br />
A következő fejrész azt mutatja , hogy milyen további opcionális fejrészek vannak a<br />
csomagban, ha vannak. Az opcionális fejrész bevezetése tette lehetővé a kötelező<br />
fejrész jelentős egyszerűsítését. A kiegészítő fejrészek az<br />
átugrási opciókra<br />
forgalomirányításra<br />
darbolásra<br />
hitelesítésre<br />
titkosítottságra<br />
cél opciókra<br />
vonatkozhatnak.<br />
Az átugrás korlát itt valóban az ugrások számát jelöli , nem tartalmaz időt.<br />
A címek 16 byte, azaz 128 bit hosszúságúak. A címmező rossz kihasználása esetén<br />
is belátható ideig elég a címtartomány.<br />
Az IPv6 - ból kimaradt az ellenőrzőösszeg, ami jelentősen csökkenti a routerek<br />
terhelését, és a felettes rétegeket sem terheli túlságosan az ellenőrzés a mai,<br />
viszonylag megbízható fizikai réteg felett.<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
176
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
177
8.2.6. Az <strong>Internet</strong> szállítási protokolljai<br />
TCP - Transmission Control Protocol<br />
A protokollt kezdettől fogva sok hálózat összekapcsolására tervezték. Feltételezték,<br />
hogy az adattovábbítás megbízhatatlan, és a közbenső csomópontok<br />
meghibásodhatnak, megsemmisülhetnek. A modellt TCP/IP néven 1974-ben<br />
definiálták.<br />
A TCP összeköttetés orientált protokoll. Alapvetően a korábban tárgyalt 3-utas<br />
kézfogás módszerét használja. Feltételezi, hogy az alatta lévő hálózat<br />
megbízhatatlan (OSI terminológia szerint C-osztályú) összeköttetést nyújt, és a TCP<br />
feladata, hogy a csomagok hibátlanságát és helyes sorrendjét biztosítsa.<br />
A TCP tartalmaz nyugtázást, így azokon a hálózatokon, ahol jelentős a késleltetés,<br />
az adatkapcsolati rétegben valamilyen csúszóablakos protokollt használnak a<br />
hatásfok javítása érdekében.<br />
A TCP az IP hálózati protokoll ( IPv 4 vagy IPv 6 ) felett fut, használja a<br />
szolgáltatásait. Az IP felett azonban más protokollok is használatosak ( UDP,<br />
ICMP,…).<br />
A TCP tetszőleges hosszúságú adatokat fogad az alkalmazásoktól. Ezeket max. 64<br />
kbyte hosszú darabokra (szegmensekre) tördeli. A darabokat független datagramként<br />
továbbítja a hálózaton. A kommunikáció alapvetően "szegmensekben " történik. Egy<br />
szegmensnek a TCP fejrésszel együtt bele kell férni az IP 65536 bájtos<br />
adatmezejébe. A hálózatban lévő eszközök (router, gateway) a maximális hosszt<br />
tovább korlátozzák. A szegmensek hossza általában jóval rövidebb a maximális 64<br />
kbyte-nál, néhány ezer bájt szokott lenni.<br />
A szegmens hossza valójában a hálózatban átvihető leghosszabb adategységhez<br />
(Maximum Transfer Unit) illeszkedik. Előfordulhat , hogy a hálózat különböző részein<br />
ez eltérő, és egy szakaszán az MTU rövidebb, mint a szegmens hossza. Ilyen<br />
esetben feldaraboljuk a szegmenst, és minden darabot önálló IP csomagként<br />
továbbítunk. A rövidebb szegmensekhez kapcsolódó IP fejrészek jelentős<br />
többletterhet jelentenek a hálózatnak.<br />
A TCP-ben minden byte-nak sorszáma van. A 32 bájtos sorszám elegendően nagy<br />
ahhoz, hogy a kettőződést elkerüljük a többszörös beérkezések esetén.<br />
A körülfordulási idő 100 Mbit/sec sebességű hálózaton is nagyobb mint 6 perc.<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
178
A TCP fejrész a valóságban kiegészül még egy pszeudofejrésszel. A pszeudofejrész<br />
az IP-hez tartozó adatokat tartalmaz. A szerepe az, hogy a tévesen továbbított<br />
csomagok könnyebben detektálhatók legyenek.<br />
A TCP szegmens fejrésze:<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
0<br />
32 bit<br />
Source IP address Pseudo<br />
Destination IP address header<br />
Protocol(6) TCP segmenth lenght<br />
Source TCP port Destination TCP port<br />
Sequence number TCP<br />
Acknowledgement number header<br />
Hdr.l. Flags Window size<br />
Checksum Urgent pointer<br />
Options<br />
Data<br />
Flags<br />
URG ACK PSH RST SYN FIN<br />
8.8. ábra. TCP fejrész felépítése<br />
A forrásport (source port) és a célport (destination port) szolgáltatásokat<br />
azonosítanak. Minden hoszt részben szabadon dönt a portok és a szolgáltatások<br />
ö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<br />
és az IP cím együtt alkotja a 48 bites TSAP címet.<br />
A TCP bájtonként sorszámoz. A sorszám (sequence number) a szegmens első<br />
bájtjának sorszáma. A nyugtaszám (acknowledgement) mező a következő várt bájt<br />
(az utolsó helyesen vett sorszáma + 1) sorszámát tartalmazza.<br />
A TCP fejrész hossz (TCP header lenght) megadja, hogy hány 32 bites szóból áll a<br />
fejrész ( a pszeudofejrész nélkül).<br />
A fejrész hossza az opciók miatt változik, így meg kell adnunk a hosszát, hogy az<br />
adatmező kezdete ismert legyen.<br />
Ezt követi egy 6 bites használaton kívüli rész, majd a jelzőbitek (flags) következnek.<br />
Flags:<br />
179
URG = 1 ha használunk sürgősségi mutatót. A sürgősségi mutató a sürgős rész<br />
helyét jelöli a sorszám mezőhöz képest. Az URG szerepe hasonló, mint a<br />
megszakításé a programok futása közben.<br />
ACK = 1 értéke azt jelzi, hogy a szegmens nyugtát tartalmaz. Ha az értéke 0, akkor a<br />
nyugtamező figyelmen kívül hagyható.<br />
PSH = 1 (PUSH) azt kéri a vevőtől, hogy az adatokat pufferelés nélkül továbbítsa az<br />
alkalmazásnak.<br />
RST = 1 Restart. Ha az összeköttetés összeomlott, vagy valami más rendellenesség<br />
történt, akkor tartalmaz a szegmens RST=1-et. Ha ilyet veszünk, fel kell készülni<br />
valami rendkívüli esemény kezelésére.<br />
SYN bit-nek az összeköttetés felépítésekor van szerepe. Valójában az ACK-val<br />
együttesen van értelme. Ha SYN=1, ACK=0 akkor ez valójában egy CONNECTION<br />
REQVEST kérés. A SYN=1, ACK=1 a CONNECTION ACCEPTED-nek felel meg.<br />
FIN bit az összeköttetés bontására szolgál.<br />
Az ablakméret (windows size) mező azt jelzi, hogy a nyugtában szereplő bájttal<br />
kezdődően hány bájtot küldhetünk el. Az ablakméret a csúszóablakos protokollnál<br />
tárgyaltaknak felel meg. Ez egy változó méretű csúszó ablak. A Ø hossz is<br />
értelmezett. Azt jelenti, hogy a vevő az adás felfüggesztését kéri.<br />
Az ellenőrzőösszeg (Checksum) számításába a pszeudofejrész, a fejrész és az<br />
adatmezők is beleszámítanak. Az ellenőrző összeg képzése 16 bites 1-es<br />
komplemens összeadással történik. Az adatmezőt, ha nem páros számú bájtot<br />
tartalmaz, páros számúra egészítjük ki. A kapott összeg 1-es komplemensét véve<br />
kapjuk az ellenőrző összeget.<br />
A vevő oldalon elvégezve az összeadást a teljes szegmensre 0-t kell kapnunk.<br />
Az opciók (Options) mezőt elsősorban a vevő által elfogadható legnagyobb TCP<br />
adatmező méretének meghatározására szokták használni.<br />
A nagy sebességű és nagy késleltetésű vonalakon a 64 Kbyte nem elegendően nagy<br />
ablak. Egy műholdas csatornában (50Mbit/sec) a 64 Kbyte továbbítása 10 msec<br />
körüli időt vesz igénybe. A vonali késleltetés minimálisan 2*270 msec a nyugta<br />
megérkezéséig. A hatásfok tehát katasztrófális. A hatásfok javítható lenne az ablak<br />
hosszának növelésével. Javaslatok vannak a nagyobb (legfeljebb 2 30 ) méretű ablak<br />
használatára. A legtöbb TCP implementáció ma már megengedi és támogatja a<br />
nagyméretű szegmensek átvitelét.<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
180
UDP (User Datagram Protocol)<br />
Az UDP az <strong>Internet</strong> összeköttetés nélküli szállítási protokollja. IP datagramok<br />
küldését teszi lehetővé összeköttetés létesítése nélkül. Jóval egyszerűbb mint a<br />
TCP.<br />
Használata ott célszerű, ahol egy kérésre egyetlen válasz érkezik, és a<br />
nyugtázásnak nincs jelentősége. Pl.: ha elküldünk egy ARP kérést (lásd 8.2.5),<br />
felesleges nyugtázni, mert ha megkaptuk a választ, akkor a nyugta nélkül is biztos,<br />
hogy a kérés célba érkezett.<br />
Ha nem, akkor egy időzítés lejárta után a kérés újbóli elküldése az egyetlen<br />
lehetséges lépés, tehát a nyugta itt is felesleges.<br />
Az összeköttetés lebontása és felépítése elmarad, a fejléc is lényegesen<br />
egyszerűbb.<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
0<br />
32 bit<br />
Source IP address Pseudo<br />
Destination IP address header<br />
Protocol(6) UDP segmenth lenght<br />
Source UDP port Destination UDP port UDP<br />
UDP Message lenght UDP Checksum header<br />
Data<br />
8.9. ábra.UDP csomag felépítése<br />
A pszeudofejrész az ellenőrző összeg számításakor beleszámít a fejrészbe. Az UDP<br />
szegmens hossz a fejrész és az adatrész együttes hosszát adja meg.<br />
A forrás és a célport a hosztokon belül azonosítja a végpontokat (szolgáltatásokat).<br />
Az UDP-t az RFC 768-ban találjuk meg részletesen.<br />
181
8.2.7. Az <strong>Internet</strong> vezérlő protokolljai<br />
ICMP<br />
Az ICMP (<strong>Internet</strong> Control Message Protocol) <strong>Internet</strong> vezérlőüzenet protokoll az<br />
<strong>Internet</strong> felügyeletét szolgálja. Összesen mintegy tucatnyi üzenetet definiáltak. Az<br />
üzeneteket főként routerek hozzák létre. A visszhang és időbélyeg kérést indíthatja<br />
egy hoszt is.<br />
A fontosabb ICMP üzenetek:<br />
DESTINATION UNREACHABLE Cél elérhetetlen<br />
TIME EXCEEDED Időtúllépés<br />
PARAMETER PROBLEM Paraméter probléma<br />
SOURCE QUENCH Forrás lefojtás<br />
REDIRECT Újrairányítás<br />
ECHO REQUEST Viszhang kérés<br />
TIMESTAMP REQUEST Időbélyeg kérés<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
8.10. ábra. ICMP üzenetek<br />
A CÉL ELÉRHETETLEN üzenet akkor keletkezik, ha a router nem találja a célt, vagy<br />
ha olyan üzenetet kapott, ahol áll a DF bit, és a hálózat nem tud akkora csomagot<br />
kezelni, mint a beérkezett.<br />
IDŐTÚLLÉPÉS üzenetet akkor küld a router, ha a csomag élettartam mezője elérte a<br />
nullát. (Torlódás van, hurokba került a csomag, túl alacsony a beállított élettatam).<br />
PARAMÉTER PROBLÉMA üzenet az IP fejrész hibáját jelzi. Rendszerint valamelyik<br />
router szoftver hibája okozza.<br />
FORRÁSLEFOJTÁS üzenetet a túl sok csomagot küldő hosztok kapnak, hogy<br />
lassítsanak. Az új forgalomirányító algoritmusok nem használják. (A<br />
forgalomszabályozás a szállítási rétegben történik.)<br />
182
ÚJRAIRÁNYÍTÁS üzenetet akkor küld a router, ha a csomag rosszul irányítottnak<br />
tűnik. (Teljesen rossz földrajzi irány.)<br />
VISSZHANG KÉRÉS és VISSZHANG VÁLASZ üzenetek egy hoszt elérhetőségének<br />
tesztelésére használhatók.<br />
Az IDŐBÉLYEG KÉRÉS és IDŐBÉLYEG VÁLASZ üzenet a hoszt elérhetőségén túl<br />
a hálózat teljesítményét is méri. Az üzenet érkezési ideje és a válasz indulási ideje is<br />
szerepel a válaszban.<br />
Az ICMP teljes definíciója az RFC 792-ben található.<br />
ARP (Adress Resolution Protocol)<br />
Minden <strong>Internet</strong>re csatlakozó gépnek van legalább egy IP címe. Az IP cím logikai<br />
cím, amit az interface hardvere nem ért meg. Az IP címeket le kell fordítanunk az<br />
adatkapcsolati réteg számára érthető fizikai címekre.<br />
Az összerendelést elvileg megoldhatnánk táblázatokkal is, de a gyakorlat számára ez<br />
túl nehézkes megoldás, és nem követi a hálózat változásait. (Bekapcsolnak,<br />
kikapcsolnak gépeket, hálózati szegmenseket,)<br />
A másik nehézség abból adódik, hogy távoli hálózatokban lévő gépeket is meg<br />
akarunk szólítani, amelyeknek a fizikai címét nem ismerjük<br />
A megoldást nézzük meg egy egyszerű hálózaton:<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
WAN<br />
Router3<br />
193.16.35.2 193.16.35.3<br />
193.16.35.1 193.16.35.4<br />
Router1 Router2<br />
193.6.52.254 193.225.18.254<br />
193.6.52.11 193.6.52.19 193.6.52.193 193.225.18.2 193.225.18.7<br />
d31.pte.hu geniusz.pte.hu k19.pte.hu<br />
ETHERNET1 ETHERNET2<br />
8.11.ábra. Összekapcsolt C osztályú hálózatok<br />
183
Fel kell tételeznünk, hogy a küldő ismeri a cél címét. A cím egy hierarchikusan<br />
felépített szöveges elem, pl.: geniusz.pte.hu<br />
A névhez a "Domain Name System" (körzetnév kezelő rendszer) fogja visszaadni az<br />
IP címet. A példánkban 193.225.18.2-őt.<br />
(A DNS rendszer ismertetése a 8.3. fejezetben.)<br />
A küldő gép az IP cím ismeretében kiadhat az alhálózatra egy adatszórást:<br />
"kié a 193.225.18.2 cím ?" Az adatszórás természetesen ETHERNET szintű, tehát<br />
fizikai cím szerinti adatszórás. A kérés tartalmazza a kérdező gép fizikai címét is.<br />
A magát felismerő címzett eltárolja a kérő fizikai címét, majd elküldi a saját fizikai<br />
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<br />
elküldi az üzenetet. Látnunk kell, hogy az ETHERNET alhálózatban a keretek csak<br />
fizikai címekre küldhetők. A kérdés és válasz lebonyolítását végző protokoll az ARP.<br />
A protokollt az RFC 826 definiálja.<br />
Valamivel bonyolultabb a helyzet akkor, ha a küldő és a címzett nem ugyanabban az<br />
alhálózatban van. A küldő például a d31.pte.hu. Ekkor a küldő miután visszakapta az<br />
IP címet, látja, hogy a cél egy távolabbi hálózatban van. Ekkor az adatkeretet elküldi<br />
egy az alhálózaton belüli fix ETHERNET címre, a routernek az alhálózathoz<br />
csatlakozó fizikai címére. Minden, az alhálózaton kívülre címzett üzenetet ide kell<br />
küldenünk (Default router).<br />
Az IP hálózat feladata, hogy eljuttassa a megfelelő alhálózatig a csomagot. Az<br />
alhálózaton belül az ottani router fogja megkeresni a fizikai címet, és továbbítani a<br />
keretet.<br />
A hálózat minden eleme tart fenn táblázatokat, melybe a címfeloldással kapcsolatos<br />
adatokat bejegyzi. Az adatok gyors-tárba kerülnek és egy ideig megőrződnek. Ez a<br />
módszer csökkenti a hálózati forgalmat, és gyorsítja a címek megtalálását.<br />
RARP (Reverse Addres Resolution Protocol)<br />
Szükség lehet a korábban tárgyalt ARP fordítottjára is. Fizikai címhez kereshetünk IP<br />
címet. Egy diszk nélküli állomás indulásakor adatszórással megkérdezi, hogy az<br />
állomás fizikai címéhez ki tud egy IP címet.<br />
A RARP szerver kikeresi a táblázatából az IP címet, és elküldi az ismert fizikai címre.<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
184
A RARP csupa 1-ből álló címet tud csak adatszóráskor megadni, tehát az adatszórás<br />
lokális. A kérést a routerek nem továbbítják. Emiatt minden alhálózaton kell lenni egy<br />
RARP szervernek. Nem biztos, hogy minden alhálózatban van szerver, és ha nincs,<br />
a megoldás nem működik. A probléma megkerülésére használják a BOOTP<br />
protokollt. Ez UDP üzeneteket használ, amit a routerek továbbítanak, és nem<br />
szükséges minden hálózati szegmensben egy RARP szerver.<br />
A RARP definícióját az RFC 903, a BOOTP részleteit az RFC 951 írja le.<br />
8.3. DNS (Domain Name System) Körzeti névkezelő rendszer.<br />
A hálózati eszközök bináris címeket ismernek. A legtöbb ember számára az értelmes<br />
nevek, vagy rövidítések is sokkal jobban megjegyezhetők, mint a bináris címek.<br />
Szükség van tehát a kétféle ábrázolásmód kölcsönös megfeleltetésére.<br />
Maguk a nevek is gondot okoznak, hiszen az azonos nevek okozta konfliktusok csak<br />
valamilyen központi nyilvántartással, vagy hierarchikus rendszerrel oldhatók meg.<br />
A hierarchikus megoldás nagyszámú cím esetén nyilvánvalóan egyszerűbb, és<br />
működőképesebb megoldás.<br />
Egy tipikusan hierarchikus cím a lakcímünk is. A legtöbb faluban, városban van<br />
Petőfi utca. Ennek ellenére könnyen kiválaszthatjuk, hogy melyikről van szó, ha<br />
szerepel a helység neve is a címzésben.<br />
Az egyes elemeket ponttal elválasztva az alábbi alakja lehetne a címnek:<br />
név.házszám.utca.város.ország<br />
Hasonló az <strong>Internet</strong> címzése is, a DNS névtér.<br />
8.3.1 DNS névtér<br />
Az <strong>Internet</strong> a lehetséges címek halmazát néhány száz elsődleges körzetre (domain)<br />
bontja. Minden körzet további alkörzetekre bontható, egészen addig, míg a fa<br />
leveleiként eljutunk a hosztokig.<br />
A legfelső szinten lévő elsődleges körzetek kétfélék lehetnek:<br />
általános körzetek<br />
országok<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
185
Az általános körzeteket az USA-n belül használják a különböző szervezetek<br />
megkülönböztetésére.<br />
Ilyenek a com (kereskedelem), edu (<strong>oktat</strong>ási intézmények), mil (USA fegyveres erői),<br />
org (non-profit szervezetek), stb.<br />
A felosztást az ISO 3166 tartalmazza.<br />
A körzetek egy névtelen gyökérhez kapcsolódnak. A hierarchikus felépítésből<br />
adódóan névkonfliktusok földrajzilag kis területen , egy alkörzeten belül<br />
fordulhatnak elő, és ott könnyen megoldhatók.<br />
Root<br />
szerverek<br />
Általános O rszágok<br />
com int edu gov m il org… .. hu de nl… … ..<br />
hp yale pte axelero tu-bs<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
cs eng m it ktk cs adm bib<br />
ai m i-<strong>oktat</strong> k-229 ibr robots<br />
golem<br />
8.12. ábra. DNS névtér<br />
A körzetnevekben a kisbetűs és nagybetűs írásmód között nincs különbség.<br />
schoenw new<br />
A névkomponensek maximális hossza 63 karakter. A teljes útvonalnév rövidebb vagy<br />
egyenlő 255 karakterrel. Minden körzet maga ellenőrzi az alatta lévő körzeteket, így<br />
elkerülhető egy végtelen méretű központi nyilvántartás létrehozása. Egy új körzet<br />
létrehozását az a körzet engedélyezheti, ahova tartozni fog.<br />
Az elnevezések a szervezeti hierarchiához igazodnak, nem követik a hálózat fizikai<br />
felépítését.<br />
8.3.2 Erőforrás nyilvántartás<br />
A név-IP cím megfeleltetésen túl is van szükség adatokra az <strong>Internet</strong><br />
üzemeltetéséhez. Minden körzethez tartozik egy erőforrás rekord halmaz.<br />
Szélsőséges esetben az erőforrás bejegyzés lehet egyetlen IP cím, ha egyetlen gép<br />
van a körzetben, de számos más bejegyzés is létezhet.<br />
Egy általános erőforrás rekord:<br />
186
Körzet_név Élettartam Osztály Típus Érték<br />
Az erőforrás rekordok ASC II formátumban tárolja a Domain Name Server.<br />
A Körzet_név azt a körzetet jelenti, amihez a rekord tartozik. A legtöbb esetben egy<br />
körzethez sok rekord tartozik. Az adatbázisban a zóna ( több körzet, részletesebben<br />
8.3.3.fejezet) adatai szerepelnek, és a körzet_név az elsődleges kulcs.<br />
Az Élettartam mező a bejegyzés stabilitására utal. A legmagasabb érték 86400, ami<br />
egy nap másodpercekben kifejezve. Azt mutatja, hogy az adott rekord meddig marad<br />
a cache-tárban. Az instabil bejegyzések rövid ideig maradnak a cache-tárban. A<br />
"rövid idő" 60 másodperc körüli értéket jelent.<br />
Az Osztály a hálózattípusokat különbözteti meg. Az <strong>Internet</strong>hez tartozó<br />
információknál, tehát majdnem mindig "IN".<br />
A Típus mező az információ jellegére utal.<br />
A legfontosabb típusok:<br />
SOA a lista kezdete A zónához tartozó névsorról tárol információkat, az<br />
adminisztrátor e-mail címét, egy egyedi sorozatszámot, jelzőket és időzítők<br />
értékeit adja meg.<br />
Az A(ddres) egy 32 bites IP cím egy hoszthoz.<br />
MX tartalmazza a körzethez tartozó levelek fogadására alkalmas gépek nevét. A név<br />
előtt egy sorszám van, ami a kézbesítési sorrendet jelöli. Elsőnek az 1-es számú<br />
gépnek próbálja meg az e.-mail-ek továbbítását. Ha nem működik, akkor a 2-es<br />
számú gépnek, és így tovább, amíg van levelező szerver a listán.<br />
NS névszerver rekord<br />
A névfeloldás működéséhez minden DNS adatbázis tárol az összes elsődleges<br />
körzet DNS szerveréhez egy rekordot, és további névszerverek adatait is<br />
tárolhatja. A névfeloldás részletesebb vizsgálatánál látni fogjuk ennek szerepét.<br />
CNAME bejegyzések álneveket takarnak. Ha megváltozik a körzetnevünk, akkor<br />
célszerű a régi nevet álnévként megadni. Korábban a PTE-en belül használtuk a<br />
PMMF alkörzetet is. Ha megadjuk a CNAME rekordot, akkor a régi nevén is meg<br />
fogják találni a hosztot. Például:<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
187
almos.pmmf.pte.hu 86400 IN CNAME almos.pte.hu<br />
PRT álnév egy IP-címhez<br />
HINFO hoszt leírás. A számítógép típusára és az operációs rendszerre utal.<br />
TXT szöveges leírás. A számítógépek nem használják, csak az emberek számára<br />
teszi olvasmányosabbá az állományt.<br />
Érték mező tartalmazhat számot, vagy ASCII karakterláncot.<br />
Néhány példa a bejegyzésekre:<br />
Az atlas.pte.hu egy szerver, a K_32401 pedig egy munkaállomás. Ez egy<br />
részlet az adatbázisból.<br />
.……………..<br />
atlas.pte.hu 86400 IN HINFO IBM UNIX<br />
atlas.pte.hu 86400 IN A 193.225.18.2<br />
atlas.pte.hu 86400 IN MX atlas.pte.hu<br />
K_32401.pte.hu IN A 193.225.18.61<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
IN MX atlas.pte.hu<br />
IN HINFO IBM windows<br />
A K_32401 gép bejegyzéséből látszik, hogy közvetlenül nem fogad leveleket, a<br />
létrehozott levelező fiókoknak szóló üzenetek az atlas.pte.hu gépen fognak tárolódni.<br />
Az elsődleges körzetek adatai nem szerepelnek az adatbázisban. Ezeket egy<br />
konfigurációs fájl tartalmazza, ami a DNS szerver indításakor betöltődik a gyorsító<br />
tárba. A fájl szerkezete hasonló, mint az egyéb erőforrás bejegyzések.<br />
$ORIGIN RootServerInfo<br />
@SOA server.root. (1997082000 3600 604800 86400)<br />
…….<br />
; formerly NS.INTERNIC.NET<br />
3600000 NS A.ROOT-SERVERS.NET.<br />
3600000 NS B.ROOT-SERVERS.NET.<br />
3600000 NS C.ROOT-SERVERS.NET.<br />
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4<br />
; formerly NS1.ISI.EDU<br />
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107<br />
188
………………….<br />
; housed in Japan, operated by WIDE<br />
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33<br />
8.3.3 Név szerverek (Domain Name Servers)<br />
Tisztán logikailag az egész névtérnek egyetlen DNS szervere is lehetne, ahol a teljes<br />
adatbázist tároljuk. Ez a megoldás sem a hálózati forgalom, sem a biztonság, sem az<br />
adminisztráció szempontjából nem elfogadható.<br />
A névteret ezért egymást át nem fedő zónákra osztják. Egy zónában több név<br />
szerver van a megbízhatóság növelése érdekében. A zónában egy elsődleges, és<br />
egy vagy több másodlagos név szerver van. A másodlagos név szerverek másolatai<br />
a primer név szervernek. Módosításokat csak a primer név szerveren lehet<br />
végrehajtani. A módosítások automatikusan másolódnak a másodlagos szerverekre.<br />
Szerepük a terhelés megosztása, és a biztonság növelése.<br />
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<br />
zóna adminisztrátortól függ. A terheléselosztás és a menedzselés szempontjai a<br />
meghatározók.<br />
Általános Országok<br />
com int edu gov mil org….. hu de nl……..<br />
hp yale pte axelero tu-bs<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
cs eng mit ktk cs adm bib<br />
ai mi-<strong>oktat</strong> k-229 ibr robots<br />
golem<br />
8.13.ábra. DNS névtér egy része a zónák jelölésével<br />
schoenw new<br />
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<br />
szervert üzemeltet. (A példák csak az elvet szemléltetik, nem hitlesek!)<br />
Ha egy címfeloldó szeretne tudni valamit egy körzetnévről, akkor elküldi a kérdést<br />
egy helyi név szervernek. Ha a körzet az adott szerverhez tartozik, akkor az<br />
visszaküldi a hiteles erőforrás bejegyzéseket. A hiteles bejegyzés (authoritative<br />
189
ecord) azt jelenti, hogy a bejegyzés attól a szervertől származik, amelyik a<br />
bejegyzést kezeli. Egy a gyors-tárban lévő adat lehet elavult is , de ez az adat<br />
biztosan meg fog egyezni a diszken tárolt adattal, hiteles.<br />
A kérdések azonban távoli körzetekre is irányulhatnak, és ekkor a folyamat<br />
bonyolultabb. A lekérdezés alapvető típusai a 8.14. ábrán láthatók.<br />
A rekurzív lekérdezéses módszernél a szerver ha nem rendelkezik megfelelő<br />
információval a célról, továbbadja egy másik szervernek, amíg eléri a hiteles<br />
bejegyzést. A példában andi.pte.hu fordul a lokális szerverhez, az a "hu" elsődleges<br />
körzet szerveréhez.<br />
A "hu" ismeri a bme.hu címét, és ez a szerver hitelesen tárolja a peter.bme.hu címét,<br />
visszakapjuk a hiteles bejegyzést a peter.bme.hu gépről.<br />
Az iteratív lekérdezésnél ha a lokális keresés sikertelen, akkor annak a szervernek a<br />
címét kapjuk vissza, ahol a legközelebb próbálkozhatunk. Ennél a módszernél az<br />
andi.pte.hu elsőnek a "hu" szerver címét kapja vissza. A hu szervertől megkapja a<br />
bme.hu címét, ami rendelkezik a peter.bme.hu hiteles bejegyzésével.<br />
pte.hu<br />
andi.pte.hu<br />
hu<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
Recursive Query Iterative Query<br />
root Name Server<br />
bme.hu<br />
peter.bme.hu<br />
pte.hu<br />
2(Rfr)<br />
andi.pte.hu<br />
hu<br />
root Name Server<br />
Name Server Name Server Name Server<br />
Name Server<br />
(authoritative)<br />
(authoritative)<br />
1(Q)<br />
2(Q)<br />
5(R)<br />
6(R)<br />
4(R)<br />
3(Q)<br />
1(Q)<br />
8.14. ábra. Alapvető DNS lekérdezési formák<br />
3(Q)<br />
5(Q)<br />
4(Rfr)<br />
6(R)<br />
bme.hu<br />
peter.bme.hu<br />
190
ceg.hu NS<br />
(intermediate)<br />
Cache<br />
2(Q)<br />
1(Q)<br />
Pandur B: Számítógép hálózatok.<br />
2004-2010<br />
teve.reszleg.ceg.hu<br />
3(Q)<br />
4(Rfr)<br />
5(Q)<br />
data base 8(R)<br />
data base<br />
Cache<br />
data base<br />
Cache<br />
data base<br />
9(R)<br />
reszleg.ceg.hu NS<br />
(local NS)<br />
10(R)<br />
root Name Server<br />
Cache<br />
data base<br />
tu.de NS<br />
(intermediate)<br />
6(Q)<br />
7(R)<br />
andi.cs.tu.de<br />
Kérdés: mi az IP címe az andi.cs.tu.de hosztnak?<br />
Cache<br />
cs.tu.de NS<br />
(authoritative)<br />
8.15. ábra. Rekurzív és interaktív keresés együttes használata<br />
Q= Query<br />
R= Response<br />
Rfr= Referral<br />
Távoli címek keresésénél a két módszer kombinációja hatékony (8.15.ábra).<br />
A teve.reszleg.ceg.hu hosztról keressük andi-t, egy német egyetem informatikai<br />
tanszékén. A cím: andi.cs.tu.de. Rekurzív kereséssel jutunk el egy root szerverhez.<br />
A ceg.hu szerver ismeri a de primer körzet név szerverének címét (betöltötte a<br />
konfigurációs fájlból), ahonnan megkapja a tu.de szerver címét (interaktív keresés).<br />
A tu.de rekurzívan megkeresi a cs.tu.de szervert, ahonnan megkapja a hiteles<br />
bejegyzést, és visszaküldi a cég.hu szervernek, ahonnan eljut a teve.reszleg.ceg.hu<br />
gépig.<br />
Ha végiggondoljuk a keresés lépéseit, belátható, hogy ezzel a módszerrel terheljük<br />
legkevésbé a nagy forgalmú nemzetközi hálózatot.<br />
A keresési típusok beállítása a Name Server-t üzemeltető adminisztrátor feladata.<br />
Belátható, hogy a jó konfiguráció jelentősen gyorsíthatja a rendszer működését, vagy<br />
egy ügyetlenebb beállítás jelentős erőforrásokat köthet le.<br />
191
Change language