Hálózati architektúrák és protokollok Gazdasági informatikusoknak
Utolsó szerkesztés: 2010. Aug. 27 Végh János (
[email protected])
i
Hálózati architektúrák és protokollok
ii
Tartalomjegyzék I. Kezd® könyv
1
1. Bevezet®
1
1.1.
Bevezetés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2.
Fogalmak és jelölések . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3.
Hagyományos és internetes szolgáltatás
3
. . . . . . . . . . . . . . . . . . . . . . .
2. Hálózatok 2.1.
2.2.
2.3.
2.4.
4
Az adatkommunikációs alapvetés
. . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1.
Kommunikációs fogalmak
. . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.2.
Átviteli módok
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.3.
Rétegelt architektúra . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Hálózati alapfogalmak
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1.
Strukturális és m¶ködési modellek . . . . . . . . . . . . . . . . . . . . . .
7
2.2.2.
Hálózati címzés
9
2.2.3.
Kapcsolatmentes és kapcsolat-alapú protokoll
2.2.4.
Adatcsomagolás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A hálózat megvalósítása
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hálózat-speci kus rétegmodellek . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.2.
Hálózati hardver
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.3.
Hálózati szoftver
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
A hálózati szolgáltatás 2.4.1.
Számítógépünkben
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.2.
Szolgáltatóknál
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
17
A hálózat 7-réteg¶ OSI modellje . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Alkalmazási 4.1. 4.2.
4.3.
4.4.
4.5.
12 13
2.3.1.
3. Rétegek 3.1.
11
Áttekintés
18
18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
A tartománynév (DNS) rendszer . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.1.
Névfeloldás
21
4.2.2.
A DNS névtér felépítése
. . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2.3.
A DNS lekérdezések m¶ködése . . . . . . . . . . . . . . . . . . . . . . . .
23
Fájl átvitel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1.
File Transfer Protocol (FTP)
4.3.2.
Trivial File Transfer Protocol (TFTP)
. . . . . . . . . . . . . . . . . . .
28
4.3.3.
Telnet - távoli terminál . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Az elektronikus levél
. . . . . . . . . . . . . . . . . . . . . . . .
26 26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.4.1.
Az SMTP protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.4.2.
A POP3 protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.4.3.
Az IMAP protokoll
32
4.4.4.
A MIME kiterjesztés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
A Világháló (WWW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.5.1.
A Hypertext Markup Language (HTML) . . . . . . . . . . . . . . . . . .
34
4.5.2.
A Hypertext Transfer Protocol (HTTP)
35
Tartalomjegyzék
. . . . . . . . . . . . . . . . . .
Hálózati architektúrák és protokollok
4.5.3. 4.6.
iii
A WWW címzési rendszere (URIs)
. . . . . . . . . . . . . . . . . . . . .
36
Webmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5. Szállítási
37
5.1.
Áttekintés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2.
A szállítási szolgáltatás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.3.
Az UDP protokol
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.4.
A TCP protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.4.1.
Címzés és multiplexelés . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.4.2.
Kapcsolat kezelése
5.4.3.
Adatkezelés és csomagolás
. . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.4.4.
Megbízható adatátvitel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6. Hálózati 6.1. 6.2.
6.3.
48
Áttekintés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Alapfogalmak 6.2.1.
43
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
Kommunikációs módok . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
IP címzés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.3.1.
IP címek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.3.2.
IP címosztályok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6.3.3.
IP alhálózatok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.3.4.
Osztály nélküli címfelosztás - CIDR . . . . . . . . . . . . . . . . . . . . .
59
6.4.
IP datagrammok
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.
Forgalomszervezés (routing)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
6.6.
Címfeloldó protokoll (ARP)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
7. Adatkapcsolati
60
68
7.1.
Áttekintés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
7.2.
A közegelérési alréteg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
7.3.
Csatornakezel® protokollok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
8. Fizikai
73
8.1.
Áttekintés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
8.2.
Az átvitel technikai megvalósítása . . . . . . . . . . . . . . . . . . . . . . . . . .
73
8.3.
Az adatátvitel elméleti alap jai . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
8.3.1. 8.4.
8.5.
. . . . . . . . . . . . . . . . . . . . . . . .
76
Vezetékes adatátvitel
Sávszélesség és sávkihasználás
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
8.4.1.
Fémvezetékek
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.2.
Optikai kábelek
80
Vezeték nélküli adatátvitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
9. Hálózatépítés 9.1. 9.2.
77
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Local-Area Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hálózati eszközök
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83 84
9.2.1.
Fizikai (1.) réteg
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
9.2.2.
Adatkapcsolati (2.) réteg . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
9.2.3.
Hálózati (3.) réteg
85
Tartalomjegyzék
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hálózati architektúrák és protokollok
iv
II. Középhaladó könyv
85
10.Adatkapcsolati
85
10.1. Az adatfolyam keretezése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
10.2. Hiba javító kódok
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.Hálózati 11.1. DHCP
87 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2. Az útválasztás további részletei
. . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3. Dinamikus forgalomszervez® algoritmusok
. . . . . . . . . . . . . . . . . . . . .
11.4. Különleges routing alkalmazások . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.1. Címfordítás (NAT)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5. IPv6: Internet Protocol Version 6
. . . . . . . . . . . . . . . . . . . . . . . . . .
91 94 94 96
11.5.1. Az IPv6 áttekintése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
11.5.2. Az IPv6 címtér
97
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.3. Az IPv6 datagrammok
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.Szállítási
98
98
12.1. Az UDP protokoll felhasználása 12.1.1. A TCP torlódáskezelés
12.2.
87 91
. . . . . . . . . . . . . . . . . . . . . . . . . . .
98
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
12.1.2. A TCP min®ségbiztosítása . . . . . . . . . . . . . . . . . . . . . . . . . .
99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
Függelék
i
A. Bináris információ és ábrázolása
i
A.1. Szám ábrázolása és átalkítások . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
A.2. Aritmetics in other number systems . . . . . . . . . . . . . . . . . . . . . . . . .
iii
A.3. Boolean Logic and Logical Functions
iii
. . . . . . . . . . . . . . . . . . . . . . . .
A.4. Bit Masking Using Boolean Logical Functions
. . . . . . . . . . . . . . . . . . .
B. A hálózati jeltovábbítás zikai alapjai B.1. Az anyagok elektromos tulajdonságai B.2. A fénytörés ziká ja
vii . . . . . . . . . . . . . . . . . . . . . . . .
vii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
B.3. Adattovábbítás rádióhullámokkal B.3.1.
vi
. . . . . . . . . . . . . . . . . . . . . . . . . .
ix
Az elektromágneses spektrum és tula jdonságai . . . . . . . . . . . . . . .
ix
B.4. Adattovábbítás rádióhullámokkal
. . . . . . . . . . . . . . . . . . . . . . . . . .
Tárgymutató
x
x
Ábrák jegyzéke 1.1.
Az Internet a felhasználó szemszögéb®l
1.2.
Sir Tim Berners-Lee, a World Wide Web feltaláló ja
. . . . . . . . . . . . . . . .
2
1.3.
A hálózati diagram jelölésrendszere
. . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4.
Megosztott er®források használata a hálózaton . . . . . . . . . . . . . . . . . . .
2
1.5.
A hagyományos és az elektronikus levél felépítése
. . . . . . . . . . . . . . . . .
3
1.6.
Az elektronikus levél m¶ködése
. . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.
Az adatátvitel általános folyamata
Ábrák jegyzéke
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
1
4
Hálózati architektúrák és protokollok
v
2.2.
Az adatátvitel története
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3.
A küldés és fogadás viszonyai
2.4.
Logikai és zikai útvonal
2.5.
Simplex átviteli mód
2.6. 2.7.
Duplex átviteli mód . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.8.
A hálózatok m¶ködése kaotikus és rétegelt megvalósítás esetén
2.9.
Egy egyszer¶ hálózat
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Fél-duplex átviteli mód . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
. . . . . . . . . .
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.10. Peer-to-Peer Networking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.11. Client-Server Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.12. A szerver-kliens m¶ködési mód . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.13. A szerver-kliens m¶ködési mód m¶veletei . . . . . . . . . . . . . . . . . . . . . .
8
2.14. Címzési és továbbítási módszerek
9
. . . . . . . . . . . . . . . . . . . . . . . . . .
2.15. IPv4 címek értelmezése és szerkezete
. . . . . . . . . . . . . . . . . . . . . . . .
2.16. Az IP címek csoportosítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.17. A port egy bizonyos alkalmazás címét jelenti 2.18. Az inetd szerver m¶ködése
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.19. Port információk cseréje kapcsolatfelvételkor
9 9 10 11
. . . . . . . . . . . . . . . . . . . .
11
2.20. Kapcsolatmentes protokoll
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.21. Kapcsolat-alapú protokoll
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.22. Adatcsomagolás hagyományos módon . . . . . . . . . . . . . . . . . . . . . . . .
13
2.23. Adatcsomagolás network stack módon . . . . . . . . . . . . . . . . . . . . . . . .
13
2.24. A hálózati üzenetek formája
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.25. Adatcsomag nevek a különböz® rétegekben . . . . . . . . . . . . . . . . . . . . .
13
2.26. Az OSI 7 réteg¶ modellje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.27. Az OSI üzenetküldési modellje . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.28. A szolgáltatások és protokollok viszonya
. . . . . . . . . . . . . . . . . . . . . .
15
2.29. Az OSI és a TCP/IP modell összevetése
. . . . . . . . . . . . . . . . . . . . . .
15
2.30. Rétegek, protokollok és interfészek . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.31. A hálózat er®sen egyszer¶sített m¶ködése . . . . . . . . . . . . . . . . . . . . . .
16
2.32. Adat be- és kivitel hálózati adatforgalom során . . . . . . . . . . . . . . . . . . .
17
2.33. A hálózat elérésének legfels®bb szintjei
. . . . . . . . . . . . . . . . . . . . . . .
18
3.1.
A TCP/IP néhány jellemz® protokollja
. . . . . . . . . . . . . . . . . . . . . . .
19
4.1.
Az OSI alkalmazási (application) rétege . . . . . . . . . . . . . . . . . . . . . . .
20
4.2.
Az OSI megjelenítési (presentation) rétege
. . . . . . . . . . . . . . . . . . . . .
20
4.3.
Az OSI viszony (session) rétege
. . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.4.
Egy hálózati alkalmazás API szerepe és használata
4.5.
Fájl- vagy nyomtató kiszolgáló . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.6.
Névfeloldás helyi fájlból
22
4.8.
A DNS nevek kódolása
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.7.
A tartománynévtér felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.9.
DNS névfeloldás rekurzív és iteratív módon
25
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10. A tartománynévtér a fordított keresési ággal 4.11. Egy lehetséges DNS-adatbázis
. . . . . . . . . . . . . . . . . . . .
25 27
. . . . . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.14. Elektronikus levélküldés menete
. . . . . . . . . . . . . . . . . . . . . . . . . . .
4.15. A levelezés szerepl®i és protokolljai
Ábrák jegyzéke
. . . . . . . . . . . . . . . . . . . .
21
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.12. A DNS lekérdezések formátuma 4.13. Az FTP modell
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
30 30
Hálózati architektúrák és protokollok
vi
4.16. A levelezés állandó internet kapcsolattal és anélkül . . . . . . . . . . . . . . . . .
31
4.17. Az SMTP kapcsolat lefutása . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.18. A POP3 protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.19. Három üzenet letöltése POP3 segítségével
. . . . . . . . . . . . . . . . . . . . .
32
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.20. Az IMAP protokoll
4.21. Levélküldés a MIME használatával
. . . . . . . . . . . . . . . . . . . . . . . . .
33
4.22. Egy MIME alternatívákat tartalmazó példa . . . . . . . . . . . . . . . . . . . . .
33
4.23. Egy MIME átviteli példa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.24. A World Wide Web f®bb komponensei
. . . . . . . . . . . . . . . . . . . . . . .
34
4.25. A World Wide Web modellje . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.26. HTML minta szöveg
34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.27. HTML minta megjelenítés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.28. Néhány HTML utasítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.29. HTTP Request üzenetformátuma
36
4.30. HTTP Response üzenetformátuma
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.31. A Webmail komponensei és m¶ködése . . . . . . . . . . . . . . . . . . . . . . . .
38
5.1.
Az OSI szállítási (transzport) rétege . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.2.
A szállítási réteg helye és feladata . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.3.
Az UDP szegmens adatformátuma
. . . . . . . . . . . . . . . . . . . . . . . . .
39
5.4.
A TCP szegmens adatformátuma
. . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.5.
A bejöv® és kimen® adatok multiplexelése TCP/UDP port címek alapján
. . . .
43
5.6.
A háromutas kézfogás TCP kapcsolat létesítésekor . . . . . . . . . . . . . . . . .
43
5.7.
TCP kapcsolat lezárása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.8.
A TCP adatfolyam feldolgozása és szegmensenkénti küldése . . . . . . . . . . . .
45
5.9.
Pozitív nyugtázás újraküldéssel
. . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.10. Javított pozitív nyugtázás újraküldéssel . . . . . . . . . . . . . . . . . . . . . . .
46
5.11. A TCP átviteli stream logikai kategóriái 5.12. TCP tranzakció újraküldéssel
. . . . . . . . . . . . . . . . . . . . . .
47
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.13. TCP tranzakció szelektív újraküldéssel
. . . . . . . . . . . . . . . . . . . . . . .
47
6.1.
A hálózati (internet) réteg áttekintése . . . . . . . . . . . . . . . . . . . . . . . .
48
6.2.
Az OSI hálózati (network) rétege
48
6.3.
A hálózati réteg önti formába az adatokat a zikai hálózat számára
. . . . . . .
49
6.4.
Egy egyszer¶sített kommunikációs modell-diagram . . . . . . . . . . . . . . . . .
49
6.5.
Hálózat vonalkapcsolással
50
6.6.
Hálózat csomagkapcsolással
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.7.
Virtuális áramkör alapú kapcsolat . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.8.
Datagram alapú kapcsolat
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.9.
Virtuális áramkör diagram
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.10. Datagram diagram
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.11. Forgalomirányítás datagramm alhálózatban
. . . . . . . . . . . . . . . . . . . .
6.12. Forgalomirányítás virtuális áramkör alhálózatban 6.13. Tipikus hálózati eszközök interfészelése
52
. . . . . . . . . . . . . . . . .
52
. . . . . . . . . . . . . . . . . . . . . . .
53
6.14. Több interfésszel rendelkez® csomópontok egy együttm¶köd® IP hálózatban . . .
53
6.15. IPv4 címosztályok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.16. IP cím ábrázolásmódjai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6.17. IPv4 címosztályok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6.18. Az IP-címek osztályba sorolásának folyamatábrája . . . . . . . . . . . . . . . . .
55
6.19. IP cím felbontása bájton belül hálózat és gazdagép címre . . . . . . . . . . . . .
55
Ábrák jegyzéke
Hálózati architektúrák és protokollok
vii
6.20. Egy B osztályú hálózat felosztása alhálózatokra
. . . . . . . . . . . . . . . . . .
56
6.21. Alhálózati maszk meghatározása . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.22. Alhálózati azonosító el®állítása az alhálózati maszk felhasználásával
56
. . . . . . .
6.23. Az A, B és C címosztályok alapértelmezett alhálózati maszkjai . . . . . . . . . .
57
6.24. Címzés/útválasztás alhálózatok esetén
. . . . . . . . . . . . . . . . . . . . . . .
57
6.25. C osztályú alhálózatok tervezése . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6.26. Alhálózat készítés egy C osztályú címb®l, egyszer¶ . . . . . . . . . . . . . . . . .
58
6.27. Alhálózat készítés egy B osztályú címb®l, bonyolultabb
58
6.28. Alhálózat cím egy C osztályú hálózatban
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
59
6.29. Gazdagép cím egy C osztályú hálózatban . . . . . . . . . . . . . . . . . . . . . .
59
6.30. A CIDR megoldása a szemcsézettség problémá jára . . . . . . . . . . . . . . . . .
60
6.31. Az IPv4 fejzet mez®i
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.32. IP datagramm beágyazás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
6.34. IP datagramm kétlépcs®s fragmentáció
62
. . . . . . . . . . . . . . . . . . . . . . .
6.35. IP datagramm kétlépcs®s fragmentációs folyamata . . . . . . . . . . . . . . . . .
62
6.33. IP Maximum Transmission Unit (MTU) és a fragmentáció
63
. . . . . . . . . . . .
6.36. A router mint többcím¶ számítógép . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.37. Komplex hálózat forgalomszervezése . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.38. IP útválasztás és útválasztó táblázatok
64
6.39. A forgalomszervezése folyamata
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.40. Egy üzenet útvonalválasztása az OSI hivatkozási modellben . . . . . . . . . . . .
65
6.41. Az IP továbbítási folyamat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.42. Csomagtovábbítás a hálózati rétegben, ugrópontokkal
. . . . . . . . . . . . . . .
66
. . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.43. Két szegmenst összeköt® router
6.44. Adattovábbítás közvetett csatolású routerek esetén
. . . . . . . . . . . . . . . .
67
6.45. Why address resolution is necessary . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.46. Dynamic address resolutiony . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.47. Az ARP képezi le az IP címeket zikai címekké
. . . . . . . . . . . . . . . . . .
68
. . . . . . . . . . . . . . . . . . . . . .
69
7.1.
Az OSI adatkapcsolati (data link) rétege
7.2.
A csomagok és a keretek közötti kapcsolat
. . . . . . . . . . . . . . . . . . . . .
69
7.3.
Az adatkapcsolati protokoll elhelyezkedése
. . . . . . . . . . . . . . . . . . . . .
70
7.4.
MAC cím
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
7.5.
Kerettovábbítás az egyszer¶ ALOHA rendszerben
7.6.
Ütközésveszély a keretek között
7.7.
ALOHA rendszerek átereszt®képessége
7.8.
Véletlen hozzáférés¶ protokollok átereszt®képessége
7.9.
A CSMA/CD protokoll állapotai
7.10. Az alapvet® bittérkép protokoll
. . . . . . . . . . . . . . . . .
71
. . . . . . . . . . . . . . . . . . . . . . . . . . .
71
. . . . . . . . . . . . . . . . . . . . . . .
72
. . . . . . . . . . . . . . . .
72
. . . . . . . . . . . . . . . . . . . . . . . . . .
72
. . . . . . . . . . . . . . . . . . . . . . . . . . .
7.11. Egy ütközéselkerüléses protokoll (MACA) 7.12. A CSMA/CD egyszer¶sített folyamatábrá ja
. . . . . . . . . . . . . . . . . . . . .
72 73
. . . . . . . . . . . . . . . . . . . .
73
8.1.
Az OSI zikai (physical) rétege
. . . . . . . . . . . . . . . . . . . . . . . . . . .
73
8.2.
Példa analóg és digitális jelre . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
8.3.
Példa analóg jeltovábbításra
8.4.
Példa digitális jeltovábbításra
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
8.5.
Periodikus analóg és digitális jelalak . . . . . . . . . . . . . . . . . . . . . . . . .
74
8.6.
Egy egyszer¶sített kommunikációs modell . . . . . . . . . . . . . . . . . . . . . .
75
8.7.
Digitális jel átvitelének modulációs lehet®ségei
. . . . . . . . . . . . . . . . . . .
75
8.8.
Digitális jel és fokozatos közelítése . . . . . . . . . . . . . . . . . . . . . . . . . .
76
Ábrák jegyzéke
Hálózati architektúrák és protokollok
8.9.
viii
Digitális jel fokozatos közelítése
. . . . . . . . . . . . . . . . . . . . . . . . . . .
8.10. Digitális jelek átviteli csillapítása
76
. . . . . . . . . . . . . . . . . . . . . . . . . .
76
8.11. Frekvenciaosztásos multiplexelés . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
8.12. Hullámhosszosztásos multiplexelés . . . . . . . . . . . . . . . . . . . . . . . . . .
77
8.13. Id®osztásos multiplexelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
8.14. A sodrott érpáras kábel felépítése
77
. . . . . . . . . . . . . . . . . . . . . . . . . .
8.15. A sodrott érpáras kábel árnyékolása . . . . . . . . . . . . . . . . . . . . . . . . .
77
8.16. A sodrott érpáras kábel néhány típusa
78
8.17. Az UTP kábel tipikus használata 8.18. A koaxiális kábel szerkezete
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
8.19. Fémes vezet®kábelek speci kációja
. . . . . . . . . . . . . . . . . . . . . . . . .
78
8.20. A hálózati kábelek lezárása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
8.21. 10BASE5 kábelezés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
8.22. Az UTP kábelcsatlakozó
79
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.23. 10BASE2 kábelezés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
8.24. Koaxiális kábel BNC csatlakozóval
79
8.25. Koaxiális kábel T csatlakozóval
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
80
8.26. Koaxiális kábel T csatlakozó véd®sapkában . . . . . . . . . . . . . . . . . . . . .
80
8.27. RJ-45 típusú csatlakozó és aljzat
. . . . . . . . . . . . . . . . . . . . . . . . . .
80
8.28. Optikai kábelek csatlakozói . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
8.29. A teljes visszaver®dés két eltér® törésmutatójú közegben
. . . . . . . . . . . . .
81
8.30. A teljes visszaver®dés jelensége koncentrikus hengerekben . . . . . . . . . . . . .
81
8.31. Az optikai kábel módusainak értelmezése
. . . . . . . . . . . . . . . . . . . . . .
81
. . . . . . . . . . . . . . . . . . . . . . . . .
81
8.32. A numerikus appertura értelmezése
8.33. A fém és az optikai kábel összehasonlítása
. . . . . . . . . . . . . . . . . . . . .
8.34. Az elektromágneses spektrum felhasználása a távközlésben 8.35. Rádiófrekvenciás átvitel
82
. . . . . . . . . . . .
82
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
8.36. Kommunikációs m¶holdak tula jdonságai
. . . . . . . . . . . . . . . . . . . . . .
82
9.1.
Eszköz a hálózati adatforgalom sz¶résére
. . . . . . . . . . . . . . . . . . . . . .
83
9.2.
Nyomtató kezelése helyi hálózattal és anélkül . . . . . . . . . . . . . . . . . . . .
83
9.3.
Csillag (star) elrendezés¶ topológia
. . . . . . . . . . . . . . . . . . . . . . . . .
83
9.4.
Gy¶r¶ (ring) elrendezés¶ topológia
. . . . . . . . . . . . . . . . . . . . . . . . .
84
9.5.
Fa (tree) elrendezés¶ topológia . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
9.6.
A jelismétl® (repeater) m¶ködése
84
9.7.
Megosztott Ethernet
9.8.
Két Ethernet szegmenst összekapcsoló híd (bridge)
. . . . . . . . . . . . . . . .
85
9.9.
Két LANt az Internetre kapcsoló router . . . . . . . . . . . . . . . . . . . . . . .
85
10.1. Hiba hatása a karakterszámlálásos módszerre . . . . . . . . . . . . . . . . . . . .
86
10.2. Jelz®bájtokkal határolt keret . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
10.3. Az eredeti adat és bitbeszúrással megváltoztatott változata . . . . . . . . . . . .
86
10.4. A Hamming-kód alkalmazása csoportos hibák kijavítására . . . . . . . . . . . . .
87
11.1. A DHCP címfoglalási folyamat
89
11.2. DHCP életciklus példa
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3. Forgalomszervezés változása egy alhálózatban 11.4. Igazságosság és optimalitás kon iktusa
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
11.5. Egy alhálózat és egy nyel®fa a B routerhez
. . . . . . . . . . . . . . . . . . . . .
11.6. Az els® öt lépés az A-tól D-ig vezet® legrövidebb út kiszámításában
90 91 91 91
. . . . . . .
93
11.7. Távolságvektor alapú forgalomirányító táblázat m¶ködése . . . . . . . . . . . . .
93
Ábrák jegyzéke
Hálózati architektúrák és protokollok
ix
11.8. Távolságvektor alapú forgalomirányítás egy alhálózatban
. . . . . . . . . . . . .
94
11.9. A végtelenig számolás problémája . . . . . . . . . . . . . . . . . . . . . . . . . .
94
11.10.Egy hálózati címfordító (NAT) eszköz . . . . . . . . . . . . . . . . . . . . . . . .
95
11.11.Az IP NAT terminológiája . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
11.12.Az IPv6 és IPv4 címtér viszonya . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
11.13.Az IPv6 címek bináris, decimális és hexadecimális ábrázolása . . . . . . . . . . .
97
11.14.Az IPv6 címrendszerbe ágyazott IPv4 cím ábrázolásmódja 11.15.Az IPv6 címrendszerbe leképezett IPv4 cím ábrázolásmódja 11.16.Az IPv6 fejzet általános szerkezete 11.17.Az IPv6 fejzet formátuma
97
. . . . . . . . . . .
98
. . . . . . . . . . . . . . . . . . . . . . . . .
98
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
11.18.Az IPv6 fejzet kiterjesztésének használata 12.1. Távoli eljáráshívás
. . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
12.2. Az RTP protokoll helye (a) és csomagjainak felépítése (b) . . . . . . . . . . . . .
99
12.3. Tipikus t¶zfal kapcsolat
99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1. Bináris információ ábrázolások és elnevezéseik
. . . . . . . . . . . . . . . . . . .
A.2. Binary, Octal and Hexadecimal Number Representations A.3. Clearing Bits Using an AND Bit Mask
. . . . . . . . . . . . .
i ii
. . . . . . . . . . . . . . . . . . . . . . .
vi
B.1. Az anyagok felosztása vezet®képességük szerint . . . . . . . . . . . . . . . . . . .
vii
B.2. Elektromos áramkör zárt és nyitott állapotban . . . . . . . . . . . . . . . . . . .
viii
B.3. Különböz® anyagok törésmutatói B.4. A fénytörés jelensége
. . . . . . . . . . . . . . . . . . . . . . . . . .
viii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
B.5. A fénytörést bemutató kísérlet . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
B.6. A fénytörés elvi rajza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
B.7. A fénytörést leíró formula
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
B.8. A teljes visszaver®dést leíró képlet . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
B.9. A teljes visszaver®dés elvi ra jza
. . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
B.10.A teljes visszaver®dés jelensége
. . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
B.12.A h®mérsékleti sugárzás színspektruma . . . . . . . . . . . . . . . . . . . . . . .
ix
B.13.Karakterisztikus sugárzás
ix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.11.Az elektromágneses spektrum
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
x
Táblázatok jegyzéke 2.1.
"Jól ismert" portcímek
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
4.2.
A legfontosabb DNS er®forrás bejegyzés típusok) . . . . . . . . . . . . . . . . . .
27
4.3.
Egy fá jl letöltése FTP protokollal
. . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.4.
A POP3 és IMAP protokollok összehasonlítása . . . . . . . . . . . . . . . . . . .
31
5.5.
Berkeley TCP-primitívek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.6.
Datagramm és virtuális áramkör módszerrel megvalósított alhálózatok összehasonlítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
A.7. Bináris információ csoportok és elnevezések . . . . . . . . . . . . . . . . . . . . .
i
A.8. Binary and Decimal Number Equivalents . . . . . . . . . . . . . . . . . . . . . .
ii
A.9. Hexadecimal to Decimal Number Conversion . . . . . . . . . . . . . . . . . . . .
iii
A.10.Decimal to Binary Conversion
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
A.11.Decimal to Hexadecimal Number Conversion . . . . . . . . . . . . . . . . . . . .
iv
A.12.Binary addition
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
A.13.Hexadecimal addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
A.14.
v
NOT Operator Truth Table
Táblázatok jegyzéke
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hálózati architektúrák és protokollok
AND Operator Truth Table . . . . . . A.16.OR Operator Truth Table . . . . . . . A.17.XOR Operator Truth Table . . . . . . A.18.Setting Bits Using an OR Bit Mask . . A.19.Clearing Bits Using an AND Bit Mask A.20.Inverting Bits Using an XOR Bit Mask A.15.
Listings
Listings
x
. . . . . . . . . . . . . . . . . . . . . . .
v
. . . . . . . . . . . . . . . . . . . . . . .
v
. . . . . . . . . . . . . . . . . . . . . . .
v
. . . . . . . . . . . . . . . . . . . . . . .
vii
. . . . . . . . . . . . . . . . . . . . . . .
vii
. . . . . . . . . . . . . . . . . . . . . .
vii
Hálózati architektúrák és protokollok
1
I. rész
Kezd® könyv 1. Az Internet, közelebbr®l 1.1. Bevezetés Mindennapjaink egyre szorosabban összefüggenek az Internettel. Tanulás, ügyintézés, szó-
a háló. De mi is az, ami
rakozás, munka : irány
c www.cs.princeton.edu/bwk/cloud.jpg
nélkül (szinte) élni sem tudunk? Az a
világ
Internet,
avagy
legnagyobb
a
világháló
számítógépes
ma
már
hálózata.
1.1. ábra. Az Internet a felhasználó szemszögéb®l
Szerencsére, akkor is m¶ködik, és valamilyen
szolgáltató któl.
hatékonysággal akkor is tudjuk azt használni,
ni bizonyos információkat ún.
ha nem tudjuk m¶ködésének részleteit. Ah-
Magától értet®d®nek tartja, hogy szüksége van
hoz, hogy mindennapi életünkben hatékonyan tudjuk használni, legalábbis madártávlatból ismernünk kell m¶ködésének elveit, a fogalmakat, a szakszavak nagy részét, a rövidítéseket, a szabványokat, mindenféle összefüggéseket és rengeteg más dolgot. Amikor elkezdünk ismerkedni az Internet m¶ködésének
részleteivel,
hihetetlen
bonyo-
lultsággal, valamint rengeteg ismeretlen szóval és fogalommal találkozunk. Ismerkedjünk meg el®ször alaposabban az ismert(nek t¶n®) alkalmazásokkal, és pillantsunk egy kicsit a színfalak mögé. Aztán, mivel ott újabb színfalat
találunk,
ott
is
ismerkedjünk
meg
a
m¶helytitkokkal. A megismerésnek különböz® szintjei már
vannak,
ismertnek
ezért
id®nként
gondolt
visszatérünk
részekhez
és
számítógép re (vagy legalábbis ilyen jelleg¶ szerkezetre), amin egy operációs rendszer fut, és valami csatlakoztató hardver re. Tudja, hogy el® kell zetnie a hozzáférés jogosultságáért, zetnie kell a fel- vagy letöltött adat ok után; elhiszi hogy a jelszóval védett adataihoz kizáegy
rólagos joggal fér hozzá, és bízik benne, hogy
adatai titok ban maradnak, zet egy multimédiás anyag élvezetéért. Beállít (kon gurál) bizonyos hálózattal kapcsolatos szoftvereket, ennek során hálózati cím eket ad meg, vagy éppen névkiszolgáló t vagy átjáró t jelöl ki, megadja saját statikus IP cím ét vagy dinamikus címkiosztás t kér. S®t, t¶zfal beállítás t engedélyez és hálózati protokoll t választ. Használja a fenti kiemelt hitelhártyájának amikor
továb-
szavakat, általában anélkül, hogy teljes mér-
bi részletekkel foglalkozunk. Az is el®fordul
tékben ismerné azok jelentését; vagy tudná,
majd, hogy korábbi megfogalmazásokat pon-
kinek
tosítunk, s®t részben visszavonunk.
az 1.2 ábrát.
köszönheti
Az
Internet
az
a
Internet
élvezetét,
legkülönböz®bb,
lásd
többé-
kevésbé zárt hálózatokat kapcsolja össze, megA mai Internet már túl nagy és túl bonyolult
ahhoz,
hogy
akárcsak
kicsit
realisz-
tikusan ábrázolni tudjuk. A legtöbb felhasz-
lehet®sen bonyolult módon. Különböz® technikákat,
felh® t, mint amilyen az 1.1 ábrán látható. csatlakozv a valamilyen rejtélyes módon, bizonyos alkalmazás ok felhasználásával kapcsola tba tud lépni barátaival, be tud szerez-
Erre
1.1. Bevezetés
összekötési
módokat,
protokollokat használ.
náló számára az Internet valami közelebbr®l meg nem határozott dolgot jelent. Egy olyan
sebességeket,
Érdemes oda gyelni a helyesírásra: az
ternet
az
rövidítése, terjed® túl
internetworking az
Internet
hálózat.
határozott
Egyes
az
nev¶ egész
részeire
jelentéssel)
in-
technológia világra néha
ki-
(nem
használatosak
az
Hálózati architektúrák és protokollok
2
c http://www.networkworld.com/subnets/cisco
1.3. ábra. A hálózati diagram jelölésrendsze-
c //blogs.zdnet.com/images/bernerslee400
1.2.
ábra.
Sir
Tim
re
Berners-Lee,
a
World A hálózat egyik f® feladata, hogy lehet®vé te-
Wide Web feltaláló ja
gye a felhasználók és az alkalmazások számára
intranet (egyfajta bels® elérés¶ magánhálózat) és extranet (egyfajta kívülr®l is elérhet®
az adatok és az er®források megosztotthasználatát. Egy jellemz® példát mutat az 1.4 ábra.
magánhálózat) kifejezések is.
1.2. Fogalmak és jelölések Az el®z® (népszer¶sít® szint¶) hálózat ábrázolás kötetlenebb; a szakmaibb, az ún. hálózati diagram
(lásd
az
1.3
ábrát)
a
hálózat
ele-
meinek ábrázolására speciális szimbólumokat használ:
•
A
felh®
az
Internetet
vagy
egy
WAN
kapcsolatot ábrázol.
•
A nyilakkal ellátott henger egy routert jelent.
•
c http://www.networkworld.com/subnets/cisco
1.4. ábra. Megosztott er®források használa-
A nyilakkal ellátott négyszögletes doboz
ta a hálózaton
egy switch. Az
Internet
való jában
egy
olyan
extrém
•
A torony PC egy szervert jelent.
•
A laptop vagy monitor egy végfelhaszná-
a
lói PC-t ábrázol.
hálózatok a már említett elemekb®l épülnek
nagyméret¶ számítógépes hálózat, amelyiket gyakorlatban
bármire
használhatunk.
A
fel, ezeket majd fokozatosan megismerjük. Ha
•
Egy Ethernet kapcsolatot egyenes vonal,
•
Egy
soros
kapcsolatot
Z-alakú
vonal
ábrázol. A
továbbiakban
komolyabb igényünk
végreha jtási
van,
akkor
id®
arra
vagy külön
gyelnünk. Néhány jellemz® használata:
mindkét
fajta
ábrázolást
•
World Wide Web
•
Email
használni fogjuk.
1.2. Fogalmak és jelölések
biztonsági oda
kell
Hálózati architektúrák és protokollok
3
•
FTP
•
Newsgroups (hírcsoportok)
•
Chat and instant messaging (üzenetküldés)
•
Remote access (távoli hozzáférés)
Az Internet fejlesztése ma is teljes lendülettel folyik:
új
szolgáltatások,
m¶ködési
módok,
eszközök, protokollok, stb jelennek meg. Különleges fejleszt®i modellje van: a fejlesztési
javaslat ot
az
RFC
editor
http://www.
(l.
rfc-editor.org/) webhelyen közzéteszik. Ez lesz
a
leírás, amelyhez vitás esetben vissza kell
menni. Letisztult, magyarázatokkal és példákkal
ellátott
változatait
könyvekb®l
c A.
S. Tanenbaum: Computer Networks
1.5. ábra. A hagyományos és az elektronikus levél felépítése
érdemes
megtanulni.
1.3. Hagyományos és internetes szolgáltatás A hálózati szolgáltatások egy része hagyományos szolgáltatás mintájára és helyettesítésére jött létre. Például, az elektronikus levél
•
Az egyik leggyakrabban használt alkalmazás a számítógéphálózatokon
c W.
•
Stallings: Data and Computer Communications
Felépítése a hagyományos levélre hasonlít, lásd az 1.5 ábrát. Használata közben
1.6. ábra. Az elektronikus levél m¶ködése
azonban egyedi stílus született Nagyon
•
Egyszer¶ szövegeket szállít
•
Más
típusú
m¶ködése
megérthet®
az 1.6 ábráról. A közelebbi vizsgálat már olyan
melléklet ként
adatokat
távolról
(hang kép, mozgókép) is szállít
SMTP, TCP, port, protokol, stb. Szerepel benne user agent, message transfer agent, háttérben futó program (daemon, vagy service ). Szóba kerülnek
b¶vszavakat
tartalmaz,
mint
operációs rendszer feladatok, id®zítések, komHasználatát
jól
ismerjük,
a
részletes
és
munikációs
módok
(protokollok),
üzenetfor-
megalapozott hálózati ismeretek nélkül gya-
mátumok, stb. Tehát, egyszer¶ kezelhet®sége
koroljuk.
Kb.
1990
m¶ködését
ellenére, igen bonyolult a m¶ködése. És, még
a
821
(l.
http://www.rfc-editor.org/
nem is beszéltünk arról, hogyan jut el a levél a
rfc/rfc821.txt) és RFC 822 (l. http://www.
felhasználói alkalmazástól a hálózati eszközig,
rfc-editor.org/rfc/rfc822.txt), vagy újabban a
hogyan jut át a hálózaton, hogyan talál célba,
http://www.rfc-editor.org/rfc/
hogyan jut a célszámítógép hálózati eszközét®l
http://www.
a partner hálózati alkalmazásig. A kurzus so-
RFC
RFC
5321
(l.
rfc5321.txt)
és
RFC
óta
terjed,
5322
(l.
rfc-editor.org/rfc/rfc5321.txt) írják le.
1.3. Hagyományos és internetes szolgáltatás
rán ennek a rendkívül bonyolult folyamatnak
Hálózati architektúrák és protokollok
4
a részleteivel ismerkedünk meg.
2. Adatkommunikációs hálózatok
c 2004
by Sams Publishing/J. Casad
A felhasználó sa ját számítógépén egy alkal-
2.1. ábra. Az adatátvitel általános folyama-
mazástól
ta
a
gépen
tásával
kér
hálózati
operációs rendszer
futó tud
funkciókat,
teljesíteni.
A
amit
az
közbeikta-
hálózat
elérésére
használt hardver eszközöket a számítógéphez csatlakoztatni kell, a megfelel® szoftveres kezel®programokat és kiegészítéseket beüzemelni, a lehetséges választási lehet®ségek megfelel® beállításával üzemkésszé tenni az alkalmazást és
nem
utolsósorban
megtanulni
annak
ke-
zelését. Az egész komplex folyamat részben rendszergazdai
jogosultságokat
is
igényel.
A
folyamat teljes áttekintése nyilván meghaladja a tananyag kereteit, de nagy vonalakban azért át kell látnunk. A számítógépes hálózatok felhasználásával végzett kommunikáció
•
viszonylag
egyszer¶en
elvégezhet®,
de
komplex m¶ködés¶ folyamat
•
számítógépes alkalmazások között folyik
•
sok komponens¶, bonyolult infrastruktúrát igényel
•
dinamikus, az alkalmazott technológiáktól
(a
hardver
és
szoftver
gyártóktól)
független
2.1. Az adatkommunikációs alapvetés c 2004
by Sams Publishing/J. Casad 2.2. ábra. Az adatátvitel története
Az adatátvitel fogalma szinte alig változott a történelem folyamán (lásd 2.1 ábra), annak konkrét megvalósulási formái azonban
2.1.1. Kommunikációs fogalmak
annál inkább. Az üzenet valamiféle rögzítésére (kódolására) oldalon
mindig
pedig
kódolására).
annak
szükség
volt,
a
fogadó
visszaalakítására
Különösen
érdemes
(de-
•
El®állítja a továbbítandó jelet
meg gyelni
az adateljuttatás sebességét és hatótávolságát (lásd 2.2 ábra)
2.1. Az adatkommunikációs alapvetés
Adatforrás (source)
•
Küld®egység (adó, transmitter)
Hálózati architektúrák és protokollok
5
A továbbítand® adatokat továbbítható jelekké alakítja
•
Az adattovábbító rendszer (Transmission System) Szállítja az adatokat
•
Fogadóegység (vev®, receiver) a fogadott jeleket adatokká alakítja
•
c 2004
Cél számítógép (destination) fogadja a bejöv® adatokat
Cisco Press/M. J. Castelli
2.3. ábra. A küldés és fogadás viszonyai
Az adatkommunikáció néhány alapfeladata
•
az átviteli rendszer használata
•
a rendszerek egymáshoz illesztése
•
jelgenerálás
•
szinkronizálás
•
adatcsere kezelése
•
hibák felismerése és javítása
•
adatáramlás vezérlése
•
címzés
•
útvonalkezelés
•
újrakezdés
•
üzenetformázás
•
biztonsági feladatok
•
a hálózat kezelése
c 2004
Cisco Press/M. J. Castelli 2.4. ábra. Logikai és zikai útvonal
2.1.2. Átviteli módok Szimplex
adatforgalom
szigorúan
csak
egy
irányban (pl. rádiós m¶sorszórás), l. 2.5 ábra.
Fél-duplex
adatforgalom mindkét irányban
lehetséges, de nem egyidej¶leg (pl. CB rádió), l. 2.6 ábra.
Duplex
adatforgalom
mindkét
irányban,
egyidej¶leg (pl. telefon), l. 2.7 ábra. Egy
csomópont
lehet
adatküld®
(forrás,
adó) vagy adatfogadó (nyel®, vev®), vagy akár mindkett®, l. 2.3 ábra.
2.1.3. Rétegelt architektúra Bonyolult m¶ködés¶ rendszerek esetén álta-
Érdemes megkülönböztetni a zikai és a logikai utat(l. 2.4 ábra): a közbüls® csomópont csak átszállóhely, a logikai útvonalban helyettesíthet® és el is hagyható.
lában
az
ún.
rétegelt
megvalósítást
szokták
alkalmazni. Ez azt jelenti, hogy a részletek ismerete
nélkül,
a
bonyolult
m¶ködtetést
a
megfelel® hardverre/szoftverre bízva használhatjuk a megfelel® eszközt vagy szolgáltatást.
2.1. Az adatkommunikációs alapvetés
Hálózati architektúrák és protokollok
c 2004
6
Cisco Press/M. J. Castelli 2.5. ábra. Simplex átviteli mód
c 2004
Cisco Press/M. J. Castelli 2.7. ábra. Duplex átviteli mód
rétegelt felépítés¶ként lehet jól tárgyalni. A kurzus többféle réteg(szer¶) modellt is tárgyal. Ezek
közül
a
legalapvet®bb
az
Open
Sys-
tems Interconnection (OSI) 7-réteg¶ modellje, aminek egyfajta áttekintése a 2.8 ábra jobb oldalán látható.
c 2004
Cisco Press/M. J. Castelli 2.6. ábra. Fél-duplex átviteli mód
Pl. a mindennnap használatos személyi számítógépeink esetén is rétegelt rétegelt felépítés
c 2004
http://www.globalknowledge.com
használatos: az alkalmazások operációs rend-
2.8. ábra. A hálózatok m¶ködése kaotikus és
szeren futnak, az operációs rendszer megha jtó
rétegelt megvalósítás esetén
egységeken eszközökkel,
keresztül a
kommunikál
meghajtók
a
hardver
m¶ködésükhöz
a
BIOS (Basic Input/Output System) szolgál-
A kommunikáció folyamatát azért célszer¶ rétegekre bontani, mert
tatásait veszik igénybe. A hálózatok esetén hihetelenül bonyolult
•
mind a felépítés, mind a m¶ködés. Ha nem teremtünk benne rendet, a 2.8 ábra bal oldalán mutatott módon kaotikus, átláthatatlan lesz a m¶ködés. A hálózatokat célszer¶en szintén
2.1. Az adatkommunikációs alapvetés
a protokoll(ok) megadása nehéz, komplex feladat
•
egy (hierarchikus) protokoll rendszer áttekinthet®bb
Hálózati architektúrák és protokollok
•
csak
a
rétegek
illeszkedését
7
(interfész)
kell meghatározni, a m¶ködését nem
•
az egyes rétegeket különböz® gyártók is implementálhatják
•
könnyebb implementálni
•
könnyebb változtatni
•
könnyebb hibát keresni
•
egyszer¶en kicserélhet®
•
könnyebben tanulható
2.2. Hálózati alapfogalmak
c 2004
Hálózati szakkifejezéssel, a hálózatot alkotó a számítógépeket vagy eszközöket
pont oknak
(node)
vagy
gazdagép nek
nevezik. Egy hálózatban, az egyik számítógépen elküldött üzenetek (kérések és a hozzájuk tartozó adatok) az átviteli közegen (ami hálózati kábel, telefonvonal, rádiós vagy m¶holdas kapcsolat egyaránt lehet) át egy másik számítógépre jutnak. A küld® számítógépnek képesnek
kell
elküldésére,
a
lennie
az
fogadó
üzenet
vagy
kérés
számítógépnek
pedig
annak megértésére és a válaszolásra.
Ehhez
a jelek zikai érzékelésére (hardver eszközök) és megfelel® értelmezésére (ún.
2.9. ábra. Egy egyszer¶ hálózat
csomó(host)
protokoll ok) is
szükség van. A hálózatok sokfélesége miatt, a széleskör¶ tárgyalhatóság érdekében elég laza de níciót használunk.
by Sams Publishing/J. Casad
2.2.1. Strukturális és m¶ködési modellek A
hálózatokban
lönböz®
szerepl®
szerepeket
eszközöknek
szánhatunk;
a
kü-
szerept®l
függ, hogy hogyan fér egy csomópont hozzá más
csomópontokhoz
kapcsolt
eszközökhöz.
Egyenrangú csomópontok (peer-to-peer) esetén a szerepek egyformák, bármely csomópont bármelyik másikkal kapcsolatba léphet, lásd 2.10 ábra. Ez a modell f®ként kisebb hálózatok esetén használatos. Nagyobb hálózatokban a csomópontok
egy
része
(gyorsabb
hálózati
kapcsolattal, nagyobb memóriával, stb. rendelkez®) központi szerverként, kisebbik része felhasználói kliensként üzemel, lásd 2.11 ábra.
A hálózat létrehozásának céljai:
Az
adatforgalom
tipikusan
a
szerver
és
a
kliensek között folyik, bár a kliensek egymással
•
Er®források/információ megosztása
•
Megbízhatóság növelése
•
is kapcsolatba tudnak lépni.
A
Sebesség/teljesít®képesség növelése
hálózaton
keresztül
kapcsolatba
kerül®
programok legtöbbször szerver-kliens (kiszolgáló/ügyfél) elven (lásd 2.12 ábra) m¶ködnek.
•
A
Emberi kommunikáció
kliens
kezdeményez,
a
szerver
passzívan
várakozik a kapcsolatfelvételre: ha kérdezik, (Pl.
számítógép,
nyomtató,
forgalomirá-
válaszol.
nyító, kiszolgáló). Egy kommunikációban egy
Az ilyen m¶ködési mód attól sikeres, hogy
csomópont m¶ködhet adó (forrás) illetve vev®
a partnerek pontosan tudják, mit várhatnak
(nyel®) funkcióval.
el egymástól (itt jut szerephez a
2.2. Hálózati alapfogalmak
protokoll ):
a
Hálózati architektúrák és protokollok
8
c 2004
by Sams Publishing/J. Casad
2.12. ábra. A szerver-kliens m¶ködési mód
c 2005
by http://www.tcpipguide.com/C. M. Kozierok 2.10. ábra. Peer-to-Peer Networking
c 2004
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
2.13. ábra. A szerver-kliens m¶ködési mód m¶veletei
2.11. ábra. Client-Server Networking
szerverek gyelnek és kérésre adatokat külde-
megfelel® kiszolgáló m¶ködésének blokkdiagramját
nek. A
tényleges
kivitelezés
általában
bonyo-
lultabb, mint a 2.13 ábrán bemutatott funkcionalitás.
Az
kapcsolatban
ábra álló
egy,
a
felhasználóval
alkalmazás
2.2. Hálózati alapfogalmak
by Wiley Publishing:N. Matthew, R. Stones
(ügyfél)
és
is a
mutatja.
Néha
még
a
kifejezések
is
segítenek elfedni, hogy szerver kliens üzemmódot használunk: pl. böngész®t mondunk WEB kliens helyett.
helyett,
és
honlapot
WEB
szerver
Hálózati architektúrák és protokollok
9
A hálózaton az üzeneteket meg kell címezni és
egyedi ilyen címe van. A hívószám
el kell juttatni a címzettnek, lásd 2.14 ábra.
is nagyon hasonlít a telefonszámokhoz, hogy
Az
el®hívó
üzenet
célja
meghatározza
az
eljuttatás
számra
(hálózatazonosító)
és
abban
helyi
telefonszámra (gazdagép azonosító) osztható.
módját is.
Mint az a 2.15 ábrán látható, ez a felosztás nem egy bizonyos helyen történik, hanem annak helye a körülményekt®l függ®en változhat.
c 2008
by http://wiki.hill.com
2.15. ábra. IPv4 címek értelmezése és szerkezete
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
2.14. ábra. Címzési és továbbítási módszerek
Unicast
egyik eszköz üzen a másik eszköz-
nek. Az üzenetet az eszköz címére küldi.
Broadcast
egyik
eszköz
üzen
a
hálózaton
lev® összes eszköznek. Az üzenetet általában egy erre a célra fenntartott címre küldi
Multicast
egyik eszköz üzen a hálózaton lev®
eszközök
bizonyos
csoportjának.
c 2004
by Sams Publishing/J. Casad
Nem
triviális a csoport kiválasztása, speciális
2.16. ábra. Az IP címek csoportosítása
módon történhet. A hálózaton az adatok a címek alapján továbbítódnak. Mint látni fogjuk, nem a szá-
2.2.2. Hálózati címzés
mítógép,
hanem
annak
a
hálózati
adaptere
(interfésze) rendelkezik számmal. Egy számíA
számítógépes
hálózatokban
az
egyes
tógépben több hálózati interfész is lehet, így
gépeket egy 32-bites egyedi szám, az ún. IP-
több
szám azonosítja (hogy miért IP szám, arról
akár egyetlen hálózati adapterhez is több cím
majd kés®bb). Az IP alapú hálózatok hierar-
tartozhat.) A címhez tartozó eszközt
hálózati
címe
is.
(Bizonyos
esetekben
gazda-
chikus, hardver-független címzési rendszerrel
gép nek (host) nevezik.
rendelkeznek.
ján következtetni lehet annak földrajzi helyére
Minden
egyes
2.2. Hálózati alapfogalmak
csomópontnak
A gazdagép címe alap-
Hálózati architektúrák és protokollok
10
is, egyfa jta postai irányítószámként szolgál.
tógépek nyújtanak és igénybe vesznek. A szol-
Ugyanilyen módon pl. épületet vagy egyéb
gáltatások
hierarchiát is rendelhetünk az IP számokhoz,
is kellett bevezetni. Például, az FTP alkal-
lásd 2.16 ábra. Vegyük észre, hogy az egyes
mazás a 21-es porton veszi fel a kapcsolatot
körökben található gazdagépek címének els®
a
része (a hálózat címe) azonos. Ennek alap ján
helyzetet, hogy a cím és az alcím mellett még
fogunk ma jd
a szállítási protokollt is meg kell adni, hogy
alhálózat okat bevezetni.
megjelölésére
szerverrel,
lásd
2.17
egy
alcímet
ábra.
(port)
Bonyolítja
a
egyértelm¶ legyen a szolgáltatás kijelölése. A Bár
a
gazdagépeket
(pontosabban
azok
hálózati illeszt®kártyáját) egyértelm¶en meghatározza IP-címük, a ra jtuk futó különféle alkalmazások azonosításához címkiterjesztésre (port, 16 bites) van szükség. A TCP/IP rendszerben (lásd a következ® szakaszt) van egy olyan
mechanizmus,
amelyik
lehet®vé
szabványos szolgáltatások (well-known ports) az
1024
alatti
portokon
vehet®k igénybe,
a
többit a felhasználók tetsz®leges célra vehetik igénybe. (RFC
Néhány
1700
(l.
ilyen
szolgáltatás
adatait
http://www.rfc-editor.org/rfc/
rfc1700.txt) a 2.1 táblázat sorolja fel
teszi,
hogy a hálózati adatokkal bizonyos alkalmazásokat az
címezzünk
UDP
keresztül.
protokoll Az
IP
meg,
vagy
a
TCP
használatával,
címet
és
a
vagy
portokon
portot
együtt
nevezik socketnek.
2.1. táblázat. "Jól ismert" portcímek
Név
Port/protokol
Megjegyzés
echo
7/tcp
echo
echo
7/udp
echo
ftp-data
20/tcp
#File Transfer (default)
ftp-data
20/udp
#File Transfer (default)
ftp
21/tcp
#File Transfer (control)
telnet
23/tcp
telnet
telnet
23/udp
telnet
smtp
25/tcp
mail # Simple Mail
smtp
25/udp
mail # Simple Mail
http
80/tcp
# WWW http
http
80/udp
# WWW http
Emellett vannak RFC-ben nem rögzített, de szintén szabványosan használt ún. regisztrált portok (a WINS (1512), NFS (2049), X11 (6000 - 6063) protokollok számára).
c 2004
Természetesen, ha minden egyes szolgálta-
by Sams Publishing/J. Casad
tás számára elindítanánk egy saját démont, 2.17. ábra. A port egy bizonyos alkalmazás
akkor a memória tele lenne tétlen szerverekkel.
címét jelenti
A ténylegesen alkalmazott megoldást a 2.18 ábra mutatja.
A lózati
socketek
alapvet®
kommunikáció
kommunikáló
jelent®ség¶ek
szempontjából:
processz
mindegyike
a a
hákét
létrehoz
egy-egy socketet. A kapcsolatot a socket pár
Egy master server eljárás várakozik a bejöv® kérésekre. Amikor kérés érkezik egy klienst®l, a master server létrehozza a kapcsolatot, majd elágaztatással (forking) elindít egy child server
megadásával is leírhatjuk, pl.
(41.199.222.3:80, 177.41.72.6:3022)
folyamatot.
A
child
server
folyamat
kezeli a kliens kérését, a master server pedig visszatér várakozó alapállapotába.
egy WEB-szerverrel létrehozott kapcsolatot ír le. Id®vel
A kialakultak
olyan
szokásos
hálózati
feladatok (szolgáltatások), amelyeket a számí-
2.2. Hálózati alapfogalmak
kapcsolatfelvételhez
a
két
partnernek
ismernie kell egymás teljes címét. A következ® példa
mutatja,
hogyan
lehet
elérni
a
küld®
Hálózati architektúrák és protokollok
c 2004
11
http://www.fmc-modeling.org 2.18. ábra. Az inetd szerver m¶ködése
át
kapja
kérést,
meg
és
az
A
válaszát
számítógépt®l
az
A
a
számítógép
forráscímeként feltüntetett címre küldi. A B számítógépen futó alkalmazás által az A számítógépen futó alkalmazásnak
c 2004
by Sams Publishing/J. Casad
küldött üzenetekben ez a socket cím lesz a cél címe.
2.19. ábra. Port információk cseréje kapcsolatfelvételkor
A (kezdeményez®) kliens alkalmazás id®leges (ephemeral) port számokat használ, azaz
gépr®l socketen keresztül a célgép egy alkal-
a
mazását:
alkalmával általában más és más számot kap.
1. Az A számítógép kapcsolatot kezdeményez a B számítógéppel egy jól ismert port címen. A legtöbb közismert alkalmazásnak UDP zat.
ilyen
címe
szolgáltatásként, A
küldött
van, lásd
üzenet
TCP 2.1
egyik
számítógépnek
milyen
port
port
különböz®
kapcsolatfelvételek
2.2.3. Kapcsolatmentes és kapcsolatalapú protokoll
vagy táblá-
mez®je
tartalmazza azt az információt, hogy a B
kliens
A szóban forgó megoldás megkívánt min®ségi szintjét®l függ®en, a fejleszt®k kétféle típusú hálózati protokoll típust használnak:
számot
kell használnia, amikor információt küld
•
kapcsolatmentes protokoll (lásd 2.20 áb-
vissza az A számítógépnek. Ez lesz az A
ra)
esetén
számítógép forrás socket címe, lásd 2.19
az
ábra.
hogy értesítse a fogadó számítógépet az
adatokat
adatok 2. A B számítógép egy jól ismert porton
2.2. Hálózati alapfogalmak
a
pedig
küld® és
nem
elküldésér®l. csak
egyszer¶en foglalkozik
A
megkapja
cél az
elküldi azzal,
számítógép adatokat
és
Hálózati architektúrák és protokollok
12
2.2.4. Adatcsomagolás Az
adatcsomagolást
a
mindennnapi
életben
is használjuk, l. 2.22 ábra: leveleinket több papírra nyomtatjuk, azokat a postázóban méretükt®l függ®en több borítékba is helyezhetik, független szállító viheti a címzetthez. A hálózatok világában is hasonló a helyzet: az
c 2004
egyes
rétegeknek
felbontatlanul
by Sams Publishing/J. Casad
csomagot, 2.20. ábra. Kapcsolatmentes protokoll
kell
ehhez
egymástól
függetlenül,
továbbküldeni
újból
be
kell
a
kapott
csomagolni
azt. Mindegyik protokoll létrehozza továbbítás céljára szükséges protocol data unit (PDU) csomagot, ami a továbbítandó adatból és a protokoll számára szükséges fejzetb®l áll. Ez a az
csomag
lesz
alatta
a
lev®
service
data
unit
következ®
réteg
számára.
(SDU) A
2.23 ábra szerinti diagram bal oldala a küld® csomópont 7. rétegének PDU-ját mutatja, ami a 7. réteg fejzetéb®l (L7H) és az alkalmazás adatából áll. Amikor ez átkerül a 6. rétegbe, ott ez lesz a 6. réteg SDU-ja. A 6. réteg elébe teszi sa ját fejzetét (L6H), hogy létrehozza a
6.
réteg
PDU-ját,
amit
aztán
átad
az
5.
rétegnek. Ez a csomagolási folyamat egészen a 2. rétegig folytatódik, ami létrehozza a 2. rétegbeli PDUt (ebben az esetben fejzetet és kifutót is adva hozzá), ami bitekké alakítódik és
átkerül
az
1.
rétegbe.
Mint
azt
a
2.23
ábrán látjuk, a fogadó csomópontban (jobb
c 2004
by Sams Publishing/J. Casad
oldali oszlop) a folyamat fordítva megy végbe:
2.21. ábra. Kapcsolat-alapú protokoll
minden
réteg
lehámozza
a
csak
neki
szóló
fejzetet, míg végül az alkalmazás megkapja a küld® alkalmazás adatát.
nem
foglalkozik
azzal,
hogy
a
küld®
számítógépnek státuszjelentést küldjön. A hálózatokon az adatokat üzenetek for-
•
a kapcsolat-orientált protokoll (lásd 2.21
májában
ábra) a kommunikáló számítógépek kö-
három részb®l állnak, l. 2.24 ábra:
zött kapcsolatot hoz létre és tart fenn az
Header
adatátvitel ideje alatt. Más szavakkal, a hálózaton átküldött minden egyes csomagra válasz érkezik, státusz információ jelzi az adatátviteli hibákat és szükség esetén a csomag ismételten elküld®dik. Az adatátvitel végén a küld® és fogadó számítógépek rendezett módon befejezik a kapcsolatot.
2.2. Hálózati alapfogalmak
viszik
át.
Az
üzenetek
jellemz®en
vezérl® információ az adatok értel-
mezésér®l
Data/payload
maga a hasznos adat; gyak-
ran továbbításra becsomagolva
Footer/trailer
a headerhez hasonló, sokszor
nincs szükség rá
Hálózati architektúrák és protokollok
c 2004
13
Cisco Press/M. J. Castelli 2.22. ábra. Adatcsomagolás hagyományos módon
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
2.23. ábra. Adatcsomagolás network stack módon
c 2007
c 2005
by http://www.networkguruz.com
2.25. ábra. Adatcsomag nevek a különböz®
by http://www.tcpipguide.com/C. M. Kozierok
rétegekben 2.24. ábra. A hálózati üzenetek formája kis ikonnal. Az egyes rétegek feladatai: Bár
a
csomagolási
elvek
egységesek,
és
mindegyik réteg adatcsomagokkal dolgozik, az egyes
rétegekben
az
adatcsomagok
neve
is
eltér, lásd 2.25 ábra. Ez könnyebben azonosíthatóvá teszi, hogy melyik rétegr®l beszélünk.
2.3. A hálózat megvalósítása 2.3.1. Hálózat-speci kus rétegmodellek
Alkalmazási (7)
az
alkalmazások
m¶ködé-
séhez szükséges szolgáltatásokat biztosítja (pl. fájl átvitelhez elnevezési konvenciók gyelembe vétele)
Prezentációs (6)
információ-értelmezési
problémák feloldása
Session (5)
az alkalmazások közötti dialógu-
sok kezelése
A hálózati rétegek elhelyezkedését lásd a 2.26 ábrán, a rétegek feladatára emlékeztet®
Szállítási (4) áramlást
2.3. A hálózat megvalósítása
két
csomópont
közötti
összeköttetést biztosítja, szabályozza az
Hálózati architektúrák és protokollok
14
az alkalmazási réteget látja, középtájt olyan feladatok valósulnak meg, amelyek más számítógépek (a hálózat) eléréséhez szükségesek, alul pedig a zikai összekötéshez szükséges eszközök m¶ködnek. (Érdemes meg gyelni, hogy a fels®bb rétegeket nagyobbrészt szoftveres, az alsókat nagyobbrészt hardveres módon valósítják meg.) Egy hálózati kapcsolat megvalósításához mindezeknek egymással összhangban, perfekt módon kell m¶ködniük!
c 2004
by Cisco Press/M. J. Castelli
2.27. ábra. Az OSI üzenetküldési modellje
Hálózati adattovábbítás során az adatok a hétréteg¶ OSI modell egyik rétegéb®l a má-
c 2004
sikba haladnak, a küld® állomás alkalmazási
The Computer Language Co Inc
rétegéb®l kiindulva. A vezérlés a modellben 2.26. ábra. Az OSI 7 réteg¶ modellje
felülr®l lefelé halad, lásd 2.27 ábra, ma jd az állomások közötti zikai kapcsolaton át eléri
Hálózati (3)
hálózati
forgalmazást
biztosít
(összekötés, címzés és útvonalválasztás)
Adatkapcsolati (2) adatátvitelt hálózati zikai
( zikai
topológia,
címzés,
közeghozzáférés,
hiba jelzése,
a
keretek
rétegek igen
az
a
2.26
feladata
eltér®.
réteg a küld®
n-edik
n-edik réteg által küldött adato-
kat kapja meg, azaz
virtuálisan
ezek a rétegek
a k -adik réteg szolgáltatást k + 1-ediknek és igénybe veszi a k − 1-
Általában, jeltovábbítás, jól speci kált elekt-
romos, optikai és mechanikai jellemz®k Mint
Adatkommunikáció során a fogadó
vannak kapcsolatban.
sorrendhelyes kézbesítése)
Fizikai (1)
felfelé haladva, eléri a legfels® réteget.
megbízható
biztosít
átvitel
a fogadó állomást, és ott modell rétegekben
A
és
ábrán
látható,
az
megvalósításának
felhasználó
2.3. A hálózat megvalósítása
csak
a
egyes módja
legfels®,
nyújt a
edik réteg szolgáltatásait. Mivel (virtuálisan) a két
k -adik
réteg áll kapcsolatban, lásd 2.28
ábra, a kommunikáció (protokoll) tárgyalásakor elég erre a szintre szorítkozni.
Hálózati architektúrák és protokollok
c 2004
15
by Cisco Press/M. J. Castelli
2.28. ábra. A szolgáltatások és protokollok viszonya
A
2.26
évekig
ábrán
tartó
gyobbrészt
bemutatott
szabványosítás tisztán
rétegszerkezet
eredménye.
szétválasztja
a
Na-
rétegek
funkcióit, és a részletes elvi leírás mellett jól használható lenne a gyakorlatban is. Közben azonban
kialakult
egy
másik,
a
gyakorlati
szakemberek által el®nyben részesített rétegmodell (lásd 2.29 ábra) is. Ez utóbbi, TCP/IP
c 2004
by Sams Publishing/J. Casad
2.29.
ábra. Az
OSI és
a TCP/IP
modell
összevetése
stack modellben a gyakorlat igényeinek meg-
felel®en kevesebb réteg van: az OSI modell leg-
kétpontos hálózatok
fels® három rétegének funkciói között gyakran
számítógép
fordulnak el® üresek, és funkció juk sem mindig
(point-to-point
válik szét az OSI modellnek megfelel®en; ezért
küldés (unicasting) névvel is illetik.
a TCP/IP alkalmazási rétege felel meg az OSI
A kapcsolat közbüls® gépeken, kü-
alkalmazási, prezentációs és session rétegének.
lönböz® útvonalakon jön létre.
Az OSI modell három extra rétege még több járulékos felosztást tesz lehet®vé, ami tulajdonságokat a TCP/IP tervez®i az alkalmazási réteg fejzeteiben vettek gyelembe. Hasonlóképpen összeolvad a hálózat zikai elérésének funkcionalitása az alsó két rétegben. A többi réteg funkcionalitása nagyobbrészt egymásnak megfeleltethet®.
2.3.2. Hálózati hardver
network).
össze Egyes-
Méret (processzorok távolsága) szerint
1 m Személyi 100 m Lokális 10 km Városi 100 km Országos 10.000 km Internet rét megvalósítás, a használt hálózati eszközök, a technikai megoldások jelent®sen különböznek, ezért azokat csak a technikai ismeretek
Funkció szerint
kötnek
A különböz® típusú rendszerek esetén a konk-
A hálózatok felosztása:
•
•
párokat
elsajátítása után tárgyaljuk. adatszóró hálózatok m¶ködési
elvük
lehet
adatszó-
2.3.3. Hálózati szoftver
rás (broadcasting) vagy többesküldés (multicasting); aszerint, hogy a
A számítógépek hardveres összekötése után a
küldemény mindenkinek vagy csak
következ® (és a hálózatok használatának rob-
bizonyos csoportnak szól.
banásszer¶ terjedése miatt, mind fontosabb)
2.3. A hálózat megvalósítása
Hálózati architektúrák és protokollok
16
lépése az összekötés szoftverének megteremtése. Mint azt a 2.26 ábra mutatja, a tervezés bonyolultságának csökkentése érdekében, rétegeket (layer) vagy szinteket (level) alakítanak ki. Sok esetben a hardver és szoftver határok is elmosódnak. A rétegek szolgáltatást nyújtanak a felettük elhelyezked® rétegnek és igénybe veszik az alattuk lev® réteg szolgáltatását, lásd 2.30 ábra. A két partner azonos szint¶ rétegei tudnak egymással kapcsolatba lépni, a közöttük lev® rétegek közvetítésével. Természetesen ez csak logikai kapcsolat, a zikai kapcsolat a mélyebb rétegek felhasználásával jön létre.
c 2004
by Sams Publishing/J. Casad
2.31. ábra. A hálózat er®sen egyszer¶sített m¶ködése
kiszolgálási igényeket az alkalmazások rendszerhívások formájában jelezhetik, lásd 2.32 ábra.
A
*nix
operációs
rendszerek
alatt
minden FILE-ként kezelend®; ez alól a hálózat sem kivétel. Az erre a célra szolgáló socket kezeli (küldi és fogadja) az adatokat. Végs® soron A
ez
is
Windows
FILE, is
közvetlenül
hasonló
pipe.
pedig
rendszert
vett
át,
árnyalatnyi eltérésekkel. Mivel az operációs rendszer szolgáltatásai technikailag (egyetlen
c A.
sokféleképpen
könyvtár
megvalósíthatók
függvényeinek
hívásával,
deamon/service formájában, driverként, stb.),
S. Tanenbaum: Computer Networks
az esetek nagy részében marketing is befolyá2.30. ábra. Rétegek, protokollok és interfé-
solja a konkrét megvalósítást. Néhány esetben
szek
a technikai megvalósítás eldönti a problémát: a számítógép er®forrásainak kezelése mindig
2.4. A hálózati szolgáltatás
az
2.4.1. Számítógépünkben
sultságot követelnek, az alkalmazások nom-
A
felhasználó
alkalmazáson másik
egy
számítógépen
lép
futó
kliens
jelleg¶)
kapcsolatba
(általában
egy
szerver
jelleg¶) alkalmazással, lásd 2.31 ábra. A kapcsolat
megteremtéséhez
rendszer
hatásköre.
Emiatt
a
beállításai viszont a felhasználóra maradnak.
(általában
keresztül
operációs
hálózati alapbeállítások rendszergazdai jogo-
megfelel®
hardveres
(hálózati interfész) és szoftveres (az operációs rendszer által biztosított protokollkészlet)
A határesetekben többnyire a használhatóság a dönt® tényez®. A zikai eszközök kezelését eszköz speci kus meghajtók végzik, a hálózati funkciókat rendszerhívások és rendszer-szint¶ függvényhívások segítségével lehet elérni.
2.4.2. Szolgáltatóknál
feltételek szükségesek. A
hálózat
m¶ködtetése
az
operációs
rend-
szert®l rendszerszint¶ er®forrásokat igényel; a
2.4. A hálózati szolgáltatás
Bár
általában
a
felhasználó
nem
kerül
Hálózati architektúrák és protokollok
c 2004
17
by Sams Publishing/J. Casad 2.32. ábra. Adat be- és kivitel hálózati adatforgalom során
velük közvetlen kapcsolatba, jó tudni, hogy
1996/standorg/standorg.htm)
a legfels®bb szint¶ kapcsolódási lehet®ség a
Advisory
hálózat elérési pont (
Engineering Task Force (IETF), stb.)
Network Access Point, NAP ). A szolgáltatók (Internet Service Provider, ISP ) egy csatlakozási pontot (Point of Presence, POP ) bérelnek és a hálózat el-
•
Board
mindenki
egyazon
(Internet
(IAB),
nyelven
Internet
(TCP/IP)
beszél
érésére, forgalomirányításra saját szervereiket használják. A nagyobb szolgáltatók gyakran kisebb szolgáltatókat is kiszolgálnak.
Az In-
ternet zikailag összekapcsolt ilyen rendszerek sokaságából áll. Jellemz® használati módját és elérési lehet®ségét mutatja a 2.33 ábra. Elég távolról valóban ködnek látszik. Közelebbr®l is megnézve, nem találunk valamiféle központot: egyszer¶en csak mindenütt jelen van. Hogy mégis egységesnek tekinthet®, annak okai:
•
bizonyos közös szabályokat mindenki betart (elnevezési szabályok, protokollok,
3. A hálózat rétegmodellje Bonyolult m¶ködés¶ rendszerek esetén általában
az
ún.
rétegelt
megvalósítást
szokták
alkalmazni. Ez azt jelenti, hogy a részletek ismerete
nélkül,
a
bonyolult
m¶ködtetést
a
megfelel® hardverre/szoftverre bízva használhatjuk a megfelel® eszközt vagy szolgáltatást. Pl. a mindennnap használatos személyi számítógépeink esetén is rétegelt rétegelt felépítés használatos: az alkalmazások operációs rend-
stb)
szeren futnak, az operációs rendszer megha jtó
•
vannak
a
foglalkozó (l.
3. Rétegek
kezeléssel
és
nemzetközi
m¶ködtetéssel szervezetek
http://www2.rad.com/networks/
egységeken eszközökkel,
keresztül a
kommunikál
meghajtók
a
hardver
m¶ködésükhöz
a
Hálózati architektúrák és protokollok
18
•
könnyebb hibát keresni
•
egyszer¶en kicserélhet®
•
könnyebben tanulható
3.1. A hálózat 7-réteg¶ OSI modellje A
gyakorlatban
legtöbbször
a
TCP/IP
rétegszerkezetet használják az OSI rétegszerkezet helyett. Ennek néhány jellemz® proto-
c 2004
kollját mutatja a 3.1 ábra. Az egymás mellett
by Sams Publishing/J. Casad
feltüntetett
2.33. ábra. A hálózat elérésének legfels®bb
rétegben,
szintjei
hetnek.
BIOS (Basic Input/Output System) szolgáltatásait veszik igénybe. A hálózatok esetén hihetelenül bonyolult mind a felépítés, mind a m¶ködés. Ha nem teremtünk benne rendet, a
?? ábra bal oldalán
protokollok
egymással
a
megfelel®
párhuzamosan
szint¶ m¶köd-
4. Az OSI modell alkalmazási (7.) rétege I. 4.1. Áttekintés
mutatott módon kaotikus, átláthatatlan lesz a m¶ködés. A hálózatokat célszer¶en szintén rétegelt felépítés¶ként lehet jól tárgyalni. A kurzus többféle réteg(szer¶) modellt is tárgyal. Ezek közül a legalapvet®bb az Open Systems Interconnection (OSI) 7-réteg¶ modellje, aminek egyfajta áttekintése a
?? ábra jobb oldalán
A TCP/IP protokollkészlet (TCP/IP's stack) legfels®
eleme
lication
layer),
az
alkalmazási
amelyben
réteg
lazán
összefügg®
hálózati komponensek találhatók, l. ra. és
Az
itt
található
szolgáltatások
az
hálózati alsóbb
(App-
3.1 áb-
alkalmazások
rétegekkel
TCP
és UDP portokon keresztül kommunikálnak,
látható. A kommunikáció folyamatát azért célszer¶
ami önmagában is egy jól de niált interfészt jelent.
rétegekre bontani, mert
Emiatt
az
alkalmazási
réteg
illik
a
legkevésbé a protokollkészletbe, de ebben a
• •
készletben
lex feladat
ni szolgáltatások nem mindig szükségesek a
egy (hierarchikus) protokoll rendszer áttekinthet®bb
•
minden
a protokoll(ok) megadása nehéz, komp-
csak
a
rétegek
réteg szükséges. Az itte-
protokollrendszer m¶ködéséhez, inkább csak a felhasználó kényelmét szolgálják. A réteg komponensei nem párhuzamosak
illeszkedését
(interfész)
kell meghatározni, a m¶ködését nem
abban az értelemben, hogy logikailag hasonlók vagy egyenérték¶ek lennének. Némelyikük csak egyszer¶ segédprogram, amelyik informá-
•
az egyes rétegeket különböz® gyártók is
ciót gy¶jt a hálózati kon gurációról, mások
implementálhatják
felhasználói interfészként (pl. X Window) vagy
•
könnyebb implementálni
•
könnyebb változtatni
3.1. A hálózat 7-réteg¶ OSI modellje
az operációs rendszert támogató interfészként (Application
Program
Interface,
API)
m¶-
ködnek. Van közöttük hálózati szolgáltatást
Hálózati architektúrák és protokollok
c 2005
19
by http://www.tcpipguide.com/C. M. Kozierok 3.1. ábra. A TCP/IP néhány jellemz® protokollja
(fájl- vagy nyomtatókiszolgálást, névfeloldást) nyújtó komponens is.
rendszerek leírására. A gyakorlatban az OSI modell által tisztán
Mint már volt szó róla, a TCP/IP és az
szétválasztott elvi funkcionalitás másként va-
OSI rétegmodellek eltérnek. Az OSI modell
lósul meg: némelyik rétege üres, mások osztott
jelent®sen befolyásolta a hálózati rendszerek
van
fejl®dését, és a jelenlegi, több-protokollos fej-
alábbiakban a TCP/IP értelemben tárgyaljuk
l®dési irány is megnövelte az OSI terminológia
az alkalmazási réteget, de az egyértelm¶ség
és koncepció jelent®ségét. Az alkalmazási réteg
kedvéért a rétegek OSI értelemben vett szá-
szinte minden operációs rendszerrel és hálózati
mozását használjuk.
környezettel együtt tud m¶ködni, és az OSI modell
jól
használható
4.1. Áttekintés
segédeszköz
hálózati
eltér®
sorrendben
valósulnak
meg.
Az
A 7. (alkalmazási) réteg interfészt biztosít a hálózatra kapcsolódó felhasználó és a háló-
Hálózati architektúrák és protokollok
c 2004
20
•
adatok titkosítási kódolása/dekódolása
•
üzenetek tömörítése és kifejtése
•
gra kus formattálás
•
tartalom fordítása
http://www.globalknowledge.com
4.1. ábra. Az OSI alkalmazási (application) rétege
zati eszköz között. A felhasználó ténylegesen
c 2004
ezt a réteget (4.1 ábra) látja, amikor elindít
http://www.globalknowledge.com
4.3. ábra. Az OSI viszony (session) rétege
egy hálózati alkalmazást (pl. böngész® vagy levelez®). Példák a réteg funkcióira:
•
fájlok átvitele
•
hálózati nyomtatás
•
elektronikus levelezés
•
böngészés a WEB-en
•
elektronikus üzenetküldés
c 2004
Az 5. (viszony) réteg (4.3 ábra) különféle szolgáltatásokat nyújt. Létrehoz, kezel és lezár hálózati dialógusokat, nyilvántartja az átvitt bájtok számát. Példák a réteg funkcióira:
•
virtuálisan kapcsolatot teremt alkalmazások között
•
szinkronizálja az adatáramlást
•
dialógusokat hoz létre
•
paramétereket egyeztet
•
adatokat nyugtáz, újraküld
•
fukciócsoportokra osztja a szolgáltatást
http://www.globalknowledge.com Egy alkalmazás számára az API (Application
4.2. ábra. Az OSI megjelenítési (presentati-
Programming Interface) egy olyan függvény-
on) rétege
gy¶jtemény, alkalmazás
amely az
lehet®vé
operációs
teszi,
rendszer
hogy
az
bizonyos
A 6. (megjelenítési) réteg (4.2 ábra) fele-
funkcióit használja, ezeken a függvényeken át
l®s azért, hogy az alkalmazás milyen módon
tud kommunikálni az operációs rendszerrel, pl.
formattálja a hálózatra kiküldend® adatokat,
kapcsolatot
és lehet®vé teszi, hogy az alkalmazás megértse
a
a kapott üzeneteket. Példák a réteg funkcióira:
4.1. Áttekintés
hálózaton
kiépíteni át
és
adatokat
lebontani, írni
és
valamint
olvasni.
A
Hálózati architektúrák és protokollok
21
hálózati API neve socket, részleteit az adattovábbítási
(transport)
rétegnél
tárgyaljuk.
Egy socket lényegében egy IP cím és egy port együttese. Például, az 111.121.131.141 címen a 21-es portot a 111.121.131.141.21 socket cím adja meg.
c 2004
by Sams Publishing/J. Casad
4.5. ábra. Fájl- vagy nyomtató kiszolgáló
Egy kiszolgáló más számítógépek számára nyújt szolgáltatásokat. A nyomtatókiszolgáló nyomtatót kezel és nyomtatási kéréseket teljesít. A fájl kiszolgáló azon az eszközön írási és olvasási kéréseket teljesít.
4.2. A tartománynév (DNS) rendszer A számítógépek hálózatba kötése után gyorsan
c 2004
4.4.
kiderült, hogy nagyon kényelmetlen a számí-
by Sams Publishing/J. Casad
ábra.
Egy
hálózati
tógépek számcsoportokkal megadott számait alkalmazás
API
használni címzéskor, így gyorsan kifejl®dött a számítógép elnevezésének koncepció ja. A há-
szerepe és használata
lózat gyors növekedésével egyre nehezebb volt A hálózati API, (lásd 4.4 ábra), teszi le-
a nevek karbantartása, rendszerezése. A nevek
het®vé egy hálózati alkalmazás számára, hogy
keresését
az ún. protokoll csomaggal (protocol stack)
kellett
kommunikáljon.
használja
A legtöbb operációs rendszernek van egy saját külön rétege arra, hogy az alkalmazási réteg a
fölött
m¶ködjék
felhasználó
lózat
m¶ködését.
explorer.exe A
4.5
és
ábra
az A
és
mintegy
alkalmazás Windows
tipikus
névfeloldást)
bízni. a
Bár
ezt
a
felhasználó
is
a
számítógépre
szolgáltatást közvetlenül,
ritkán
létezése
alapvet® fontosságú a mind nagyobb méret¶ hálózatokban.
elrejtse
el®l
esetén
a
há-
pl.
az
lát el ilyen feladatokat.
egy
(a
fá jlkiszolgálási
A névfeloldás teszi lehet®vé, hogy egy számíese-
ményt mutat. Egy fá jlkérés a hálózaton keresztül érkezik be a protokollrétegeken keresztül a szállítási réteghez, ahol az a fáljkiszolgáló szolgáltatás megfelel® portjához irányítódik.
4.2. A tartománynév (DNS) rendszer
4.2.1. Névfeloldás tógépnevet használhassunk a számítógép IP címe helyett és a rendszer a megadott nevet IP címmé alakítsa. Ilyen módon a szolgáltatók neveket tehetnek közé és (a szolgáltatás
Hálózati architektúrák és protokollok
22
zavarása nélkül) bármikor megváltoztathatják
127.0.0.1
localhost
a hozzá rendelt IP számot.
198.1.14.2
bobscomputer
#Bob's PC
198.1.14.128
r4downtown
##gateway
A DNS rendszerben a névfeloldáshoz szük-
(A
séges adatokat egy vagy több szerveren helyezik el. Ha egy hálózati számítógép a cím helyén nevet talál, megkérdezi a szervert®l a névhez tartozó IP címet. Ha a DNS kiszolgáló rendelkezik a címmel, visszaküldi azt a kérést küld®
számítógépnek.
Ezután
a
számítógép
a
olyan
be
(új
számítógép
jelenik
a A
hatékony,
az
IP
#
szám,
mögött
nagyobb
hierarchikus
mögötte
magyarázó
hálózatokban név
rendszerre
van szükség, amelyik
•
megosztja a névfeloldás felel®sségét speciális névkiszolgálók között. Az egyes ki-
végrehajtja a parancsot. Amikor a hálózatban áll
elején
található,
megjegyzéssel.)
észrevétlenül helyettesíti a nevet a címmel, és
változás
sorok
név
#this machine
szolgálók táblázatokban tárolják a név-
meg
cím hozzárendeléseket, a hálózat többi
vagy valamelyik gép neve megváltozik), a há-
gépe pedig ezekt®l a kiszolgálóktól szer-
lózati adminisztrátornak egyetlen helyen kell
zi be a cím hozzárendelésre vonatkozó
változtatni a DNS kon gurációját; a keresés
információt.
optimalizálható.
•
a
helyi
nevek
minisztrátor
feloldását
jogává
(és
a
helyi
ad-
kötelességévé)
teszi. Más szavakkal, nincs egyetlen központi
adatbázis,
hanem
az
A
hálózat
adminisztrátora felel®s az A hálózatbeli névfeloldásért. Ezek kívül, a hálózat változtatásáért azért
is,
felel®s
hogy
a
személyek
változások
a
felel®sek hálózat
infrastruktúrájában is tükröz®djenek.
A mai megoldást az RFC 1034 (l.
rfc-editor.org/rfc/rfc1034.txt), c 2004
http://www.
RFC
1035
(l.
http://www.rfc-editor.org/rfc/rfc1035.txt) tar-
by Sams Publishing/J. Casad
talmazzák. Alapszempontjai: 4.6. ábra. Névfeloldás helyi fájlból
•
tás
Kezdetben a számítógépnek nevet adtak (gazdagép név, hostname), és a neveket a hozzájuk rendelt címekkel együtt egy fájlban
tárolták,
amit
egy
hosts nev¶
központi
helyr®l
(NIC) le lehetett tölteni. Amikor az operációs rendszer
hosts l.
4.6
számítógépnévvel
fájl ábra.
alapján A
találkozik,
címmé
módszer
kis
tudja
azt
a
mai
egy
operációs
etc/hosts
rendszerek
hálózatok
fájl,
ami
alatt
•
elosztott adatbázis
A rendszer három f® komponensb®l áll:
•
tartománynevek és er®forrás rekordok
•
névkiszolgálók
•
címfeloldó programok
fordítani, (pár
tucat csomópont) esetén ma is használható, a
hierarchikus, tartomány alapú névkiosz-
is
létezik
ugyanilyen
módon
részt vehet a névfeloldásban. Az Internet 80-as
A követelmények eredményezték a tartomány-
évekbeli fejl®désével el®állt nagy hálózatokban
név
azonban megn® a keresési id® és kényelmetlen-
kifejl®dését.
né válik az adatok naprakész karbantartása.
tományrendszer, tervezésekor számításba vet-
Egy példa fájl:
ték, hogy melyik szervereket kell megkérdezni,
4.2. A tartománynév (DNS) rendszer
rendszer
(domain A
DNS
name
névtér
system,
DNS)
többszint¶
tar-
Hálózati architektúrák és protokollok
23
hogy megkapjuk a keresett címet. A gazdagép neve
és
adják
körbevett csomópontok) adminisztrációja (ál-
meg a teljesen kifejtett tartománynevet (fully
talában) egy szervezet feladata: joga és köte-
quali ed domain name, FQDN).
lessége. Egy ilyen zóna egyértelm¶en jellemez-
Az
a
tartománynév
egyes
lekérdez®
együttesen
Az ilyen zónák (az 4.7 ábrán ellipszisekkel
funkciók
ideje
(helyi
keresés esetén) millisecundumtól (több, távoli
het® a gyökérhez legközelebb es® csúcsának tartománynevével.
kiszolgálót érint® lekérdezés) több másodper-
Az
cig terjedhet.
tartománynevek
mindig
tartal-
karakterre végz®dnek.
4.2.2. A DNS névtér felépítése A tartománynevek a felhasználók számára a
abszolút
mazzák a gyökér csomópontot, így mindig .
felhasználói
DNS
nevek
kódolásakor
az
egymás
után
f¶zött címkék elé egy bájtban beírják a címke
Ilyenkor az egyes csúcsokat leíró címkesoro-
karaktereinek számát, a végére pedig '0' érték¶
zat
bájtot tesznek. Pl. a
egymástól
jelennek
A
meg.
tagjait
interfészekben
ponttal
választjuk
el.
A kis- és nagybet¶k azonosnak számítanak,
www.xyzindustries.com
de
név kódolása
jó
gyakorlat
megtartani
a
forrás
eredeti
írásmódját.
[3] w w w [13] x y z i n d u s t r i e s [3] c o m [0] (lásd 4.8
A hierarchia tetején a root (az ún. gyökér) csomópont
áll.
lehet.
nulla
Egy
Ebb®l
csak
egyetlen
hosszúságú
címke
ábra).
darab írja
le;
szövegként . a jele. Az egyazon csomópontból származó, ún. testvér csúcsok egy-egy alkotnak.
Az
azonos
szinten
lev®
szint et
(testvér)
csúcsok címkéinek eltér®knek kell lenni. A csúcstól való távolságuk alap ján az egyes csomópontok ún. szintekbe szervez®dnek, lásd 4.7
ábra.
A
hierarchia
minden
szintjén,
ez
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
egyes csúcsok valamilyen közös jellemz® alap4.8. ábra. A DNS nevek kódolása
ján fogják össze az alattuk elhelyezked® csomópontokat. Ez általában funkcionális (.com a kereskedelmi, .edu az oktatási tevékenységet végz®
intézmények
végz®dése)
vagy
területi
(.hu a magyar, .de a német csomópontok végz®dése); de jelent®s eltérések is lehetségesek. Hasonló felosztás létezik alsóbb szinteken is, pl.
egy
vállalat
alacsonyabb
szint¶
A DNS m¶ködése
épületeket, stb. Az csomópontokat leginkább kétféle szempont alap ján lehet csomópontokra osztani: a csomópontnak megfelel® IP cím alap-
(l.
http://www2.rad.com/
networks/applications/dns/movie0.htm) A nagy rendszerekben elhelyezked® névki-
csomó-
pontjai jelölhetnek osztályokat, telephelyeket,
•
4.2.3. A DNS lekérdezések m¶ködése
szolgálók a helyi gépek kiszolgálása mellett
egymással
is
kapcsolatba
léphetnek.
Név-
feloldási kérés beérkezése esetén a szerver a következ®k valamelyikét teheti:
•
ha
a
keresett
címet
megtalálta
saját
adatbázisában, azt azonnal visszaküldi
ján osztályozni
az ügyfélnek
•
gráfelméleti szempontból, a gráf éleinek átvágásával végzett darabolással
•
ha nem találta meg a címet, megkérdezi a többi névszervert, és így küldi meg a címet az ügyfélnek
4.2. A tartománynév (DNS) rendszer
Hálózati architektúrák és protokollok
24
.
root szint
com
mil
els® szint
net
.
org
edu
hu
de
Debrecen
M icrosof t microsof t
második szint
www
support
dev
mit
IBM
bme
unideb
neptun
harmadik szint
www
inf
IK negyedik szint
www
irh
4.7. ábra. A tartománynévtér felépítése
Kicsit részletezve:
radhatatlanul folytatja: megismétli a kérést,
A DNS névfeloldás azzal kezd®dik, hogy egy
felhasználó
címet,
hanem
tógép
hálózati
egy
egy
ügyfél
nevet
gépen
használ.
alap-beállításának
nem A
IP
számí-
része
egy
DNS kiszolgáló megnevezése is. Els® lépésként
1
(lásd 4.9 ábra
) az alkalmazói program
ennek a kiszolgálónak küldi el a kapott (pl. a
www.unideb.hu)
címet,
és
kéri
az
ennek
megfelel® IP-szám megadását. A DNS kiszolgáló természetesen nem tudja azonnal megadni a választ, ezért megkérdezi
2
a legfels®bb szint¶ (root) névkiszolgálót
.
Annak természetesen nincs kéznél valamennyi elérhet® csomópont címe, viszont tudja, hogy a névtérben melyik kiszolgáló tud a .hu zónára vonatkozóan információt adni, ezért ennek a kiszolgálónak
3
.
A
a
válasz
címét
küldi
ismeretében
meg az
válaszként
ügyfél
gépé-
immár az unideb.hu zónára vonatkozó isme-
mi
a
www.unideb.hu
nev¶
Az
ügyfél
gépének
DNS
eredeti
kérdést
megküld®
megkapja válaszként
8
formációt leteltéig
menteni.
4
marad
az
adat,
:
mi
a
Azonban, még ez a kiszolgáló sem ismeri az összes magyar csomópont adatait, de megint egy lépéssel közelebb visz a célhoz, és válasz-
5
) visszaküldi a Debreceni Egyetem
ügyfél
gépének
DNS
a
elévülési
kérés
id®
els®ként
a
cache DNS-hez fut be. Ha ebben megtalálható a kért információ, akkor gyorsan válaszol a helyi DNS. Ez a válasz viszont nem autentikus.
A
a
felhasználó
végeredmény,
tudta
hogy
az
t®dik a 193.6.128.25 IP számmal, és az ügyfél számítógép ezzel dolgozik tovább. Vegyük észre, hogy a fenti színdarab szerepl®i kétféle módon kommunikáltak egymással. Az ügyfél számítógépének sa ját kiszolgálója addig kérdezgetett, amíg pontos választ nem tudott adni a kérdésre; a többi kiszolgáló pedig
névkiszolgáló jának címét. Az
az
eredetileg beírt www.unideb.hu cím helyettesí-
www.unideb.hu nev¶ számítógép IP száma?
ként (
) a kért IP számot.
Ebben
le.
feltéve
számítógép
gyorsítótárakba (cache) szokták a kapott in-
za jlik
kiszolgálónak
ügyfél
els®dleges információforráshoz fordulni, ezért
nélkül
rendelkez®
.
most
Természetesen id®veszteséget jelent mindig az
immár a .hu zónára vonatkozó ismeretekkel
a
kiszolgálója
már tud válaszolni az eredeti kérdésre, így az
folyamat
megismétli
7
forgó csomópont IP számát küldi vissza
egész
kiszolgálója
:
IP
lehet a válasszal: az egyetemi szerver a szóban
Az
DNS
számítógép
száma? És, ezúttal teljes mértékben elégedett
kérést,
nek
6
retekkel rendelkez® kiszolgálónak feltéve
kiszolgáló ja
4.2. A tartománynév (DNS) rendszer
fá-
egy fokkal jobb közelítést mondott a kérdez®-
Hálózati architektúrák és protokollok
25
root 2
rekurzív lekérdezés
3
root DNS
com
hu 4
5
saját DNS 7 1
6
8
unideb
hu DNS
www DNS kliens iteratív lekérdezés unideb.hu DNS
4.9. ábra. DNS névfeloldás rekurzív és iteratív módon
fordított
nek, de az csak egy utalás volt a kérdést jobban ismer® névkiszolgálóra. Az el®bbi válaszolási módot
rekurzív,
az
utóbbit
pedig
iteratív
.
normál
.
lekérdezésnek nevezik. Mint az el®bbi példából arpa
látható, a kett® eredményesen kombinálható.
net
edu
hu
A hierarchiában magasabb szinten álló gépek in − addr
inkább lev®k
az
iteratív,
pedig
a
az
alacsonyabb
rekurzív
technikát
mit
szinten
részesítik
157
unideb
193
inf
6
www
bme
www
el®nyben. Természetesen, a végeredmény nem csak az lehet, hogy megkap juk a kért IP címet. A
128
felhasználó hibás címet is írhat be, valamelyik zóna
adminisztrátora
is
tévedhet,
továbbá
25
el®fordulhatnak átmeneti technikai hibák is. A
névkiszolgálók
természetesen
(hibakódok
formájában) közlik a kezdeményez® számítógéppel a hiba el®fordulását és rá bízzák annak kezelését.
4.10.
ábra.
A
tartománynévtér
a
fordított
keresési ággal Néha (pl. biztonsági ellen®rzés során) felmerül
az
az
igény,
hogy
az
adatbázisban
hogy ahhoz milyen tartomány név tartozik.
fordított irányban keressünk. Azaz, ilyenkor
A
ismerjük
használhatatlanul
az
IP
számot,
de
nem
ismerjük,
4.2. A tartománynév (DNS) rendszer
tartománynevek
elosztott
lassan
adatbázisában
lehetne
kikeresni
a
Hálózati architektúrák és protokollok
26
már megismert úton egy megadott IP címhez tartozó
tartománynevet.
Hogy
a
fordított
gráfnak
egy
éle
külön
az
ilyen
irányú
•
a
rendszer
a
arpa
módon keres: a számot az tartomány keresi,
in − addr
ma jd
a
már
ismertetett
paraméterei.
cím
•
Válasz
központozott
alakjának sorban els®, második, harmadik és negyedik számcsoportját használja címkeként. A
193.6.128.25
IP
tulajdonképpen
a
tartománynevet
szám
A kérdéses név, és a kérdés egyéb
legfels® szint¶
nev¶ altartományában
megadott
különböz®
Kérdés
tott feliratú ellipszisben lev® csomópontokat. esetben
a
query stb.) elkülönítésére.
keresést szolgálja, lásd a 4.10 ábrán a fordí-
Ilyen
bitkombináció
kérdések (pl. standard query, status
irányú keresés gyorsabb legyen, a névtérben a
Egy
megadásakor
•
tehát
A kérdéshez tartozó direkt válasz.
Hitelesség
25.128.6.193.in-addr.arpa. keresi meg és a lekérdezés
A
hiteles
szerverek
adatait
leíró
rekordok.
eredménye a www.unideb.hu tartománynév. A mind
fenti a
információkat
két
felét)
(az
ugyanaz
•
információnak az
További adatok
adatbázis
tartalmazza, ugyanazok az adminisztrátorok
formációk (RR).
kezelik. Redundáns és hibalehet®séget is rejt, de
mindkét
irányból
gyorsan
kereshet®
A kérdéshez kapcsolódó egyéb in-
az
4.3. Fájl átvitel
adatbázis.
A DNS rendszerben a névfeloldáshoz szükséges adatokat egy vagy több szerveren helyezik el. A névfeloldáshoz szükséges információt ún. er®forrás rekordok (resource record, RR) tárolják egy adatbázisban. Hatékonysági okokból bináris formában tárolják, de egyszer¶ ASCII forrásként ábrázolják, egysoros bejegyzésként. A leggyakrabban használt típusokat a 4.2 táblázat mutatja. Egy lehetséges DNS-adatbázis
A
fájlok átvitele
között
az
els®
hálózatba
alkalmazások
kapcsolt egyike
gépek
volt,
az
ilyen igény jelent®sen motiválta a hálózatok kialakítását.
net ben
Sokszor
egy
fájt
üze-
egyetlen
visznek át. A fájlok átvitelére speci-
alizált protokollok közül az FTP és a TFTP protokollt említjük meg. Ezek a legegyszer¶bb feladatot
oldják
meg:
adatokat
visznek
át
egyik számítógépr®l a másikra.
tartalmat a 4.11 ábra mutat. Amikor a hálózatban változás áll be (új számítógép jelenik meg vagy valamelyik gép neve megváltozik), a hálózati adminisztrátornak egyetlen helyen kell változtatni a DNS kon gurációját; a keresés optimalizálható. A szervezeten
belüli
kiszolgálását
a
sa ját
szerver
altartományok delegálhatja
név-
az
al-
tartomány szerverének. Ilyen módon az adminisztrátorok
vezérelni
tudják
a
megfelel®
tartományban a név-cím hozzárendelést.
4.3.1. File Transfer Protocol (FTP) A fá jl átvitel fontosságát jól mutatja, hogy az ®s-FTP (RFC 114 (l.
http://www.rfc-editor.
org/rfc/rfc114.txt))
jóval
megszületett,
a
z® (l.
mint
protokollok.
Mai
el®bb
hálózat formáját
(1971-ben)
alapját az
képe-
RFC
959
http://www.rfc-editor.org/rfc/rfc959.txt) ír-
ja le. Mint a neve is mutatja, általános fájl átvitelre való. Nem igazán egyszer¶, de nagyon sok szolgáltatást nyújt.
A DNS lekérdezések és válaszok formátuma (lásd 4.12 ábra):
Az
klienst
•
Fejrész
4.3. Fájl átvitel
FTP
m¶ködési
szerver-kliens
user
közvetlenül
modellen
módja
a
alapszik,
klasszikus bár
itt
a
névvel illetik, mivel a felhasználó m¶ködteti.
Fontos
megemlíteni,
Hálózati architektúrák és protokollok
27
4.2. táblázat. A legfontosabb DNS er®forrás bejegyzés típusok)
Típus
Jelentés
Érték
SOA
Lista kezdete
Ehhez
a
zónához
tartozó
paraméterek A
Egy hoszt IP címe
32-bites egész
MX
Levél csere
A levelet fogadó körzet
NS
Névszerver
Egy körzethez tartozó szerver neve
c 2003
CNAME
Kanonikus név
Körzetnév
PTR
Mutató
Álnév egy IP-címhez
HINFO
Hoszt leírás
CPU és oprendszer leírás
TXT
Szöveg
Tetsz®leges ASCII szöveg
by Prentice Hall/A. S. Tanenbaum 4.11. ábra. Egy lehetséges DNS-adatbázis
hogy
(a
eltér®en) 4.13
hasonló
alkalmazások
két logikai csatornát
ábra.
A
vezérl®
többségét®l
csatorna
is használ, lásd
csatorna
csak a tényleges átvitel ideje alatt.
felel®s
Szerver és klines oldalon
folyamatosan
létezik a két partner között, az adat csatorna
kezeléséért
illetve
PI
USER-DTP
folyamat.
SERVER-DTP,
a neve.
A vezérl® csatornán kapott utasítások értelmezéséért felel (Protocol Interpreter).
DTP
A kapcsolat létrehozásáért és az adat-
4.3. Fájl átvitel
Eltér®
funkciói
vannak
a
kliens
és
a
Hálózati architektúrák és protokollok
c 2005
28
by http://www.tcpipguide.com/C. M. Kozierok 4.12. ábra. A DNS lekérdezések formátuma
felhasználói
utasítások,
bet¶vel
FTP
az
jobb
protokoll
oldalon
ennek
vastag
megfelel®
utasításai, és a többi válasz látható.
Az FTP utasítások alapvet®en három csoportba sorolhatók:
c 2008
•
Hozzáférés vezérlés
•
Adatátviteli utasítások
•
Szolgálati utasítások
by http://en.kioskea.net A 4.13. ábra. Az FTP modell
kérésekre
adott
válaszok
számokat
és
szöveget tartalmaznak; a felhasználói interfész könnyedén értékeli a válaszokat a számok alap-
szerver oldalon:
ján, a felhasználó könnyen megérti a szövegek
• SERVER-PI által
a
gyeli
vezérl®
a
USER-PI
csatornán
küldött
alapján. A felhasználó egy interfész programmal áll kapcsolatban, amely
utasításokat, létrehozza az adatcsatornát, fogadja és megválaszolja a
USER-PI
által küldött utasításo-
kat, futtatja a
• USER-PI
SERVER-DTP -t.
felel®s a kapcsolat létre-
•
felhasználóbarát
•
a felhasználóhoz igazítható
•
egyszer¶síthet®, absztrahálható
hozásáért a szerverrel, utasításokat küld és fogad, szükség esetén vezérli
USER-DTP -t
4.3.2. Trivial File Transfer Protocol (TFTP)
A 4.3 táblázat egy fá jl letöltésének menetét
Az FTP sok mindent tud, de bizonyos (pl.
mutatja
oldali
beágyazott) gépeken nehéz implementálni, és
adott
legtöbb funkciójára nincs is szükség. Ha a kis
FTP
oszlopban
a
használatával.
kliens(user)
4.3. Fájl átvitel
A
bal
programnak
Hálózati architektúrák és protokollok
29
4.3. táblázat. Egy fá jl letöltése FTP protokollal
Felhasználói utasítás
FTP protokol utasítás/FTP szerver válasz Connected to pcguide.com. 220 ftp199.pair.com NcFTPd Server (licensed copy) ready.
ftp -d pcguide.com
Name (pcguide.com:ixl):
USER ixl
ixl
331 User ixl okay, need password.
PASS XXXX
230-You are user #1 of 300 simultaneous users allowed. 230-Welcome to (<system name>) 230 Logged in.
SYST
****
215 UNIX Type: L8 Remote system type is UNIX. Using binary mode to transfer les.
PASV
227 Entering Passive Mode (ip1,ip2,ip3,ip4,193,224)
LIST
150 Data connection accepted from ip5.ip6.ip7.ip8:4279;
dir
transfer starting. -rw-r-r- 1 ixl users 16 May 22 17:47 test le.txt 226 Listing completed.
TYPE A
asc
200 Type okay.
PASV
227 Entering Passive Mode (ip1,ip2,ip3,ip4,193,226)
RETR test le.txt
150 Data connection accepted from ip5.ip6.ip7.ip8:4283;
get test le.txt
transfer starting for test le.txt (16 bytes). 226 Transfer completed. 17 bytes received in 0.10 seconds (0.17 KB/s)
QUIT
quit
221 Goodbye.
méret és egyszer¶ implementálás fontosabb,
elegend® a Trivial File Transfer Protocol (TFTP) is, ami lényegében a File Transfer Protocol (FTP) lecsupaszított változata. B®vebben lásd pl. [?] (l. http://
•
akkor
www.tcpipguide.com/free).
protokol
azt
teszi
teszi
közvetlenül
egy
lehet®vé.
lehet®vé,
távoli
egyszer¶ kommunikációs protokol
•
de: Network Virtual Terminal (NVT)
gött
hogy
A
köz-
Telnet
egy
helyi
számítógépnél ül® felhasználó ugyanúgy dolgozhasson
•
(A Telnet viszonylag egyszer¶ m¶ködése mö-
A fájlok átvitele a távoli számítógépek használatát
tot tarthat (különböz® IP/port címeken)
fedi el a m¶ködési részleteket
4.3.3. Telnet - távoli terminál vetett
a szerver gép több klienssel is kapcsola-
számítógéppel,
az
(is)
áll,
hogy
a
partnerek
számos
m¶ködési részletet (opciók) a kapcsolat létrehozásakor megtárgyalnak.) Használatára példa:
$ telnet www.someserversomewhere.org
mintha
ahhoz kapcsolódna. A Telnet f®bb
4.4. Az elektronikus levél
jellemz®i
•
kliens/szerver módszerrel m¶ködik
•
állandó
Az elektronikus levél az egyik legrégebbi és kapcsolatot
épít
ki
a
session
számára
leggyakrabban használt hálózati szolgáltatás. Ez a szolgáltatás abban eltér az összes többit®l, hogy nem számítógépek, hanem felhaszná-
•
jól ismert 23/TCP port címet használ
•
egyetlen adatfolyamot küld
lók közötti kommunikációt valósít meg. Mint a 1.5 ábra mutatja, az elektronikus levél szerkezete nagyon hasonló a hagyományoséhoz.
4.4. Az elektronikus levél
Hálózati architektúrák és protokollok
30
így a
[email protected] név kódolása [6] j o h n n y [9] s o m e w h e r e [3] o r g [0] .
Lásd még 4.8 ábra.)
c 2007
by Wikipedia
4.14. ábra. Elektronikus levélküldés menete
Alice és Bob levelezni szeretnének. Nincs azonban garancia arra, hogy Bob is ugyanakkor van a számítógépénél, mint Alice, ezért a levelezésnek olyan mechanizmust kell használ-
c 2005
by http://www.mcmcse.com
nia, amelyik elválasztja a két számítógép közötti levéltovábbítást (message transfer agent) a felhasználó által használható alkalmazástól
4.15. ábra. A levelezés szerepl®i és protokolljai
(user agent). (A felhasználók leválasztása a hálózatról fontos tervezési elv volt.) A levélküldés menete a 4.14 ábrán látható. A felhasználó által megírt levelet a levél1
Amint említett
azt
DNS
a
4.15
ábrán
protokoll
látjuk,
mellett
két
a
már
további
protokoll is szerephez jut a folyamatban. Az SMTP protokoll f®ként a levelez® kiszolgálók
. Amikor Alice
közötti adatforgalomban használatos, de ezt
elektronikus levelet akar küldeni Bobnak, ak-
használják a levél eljuttatására a klienst®l a
kor ismernie kell Bob címét. Ez a cím két, a '@'
szerverhez is.
továbbító program veszi át
jellel elválasztott részb®l áll. Ennek második fele azt a számítógépet azonosítja, amelyikkel Bob
levelez®
alkalmazása
kapcsolatban
áll.
A legegyszer¶bb esetben a felhasználó levelez® kliense ugyanazon a számítógépen ta-
a
lálható, mint a levélkiszolgáló (azaz, automa-
megtalálása, ezt a levéltovábbító a más megis-
tikusan állandóan on-line van a kliens), lásd
mert DNS szolgáltatás segítségével oldja meg.
4.16 (a) ábra. Ha a kliens csak alkalmanként
Ennek
kapcsolódik
Az
els®
feladat
során
az
ennek
MX
a
számítógépnek
típusú
(lásd 4.2 táblázat) használja.
bejegyzéseket 2
meg
.
Most
már
kapcsolatba
tud
Bob számítógépének levéltovábbítójával és
átadja
a
levelet,
amit
aztán
az
internetre,
a
felhasználó
leveleit el kell kérnie (le kell töltenie) a szer. A választ
Bob számítógépének névkiszolgáló jától kap ja 3
fel
Bob
levelez® alkalmazásával letölt és elolvas
vert®l, lásd 4.16 (b) ábra. A levelek letöltésére a szerverr®l a kliensre a POP3 vagy IMAP
lépni
protokollok valamelyikét használják. A POP3
4
és IMAP protokollok néhány tulajdonságának
,
saját 5
.
Bob számítógépe a '@' el®tti címrészb®l azo-
összehasonlítását mutatja a 4.4 táblázat.
4.4.1. Az SMTP protokoll
nosítja a címzettet. (A DNS keresés során a '@' karakter a '.' karakterrel helyettesít®dik,
A Simple Mail Transfer Protocol (SMTP) a levelez®rendszer
4.4. Az elektronikus levél
legfontosabb
része,
a
25-ös
Hálózati architektúrák és protokollok
c 2004
31
A. S. Tanenbaum: Computer Networks 4.16. ábra. A levelezés állandó internet kapcsolattal és anélkül
4.4. táblázat. A POP3 és IMAP protokollok összehasonlítása
Tulajdonság
|
POP3
De níció ja
| RFC
| 1939
IMAP
http: | RFC
(l.
2060
http:
(l.
//www.rfc-editor.org/
//www.rfc-editor.org/
rfc/rfc1939.txt)
rfc/rfc2060.txt)
Használt port/protokoll
| 110/TCP
| 143/TCP
E-mail tárolása
| Felhasználói PC
| Szerver
E-mail olvasás helye
| O-line
| On-line
Kapcsolat ideje
| Kevés
| Sok
Szerver er®forrás igény
| Kevés
| Sok
Több levél ók
| Nincs
| Lehetséges
Leveleket menti
| Felhasználó
| ISP
Mobil felhasználásra jó?
| Nem
| Igen
Letöltés vezérlési lehet®ség
| Kicsi
| Nagy
Részleges letöltés
| Nincs
| Van
Tárolási kvóta problémák
| Nincs
| Lehet
Egyszer¶ implementálni?
| Igen
| Nem
Széleskör¶en támogatott?
| Igen
| Növekszik
portot használja. A levelek célba juttatásá-
Létezik egy kiterjesztett változata is (extended
ért felel®s. Az alsóbb rétegek felhasználásá-
SMTP,
val megbízható, hatékony szolgáltatást jelent,
rfc-editor.org/rfc/rfc2821.txt)). Ennek a HELO
aminek
helyett
napi
24
órában
rendelkezésre
kell
az
A Telnet NVT módszerét (lásd 4.3.3 szahasználja
az
SMTP
is.
Például,
az
esetén
2821
els® a
http://www.
(l.
parancsa.
régebbi,
Ennek
kevesebbet
tudó protokollt kell használni.
egy
SMTP kiszolgálóhoz közvetlenül is kapcsolódhatunka következ® parancssor kiadásával:
$ telnet www.someserversomewhere.org 25 4.4. Az elektronikus levél
RFC
EHLO
sikertelensége
állnia.
kasz)
ESMTP,
4.4.2. A POP3 protokoll Az
elektronikus
levelez®
leveleket
kliensekkel
a
PC-re
(Outlook,
installált
Eudora,
...)
Hálózati architektúrák és protokollok
c 2005
32
by http://www.tcpipguide.com/C. M. Kozierok
4.17. ábra. Az SMTP kapcsolat lefutása
írjuk és olvassuk, a POP3 protokollt (RFC 1939 (l.
http://www.rfc-editor.org/rfc/rfc1939.
txt)) használva, (lásd 4.18 ábra). A POP3 csak
c 2004
A. S. Tanenbaum: Computer Networks
egyirányú átvitelt tesz lehet®vé, a levélkiszolgálótól a levelez® kliens felé. M¶ködését meg gyelhetjük a következ® parancssor kiadásával:
$ telnet mail.isp.com 110
4.19. ábra. Három üzenet letöltése POP3 segítségével
is, hogy a szerveren könyvtárakba rendezzük a
leveleinket.
Ett®l
teljesen
eltér®
módon
m¶ködik a webmail, amelynek használatával leveleinket egy web böngész® segítségével tudjuk írni és olvasni, lásd 4.20 ábra.
c 2003
by http://www.sahughes.net 4.18. ábra. A POP3 protokoll
c 2003
A
felhasználó
ténylegesen
(a
4.19
by http://www.sahughes.net
ábra
4.20. ábra. Az IMAP protokoll
szerinti módon) sa ját gépére tölti le leveleit és törli azokat a kiszolgálóról. Az letöltés idejére TCP összeköttetés épül ki.
4.4.3. Az IMAP protokoll
4.4.4. A MIME kiterjesztés A csak szöveget továbbítani tudó elektronikus levelezés
hamar
elégtelenné
vált.
Nemcsak
A POP protokollal szemben a IMAP4 proto-
az angol ABC bet¶inek ékezetes változatait,
http://www.rfc-editor.org/
hanem nem-latin karaktereket, valamint álta-
koll (RFC 2060 (l.
rfc/rfc2060.txt)) nemcsak elszállítja a leveleket
lános
a kliens szoftverhez, hanem lehet®vé teszi azt
stb. is akartak a levelekhez csatolni. A MIME
4.4. Az elektronikus levél
bináris
fájlokat
és
hangokat,
képeket,
Hálózati architektúrák és protokollok
33
(Multipurpose Internet Mail Extensions, RFC 2045 (l.
http://www.rfc-editor.org/rfc/rfc2045.
txt)-RFC 2049 (l. http://www.rfc-editor.org/ rfc/rfc2049.txt)) teszi lehet®vé, hogy ne csak angol szövegeket, hanem akár kép vagy hangüzeneteket csatoljunk az elektronikus levelekhez, lásd 4.21 ábra. Mint látni fogjuk, melléklet min®ségében egyáltalán nem mellékes szerepet játszik, és nem csak a levelezésben. Az üzeneteket a küld® szoftver szöveggé kódolja, a fogadó pedig dekódolja. Szerencsére az RFC 822 (l.
http://www.rfc-editor.org/rfc/
rfc822.txt) lehet®vé teszi, hogy az elektronikus levél
felhasználó
használjon,
és
által
ezt
a
de niált
mez®ket
lehet®séget
a
is
e-mail
továbbító protokollok is megfelel®en kezelik.
c 2004
A. S. Tanenbaum: Computer Networks
4.22. ábra. Egy MIME alternatívákat tartalmazó példa
c 2008
by http://www.learnthenet.com
4.21. ábra. Levélküldés a MIME használatával
A fogadó szoftvernek tudnia kell, mivé kódolja vissza a kapott szöveget. Ennek segítésére a küld® egy
Content-Type:
/<subtype> [; parameter1 ; . ; parameterN ] formájú sorban adja meg a melléklet
A. S. Tanenbaum: Computer Networks 4.23. ábra. Egy MIME átviteli példa
/<subtype> adattípusát, lásd
c 2004
?? táblázat. A paraméte-
rek további pontosítást tesznek lehet®vé.
A 4.22 ábrán bemutatott üzenet a fogadó kliens képességeire bízza az üzenet megjelenítését: ha tud hangüzenetet lejátszani, akkor a
4.4. Az elektronikus levél
Hálózati architektúrák és protokollok
34
címzett dallamot fog hallani a levél megnyitásakor; ha nem, akkor csak egy jókívánságokat tartalmazó
szöveget
átküldés
4.23
a
fog
ábra
látni.
szerint
A
meg
tényleges végbe:
a
szerver (S) és a kliens (C) szöveges üzenetek formájában továbbítják a tennivalókat.
4.5. A Világháló (WWW) Az
elektronikus
gyakrabban
levélnél
használt
is
népszer¶bb
szolgáltatás
a
és
c 2004
A. S. Tanenbaum: Computer Networks
WWW
(a World Wide Web; a Világháló). Annyira
4.25. ábra. A World Wide Web modellje
domináns szolgáltatás, hogy a közbeszédben az internetezni kifejezés többnyire az Internet WWW szolgáltatását használni kifejezést
követve átkerülünk a másik Web kiszolgálóra, szinte észrevétlenül.
helyettesíti. Létezése óta szinte átformálta a társadalmat A
is,
WWW
minden
területen
lényegében
csak
jelen
van.
kiterjeszti
az
elektronikus levél és a fájlküldés (FTP) során
4.5.1. A Hypertext Markup Language (HTML)
már megismert szolgáltatásokat. Hogy azoknál mégis lényegesen többet nyújt, az f®ként a do-
•
Egy olyan jelöl®nyelv, amelyben utasí-
cumentumok között kapcsolatot teremt® (hy-
tásokkal (lásd 4.26 ábra) írjuk le, hogy
pertext) tulajdonságának, és a multimédiás
hogyan
fájlokat is hatékonyan kezel® protokolljának
(lásd 4.27 ábra)
kell
a
tartalmat
megjeleníteni
köszönhet®. A WWW f®bb komponenseit a
•
4.24 ábra mutatja.
se: ISO standard 8879:1986: Standard Generalized Markup Language (SGML)
•
Szöveges olyan
utasításai szempontra,
dokumentumokat
meg
vannak
minden
ami
szerint
lehet
jeleníteni
(lásd 4.28 ábra)
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
4.24. ábra. A World Wide Web f®bb komponensei
A
WWW
Internetre
m¶ködése
kapcsolódni
során
tudó
a
sa ját,
az
számítógépünk-
ben található böngész®vel kapcsolatba lépünk az
abcd.com
valamelyik
Web
kiszolgálóval,
dokumentumát
és
böngésszük
annak saját
képerny®nkön, lásd 4.25 ábra. Ha találunk egy
xyz.com
oldalra
vonatkozó
4.5. A Világháló (WWW)
hivatkozást,
azt
c 2004
A. S. Tanenbaum: Computer Networks 4.26. ábra. HTML minta szöveg
Hálózati architektúrák és protokollok
35
V1.0
változatának
RFC-je
is
csak
több
évi
tényleges használat után készült el. Jelenleg használatos
változata
a
Protocol - HTTP/1.1
Hypertext Transfer
(RFC 2616 (l.
http://
www.rfc-editor.org/rfc/rfc2616.txt)). A Telnet NVT módszerét (lásd 4.3.3 szakasz) használja a HTTP is. Például, a
$ telnet www.someserversomewhere.org 80 c 2004
parancssor kiadásával közvetlenül is kapcso-
A. S. Tanenbaum: Computer Networks
lódhatunk
egy
HTTP
kiszolgálóhoz,
ami
a
fenti bejelentkezés után HTTP kéréseket vár,
4.27. ábra. HTML minta megjelenítés
mintha a felhasználó egy HTTP kliens lenne. A protokol különböz® médiumokat is kezel, az
elektronikus
levél
MIME
koncepciójának
nagyon sok elemét használja. Generikus üzenetformátuma:
<start-line>\ <message-headers>\ <empty-line> [<message-body>] [<message-trailers>]
A
c 2004
HTTP
kliens
A. S. Tanenbaum: Computer Networks
párbeszéd
kezdeményezi,
egy a
üzenetformátummal:
4.28. ábra. Néhány HTML utasítás
A HTML nyelv néhány jellemz® utasítását mutatja a 4.28 ábra. Mint látható, az utasítások záró jel-szer¶en használandók és valóban formátumozási
el®írásokat
tartalmaznak.
A
HTML nyelv és a továbbfejlesztett változatai XHTML, XML önállóan is képezhetik egyegy féléves kurzus tárgyát.
4.5.2. A Hypertext Transfer Protocol (HTTP) A HTTP protokoll ®s-változata (V0.9) nem is
szerepelt
RFC
dokumentumban,
még
a
lényegesen átdolgozott és sok éven át használt
4.5. A Világháló (WWW)
<request-line> <request-headers> <entity-headers> <empty-line> [<message-body>] [<message-trailers>]
üzenetváltását
következ®
a
generikus
Hálózati architektúrák és protokollok
Egy
HTTP
kérés
példát
mutat
36
a
4.29
ábra. A kérés tipikusan nem szállít entitást, a megfelel® mez®k üresek.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
4.30. ábra. HTTP Response üzenetformátuma
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
4.29. ábra. HTTP Request üzenetformátu-
A
ma
(status line)
Az els® (request line) sor formátuma:
<METHOD> <request-uri> <METHOD> valójában utasítás; a <request-uri> legtöbbször egy HTTP URL; a pedig a kliens által A
használt
HTTP
verzió.
A
felhasználó
szerver
válaszában
az
els®
az
állapotsor
<status-code> el®ször
a
szerver
tozatot
adja
meg
által
használt
(ami
nem
HTTP
lehet
vál-
nagyobb,
mint amelyet a kliens használt a kérésben), a háromjegy¶ állapot kód után a felhasználónak szánt szöveg áll.
által
eredetileg beírt URL protokoll része nyilván
A HTTP kérésre válaszul legalább egy HTTP
nem
válasz üzenet érkezik. A válasz állapotkódot
szükséges
már
itt,
a
szervergép
neve
külön szerepel; itt már csak a szervergépen
tartalmaz, és többnyire a kért er®forrást.
érvényes útvonal játszik szerepet.
Egy HTTP kérésre pontosan egy válasz érke-
4.5.3. A WWW (URIs)
zik. A válaszok generikus formátuma:
<status-line>
címzési
rendszere
Az URI a hálózat (WWW) használatából n®tt ki, mára általánosították és általánosan hasz-
nálják a TCP/IP protokollokkal kapcsolatosan F®ként az er®források megtalálására szolgál; a
DNS nevekhez képest pontosítja a címet: az eszközön belül fájlt, objektumot, stb. ad meg.
<entity-headers>
Az
<empty-line>
URI
összefoglaló
név;
két
f®
fajtája:
Uniform Resource Locator (URL) és Uniform Resource Name (URN)
[<message-body>]
Az elterjedten használt URL elvi felépítése:
<scheme>:<scheme-specific-part>
[<message-trailers>]
aminek a legáltalánosabb kifejtett formája
Egy
HTTP
válasz
példát
mutat
a
4.30
ábra. A válasz már (általában) szállít entitást.
4.5. A Világháló (WWW)
<scheme>://<user>:<password>@ :<port>/; <params>?#
Hálózati architektúrák és protokollok
Az
egyes
elérési
módokhoz
(sémák)
37
tartozó
5. Új
szintaxisok eltér®ek.
elektronikus
levelet
a
böngész®ben
írunk, a HTTP protokollal elküldjük a szervernek, ami aztán SMTP protokollal
Egy hálózati er®forrás különböz® kópiái külön-
küldi tovább.
böz® neveket kapnak, bár egyébként azonosak. Ezek
egységesen
jelölhet®k
a
Uniform
Re-
source Name (URN) használatával, lásd RFC 1737 (l.
azon a számítógépen is futhat.
http://www.rfc-editor.org/rfc/rfc1737.
txt), RFC 2141 (l. http://www.rfc-editor.org/ rfc/rfc2141.txt). Az URL-hez képest, kevésbé kiforrott technológia. A különféle er®forrásokat
A webmail szerver és a levelez® szerver ugyan-
egy-egy
névtér
(namespace)
írja
le.
Az
URN általános szintaxisa
Az ilyen szerverekkel is kapcsolatba léphetünk a Telnet módszerével:
$ telnet gmail-smtp-in.1.google.com 25 Természetesen
el®tte
be
kell
szereznünk
a
levelez® szerver címét, pl. a
URN: :$ host -a -v gmail.com Például egy könyv esetén
utasítással, ami a a DNS szolgáltatás igénybe-
URN:isbn:0-679-73669-7
vételével az MX rekord tartalmát adja vissza.
Bár egyértelm¶en azonosít egy er®forrást, nem mondja meg, hogy lehet azt elérni. Erre egy, a DNS-hez hasonló feloldási mechanizmus szükséges,
lásd
RFC
2483
(l.
http://www.
rfc-editor.org/rfc/rfc2483.txt) (URI Resolution Services Necessary for URN Resolution)
5. Az OSI modell szállítási (4.) rétege I. 5.1. Áttekintés
4.6. Webmail
A szállítási réteg egy absztrakt kommunikációs
A Webmail az IMAP4 protokollt használja.
modellen
m¶ködésr®l
alapszik.
nem
tud:
A
konkrét
nincsenek
hálózati
benne
há-
A tényleges IMAP4 levelez® klienst a webmail
lózati
kiszolgáló biztosítja (lásd 4.31 ábra). M¶ködé-
konkrét hálózatoktól függetlenül, megbízható,
se:
gazdaságos
szállítási
közvetlenül
fölötte
1. A HTML protokol segítségével kapcsolatba lép a felhasználó PC-jével (a felhasználó saját gépén egy WEB böngész®t futtat). felhasználónévvel
azonosítja
a
felhasználót.
és
írhat, olvashat és küldhet levelet. elektronikus
képerny®n
leveleket
kiolvassa
a
megjeleníti
a
beérkezett
levelek listá ját. 4. A listából egy levelet kiválasztva megjeleníti az üzenetet.
5. Szállítási
szolgáltatást
elhelyezked®
stb.
biztosít
A
a
alkalmazási
rétegben futó különféle folyamatok számára. A feladatokat megvalósító kód az alkalmazási réteg feladatait megvalósító kódhoz hasonlóan
teljes egészében a felhasználó számítógépén fut. A 4. (szállítási) réteg (5.1 ábra) végpontok
közötti szolgáltatást biztosít a hálózaton át.
felhasználó saját levél ókjából és a webes
protokollok,
A
sikeres bejelentkezés után a felhasználó
3. Az
csomagok,
2. Bejelentkezéskor jelszóval
hibák,
Lehet kapcsolat alapú vagy kapcsolatmentes, de mindenképpen "best eort" jelleg¶. Példák a réteg funkcióira:
•
alkalmazás
azonosítása,
egyed azonosítás
kliens-oldali
Hálózati architektúrák és protokollok
c 2003
38
by http://www.sahughes.net 4.31. ábra. A Webmail komponensei és m¶ködése
5.2. A szállítási szolgáltatás A szállítási réteg legfontosabb feladata, hogy a hálózat esetlegességeit, hibáit, id®nként bonyolult kezelését elrejtse a az alkalmazási réteg el®l, ezáltal az alkalmazási réteg számára a
c 2004
http://www.globalknowledge.com
5.1.
ábra.
Az
OSI
hálózati
szállítási
(transzport)
tes szolgáltatásnak mutassa.
sport
A ténylegesen
entity)
ebben
a
szakaszban
absztrakt
lehet az operációs rendszer kernelének része, egy hálózati alkalmazáshoz tartozó könyvtár
az adatok szegmentálása hálózati átvitelhez
•
hibamen-
fogalomként kezel®dik. Konkrét megvalósítása az egész üzenet épségben való megérkezésének nyugtázása
•
megbízható,
szolgáltatást nyújtó funkcionális elem (tran-
rétege
•
adatkezelést
vagy akár a hálózati illeszt® kártya része, vagy ezek
(akár
Mint
azt
szoftver/hardver)
tárgyaltuk,
kombináció ja.
összeköttetés
alapú
és
adatáramlás vezérlése, memória túlcsor-
összeköttetés nélküli szállítási szolgáltatás is
dulás megel®zésére
létezhet.
•
átviteli hiba észlelése
•
az adatok sorbarendezése a fogadó oldalon
•
egyetlen zikai vonal megosztása több session között
•
(virtuális áramkörök létrehozása és fenntartása,
mindkét
végponton,
amennyi-
c 2004
A. S. Tanenbaum: Computer Networks
ben ilyen típusú kapcsolatot építünk fel) 5.2. ábra. A szállítási réteg helye és feladata
Az absztrakt megfogalmazásban a szállítási protokoll adategysége a TPDU (Transfer
5.2. A szállítási szolgáltatás
Hálózati architektúrák és protokollok
39
Protocol Data Unit), ami zikailag (esetleg
•
Az UDP nem biztosítja a sorrend át-
egymásba ágyazott) adatcsomagnak felel meg.
rendezését.
Hasonlóképpen, a szolgáltatás elérési pontjá-
nagyon fontos, mivel a szegmensek kü-
nak
lönböz® utakon haladhatnak és jelent®s
neve
TSAP
(Transport
Service
Access
Point).
hálózatok
esetén
ez
késéseket szenvedhetnek. Lokális hálózatokon ennek hatása nem jelent®s.)
A hálózati rétegben nagyon hasonló funkciókkal
(Nagy
fogunk
történetileg
a
találkozni. két
réteg
Ennek
együtt
oka,
hogy
fejl®dött
és
sokáig egyetlen rétegként kezelték. A lényeges
Az UDP adatformátumát a 5.3 ábra mutatja.
eltérés, hogy az itteni funkciók a felhasználó számítógépén,
az
ottaniak
a
hálózat
más
számítógépein valósulnak meg. A szállítási rétegnek egy szállítási szolgálati interfészt
kell
biztosítani
lyamatok
számára.
A
az
alkalmazási
legelterjedtebb
fo-
ilyen,
el®ször a Berkeley UNIX-ban használt TCPsocket primitíveket a 5.5. táblázat tartalmazza.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
5.3. ábra. Az UDP szegmens adatformátuma
Az adatokat az alkalmazásoktól a szállítási réteg
továbbítja
rétegei
felé.
a
protokollkészlet
Ebben
a
rétegben
mélyebb
végezhetünk
hibavizsgálatot, adatfolyam vezérlést, hálózati
A fejzet egyes adatmez®i a következ®k
Küld® port
(16-bit)
átvitel ellen®rzést is. A 3.1 ábra szerint ebben
A küld® számítógépen futó alkalmazás-
a rétegben két protokollt kell megemlíteni: az
hoz
összekötés
szükséges,
nélküli
UDP
és
az
összeköttetés
Fogadó port
5.3. Az UDP protokol UDP
768
(l.
(User
száma.
választ
kell
Csak
akkor
küldeni.
Ha
Datagram
(16-bit)
Amilyen
Protocol,
RFC
http://www.rfc-editor.org/rfc/rfc768.
txt)) mindössze 8 bá jtos fejzetb®l és a felhasználói adatokból álló csomagokat (szegmenseket) képes küldeni a hálózaton, összeköttetés kiépítése nélkül.
•
port
ha
nem szükséges, nullával kell kitölteni.
alapú TCP.
Az
rendelt
port
címre
szállítja
az
UDP
UDP
data-
szoftver a datagrammokat.
Hossz
(16-bit)
Ez
az
érték
adja
meg
az
grammban lev® bájtok számát. A hossz egyaránt tartalmazza az UDP fejzet és a hasznos adat hosszát. Mivel az UDP
Bár az UDP protokollt általában úgy jel-
fejzet hossza 8 bá jt, ez az érték mindig
lemzik, hogy abban nincs hibavizsgálat,
legalább 8.
valami (eléggé korlátozott) elemi ellen®rzést azért végez. Az UDP datagramm
Ellen®rz® összeg
(16-bit)
is tartalmaz egy ellen®rz® összeget, amit
A szegmens épségének vizsgálatára hasz-
a fogadó számítógép ellen®rizni tud (bár
nált mez®. A fogadó számítógép is készít
ez
csak
egy ellen®rz® összeget (a fejzetb®l vala-
egy lehet®ség). Szerepel benne a cél-cím
mint a hasznos adatból, meg esetlegesen
is, így megvizsgálható a helyes címzés
a kitölt® bájt(ok)ból is), és azt összeha-
is. A fogadó számítógép ICMP üzenettel
sonlítja a szegmensben tárolt értékkel,
értesítheti a küld®t, ha az üzenet inaktív
amit még a küld® számítógép számított
vagy de niálatlan portot akar használni.
ki.
a
vizsgálat
a
5.3. Az UDP protokol
legtöbb
esetben
Hálózati architektúrák és protokollok
40
5.5. táblázat. Berkeley TCP-primitívek
Mivel
Primitív
Jelentés
SOCKET
Új kommunikációs végpont (csatlakozó) létrehozása
BIND
Helyi cím hozzárendelése a csatlakozóhoz
LISTEN
Összeköttetés-elfogadási szándék bejelentése
ACCEPT
Hívó blokkolása összeköttetés-létesítési kísérletig
CONNECT
Összeköttetés létrehozási kísérlet
SEND
Adatküldés az összeköttetésen keresztül
RECEIVE
Adatfogadás az összeköttetésen keresztül
CLOSE
Az összeköttetés felbontása
az
UDP
fejzet
nem
tartalmazza
összetett, bonyolult funkcionalitású protokoll.
sem a küld®, sem a fogadó IP címét, téves
se a Network Control Protocol (NCP), ami a
kézbesítés is lehetséges. (Lehet azonban ilyen
mai TCP/IP funkcionalitásának felelt meg. A
információ az adatok között, ha szükséges.)
TCP feladata, hogy csomópontok között kap-
Hátrányai ellenére, az UDP nagyon hasznos
pl.
gyakori,
rövid
kérések
kiszolgálása
A DNS rendszer, id®zítés gyeléssel kombinálva, UDP üzenetben küld információt. esetén.
Egy lekérdezés esetén mindössze két üzenet halad át a hálózaton, és a kapcsolat kiépítése semmi többlet funkcionalitást nem adna.
csolatot hozzon létre, és a kapcsolat fennállása alatt bájtfolyam jelleg¶, kétirányú kapcsolatot tartson fent, a fölötte lev® réteg számára megbízható
hálózati
adatátviteli
mechanizmust
szolgáltasson. A
fejzet
egyes
adatmez®i
a
következ®k
(m¶ködésüket ma jd a TCP átvitel tárgyalása során értjük meg):
5.4. A TCP protokol
Küld® port min®sége
A TCP-t els®sorban az adatátvitel különbözteti
meg
az
UDP-t®l.
Ennek
két
(16-bit)
A küld® számítógépen futó alkalmazáshoz rendelt port száma.
Fogadó port
kulcsfeladata:
Megbízhatóság
Megérkezés
ellen®rzésével
(16-bit)
A fogadó számítógépen futó alkalmazáshoz rendelt port száma.
és újraküldéssel
Adatáramlás vezérlése
a
küldési
sebesség
változtatásával, a túlterhelés elkerülésére
Sorszám
(32-bit)
SYN=1
a kezdeti sorszám (ISN), ami
a sorszámok szinkronizálására szolAz
UDP
protokoll
esetén
az
elküldött
gál. Ebben az esetben az els® oktet
üze-
száma ISN+1.
netr®l nincs visszajelzés: ha megérkezett, jó, ha
nem,
úgy
is.
A
küld®
soha
nem
kap
SYN=0
visszajelzést. A
TCP
szegmensben (Transmission
col RFC 793 (l.
Control
Proto-
http://www.rfc-editor.org/rfc/
rfc793.txt), számos kiterjesztése és b®vítése külön RFC-k tárgya) adatformátumát a 5.4 ábra mutatja. Már ennek alap ján is fogalmat alkothatunk a TCP összetettségér®l és funkcionalitásának
az els® bá jt sorszáma ebben a
sok
vonatkozásáról.
5.4. A TCP protokol
A
TCP
Nyugtaszám A
(32-bit)
nyugtaszám
a
fogadott
szegmens
nyugtatványa. Az értéke az a sorszám, amit a fogadó számítógép vár; másképpen kifejezve, az utolsó fogadott érték + 1.
Hálózati architektúrák és protokollok
c 2005
41
by http://www.tcpipguide.com/C. M. Kozierok 5.4. ábra. A TCP szegmens adatformátuma
Adat oset Azt
PSH
(4 bit)
közli
a
fogadó
TCP
sítja
szoftverrel,
számát megadó egész érték.
Fenntartott Kés®bbi
szoftvert,
hogy
az
RST
(Reset) ennek 1 értéke alapálla-
potba helyezi a kapcsolatot (6 bit) használatra
(el®re
nem
látott
kell lennie.
Vezérl® jelz®bitek
SYN
(Synchronize)
ennek
1
értéke
jelzi, hogy szinkronizálni kell a sorszámokat, azaz új kapcsolat épül ki.
FIN
(Finish)
ennek
1
értéke
jelzi,
hogy a küld® számítógépen nincs
(1 bites értékek)
több adat; a kapcsolat lezárására (Urgent) ennek 1 értéke sürg®s
tartalmat jelent, és ilyenkor a Sürg®s mutató mez® tartalma értékes.
ACK
TCP
fogadó alkalmazásnak.
fejlesztések) fenntartva; nulla érték¶nek
URG
a
eddig töltött adatokat továbbítsa a
milyen hosszú a fejzet, azaz hol kezd®dik az adat. Az oset értéke 32-bites szavak
(Push) ennek 1 értéke arra uta-
(Acknowledge) ennek 1
értéke
használatos.
Ablak
(16-bit)
Az
adatátviteli
forgalom
vezérlésére
azt jelzi, hogy a Nyugtaszám me-
használt paraméter: azt az ablakméretet
z® tartalma értékes.
adja meg, hogy hány további szegmenst
5.4. A TCP protokol
Hálózati architektúrák és protokollok
42
küldhet a küld® számítógép nyugta fogadása nélkül.
Biztonság szolgáltatása
más mechanizmu-
sokkal kell az átvitel biztonságát szolgál-
Ellen®rz® összeg
tatni (16 bit)
A szegmens épségének vizsgálatára használt mez®. A fogadó számítógép is készít egy ellen®rz® összeget és azt összehasonlítja a szegmensben tárolt értékkel, amit
Üzenethatárok megtartása
bájtfolyamot
visz át, nem egyes üzeneteket
A kommunikáció garantálása
mindent
megpróbál, de csodát nem tud tenni
még a küld® számítógép számított ki.
Sürg®s mutató
Kapcsolat-orientált
(16 bit)
A
TCP
megköveteli,
Oset érték, a sürg®s információ kezde-
hogy az eszközök adatküldés el®tt kap-
tére mutat.
csolatot teremtsenek egymással. A kapcsolat
Opciók
telefonhívás
létrehozott
rehozása el®tt a partnerek megtárgyalják a kapcsolat és az adatcsere paramé-
Tölt®bitek
tereit. tölt®bitek,
hogy
az
adatok
32-
bites szóhatáron kezd®djenek.
Adatok
Kétirányú
A
kapcsolat
létrejötte
után
a
TCP mindkét irányban képes adatokat küldeni. Mindkét eszköz képes adatokat
A szegmensben található adatok. A TCP ezeket az adatmez®ket használja az átvitel vezérlésére, nyugtázásra és ellen®rzésre.
A TCP tevékenysége a következ® f® feladatok-
küldeni
és
fogadni,
függetlenül,
hogy melyikük kezdeményezte a kapcsolatot
Több végpontú
A
socket
pár
eszköz
használ
TCP
kapcsolatot
azonosítja,
megnyithatnak,
Címzés/multiplexelés Kapcsolat kezelése
lásd 5.4.1 szakasz
a
amelyet
kapcsolat
az a
a
két
fennállása
Adatkezelés és csomagolás
lásd 5.4.3 sza-
kasz
Megbízhatóság és min®ség biztosítása lásd 5.4.4 és 12.1.2 szakasz
Adatáramoltatás
lásd
?? és 12.1.1 szakasz
nem csinál:
Használati mód el®írása a felhasználási módot
egymástól
Megbízható
függetlenül,
ütközés
A TCP gyelemmel kíséri mind
tudja
garantálni,
hogy
az
összes
adat megérkezik, biztosan megkísérli fogadni az adatokat, megvizsgálja azok épségét és újraküldi azokat, ha szükséges. Best
eort
:
mindent
megtesz,
amit
tud.
Nyugtázott
A
darabra
a
TCP fogadó
Igen,
minden fél
küldeményt
minden
megkaptam
üzenet-
üzenettel
válaszol. Ez élesen eltér a legtöbb üzenetprotokolltól, és a TCP sikerességének egyik kulcsa.
5.4. A TCP protokol
akár
az adatok küldését, mind fogadását. Bár
nyugtáz. nem szabja meg
ugyanazzal,
nélkül kezelhetik.
nem lásd 5.4.4 szakasz
akár
különböz® eszközzel, és ezeket a kapcsolatokat
(létrehozása, fenntartá-
sa és megszüntetése) lásd 5.4.2 szakasz
Adatátvitel
attól
alatt. Az eszközök több kapcsolatot is
ra koncentrál:
És amit
által
áramkörrel egyenérték¶. A kapcsolat lét-
Opcionális beállítások kis csoportja
Extra
a
Hálózati architektúrák és protokollok
Stream-orinentált protokoll
43
A legtöbb alsóbb-szint¶
adatblokkokat
fogad;
pl.
az
IP a kapott üzenetet datagrammokban küldi tovább. Hasonlóképpen az UDP is. A TCP viszont folyamatos adatfolyam küldését
teszi
lehet®vé.
Az
alkalmazá-
soknak nem kell az adatok darabolásával foglakozniuk, ez a TCP feladata.
Struktúra nélküli
A
TCP
adatfolyamban
nincsenek természetes osztópontok a alkalmazástól
kapott
adatfolyam
elemei
között. Amikor több üzenetet küldünk TCP-n keresztül, az alkalmazásnak kell módot biztosítani arra, hogy az egyik üzenetet (adatelemet, rekordot, stb) el tudjuk választani a másiktól.
Adatfolyam-vezérelt
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
5.5. ábra. A bejöv® és kimen® adatok multiplexelése TCP/UDP port címek alapján
A TCP nem csak be-
csomagolja és a lehet® leggyorsabban továbbítja az adatokat. Kezeli kapcsolatot is, hogy az egyenletes és akadálymentes legyen, azaz foglalkozik az ennek során el®fordulható problémákkal is.
alapján tudja a szerver szoftvere a megfelel® processzhez továbbítani az üzeneteket.
5.4.2. Kapcsolat kezelése A TCP nyújt olyan szolgáltatásokat, amelyek
5.4.1. Címzés és multiplexelés
felhasználásával
az
eszközök
a
részletek
el®zetes megbeszélése után létrehozhatnak A hálózatra kapcsolt számítógépen futó külön-
az adatok továbbítására szolgáló kapcsolatot.
féle alkalmazások a TCP/IP protokollkészlet
Ennek megnyitása után a TCP kezelni tudja a
rétegein át tudják eljuttatni a partner alkal-
kapcsolatot és az azzal kapcsolatos problémá-
mazáshoz üzeneteiket. A becsomagolás során
kat. Amikor már nincs szükség a kapcsolatra,
a különféle protokollokat használó különféle
külön eljárással le lehet azt zárni.
alkalmazásoktól származó üzenetek uniformizálódnak, a fogadó oldalon pedig a kézbesítéshez szükség van a címzett pontos azonosítására, amihez a port címet használja. Ezt a folyamatot nevezik (de)multiplexelésnek. A demultiplexelés kulcsa a socket cím. Mivel a socket is
cím
az
IP
tartalmazza,
címet
és
a
egyértelm¶en
port
számot
azonosít
egy
bizonyos gépen futó egy bizonyos alkalmazást. A zás
5.5,
ábrán
kommunikál
négy
különböz®
egymással
(az
alkalma-
ábra
csak
a
klienst®l a szerver felé irányuló csomagokat mutatja). Van közöttük TCP és UDP protokollt használó alkalmazás is; ezek mindegyike a
megfelel®
TCP
vagy
UDP
portra
küldi
üzeneteit. Az üzenetekben szerepl® port szám
5.4. A TCP protokol
c 2008
http://www.itwizard.info
5.6. ábra. A háromutas kézfogás TCP kapcsolat létesítésekor
Hálózati architektúrák és protokollok
44
•
Ahhoz, hogy sorszám/nyugta rendszer m¶ködjön,
a
máshoz
kell
mindkét sik
számítógépeknek
gépnek
milyen
kezdetben
szinkronizálniuk ismernie
kezd®sorszámot
egy-
hogy
(initial
a
=
N
+
1,
ahol
N
az B számítógépt®l kapott utolsó
m¶ködésüket:
kell,
Nyugtaszám
sorszám
má-
sequence
number, ISN) használ a sorozat kezdetének jelölésére. Ez a szinkronizáció az ún.
háromutas kéz-
fogás keretében történik meg, lásd 5.6 ábra. Ez a folyamat a TCP kapcsolat kezdetén történik meg. A lépések:
1. Az
A
számítógép
küld
egy
adatszeg-
menst, amelyik az
•
SYN = 1 (ez jelöli a kapcsolatfelvétel kérést)
•
ACK = 0
•
Sorszám = X, ahol X az A számí-
c 2008
tógép által adott sorszám (ISN)
http://www.itwizard.info 5.7. ábra. TCP kapcsolat lezárása
beállításokat tartalmazza. A B számítógépre átvitt els® bá jt sorszáma ISN+1
Amikor
lesz
bontására, 2. A B számítógép megkap ja az A számí-
olyan
FIN
tógép által küldött szegmenst, és olyan
a
szegmenst küld vissza, amelyben
ekkor
•
•
fogad álló
id®
jelz®bitje
ír
be
1
n-wait
a
a
kapcsolat
számítógép
sorba,
érték¶.
(várakozás
leegy
amelyiknek
Az
alkalmazás
a
befejezésre)
szegmenseket
szegmenseket,
és de
feldolgozza az
a
sorban
alkalmazástól
már
ACK = 1 (a nyugta mez®ben most
nem fogad el további adatot. Amikor a másik
már van érték)
számítógép kap egy
Sorszám = Y, ahol Y a B számítógép által adott sorszám (ISN)
•
szegmenst
a
az
kezdeményez®
állapotba kerül: a TCP szoftver továbbra is SYN = 1 (még mindig a szinkronizálási fázisban vagyunk)
•
elérkezik a
Nyugtaszám
=
M
+
1,
ahol
FIN
szegmenst, azt nyug-
tázza, elküldi az összes rendelkezésre álló szegmenst, ma jd értesíti az alkalmazást. Ezután egy
FIN szegmenst küld az els® számítógépnek,
M
amit az nyugtáz; ezzel a kapcsolat lebontódik.
az A számítógépt®l kapott utolsó
A kapcsolat létrehozásakor és felbontása-
sorszám
kor is komoly probléma, hogy valamelyik üzenet elveszhet. Ezért a partnerek id®túllépést
3. Az A számítógép olyan szegmenst küld a B számítógépnek, ami nyugtázza a B számítógép ISN megérkezését
•
SYN = 0
•
ACK = 1
•
Sorszám = az (M+1) sorozat következ® értéke
5.4. A TCP protokol
gyelve,
a
felszámolás
kezdeményezése
után
bizonyos üzenetek hiányában is felbontják az összeköttetést.
5.4.3. Adatkezelés és csomagolás
Hálózati architektúrák és protokollok
45
TCP maga nem tudja jelölni, hogy hol vannak az
üzenethatárok,
erre
a
célra
magában
az
üzenetekben kell elhelyezni kódot.
5.4.4. Megbízható adatátvitel
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
5.8. ábra. A TCP adatfolyam feldolgozása és szegmensenkénti küldése
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
5.9. ábra. Pozitív nyugtázás újraküldéssel
A TCP esetében a legtöbb protokolltól eltér®en nincs szükség arra, hogy az alkalmazások csomagonként küldjék az adatokat. Ha
egyszer
a
alkalmazás
TCP
kapcsolat
bármilyen
létrejött,
stream-et
küldhet
az a
A
legegyszer¶bb
esetben
a
fogadó
gép
nyugtát küld a küld®nek. A küld® gép egy id®zítést
gyel;
ha
adott
id®n
belül
nincs
TCP-nek, nem kell semmiféle formai szabályt
válasz, újraküldi az üzenetet, lásd 5.9 ábra.
betartania. A TCP a bájtokat különböz®
Egyszerre csak egy üzenet lehet folyamatban,
paraméterek alapján megfelel® méret¶ szeg-
így a módszer nem hatékony; meglehet®sen
mensekké
lassú lesz a rendszer.
tördeli.
A
szegmenseket
átadja
a
következ® (hálózati) rétegnek, amely azokat (IP
datagrammként)
továbbítja.
A
fogadó végbe:
Két egyszer¶ változtatással jelent®sen ja-
a kapott csomagokból (IP datagrammokból)
víthatunk a módszeren. Egyrészt az üzenetek-
el®veszi a szegmenseket, majd a szegmensek-
hez hozzárendelhetünk egy
b®l a bá jtokat, és azokat bá jtfolyamként adja
válaszként kapott nyugtában is szerepel. Ezzel
tovább a megfelel® alkalmazási protokollnak.
meg
A bájtfolyamként való kezelésnek több fon-
és a nyugtákat is; ilyen módon több üzenet
tos
is
eszközben
a
folyamat
következménye
azonosítás.
fordítva
van.
Az
megy
egyik,
az
adat
Hogy a TCP megbízható legyen,
a
tudjuk
lehet
különböztetni
folyamatban
küldési limit
sorszám ot, az
üzeneteket
egyidej¶leg.
paraméterrel
ami a
is
Másrészt
korlátozhatjuk
meg kell bizonyosodnia arról, hogy a címzett
a folyamatban lev® (nyugtázatlan) üzenetek
hiánytalanul és helyes sorrendben kapta meg a
számát. Ezt a paramétert a fogadó gép állítja
küldött adatokat. Ezt a feladatot a TCP úgy
be sa ját aktuális terhelésének megfelel®en, és
oldja meg, hogy az egyes bájtokhoz sorszámot
a
küld®
rendel.
a
csomagküldés
A
másik
az
5.4. A TCP protokol
adatok
elhatárolása.
A
gép
ennek
megfelel®en
intenzitását.
Ez
változtatja a
javított
Hálózati architektúrák és protokollok
46
ablak,
A folyamat kulcsa a (küldési)
azaz az
a bá jtmennyiség, amit a fogadó engedélyez a küld®nek, hogy azokat nyugta nélkül elküldje. Id®vel elküldjük a még elküldhet® bájtokat (az ablak jobb oldalán mutatott bá jtok másik kategóriába
kerülnek),
ma jd
megérkeznek
a
nyugták (az ablak bal oldalán mutatott bá jtok is
másik
kategóriába
kerülnek).
ablak bal oldala odébb
csúszik,
Ekkor
az
jobbról újabb
elküldend® bájtok kerülnek az ablakba, és így tovább, amíg van mit küldeni.
Az eddigi tárgyalásban valamennyi elküldött csomag megérkezett a címzetthez.
A valódi
hálózatokon a legkülönböz®bb okokból vesz-
c 2005
hetnek el csomagok. A 5.4.4 szakaszban meg-
by http://www.tcpipguide.com/C. M. Kozierok
ismert mechanizmus megemlíti az újraküldés 5.10. ábra. Javított pozitív nyugtázás újra-
lehet®ségét. Az egyes szegmensek elküldését a
küldéssel
TCP úgy végzi el, hogy azokat egy
rendszer hatékony,
(lásd és
5.10 elemi
ábra)
már
megbízható,
adatfolyam
vezérlést
is
sor ba helyezi el, és az elküldéskor elindít egy újraküldési id®zít® t, természetesen újraküldés esetén is. A továbbítás során minden egyes szegmens
biztosít.
bekerül
újraküldési A
TCP
ehhez
hasonló,
de
bonyolultabb
újraküldési
rendezett.
ebbe
id®zít® Ha
a
a
sorba.
maradék
nyugta
az
A
sor
az
értéke
szerint
id®zítés
lejárta
módszert követ. Ezt az teszi szükségessé, hogy
el®tt megérkezik, a TCP kiveszi a szegmenst a
az el®z® protokol üzenet-orientált, a TCP vi-
sorból, különben újraküldi. A szegmens utolsó
szont stream-orientált adattovábbítást végez.
bájtja
A TCP bájtokat lát, de minden egyes bá jttal
nyugtaszám jelzi, hogy a szegmens épségben
egyedileg foglalkozni rémesen lassú lenne. A
megérkezett. Az újraküldések számának van
TCP
egy fels® korlátja.
eleve
szegmenseket
küld
és
fogad,
a
sorszámánál
nagyobb
(vagy
egyenl®)
nyugtában viszont nem egy üzenetazonosítót küld
vissza,
hanem
az
utolsó
fogadott
bájt
A 5.12 ábra szerint a szerver négy szegmenst
sorszámát. Azaz, bá jt tartományok átvitelér®l
küld
kapunk nyugtát.
méret¶eket. A megfelel® sorszámok 1, 81, 201
Az átviend® TCP stream
bájtjait logikailag négy kategóriába sorolhat-
el
a
kliensnek,
80,
120,
160
és
140
és 361. A
juk, lásd 5.11 ábra:
5.12
ábra
mutatja,
hogy
a
szerverek
mutatókat küldenek és a kliensek mutatókat 1. Elküldött és nyugtázott bá jtok 2. Elküldött,
de
(még)
nem
nyugtázott
bájtok 3. Elküldhet® bá jtok, amelyeket a fogadó képes fogadni 4. Elküldend® bájtok, amelyeket a fogadó (még) nem képes fogadni
fogadnak. A szerver gyors egymásutánban elküld három szegmenst, mindegyiknél elindítva egy id®zít®t. Az els® két szegmens szegmens rendben meg is érkezik, a nyugta megérkezése után si
a
szerver
sorból.
A
azokat
harmadik
negyedik
szegmens
adatokat
a
nyugtát
az
szegmens
érkezésekor
helyükre
elküldeni,
kiveszi
teszi,
mivel
a
újraküldéelvész.
A
kliens
az
de
nem
azzal
a
tudja
a
harmadik
szegmens érkezését is elismerné. A harmadik szegmens id®zítésének lejártakor a szerver újra
5.4. A TCP protokol
Hálózati architektúrák és protokollok
c 2005
47
by http://www.tcpipguide.com/C. M. Kozierok 5.11. ábra. A TCP átviteli stream logikai kategóriái
el ismét, amelyiknek lejárt az id®zítése, vagy mindet, amelyikr®l még nem kaptunk nyugtát. Az els® esetben esetleg lassúbb lesz a küldés, a másodikban sok felesleges (ismételt) adatot kell elküldenünk. Nincs jó megoldás.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
5.12. ábra. TCP tranzakció újraküldéssel
elküldi a szegmenst, aminek megérkezésekor a harmadik és a negyedik szegmens egyaránt nyugtázódik, általában csak egy nyugtával. Az újraküldés id®zítését alkalmasan kell megválasztani:
túl
kis
érték
felesleges
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
újraküldést
eredményez, túl nagy érték pedig lelassítja a
5.13. ábra. TCP tranzakció szelektív újra-
m¶ködést. Az érték dinamikusan változhat.
küldéssel
A kiesett csomagok újraküldésére is több megközelítés van: vagy csak az els® olyat küldjük
5.4. A TCP protokol
Ha
a
partnerek
mindegyike
képes
rá
és
ezt el®zetesen végigtárgyalják, a hiányzó cso-
Hálózati architektúrák és protokollok
magot
a
küldött
küld®
kiválasztja
szelektív
nyugta
a
48
fogadó
alapján.
által
A
5.13
ábrán a fogadó TCP jelzi, hogy megkapta a negyedik
szegmenst,
ennek
alapján
a
küld®
következtetni tudja, hogy csak a harmadikat kell újraküldenie.
6. Az OSI modell hálózati (3.) rétege I.
c 2004
6.1. Áttekintés
http://www.globalknowledge.com
6.2. ábra. Az OSI hálózati (network) rétege
A 3. hálózati (network) réteg (6.2 ábra) egy olyan, végpontok közötti logikai címzési rendszert
szolgáltat,
hogy
az
adatcsomago-
kat számos, különféle (Ethernet, Token Ring, Frame Relay, stb.) 2. rétegbeli hálózaton át a
célba
lehessen
gyártónak rétegbeli
sa ját
irányítani. rendszere
címzés
(IP)
Eleinte
volt.
A
bevezetése
minden közös
3.
jelent®sen
egyszer¶sítette a kapcsolat létrehozását, mindkét oldalon. A
c 2005
hálózat
kezelésének
ellen®rzése
és
az
adatáramlás egyszer¶bb vezérlése céljából a
by http://www.tcpipguide.com/C. M. Kozierok
6.1. ábra. A hálózati (internet) réteg átte-
hálózatot
az
azt
lózatokra
osztják,
lomszabályzó
kintése
használó és
a
elemeket
szervezetek
részek
között
(router)
alháforga-
használnak.
Ezek a routerek egymás között megosztják a A szállítási réteg az adatok továbbítását a
útvonalakra vonatkozó ismereteiket, és ennek
hálózati (network, Internet) rétegen keresztül
alapján döntenek az adattovábbítás konkrét
végzi. Felügyeli a csomagok forgalmát, ellen-
útvonaláról.
®rzi a
az
átvitel
csomagokat,
helyességét, de
hálózati réteg végzi. tokolljai hogy
annyira
általában
rakja
A két említett réteg pro-
szorosan a
sorrendbe
a tényleges továbbítást a együttm¶ködnek,
TCP/IP
protokollpárost
emlegetik az adattovábbító protokollként.
(data
link
layer)
határozza
meg,
során
mit
szükség
lehet
a
(a
2.
rétegbeli
konkrét protokol képességei miatt) az üzenetek méretének korlátozására. Emiatt a küld® csomópont hálózati rétege részekre (fragment) bontja
Mint majd látni fogjuk, az adatkapcsolati réteg
A különböz® hálózatok közötti adattovábbítás
az
mópont
üzeneteket,
hálózati
majd
rétege
a
újból
fogadó
cso-
összeállítja
a
részekre tördelt csomagokat.
is tekintünk egy hálózatnak: ott már csak a
A hálózati réteg gyeli és jelenti a hálózat
hálózat egymáshoz képest lokális eszközeivel
normál m¶ködésének logikai változásait. Bár
foglalkozunk.
hálózati diagnosztikát bármelyik, a hálózatba
A hálózati réteg a hálózatok együttm¶ködését (internetworking) határozza meg, lásd 6.1 ábra. Az eddig megismert hálózati rétegek közül ez az utolsó olyan, amelyik
kapcsolt tozást
6.1. Áttekintés
felfedez®
kezdeményezhet,
rendszer
csak
az
a
vál-
változást
elszenved® csomag eredeti küld®jét értesíti.
ténylegesen adatküldéssel és fogadással foglalkozik.
számítógép
A réteg ellen®rzi a kapott üzenet tartalmát. Ha
a
tartalom
sérült,
a
csomagot
eldobja,
Hálózati architektúrák és protokollok
49
az üzenet megismétlését a magasabb rétegbeli
tördelve, darabonként kell elküldni. Az
protokollokra hagyja. Néhány alapvet® bizton-
üzeneteket a másik oldalon újból össze
sági funkciót is végezhet a 3. rétegbeli címek
kell állítani.
routerek általi sz¶résével.
Hibakezelés
•
közös 3. rétegbeli címzési rendszer
•
alhálózatokra osztás és forgalomirányí-
Külön protokollok használato-
sak a hálózat és az eszközök állapotának közlésére.
tás
•
üzenetek méretének korlátozása
•
a hálózat logikai változásainak nyomon követése
•
a hálózat m¶ködésének diagnosztizálása
•
az adatátvitel épségének ellen®rzése
c 2004
A hálózati réteg biztosít lehet®séget adatforgalmazásra az alhálózaton kívüli állomásokkal.
by Sams Publishing/J. Casad
6.3. ábra. A hálózati réteg önti formába az adatokat a zikai hálózat számára
Alapfeladatai:
Logikai címzés
A
eszközöknek
hálózaton
sa ját
kommunikáló
logikai cím ük
van,
ami csak itt, a harmadik rétegben hasz-
6.2. Alapfogalmak 6.2.1. Kommunikációs módok
nálatos. Ezt a szerepet tölti be az IPszám. (Mint majd látni fogjuk, az adatkapcsolati rétegnek is van címzési funkciója, de azok a címek zikai eszközöket jelölnek. A logikai címek viszont függetlenek a konkrét hardvert®l és az egész hálózatra kiterjed® érvényesség¶ek. Lehetnek
örök
érvény¶
statikus
címek,
vagy átmeneti dinamikus címek.)
Útválasztás csolt
Az adattovábbítás az összekap-
hálózatokon
át
a
hálózati
réteg
meghatározó funkciója. Az eszközök és a
szoftver
rutinok
fogadják
a
bejöv®
c 2004
by Prentice Hall/W. Stallings
csomagokat, meghatározzák azok végs® célját, és merrefelé kell azokat továbbí-
6.4. ábra. Egy egyszer¶sített kommunikáci-
tani.
ós modell-diagram
Datagram csomagolás
Mint a többi réteg-
ben is, csak kicsit másként
Tördelés és összeállítás
A
hálózati
réteg-
ben használatos technológiák korlátozzák az üzenetek hosszát. Ha az üzenet túl
hosszú,
6.2. Alapfogalmak
akkor
azt
több
A kációs
üzenetté
2.1
ábra
modell
szerinti
általános
konkrétan
úgy
kommuni-
valósul
meg,
hogy a küld® illetve a fogadó fél számítógépe tartalmazza a forrás adatokat és az átalakítót, illetve az átalakítót és a cél-adatokat, a hálózat pedig elvégzi a továbbítást, lásd 6.4/a ábra.
Hálózati architektúrák és protokollok
Telefonos
(modemes)
átvitel
esetén
50
a
•
6.4/b
nak
ábra szerint valósul meg.
A
hálózatok
kapcsolunk típusa:
létrehozásakor
össze.
A
vonalkapcsolt
az adatok kis csomagokban továbbítód-
számítógépeket
megvalósítás (circuit
két
alap-
switching)
és
•
részekre bontva, vezérl® információkkal
•
a
csomag
vétel
után
tárolódik,
ma jd
továbbítódik
csomagkapcsolt (packet switching).
•
egyes vonalszakaszok többszörösen is kihasználhatók
•
sorbanállás jön létre,
Csomagkapcsolt mások és
c 2004
by Prentice Hall/W. Stallings 6.5. ábra. Hálózat vonalkapcsolással
dedikált kommunikációs út az állomások
intelligensnek kell lennie az útvonal megtervezéséhez
•
után
tördelik,
elküldik.
A
•
a csomagok függetlenül kezel®dnek
•
akármilyen útvonalon haladhatnak
•
más sorrendben is megérkezhetnek, el-
között
•
csomagokba
egymás
állo-
Datagram módszer
köttetés idejére, lásd 6.5 ábra. Jellemz®i:
fázisai: felépítés - átvitel- lebontás
üzeneteket
az
összehasonlítása:
Vonalkapcsolásos hálózat esetén tényleges
•
az
csomagokat
esetén
jellemz®en használt két továbbítási módszer
vezetékes kapcsolatot hozunk létre az össze-
•
a
hálózatok
veszhetnek
•
a
fogadótól
függ
az
újrakezdés
és
a
hiánypótlás
Virtuális áramkör módszer
a nem használt kapacitás elvész
•
csomagküldés el®tt létrejön az útvonal
•
kézfogásos (handshake) kapcsolatfelvétel
•
nem a célt, hanem a virtuális áramkört azonosítja a csomag
•
nem kell az egyes csomagok útvonaláról dönteni
• c 2004
nincs dedikált útvonal
by Prentice Hall/W. Stallings
6.6. ábra. Hálózat csomagkapcsolással
A virtuális áramkör alapú hálózatban az eszközök között egy áramkör épül fel miel®tt meg-
Csomagkapcsolt hálózat esetén az adatokat kis csomagokra bontva továbbítjuk, lásd 6.6 ábra. Kapcsolatnak csak egy adatcsomag továbbításának idejére kell fennállni, és csak a két f®szerepl® számítógép között. Jellemz®i:
6.2. Alapfogalmak
kezdenének kommunikálni egymással. (lásd 6.7 ábra. Egy csomagkapcsolt hálózatban nem épül fel
ilyen
egyik
áramkör
eszközt®l
a
az
adatküldés
másikhoz
el®tt.
küldött
Az
adatok
Hálózati architektúrák és protokollok
c 2005
51
by http://www.tcpipguide.com/C. M. Kozierok
6.7. ábra. Virtuális áramkör alapú kapcsolat
c 2005
by http://www.tcpipguide.com/C. M. Kozierok 6.8. ábra. Datagram alapú kapcsolat
c 2004
bármilyen
útvonalon
haladhatnak,
lásd
6.9. ábra. Virtuális áramkör diagram
ábra.
A kétféle technológia esetén az adatcsomagok eltér®
by Prentice Hall/W. Stallings
6.8
módon
haladhatnak(lásd
6.9
és
6.10
ábra).
Alapállapotban az A gazdagép a az F gazdagépnek szánt üzeneteket a C csomóponton át továbbítja, majd (pl. egy észlelt útvonalhiba
Látható, hogy a csomagkapcsolt hálózatban sorrendcsere is el®fordulhat; mint majd a
miatt) a kés®bbi csomagokat a B csomóponton át.
m¶ködési részletek során megértjük: a csomagok el is veszhetnek, s®t többszöröz®dhetnek is.
Összeköttetés alapú szolgáltatás esetén az adattovábbítás el®tt a két végpont között kiépül egy kapcsolat (az ún. virtuális áramkör), Összeköttetés
zatban
a
nélküli
gazdagépek
továbbításnak egymással.
csak
idejére
Például,
(datagramm) egy-egy
vannak
a
H1
háló-
csomag
kapcsolatban
gazdagépen
futó
P1 folyamat üzenetet szeretne küldeni a H2 gazdagép
P2
folyamatának,
lásd
6.11
ábra.
A gazdagépek egymásnak tudják csak továbbítani az üzenetet; erre a célra minden gazdagépnek vagy egy táblázata, hogy az egyes gazdagépek
számára
szóló
üzenetet
melyik
és a kapcsolat lebontásáig valamennyi üzenet ugyanazon a kiépített útvonalon halad. Ilyenkor a közbüls® csomópontok esetén nehezebb megkülönböztetni
a
virtuális
áramköröket.
Például, a 6.12 ábra esetén a H1 gazdagép által kiépített kapcsolat számára az egyes számú. Amikor azonban a H3 gazdagép is virtuális áramkört
épít
ki
a
H2
gazdagéphez,
az
A
csomóponttól kezdve már új számot kell adni az áramkörnek.
gazdagépnek kell elküldeni, A táblázatban az egyes bejegyzések két részb®l állnak: a címzett
A datagramm és virtuális áramkör módszerrel
és a továbbító gazdagép címéb®l. A 6.11 ábra
megvalósított
mutatja
tulajdonságát a 6.6 táblázat hasonlítja össze.
az
egyes
6.2. Alapfogalmak
csomópontok
táblázatát.
alhálózatok
néhány
fontosabb
Hálózati architektúrák és protokollok
52
6.6. táblázat. Datagramm és virtuális áramkör módszerrel megvalósított alhálózatok összehasonlítása
Kérdés
Datagramm
Virtuális áramkör
Nem szükséges
Szükséges
Címzés
Teljes forrás és célcím
Virtuális áramkör szám
Állapotinformáció
Nincs
Virtuális áramköröket tá-
Forgalomirányítás
A
Kapcsolat
felépí-
tés
rolni kell csomagok
függetle-
Minden csomag a felépített
nek Hiba hatása
Néhány
útvonalon halad elveszett
cso-
A
csomóponton
átmen®
mag
összes áramkör megszakad
Szolgálatmin®ség
Bonyolult
Lefoglalt er®forrástól függ
Torlódásvédelem
Bonyolult
Lefoglalt er®forrástól függ
c A.
S. Tanenbaum: Computer Networks
6.11.
ábra.
Forgalomirányítás
datagramm
alhálózatban
c 2004
by Prentice Hall/W. Stallings 6.10. ábra. Datagram diagram
c A.
S. Tanenbaum: Computer Networks
6.12.
6.3. IP címzés
ábra.
Forgalomirányítás
virtuális
áramkör alhálózatban
6.3.1. IP címek mélyebb Az IP címzés alap ján tudni kell a
címzettet
milyen
és
útvonal
azonosít ani
IP
szám,
fekv® a
eszközöknek
hálózatok
nem
összeköt®
hogy
egységeknek pedig egynél több IP számra is
vezet hozzá. A hálózati réteg-
szükségük van, hogy több hálózattal tudjanak
ki
kell
tudni
találni,
ben adatokat forgalmazni akaró eszközöknek rendelkezni kell (legalább egy) IP címmel. A
6.3. IP címzés
szükséges
rétegekben
kommunikálni. A 6.13 ábra néhány hálózati eszközt mutat,
Hálózati architektúrák és protokollok
53
A 6.14 ábra két összekapcsolt LAN hálózatot mutat. Az A (lila) hálózatban van egy (nagyobb teljesítmény vagy különböz® funkció miatt) két interfésszel felszerelt csomópont. A két hálózat között a kapcsolatot egy két interfésszel felszerelt csomópont biztosítja, amelyik úgy van kon gurálva, hogy megfelel®en irányítsa
közöttük
az
adatforgalmat.
Mivel
csak az A LAN-nak van internetkapcsolata, ugyanennek a csomópontnak a B (kék) LAN Internetforgalmát is ki kell szolgálnia.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
IP címek lényegében 32-bites bináris számok, ameA hálózati eszközök címzésére szolgáló
6.13. ábra. Tipikus hálózati eszközök inter-
lyeket az emberi felhasználók a könnyebbség
fészelése
kedvéért általában 4 db, közbüls® pontokkal elválasztott ahol az interfészeket kis kékes körökkel ábrázolja. A rendes csomópontoknak egy interfésze van, a router (lásd kés®bb) nev¶ eszköznek három, mivel három különböz® hálózatot kapcsol össze. A kettes rétegben m¶köd® switch (lásd ott)
nev¶
eszközöknek
nincs
IP
interfésze.
Lásd még a 6.14 ábrát is.
decimális
számként
adnak
meg.
Az egyes decimális számok az egyes bájtoknak felelnek meg; ennek következtében a decimális értékek 0-255 közé esnek. A 32-bites címet 4 bá jtra osztják, és a szokásos ábrázolása a bá jtok decimálisan megjelenített, központokkal elválasztott értéke, lásd 6.15 ábra. A 6.16 ábra mutat egy példát egy IP-cím háromféle ábrázolására. Természetesen más
(pl.
decimális)
ábrázolás
is
lehetséges,
ett®l az ábrázolt érték nem változik meg. A gyakorlatban
a
központozott
decimális
és
a
bináris ábrázolás honosodott meg.
c 2008
by http://http://technet.microsoft.com
6.15. ábra. IPv4 címosztályok
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
6.14. ábra. Több interfésszel rendelkez® csomópontok egy együttm¶köd® IP hálózatban
A teljes címtér különálló zikai hálózatokra osztása
megnöveli
hálózat
kapacitását
és
részét használhassuk. Ebben az (általánosan használt)
6.3. IP címzés
a
ezért lehet®vé teszi, hogy a címtér nagyobb
esetben
azonban
külön
jeleznünk
Hálózati architektúrák és protokollok
c 2005
54
by http://www.tcpipguide.com/C. M. Kozierok 6.16. ábra. IP cím ábrázolásmódjai
kell az útvonalválasztóknak, hogy hova is kell kézbesíteni
az
arra,
a
hogy
szervezzünk
adatokat. gazdagép
Bár
azonosító ja
alhálózatokat,
használhatatlan
lenne
lehet®ség
ez
pár
van
alapján
komplikált
millió
és
c 2008
by http://wiki.hill.com
gazdagép
6.17. ábra. IPv4 címosztályok
esetén. Sokkal gyakorlatiasabb a hálózati azonosítók felhasználásával felosztani a hálózatot, hogy a gazdagépek és az útvonalválasztók az IP
cím
alapján
ki
tudják
választani
a
cél-
•
sajátgép (loopback)
•
hálózatcím
•
broadcast
•
magánhálózat
szegmenst. Az IP címek intenzív használata meglehet®sen bonyolult felosztási szabályokat alakított ki. Az útvonalszervez®k képesek a hálózaton
belül
az
alhálózat
címére
(ami
általában egy hálózati szegmensnek felel meg) továbbítani a datagrammokat.
Az
egyes
címosztályokat
ugyan
értékha-
táruk egyértelm¶en de nálja, de egyszer¶bb megjegyezni a kialakítás szabályát. A 6.18 áb-
6.3.2. IP címosztályok
ra mutatja az osztálybasorolás algoritmusát: balról jobbra haladva, az el®forduló els® 0
Amikor
az
Internet
er®teljes
növekedés-
érték¶ bit határozza meg az osztályt. Ez az
nek indult, az els® ötlet a címek osztályba
osztályozás
sorolása
logikai csoportosításra.
volt.
A
címeket
eredetileg
a
6.17
elég
merev,
nem
ad
lehet®séget
ábrán látható módon osztották fel. A címeket címosztályokba sorolták, és hálózat/gazdagép címre
bontották.
hálózat
címe
osztályú
cím
8
A
bit,
esetén
osztályú a
cím
gazdagépé
16
+
16,
esetén 24
C
bit,
a B
osztályú
cím esetén 24+8. A bevezetett címosztályok az els® (legnagyobb helyiérték¶) bájt értéke alapján címosztályokra osztják fel a címteret.
Ez a módszer egy kétszint¶ hierarchiát vezet be a címtérbe: hálózatokra és hálózaton belüli gazdagépekre
osztja
fel
azt.
Bár
manapság
(az Internet több nagyságrendnyi növekedése után) inkább a hátrányait szokták hangsúlyozni, komoly el®nyei is voltak:
•
Egyszer¶ és világos
•
Kell®en exibilis
•
Egyszer¶ útvonalszervezés
•
Fenntartott címek is vannak
A gyakorlatban az A, B és C osztályú címek használatosak, az utolsó kett® speciális célú. Az
egyes
osztályokban
két
nagyságrenddel
eltér® méret¶ hálózatok alakíthatók ki, így tulajdonságaik és felhasználási körük is nagyon eltér. Az így megadott címtartományokon belül kivételesen
kezelt
is
A
vannak.
felhasználása:
6.3. IP címzés
címek
kivételként
és
címtartományok
használatos
címek
F®bb hibái viszont:
•
Bels® rugalmasság hiánya. Ami az egyiknek túl kicsi osztály (alhálózat), az a másiknak túl nagy.
Hálózati architektúrák és protokollok
55
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
6.19. ábra. IP cím felbontása bá jton belül hálózat és gazdagép címre
részre vágva 144 és 13 lesz. Mint látható, a szétvágott bá jtban a hiányzó biteket nullával pótoljuk; a decimális számmá alakítás ezután változatlan.
6.3.3. IP alhálózatok Az egyik lehetséges megoldást az IP cím-
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
6.18. ábra. Az IP-címek osztályba sorolásá-
tér jobb hatásfokú felosztására az RFC 950 (l.
http://www.rfc-editor.org/rfc/rfc950.txt) ír-
ja le. Lényege, hogy egy harmadik hierarchia-
nak folyamatábrá ja
szintet is létrehozunk: a nagy hálózat alháló-
•
zatokat tartalmaz, az pedig gazdagépeket. A címtér nem eléggé hatékony kihasználása. A megvásárolt címtér igen nagy részét nem használják a tula jdonosok.
•
El®nyei:
Jobban tükrözi a hálózat szerkezetét A
A router táblázatok jelent®s megnövekedése
gazdagépek
Flexibilitás
Mint azt a 2.15 ábrán láttuk, a hálózati IP címeket hálózatot leíró és gazdagépet leíró tartományra bonthatjuk, azaz kétszint¶ hierarchiát használunk. Az IP címzési módszere ezt a rendszert szem el®tt tartva alakult ki. Lehet azonban a felosztási módszert általánosítani. Mivel az IP címeket általában központozott decimális számnégyesekként adják meg, tanpéldákban (és osztályokra bontáskor) álta-
Az
alhálózatok
A
6.19
ábrán
a
hálózat
azonosító 20 bites, a gazdagép azonosító pedig 12
bites.
Az
osztópont
az
eredeti
IP-szám
harmadik számába kerül; így a 157-b®l két
6.3. IP címzés
gazdagépek
A
fel-
osztásról csak a szervezet tud, az Internet csak a nagy homogén hálózatot látja. Hasonlóképpen láthatatlanok maradnak a változtatások is.
A fejlesztéshez nem kell új IP cím építkeznének
is.
és
Az Internet számára nem látható
dagép címre. Természetesen való jában akárhol
belül
igényeinek
en állíthatók be.
kellene,
számokon
szervezet
száma a szervezet igényeinek megfelel®-
lában bájthatáron vágják szét hálózat és gaz-
kijelölhetjük az osztópontot, akár a nyolcbites
a
megfelel®en csoportosíthatók.
ha
kis
C
osztályú
ami
blokkokból
Nem növeli a routing táblázatokat Mivel
az
szervezetek
alhálózatok belül
útvonalválasztóknak
csak
léteznek, nem
kell
a
a
küls®
tudniuk
Hálózati architektúrák és protokollok
Az
56
róla. A bels® útvonalválasztókba viszont
megadó biteket, és meg tudjuk határozni azt
kellenek további bejegyzések.
az alhálózatot, amihez az IP cím tartozik.
alhálózatot
leíró
biteket
az
IP
címen
belül, az osztály-alapú felosztásban eredetileg a
gazdagép
címzésére
szolgáló
bitek
közül
vesszük kölcsön, lásd 6.20 ábra.
c 2005
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
by http://www.tcpipguide.com/C. M. Kozierok 6.22. ábra. Alhálózati azonosító el®állítása
6.20. ábra. Egy B osztályú hálózat felosztása
az alhálózati maszk felhasználásával
alhálózatokra Az az
IP
alhálózat cím
maszk
egyfajta
értelmezéséhez.
Ha
útmutató
csak
egészen
különleges célunk nincs, a hálózati maszk a magasabb helyértékek irányából egybefügg®en 1-es érték¶ bitekkel kezd®dik és egybefügg®en 0 érték¶ bitekkel végz®dik a kisebb helyérték¶ bitek oldalán. Bár az eredeti RFC 950 (l.
http://www.
rfc-editor.org/rfc/rfc950.txt) nem tartalmazza ezt a követelményt, célszer¶ a maszkoló bite-
c 2005
ket folytonosan, az 6.22 ábrának megfelel®en
by http://www.tcpipguide.com/C. M. Kozierok
elhelyezni. Ekkor használhatjuk az ún. CIDR 6.21. ábra. Alhálózati maszk meghatározása
jelölést (lásd kés®bb), ami az egymás mellett elhelyezett egyesek számát adja meg (a há-
Ett®l bit
kezdve
szolgál
a
bevezetünk egy
viszont
nem
gazdagépek
tudjuk,
hány
lózat+alhálózat címz®bitek együttes számát).
címzésére,
ezért
Az 6.22 ábra esetén ez /21 lenne.
alhálózat maszk (subnet mask)
paramétert, ami azt adja meg, hogy hány bitet
Az alhálózati kiterjesztés bevezetése után be
használunk fel alhálózat azonosítóként és hány
kellett
marad a gazdagépek címzésére.
azokban
az
vezetni a
az
alhálózati
rendszerekben
is,
kiterjesztést amelyek
nem
Az alhálózat maszk 1 érték¶ bitjei jelölik
éltek ezzel a lehet®séggel. A megoldást az ún.
IP
alapértelmezett alhálózati maszk adja.
cím
azon
bitjeit,
amelyek
a
hálózati alhálózat
Az alhálózati maszk egyszer¶en értelmez-
azonosító (subnet ID) részei, lásd 6.21 ábra.
het® az alap címosztályok esetén is: a hálózat
A 0 érték¶ bitek pedig azokat a biteket jelölik,
hossz adott, az alhálózat hosszúsága 0 bit. Az
amelyek az IP címben a gazdagép címét (host
egyes címosztályok alapértelmezett alhálózati
ID) tartalmazzák.
maszkját
azonosító
(network
ID)
vagy
az
az
6.23
ábra
mutatja.
Vigyázat,
a megfeleltetés nem kölcsönösen egyértelm¶: Ennek megfelel®en az alhálózat maszkolása
a
kifejezés egy logikai ÉS kapcsolat létrehozását
mezettként
jelenti az alhálózati maszk és az IP cím kö-
lehet egy olyan B osztályú hálózat alhálózati
zött. Ilyenkor leválasztjuk a gazdagép számát
6.3. IP címzés
255.255.255.0 egy
maszk C
tartozhat
osztályú
alapértel-
hálózathoz,
de
Hálózati architektúrák és protokollok
57
bitjei alap ján kerül. A szegmens elérése után pedig a gazdagép azonosítója alapján kerül a datagramm a megfelel® számítógéphez, lásd 6.24 ábra .
Alhálózat tervezésekor el®ször azt kell eldöntenünk, hány bitet lopjunk el a gazdagép címzésére szolgáló bitekb®l az alhálózat címe
c 2005
számára.
Például,
a
6.25
ábra
szerint
egy C osztályú cím esetén hatféleképpen is
by http://www.tcpipguide.com/C. M. Kozierok
dönthetünk. A határt egy bittel jobbra eltolva 6.23.
ábra.
Az
A,
B
és
C
címosztályok
alapértelmezett alhálózati maszkjai
kétszeresére növeljük az alhálózatok számát és egyidej¶leg felére csökkentjük az alhálózatok gazdagépeinek lehetséges számát; balra tolva
maszkja is, amelyik 8 bitet használ alhálózat
fordított a változás. (Alhálózatban lev® gazdagépek esetén nem szokták tekinteni a csupa
címként.
0
és
csupa
1
értéket
tartalmazó
címeket,
az alhálózatok címtartományában nincs ilyen sz¶kítés.) A 6.29 ábra mutatja, hogyan határozhatjuk meg két lépésben mind az alhálózat címét, mind a gazdagép címét. A alhálózat címét úgy kapjuk meg, hogy a hálózat (az ábrán pirossal jelölt)
alhálózat
azonosító
bitjeit
alhálózat
azonosító értékekké alakítjuk. Ezután az egyes alhálózatokban
az
egyes
gazdagépek
címét
úgy határozhatjuk meg, hogy a hálózat (az ábrán kékkel jelölt) gazdagép azonosító bitjeit gazdagép azonosító értékké alakítjuk. Például, a
#6
alhálózatban
a
#2
gazdagép
alháló-
zat azonosító ja 110, a gazdagép azonosító ja 00010, ami az utolsó bá jtban a 11000010 bitsorozatot eredményezi, (decimális) 194 értékkel. Más megfogalmazásban:
c 2004
by Sams Publishing/J. Casad
Osszunk fel egy C osztályú hálózatot öt
6.24. ábra. Címzés/útválasztás alhálózatok esetén
útvonalválasztók
és
a
gazdagépek
tud-
nak az egyes IP címekhez tartozó alhálózati maszkról. A datagrammok hálózatba irányítása az IP cím hálózatazonosító bitjei alap ján történik,
lehetséges
alhálózat
címet
tesz
lehet®vé.
A
maradék öt bittel címezzük a gazdagépeket,
Az alhálózatokat tartalmazó hálózatokban az
alhálózatra. Ehhez 3 bit szükséges, ez nyolc
amiket
a
címosztály
határoz
meg.
Ha a datagramm már elérte a hálózatot, a megfelel® szegmensbe az alhálózat azonosító
6.3. IP címzés
ez 32 különböz® címet engedélyez. Az els® három oktet valamennyi alhálózat esetén azonos. A negyedik oktetet az alhálózat azonosító írásával
és
a
kap juk.
gazdagép Ennek
cím a
egymás
után
csomópontnak
a
teljes címe 211.77.20.194.
A hálózatok tervezésekor az igények alap ján kell eldöntenünk, hogy miként alakítjuk ki az
Hálózati architektúrák és protokollok
c 2005
58
by http://www.tcpipguide.com/C. M. Kozierok 6.25. ábra. C osztályú alhálózatok tervezése
alhálózatokat.
Az
alábbi
két
példa
közül
a
nem tudunk elég sok gazdagép címet kiadni.
másodikban több lehet®ség közül választha-
A
tunk; a követelményeknek mindegyik kialakí-
bölcsen.
tás megfelel.
közbüls®
lehet®ségekb®l
kell
választani,
A 6.26 ábrán bemutatott C
osztályú hálózatban
legalább
7 alhálózatot kell
kialakítanunk, hogy azok mindegyike
legalább
25 gazdagépet tartalmazzon. Ebben az esetben csak egyetlen módon tudunk megoldást találni.
c 2005
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
by http://www.tcpipguide.com/C. M. Kozierok
6.27. ábra. Alhálózat készítés egy B osztályú
6.26. ábra. Alhálózat készítés egy C osztályú
címb®l, bonyolultabb
címb®l, egyszer¶
A 6.27 ábrán bemutatott B osztályú hálózatban tanunk,
legalább
hogy
15 alhálózatot kell kialakí-
azok
mindegyike
legalább
450
gazdagépet tartalmazzon. Az alhálózat kialítására 3 bit túl kevés, 8 bitet használva meg
6.3. IP címzés
Az eddigiek alapján már könnyen meg tudjuk határozni egy hálózatban mind egy alhálózat címét (lásd 6.28 ábra)), mind egy gazdagép címét (lásd 6.29).
Hálózati architektúrák és protokollok
59
meg nem praktikusak az internetszolgáltatók számára (a forgalomirányításkor számos bejegyzés szükséges egyazon hálózat eléréséhez). Az
osztály
nélküli
útvonalszervezés
(CIDR,
Classless Internet Domain Routing, lásd RFC 1517 (l.
http://www.rfc-editor.org/rfc/rfc1517.
txt) - RFC 1520 (l. http://www.rfc-editor.org/ rfc/rfc1520.txt)) egy ún.
supernet mask
hasz-
nálatával lehet®vé teszi, hogy hálózati azonosító tartományok csoportját egyetlen címként kezeljünk. Ez a technika lényegében az alhálózatoknál használt technika ellentettje: nem további biteket adunk hozzá a hálózatot leíró részhez, hanem biteket veszünk el bel®le. (más megfogalmazás szerint az alhálózat készítést
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
6.28. ábra. Alhálózat cím egy C osztályú hálózatban
nem
egy
bizonyos
osztályú
címre,
hanem
magára a címtérre alkalmazzuk) A
címblokkot
a
legkisebb
címmel
adjuk
meg, a címet (egy törtvonal után) követi a hálózati maszk 1 érték¶ bitjeinek a száma, pl. 204.21.128.0/17.
El®nyei:
•
Hatékony címtér kihasználás : a CIDR alatt lefoglalt címtér kett® bármely hatványa lehet.
•
Kiegyenlített címméret használat
•
Hatékony útvonalszervezés : az útvonalszervez®
táblázat
kevés
számú
bejegy-
zésével nagyszámú hálózatot ábrázolhatunk. A hálózat leírókat össze lehet vonni és egyetlen bejegyzéssel ábrázolni. A CIDR hierarchikus volta miatt a kisebb hálózatok részletei rejtve maradhatnak a nagy hálózati csoportok közötti adatforgalmat kezel® routerek el®tt.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
•
Nem
szükséges
módszer 6.29. ábra. Gazdagép cím egy C osztályú
:
a
CIDR
alhálózat
kon-
használt módszert bármely cég követheti saját hálózatában.
6.3.4. Osztály nélküli címfelosztás CIDR
Legf®bb hátránya:
Az A osztályú címek rég elkeltek, kifogyunk a
•
6.3. IP címzés
az
alhálózatkezel®
cepciót magában hordja. Az Interneten
hálózatban
B osztályú címekb®l, a C osztályúak (254 cím)
külön
Összetettsége
Hálózati architektúrák és protokollok
c 2005
60
by http://www.tcpipguide.com/C. M. Kozierok
c 2005
6.30. ábra. A CIDR megoldása a szemcsé-
by http://www.tcpipguide.com/C. M. Kozierok 6.31. ábra. Az IPv4 fejzet mez®i
zettség problémá jára
Szolgáltatás típus (8-bit) A
6.30
rázolás C
ábra
a
els®dleges
osztályú
alapuló
problémá ját
hálózatok
távolságot. bitszámot
osztályokon
mérete
illusztrálja. megenged
A
B
közötti
CIDR
hálózati
a
ábés
nagy
bármilyen
azonosítóként.
ciális
Ez a mez® spe-
útvonalválasztási
lölhet.
A
mez®
lehet®séget
információt
els®dleges
biztosítson
a
célja,
je-
hogy
továbbításra
várakozó datagramok prioritásának kezelésére.
A
legtöbb
IP
implementáció
Egy 5000 gazdagépet m¶ködtet® szervezet ese-
nullát
tén egy /19-es hálózattal 8190 csomópontnyi
mostanában
címteret rendelhetünk a szervezethez, ami a
min®ségbiztosítási
címtér
QoS) technológiák el®térbe kerülésével.
kal 8
is
veszteségét
ilyen
csökkentheti.
hasonló
osztályú
méret¶
hálózat
módon
Másként szervezet
helyén
a
akár
95%-
kifejezve: is
elfér
CIDR
akár
egy
B
módszerét
ír
ebbe
a
kap
mez®be. nagyobb
Teljes hossz (16-bit) hosszát
adja
Használata gyelmet,
(Quality
of
a
Service,
az IP datagram teljes
meg,
bájtokban.
Tartal-
mazza az IP fejzet és a hasznos infor-
használva.
máció hosszát is.
6.4. IP datagrammok Az
IPv4
datagramm
Azonosító (16-bit)
egy
20-bá jtos
rög-
zített tartalmú fejzettel kezd®dik, és változó mennyiség¶ adatot tartalmaz; a kett® között
opciók
a változó terjedelm¶
helyezkednek el.
A fejzet egyes adatmez®i a következ®k
Verzió (4-bit)
A
jelenlegi
verziót
a
0100
IP
(Internet Header Length) : az
fejzet
hosszát
adja
meg,
32-bites
szavakban. A minimum hossz 5 (32-bites szó), a tipikus bitminta 0101.
6.4. IP datagrammok
sorszám.
Amikor
folytonosan üzenetet
növekv®
küldünk
az
IP rétegnek, és az nem fér el egyetlen datagramban,
az
IP
az
üzenetet
több
datagramra tördeli és az egyes datagramoknak
ugyanazt
számítógép,
az
azonosítószámot
hogy
újból
összeállítsa
az
eredeti üzenetet.
Jelz®bitek (3-bit)
bitminta jelzi.
IHL (4-bit)
rendelt,
adja. Ezt a számot használja a fogadó
Azt jelzi, melyik IP verziót
használjuk.
A küld® IP által az üze-
netekhez
tördelési
Ez
a
mez®
lehet®ségeket.
adja
Az
meg
els®
a
bitet
nem használjuk, értéke mindig 0. A következ® bit neve DF (Don't Fragment): azt jelzi, hogy a további tördelés megen-
Hálózati architektúrák és protokollok
61
gedett (érték=0) vagy sem (érték=1). A
Töltelék bitek (változó bit)
nulla
érték¶
következ® bit a MF (More Fragments)
bitek; az el®z®, változó hosszúságú mez®t
jelz®bit,
egészíti
ami
azt
jelzi,
következnek-e
ki
úgy,
hogy
a
teljes
hossz
további fragmentumok. Ha a bit értéke
32-bit egész számú többszöröse legyen
0, nem kell további fragmentumokat kül-
(az IHL mez® a fejzet hosszát 32-bites
deni (esetleg, hogy az eredeti datagram
egységekben adja meg).
nem fragmentálódott).
Fragment Oset (13-bit)
IP hasznos adatok (változó bit) Ezt
a
mez®t
A
TCP
vagy UDP (esetleg ICMP vagy IGMP)
a
nem-els® fragmentumokhoz rendeljük. A
protokollok
valamelyikével
átviend®
fogadó számítógép ezt az oszet értéket
adatok. A hossz változó, több ezer bá jt
használja arra, hogy a fragmentumokat
is lehet.
megfelel® sorrendbe rendezze. Az oset értéke 8-bá jtos egységekben értend®.
Életid® (Time to Live, TTL) (8-bit) Ez
a
mez®
a
csomag
életidejét
adja
meg, másodperc vagy csomópont szám egységekben. a
csomag
Az
életid®
eltelte
megsemmisül.
Az
után
életid®
minden továbbítás alkalmával legalább eggyel (vagy a továbbításkor szenvedett késedelem értékével) értéke
másodpercekben csökken.
nullára
Amikor
csökken,
a
kifejezett a
mez®
datagram
megsemmisül.
Protokoll (8-bit)
Azt a protokollt határoz-
za meg, amelyik fogadja a hasznos információt. (pl. TCP esetén az érték 6).
Fejzet ellen®rz® összeg (16-bit) érvényességét
megadó
c 2005
A
számított
by http://www.tcpipguide.com/C. M. Kozierok
fejzet érték.
6.32. ábra. IP datagramm beágyazás
A továbbítás során minden alkalommal újból kiszámítódik, amikor a TTL mez® értéke csökken.
6.32
ábra
lényegében
az
OSI
referen-
ciamodellre vonatkozó 2.23 ábra adaptálása.
Forrás IP cím (32-bit)
Azt mutatja, hogy az adatbeágyazás hogyan A datagram forrá-
sának IP címe.
Cél IP cím (32-bit)
A
valósul meg TCP/IP esetén. Mint látható, a legfels® réteget becsomagoljuk egy UDP vagy
A datagram címzettjé-
nek IP címe. A fogadó használhatja a címzés helyességének ellen®rzésére.
IP opciók (változó bit)
egy TCP üzenetbe. Ez lesz a hasznos teher az IP datagramm számára, amit itt csak egy fejzettel látunk el (bár a valóságban egy kicsit összetettebbek a dolgok). Az IP datagrammot
fejrész
ezután átadjuk a 2. rétegnek, ahol az még egy-
jelz® és vezérl®bitek, els®sorban teszte-
szer becsomagolódik valamilyen (LAN, WAN
lési, fejlesztési, biztonsági célokra. (pl.
vagy WLAN) keretbe, ma jd bitekké alakul és
útvonal
továbbítódik a zikai rétegben.
el®írása,
Opcionális
id®bélyeg,
biztonsági
korlátozások, stb). Az IP hálózatokon minden eszköz implementációjának gyelembe kell venni a használt tech-
6.4. IP datagrammok
Hálózati architektúrák és protokollok
62
nológia kapacitási korlátait, miel®tt továbbadná az adatkapcsolati rétegnek. Emiatt létezik egy legnagyobb továbbítható csomagméret (MTU). A küld® csomópont kiszámítja (a legalább 20 bájtos IP fejzet gyelembevételével) a maximális továbbítható csomagméretet, de az a továbbítás során is megváltozhat. A 6.33 ábra szerinti példa egy routerb®l és két zikai vonalból álló hálózatot mutat, ahol az A eszköz a B eszköznek küld adatokat.Az A eszköz és a router közötti kapcsolat MTU értéke
3300
bájt,
a
router
és
a
B
eszköz
között viszont csak 1300 bá jt. Emiatt minden, 1300-nál
nagyobb
IP
datagrammot
fel
kell
darabolni.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
6.35. ábra. IP datagramm kétlépcs®s fragmentációs folyamata
vonalon;
ez
látható
az
ábra
alján.
Vegyük
észre, hogy a második router nem rakja össze az
1300
bájtos
fragmentumokat,
bár
ennek
a vonalnak az MTU értéke 3300 bá jtos. fragmentumok
kialakulásának
A
folyamatát
a
6.35 ábra mutatja.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
6.34. ábra. IP datagramm kétlépcs®s frag-
6.5. Forgalomszervezés (routing)
mentáció Az A 6.34 ábra egy nagyméret¶ IP datagramm
eddigiekben
mással
megtanultuk,
összeköttetésben
lev®
hogy
az
egy-
számítógépek
fragmentálódását mutatja. A dobozok data-
adatokat cserélhetnek egymással. A hálózatba
grammokat
kapcsolt
vagy
azok
töredékét
ábrázolják,
számítógépek
valahogyan
csoporto-
méretarányosan. A nagy szürke doboz ábrá-
sítva
zolja az eredeti, 12000 bájtos datagrammot.
eddigi fejezetekben szerepelt egy olyan elem,
Hogy
amelyik a hálózatok határán helyezkedett el,
ezeket
az
adatokat
a
hálózaton
át
vannak
(alhálózatok,
szegmensek).
Az
továbbitani tudja, az A eszköz az adatokat
mindegyik
négy részre bontja, amit az ábra bal oldalt
olyan
négy színnel mutat. Az els® routernek ezeket a
hálózatokhoz kapcsolódni tudott és ezeknek
fragmentumokat részekre kell bontania, hogy
a
át tudja küldeni az 1311 bájtos MTU érték¶
Ez az egység (router) látja el a hálózatokon
6.5. Forgalomszervezés (routing)
hálózathoz
illeszt®egysége,
címe
illeszkedett
hozzáfért
(volt
amelyikekkel
az
egyes
az
több egyes
hálózatokhoz).
Hálózati architektúrák és protokollok
c 2005
63
by http://www.tcpipguide.com/C. M. Kozierok 6.33. ábra. IP Maximum Transmission Unit (MTU) és a fragmentáció
közleked® datagrammok számára a forgalom-
hozzáférés rétegre jellemz® fejzetet, hogy abba
szervezés
a másik hálózati szegmensre vonatkozó zikai
(az
útvonalválasztás)
feladatát.
A
router legegyszer¶bb formájában egy két hálózati illeszt®kártyával ellátott számítógép, l. 6.36
ábra.
Manapság
a
routerek
jellemz®en
egyre kevésbé több interfészes számítógépek;
A routerek teszik lehet®vé, hogy a különálló alhálózatokból egy egységes Internet jöjjön létre, ezért a routerek cím információ kerüljön bele.
nagyon fontos hálózati eszközök.
egyre inkább speciális eszközöket használnak erre a célra.
c 2004
by Sams Publishing/J. Casad
6.36. ábra. A router mint többcím¶ számítógép
c 2004
A hálózati számítógépek felismerik a sa ját címükre érkez® csomagokat, és csak a nekik
by Sams Publishing/J. Casad
6.37. ábra. Komplex hálózat forgalomszervezése
szóló csomagokat továbbítják a protokollcsomag következ® elemének feldolgozás céljából.
A hálózati forgalomirányítás szerepét job-
A router egységek, mint számítógépek más-
ban megértjük egy összetettebb hálózat ese-
ként viselkednek. Amikor valamelyik portjára
tén. Egy valódi hálózatban:
datagramm annak cél
érkezik,
IP cím ét.
a
router
megvizsgálja
Ha ez a cím ugyanabba
•
csolódhat, ha kett®nél több interfésszel
a hálózati szegmensbe esik, mint ahonnét az üzenet hogy
érkezett,
bármit
akkor
nincs
csináljon,
szükség
ilyenkor
az
rendelkezik. Ilyenkor eleve bonyolultabb
arra,
eldönteni, hová továbbítsuk az adatokat,
üzenet
valamint megnövekszik az adatutak re-
elhanyagolódik. Ha azonban a cél-cím másik hálózati
szegmenshez
tartozik,
a
router
table )
routing
található információk alapján a meg-
felel® helyre továbbítja a küldeményt. Ennek során
megfelel®
módon
kicseréli
6.5. Forgalomszervezés (routing)
a
dundanciája is.
a
saját forgalomirányítói táblázatában (
hálózati
A router kett®nél több hálózathoz is kap-
•
Az összekötött hálózatok maguk is kapcsolódnak
más
hálózatokhoz,
azaz
a
router olyan címeket is lát, amelyekhez nem
kapcsolódik
közvetlenül.
Ilyenkor
Hálózati architektúrák és protokollok
•
64
stratégiát kell kidolgozni arra, hogy ho-
router a cél-hálózat felé. A 6.38 ábrán vagy
gyan továbbítsa az adatokat azokba a
a
hálózatokba, amelyekhez nem kapcsoló-
annak a routernek a címe, amelyiken keresztül
dik közvetlenül.
a router továbbítani tudja az adatokat.
célhálózat
routerének
címe
szerepel,
vagy
Az útválasztás folyamata lehet statikus (ha Többféle adatút is szóba jöhet, a router egységnek kell döntenie, melyiket használja
az adminisztrátor kézzel viszi be az útvonalválasztási adatokat) vagy dinamikus (ha a router maga gy¶jti össze az adatokat a routing protokollokból kapott információk alapján). A 'kö-
A 6.38 ábra olyan egyszer¶ hálózatot mutat, ami négy LAN-ból áll. A hálózatok mindegyikét egy router szolgálja ki, amelynek az az útvonalválasztó táblázata azt mutatja, hogy az egyes célhálózatokba szánt datagrammokat
vetkez® ugrópont' a kulcsfogalom a
forgalomirányítás hálózatban
dinamikus
megértéséhez. Egy összetett
számos
útvonalon
érhetjük
el
a
célt, és a routernek kell eldöntenie, hogy a következ® ugrással melyik útvonalat választja.
melyik routernek kell elküldeni. (A táblázatokban a cím színkódja megegyezik a megfelel® hálózat
színkódjával.)
Mivel
egy
háromszög
csúcspontjaiban vannak, R1, R2 és R3 közvetlenül tud egymásnak datagrammokat küldeni. Azonban, R2 és R3 csak R1-en át tud datagrammot küldeni R4-nek, és R4-nek R1-et kell használnia, hogy elérje a másik két gépet.
c 2004
by Sams Publishing/J. Casad
6.39. ábra. A forgalomszervezése folyamata
A router feladatai:
c 2004
by Sams Publishing/J. Casad
6.38.
ábra.
IP
•
útválasztás
és
útválasztó
táblázatok
Adatot
fogad
a
csatlakozó
hálózatok
valamelyikéb®l
•
Az adatokat a protokol stack-en keresztül továbbítja az Internet rétegnek. Más
Az útvonalválasztó táblázat lényegében a cél hálózatok azonosítóját képezi le a követke-
szavakkal,
z® csomópontra - ami a datagramm útvonalán
réteg fejzet információját, és (ha szük-
a következ® állomás a cél-hálózat felé.
séges) újból összeállítja az IP datagram-
közvetlenül
kapcsolódó
kapcsolódó
hálózatokat.
A
és
közvetve
következ®
ugrás
helye akár a cél-hálózat is lehet (ha az közvetlenül kapcsolódik), vagy pedig a következ®
6.5. Forgalomszervezés (routing)
router
eldob ja
a
hálózati
mot.
A routing táblázat megkülönbözteti a routerhez
a
•
A router megvizsgálja az IP header célcímét.
Ha
a
cím
abban
a
hálózatban
található, ahonnét az adat érkezett, a
Hálózati architektúrák és protokollok
•
65
router elhanyagolja az adatot. (Az adat
számára, és egy alapértelmezett útvonal azon
már valószín¶leg elérte célállomását, mi-
csomagok számára, amelyek nem továbbítha-
vel a cél-számítógép hálózatán továbbí-
tók
tódott.)
irányítási információ már elegend®, hogy egy
helyi
szegmensen
belül.
Ez
a
durva
datagram eltaláljon a rendeltetési helyére. Ha az adatot másik hálózatba szánták, a router megvizsgálja sa ját útválasztási táblázatait, hogy miként továbbítsa az adatokat
•
a
küldjük a datagrammot, de a folyamat nem egyszer¶. Az IP fejzet (lásd 6.31 ábra) csak a
Miután a router meghatározta, melyik hálózati
Ha a cél a hálózaton kívül van, a routernek
adapterén
adatokat,
a
kell
hálózati
továbbítani
hozzáférési
az
réteg
megfelel® szoftverén keresztül továbbítja
küld®
és
a
fogadó
IP
címét
tartalmazza,
nincsenek benne a közbüls® útvonalválasztók címei, amelyeken a datagramm útközben áthalad. Valójában a továbbítás során a router címe nem is kerül bele az IP fejzetbe, hanem a gazdagép átadja a datagrammot és a router
az adatokat az adapternek
IP címét a hálózati hozzáférés rétegnek, ahol a protokoll szoftver külön keresési folyamatot futtat,
hogy
a
datagrammot
egy
olyan
ke-
retbe tegye, amelyik azt helyileg a routerhez szállítja. Másképpen mondva, egy továbbított datagramm IP címe arra a gazdagépre mutat, amelyik esetlegesen megkapja az adatokat. A folyamat részletei:
c 2004
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
by Sams Publishing/J. Casad
6.41. ábra. Az IP továbbítási folyamat
6.40. ábra. Egy üzenet útvonalválasztása az OSI hivatkozási modellben 1. A gazdagép egy datagrammot akar külA router közbüls® eszközként a küld® és fogadó hálózatokat köti össze. Ezen a közbüls® eszközön az üzenet egészen a hálózati rétegig emelkedik, majd (újracsomagolva) halad lefelé egy másik hálózati csatlakozó irányába.
dinamikusan
m¶köd®
hálózatok
esetén
mutatkozik meg igazán. Forgalomirányító pekben
és
a
táblázatok
routerekben
is
a
gazdagé-
találhatók.
A
gazdagépek esetében a táblázat akár két sorral is megadható: egy bejegyzés a helyi hálózat
6.5. Forgalomszervezés (routing)
irányító táblázatait. 2. Ha a datagram nem a helyi hálózatba irányul, a gazdagép megkeresi a táblázatban
A routerek haszna nagy, eltér® alhálózatokból álló,
deni, el®tte megvizsgálja sa ját forgalom-
a
célállomáshoz
tartozó
router
IP címét. (Ha ez egy helyi szegmensben történik,
ez
legvalószín¶bben
a
helyi
alapértelmezett átjáró címe.) 3. A (távoli gazdagépnek küldend®) datagrammot átadja a hálózati hozzáférési rétegnek,
annak
a
routernek
a
zikai
Hálózati architektúrák és protokollok
66
címével együtt, amelyik meg fogja kapni a datagrammot. 4. A router hálózati adaptere megkap ja a keretet. 5. A router kicsomagolja a keretet és átadja a datagrammot az Internet rétegnek. 6. A router megvizsgálja a datagramm IP címét. Ha az megfelel a router sa ját IP címének, akkor a datagramm a routernek szól. Ha nem, akkor a router megpróbálja sa ját forgalomszervezési táblázata alap ján továbbítani a datagrammot
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
6.42.
ábra.
Csomagtovábbítás
a
hálózati
rétegben, ugrópontokkal
a célja felé. 7. Ha a datagramm a routerhez kapcsolódó
rendelkeznek a továbbításhoz szükséges isme-
egyik szegmensbe sem továbbítható, ak-
retekkel. A csomópontok mindig valamelyik
kor a router továbbítja a datagrammot
közvetlen
egy másik routerhez, és a folyamat ott
üzenetet (
next hop routing ).
A 6.42 ábrán a
megismétl®dik (goto step 1), amíg csak
közvetlen
továbbítás
(zöld)
valamely router közvetlenül továbbítani
ilyen ugrópont van (a switch nem az, mivel
nem tudja a datagrammot a cél számí-
az
tógépnek.
helyi indirekt továbbítás esetén két ugrópont
nem
szomszédjuknak
látható
a
küldik
esetén
harmadik
tovább
csak
az
egy
rétegben).
A
van, mivel közben van egy router. Az ábrán A 6. lépésben leírt IP továbbítási folyamat
mutatott
esetben
az
Interneten
át
történ®
a router egy nagyon fontos jellemz®je. Csupán
továbbítás esetén hat ugrópont van; egy tény-
attól még nem router egy számítógép, hogy
leges Internet útvonal lényegesen hosszabb is
két
lehet.
hálózati
interfész
van
benne.
Ha
nincs
hozzá megfelel® szoftver, a datagrammok nem kerülnek át egyik interfészr®l a másikra. Ha nem megfelel® a kon gurálás, a datagrammok egyszer¶en elhanyagolódnak.
c 2004
A 6.42 ábrán háromféle továbbítás látható. Az
els®
eszköze
(zölddel közötti
jelölt)
a
helyi
közvetlen
hálózat
továbbítást
6.43. ábra. Két szegmenst összeköt® router
két
jelöli. Ha a router csak két szegmenst köt össze, a
A második (lila) a helyi hálózat routerrel elválasztott két gépe (szerver és kliens) közötti továbbítást mutat. A harmadik (zöldeskék) pedig egy olyan továbbítást, amelyik a helyi hálózat
egyik
kliense
és
egy
távoli
hálózat
szervere között az Interneten át jön létre. Az utóbbi kett® router közbeiktatásával végzett,
közvetett Az
rétegbeli
továbbítás
csomópontoknál
forgalomirányító táblázat nagyon egyszer¶. A 6.43 ábra szerinti router soha nem találkozik olyan
IP
címmel,
amelyik
nem
valamelyik
portjához tartozik, és a router közvetlenül kapcsolódik mindkét alhálózathoz. Azaz, a router minden datagrammot közvetlen címzéssel tud továbbítani.
továbbítás.
aktuális
by Sams Publishing/J. Casad
olyan, történik,
Tekintsük a kicsit bonyolultabb esetet a
harmadik amelyek
6.44. ábrán. a
6.5. Forgalomszervezés (routing)
3.
Ha az A router nem csatlakozik
szegmenshez,
segítség
nélkül
nem
kap
Hálózati architektúrák és protokollok
c 2004
67
by Sams Publishing/J. Casad
6.44. ábra. Adattovábbítás közvetett csatolású routerek esetén
információt a 3. szegmensr®l. Ezt a helyzetet hívják közvetett forgalomirányításnak. A legtöbb hálózat valamilyen mértékben használja a
közvetett
forgalomirányítást.
Nagy
céges
hálózatokban routerek tucatjait találjuk, ame-
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
6.45. ábra. Why address resolution is necessary
lyek közül csak egy-kett® kapcsolódik közvetIn Fig 6.45, a client on the local network is
lenül valamelyik szegmenshez. A közvetett címzésre vonatkozó informáci-
accessing a server somewhere on the Internet. This
ót beszerezhetjük
connection
directly
•
a rendszer adminisztrátorától (static)
•
a többi routert®l (dynamic)
between
apparently the
client
can and
be
made
server,
but
in reality it is sequence of physical links at layer two. In this case most of the six links lie between the client and server. At each step
For little network even the static method
the decision where to forward the data is made
can be appropriate. However, only the dyna-
based on a logical (layer three) address, but
mic method can take into account dynamic
the
changes of the network. The network shown in
using the physical (layer two) address of the
Fig 6.44 can use the default con guration. Ro-
next intended recipient in the route.
actual
transmission
must
be
performed
uter A shall not know anything about segment 3. It is enough if it sends the datagrams with an unknown address to router B, and relies on router B, what to do with it.
6.6. Címfeloldó protokoll (ARP) Ahhoz,
hogy
küldeni
egy
ismernie
egy
gazdagép
másik
kell
gép
annak
adatot
hálózati
zikai
tudjon
adapterére,
címét.
Emiatt
a
címfeloldó protokol(ARP, Address Resolution Protocol) nagy jelent®séggel bír. A TCP/IP implementációja azonban olyan, hogy az ARP (és általában a zikai cím feloldásának folyamata) csaknem teljesen láthatatlan marad a felhasználó
számára.
A
felhasználó
számára
egy hálózati adaptert annak IP címe azonosít.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
A színfalak mögött azonban ezt az IP címet le kell képezni egy zikai címre, hogy az üzenetek célbaérjenek.
6.6. Címfeloldó protokoll (ARP)
6.46. ábra. Dynamic address resolutiony
Hálózati architektúrák és protokollok
In
Fig
6.46,
data to device
IP B ,
address
A
device
B,
needs
68
to
send
but it knows only its IP
and not its hardware address.
A broadcasts a request asking to be sent the hardware address of the device using the IP qaddress
IP B . B
A
responds back to
directly
with the hardware address.
RARP
Az RARP az ARP fordított m¶vele-
te. Az ARP protokollt akkor használjuk, amikor az IP címet ismerjük és a zikai címet nem. Az RARP protokollt akkor használjuk, amikor a zikai cím ismert, az
IP
cím
viszont
nem.
Az
RARP
protokollt gyakran használják a BOOTP
c 2004
by Sams Publishing/J. Casad
6.47. ábra. Az ARP képezi le az IP címeket zikai címekké
protokollal karöltve, mágneslemez nélküli munkaállomások elindításakor.
BOOTP
többi számítógépe megkapja a kérést, és az
Sok hálózati adapter tartalmaz egy
üres foglalatot, amibe egy boot PROM funkciójú integrált áramkört lehet belerakni.
Ennek
bekapcsolása
rmware-e után
a
azonnal
számítógép elindul,
és
betölt egy operációs rendszert a számító-
a számítógép, amelyik a keresett IP címmel rendelkezik, elküldi saját zikai címét a kérést eredetileg zikai
mezr®l.
és
A
nem
egy
BOOTP
helyi
mágnesle-
eszközre
letöltött
operációs rendszer egy bizonyos IP címre
leképezésre
vonatkozó
A
logikai-
információt
a
tárában elmenti. Az
ARP
gyorsítótárban
a
bejegyzések
általában egy el®re meghatározott id® után elévülnek. évül,
az
Amikor törl®dik
következ®
van el®-kon gurálva.
számítógépnek.
kérést küld® számítógép sa ját ARP gyorsító-
gép memóriá jába, mégpedig egy hálózati szerverr®l
küld®
az
elévült
egy a
ARP
bejegyzés
táblázatból.
alkalommal
a
bejegyzésnek
Amikor
gazdagépnek megfelel®
IP
ela
ismét címre
kell adatot küldenie, a címfeloldási folyamat A hálózati szegmens minden egyes gazdagépé-
újrakezd®dik.
nek memóriájában található egy ARP táblázat
áttekinteni, hogyan megy végbe
folyamat
vagy egy ARP gyorsítótár (cache). A
gyorsítótár
rendeli
hozzá
a
hálózati
(l.
Érdemes
ezen
az
animáción
a teljes ARP
http://www2.rad.com/networks/
2005/clieserv/ClieServ.swf/).
szegmens többi gazdagépének IP címét zikai címekhez (lásd 6.47 ábra). Amikor egy gazdagépnek üzenetet kell küldenie a szegmens egy másik gazdagépének, a gazdagép megvizsgálja az
ARP
gyorsítótárat,
hogy
megtalálható-e
benne a célgép zikai címe. Az ARP gyorsítótár cím
dinamikusan
pillanatnyilag
gyorsítótárban,
a
változik. nem
Ha
a
található
gazdagép
kiküld
keresett az egy
cso-
címkeresésnek (ARP request frame) hívnak. ARP
címkeresés
egy
feloldatlan
IP
címet tartalmaz, továbbá a kérést küld® gép IP címét és zikai címét. A hálózati szegmens
7. Adatkapcsolati
7.1. Áttekintés
ARP
portos üzenetet (lásd 6.47 ábra), amit ARP
Az
7. Az OSI modell adatkapcsolati (2.) rétege I.
A 2. (adatkapcsolati) réteg általában magában foglalja az operációs rendszer eszközmeghajtó ját,
valamint
számítógép
megfelel®
hálózati interfész kártyá ját. (7.1 ábra) funkciói:
Hálózati architektúrák és protokollok
69
Logikai kapcsolatvezérlés
-
Logical
Link
Control (LLC) A helyi hálózati eszközök közötti kapcsolat létrehozása és vezérlése. Szolgáltatást nyújt a felette lev® rétegnek és elrejti a különböz® technológiák esetlegességeit a fels®bb rétegek el®l. A legtöbb helyi hálózati technológia az IEEE 802.2 LLC protocolt használja.
c 2004
http://www.globalknowledge.com
Közeg hozzáférés vezérlés
7.1. ábra. Az OSI adatkapcsolati (data link) rétege
- Media Access
Control (MAC) A hálózati közeg hozzáférésének vezérlése. A legtöbb hálózat közös jelátviv®
•
lehet®vé teszi, hogy az eszköz elérje a
közeget használ (pl. ugyanazt a hálózati
hálózatot, üzenetek küldése és fogadása
kábelt), szabályozni kell az ehhez való
céljából; együttm¶ködik az eszköz háló-
hozzáférést.
zati szoftverével
•
•
biztosít egy zikai (MAC) címet, hogy
Adatkeretezés A hálózati csomag okat keret ekbe
rétegt®l
kapott
foglalja.
Ez
a
az eszköz adatot küldhessen a hálózaton
réteg végzi a fels®bb rétegeib®l kapott
át
üzenetek végs® keretezését, amiket már csak át kell küldeni a zikai rétegen, lásd
hiba észlelési lehet®séget biztosít
7.2 ábra.
A 2. (adatkapcsolati) réteg (7.1 ábra) tipikus eszközei:
•
hálózati interfész kártya (NIC)
•
switch (Ethernet és Token ring)
•
bridge
c 2003
A MAC cím alap ján a switch sz¶ri és irányítja a forgalmat, segít megel®zni a hálózati szeg-
by Prentice Hall/A. S. Tanenbaum
7.2. ábra. A csomagok és a keretek közötti kapcsolat
mensen belül torlódást és ütközést. A bridge és a switch hasonlóképpen m¶ködik, de a bridge általában a
switch
egy
szofver
pedig
programot
dedikált
m¶ködtet,
hardverként
sokkal
gyorsabb m¶ködés¶.
Címzés
Ez
az
amelyik
OSI
még
modell
címzéssel
legalsó
rétege,
foglalkozik:
a
hálózat minden eszközének egyedi száma van
(amit
hardver
címnek
vagy
MAC
címnek hívnak), amit az ebben a rétegA hálózaton belül továbbítandó üzenetek az adatkapcsolati rétegbe kerülnek. F®ként ebben a
rétegben
m¶ködnek
azok
a
technológiák
(Ethernet, Token Ring, FDDI és 802.11 (WiFi), amelyekkel összekötött eszközök összes-
ben használatos protokollok használnak arra, hogy az egy bizonyos gépnek szánt adatok biztosan célbaérjenek.
Hiba észlelés és kezelés
A protokoll stack
ségét hálózat névvel illetjük. Néha még ezt a
alsóbb
szintjein
réteget is el®nyös Logical Link Control (LLC)
kezeli.
Például,
és Media Access Control (MAC) alrétegekre
dundancia vizsgálattal (CRC) ellen®rzi,
osztani.
hogy az adatok épségben megérkeztek-e
Az adatkapcsolati réteg f®bb funkciói:
7.1. Áttekintés
el®fordulható általában
a fogadó állomásra.
hibákat
ciklikus
re-
Hálózati architektúrák és protokollok
70
Az adatkapcsolati réteg általában háromféle szolgáltatást nyújt:
•
összeköttetés nélküli, nyugta nélküli Független
keretek,
nincs
kapcsolatépí-
tés. Jól alkalmazható kis hibas¶r¶ség¶ kapcsolatban.
•
összeköttetés nélküli, nyugtázott
c 2004
by Cisco Press/M. J. Castelli
El®nyösebb darabokra tördelt üzenetet darabonként nyugtázni, nagyobb hiba-
7.4. ábra. MAC cím
s¶r¶ség¶ hálózatokban el®nyös.
•
összeköttetés alapú, nyugtázott
Ebben
a
rétegben
már
tipikusan
hardver
eszközök szerepelnek, ezek fejlesztése az eddig Megbízható keretfolyamot hoz létre. A keretek
pontosan
egyszer
és
megfelel®
sorrendben érkeznek meg.
megismert
rétegekt®l
adatkapcsolati
Az adatkapcsolati protokoll elhelyezkedését a 7.3 ábra mutatja.(ne feledjük, ez a logikai útvonal, a tényleges kommunikáció a zikai rétegen át halad!)
eltér®
úton
történt,
a
nyelvezete is eltér az eddig megismertt®l. Az réteg
funkcióit
általában
ún.
hálózati illeszt®kártyák realizálják. Egy olyan eszköz, mint az ethernet illeszt®kártya, nem tud semmit sem a fels®bb réteg protokolljairól. Nem ismeri saját IP címét sem, meg azt sem tudja, hogy a beérkez® csomagot a Telnet vagy FTP számára kell továbbítania. Egyszer¶en csak fogadja a bejöv® adatkereteket, olyan adatkeretet vár, amelyik sa ját zikai címére érkezik, és az ilyen kereteket továbbítja felfelé a protokoll stack-ban. A
hálózati
zikailag
illeszt®kártya
elérhet®
minden
csomaghoz
(alapbeállításként) csak a saját
egyes,
hozzáfér,
de
zikai cím ére
érkez® csomagokra gyel és csak azokat továb-
c 2003
by Prentice Hall/A. S. Tanenbaum
bítja a következ® rétegnek, amelyik neki szól.
7.3. ábra. Az adatkapcsolati protokoll elhe-
Lehet olyan beállítást használni (pl. kémprogram vagy hálózati csomaganalizátor esetén),
lyezkedése
amelyben minden egyes csomag továbbítódik a következ® rétegnek.
A csomópontoknak adott logikai cím mellett a csomópontokat a hálózatra kapcsoló zikai eszköz, a hálózati illeszt®kártya (network interface) egy egyedi, a gyártás során kapott azonosítószámmal is rendelkezik, lásd 7.4 ábra.
Való jában
a
helyi
hálózatban
átküldött
adatkeretek a küld® és fogadó interfész kártyák 48-bites zikai címét tartalmazzák, de annak használata még barátságtalanabb, mint az IP számoké. Szerencsére, a felhasználó szinte soha nem találkozik vele.
7.2. A közegelérési alréteg
7.2. A közegelérési alréteg Az egymással verseng® felhasználók között pl. frekvenciaosztásos nyalábolással (FDM) lehet kiosztani a kommunikációs csatornákat. Ennek hatékonyságát a sorbanállási elmélet alap ján egyszer¶en becsülhetjük. Ha a keretek hosszát
1/µ
[bit/keret] várható érték¶ exponenciális
eloszlás
határozza
meg,
statikus
csatornaki-
Hálózati architektúrák és protokollok
71
7.3. Csatornakezel® protokollok
osztás esetén a rendszerben eltöltött id®
T = 1/(µC − λ) (az érkezési intenzitás
Az ALOHA rendszer lényege, hogy a felhasz-
λ keret/s, a kiszolgálási
µC keret/s)
intenzitás
lásd
7.5
ábra.
Visszacsatolásra,
az
elküldés
sikerességének gyelésére van szükség.
ahol
C
náló akkor ad, amikor akar (és amikor tud),
a csatorna kapacitása, [b/s]
λ
az érkez® adatok intenzitása [keret/s]
µ
a kerethossz eloszlásparamétere
T
az igény által a rendszerben eltöltött id® [s]
azaz a rendszer csak nagyon kevéssé hatékony. Ha
a
N
rendszert
darab
juk, azok mindegyike
C/N
alcsatornára
vág-
[b/s] kapacitással
rendelkezik, és az alcsatornákon az érkezési
λ/N ,
intenzitás
TF DM
c 2003
by Prentice Hall/A. S. Tanenbaum
akkor
N 1 = = NT = µ(C/N ) − (λ/N µC − λ
7.5. ábra. Kerettovábbítás az egyszer¶ ALOHA rendszerben
Egy
lesz a vonal kapacitása.
keret
akkor
nem
szenved
ütközést,
ha
elküldése során (az els® pillanattól az utolsóig)
Állomás
Továbbítandó
függetlenül.
∆t
kereteket
id®
alatt
generál,
λ∆t
keret
állomás
nem
ad,
lásd
7.6
ábra.
Nincs
id®szinkronizálás, ezért egyszer¶. Viszont, a keretek ütközhetnek, elveszhetnek, stb.
generálódik
Csatorna
más
Egyetlen
csatornát
használunk
adatforgalomra
Ütközés
(collision) legalább két keret egyide-
j¶ továbbítása
Id® Folyamatosan adhatunk Diszkrét id®közönként folytonos
id®t
adhatunk.
id®résekre
A
osztjuk.
Kerettovábbítás csak az id®rés elején
lehetséges.
Egy
id®rés
c 2003
by Prentice Hall/A. S. Tanenbaum
tartal-
mazhat nulla keretet (üres), 1 ke-
7.6. ábra. Ütközésveszély a keretek között
retet (sikeres továbbítás), több keretet (ütközés).
Viv®jel érzékelés
Az 7.6 ábra azt sugallja, hogy érdemes lenne (carrier sense) Az állomá-
az id®t
to
szélesség¶
id®rés ekre
osztani. Egy
sok meg tudják állapítani, hogy a csator-
adott id®rés alatt
na foglalt-e, miel®tt adni kezdenek.
Gk e−G k! valószín¶séggel keletkezik k új keret. Az ALO-
van - meg sem próbál adni nincs - elkezd adni 7.3. Csatornakezel® protokollok
Pr [k] =
HA rendszerek átereszt®képességét a 7.7 ábra
Hálózati architektúrák és protokollok
72
mutatja. A réselt ALOHA kapacitása valóban
Az
ütközés
érzékeléséhez
gyelembe
kell
kétszerese az egyszer¶ ALOHA rendszernek.
venni az állomások közötti terjedési id®t is.
Az ár, hogy központi órát kell építeni.
Azaz, el®fordulhat, hogy az állomás elkezd adni, de egy távoli állomás ugyanakkor elkezdett adni (az is szabadnak érezte a csatornát), a terjedési id® lejártával ez az állomás ütközést észlel, és leállítja az adást. Még egy jó érv, hogy a hálózatokat a lehetséges legkisebbre méretezzük.
c 2003
by Prentice Hall/A. S. Tanenbaum
7.7. ábra. ALOHA rendszerek átereszt®képessége
c 2003
Egy másik lehetséges elv, hogy az adó belehall-
by Prentice Hall/A. S. Tanenbaum
7.9. ábra. A CSMA/CD protokoll állapotai
gat a csatornába, és ha üresnek találja, valamilyen valószín¶séggel adni kezd, esetleg valamilyen véletlen hosszúságú késleltetés után. Érdekes módon a kevésbé mohó, türelmesebb
Ezekben a protokollokban az állomások nem függetlenek;
el®írjuk,
hogy
melyikük
adhat.
Például, a bittérképes protokollban (lásd. 7.10.
módszer sikeresebb, lásd 7.8 ábra.
ábra) mindegyik állomás jelezheti saját jelz®bitjének 1-be állításával, hogy van kész kerete. A következ® id®szakban az állomások sorban elküldik
saját
keretüket,
az
ütközésre
nincs
lehet®ség.
c 2003
c 2003
by Prentice Hall/A. S. Tanenbaum
7.8. ábra. Véletlen hozzáférés¶ protokollok
by Prentice Hall/A. S. Tanenbaum
7.10. ábra. Az alapvet® bittérkép protokoll
átereszt®képessége Ezek a protokollok az állomások együttm¶Megint
másik
lehetséges
elv,
hogy
az
adó
ködésén
alapszanak.
Az
állomások
jelzik
a
folyamatosan hallgatja a csatornán folyó for-
szomszédoknak, hogy milyen m¶veletre készül-
galmat, és ha az nem egyezik az általa kül-
nek. A szomszédok a m¶velet alatt csendben
dött adással, azonnal beszünteti m¶ködését.
maradnak. Például, (lásd. 7.11 ábra) ha az A
Ezután
adnia,
állomás B állomásnak akar üzenetet küldeni,
hiszen úgyis az összes, éppen a csatornában
már
felesleges
lenne
tovább
a rádióállomások véges hatósugara miatt A
folyó keret sérült lenne.
Véletlen hosszúságú
üzenetét hallja C, de nem hallja D, így D el-
ideig vár, majd újra versenybe száll az adási
kezdhet adni, miközben B éppen válaszkeretet
jog
egy
akar küldeni. Ha azonban A egy RTS (Request
állomás háromféle állapotban lehet, lásd 7.9
To Send) jelzést küld és arra B CTS (Clear To
ábra: vagy tétlen, vagy ad, vagy pedig az adási
Send) üzenettel válaszol, az utóbbit D is hallja
jog megszerzéséért küzd.
és a forgalmazás alatt csendben marad.
megszerzéséért.
Ebb®l
következ®en
7.3. Csatornakezel® protokollok
Hálózati architektúrák és protokollok
c 2003
73
by Prentice Hall/A. S. Tanenbaum
7.11. ábra. Egy ütközéselkerüléses protokoll
c 2004
(MACA)
http://www.globalknowledge.com
8.1. ábra. Az OSI zikai (physical) rétege
valamint
kábelezési
követelményeket
tartal-
maz. Elektromos, mechanikai, funkcionális és módszerbeli követelményeket támaszt ahhoz, hogy egy bitfolyamot a számítógéphálózatra küldhessünk. A réteg komponensei:
•
a rendszer komponensei közötti kábelezés
•
a médiumokat a zikai interfészhez kapcsoló adapterek
•
csatlakozók
tervezése
és
az
érintkez®k
számozása
•
hub, repeater és patch panel speci kálása
c 2008
•
vezeték nélküli rendszer komponensei
•
hálózati interfész (NIC)
by http://www.Wikipedia.org
7.12.
ábra.
A
CSMA/CD
egyszer¶sített
folyamatábrája
8. Az OSI modell zikai (1.) rétege I. 8.1. Áttekintés
8.2. Az átvitel technikai megvalósítása Analóg és digitális átvitelt használhatunk a technikai megvalósítás során. A kétfajta átvitel tula jdonságai jelent®sen különböznek:
Analóg jel
Simán (törés nélkül) változik az
id®vel, lásd 8.2. fels® ábra.
Digitális jel Az ben
1.
( zikai)
csatlakozó
és
réteg
(8.1
interfész
ábra)
lényegé-
speci kációkat,
8.2. Az átvitel technikai megvalósítása
Egy ideig állandó, ma jd másik
állandó értéket vesz fel, lásd 8.2. alsó ábra.
Hálózati architektúrák és protokollok
74
c 2004
c 2004
by Prentice Hall/W. Stallings
by Prentice Hall/W. Stallings 8.4. ábra. Példa digitális jeltovábbításra
8.2. ábra. Példa analóg és digitális jelre
Analóg átvitel esetén, lásd 8.3 ábra:
•
a tartalom lényegtelen
•
analóg jellel analóg és digitális adatot is továbbíthatunk
•
a jel a távolsággal csillapodik, er®síteni kell
•
a za jt is er®sítjük
c 2004
c 2004
by Prentice Hall/W. Stallings
by Prentice Hall/W. Stallings 8.5.
8.3. ábra. Példa analóg jeltovábbításra
Digitális átvitel esetén, lásd 8.4 ábra:
Az
ábra.
Periodikus
analóg
és
digitális
jelalak
Periodikus jel
a jelalak bizonyos id®közön-
ként ismétl®dik. Analóg és digitális je-
•
a tartalom fontos
•
ismétl®ket kell használni
•
amplitúdó
•
nincs csillapítás, zajt nem er®sít
•
frekvencia (hullámhossz)
•
fázis
átvitel
során
egyaránt
lekre egyaránt értelmezhet®. Jellemz®i:
el®fordulhatnak
periodikus és aperiodikus jelek, lásd 8.5 ábra:
8.2. Az átvitel technikai megvalósítása
A jelalak ismétl®dési ideje a T periódusid®, a jelismétl®dések id®egységre es®
Hálózati architektúrák és protokollok
75
f frekvencia (gyakoriság). A kett® közötti összefüggést a T = 1/f képlet írja le. A λ hullámhossz az egy
nálnak, amikor is a viv®hullám valamely jel-
periódusid® alatt megtett távolság (ha a
A
száma
a
haladási sebesség
Aperiodikus jel
v,
akkor
λ = vT ).
Az átvitel során váltóáramú jelzést hasz-
lemz® jét használják az információ átvitelére. 8.7
ábra
a)
részén
az
átviend®
digitális
jel, a b) részén ennek amplitudómodulált, a c) részén frekvenciamodulált, a d) részén a
a jelalaknak nincs ilyen jel-
lemz® ismétl®dési ideje
fázismodulált formája látható. Itt (legalább) két különböz® jelamplitudót, frekvenciát vagy fáziseltolást használnak a digitális jel átvitelére.
8.3. Az adatátvitel elméleti alapjai Bármely,
T
periódusidej¶
g(t)
függvény el®ál-
lítható szinuszos és koszinuszos tagok (végtelen) összegeként:
c 2004
by Prentice Hall/W. Stallings
8.6. ábra. Egy egyszer¶sített kommunikációs modell
∞ ∞ X 1 X an sin (2πnf t)+ bn cos (2πnf t) g(t) = c+ 2 n=1 n=1
f = 1/T az alapfrekvencia, an és bn pedig az n-edik harmonikus (tag) szinuszos ahol
Az
átvitel
során
használhatunk
digitális
és/vagy analóg jelábrázolást, szimplex/duplex
ill. koszinuszos amplitudó ja.
átviteli módot, stb; ezek a részletek az átlag felhasználó
el®tt
rejtve
maradnak,
lásd
8.6
ábra.
Egyre több ilyen harmonikust használva, egyre
g(t)
jobb
közelítéssel
tudjuk
összerakni
a
függvényt (lásd 8.8 és 8.9 ábra). Attól
függ®en, hogy az átviteli közeg milyen frekvenciájú harmonikusokat tud átvinni, különböz® jósággal tudjuk rekonstruálni az átvinni kívánt jelalakot. Más megfogalmazásban, az átvitel frekvenciahatárolása korlátozza a közegen átvihet® jelzés frekvenciáját.
A zikai átvitelkor a jelek gyengülnek, a jelalak is megváltozik, lásd 8.10 ábra. Másként
azt
is
mondhatjuk,
hogy
a
különböz®
harmonikusok különböz®képpen gyengülnek a továbbításkor.
Így
elegend®
csak
az
egyes
harmonikusok átvitelét vizsgálni, ami viszont elég jól ismert és kényelmesen kezelhet® mind matematikai szempontból, mind a megvaló-
c 2004
by Prentice Hall/W. Stallings
sításkor ún. sávsz¶r®kkel. A még elfogadható
8.7. ábra. Digitális jel átvitelének moduláci-
mérték¶
gyengülés
frekvenciatartománya
alapján de niáljuk a sávszélességet.
ós lehet®ségei Egy tökéletes átviteli csatornának is véges az átviteli kapacitása:
8.3. Az adatátvitel elméleti alapjai
Hálózati architektúrák és protokollok
76
zet® szálak használata, amelyeken elektronok vagy fotonok felhasználásával továbbítják az adatokat. A vezeték nélküli átvitelre a rádióhullámok valamely fa jtáját használják.
8.3.1. Sávszélesség és sávkihasználás A jeltovábbításban vannak olyan frekvenciatartományok,
amelyeken
belül
a
csillapítás
viszonylag azonos; néha ún, sz¶r®kkel mesterségesen is megnövelik a csillapítást.
c 2004
A. S. Tanenbaum: Computer Networks
8.8. ábra. Digitális jel és fokozatos közelítése
c 2004
c 2004
A. S. Tanenbaum: Computer Networks
8.11. ábra. Frekvenciaosztásos multiplexelés
A. S. Tanenbaum: Computer Networks
8.9. ábra. Digitális jel fokozatos közelítése
A
gyakorlatban
az
átviv®
közeg
tényle-
ges sávszélessége jóval meghaladja az átvinni kívánt
sávszélességet.
Pl.
amikor
egy
nagy
sávszélesség¶ telefonvonalon emberi beszédet akarunk
átvinni,
csak
kb.
3
kHz
szélesség¶
csatornára van szükségünk, az átviv® közeg
c 2004
by Prentice Hall/W. Stallings
kapacitása
8.10. ábra. Digitális jelek átviteli csillapítása
ezt
sokszorosan
meghaladja,
és
lehet®vé tesz, hogy egyidej¶leg több beszélgetést is továbbítsunk ugyanazon a közegen.
Max. adatsebesség = ahol
H
2H log2 (V )
Az átviteli kapacitás kihasználására különbö[b/s]
a csatorna sávszélessége, és
V
az
átvitt jel diszkrét szintjeinek száma. Zajos csatorna esetén (ahol a zajosságot a hasznos jel és a zaj teljesítményének arányával jellemzik, ez a S/N arány) Max.
adatsebesség
=
H log2 (1 + S/N )
[b/s] Ez egy olyan fels® korlát, amit a gyakorlatban el®forduló esetekben nem érünk el. Vezetékes átvitelre a gyakorlatban kétféle technika terjedt el: a fémvezetékek és a fényve-
8.3. Az adatátvitel elméleti alapjai
z® technikák alakultak ki. A 8.11 ábrán az ún.
frekvenciaosztásos
multiplexelés
(Frequ-
ency Division Multiplexing, FDM) látható: az egyes beszélgetések alapfrekvenciáját különböz® mértékben megnövelik, és a multiplexelt csatornában már az egyes csatornák egymás szoros közelségében, egyidej¶leg haladnak. Az egyes átviend® csatornáknak minden id®pillanatban ténylegesen csak az átviteli kapacitás töredéke áll rendelkezésre.
Hálózati architektúrák és protokollok
c 2004
77
A. S. Tanenbaum: Computer Networks
8.12. ábra. Hullámhosszosztásos multiplex-
c 2006
elés
by CISCO
8.14. ábra. A sodrott érpáras kábel felépítése A
telefontechnikában
használatos
fenti
megoldás született újjá a fénykábelek esetén: különböz® hullámhosszú fénnyel küldött információ halad ugyanazon az üvegkábelen (Wave Division Muliplexing, WDM) lásd 8.12 ábra) nagy távolságon, majd a végállomástól külön
A legrégebbi, de még ma is használt közeg a csavart érpár (twisted pair). Két szigetelt rézhuzalból áll, amelyet meghatározott módon spirálszer¶en
megtekernek,
lásd
8.14
ábra,
hogy az antenna-hatást csökkentsék. A sodrott
folytatja útját.
érpárok esetén a sodrás jelent®sen befolyásolja az árnyékoló hatást. Egy kábelben több érpárt is elhelyeznek, lásd 8.15 ábra. Az árnyékolás javítására küls® árnyékoló burkolatot is alkalmazhatnak, az érpárokra egyenként, vagy az összes érpárra egy küls® árnyékolást, lásd 8.16 ábra.
c 2004
A. S. Tanenbaum: Computer Networks 8.13. ábra. Id®osztásos multiplexelés
Az
átviend®
jelek
mintavételezése
gyor-
san kivitelezhet®, a Nyquist tétel értelmében a
maximálisan
szükségesnél
nagyobb
min-
tavételezési gyakorisággal már nem nyerünk plusz
információt,
így
további
csatornákból
vett mintákat tudunk egyidej¶leg továbbítani.
c 2003
The Computer Language Co
8.15. ábra. A sodrott érpáras kábel árnyékolása
Ilyenkor az egyes csatornák jelei egyidej¶leg, de
különböz®
id®szeletekben
továbbítódnak,
lásd 8.13 ábra. Kivitele szerint lehet árnyékolatlan (Uns-
8.4. Vezetékes adatátvitel 8.4.1. Fémvezetékek
hielded
Twisted
Pair,
UTP)
vagy
drágább,
kevéssé használt árnyékolt (Shielded Twisted Pair, STP). Az UTP a legelterjedtebb kábeltípus pl. épületen belüli kábelezés készítéséhez. Vegyük
8.4. Vezetékes adatátvitel
észre
a
jellemz®
távolságokat
és
a
Hálózati architektúrák és protokollok
78
c 2006
by CISCO
8.18. ábra. A koaxiális kábel szerkezete
c 2006
8.19 ábra:
by CISCO
8.16. ábra. A sodrott érpáras kábel néhány típusa
c 2006
by CISCO
8.19. ábra. Fémes vezet®kábelek speci kációja
c 2006
by CISCO
8.17. ábra. Az UTP kábel tipikus használata
hálózati eszközök beiktatását a csomópontok közé.
A
koaxiális
kábel
esetén
a
vezetékszál
szigetel®vel és árnyékolással körülvett fémszál. Egy
másik,
szintén
elég
régi
kábelfa jta.
Jó
az árnyékolása és nagy a sávszélessége, ezért f®ként analóg jelátvitelre használják.
A kábelek jelölése a kábelek f®bb jellemz®it
c 2006
by CISCO
adja meg: a kábel üzemi sebességét, a hullámsávot, a maximális jeltovábbítási távolságot, l.
8.4. Vezetékes adatátvitel
8.20. ábra. A hálózati kábelek lezárása
Hálózati architektúrák és protokollok
79
A hálózati kábeleken hullámok haladnak, amelyek a kábel végein visszaver®dhetnek. A visszaver®dött hullámot,
hullám
ezért
a
gyengítheti
kábelek
végét
a
vámpír csatlakozóval az egyes csomópontokat, lásd 8.21 ábra. (ez volt a locsolócs®).
terjed®
megfelel®
A
koaxiális
kábelek
ennél
könnyebben
ke-
zelhet®k, a csatlakoztatásuk is egyszer¶bben
ellenállással le kell zárni.
kivitelezhet®. A koaxiális kábelekre a számítógépeket T alakú, BNC kivitel¶ csatlakozókkal (lásd
8.24-8.26
ábrák)
f¶zik
fel
(lásd
8.23
ábra).
c 2006
by CISCO c 2006
by CISCO
8.21. ábra. 10BASE5 kábelezés 8.23. ábra. 10BASE2 kábelezés
c 2006
by CISCO
8.24. ábra. Koaxiális kábel BNC csatlakozóval
c 2006
by CISCO 8.22. ábra. Az UTP kábelcsatlakozó Mind a rézvezetékes, mind a száloptikás
Kezdetben viszonylag vastag kábelt használtak,
lásd
8.22
ábra,
erre
f¶zték
fel
ún.
kábeleket csatlakoztatni kell az eszközökhöz, és egymáshoz. A csatlakozó típusa RJ (registered jack), az egyes típusokat szám azonosítja.
8.4. Vezetékes adatátvitel
Hálózati architektúrák és protokollok
c 2006
80
by CISCO
8.25. ábra. Koaxiális kábel T csatlakozóval
c 2006
by CISCO
8.26.
ábra.
Koaxiális
kábel
T
csatlakozó
véd®sapkában
c 2004
Cisco Press/M. J. Castelli
8.27. ábra. RJ-45 típusú csatlakozó és aljzat
c 2008
by http://www.americantechsupply.com
8.28. ábra. Optikai kábelek csatlakozói A legelterjedtebb RJ-45 legfeljebb 8 vezetéket tartalmaz, lásd 8.27 ábra. Az optikai csatlako-
készült nom üvegszálak találhatók. Az opti-
zók spektruma jóval szélesebb, lásd 8.28 ábra.
kai jeltovábbítás esetén a jeltovábbító közeg a
vékony
üvegszál,
amelyneknek
két
végén
fényforrás, illetve fénydetektor található. Egy
8.4.2. Optikai kábelek
vékony
üvegrétegen
belül
a
fény
jelent®s
veszteség nélkül tud terjedni, sorozatos teljes Az optikai kábelekben nagytisztaságú üvegb®l
8.4. Vezetékes adatátvitel
visszaver®dések útján (lásd 8.29 ábra). Az op-
Hálózati architektúrák és protokollok
81
tikai szál sa játos geometriájában a fény a teljes visszaver®dés
révén
a
bels®
szálban
marad
(lásd 8.30 ábra). Könny¶, olcsó, biztonságos technológia.
c 2006
by CISCO
8.29. ábra. A teljes visszaver®dés két eltér® törésmutatójú közegben
c 2006
by CISCO
8.31.
ábra.
Az
optikai
kábel
módusainak
értelmezése
c 2006
by CISCO
8.30. ábra. A teljes visszaver®dés jelensége koncentrikus hengerekben
Az elegend®en vastag optikai szálon belül minden, a határszögnél nagyobb szögben belép® fénysugár terjedni tud, ilyenkor a szál
módusú ,
több-
lásd 8.31 ábra. Ha a szál vastagsága
mindössze
a
szorosa,
szál
a
fény
hullámhosszának
hullámvezet®ként
néhány-
viselkedik,
a fény pedig a szál tengelye mentén terjed.
egymódusú
Ilyenkor a szál (
c 2006
by CISCO
szál) fényvezet®. A
numerikus appertúra azt a szöget adja meg,
8.32. ábra. A numerikus appertura értelme-
amelynél
zése
teljes
kisebb
szögben
visszaver®dést
bees®
fénysugarak
szenvednek,
lásd
8.32
ábra.
•
kevésbé zavarérzékeny
Az optikai adatátvitel el®nyei a rézvezetékessel
•
veszélyes környezetben is alkalmazható
•
nem kell lecserélni a technológia fejl®dé-
szemben
•
sokkal nagyobb a sávszélessége
•
sokkal olcsóbb és könnyebb
8.4. Vezetékes adatátvitel
sével
Hálózati architektúrák és protokollok
82
c 2004
A. S. Tanenbaum: Computer Networks 8.35. ábra. Rádiófrekvenciás átvitel
de visszaver®dnek az ún. ionoszféráról. A rádióhullámok terjedéskor gyelembe kell venni a meteorológiai viszonyokat is. A tömeges felhasználási igény miatt szigorúan szabályozni
c 2008
kell az adók frekvenciá ját és teljesítményét is.
by http://www.informationeconomy.sa.gov.au
8.33.
ábra.
A
fém
és
az
optikai
kábel
összehasonlítása
8.5. Vezeték nélküli adatátvitel
c 2004
A. S. Tanenbaum: Computer Networks
8.36. ábra. Kommunikációs m¶holdak tulajdonságai
c 2004
A. S. Tanenbaum: Computer Networks
8.34.
ábra.
Az
A
elektromágneses
spektrum
rádiós
adatátvitel
egy
speciális
esetét
jelentik a m¶holdakon elhelyezett rádiós adóvev® berendezések. A világ¶rben m¶holdakat
felhasználása a távközlésben
csak az ún. sugárzásmentes övezetekben lehet Az elektromágneses spektrum frekvenciatartománya igen nagy, lásd 8.34 ábra. Ebbe tartozik a látható fény is, amit optikai jelátvitelre használunk. A maradék tartomány nagy része is használatos a távközlésben, igen eltér® megvalósításokkal és tulajdonságokkal.
elhelyezni, lásd 8.36 ábra. A m¶holdak magassága meghatározza olyan tulajdonságaikat is, mint a keringési id®, a távolság befutása miatti késleltetés
és
a
teljes
lefedettséghez
szüksé-
ges m¶holdak száma. Manapság leginkább a földfelszíni fényvezet® szálak és a cella alapú rádiózás kombinációját használják. Hogy mikor melyiket, abban a felhasználás jellege,
A
rádióhullámok
terjedési
tula jdonságai
az
átviend®
adatok
mennyisége,
a
telepítés
er®sen függenek a frekvenciájuktól, lásd 8.35
gyorsasága, stb. szempontok játszanak dönt®
ábra.
szerepet. Ráadásul, az összetev®k és a szem-
A VF, LF és MF sávokban a rádóhullá-
mok messze terjednek, követik a föld görbületét, a HF és VHF sávban a hullámok egyenes vonalban terjednek, földközelben elnyel®dnek,
8.5. Vezeték nélküli adatátvitel
pontok akár menet közben is változhatnak.
Hálózati architektúrák és protokollok
83
9. Hálózatépítés és eszközök
összekötésére használatosak. Jellemz®i:
9.1. Local-Area Networking A és
hálózatok
az
Mint
azokat láttuk,
nem
csak
összeköt® a
•
a
állnak.
könnyebb
re
osztják.
érdekében Az
egyes
hálózati
szegmensek-
különálló
szegmensek-
nek/(al)hálózatoknak valahogyan kapcsolatba kell lépniük egymással.
Emiatt szükség van
a hálózati forgalom irányítására és az adatok sz¶résére is. A szegmenseket speciális hálózati elemek (
•
protokollok - hogyan kommunikálnak
•
médium - milyen közegen keresztül
ke-
zelhet®ség érdekében és a hálózati forgalom csökkentése
topológia - a számítógépek geometriai elrendezése
számítógépekb®l
kábelekb®l
hálózatokat
lomások, routerek és egyéb hálózati eszközök
connectivity device, ltering device )
Egy LAN tipikusan pár száz méterre terjed ki; több kisebb LAN is alkothat egy nagyobb LAN-t.
LAN
felhasználásával
hálózati
kom-
munikációra képes eszközöket hasznosabban, gazdaságosabban
használhatunk,
l.
pl.
9.2
ábra.
kapcsolják össze. Az egymás szoros közelségében
lev®
számítógépeknek
általában
több
közös dolguk van (pl. információ megosztás, eszközmegosztás), mint a zikailag távolabb fekv®knek, így az adatforgalom nagy részének nem kell a helyi szegmensen kívülre mennie. A hálózati forgalom csökkentése érdekében az
c 2004
Cisco Press/M. J. Castelli
összeköt® eszközök sz¶r® ( ltering) feladatot is ellátnak, l. 9.1 ábra. Az összeköt® eszközök feladatai:
•
Forgalomirányítás
•
Összekapcsolás ( zikailag különböz® esz-
9.2. ábra. Nyomtató kezelése helyi hálózattal és anélkül
közök vagy eltér® protokollok)
•
Hierarchikus címzés megvalósítása
•
Jel regenerálás (alsóbb szinteken)
c 2004
c 2004
by Sams Publishing/J. Casad
9.1. ábra. Eszköz a hálózati adatforgalom sz¶résére
Cisco
9.3. ábra. Csillag (star) elrendezés¶ topológia
A csillag elrendezés tipikusan otthoni vagy kis irodai elrendezésekben fordul el®, lásd 9.3
A helyi számítógéphálózatok (Local-Area Network, LAN) személyi számítógépek, munkaál-
9.1. Local-Area Networking
ábra.
A
középs®
elem,
általában
switch, irányítói feladatokat is ellát.
hub
vagy
Hálózati architektúrák és protokollok
84
gy¶r¶ topológia; sorjában mindenki jogot kap a használatra.
FDDI
(pronounced
" ddy")
kett®s
gy¶r¶,
hibat¶r®
Ethernet megosztott közeg¶ LAN (carrier sense multiple access collision detect (CSMA/CD) technológia)
9.2. Hálózati eszközök c 2004
Cisco
A
9.4. ábra. Gy¶r¶ (ring) elrendezés¶ topológia
hálózati
kommunikáció
során
különböz®
technikai eszközöket is használunk. Ezek feladatai és m¶ködési elvei nagyon eltérnek,
9.2.1. Fizikai (1.) réteg A gy¶r¶ elrendezés tipikusan Token Ring és Fiber Distributed Data Interface (FDDI)
Analóg
hálózatokban
tula jdon-
érvényes tapasztalat: a jeltovábbítás energia-
csomópontok
veszteséggel jár, id®nként a jel frissítésére van
sága
a
fordul
kétirányú
el®.
Kedvez®
kapcsolat
a
és
digitális
átvitel
során
egyaránt
között. Nem használ switch egységeket, lásd
szükség.
9.4 ábra.
és digitális jelátvitel esetén: Analóg jelátvitel esetén
Ennek
mechanizmusa
jel-er®sít®ket
kell
eltér
használni,
analóg
digitális
átvitel esetén ún. jel-ismétl®ket használnak, amelyek a nem-teljesen perfekt jelb®l újból tökéletes jelet készítenek. A jelátalakítók mindkét
irányú
adatformalomban
részt
vesznek,
lásd 9.6 ábra.
c 2004
Cisco Press/M. J. Castelli
9.6. ábra. A jelismétl® (repeater) m¶ködése
c 2004
Cisco Press/M. J. Castelli
9.5. ábra. Fa (tree) elrendezés¶ topológia
A
hub
többportú jelismétl®, ami az egyik
bemenetére érkez® jelet feler®sítve összes kiA fa elrendezés tula jdonképpen hierarchi-
menetén
elérhet®vé
teszi.
Ezáltal
lehet®vé
kus csillag topológia, lásd 9.5 ábra. Sok switch
válik az Ethernet er®források megosztása és
egységet
a hálózati szegmensek kiterjesztése nagyobb
használ,
bonyolult
hierarchiákban
használható.
távolságokra, lásd 9.7 ábra. topológiát
Token Ring
Max. 255 node, speciális token,
9.2. Hálózati eszközök
visz
felhasználók
a
A hub csillag-
hálózatokba
megosztják
a
és
mivel
sávszélességet
növekszik a torlódás veszélye is.
a is,
Hálózati architektúrák és protokollok
85
9.2.3. Hálózati (3.) réteg A
router
továbbít egy
olyan egy
másikba.
ben
eszköz,
LAN A
m¶ködnek.
amelyik
(vagy
WAN)
harmadik
csomagokat hálózatból
(hálózati)
Útvonalszervez®
réteg-
táblázatok
és protokollok segítségével a hálózati címek alapján továbbítják a csomagokat. A hálózati szegmensek peremén is használják, másik szegmenshez vagy az Internethez való kapcsolódásra, lásd 9.9 ábra.
c 2004
Cisco Press/M. J. Castelli 9.7. ábra. Megosztott Ethernet
9.2.2. Adatkapcsolati (2.) réteg A
bridge
c 2004
Cisco Press/M. J. Castelli
9.9. ábra. Két LANt az Internetre kapcsoló jóval intelligensebb eszköz, mint a
router
repeater és a hub. A bridge a második rétegben van, ismeri az MAC címeket a hálózati szegmensekben, így nem csak összekapcsolja, hanem el is választja a szegmenseket. A hídon csak a külvilágba tartó üzenetek haladnak át, a bels® forgalom nem. A 9.8 ábrán látható két szegmens egyazon céghez tartozó két osztály hálózatát
mutatja.
A
híd
megakadályozza,
hogy a bels® üzenetek mindkét szegmensben megjelenjenek dését.
Egy
és
hub
lassítsák
a
használata
hálózat esetén
m¶kö-
ez
nem
történne meg.
II. rész
Középhaladó könyv 10. Az OSI modell adatkapcsolati (2.) rétege II. 10.1. Az adatfolyam keretezése A zikai réteg továbbítja a bitfolyamot, de a bitsorozat tördelése az adatkapcsolati réteg feladata. Az egyes keretek kijelölésekor id®zítésre nem lehet hagyatkozni, mivel a késleltetések azt megváltoztathatják.
A keretek
határának kijelölésére használt módszerek:
c 2004
Cisco Press/M. J. Castelli
9.8. ábra. Két Ethernet szegmenst összekap-
•
Karakterszámlálás
•
Kezd® és végkarakterek beszúrása
•
Kezd® és végjelek bitek beszúrásával
•
Kódolássértés a zikai rétegben
csoló híd (bridge)
Hálózati architektúrák és protokollok
86
A karakterszámlálásos módszer esetén a fejzet-
elején és végén fordulhat el®. Hasonlóképpen
ben megadjuk a karakterek számát. Ha azon-
az el®z® módszerhez, az adó öt egymás utáni
ban hiba történik (a 10.1. ábrán a második ke-
egyes után minden esetben beszúr egy nulla
ret els® keretének egyetelen bitje megsérül), a
karaktert, a vev® pedig kisz¶ri, lásd 10.3 ábra.
karakterek értelmezése megváltozik. Az összes további keret használhatlan, a hiba ismétléssel sem javítható.
c 2003
by Prentice Hall/A. S. Tanenbaum
10.3. ábra. Az eredeti adat és bitbeszúrással
c 2003
megváltoztatott változata
by Prentice Hall/A. S. Tanenbaum
10.1. ábra. Hiba hatása a karakterszámlálásos módszerre
Egy
másik
10.2. Hibajavító kódok
keretezési
karakterekkel
jelzik
a
eljárásban keret
különleges
elejét
és
végét
(rendszerint ugyanaz a bájt), lásd 10.2 ábra. Ilyenkor csak meg kell keresni az üzenetben ezt a karaktert, annak helye megadja a keret végét. Az üzenetben el®forduló ilyen karaktereket
viszont
külön
jelölni
kell,
kivételes
karakterként. Ezért az adó az üzenetben megkeresi az ilyen karaktereket, bá jtbeszúrással különlegessé teszi, a vev® pedig a megfordított folyamattal visszaállítja az eredeti helyzetet.
Az adattovábbítás során kisebb-nagyobb gyakorisággal ezeket beli
el®fordulnak
el®idéz®
átviteli
jelenségek
kiterjedése)
olyan,
hibák.
természete
hogy
ezek
a
Az
(id®hibák
jellemz®en nem elszórtan (egyedileg), hanem csoportosan legalább
a
jelentkeznek. hibák
Törekednünk
jelzésére,
ilyenkor
a
kell vev®
észleli a hibát, és a hibás adatsor újraküldését kérheti. Ennek lehet®vé tételéhez az értékes adatokhoz valamennyi redundáns információt is
csatolhatunk.
arra
is
képes
információ
Bizonyos
lehet,
erre
esetekben
hogy
elegend®)
(ha
a
az
a
vev®
redundáns
átviteli
hiba
ellenére helyreállítsa az eredeti adatsort. Az
hibajelz® kód ok (error detecting utóbbit ún. hibajavító kód ok (error
el®bbi célt ún. code),
correcting Mindkét
code)
használatával
módszer
használatos,
választhatunk milyen
közöttük,
egyszer¶en
és
hogy
olcsón
érhetjük aszerint az
el. (is)
újraküldés
oldható
meg,
illetve mennyi az esélye a hibás ismétlésnek.
c 2003
by Prentice Hall/A. S. Tanenbaum
A hogy
10.2. ábra. Jelz®bájtokkal határolt keret
redundancia az
m
adatbitb®l
üzenekhez még
r
Egy másik keretezési eljárásban azt használják ki, hogy a speciális '01111110' bá jt csak a keret
10.2. Hibajavító kódok
azt
(message
jelenti,
bits)
álló
redundáns bitet adunk. Így
a keret teljes hossza egységet
alkalmazása
n=m+r
kódszó nak nevezik.
lesz. Ezt az
Hálózati architektúrák és protokollok
87
koribbá vált, hogy egyik hálózatból egy másikba kerültek, ahol más hálózati címre volt szükségük.
Ezzel
egyidej¶leg
mind
nagyobb
problémát jelentett az IP címtér kimerülése: mindinkább luxussá vált, hogy a hálózathoz csak
id®legesen
kapcsolódó
számítógépekhez
állandó IP számot rendeljünk. A megoldást a DHCP protokol jelentette, amelynek ötlete az ARRP protokollból származik (és amelyet a BOOTP közbüls® protokollon át fejlesztettek ki. A DHCP leg gyelemreméltóbb tula jdon-
a kliensekhez dinamikusan tud címeket rendelni és azokat központilag kezeli. A sága, hogy
c 2003
DHCP manapság a legelterjedtebben használt
by Prentice Hall/A. S. Tanenbaum
10.4.
ábra.
A
TCP/IP kon gurációs protokoll, amit a leg-
Hamming-kód
alkalmazása
egyszer¶bb
házi
kliens-szerver
rendszerekt®l
az egész szervezetekkre kiterjed® hálózatokig
csoportos hibák kijavítására
mindenütt használnak. Két ilyen kódszó összehasonlításakor azt akarjuk megtudni, hogy azok azonos helyen lev® két
bitjei
között
kódszó
m¶velet
között
elvégzése
megszámlálásával két
kódszó
hány egy után,
eltér® kizáró az
kap juk.
van. vagy
'1' Ezt
a
d
a
(XOR)
érték¶
bitek
számot
Hamming-távolság ának
Két, egymástól
Ezt
a
nevezik.
Hamming-távolságban lev®
kódszót esetén egyiket a másikból olyan hiba esetén kap juk, amelyik pontosan
d
bitet
érint. Az adatátvitel során általában mind a
2m
adatüzenet
legális,
de
az
ellen®rz®
kód
megfelel® megválasztása esetén nem fordul el® mind a A
2n
két
lehetséges kódszó. kódszó
Egy
d+1
távolságú
egy
cím
lefoglaló
mechanizmusból,
(address
valamint
egy
allocation)
olyan
proto-
kollból, amelyik lehet®vé teszi, hogy a kliensek kon gurációs információt kérjenek, a szerverek pedig ilyet szolgáltatni tudjanak. A
DHCP
(Dynamic Host Con guration
Protocol RFC 2131 (l.
http://www.rfc-editor.
org/rfc/rfc2131.txt)) használatával több gép oszt meg egy IP címtér részt (pool). A DHCP háromféle cím lefoglaló mechanizmust ismer:
Statikus
Egy
bizonyos
IP
címet
az
admi-
nisztrátor egy bizonyos eszközhöz rendel. A DHCP közli az eszközzel annak IP
Haming-távolságától
függ,
hogy hibajelz® vagy hibajavító kódot tudunk készíteni.
A DHCP lényegében két f® alkotórészb®l áll:
kódszó
pár
címét.
Dinamikus cím¶
esetén
(permanent
automatic,
automatikus)
a
DHCP
állandó állandó
jelleggel IP címet rendel az eszközhöz,
11. Az OSI modell hálózati (3.) rétege II. 11.1. Dynamic Host Con guration Protocol (DHCP)
amely címet egy rendelkezésre álló címkészletb®l (pool) választ ki
Automatikus ges
(temporary automatic, id®le-
használatú
meghatározott rendel
az
id®
múlásával
a
számítógépek
egyre
ki-
sebbek és könnyebbek lettek, így mind gya-
11.1. DHCP
választ ki
id®tartamra
eszközhöz,
rendelkezésre Az
automatikus)
álló
amely
a IP
DHCP címet
címet
címkészletb®l
egy
(pool)
Hálózati architektúrák és protokollok
88
Automatizálás Minden kliens automatikusan kaphat IP címet, nem kell az adminisztrátornak manuálisan intézkedni, hogy melyik kliens milyen címet kapjon.
üzenetét.
valamennyi
IP
címet
a
DHCP szerver kezeli. Az adminisztrátor könnyen megnézheti, melyik eszköznek milyen címe van, könnyen karbantartható.
kliens
DHCPOFFER
begy¶jti
üzeneteket:
és
kiértékeli
eldönti,
a
melyiket
fogadja el. A kiválasztott szervernek elküld egy
DHCPREQUEST a
Központi kezelés
A
választ.
üzenetet,
Valamennyi
ma jd
szerver
megvárja
megkapja
a
kliens címkér® üzenetét. A kiválasztott szerver visszaküld egy üzenetet
DHCPACK
(nyugtát)
(esetleg
(acknowledge)
egy
DHCPNAK
(negative acknowledge) üzenetet, ha a felajánlott cím már nem elérhet®). A kliens fogadja
Cím újrafelhasználás és megosztás DHCP
szerver
tudja,
hogy
a
egyszer¶en
és
A
biztosítani
rendelkezésre
álló
IP
címtartomány elemei tcsak a hálózatot
aktívan
használó eszközök kap ják megk.
Bizonyos id® után a nem használt címek újból
talonba
kerülnek,
ezáltal
más
nyugtát,
és
(esetleg
egy
utolsó ellen®rzés után) véglegesíti a "bérleti szerz®dést". DHCP életciklusa a következ® fázisokból áll:
Címfoglalás A kliens a már ismert címfoglalás (allocation) mechanizmussal címet Újrafoglalás
Hordozhatóság és univerzalitás cimfoglalást
a
foglal magának.
eszközök tudják azokat használni.
Dinamikus
feldolgozza
használva,
bérelt
Ha
a
címe,
kliensnek
és
már
újraindul
bekapcsolták,
használati mód mobil eszközök számára.
DHCP szerverrel, amely a címet adta és
egy
IP
címtárból,
lép
a
meger®síti bérlési szándékát és bekéri a Nem
le-
hetséges IP címzési kon iktus, mivel az eszközök
kapcsolatba
egy
újból
bármelyik kliens kérhet IP címet. Ideális
Címzési kon iktusok elkerülése
újból
van
vagy
a
DHCP
szerver közvetítésével kapnak IP címet.
m¶ködéshez szükséges paramétereket.
Normál m¶ködés
Ha már a bérlet létrejött,
a kliens egyszer¶en használja IP címét és egyéb paramétereit
Hagyományosan, a gazdagép címét;
birtokolja bérli
dinamikus címfoglalás esetén csak
az IP
Megújítás
Bizonyos id® eltelte után a kliens
újból kapcsolatba próbál lépni a címet felajánlott szerverrel
azt.
Átkapcsolódás
Ha az eredeti szerverrel nem
sikerül a bérleti id®t meghosszabbítani, a Alapvet®en a cím "bérlési" folyamat úgy zajlik le, amint azt a 11.1 ábra mutatja. A kliensnek nincs IP címe, és még azt sem tudja, hogy Hogy
van-e
DHCP
találjon
kibocsát egy
egy
kiszolgáló
a
kiszolgálót,
DHCPDISCOVER
hálózatban. létrehoz
és
kliens megpróbál egy másik aktív DHCP szerverhez kapcsolódni
Felmondás
A kliens bármikor felmondhatja
a bérleti szez®dést
üzenetet. A
hálózat valamennyi kiszolgálója megkapja a kliens üzenetét és megvizsgálja azt. A vizsgá-
A 11.2 ábrán bemutatott példában a kez-
lat eredményeként vagy felkínál egy bérelhet®
deti bérleti id® nyolc nap, és a bérlet a 0.
címet, vagy nem. Ha küld ajánlatot, abban
napon kezd®dik. A T1 és T2 id®zítéseket 4
szerepel az IP szám, a bérlési id® és további
illetve 7 napra állítjuk be Amikor T1 lejár, a
paraméterek (a szerver ajánlatküldés el®tt ki-
klient kezdeményezi a megújítást, és az ötödik
próbálhatja és lefoglalhatja a kérdéses címet).
napon sikeresen megújítja 8 napra a bérlést.
Minden
Amikor eme második bérlés T1 id®zít® je is
szerver
11.1. DHCP
elküldi
saját
DHCPOFFER
Hálózati architektúrák és protokollok
c 2005
89
by http://www.tcpipguide.com/C. M. Kozierok 11.1. ábra. A DHCP címfoglalási folyamat
lejár, a kliens nem tudja megújítani a bérlést
útvonalválasztók
az
sage
eredeti
szerverrel.
Amikor
a
T2
id®zítés
Protocol,
arra,
problémáról. Emellett, az ICMP protokollnak
nappal nincs szüksége többé a bérlésre, ezért
más diagnosztikai és hibakeresési funkciói is
felmondja azt.
vannak.
ezután
Egy távoli számítógépnek szóló üzenet gyakran több útvonalválasztón (router) is áthalad. Eközben számtalan probléma léphet fel. Az
11.1. DHCP
IP
címet
Mes-
használják
három
Viszont
küld®
Control
protokollt
8
periódusra.
a
(Internet
is lejár, keres egy másik szervert egy újabb napos
hogy
az
ICMP)
értesítsék
a
Néhány tipikus üzenete:
Echo
leginkább teszteléskor használt ICMP üzenetek. Amikor a
ping
utasítással az
Hálózati architektúrák és protokollok
c 2005
90
by http://www.tcpipguide.com/C. M. Kozierok 11.2. ábra. DHCP életciklus példa
összekötést
teszteljük,
tokoll
IP
egy
címre
az
ICMP
küld
egy
prodata-
grammot és a célállomástól az adatok visszaküldését az
kéri.
Echo Request
11.1. DHCP
és
Ilyenkor
való jában
Echo Reply
üzene-
teket használjuk.
Source Quench nagy
Ha
egy
gyors
adatmennyiséget
számítógépnek,
az
küld
számítógép egy
távoli
adatmennyiség
túl-
terhelheti az útvonalválasztót. Az útvo-
Hálózati architektúrák és protokollok
91
nalválasztó egy Source Quench ICMP
A 11.3. ábrán a kezdeti sorrendhez képest
utasítással kérheti a küld®t, hogy csök-
megváltozik az A router táblázatában az E
kentse
és
F
A
változás
a
küldési
sebességet.
Szükség
esetén az utasítás ismételhet®.
Destination Unreachable tó
olyan
datagramot
routerbe
irányuló
után
forgalom
elküldött
szervezése.
csomagok
más
útvonalon haladnak. Ha az útválaszkap,
amit
nem
tud továbbítani (például meghibásodás vagy karbantartás miatt), az ICMP se-
11.3. Dinamikus forgalomszervez® algoritmusok
gítségével egy Destination Unreachable üzenetet küld vissza a küld® állomásnak.
Time Exceeded
Az ICMP ezt az üzenetet
küldi vissza a küld®nek, ha egy datagram azért törl®dik, mert a TTL nulla értéket ért el. Ez vagy azt jelenti, hogy a célállomás nem érhet® el a kezdetben adott TTL értékkel, vagy pedig egy útvonalválasztási problémát (routing loop) takar.
by Prentice Hall/A. S. Tanenbaum
11.4. ábra. Igazságosság és optimalitás konf-
Fragmentation Needed üzenetet
c 2003
küldi
Az
vissza
a
ICMP
ezt
az
küld®nek,
ha
liktusa
Az A és A', B és B', C és C' közötti for-
olyan üzenetet kap, amelyikben a Don't Fragment bit egyes érték¶, a továbbításhoz viszont a datagramot fragmentálni kell.
galom teljesen kitölti a vizszintes összekötést, lásd 11.4. ábra. A hatékonyság érdekében ki kellene zárni a X és X' közötti forgalmat, az igazságosság jegyében nem szabad azt tenni.
11.2. Az útválasztás további részletei
Az
optimalitási elv
(optimality principle) sze-
rint, ha a J router az I routert®l a K router felé vezet® optimális útvonalon helyezkedik el, akkor a J routert®l a K routerig vezet® útvonal is
ugyanerre
összes
esik.
forrásból
Ennek
egy
következtében
célba
tartó
az
optimális
útvonalak egy fát alkotnak, amelynek gyökere a cél.
c 2003
c 2003
by Prentice Hall/A. S. Tanenbaum
by Prentice Hall/A. S. Tanenbaum
11.5. ábra. Egy alhálózat és egy nyel®fa a B routerhez
11.3. ábra. Forgalomszervezés változása egy alhálózatban
11.3. Dinamikus forgalomszervez® algoritmusok
Hálózati architektúrák és protokollok
92
Az ilyen fát nyel®fának (sink tree) nevezik.
A
távolságvektor
alapú
(Bellman-Ford)
A 11.5 ábra bal oldalán mutatott alhálózat
forgalomirányítás (Distance Vector Routing)
nyel®fája az ábra jobb oldalán látható.
egyszer¶, hatékony és sok protokollban használatos módszer. Valamikor domináns szerepe
Triviális forgalomirányítási módszer: minden-
volt,
kinek mindenr®l küldünk másolatot. Ez nyil-
átveszik szerepét ki nomultabb módszerek.
ván az üzenetek exponenciális sokszorozódásához vezet. De:
•
ma
is
használatos,
de
egyre
inkább
A módszert úgy tervezték, hogy az minimalizálja a routerek közötti kommunikációt és
Nem küldjük vissza az eredeti küld®nek
azt az adatmennyiséget, amelynek a routing táblázatokba kell kerülni. A módszer alapöt-
•
Nyilvántartjuk
a
továbbított
csomago-
lete,
hogy
egy
routernek
nem
kell
ismernie
minden egyes szegmenshez az oda vezet® út-
kat
vonalat csak annyit kell tudnia, hogy melyik
•
Figyeljük az üzenetek sorszámát
•
Válogatjuk a partnereket irány szerint
irányba kell elküldenie a szegmensbe címzett datagrammot
(innét
jön
a
'vektor'
elneve-
zés). A hálózati szegmensek közötti távolságot A módszer hasznos lehet pl. er®sen zajos, nagy
azon routerek száma adja meg, amelyeken a
hibas¶r¶ség¶ rendszerekben.
datagrammoknak
át
kell
haladni,
miközben
szegmensr®l szegmensre vándorolnak. A távolÉpítsünk
fel
egy
olyan
gráfot,
amelyben
a
ságvektor
alapú
forgalomirányítást
használó
routerek alkotják a csomópontokat és a kom-
routerek úgy próbálnak útvonalat optimalizál-
munikációs
távolság
ni, hogy minimalizálják azon routerek számát,
lehet zikai hosszúság, átviteli id®, stb. A szá-
amelyeken a datagrammnak át kell haladnia.
mításra leginkább használatos elv Dijkstrától
Ez
származik.
count).
A
vonalak
számítás
els®
az
öt
éleket.
A
lépését
a
11.6
a
távolságparaméter
az
ugrásszám
(hop
életre
érzé-
ábra
mutatja. Ha az A-tól D-ig vezet® legrövidebb útvonalat
akarjuk
megtalálni,
kezdetben
az
útvonalra vonatkozóan semmit sem ismerünk (minden pontot
végtelen
rögzítjük
távolságban
(ezt
jelzi
a
van).
tele
Az
kör)
és
•
Amikor
az
A
router
kel,
keli a vele közvetlen kapcsolatban álló
A
szegmenseket
a
és
azokat
elhelyezi
vele szomszédos pontokat újra számoljuk, a
forgalomirányító
pontokhoz az A-tól való távolságot rendelve.
szetesen ezekhez a szegmensekhez 0 ug-
Az
szomszédait
rásszámmal el lehet jutni, mert nem kell
munka-csomópontként használva megismétel-
további routeren áthaladni a szegmensig.
A
pont
így
újra-címkézett
jük az eljárást, az új (eddig még nem vizsgált) szomszédokkal. Ha eddig még nem használt
•
szegmenseket,
sik munka-csomóponttal jobb értéket találunk,
tudomása
a címkét arra az értékre cseréljük és megje-
táblázattól függ. Számos routing protokol van használatban, ezek alapvet®en két forgalomszervezési módszerhez kapcsolódnak:
11.3. Dinamikus forgalomszervez® algoritmusok
router
amelyekr®l
van,
és
a
a
routernek
hozzá juk
tartozó
ugrásszámot.
gyezzük a munka-csomópont nevét is.
grammokat. A routerek viselkedés a routing
a
a jelentés tartalmazza azokat a hálózati
címkével ellátott csomópont esetében egy má-
cserélnek arról, hogyan is továbbítsák a data-
id®közönként
Termé-
jelentést kap közvetlen szomszédaitól. Ez
csomópontra bukkanunk, vagy egy ideiglenes
Az egy csoportba tartozó routerek információt
Meghatározott
táblázatában.
sa ját
•
A
jelentések
alapján
az
A
router
in-
tegrálja a forgalomirányító információt saját forgalomirányító táblázatába:
Ha
a
B
router
szegmensr®l
is
olyan
tud,
hálózati
amelyik
nem
Hálózati architektúrák és protokollok
B 2 A
1 6 G
E 2
3
4
B(2,A)
3
F 2
E(∞,-) F(∞,-)
A
D
H
G(6,A)
H(∞,-)
C(9,B)
B(2,A)
C(9,B) E(4,B)
F(∞,-)
D(∞,-)
H(∞,-)
G(5,E)
H(∞,-)
B(2,A)
C(9,B)
B(2,A)
C(9,B)
E(4,B)
E(4,B) D(∞,-)
F(6,E)
G(5,E)
D(∞,-)
F(6,E)
A
G(6,A)
A
D(∞,-)
2
E(4,B) A
C(∞,-)
B(2,A)
C
7 2
93
H(9,G)
D(∞,-)
F(6,E)
A
G(5,E)
H(8,F)
11.6. ábra. Az els® öt lépés az A-tól D-ig vezet® legrövidebb út kiszámításában
az
útvonal
a
B
router,
ami
azt
jelenti, hogy az új szegmensbe címzett
datagrammokat
az
A
router
továbbítja a B-nek. Az ugrásszám a
B
táblázatában
talált
értéknél
eggyel nagyobb, mivel az A router egy szegmenssel távolabb van.
Ha a B router listája olyan szegmenst tartalmaz, amelyik már megtalálható az A router táblázatában, az
A
tában
router talált
a
B
router
értékénél
tábláza-
eggyel
na-
gyobb számot hasonlít össze a sa ját táblázatában talált értékkel. Ha a B router táblázatában talált érték jobb, mint az A által ismert érték, az
A
router
frissíti
a
táblázatát,
hogy a B router irányába kell továbbítani
c 2004
az
ebbe
a
szegmensbe
címzett datagammokat.
by Sams Publishing/J. Casad
11.7. ábra. Távolságvektor alapú forgalomirányító táblázat m¶ködése
Ha
a
B
routeren
át
vezet®
út
hosszabb, mint amit az A router táblázatában meg lehet találni, a B routeren át vezet® utat nem fogjuk
szerepel az A router forgalomirá-
használni. Az A router tovább hasz-
nyító
nálja a táblázatában már szerepl®
az
új
táblázataiban, szegmenst
táblázatához.
Az
az
A
hozzáadja új
router sa ját
szegmenshez
11.3. Dinamikus forgalomszervez® algoritmusok
értéket.
Hálózati architektúrák és protokollok
94
A 11.7 ábra szerinti táblázatokban bemutatott
adatok
szerint
a
B
információ gyorsan, a kedvez®tlen lasan terjed.
router
hatékonyabban tudja elérni a 14-es hálózatot, így A frissíti táblázatát. Az A routernek jobb elérési módja van a 7. hálózat elérésére, így a táblázatot nem kell
frissíteni.
(viszont
B
valószín¶leg
frissíteni fog az A-tól kapott információk alapján.)
c 2003
Minden router ismeri minden célhoz az oda vezet® út azonosítóját és a távolságot a célig.
by Prentice Hall/A. S. Tanenbaum
11.9. ábra. A végtelenig számolás problémája
A 11.9 ábra bal oldalán kezdetben A nem m¶ködik,
a
van
Amikor
t®le.
többi
router
végteln
megjavul,
a
távolságra
vektorcserék
alkalmával a jó hír gyorsan eléri a többi routert is. A jobb oldalon kezdetben minden m¶ködik, majd A elromlik. Ekkor A nem kommunikál, a B-t®l való távolságát újra kell számolni. B elhiszi C közlését, hogy neki van egy 2 egység hosszú útvonala, és nem veszi észre, hogy ez az útvonal B és A között is vezet, ami nem m¶ködik, csak C még err®l nem értesült. Aztán
c 2003
szépen, lassan, egyesével feltornásszák sa ját
by Prentice Hall/A. S. Tanenbaum
távolságértékeiket a végtelenig (,ha hagyjuk). 11.8. ábra. Távolságvektor alapú forgalomirányítás egy alhálózatban
A
problémát
az
okozza,
hogy
a
router
a
szomszédtól kapott információból nem tudja megállapítani, hogy a felajánlott útvonal nem
(A
router
a
céltól
való
távolságot
akár
saját magán át vezet-e.
mérheti is, pl. speciális ECHO csomagokkal.) A routerek id®nként kicserélik távolságinformációikat egymással és annak alapján frissítik saját táblázataikat. A 11.8 ábra mutatja a frissítés folyamatát. Az ábra fels® része a hálózat topológiá ját mutatja, az alsó részén baloldalt
11.4. Különleges routing alkalmazások 11.4.1. Címfordítás (NAT)
a J router szomszédaitól kapott adatok, jobb oldal a J által az adatok alap ján összeállított saját táblázatot mutatja. Ebbe a J azokat az értékeket írja, amelyeket legjobbként értékel a
kapott
adatok
alap ján,
a
routerirányt
is
megjegyezve.. Például, G felé az I, H és K routeren keresztül is el lehet jutni, (31+10), (6+12) és (31+6) távolságot megtéve, ezért Hn át célszer¶ haladni.
A
távolságvektor
alapú
A routerek egy speciális alkalmazása, hogy képesek elfedni egy alhálózat összes részletét, s®t
akár
(Network 11.10
(rossz esetben) lassan konvergál. A kedvez®
11.4. Különleges routing alkalmazások
létezését
Address
ábra.
A
is:
ez
a
Translation,
NAT
eszköz
a
címfordítás NAT),
helyi
lásd
hálózat
átjárójaként szolgál az Internethez. A NAT eszköz mögötti alhálózatban bármiféle helyi címteret
forgalomirányítás
a
lehet
használni.
Ilyenkor
a
NAT
eszköz közvetít®ként (proxy) m¶ködik. Amikor egy helyi számítógép megpróbál kapcsolódni
Hálózati architektúrák és protokollok
95
Könnyebb terjeszkedés
Mivel a helyi há-
lózati eszközöknek magán címe van, és nincs
is
szükségük
publikus
IP
címre,
a helyi hálózathoz könnyen hozzáadhatunk új klienseket
Nagyobb helyi kontrol nisztrálásakor
a
A
hálózat
admi-
magánhálózat
összes
el®nyét élvezhetjük, mégis kapcsolódunk az Internethez.
Nagyobb exibilitás szolgálatót
Egyszer¶bben
(ISP)
cserélni,
mivel
lehet nem
kell újraszámozni a hálózat valamennyi gépét.
Nagyobb biztonság
A NAT egy indirekciós
szintet jelent, azaz egyfajta túzfalként
c 2004
m¶ködik a hálózat és a publikus Inter-
by Sams Publishing/J. Casad
net között. A kliens gépek nehezebben
11.10. ábra. Egy hálózati címfordító (NAT)
támadhatóak,
mivel
nincs
publikusan
ismert IP címük.
eszköz
(Csaknem) transzparens egy Internet er®forráshoz, a NAT eszköz hozza létre a kapcsolatot. Az Internet er®forrástól kapott csomagokat a helyi hálózat címterébe
A
változtatáso-
kat csak egy (vagy legfeljebb néhány) routeren kell elvégezni, a kliens gépek százait nem kell változtatni.
fordítja és továbbítja a kapcsolatot kezdeményez® számítógépnek.
A NAT eszköz jelent®-
sen javítja a biztonságot, mivel egy esetleges küls® támadó meg a helyi hálózat lézetésér®l sem tud: a külvilág számára a NAT eszköz egyetlen
számítógépnek
tudna
a
is
támadó
az
t¶nik.
De,
alhálózat
még
ha
létezésér®l,
akkor sem tudna kapcsolatot létesíteni a helyi
Bonyolultság
A hálózat kezelésében egy fo-
kozattal nagyobb bonyolultságot jelent, ami a címhelyettesítés miatt nehezebb hibakeresést is jelent.
Publikus cím hiánya
Bizonyos
számítógépekkel, mivel azon címzési rendszere
nem
nem illeszkedik az Internet címteréhez. Emel-
valódi IP címek esetén.
lett,
a
NAT
csökkenti
a
szervezet
számára
szükséges Internet-kompatibilis címek számát
megfelel®en
függvények
m¶ködnek
Kompatibilitási problémák
nem-
Mivel a NAT
is, mivel csak egyetlen eszköznek kell elérnie
megváltoztatja az IP fejzet mez®it (de az
az Internetet. Eme tulajdonságai miatt a NAT
alkalmazás adatait nem), az olyan alkal-
eszközök nagyon népszer¶ek, otthoni és céges
mazások (pl. FTP) utasításait, amelyek
hálózatokban egyaránt.
IP
címeket
és
portokat
tartalmaznak,
külön kell kezelni. Bizonyos alkalmazá-
IP cím megosztás
sok akár nem is m¶ködnek. Nagyszámú
gazdagép
használhat kis számú publikus IP címet.
Biztonsági problémák
A fejzet megváltoz-
Kevesebbe is kerül és kevésbé terheli az
tását akár támadásként is értékelhetik a
IP címteret.
biztonsági protokollok.
11.4. Különleges routing alkalmazások
Hálózati architektúrák és protokollok
Csökkent kliens támogatás
kívül-
Például, a 10.0.0.207 cím¶ eszköz HTTP
r®l kapcsolatot teremteni a kliensekkel.
kérsét akar küldeni a 204.51.16.12 cím¶ In-
Pl.a
ternet szervernek. Létrehoz egy datagrammot
cég
honlapját
Nehéz
96
NAT
nélkül
kell
megvalósítani.
a
Csökkent teljesítmény
10.0.0.207
forrás
címmel.
Ha
azoban
ezt
küldené ki az Internetre, a szerver nem tudna A magánhálózat és
az Internet között minden datagram esetén címfordítás (és további m¶veletek, pl. ellen®rz®összeg számítás) szükséges.
válaszolni, mivel a 10.0.0.207 nem használható publikusan. Emiatt a NAT router a 10.0.0.207 címet a cég valamelyik regisztrált IP címére, mondjuk
a
194.54.21.10
címre
fordítja.
Ez
bels® globális cím lesz, ami a 10.0.0.207 bels® lokális címnek felel meg. A szerver ezt
egy
használja cél címként, amikor HTTP választ küld.
11.5. IPv6: Internet Version 6
Protocol
11.5.1. Az IPv6 áttekintése Az 1990-ben elkezdett munka f® céljai (RFC 1550 (l.
http://www.rfc-editor.org/rfc/rfc1550.
txt)):
•
Több
milliárd
gazdagép
támogatása,
akár igen rossz címtér kihasználás árán is
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
•
11.11. ábra. Az IP NAT terminológiá ja
A NAT cím az eszköz helye alap ján lehet:
tése
•
A protokoll egyszer¶sítése, gyorsabb feldolgozás
Bels®
A cég bels® hálózatán található eszkö-
zök. Az ezekre való hivatkozásokat bels®
•
Küls®
A helyi hálózaton kívül minden eszköz.
•
Szolgálat típus támogatása (különösen valós idej¶ adatok esetén)
NAT
cím
a
datagramm
helye
szerint
lehet:
Lokális
Biztonság növelése (hitelesítés és titkosság)
címnek tekintjük.
A
Routing táblázatok méretének csökken-
olyan
cím,
amelyik
a
bels®
háló-
•
Többesküldés hatósugár bevezetése
•
Roaming
kozik
Globális
akár bels®, akár küls® címre hivat-
olyan
cím,
amelyik
a
küls®
háló-
kezelése
(címváltozás
nélkül)
zatban található datagrammban jelenik meg,
hoszt
•
Protokoll fejl®dési lehet®ség nyitása
•
IPv4 és IPv6 együttélés biztosítása még éveken át
zatban található datagrammban jelenik meg,
kozik
akár bels®, akár küls® címre hivat-
11.5. IPv6: Internet Protocol Version 6
Ami változatlanul maradt az IPv6-ban (RFC 3513 (l.
http://www.rfc-editor.org/rfc/rfc3513.
Hálózati architektúrák és protokollok
97
txt), RFC 2460 (l. http://www.rfc-editor.org/
IPv4 címtér mérete kb 4 cm, akkor az IPv6
rfc/rfc2460.txt)):
akkora, mint a Naprendszer. A Föld minden
Címzési feladatok ra
is
a
négyzetméterére
7x1023
IP szám jut.
A két f® funkció tovább-
hálózati
IF
azonosítása
és
az
útvonalszervezés
Hálózati rétegbeli cím
Az IPv6 is hálózati
rétegbeli cím, független az adatkapcsolati rétegbeli ( zikai) címt®l
IP cím per eszköz vannak
A címek hálózati IF-hez
rendelve,
változatlan
funkció-
ban: a gazdagépeknek általában egy, a routereknek zikai hálózatonként egy
Cím értelmezés
c 2005
Leginkább az osztály nél-
küli IPv4 címzéshez hasonlít: van hálózat és gazdagép azonosító rész is, de az nincs belekódolva az értékbe
Privát és publikus címek
by http://www.tcpipguide.com/C. M. Kozierok
11.13. ábra. Az IPv6 címek bináris, decimális és hexadecimális ábrázolása
Az 11.13 ábrán az IPv6 címek szokásos áb-
Lézetik
IPv6
alatt is, de kicsit másképpen értelmezzük
rázolásmódjai láthatók. A kevert ábrázolásban az utolsó 32 bitet központozott decimális jelölésben írják. Ezt leggyakrabban a beágyazott
és használjuk
IPv4 címek ábrázolására használják. További
részletek
RFC
1883
(l.
http://
www.rfc-editor.org/rfc/rfc1883.txt)-RFC (l.
1887
http://www.rfc-editor.org/rfc/rfc1887.txt).
Olyan eszközökben, amelyek mindkét címzési rendszert
támogatják,
ún.
beágyazott
IPv4
ábrázolást használnak.
11.5.2. Az IPv6 címtér Az
IPv6
címek
mérete
komoly
vita
után
alakult ki. Az IPv6 címek 128 bitb®l állnak, a címtér mérete kifejezhetetlenül óriási.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
11.14. ábra. Az IPv6 címrendszerbe ágyazott IPv4 cím ábrázolásmódja
Az
11.14
ábrán
az
IPv6
címrendszerbe
ágyazott IPv4 cím ábrázolásmódját látjuk: 96 db nulla kerül a 32 bites IPv4 cím elé.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
Olyan eszközökben, amelyek nem IPv6 kom-
11.12. ábra. Az IPv6 és IPv4 címtér viszonya
patibilisek, az IPv4 címeket
leképezik
az IPv6
címtérbe. Az
IPv6
csillagászati
címtér méret¶.
mérete Ha
az
már
szó
11.12
szerint
ábrán
11.5. IPv6: Internet Protocol Version 6
az
Az
11.15
ábrán
az
IPv6
címrendszerbe
leképezett IPv4 cím ábrázolásmódját látjuk:
Hálózati architektúrák és protokollok
98
A címek hossza jelent®sen megn®tt, viszont sok kötelez® elem kikerült a fejzetb®l.
Többszörös fejzet
Egy
f®
fejzet,
és
kiter-
jesztések, ha szükségesek(lásd 11.16 ábra).
Áramvonalas fejzet c 2005
a
feltétlenül
szükséges mez®k maradtak meg.
by http://www.tcpipguide.com/C. M. Kozierok
11.15. ábra. Az IPv6 címrendszerbe leképe-
Átnevezett mez®k
A
mez®k
neve
tükrözi
funciójukat.
zett IPv4 cím ábrázolásmódja
80 db nulla és 16 db egyes kerül a 32 bites
Nagyobb exibilitás
Nagy mennyiségú ext-
ra információ csatolható, opciók is lehet-
IPv4 cím elé.
•
Csak
ségesek.
Általában, az els® (legmagasabb helyér-
Nincs ellen®rz® összeg
ték¶) bájtban csupa nullát tartalmazó címek fenntartott (alapesetben címzésre
Kisebb
és
f®ként
gyorsabb.
QoS támogatás
nem használt) címek. Ilyenek az eredeti-
Új mez® támogatja a for-
galmazási prioritásokat.
leg IPv4 rendszerben szerepl® címek is.
•
•
Hasonlóképpen,
vá-
Az IPv6 fejzet általános formátuma tehát jóval
lasztja ki a privát címeket: az els® bá jt
az
els®
kilenc
bit
egyszer¶bb, kevesebb mez®t tartalmaz, lásd
értéke FE, a kilencedik bit egyes.
11.17 ábra.
A loopback cím az utolsó bit kivételével csupa
nulla.
Kódolása:
0:0:0:0:0:0:0:1,
amit a felesleges nullák elhagyásával így írnak : ::1.
11.5.3. Az IPv6 datagrammok A datagrammok használata nem változott az IPv4-hez képest, a szerkezete és formátuma viszont igen.
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
11.17. ábra. Az IPv6 fejzet formátuma
Az egyik legfontosabb mez®, a
Next Field ,
teszi lehet®vé szükség esetén többféle header hozzáadását a fejzethez, lásd 11.18 ábra. Az
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
11.16. ábra. Az IPv6 fejzet általános szerkezete
11.5. IPv6: Internet Protocol Version 6
egyes kiterjesztések szerkezete er®sen eltér®.
Hálózati architektúrák és protokollok
99
(tulajdonképpen az alkalmazási rétegben) fut (RFC 1889 (l.
c 2004,
c 2005
http://www.rfc-editor.org/)).
A. S. Tanenbaum: Computer Networks
by http://www.tcpipguide.com/C. M. Kozierok 12.2. ábra. Az RTP protokoll helye (a) és
11.18. ábra. Az IPv6 fejzet kiterjesztésének
csomagjainak felépítése (b)
használata
12. Az OSI modell szállítási (4.) rétege II. 12.1. Az UDP protokoll felhasználása
A multimédiás alkalmazások több (hang, mozgókép, szöveg) valós-idej¶ adatfolyamból állnak. Az RTP ezeket egyetlen, növekv® sorszámmal ellátott folyamban küldi a hálózatra. Hiányzó blokk esetén nem küld újra, hanem interpolál. Egy másik lehet®ség az id®bélyeg használata, és pár ezredmásodperces puerelés.
Távoli egyik
eljáráshívásnak gazdagép
egy
is
tekinthet®,
távoli
amikor
gazdagépt®l
egy
üzenettel valamilyen feladat végreha jtását kéri és arra választ kap. A hívás paramétereit a kliens átrendezi, átküldi a hálózaton, a szerver saját szempontjai szerint átrendezi a paramétereket, végrehajtja a rendszerhívást, ma jd a fordított útvonalon visszaküldi az adatokat. Az eljárásnak vannak korlátai (pl. mutatók és típusok, komplex adatszerkezetek használata), de nagyon sok helyen alkalmazható. Legtöbbször UDP átviteli protokolt használ.
12.1.1. A TCP torlódáskezelés A TCP fejzet lehet®séget biztosít a kapcsolat adatáramlásának vezérlésére. Az Ablak mez®
lehet®séget
nyújt
arra,
hogy
a
küls®
számítógép ne küldjön túl sok adatot rövid id®
alatt
(ez
azt
is
eredményezhetné,
hogy
sok adat elveszne, mivel a fogadó gép nem tudja olyan gyorsan feldolgozni az adatokat, ahogyan azt a küld® gép küldeni tudja). Az adatáramlás
vezérlési
szóablakos vezérlés
módszere
(l.
az
csú-
ún.
http://www2.rad.com/
networks/2004/sliding_window/). A
fogadó
számítógép
az
Ablak
(más
néven puerméret) mez®vel megadja, hogy az utolsó nyugtázott csomag után hány csomagot jogosult
még
ablakméreten
a
küld®
túl
csak
gép a
továbbítani.
következ®
nyugta
beérkezése után szabad adatot küldeni.
c 2004,
A. S. Tanenbaum: Computer Networks
12.1.2. A TCP min®ségbiztosítása
12.1. ábra. Távoli eljáráshívás
Az RTP (Real Time Transport Protocol) az UDP-re
12.2.
épül,
és
a
felhasználó
címterében
12.2.
Az
Hálózati architektúrák és protokollok
c 2004
100
by Sams Publishing/J. Casad 12.3. ábra. Tipikus t¶zfal kapcsolat
A
t¶zfal
olyan rendszer, amelyik a helyi há-
lózatot védi meg attól, hogy azt az Internetr®l jogosulatlanul használják. Sokféle de níciója és
feladata
között
olyan
is
van,
amelyik
a
szállítási réteg funkcióihoz kapcsolódik, annak m¶ködését befolyásolja: a t¶zfal képes blokkolni
a
hozzáférést
portokhoz.
bizonyos
TCP
és
UDP
Néhány (f®ként régebbi) protokoll
komoly biztonsági kockázatot jelent, ha azon át
bárki
hozzáférhet egy szolgáltatáshoz (pl.
Telnet),
viszont
számára
nyújtani
a
megbízható felhasználó k
kell
a
szolgáltatást.
Ilyen
esetekre jelent megoldást a 12.3 ábra szerinti elrendezés.
12.2.
Hálózati architektúrák és protokollok
i
A. Bináris információ és ábrázolása A.1. Szám ábrázolása és átalkítások A modern digitális számítógépek az információt digitális formában tárolják, mivel alapvet®en
ilyen
módon
dolgoznak
vele.
A
szá-
mítógépeken belül az információ tárolása és
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
manipulálása olyan komponensekben történik, ahol az állapotok a be és ki állapotú lám-
A.1. ábra. Bináris információ ábrázolások és
pákhoz hasonlóan kétfélék lehetnek. A be és
elnevezéseik
ki állapotokat sokféle módon kifejezhetjük. Logikai kifejezések értékét igaz vagy hamis
A.7. táblázat. Bináris információ cso-
értéknek
portok és elnevezések
tekinthetjük.
Matematikai
értékek
ábrázolására legáltalánosabban az egy (be)
Bitek száma
és nulla (ki) ábrázolás használatos. A számítógépes információ alapvet® épít®köve a bit (
binary
t
digi ). A bit értéke 0
vagy 1 lehet. Ha egy bitet 1 érték¶vé teszünk, az mondjuk beállítjuk (setting) ha nullává
Elterjedt ábrázolása
1
Bit / Digit
4
Nybble / Nibble
8
Byte / Octet / Character
16
Double Byte / Word
32
Double Word / Long Word
64
Very Long Word
tesszük, töröljük (clearing). Egy
bit
mennyiség¶
természetesen információt
csak
nagyon
ábrázol:
kis
egyetlen
particular le has been modi ed; this is an
tényt vagy értéket. Bizonyos számú bitet kell
analogy to a ag either being raised or lowered
egy csoportba összefogni, hogy több informá-
to indicate a condition. These ags are often
ciót és/vagy összetettebb adattípust tudjunk
seen in networking message formats.
ábrázolni. Leggyakrabban kapcsolunk egy egységgé
és
hivatkozunk
egyetlen
The term character is also used to express
egységként.
a set of eight bits. This use comes from the
Egy ilyen nyolc bites egységet oktetnek vagy
fact that computers often store alphanumeric
bájtnak hívják (bár ma már szinte minden
characters, such as letters and numbers, one
bájt nyolc bitb®l áll).
to a byte. The 16-bit word is fairly often used,
Az id®k során más bitcsoportok is kiala-
but not nearly as much as byte. The larger
kultak, jól meghatározott jelentéssel. Egy bájt
collections of bits, such as double word and
nyolc bitb®l áll, a négy bites egységet fél bá j-
so on, are not often encountered in every-day
nak (nybble) nevezik. Nagyobb bitcsoportok
parlance; they are used to represent chunks
is vannak, különböz® nevekkel.
of data in technical elds such as hardware
A A.7 ábra foglalja össze a bitcsoportok
design or programming.
legelterjedtebb ábrázolásait és elnevezésüket;
The number of bits used for each of these
relatív méretüket pedig a A.1 ábra mutatja
terms is a power of two. This occurs because
gra kusan.
when
A
few
of
these
terms
are
worth
bits
come
in
sets
that
are
a
power
special
of two in size, they are easier to represent
mention. A bit is also sometimes called a ag;
and manipulate in a convenient manner. The
this term is most often heard when a bit is
number of bits in the term can itself be easily
used by itself to represent a particular infor-
expressed using binary numbers.
mation state. For example, a computer might use a changed ag
to represent whether a
A.1. Szám ábrázolása és átalkítások
The numbers we are used to using in everyday life are called decimal numbers. Computer
Hálózati architektúrák és protokollok
ii
A.8. táblázat. Binary and Decimal Number Equivalents
Binary number
1
1
0
1
0
0
1
1
Power of Two
27
26
25
24
23
22
21
20
Value of Digit Place
128
64
32
16
8
4
2
1
Value
128
64
0
16
0
0
2
1
Running Sum
128
128+64 = 192
192
192+16 = 208
208
208
208+2 = 210
210+1 = 211
systems deal only with binary numbers. Each
shorthand
bit can represent not a value from 0 to 9, but
both of these, instead of working with each bit
from, well, 0 to 1. A single 0 or 1 value is
individually, they are collected into subgroups,
su cient for encoding a single fact, such as
each
whether your car currently is using summer
an alternative numbering system. 11110100,
tires or snow tires.
which is 244 in decimal, is chopped into groups
Larger
collections
have
assigned
a
de ned.
single
digit
In
in
ned, such as bytes (octets), words, and so
octal or base-8 numbering system, see Figure
forth. When individual bits are collected into
A.2. Using groups of four, i.e. hexadecimal
sets in this way, they can be used together
or base-16 numbering system, number F4 is
to represent larger integers, which are called
received. In hexadecimal numbers the values
binary
10, 11, 12, 13, 14, or 15 are represented by
there
are
been
is
been
of three, starting from the right: is 364 in the
Since
bits
which
have
de-
numbers.
of
of
notations
only
two
possible values for each digit, binary numbers
the letters A , B , C , D , E
are also called base 2 numbers.
respectively.
and F ,
Counting in decimal goes 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 and so on, counting in
binary
goes
0,
1,
10,
11,
100,
101,
110,
111, 1000, 1001, 1010, 1011, 1100, 1101. The concept is identical: you just need a lot more digits for binary numbers because there are so many fewer values allowed for each digit. Table A.8 show show 211 in decimal and 11010011 in binary are equivalent, by adding the values for each binary digit place where there
is
a
1.
Read
it
from
left
to
right,
going top to bottom. Starting in the left-most
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
column, we see that the example number has a 1 in the "128s" place. So we start with a sum of 128. In the next column there is a 1 in the "64s" place, so we add 64 for a running sum of 192. But in the "32s" place the binary digit value is 0, so we don't add 32 to the sum. We continue down to the "ones" place to get the decimal equivalent of the binary number. A binary number with N digits can hold up to
2N
can hold
values. So, a byte, with eight bits,
28
or 256 dierent values, which are
numbered from 0 to 255. A 16-bit word can hold
216
numbers
or 65,536 values. easier
to
work
To make binary with,
two
A.1. Szám ábrázolása és átalkítások
dierent
A.2. ábra. Binary, Octal and Hexadecimal Number Representations
Table A.9 shows the hexadecimal number 0x830C
converted
to
decimal
(octal
uses
a
similar process). Read the table from left to right,
top
to
bottom;
multiplied
by
the
each
digit's
appropriate
value
power
of
is 16
and added together, yielding the result 33,548 decimal. The easiest of the three conversions from decimal is to binary since the maximum value of each digit is one, there is no dividing, just subtraction. All you do is the following:
Hálózati architektúrák és protokollok
iii
A.9. táblázat. Hexadecimal to Decimal Number Conversion
Hexadecimal Number
8
3
0
C
Decimal Value of Digit
8
3
0
12
Power of 16
163
162
161
160
Value of Digit Place
4096
256
16
1
Value For This Number
4096*8 = 32768
3*256 = 768
0*16 = 0
12*1 = 12
Running Sum (from left to right)
32768
32768+768 = 33536
33536
1. Find the largest power of two that is smaller than the number.
33536+12 =
33548
that place from the second number, yielding a raw digit sum of 2. This means the result for the "ones" digit is "1" and we carry a 1 to the
2. Put a 1 in the digit place for that power of two and subtract that power of two
"twos" place. We continue with this process until we have added all the digits.
from the decimal number.
Octal
3. Repeat steps #1 and #2 until you are
and
hexadecimal
are
pretty
much
the same, except that you carry if the sum in a particular digit exceeds either 8 or 16,
reduced to zero.
respectively. Table A.13, shows an example, The process for octal and hexadecimal is
which again should be read from right to left.
almost the same, except you must divide by
We start by adding "8" (decimal 8) to "A"
powers of two instead of just subtracting:
(decimal 10) in the "ones" place. This yields a raw sum of 18, from which we carry 16 as a
1. Start
with
the
highest
power
of
16
(hexadecimal) or 8 (octal) that is smaller than the number. 2. Divide
the
"1" to the "16s" place and leave a result of 2. We add this 1 to the "D" (value 13) and "E" (14 value) of the "16s" place. This is a total
decimal
number
by
that
power, keeping only the integer part of the result. 3. Keep the remainder after the division is done, for the next step. 4. Repeat steps #1 to #3 until you get to the ones place, and then put there whatever is left after the higher digits were done.
of 28, leaving 12 ("C" in hexadecimal) and we carry a 1 to the "256s" place. This continues until we are left with a sum of 6DC2h.
A.3. Boolean Logic and Logical Functions logic de nes a number of boolean logical functions, which are also sometimes called operators. Each of these uses a logical Boolean
algorithm to compute an output value based
A.2. Aritmetics in other number systems
on
the
value
of
one
or
more
inputs.
The
algorithm determines when the output is a true
value, based on what combination of
true and false values the inputs take. For
Adding binary numbers is the same as adding
this reason, the table that shows the inputs
decimal
and outputs for a logical function is called a
of
ones,
carrying
of
but
you
ones
end
since
up
there
doing are
values allowed per digit. Table A.12
a
so
lot few
truth table.
shows
The simplest such operation is negation;
an example, with one digit in each column;
the output is the opposite of the input. The
read it from right to left and top to bottom,
NOT
just as you would usually do manual addition.
called a
So we start by adding the "1" in the "ones"
table
place from the rst number with the "1" in
A.3. Boolean Logic and Logical Functions
function takes only one input, so it is
unary function or operator. The truth for NOT is shown in Table A.14. The
Hálózati architektúrák és protokollok
iv
A.10. táblázat. Decimal to Binary Conversion
Decimal
689
689
177
177
49
49
17
1
1
1
1
Power of Two
210
29
28
27
26
25
24
23
22
21
20
Value
Value
Before
Considering
This
Digit Place of
Digit
1024 512
256
128
64
32
16
8
4
2
1
of
Digit
No
Yes
No
Yes
No
Yes
Yes
No
No
No
Yes
skip
689- skip 177- skip 49-
17-16 = 1
skip skip skip 1-
Place Value Place or
Equal
Less
Current
;
To
Than
Decimal
Number? Subtraction Step
Binary Digits
0
32
1
512
128
=
=
=
=
17
0
177
49
1
0
1
0
1
1
0
0
A.11. táblázat. Decimal to Hexadecimal Number Conversion Decimal
Value
689
689
177
1
Power of 16
163
162
161
160
Value of Digit Place
4096
256
16
1
Value of Digit Place
No
Yes
No
n/a
skip
689/256
Before Considering This Digit Place
Smaller Than Current Decimal Number? Division Step
2.691;
Remainder
After
=
use
177/16
=
n/a
11.0625;
2 for this
use B for
digit.
this digit.
skip
177
1
n/a
0
2
B
1
Division Hexadecimal Digits
A.12. táblázat. Binary addition Carry
1
1
1
1
First Binary Number
1
0
1
1
0
0
1
1
Second Binary Number
0
0
1
1
1
0
0
1
Raw Digit Sum
1
1
3
2
1
1
2
2
Result
1
1
1
0
1
1
0
0
1
1
1
1
Carry to Next Higher Digit
A.3. Boolean Logic and Logical Functions
0
1
Hálózati architektúrák és protokollok
v
A.13. táblázat. Hexadecimal addition Carry
1
1
First Hex Number
2
C
D
8
Second Hex Number
4
0
E
A
Raw Digit Sum
2+4 = 6
1+12+0
1+13+14
8+10
= 13
= 28
18
D
C
2
1
1
Result
6
Carry to Next Higher
=
Digit
output is true when the input is false, and viceversa.
A.15. táblázat.
AND Operator Truth
Table
A.14. táblázat.
NOT Operator Truth
Input #1 Input #2 Output
Table
Input output 0
1
1
0
0
0
0
0
1
0
1
0
0
1
1
1
A.16. táblázat. Boolean logic is often expressed in terms of ones and zeroes, instead of true and false. The circuits inside computer processors and
OR
Operator Truth
Table
Input #1 Input #2 Output
other devices manipulate one and zero bits directly using these functions. In some (but not all) cases they interpret one and zero as true and false , but in either case the two
0
0
0
0
1
1
1
0
1
1
1
1
representations are functionally equivalent. In Table A.14
each True is represented as a 1
and each False as a 0.
output is true as long as
There are two other primary boolean func-
AND function and the OR function. Both AND and OR can
OR however, the any of the inputs is
for dessert. In the boolean
true, even if more than one is.
tions that are widely used: the
have any number of inputs, with a minimum
AND function is true and its second input and
of two. The output of an only if its rst input
A.17. táblázat.
XOR Operator Truth
Table
Input #1 Input #2 Output
its third input (etc.) are all true, see Table
0
0
0
A.15. The output of an
0
1
1
1
0
1
1
1
0
if the rst input is true is true
or
OR function is true or the second input
the input is true (again, etc.), see
Table A.16.
AND function, the OR function in fact does not have the
Interestingly, unlike the boolean
same meaning as the way that we routinely use the word or in English. When we say or , we usually mean one "`or"' the other, but not both: you can have apple pie or chocolate cake
A.3. Boolean Logic and Logical Functions
OR called Exclusive-OR XOR or EOR) represents
A modi cation of (abbreviated either
the way we normally use or in the real world. Its output is only true if one input is true or the other,
but not both. The truth table for
XOR is as shown in Table A.17.
Notice the
Hálózati architektúrák és protokollok
vi
dierence between this table and Table A.16:
painted,
the output is 0 in the case where both inputs
tape. Thus, the process is called masking. The
is 1.
string of digits used in the operation is called
The be
functions
combined
in
described
arbitrary
above
ways
can
to
also
using
plastic
or
perhaps
masking
the bit mask, or more simply, just the mask.
produce
Suppose we have the 12-bit binary input
more complex logical conditions. Boolean logic
number 101001011010, and we want to set the
expressions are used in many dierent contexts
middle six bits to be all ones. To do this,
in the computing eld.
we simply OR the number with the 12-bit
In networking, boolean logic is important
mask 000111111000. Table A.18 shows how
for describing certain conditions and functions
this works, with the changed bits in the result
in the operation of networks. Boolean func-
highlighted we simply OR each bit in the
tions are also very important because they are
input with its corresponding bit in the mask
used to set, clear and mask strings of binary digits.
A.4. Bit Masking Using Boolean Logical Functions NOT, AND, OR
The boolean functions
XOR
describe
dierent
ways
that
and
logical
expressions can be used to manipulate true and
false
values
to
represent
both
simple
and complex decisions or conditions. However, these functions can also be used in a more
c 2005
by http://www.tcpipguide.com/C. M. Kozierok
mundane manner, to allow the direct mani-
A.3. ábra. Clearing Bits Using an AND Bit
pulation of binary data. This use of boolean
Mask
logic is very important in a number of dierent To clear a certain pattern of bits, you do
applications in networking. In some situations bits are handled individually , and are set or
a
similar
masking
operation,
but
using
the
cleared simply by assigning a one or zero value
AND function instead. If you AND a bit with
to each bit. However, it is common to have
zero, it will clear it to zero regardless of what
large groups of bits that are used collectively
the bit was before, while
to represent a great deal of information, where
will leave the bit unchanged. So, to take the
many bits need to be set or cleared at once.
same
OR
Recall that the
function's output is
example
six bits, we
above
AND
ANDing
and
clear
with one
the
middle
with the reverse bit mask,
true (one) if any of its inputs is true (one).
111000000111. This is shown in Table A.19
Thus, if you OR a bit with a value known to
and illustrated in Figure A.3.
be one, the result is always going to be a one,
We can also look at this clearing function
no matter what the other value is. In contrast,
a dierent way. We are clearing the bits where
if you OR with a zero, the original value, one
the mask is a zero, and in so doing selecting
or zero, is not changed.
the
Setting
bits
en
masse
can
exploiting the properties of the By
using
a
particular to
1
while
procedure masks
string
spots,
with you
leaving is
areas
others
comparable that
zeroes
can
he
set
OR
done
and
ones
not
a
want
in
where with
a
the
mask
is
bit
mask
means
a
one.
Thus,
that
you
keep the bits where the mask is a one and remove the bits where it is a zero.
bits
There are also situations in which we want
This
to invert some bits; that is, change a one value
painter
to a zero, or a zero value to a one. To do this,
certain
how
by
function.
unchanged.
to
does
be
bits
ANDing
to
be
we use the
A.4. Bit Masking Using Boolean Logical Functions
XOR
function. If you
XOR
with a
Hálózati architektúrák és protokollok
vii
OR Bit Mask
A.18. táblázat. Setting Bits Using an Input Mask Result
of
OR
1
0
1
0
0
0
1
0
1
0
0
1
0
1
1
1 1 1 1 1 1 1 1 1 1 1 1
0
1
0
0
0
0
0
1
0
Operation
AND Bit Mask
A.19. táblázat. Clearing Bits Using an Input Mask Result
of
AND
1
0
1
1
1
1
1
0
1
0
0
1
0
1
1
0 0 0 0 0 0 0 0 0 0 0 0
0
1
0
1
1
1
0
1
0
Operation
XOR Bit Mask
A.20. táblázat. Inverting Bits Using an Input Mask Result
of
XOR
1
0
1
0
0
0
1
0
1
0
0
1
0
1
1
1 1 1 1 1 1 1 1 0 1 0 0
0
1
0
0
0
0
0
1
0
Operation
one, the input value is ipped, while
XORing
ta
félvezet®k
rosszul
vezetnek,
de
with a zero causes the input to be unchanged,
szenyezésekkel
see Table A.20.
anyagokat lehet készíteni bel®lük.
vezérelhet®
megfelel®
vezet®képesség¶
Elektronok közvetítésével a jó elektromos
B. A hálózati jeltovábbítás zikai alapjai B.1. Az anyagok elektromos tulajdonságai
vezet®kb®l készült fémkábeleken lehet adatokat átvinni. Praktikus okokból rézvezetékeket használnak. Ma már egyre inkább kiszorulnak a
gyakorlatból:
nehéz,
drága
kábelek;
kicsi
jeltovábbítási távolság; kényelmetlen kezelés, stb. Elektronokkal való adattovábbításhoz zárt áramköröket Az
(lásd
összeköttetés
áramkör beleken
jellemz®i az
haladnak
B.2
A
kell
létrehozni.
az
elektromos
határozzák
elektronok
át.
ábra
viselkedését
meg.
elektromos
kábelre
az
ún.
A
ká-
áramként
impedancia
jellemz®. Az impedancia ugyanaz váltóáram és valódi áramköri elem esetén, mint egyenáram
c 2006
by CISCO
és
B.1. ábra. Az anyagok felosztása vezet®képességük szerint
Az anyagokat elektromos vezet®képességük alapján három nagy csoportra osztjuk, lásd B.1 a
ábra.
A
szigetel®k
fémek nagyon
jó
elektromos
rossz
B.2. A fénytörés zikája
vezet®k.
vezet®k, A
tisz-
tisztán
ohmos
terhelés
esetén
az
ohmos
az áram áthaladásával szemben kifejtett ellenállás mértéke. ellenállás:
B.2. A fénytörés zikája A fény különböz® optikai tula jdonságú (lásd B.3 ábra) közegekben különböz® sebességgel
Hálózati architektúrák és protokollok
c 2006
viii
c 2004
by CISCO
B.2.
ábra.
Elektromos
áramkör
zárt
by [email protected]
B.5. ábra. A fénytörést bemutató kísérlet
és
nyitott állapotban
halad, a közegek határán irányt és sebességet vált, lásd B.4 ábra. A fény irányítását ilyen hatások segítségével oldhatjuk meg.
c 2006
by CISCO
B.3. ábra. Különböz® anyagok törésmutatói
c 2004
by [email protected] B.6. ábra. A fénytörés elvi rajza
c 2004
by [email protected]
B.7. ábra. A fénytörést leíró formula
A fénytörés jelenségét leginkább a közegek határán (a kábelek végpontjain) kell gyelembe venni.
c 2004
Bizonyos határszög alatt (lásd B.8 ábra)
by [email protected] a B.4. ábra. A fénytörés jelensége
B.2. A fénytörés zikája
fény
nem
tud
a
másik
közegbe
belépni,
ilyenkor teljes visszaver®dés (lásd B.9 ábra)
Hálózati architektúrák és protokollok
lép fel. A jelenség fontos szerepet kap abban, hogy a fény veszteségmentesen terjedhessen az optikai kábelekben.
ix
B.3. Adattovábbítás rádióhullámokkal B.3.1. Az elektromágneses spektrum és tulajdonságai Elektromágneses sugárzást elektromos töltések mozgatásával hozhatunk létre. Az elektromágneses sugárzás tulajdonsá-
c 2004
by [email protected]
B.8. ábra. A teljes visszaver®dést leíró kép-
gai
jelent®sen
lámhossz)
változnak
függvényében,
a
frekvencia
lásd
B.11
(hul-
ábra.
A
hullámhossztartomány egy részét látható fény-
let
ként észleljük, kezelésük optikai eszközökkel lehetséges.
c 2006
by CISCO
B.9. ábra. A teljes visszaver®dés elvi ra jza
c 2006
by CISCO
B.12. ábra. A h®mérsékleti sugárzás színspektruma
Az egyik jellemz® elektromágneses sugárzás keltési mód a h®mérsékleti sugárzás, lásd B.12 az a
ábra.
eloszlás sugárzó
A
sugárzási
spektrum
maximumának test
helye
h®mérsékletével.
alakja
is Ezt
és
változik a
fa jta
spektrumot folytonos eloszlásúnak nevezzük.
Egy mus atom zötti
a
másik
fontos
karakterisztikus
meghatározott energia
sugárzási sugárzás,
energiájú
sugárzódik
ki
mechanizamikor
állapotai
az kö-
elektromágneses
sugárzás formá jában, lásd B.13. ábra. Ez a spektrum
c 2004
by [email protected]
B.10. ábra. A teljes visszaver®dés jelensége
diszkrét
energia
(frekvencia
nos.
B.4. Adattovábbítás rádióhullámokkal B.3. Adattovábbítás rádióhullámokkal
vagy
hullámhossz) értékeket tartalmaz, nem folyto-
Hálózati architektúrák és protokollok
c 2008
by Wikipédia B.11. ábra. Az elektromágneses spektrum
c 2006
by CISCO B.13. ábra. Karakterisztikus sugárzás
B.4. Adattovábbítás rádióhullámokkal
x
Tárgymutató újraküldési id®zít®, 46
ICMP, 89
újraküldési sor, 46
inetd, 10 intranet, 2
adatátvitel, 4
IP cím
alhálózat, 10
v4, 10 IP címosztályok, 54
Berners-Lee
ISP, Internet Service Provider, 16
Tim, 1 broadcasting, 15
MAC cím, 70 message transfer agent, 29
CIDR, 59
MIME,
Classless Internet Domain Routing, 59
Multipurpose
Internet
Mail
sions, 33
csavart érpár, 77
multicasting, 15
csomópont, 7
multiplexelés, 43 demultiplexelés, 43 NAP, Network Access Point, 16
dinamikus forgalomirányítás, 64
network
DNS
point-to-point, 15
MX rekord, 37
next hop routing, 66
szint, 23
node, 7
zóna, 23
NVT, Network Virtual Terminal, 29 e-mail, 3 PDU, protocol data unit, 12
elektronikus levél, 3
point-to-point network, 15
extranet, 2
POP, Point of Presence, 16 port, 10
Fourier-analízis, 75 FQDN, Fully Quali ed Domain Name, 23
ephemeral, 11
Frequency Division Multiplexing, FDM, 76
registered, 10
FTP, File Transfer Protocol, 28
well-known, 10 protokoll, 7
gazdagép, 7
HTTP, 36
gráf
ICMP, 89 rész, 23
IMAP, 30 kapcsolattípusok, 12
hálózati
POP, 30
protokoll, 14
SMTP, 30, 31
réteg, 14 szolgáltatás, 14
részgráf, 23
hálózati cím
rétegek
IP, 10
OSI, 13
MAC, 70
rétegmodell, 7, 18
hálózati modell
TCP/IP, 15
OSI, 13
RFC, 3
TCP/IP, 15 sávszélesség, 75
HTTP, 36 request line, 36
sávsz¶r®, 75
status line, 36
SDU, service data unit, 12
xi
Exten-
Hálózati architektúrák és protokollok
SMTP, Simple Mail Transfer Protocol, 31 socket, 10, 11, 16 szállítási funkcionális elem, 38 számítógéphálózat, 7 szolgáltatás jól ismert, 10 TCP/IP protokollkészlet, 18 rétegszerkezet, 18 telnet, 29 TFTP, Trivial File Transfer Protocol, 29 transport entity, 38 unicasting, 15 URI, Uniform Resource Identi er, 36 URL, Uniform Resource Locator, 37 URN, Uniform Resource Name, 37 user agent, 29
Tárgymutató
xii
