Számítógép Hálózatok Programozóknak v1.0

Számítógép hálózatok programozóknak
Dr. Bilicki Vilmos, Szabó Zoltán, Jánki Zoltán Richárd

A jegyzetben található ábrák esetén az alábbi forrásokat használtuk fel (az ábra felirata végén
jelezzük ezt)
1. Az ábra a referencia könyv [1] ppt ábráinak felhasználásával készült "All material copyright
1996-2016 J.F Kurose and K.W. Ross, All Rights Reserved"
Tartalomjegyzék
1 Programozó centrikus rész 7
1 Bevezető 9
1.1 Az információs technológia (IT) jelene
1.2 Az Internet fogalma
1.3 Számítógép hálózatok felépítése
1.4 A jövő
1.5 Kommunikáció
1.6 Számítógép hálózati szolgáltatások teljesítménymutatói
1.7 Számítógép hálózatok gyakorlati felépítése
1.8 Számítógép hálózatok biztonsága
1.9 A számítógép hálózatok elméleti alapjai
1.10 Ellenőrző kérdések
1.11 Irodalomjegyzék, további olvasnivalók
1.12 Kompetenciák és tanulási eredmények
2 Hálózati biztonság 23
2.1 A kriptográfia alapjai
2.2 Üzenet integritás, digitális aláírás
3 Alkalmazás réteg 35
3.1 A hálózati alkalmazások háttere
3.2 WWW
3.2.1 HTTP 1.1 alapok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2 HTTP Gyorsítótárazás, CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.3 HTTP Biztonság, azonosítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.4 HTTP 2.0, 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.5 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 DNS
3.3.1 DNS architektúra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.2 DNS adatbázis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.3 DNS protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.4 DNS gyorsítótárazás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.5 DNS biztonság . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Email
3.5 SMTP protokoll
3.5.1 Email biztonságossá tétele - PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.6 P2P
3.6.1 BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.6.2 Paxos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7 Videó
3.7.1 Videó tömörítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.7.2 Videó folyam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2 Általános rész 67
4 Szállítási réteg 69
4.1 Szállítási réteg szolgáltatások
4.1.1 A szállítási réteg alapelvei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.2 A szállítási réteg és más rétegek kapcsolatai . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.3 A szállítási réteg és az Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2 Multiplexelés/Demultiplexelés
4.2.1 Kapcsolatmentes multiplexelés és demultiplexelés . . . . . . . . . . . . . . . . . . . . . . 72
4.2.2 Kapcsolatorientált multiplexelés és demultiplexelés . . . . . . . . . . . . . . . . . . . . . 73
4.3 Kapcsolatmentes átvitel: UDP
4.3.1 UDP szegmens struktúra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3.2 UDP ellenőrző összeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.4 A megbízható átvitel alapjai
4.4.1 Adatátvitel egy tökéletesen megbízható csatornán: rdt1.0 . . . . . . . . . . . . . . . 76
4.4.2 Adatátvitel egy bithibás csatornán: rdt2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4.3 Adatátvitel egy bithibás és adatvesztő csatornán: rdt3.0 . . . . . . . . . . . . . . . . 79
4.4.4 Cső szervezésű megbízható adatátviteli protokollok . . . . . . . . . . . . . . . . . . . . 81
4.5 Kapcsolatorientált átvitel: TCP
4.5.1 TCP kapcsolat kiépítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.5.2 TCP szegmens struktúra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.5.3 Megfordulási idő és időtúllépés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.5.4 Megbízható adatátvitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.6 A torlódásvezérlés alapjai
4.7 TCP torlódásvezérlés
4.7.1 Torlódásvezérlés algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.7.2 TCP igazságosság . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.7.3 Explicit torlódás értesítés (ECN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5 Hálózati réteg 101
5.1 Hálózati réteg elemek
5.2 Hálózati réteg felbontása
5.3 Hálózati réteg: adatsík
5.3.1 A forgalomirányítók felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.3.2 Az IP protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.3.3 IP címzés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.3.4 Hálózati címfordítás, NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.3.5 Dinamikus cím kiosztás (DHCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.3.6 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.3.7 Általánosított továbbítás - Szoftverrel Definiált Hálózat - SDN . . . . . . . . . . . . . 112
5.4 Hálózati réteg: vezérlősík
5.4.1 Bevezető . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.4.2 Forgalomirányító protokollok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.4.3 Autonóm rendszeren belüli protokollok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.4.4 Autonóm rendszerek közötti protokollok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.4.5 Az SDN vezérlő síkja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.4.6 Az ICMP protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.4.7 Hálózatmenedzsment - SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6 Adatkapcsolati réteg 127

6.1 Bevezetés
6.2 Szolgáltatások
6.3 Megvalósítása
6.4 Hibadetektálás
6.5 Többszörös hozzáférési protokollok
6.5.1 Csatorna Partícionáló Protokollok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.5.2 Véletlen hozzáférésű protokollok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.5.3 Felváltott protokollok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.5.4 DOCSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.6 Helyi hálózatok
6.7 Ethernet
6.8 VLAN
6.9 Vonal virtualizáció, MPLS
6.10 Adatközpont hálózatok
6.11 Egy webkérés életútja
6.11.1 IP cím szerzése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.11.2 Alapértelmezett átjáró MAC címének kiderítése . . . . . . . . . . . . . . . . . . . . . . 155
6.11.3 Forgalomirányítás a szerver felé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.11.4 Kliens-szerver kapcsolat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.12 Vezetékmentes hálózatok
6.12.1 Vezetékmentes vonalak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.12.2 PAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.13 WiFi
6.13.1 WiFi hálózatok biztonsága . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.14 Mobilhálózatok
6.14.1 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.14.2 4G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.14.3 5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.15 Mobilitás
6.15.1 Mobilitás cella alapú hálózatokban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

7.1 Biztonságos TCP kapcsolat: SSL
7.2 Biztonságos hálózati réteg: IPSec és VPN
7.2.1 AH és ESP protokollok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
7.2.2 Biztonsági Asszociációk (SA - Security Associations) . . . . . . . . . . . . . . . . . . . . 180
7.2.3 IPSec csomag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.3 Rendszerszintű biztonság:Tűzfal, IDS
7.3.1 Proaktív rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.3.2 Reaktív rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
3 Függelékek 187
Bibliográfia 189
Szójegyzék 193
Kompetenciák és tanulási eredmények 215
Ábrajegyzék 218
1
Programozó centrikus rész
1 Bevezető 9
1.4 A jövő
1.5 Kommunikáció
1.6 Számítógép hálózati szolgáltatások
teljesítménymutatói
3 Alkalmazás réteg 35
3.2 WWW
3.3 DNS
3.4 Email
3.5 SMTP protokoll
3.6 P2P
3.7 Videó
1. Bevezető
Miért érdekes ez a fejezet egy programozónak?

• Nehéz ma olyan alkalmazást fejleszteni amelynek nincs kapcsolata az Internettel.
• Más igényeink lehetnek egy videó folyamnál és egy sima HTTP (nem elegendő a
klasszikus WWW szoftver veremre koncentrálnunk) kapcsolatnál. Tudunk erről?
• Hol helyezkedik el a felhő, köd a mai hálózatokban? Ha nem tudjuk, hogy mi az a felhő,
köd akkor szintén szükségünk van erre a bevezetőre.

Kedves olvasó, jelen jegyzet célja a számítógép hálózatok bemutatása szoftverfejlesztőknek. A

tárgyalás módban és a felépítésben a praktikumot előtétbe helyező felülről lefelé megközelítés
módot alkalmazzuk követve a [1] tankönyv felépítését. E felépítést, tartalmat úgy pozicionáljuk,
hogy a szoftverfejlesztői tudásépítést helyezzük előtérbe. Minden egyes fejezet elején bemutatjuk,
konkrét gyakorlati példákra mutató kérdések segítségével, hogy adott fejezet tartalma miért is lehet
érdekes, fontos egy szoftverfejlesztőnk. A jegyzet terjedelmi korlátok miatt nem tud mindent kellő
mélységben tárgyalni, így javasoljuk a [1] tankönyv olvasását is részletek megismerése, mélyebb
megértés érdekében.

Az IT ma a világ és a gazdaság minden területén megjelenik. Az ipari forradalom 4. lépcsőjét
éljük meg a mesterséges intelligencia alkalmazásával. Hol helyezkedik el ebben a forradalomban
a számítógép hálózat? E fejezetben egy hálózat centrikus áttekintést adunk az aktuális és a
közeljövő IT trendjeiről. Történelmi skálában 5 nagy szakaszt különböztetünk meg az alapvető
IT képességek, technológiák viszonylatában. Ez látható az 1.1. ábrán. Az IT képességeken
túl érdekes hullámzást figyelhetünk meg a megoldásmódok között. Az első a gyakorlatban is
alkalmazott IT rendszerek a központosított nagy számítógépek voltak hozzájuk kapcsolódó „buta”
terminálokkal (csupán képernyő és billentyűzet). Ezt követte a PC (Personal Computer - személyi
számítógép) forradalma ahol az adatok feldolgozása, tárolása az irodákban lévő PC-ken történt.
Itt a cégek ügyvitele, könyvelés az adott munkatárs gépén történt, igen gyakran táblázatkezelő
10 1. fejezet - Bevezető
eszköztárral (Excel, Access...). A következő nagy lépést az Internet és annak legnépszerűbb

szolgáltatása, a WWW (Word Wide Web - világháló) készítette elő. Ekkor kezdtek az asztalokon
futó szoftverek újra a központba költözni, de ezúttal nem egyedi, csak kevesek által elérhető nagy
számítógépekbe, hanem olyan adatközpontokba ahol több tízezer gép van egy-egy nagy rendszerbe
kötve és ezekből virtualizált erőforrásokat lehet bérelni (pl.: virtuális gépet). Ezt nevezzük felhő
(cloud) számítástechnikának. Hasonlóan az elektromos áramhoz, itt is a használat utáni fizetés
(meg van mérve, hogy mennyi áramot fogyasztottunk, azt kell kifizetnünk, itt pl.: mennyi ideig
futott a virtuális gép) tette lehetővé az erőforrások ilyen méretű központosítását és megosztását. A
mobil technológia megjelenése egyrészt erősítette a felhő alapú megoldásokat (ma minden mobil
alkalmazás használ valamilyen felhő alapú szolgáltatást, ha mást nem akkor az alkalmazás boltot
az alkalmazás terjesztésére és életciklusának kezelésére). A mobil hálózatok, az olcsó és nagy
számítás kapacitású hardver magoldások lehetővé tették az IoT (Internet of Things - Dolgok
Internete) kialakulását. Itt egy új képesség jelent meg: mérni tudjuk a környezetünket és be
is tudunk avatkozni (pl.: az üdítőitalos automata 3G/4G hálózat segítségével jelzi a központba,
hogy egy adott üdítő mennyisége egy adott szint alá került). Az IoT esetén fontos lehet a helyi
feldolgozás, egy videókamera esetén például amennyiben az úton áthaladó autókat szeretném
megszámolni, akkor nem célszerű a videó-folyamot beküldeni a központba, hanem ott a helyszínen
kell a videót feldolgozni és a központba csak az autók számát kellene elküldeni. Megjelent tehát
az igény arra, hogy a felhőt mint futtatási, működtetési környezetet megtartva adott funkciókat
visszavigyük a helyszínre, ez a köd (fog) vagy vég rendszer (edge) számítástechnika. A témában
történő mélyebb elmerülésre érdemes ezt a könyvet forgatni: [2].
1.1: IT trendek

Az Internet, mint szolgáltatás alapjaiban változtatta, változtatja meg napjaink társadalmát, ma már
közműként tekintünk rá, elvárjuk hogy bármikor, bárhol és bárhogy el tudjuk érni. A jelentőségét
nem csak a társadalom megváltoztatásában találhatjuk meg, hanem abban is, hogy az Internet
az emberiség által megvalósított legnagyobb rendszer. Több milliárd felhasználó sok százmillió
szerver és több milliárd okos eszköz közös játszótere. Az Internet magasból nézve nem más mint
számítógépek hálózata, ahol számítógép alatt érthetünk az okos hűtőtől kezdve minden, a hálózaton
1.3 Számítógép hálózatok felépítése 11
kommunikálni képes eszközt. Ezen eszközöket egy közös néven végrendszernek (end system)
nevezzük. Amennyiben figyelembe vesszük az erőforrással kapcsolatos szerepköröket, akkor
szerver (szerver) - erőforrás megosztó és kliens (kliens/host) - erőforrás felhasználó kategóriákra
bonthatjuk tovább az eszközöket. A végrendszerek csomagokat küldenek egymásnak, ezen
csomagok jelentik a kommunikáció alapját. Maga a kommunikáció kommunikációs vonalakon
(communication link) valósul meg, ehhez pedig közegfüggő konkrét kommunikációs módszert (pl.:
máshogyan kell vezetéken és rádióhullámokon kommunikálni) alkalmaznak. A kommunikációs
módszernek nem csak a közeghez kell illeszkednie, hanem a kommunikáló felek igényeihez is
(pl.: szeretném-e titkosítani a tartalmat, szeretnék-e garantált kézbesítést ...). Az Internet szintén
madártávlatból nézve ezen igények kielégítésére számos szolgáltatást nyújt a kommunikáló feleknek.
Az eszközök közötti együttműködést kommunikációs protokollok írják le. A protokollok lehetnek
nyílt protokollok (mindenkinek hozzáférhető) és zárt protokollok(adott cég saját megoldása és
ezt nem publikálja). A nyílt protokollokat különböző szervezetek szabványosítják, a számítógép
hálózatok területén a legismertebbek az IETF és az IEEE. A különböző szoftverek ezen protokollok
által specifikált interfészeken keresztül férnek hozzá az Internet/számítógép hálózat szolgáltatásaihoz.
Fontos Az Internet tehát fekete dobozként tekintve a végrendszereket összekötő különböző

szintű szolgáltatásokat nyújtó hálózat.

A csak “buta” kommunikációs (csak egy csatorna, nincs feldolgozás, döntés, ...., pl.: levegő)
vonalakra építő világméretű hálózat kiépítése igen nagy kihívás lenne. Gondoljunk bele, hogy a
levegőn, mint kommunikációs közegen hogyan próbálnánk egy tömeg kellős közepén egy adott
ismerőst üdvözölni, amikor mindenki beszélget. Ezen példától jóval bonyolultabb a problémánk,
mivel a rendszer világméretű és nincs egy közös kommunikációs közegünk. A tömeges elektronika
mentes kommunikáció problémáját már megoldotta az emberiség. Egy jó példa erre a klasszikus
levél és a posta rendszerek, mint szolgáltatók. A posta, mint világméretű hálózat képes adott
feladótól a világ bármely részén lévő címzetthez továbbítani a leveleket, csomagokat. Ezen
analógia mentén lett kialakítva a számítógép hálózat is. A végrendszereken kívül vannak kiszolgáló,
a rendszert üzemeltető „postai munkatársak”, „postások” is akik elvégzik a csomagok továbbítását
a megfelelő irány kiderítésével együtt. A feladattól függően ezen elemeket forgalomirányító
(router) vagy kapcsoló (switch) nevezzük. Ahogyan a világméretű postai hálózat - a nemzeti
posta hálózatok egységes, egymással együttműködő rendszere - képes a világméretű lefedettséget
megvalósítani, úgy az Internet is hálózatok hálózataként alakul ki. A különbség az, hogy az
Internet nem feltétlenül nemzeti hálózatok hálózata, hanem egy jóval vegyesebb, sokrétűbb
együttműködés eredménye. Ide tartoznak az Internet egyfajta gerincét alkotó transzatlanti (óceánok
alatti) összeköttetéseket biztosító szolgáltatók, de ide tartoznak a falu templomtornyából WiFi
segítségével helyi Internet elérést biztosító szolgáltatók is.
A hálózatokat szokták méretek és funkcionalitás szempontjából is osztályozni. A hálózat szintek
1.2 ábra felső részén láthatóak a tipikus mérethez, kiterjedéshez kötött kategóriák. WAN- Wide
Area Network - nagy kiterjedésű hálózatnak szokták nevezni a nagyobb földrajzi területeket lefedő
hálózatokat. A városi méretű és az azzal összevethető méretű hálózatokat MAN - Metropolian
Area Network - városi hálózatnak nevezik. A helyi néhány épületet vagy helyiséget lefedő
hálózatot LAN-nak Local Area Network - helyi hálózatnak nevezik, míg a néhány métert átívelő
hálózatot PAN-nak, Personal Area Network személyi hálózatnak nevezzük. E kategóriáknak
azért van jelentőségük, mert más-más méretű hálózatoknál más-más célok mentén kell technológiát
választani. A PAN-ra egy jó példa amikor az okos órát szeretnénk a telefonnal összekapcsolni
1.2: Hálózati szintek1
vezetékmentes közegen keresztül. Itt az energiafelhasználás egy kritikus szempont azaz az óra
és a telefon kapcsolatához olyan megoldást kell választanunk amely energiatakarékos. Egész
más kihívások vannak a WAN-ban ahol a sebesség és a megbízhatóság a kritikus szempont.
A felhasználókhoz közeli, azoknak közvetlenül Internet elérést biztosító hálózatokat határ /
hozzáférési hálózatoknak nevezzük (access / edge network). Ezen hálózatok a gerinc hálózat
(core) segítségével kapcsolódnak egymáshoz és ezzel az Internethez. A hozzáférési hálózatok
feladata adott fizikai közegek segítségével a felhasználók azonosítása, a szolgáltatás szintjük
mérése, biztosítása. A szolgáltatás megvalósítására vezetékes (optikai kábel, kábel TV) vagy
vezetékmentes (4G, LTE stb... , vagy WiFi) technológiákat alkalmaznak. Magát a szolgáltatói
hálózat és a végfelhasználói végpont POP (Point of Presence) közötti részt utolsó mérföldnek
(last mile), hozzáférési vonalnak (access link) nevezik. Egy kábel TV vagy optikai hálózat esetén
a POP egy kihelyezett modem (vagy set-top-box) lehet, amely a szolgáltató hálózatát összeköti
a helyi hálózattal. A helyi hálózat lehet otthoni hálózat, de céges, egyetemi hálózat is. A helyi
hálózat célja az adott fizikai helyen lévő eszközök közötti kapcsolat megvalósítása és igen gyakran
az Internet elérés biztosítása. Technológiát tekintve a helyi hálózatok leggyakrabban WiFi vagy
Ethernet megoldásokat alkalmaznak. Azon cégeket, akik az Internet elérést, mint szolgáltatást
biztosítják, ISP-nek (Internet Service Provider) nevezzük. Ezen szolgáltatók lehetnek globálisak,
lokálisak vagy regionálisak. A szolgáltatók a hálózataikat a forgalomkicserélő pontokban (IXP
- internet exchange point) kötik össze. Ilyen például a BIX (Budapest Internet Exchange point).
Az Internet nem más tehát, mint hálózatok hálózata, melyek egymással a világ különböző részein
lévő forgalomkicserélő központokban találkoznak. Az Internet maga nem központilag tervezett,
nincs egy olyan hatóság amely megmondaná, hogy ki kivel és hogyan kapcsolódjon össze, nincs
központja, nincs egy olyan hely ahol ki lehet kapcsolni, de ennek ellenére magán hordozza a
mérnöki tervezettség jeleit.
A különböző hálózatok mérete, anyagi lehetősége adottság, amely más területekhez hasonlóan
kialakítja a nagy, közepes és kis játékos (szervezet/cég) kategóriákat. Az ISP-ket is méretük,
képességeik szerint kategóriákba szervezzük: ezek a Tier1, Tier2 és Tier3 (1.4 ábra). A Tier1-es
szolgáltatók globális, gyakran transzatlanti kapcsolatokkal bíró hálózatok (1.3 ábra), ők egymással
a kölcsönös forgalomtovábbítás elve mentén gyakran pénzdíj nélkül kötik össze a hálózataikat.
A Tier2-es méretű hálózatok nagyobb méretű lefedettséggel bírnak de nem globális játékosok,
ők fizetnek a Tier1-es hálózatoknak a kapcsolatért és egymással vagy kölcsönösség elvén, vagy
ellentételezés mentén kötik össze a hálózataikat. A Tier3-as szolgáltatók érik el közvetlenül
a végfelhasználókat. Ők jellemzően a Tier2-es szolgáltatóktól vásárolják az Internet elérést,
1.4 A jövő 13
1.3: Óceánok alatti optikai kábelek
egymással jellemzően kölcsönösségi alapon kötik össze a hálózataikat. Ez a méretbeli szeparáció ad

egy hierarchikus felépítést az Internetnek, de ezen kategóriák nem ilyen vegytiszták, a mobilszolgáltatók
például Tier2 és Tier1-es szerepkörben is jelen vannak. Még tarkábbá teszik a képet a nagy
tartalomszolgáltatók (Google, Facebook, ...) akik mindhárom szinten megjelennek, de ide tehetjük
a SpaceX és más csapatok (cégek, szervezetek) által tervezett globális műholdas lefedettséget is.
1.4: Szolgáltató szintek1
1.4 A jövő
Az előzőekben ismertetett klasszikus hierarchikus elv már a tartalomszolgáltatókkal, azok saját
hálózataikkal jelentősen átalakult, de ezen átalakulások eltörpülnek a közvetlen műholdas utolsó
mérföld és gerinc hálózat okozta változások mellett. A napjainkban kiépülő hálózatok (pl.: (1.5
ábra)) több 10.000 műholdat terveznek alacsony (LEO - Low Earth Orbit kb. 300 km) pályára
helyezni. Ezek a műholdak nem csak a közvetlen hozzáférést adják a felhasználóknak, hanem
a forgalmat egymáson átjátszva, a közvetlen összeköttetést is, azaz gerinc hálózat funkciókat
is ellátnak. A hálózat használatához egyenlőre egy dedikált vevőegységre van szükség. Nem
használható közvetlenül a mostani mobil telefonokkal vagy laptopokkal, de jó eséllyel a dedikált
vevőt igénylő technikai akadályok elhárulnak és nemsokára új globális szolgáltatók jelennek meg a
mobiltelefonok piacán is.
1.5: Starlink műholdas hálózat
1.5 Kommunikáció
Az előző fejezetben láthattuk az Internet felépítését és az alapvető felbontását gerinc hálózatra és
hozzáférési hálózatra. Jelen fejezet célja e két rendszer működésének magasszintű áttekintése. A
kommunikáció megvalósításához erőforrásokra van szükség. Amikor például egy előadó előadást
tart a diákoknak, akkor kommunikációs közeg a levegő és 90 percig ő birtokolja ezt (azaz Ő beszél
a hallgatók hallgatnak), hogy elmondhassa a mondanivalóját. Itt a kommunikációhoz dedikált
erőforrást (a levegő az erőforrás és csak ő befolyásolhatja az állapotát) rendelünk. Számítógép
hálózatoknál az ilyen megoldást áramkör-kapcsolt (circuit switched) megoldásnak nevezzük
mert a kommunikáló feleknek a kommunikáció idejére garantáljuk a kommunikációhoz szükséges
erőforrást. Bár ezen megoldás jónak tűnik, de az adathálózatoknál, ahol az adat csomós (burst), a
lefoglalt erőforrások az idő nagy részében nem lennének kihasználva. Így a klasszikus telefonhálózatoktól
eltérően az adathálózatok (és ezen keresztül ma már gyakorlatilag minden szolgáltatás) csomagkapcsolt
(packet switched) és legjobb szándék szerinti (best effort) továbbításon alapul. A küldő tehát
elküldi a csomagot az első forgalomirányítónak, amely amennyiben tudja akkor továbbküldi, ha
nem, akkor kidobja. Ez első körben meredeknek tűnik, de erre a megbízhatatlan szolgáltatásra is
lehet megbízható szolgáltatásokat építeni (például a TCP segítségével). Itt még érdemes tisztázni
azt ,hogy miért nem tudja a csomagot továbbítani. Adott fizikai közegre épített adattovábbítási
csatornának megvan a maga átviteli kapacitása (ezt leggyakrabban bit / s-ban mérik), amennyiben
azonos időben több csomagot is ugyanarra a csatornára kellene továbbítani, úgy ütközés lép fel, ezt
az ütközést a forgalomirányító a beépített memóriája segítségével kezeli, ott egy várakozási sorban
rendezi a csomagokat. Amikor ez betellik, akkor adott algoritmus szerint eldob csomagokat. A
várakozási sorral a kapcsolathoz késleltetés is hozzáadódik (1.6 ábra)).
1.6: Csomagkapcsolás várakozási sor1
A helyi döntés meghozatalához globális információra is szüksége van a forgalomirányítónak. Mi

1.5 Kommunikáció 15
a legjobb útvonal, kinek küldje tovább a csomagot? Ennek megállapítása szintén leginkább itt
történik és a forgalomirányító forgalomirányító táblájában (routing table) tárolják. Ezen táblák
karbantartását végzik a forgalomirányító protokollok.
1.7: Forgalomirányító döntés 1
A helyi és a hozzáférési hálózat esetén a konkrét fizikai közeg megfelelő használata a legfontosabb
kérdés. A közeg megosztása a párhuzamos igények között számos módon megvalósítható. Az
ismertebb módszerek, időalapú, frekvencia alapú, kód alapú és tér alapú közeg megosztás. (TDMA,
FDMA, CDMA, SDM). A fizikai közeg ma gyakorlatilag az elektromágneses hullámokra korlátozódik.
1.8: TDMA és FDMA közegmegosztás
Amennyiben a hullámok terjedése adott közeg segítségével irányított, akkor vezetett hullámokról
beszélünk, egyéb esetben irányítatlan hullámokról. Az vezetett hullámok esetén fontos szerepe
van az optikai kábelek (optical cable) a koaxiális kábelnek(coaxial cable) és a csavart érpáras
kábelnek (twisted pair TP). Míg a koaxiális és a csavart érpár jellemzően a helyi illetve a
hozzáférési hálózatban fontos, úgy az optikai kábel a gerincek által használt fizikai médium.
Kedvező tulajdonságai miatt azonban az optikai kábel egyre nagyobb teret hódít a hozzáférési
hálózatokban is (FTTH - Fiber To Home). Optikai kábelek segítségével akár 100 km-es távolság is
áthidalható ismétlő, erősítő beiktatása nélkül. Az átviteli kapacitása is a terabit / s tartomány felé
halad a technológia fejlődésével. Optikai kábel nélkül nem létezne Internet. A csavart érpár variációi
(UTP Unshielded Twisted Pair) pedig szinte egyeduralkodók a helyi hálózatok kialakításában.
A vezetett hullámú összeköttetésnél nem gond a rádiófrekvenciás médium lefoglalása, mivel
ez nem lép ki a közegből. Ettől eltérő problémák lépnek fel irányítatlan közeg esetén, ahol
ugyanazt a közeget szeretné mindenki használni és az adás nem áll meg például az épület
falánál. Annak érdekében, hogy adott szolgáltatás minőséget biztosítani lehessen, az államok
1.9: Népszerű vezetett hullámú megoldások
szabályozzák a különböző elektromágneses frekvencia sávok hozzáférését. Vannak a licenc

köteles frekvencia sávok és vannak a szabadon hozzáférhető frekvenciasávok. A szabadon
hozzáférhető frekvenciasávok esetében a sávok megfelelő használatát adott protokollok valósítják
meg, ilyen például a WiFi vagy a BlueTooth. A licenszköteles frekvenciasávok esetén a legfontosabb
szolgáltatást nyújtó a 3G, 4G, LTE 5G mobil adathálózat elérést nyújtó rendszerek. Az eddig
tárgyalt szabad hullámú kommunikációs rendszereket földfelszíni rendszereknek nevezzük, mivel
a megvalósításukhoz nem szükséges földfelszíntől független elem. A másik nagy kategória
a műholdas kommunikációs rendszerek halmaza ahol a műhold pályájától függően további
kategóriákba lehet még osztályozni (LEO, MEO, . . . .). A műholdas rendszerek jelenleg leginkább
műholdas tv adás továbbításban játszanak szerepet, de rövidtávon meg fognak jelenni az olcsó
műholdas Internet Szolgáltató rendszerek is (lásd: 1.4 fejezet).
1.6 Számítógép hálózati szolgáltatások teljesítménymutatói

Mint ahogyan az előző fejezetekben láttuk, a számítógép hálózat számos különböző kommunikációs
közegre építhet és ezen közegeken számos különböző protokoll segítségével valósíthatja meg az
adattovábbítást. A felhasználói alkalmazás oldalon sem homogén a szolgáltatás igények halmaza
(szeretnénk videót nézni ahol fontos az, hogy kicsi egyen a késleltetés, de szeretnénk email-t is
küldeni, ahol csak annyi az igényünk, hogy érkezzen meg). Fontos tehát, hogy mérni tudjuk
a szolgáltatás minőségét - QoS (Quality of Service) ezekhez metrikákat rendeljünk. Egy
ilyen, a végfelhasználók számára könnyen értékelhető metrika az adattovábbítási képesség,
azaz két végpont között adott időegység alatt mennyi bitet, bájtot tud továbbítani a rendszer.
Ezt még szokták sávszélességnek (bandwidth) is nevezni (a távközlési háttérből) de áteresztő
képességnek (network throughput) is nevezik mértékegysége bit/s. Mivel a teljes adatút több
különböző képességű kommunikációs vonal sorba kapcsolt rendszere, ezért a leggyengébb láncszem
határozza meg adott kommunikációs útvonal áteresztő képességét. A sávszélesség folyamatosan
változó, mivel a fizikai közegek és a felhasználók száma, forgalma is dinamikusan változik. A
sávszélességtől jóval mélyebb tartalmú metrika a késleltetés (delay) amelynek a végpontok között
mért értéke a vég-vég késleltetés (end-to-end delay). Egy adott útvonal mentén a késleltetést az
alábbi részekből tevődik össze (jellemzően 300 ms alatt van egy irányban):
• terjedési késleltetés (propagation delay): adott közegen az elektromágneses hullám
terjedési sebessége, ez vég-vég késleltetésnél csak a transzatlanti kábeleknél és a nagy
magasságú műholdas átjátszásnál (GEO, MEO) ad hozzá jelentősen (×100ms)
1.7 Számítógép hálózatok gyakorlati felépítése 17
• átküldési késleltetés (transmission delay): ez az adott médium aktuális sávszélességétől

és az adatunk méretétől függ. Megállapítási módja (L/R - aktuális kapacitás / átviendő
adatmennyiség)
• várakozási sor késleltetés (queuing delay): a várakozási sorban jelentkezik amikor több
csomag is ugyanarra az interfészre megy és meg kell várni míg az előtte lévőket elküldi. Ez
a legváltozékonyabb mivel függ a forgalomtól.
• feldolgozási késleltetés (processing delay): az egyes továbbító pontokon jelentkezik ez
jellemzően konstans és nem jelentős a teljes késleltetéséhez képest (µsec nagyságrendű).
1.10: Csomagtovábbítás késleltetések1
Általában a csomagok megérkeznek de több oka is lehet annak, hogy ez mégsem következik be. A
csomagvesztés leggyakoribb oka a torlódás. Ilyenkor a forgalomirányító várakozási sora betelik
és a beállításától függően elkezdi a beérkező/várakozási sorban lévő csomagokat eldobni. Ez a
forgalom intenzitásától (traffic intensity) függ. A beérkező csomagok és a kibocsátó képesség
hányadosával szokták megadni (La /R). Amikor ez tartósan nagyobb mint 1, akkor elkezdődik a
várakozási sor betellése és a csomageldobása. Adott fizikai közegen is lehet akkora zaj, hogy a jel
nem érkezik meg, ezért fontos metrika még a csomagvesztési arány (packet loss ratio).

Az előzőekben láthattuk, hogy a számítógép hálózat egy igen komplex rendszer, gondoljunk bele,
hogy az okos órától kezdve a szerver farmokig mennyi különböző igény és kényszer jelenik meg. Az
ilyen komplex problémákat úgy lehet jól kezelni, ha részekre bontjuk őket. A részekre bontás egyik
módja a rétegekre bontás. Ekkor a rendszer szolgáltatásai a különböző rétegek együttműködésével
valósulnak meg, minden rétegnek jól meghatározott feladata van. Az együttműködés megadott
szolgáltatások segítségével valósul meg. Az alsóbb rétegek szolgáltatásokat nyújtanak a felsőbb
rétegek részére. Adott rétegben a konkrét szolgáltatásokat protokollok segítségével tudjuk leírni.
Egy-egy protokoll (pl.: HTTP, IMAP stb) precízen leírja az együttműködő felek feladatát, nem csak
a kicserélhető üzenetek szemantikája, szintaktikája, hanem ezen üzenetváltások hatására létrejött
állapottér formális leírásával is, ennek egy jó ábrázolási módja a véges állapot automata FSM
alkalmazása. Az egymásra épülő protokollok halmazát protokoll veremnek (protocol stack)
nevezzük.
A hőskorban a számítógép hálózatot alkotó rétegeket két csapat kezdte kialakítani, megtervezni.
Az egyik az ISO szervezet mely specifikálta az ISO-OSI modell-t (7 réteg) míg a másik TCP/IP
Internet modellt (5 vagy 4 réteg) kutatócsoportok alakították ki. Ezek nem csak modellek
voltak, hanem adott rétegek komplett megvalósításai (konkrét C, C++ kód szinten) is. A végén a
praktikusabb TCP/IP modell lett az elterjedtebb (mert ez az implementáció terjedt el). Az egyes
rétegek és feladataik (1.11 ábra) :
1.11: ISO OSI és TCP/IP referencia modell
• Alkalmazási réteg (Application Layer): itt találhatóak az alkalmazásokat megvalósító,

vagy azokhoz legközelebb lévő protokollok. Ilyen például a HTTP vagy az FTP. Ezen
protokollok a legtöbb esetben a végrendszereken futnak. A forgalomirányítók, kapcsolók
nem foglalkoznak velük. Az alkalmazás réteg az alatta lévő rétegnek (praktikusan a szállítási
rétegnek) üzeneteket küld. Az üzenetek tartalma nem az alatta lévő rétegnek szól, hanem a
kommunikációs vonal másik végén lévő alkalmazás rétegnek - társentitásnak.
• Megjelenítési réteg (Presentation Layer) (csak ISO-OSI modell): az üzenet tartalmának
az értelmezésében játszhat szerepet, ha ezt nem az alkalmazás réteg részeként kezeljük. Ilyen
lehet a például a HTTP felett átvitt tartalom MIME kódolása (jpeg, txt, ...).
• Viszony réteg (Session Layer) (csak ISO-OSI modell): kapcsolatok kiépítése, nyomonkövetése,
határ pontokkal ellátása, azonosítás, jogosultságkezelés lehetne itt megvalósítva. Ilyen
lehetne például a HTTP protokoll azonosítással foglalkozó része (HTTP Basic/Digest
Authentication).
• Szállítási réteg(Transport Layer) : Az előző protokollokhoz hasonlóan ez is a végrendszereken
érdekes. Az azonos végrendszeren futó processzusokat segít megkülönböztetni egymástól,
megcímezni őket (TCP/UDP port). Itt kaphat a kommunikáció kapcsolat orientált jellegű
szolgáltatás szintet (TCP). A szállítási réteg szegmensek formájában adja át az információt a
másik oldalon lévő társentitásnak.
• Hálózati réteg (Network Layer) : A réteg datagramok segítségével kommunikál a társentitással.
E réteg már kevesebb funkcióval bír a végrendszeren és ez az a réteg ahol a hálózati eszközök
leginkább érdekeltek. A réteg feladata egy világméretű hálózatban eljuttatni a datagramot a
kezdőponttól a végpontig. Az ehhez szükséges útvonal felderítése is ezen réteg feladata. Itt
a legelterjedtebb protokollok: IPv4 és IPv6, valamint az ezeket támogató forgalomirányító
protokollok.
• Adatkapcsolati réteg (Link Layer): A réteg célja a konkrét fizikai réteg elfedése és
azon magasabb szintű szolgáltatások megvalósítása. A társentitással keretek segítségével
kommunikál. Ilyen például az azonosítás, titkosítás, hibajavítás . . . Ismertebb protokollok:
Ethernet, WiFi, BlueTooth stb.
• Fizikai réteg (Physical Layer): Feladat a fizikai közeg és a bitfolyam közötti átjárás
biztosítása. Olyannal foglalkozik, mint feszültségszintek, frekvencia . . . A WiFi és egyéb
(adatkapcsolati és fizikai réteget átölelő) protokollok fizikai réteg függő specifikáció tartoznak
1.8 Számítógép hálózatok biztonsága 19
ide.
A különböző rétegbeli protokollok a szükséges információt a társentitásnak a felső protokolltól
kapott adatstruktúra kiegészítésével küldik el. A felsőbb rétegbeli adatot beágyazva, azt kiegészítve
hozzák létre a saját adat struktúrájukat (lásd a 1.12 ábrát).
1.12: Egymásra épülő rétegek és azonos szinten lévő rétegek együttműködése beágyazással1

A számítógép hálózat kezdetekben sziget-rendszerek voltak és később is a robosztusság volt a fő
tervezési szempont. Az adat titkossága, a másik oldal azonosítása nem volt elsőrendű probléma,
tervezési szempont. Ma azonban azzal, hogy az Interneten megjelenik a társadalom egésze,
ugyanolyan fontossá válik a számítógépes biztonság, mint a valós életben az ajtók zárása. Amíg a
fizikai biztonság a fizikai valóság miatt jól látható, érthető, felmérhető, addig az IT biztonság egy
jóval komplexebb kérdés. Az alapvető biztonsági problémák:
• Azonosítás: más tud a nevemben eljárni (pl.: banki utalás)
• Titkosság: adott információ más is megtudni (pl.: jelszavak)
• Szolgáltatás ellehetetlenítés: adott szolgáltatáshoz nem férek hozzá
Ezen alapvető támadás típusok általában komplex műveletsorok eredményei, melyekhez különféle
eszközöket lehet használni. A végrendszerek adott szintű hozzáférését kártékony programok
(malware) tehetik lehetővé. Ezen kártékony programokat a felhasználói közreműködés igénye
alapján vírusokra és férgekre tudjuk bontani. Férgek úgy tudnak végrendszereket fertőzni,
hogy nincs szükségük a felhasználói közreműködésére. A fertőzött gép tipikusan újabb fertőzés
forrása. A kártékony programokat nem csak terjedésük módja, hanem a tevékenységük alapján
is kategorizálni szokták. A 1.13 ábra egy rövid áttekintést ad a teljesség igénye nélkül. Egy-egy
konkrét program persze több tevékenységgel is foglalkozhat, így ezek inkább címkék mind
kategóriák. A trójai programok olyan egyébként ártalmatlannak tűnő programok melyek lefuttatása
után a gépen a tudtunk nélkül más programok is lefutnak. A hátsó ajtó a trójaiak egyik első lépése,
mely segítségével a géphez külső fél számára távoli elérést biztosít. A zsaroló programok a gépen
található adatokat titkosítják és csak adott összeg kifizetése után állítják vissza. A fertőzött gépeket
nem csak fertőzés forrásként, hanem egy nagy, a kártékony programok működtetői számára elérhető
infrastruktúrába szokták szervezni. Ezek a botnetek. A botnetbe kapcsolt gépek a felhasználó
tudta nélkül olyan tevékenységet folytatnak ami a felhasználóra nézve így vagy úgy kártékony
(jelszó gyűjtés, spam küldés...). Egy-egy nagyobb botnetben a fertőzött gépek száma összevethető
a Google szerverparkjával (több százezer gép).
1.13: Kártékony programok kategóriái

A mai számítógép hálózatok elméleti alapjait az 1960-as években rakták le. Az első elv a
csomagkapcsolás kidolgozása (Leonard Kleinrock) volt, mely akkor az időosztással használható
számítógépek elérését segítette. Az 1970-es években már létrejöttek az első számítógép hálózatok,
Vincent Cerf és Robert Kahn az ARPANET számára kidolgozta a hálózatok hálózata elvet, az
internettinget. Ennek alapvető elemei:
• minimalizmus, autonómia – a hálózatok összekötéséhez nem kell azok belső struktúráját
megváltoztatni
• legjobb szándék szerinti szolgáltatásmodell - nincs szolgáltatás lefoglalás, az erőforrások
sztochasztikus multiplexálással vannak megosztva
• állapotmentes forgalomirányítók - a protokollok nem számíthatnak a forgalomirányítók
állapotartására, így a forgalomirányítók bármikor újraindulhatnak, ez nem zavarja az utat
használó prokotokollokat
• decentralizált vezérlés - nincs központosított állapot, minden döntés, információ elosztott
algoritmusok eredménye
Jelen fejezet bővebb áttekintése [1] referencia könyv 1. fejezetében (29-107) található meg.

1. Írd le az Internet fontosabb építőelemeit, ezek rövid leírását
2. Írd le hálózat határt és az itt lévő fogalmakat példákkal: eszközök, hozzáférési hálózat fizikai
közeg
3. Írd le hálózat hálózat mag fogalmát és az itt lévő fogalmakat: Internet struktúra, csomag vs
áramkör kapcsolt
4. Hogyan mérhetjük a hálózati teljesítményt? Melyek a gyakorlati mérőszámok?
5. Írd le az Internet struktúráján motivációit, elvi felépítését.
6. Sorold fel az Internet protokoll verem 5 rétegét. Melyek az alapvető szolgáltatásaik?
7. Írd le azt a három alapelvet amelyen a mai Internet alapul (Kleinrock, Cerf és Kahn)
8. Sorolj fel 6 hozzáférési hálózati technológiát és csoportosítsd ezeket otthoni, vállalati, gerinc
osztályokba.
1.11 Irodalomjegyzék, további olvasnivalók 21
9. Sorold el a legnépszerűbb vezetékmentes hozzáférési technológiákat és vesd össze őket.

10. Milyen előnyei vannak a vonalkapcsolt megoldásnak a csomagkapcsolttal szemben?
11. Miért fog két egyforma szinten lévő ISP kapcsolódni egymáshoz?
12. Sorold fel azokat a képességeket amiket egy-egy réteg rendelkezhet? Lehet egy képesség
több rétegben is?
13. Melyik fertőzés önsokszorosító?
14. Mi a különbség a vírus és a féreg között?
15. Írd le a Botnet létrehozásának a módját és a DDos megvalósításának folyamatát

[1] Keith Ross (Author) James Kurose (Author). Computer Networking: A Top-Down Approach
(7th Edition. Pearson, 2016 (cited on pages 9, 20).
[2] Zaigham Mahmood. Fog Computing: Concepts, Frameworks and Technologies. Springer,
2018 (cited on page 10).
Tudás Képesség Attitűd Autonómia-felelősség

Érti a számítógép Különbséget tesz a Törekszik a Autonóm módon
hálózatok és az referenciamodellek számítógép alkalmazza a
Internet felépítését. (OSI, TCP/IP) hálózatokkal számítógép
Ismeri a hálózati között. kapcsolatos hálózatokkal
referenciamodelleket megfelelő kapcsolatos
(OSI, TCP/IP), fogalomhasználat fogalmak használatát
azok felépítését elsajátítására. megnyilatkozásaiban.
és működési elvét.
Ismeri az Internet
felépítését.
2. Hálózati biztonság

• A PKI (Nyilvános Kulcsú Titkosítás) ismeret nélkül egy egyszerű HTTPs kapcsolatot sem
lehet létrehozni.
• A biztonság ma már az egyik legfontosabb nem funkcionális követelmény.

Az előző fejezetben láthattuk, hogy a számítógép hálózatok elsődleges tervezési szempontja

a robosztusság és nem a biztonság volt. Jelen fejezet célja, hogy a komplex megoldásokban
alkalmazott konkrét technológiákat és azok képességeit megismerjük. A számítógépes hálózatok
biztonságának leírásánál leginkább a CIA (Confidentiality, Integrity, Availability) Titoktartás,
Integritás, Rendelkezésre állás dimenziók mentén szokták megadni. Ezek kifejtve:
• Titoktartás: adott információhoz csak a meghatározott kör férhet hozzá.
• Integritás: amennyiben az adatot valaki módosította akkor ezt tudjuk detektálni
• Rendelkezésre állás: a szolgáltatás folyamatosan vagy adott keretek között elérhető (pl.:
7x24 = a hét minden napján 24 órában)
A fenti követelmények teljesítése sohasem lehet tökéletes, egy rendszernek annyira kell biztonságosnak
lennie, hogy a feltörésére fordított erőfeszítés jóval nagyobb legyen mint az elvárható haszon.
Ezt szokták az ábrán látható módon az adott esemény bekövetkeztének valószínűsége és a hatása
alapján modellezett várható kockázattal jellemezni. Azt is figyelembe kell venni, hogy a biztonság-funkcionalitás-hasz
háromszögben nem lehet mindhárom tengelyt egy időben maximalizálni. A biztonság növelését
szabályok kidolgozásával és azok gépi vagy humán betartásával lehet növelni. Ilyen szabályok
lehetnek (a teljesség igénye nélkül):
• Hozzáférés vezérlési szabályok: azonosítja az erőforrásokat (pl.: fájl) és azok hozzáférését
leíró szabályokat
• Információ biztonsági szabályok: A dolgozók számára leírja a használható és tiltott
erőforrásokat (szoftvereket, gépeket...) és a szabályok megsértésének következményeit.
• Információ védelmi szabályok: Megadja az információ szenzitivitás szintjét, megadja hogy
kinek van joga adott szinthez hozzáférni. Definiálja azt is, hogy az adat hogyan van tárolva,
továbbítva és megsemmisítve.
24 2. fejezet - Hálózati biztonság
2.1: Biztonság-Funkcionalitás-Hasznosság
• Jelszó szabályok: leírja a jelszavak struktúráját, életútját és minden egyéb betartandó

szabályt a jelszavakkal kapcsolatban.
• Email szabályok: az email rendszer használatának szabályait írja le (pl.: mit szabad és mit
nem szabad emailben elküldeni)
• Információ audit szabályok: az adott szervezet biztonsági auditálási szabályait írja le, ki,
mikor, mit, hogyan,...
A fenti szabálylista közel sem teljes, a célunk csak az volt, hogy lássuk a probléma kezelésének
módját: a gépi és humán szereplőkkel egyaránt foglalkozni kell. Számunkra a szoftverekkel
kapcsolatos problémák lesznek érdekesek a továbbiakban. Egy rövid áttekintés a szoftverek/szoftver
rendszerek biztonsági problémáiról:
• Hibás konfiguráció: adott alkalmazás, vagy szolgáltatás hibásan lett konfigurálva (pl.:
elírtuk a konfigurációt olyan módon, amire a szoftver nem volt felkészítve)
• Alapértelmezett telepítés: itt minden konfiguráció ismert a külvilágnak, így a lehetséges
gyenge pontok is azonnal elérhetőek
• Puffer túlcsordulás: A konkrét kód hibája. Olyan memória területre történik írás ahova
nem lenne szabad és ezzel befolyásolni lehet a szoftver működését.
• Hiányzó javítások (patch): a feltárt biztonsági és egyéb hibákhoz kiadott javításokat nem
telepítették
• Tervezési hiba: vannak olyan szoftverkönyvtárak, amelyek a legtöbb operációs rendszerben
megtalálhatóak, ezek tervezési hibái (pl.: Intel processzorok sérülékenysége) általános
problémát jelentenek
• Operációs rendszer tervezési hibák: adott operációs rendszert érintő tervezési problémák
• Alkalmazás tervezési hibák: adott alkalmazást érintő tervezési hibák.
• Nyitott szolgáltatások: olyan szolgáltatások (futó programok Internet felé nyitott interfészekkel),
amelyekről esetleg nem is tudunk.
• Alapértelmezett jelszavak: a telepített alkalmazások alapértelmezett jelszavakkal jönnek,
ezek nem csak a telepítő számára ismertek.
A rendszerek biztonsági hiányosságait az alábbi lépések mentén szokták feltárni, rossz esetben
kihasználni (etikus hackelés is lehet). A legelső lépés a rendszer biztonsági felderítése. Itt a hacker
célja a rendszer aktív vagy passzív lenyomatának megismerése (milyen operációs rendszer). A
következő lépés a már adott információk alapján a konkrét rendszer hálózati elérhetőségeinek,
futó szolgáltatásainak feltárása. Ezen szolgáltatások lehetséges azonosítása (pl.: Apache web
szerver), ezekről egy lista készítése. Ezután a lista alapján meg lehet vizsgálni, hogy az azonosított
szolgáltatások milyen ismert biztonsági hiányossággal bírnak és ezeket ki lehet próbálni. Amennyiben
sikeres volt adott hiányosság kiaknázása akkor a behatoló célja egyrészt a hozzáférés tartós
biztosítása (pl.: adott beállítások megváltoztatásával, adott programok telepítésével), majd a nyomok
eltüntetése (pl.: napló fájlok törlése, meghamisítása). Mint láthattuk a betörés és a védekezés is egy
komplex folyamat, a lehetséges védelmi megoldásokat egyrészt a konkrét technológiákat taglaló
fejezetekben ismertetjük , másrészt a jegyzet végén egy dedikált fejezetben foglaljuk össze.
2.1 A kriptográfia alapjai 25
2.2: IT rendszer feltörés lépései
A következőekben a kriptográfia alapjait tekintjük át egy egyszerű modell segítségével. A

modell szereplői Árgyélus királyfi és Tündérszép Ilona akik szeretnének úgy beszélgetni egymással,
hogy a harmadik fél (Vénbanya) ezt ne tudja megérteni, illetve ha módosítja a kommunikációt (pl.:
átírja az üzetenet) akkor ezt észreveszik a kommunikáló felek. A Vénbanya az alábbiakat teheti
meg:
• Lehallgathatja az üzeneteket
• Meghamisíthatja az üzeneteket
• Beszúrhat üzeneteket
• Törölhet üzeneteket
Árgyélus királyfi és Tündérszép Ilona csak ezt a csatornát használhatja kommunikációra, nincs más
biztonságos csatornájuk.
2.3: Biztonsági probléma rendszer modell

Árgyélus királyfi és Tündérszép Ilona problémájával tehát a kriptográfia foglalkozik. Árgyélus
királyfi és Tündérszép Ilona feladata egy olyan eljárás alkalmazása amely segítségével úgy alakítják
át az üzeneteiket, hogy a folyamatosan figyelő Vénbanya ne legyen képes ezeket megérteni. Itt két
megközelítésük lehet:
• csak ők ismerik az eljárást amit alkalmaznak és ez akadályozza meg Vénbanyát hogy megértse
• az eljárás nem titkos, Vénbanya nyugodtan megismerheti, de az eljárásban használt adatok
egy része a titok (pl.: a kulcsok)
A 19. században Auguste Kerckhoff, az azóta Kerckhoff elveként ismert tételt fogalmazta
meg:
Fontos A titkosító metódust nem szabad titokban tartani, az nyugodtan az ellenség kezébe
kerülhet. A titkosság csak a kulcs titkosságán kell, hogy múljon.
Az érvek ezen elv mellett:

• A kommunikáló feleknek sokkal egyszerűbb egy rövid kulcsot titokban tartani, mint egy
jóval nagyobb adatmennyiséggel bíró algoritmust/programot.
• Minden kommunikáló félnek más-más algoritmust kellene alkalmaznia (gondoljuk el egy

cégnél, hogy minden kommunikáló fél más algoritmust használ).
• Ha mégis kiszivárog az algoritmus akkor egyszerűbb egy kulcsot kicserélni mint egy egész
programot.
Ma a kriptográfiában azt tekintik biztonságosnak, ha maga az algoritmus és megvalósítás is ismert,
mindenki számára elérhető, megnézhető. Azon megoldások, ahol adott cég az algoritmusát nem
hozza nyilvánosságra, nem tekinthetőek kellően biztonságosnak. Árgyélus királyfi és Tündérszép
2.4: Rejtjelezés alapelemei
Ilona számára tehát a nyilvános algoritmus és titkos kulcs jelenti a járható utat. A probléma
amivel szembesültek nem új. Ehhez azonban néhány alapfogalommal meg kell ismerkedniük.
Szabadszövegnek (cleartext) nevezzük (“m” a lenti képletben) a titkosítandó információt. Titkosító
eljárás (cipher) az az eljárás, amivel a szabad szöveget titkosított szöveggé (ciphertext) transzformáljuk.
A kulcs (key) az az információ (KÁ és KTI ), amely a titkosító eljárásnak meg kell adnunk a
titkosításhoz illetve esetenként a visszafejtéshez. A titkosított adat visszafejtését a visszafejtő
(decrypter) végzi el.
Fontos Amennyiben a titkosító és a visszafejtő kulcs azonos KÁ (KÁ (m)) = m akkor szimmetrikus
kulcsú titkosításról beszélünk egyébként aszimmetrikus kulcsú titkosításról KTI (KÁ (m)) = m..
A különböző algoritmusok bemutatását egy egyszerű Julius Cesar-hoz kötődő algoritmussal

kezdjük. A szabad szöveges bemenet minden betűjét cseréljük ki a k kulcs által megadott
távolságban lévő betűre.
Formális leírása: DecK (c1 ...cl ) = m1 ...ml , aholmi = [(ci − k)mod26]
Nehéz ezt feltörni? Elegendő az összes kulcsértékre (ez ABC függő, az angol ABC-re ez
26) megvizsgálni a visszafejtett szöveget és ami értelmesnek tűnik, az a megoldás. Ezt a feltörés
megközelítést nyers erő (brute force) támadásnak nevezzük. Ekkor a kulcstér szisztematikus
végigjárásával próbálja a támadó megtalálni a kulcsot. Ez alapján egy fontos alapvetés az elégséges
kulcstér elv (sufficient keyspace principle).
Fontos Egy titkosítási eljárásnak elégséges kulcsteret kell biztosítania annak érdekében, hogy
a nyers erő támadások ne legyenek megvalósíthatóak.
Ma a felhő és GPU korszakában ez 1030 nagyságrendű. Ha úgy módosítjuk Caesar algoritmusát,

hogy a K kulcs egy az ABC tetszőleges permutációját jelentő betű sorozatot alakít ki, és az egyes
helyeken e betűsorozat elemeit helyezzük be adott pozícióba, akkor jóval nagyobb kulcsteret kapunk.
26! azaz 1026 nagyságrendű lehetséges kombinációt kellene végigvizsgálni. A fent leírt algoritmust
nevezik mono alfebetikus helyettesítő titkosítónak (mono alphabetic substitution cipher). A
kulcstér szempontjából ez már biztonságos, de mint algoritmus, még nem az. Amennyiben a szöveg
2.5: Ceasar titkosítása
például angol nyelvű anyag, akkor az angol nyelvben ismert karakter gyakoriságok segítségével
megbecsülhetjük az egyes helyettesítő karaktereket.
2.6: Az angol nyelv betűinek gyakorisága
A titkosított tartalom elleni támadások az alábbi megközelítéseket alkalmazhatják:

• csak a titkosított szöveg áll rendelkezésre (ciphertext only): ekkor a fentiekben is látott
információval bír a támadó, azaz csak a titkosított szöveget látja, nincs egyéb támpontja
• ismert a titkosított szöveg alapú támadás (known plain text attack): ekkor a támadó
ismeri a szabad szöveget, így megpróbálhatja megtalálni a transzformációt, kulcsot
• kiválasztott szöveg alapú támadás (chosen plain text attack): ekkor a támadó nem csak
tudja, hanem befolyásolni is tudja a titkosítandó szöveget
Az előző algoritmus a gyenge pontja okozta problémákat a poly alfabetikus helyettesítő titkosító
(polyalphabetic substitution cipher) oldja meg úgy, hogy nem karaktereket, hanem szövegblokkokat
helyettesít szövegblokkokkal. Ezzel el is jutottunk a napjainkban is alkalmazott eljárásokhoz. Mi
lehet a jó titkosítás ismérve? Elegendő, ha nem tudjuk visszafejteni a kulcsot? Nem, mert adott
minta transzformációkkal a titkosított tartalom egy része visszafejthető. Elegendő ha a támadó nem
képes a teljes szabad szöveget visszanyerni? Nem, mert adott esetben a szöveg 10%-ának ismerete
sem megengedhető. Elegendő ha nem tud karaktereket visszafejteni? Nem, mert a struktúra
megmarad és például a fizetés rész hossza utalhat a fizetés nagyságára.
Fontos A jó titkosítás ismérve az, hogy attól függetlenül, hogy a támadó milyen információval
bír, semmilyen újabb információhoz sem juthat a szabad szöveggel kapcsolatban.
A mai szimmetrikus kulcsú titkosítási eljárásokat blokk alapú titkosítás (block cipher) és folyam
alapú titkosítás (stream cipher) eljárásokra bonthatjuk. A blokk alapú eljárások, mint láthattuk,
blokkokat helyettesítenek blokkokra. Ilyen látható az ábrán. k=3 a kulcshossz, 3 bites blokkokat
cserélnek 3 bites blokkokra. Ezen eljárás k=3 értékkel nehezen tekinthető biztonságosnak, hiszen a
kulcstér 23 azaz 8 szimbólumból áll, ezek kombinációja 8! azaz 40230 variáció. Egy naiv javítási
2.7: Blokk titkosítás1
megoldás lehetne, hogy 3 bites blokkok helyett például 64 bites blokkokat alkalmazunk, ekkor
már 264! a kulcstér. Ezzel a megoldással az a gond, hogy itt a két kommunikáló félnek egy 264
méretű táblát kellene kezelnie. Ehelyett a blokk titkosítók olyan funkciókat használnak, amelyek
véletlenszerűen permutált táblákat (randomly permuted table) szimulálnak. A 2.8 ábrán egy
ilyen látható. A 64 bites bemenetet 8 bites részekre bontják és ezekre alkalmazzák a helyettesítést
- külön-külön táblákkal(8 x 28 méretű tábla már kezelhető méretű). Ezután a 8 bites elemeket
összefűzik egy 64 bites elembe, ahol ezután az egyes pozíciókat permutálják a 64 bites kimenethez.
Ezzel a kimenettel kezdik a következő kört. N ciklus után előáll a helyettesítő 64 bites blokk. A
ciklusok célja az, hogy minden bitnek legyen hatása minden kimenő bitre. Itt az algoritmus ismert,
a kulcs a csak két fél által ismert 8 db táblázat.
2.8: Véletlenszerűen permutált tábla1
A fenti elvet alkalmazzák napjaink ismert szimmetrikus titkosítás alapú algoritmusai, ilyen a
DES (Data Encryption Standard), 3DES, AES (Advanced Encryption Standard). Táblázatok
helyett mindhárom algoritmusban ilyen függvényeket alkalmaznak. A DES 64 bites blokkokkal
és 56 bites kulcsokkal míg az AES 128 bites blokokkal és 128, 192 vagy 256 bites kulcsokkal
dolgozik. Az 56 bites kulcsot 2011-ben akkori infrastruktúrával sikerült feltörni (internet szinten
összeadott erőforrásokkal). Az AES 128 bites és nagyobb kulcsterű algoritmusait ez a veszély
még nem fenyegeti (több milliárd év ezzel a megközelítéssel). Ezen eljárások alkalmasak egy-egy
önálló állomány titkosítására. Vannak olyan esetek azonban amikor egy hosszabb adatfolyamatot
kellene titkosítani. Ilyenkor a naiv megközelítésmód, hogy bontsuk azt adott hosszúságú részekre
és azokat külön-külön titkosítsuk az adatfolyam struktúrájának megismerésének veszélyét rejtheti
magában. Ha például két egymást követő adatdarab is csak üres karaktereket tartalmaz, akkor ez a
titkosított állományban is megfigyelhető (az, hogy a két egymást követő adat blokk azonos). Ezen a
problémán segítenek a rejtjeles blokkok láncolása (cipher block chaining) megközelítések. Az
ötlete az, hogy adott véletlenszerűséget viszünk a bemeneti szövegbe annak érdekében, hogy az
identikus bemeneti blokkok ne adjanak identikus kimeneti blokkokat. Egy egyszerű algoritmus:
m(i) = Ks (c(i) × r(i)), ahol m(i) az i. jelzi, hogy az adatfolyam melyik elemével foglalkozunk,
Ks a szimmetrikus titkosító, c(i) az eredeti szöveg adott blokkja, míg r(i) egy minden blokkhoz
külön legyártott véletlen szám. E megoldásnál Tündérszép Ilona az m(i) mellet az r(i)-t is átküldi
a Árgyélus királyfinak. Ez már jó megoldásnak tűnik, de Tündérszép Ilonának még dupla annyi
adatot kell átküldenie (m(i), r(i)). Ezt kiküszöbölendő egy véletlen számot fog csak átküldeni ez
az inicializáló vektor (Initialization Vector) - IV. A két oldal ezen IV számsorozat segítségével
minden egyes blokkhoz kiszámítja az aktuális véletlen számokat. Ezzel az algoritmussal fogunk a
WiFi WEP titkosításánál találkozni.
Az eddigiekben áttekintett rejtjelező algoritmusok a szimmetrikus kulcsú rejtjelezők osztályába
tartoztak. Számos biztonsággal kapcsolatos problémát tudnak megnyugtató módon kezelni, egyet
kivéve, ez pedig a két fél között a közös kulcs elosztása. Az 1970-es évekig erre számos fizikai
megoldás létezett. Caesar idejében például a fürdőben beszélték meg egymással. Belátható, hogy
a mi modellünk esetén ez nem igazán megoldható, hiszen a harmadik fél minden üzenetváltást
lát. Ezen a problémán segített a Diffie-Hellman kulcscsere algoritmus, amely elvezetett az
aszimmetrikus kulcsú (asymmetric key), vagy nyilvános kulcsú (public key) titkosításhoz. Itt
2.9: Asszimmetrikus kulcsú titkosítás
egy kulcs helyett kettők alkalmaznak. Az 2.9 látható Árgyélus királyfi titkos (private) KÁ− és
nyilvános (public) kulcsa KÁ+ Tündérszép Ilona megkapja Árgyélus királyfi publikus kulcsát, ez
mindenkinek hozzáférhető. Ezzel a kulccsal titkosítja az m üzenetet KÁ+ (m). Ezt Árgyélus királyfi
a saját titkos kulcsával fejti vissza KÁ− (KÁ+ (m)) = m. Számos algoritmus ismert, amely a fenti
képességeket biztosítja, de a legelterjedtebb az RSA (az alkotói után kapta a nevét Ron Rivest, Adi
Sharmin, Leonard Adleman).
Az algoritmus a moduló aritmetikán alapul, alapvető összefüggések:

[(a mod n) + (b mod n)] mod n = (a + b) mod n,
[(a mod n) − (b mod n)] mod n = (a − b) mod n, (2.1)
[(a mod n) · (b mod n)] mod n = (a · b) mod n
Ezekből levezethető:
(a mod n)d mod n = ad mod n (2.2)
Az RSA algoritmus az alábbi lépésekből áll:
• Válasszunk két nagy p és q prím számot (1024 bites nagyságrendűt)
• Számítsuk ki n = p · q és z = (p − 1) · (q − 1) számokat
• Válasszunk ki egy e számot amely n-től kisebb és nincs közös osztója z-vel.
• Keressünk egy d számot úgy hogy e · d − 1 osztható legyen z-vel (e · d mod z = 1)
• A publikus kulcs (KÁ+ ) az (n, e) számpár, a privát kulcs KÁ− az (n, d) számpár.
• Tündérszép Ilona titkosítási eljárása: c = m · e mod n
• Árgyélus királyfi visszafejtési eljárása: m = c · d mod n
A fenti eljárás tehát megoldja a kulcselosztás problémáját, de komoly gond vele, hogy szemben
a DES és AES egyszerű, hardverben jól implementálható műveleteihez itt komoly aritmetikai
műveletek vannak. A DES például 100-szor gyorsabb szoftveresen, míg hardverben megvalósítva
10.000-szer gyorsabb. Vegyük észre, hogy itt nem feltétlenül a késleltetés jelenti a gondot, hanem
az azonos erőforrás igény mellett használható nagyobb kulcs, ami pedig, mint láttuk, az eljárás
feltörhetőségét jellemezni. Így az aszimmetrikus kulcsú titkosítást a viszonykulcs (session key)
KS átvitelére használják. A viszonykulcs egy jellemzően egyszer használatos szimmetrikus kulcs
amelyet a két oldal közösen vagy egyik oldal egyedül hoz létre.

Az előző részben áttekintettük azokat az építőkockákat, amelyek mentén konkrét szolgáltatásokat
lehet létrehozni. Az első ilyen az üzenet integritás (message integrity), amely két konkrét képességet
igényel:
• Tudjuk validálni, hogy az üzenet valóban a feladótól származott
• Tudjuk validálni azt, hogy az üzenet valóban azt tartalmazza amit elküldtek, azaz vegyük
észre ha valaki módosította az üzenetet
Egy praktikus, eddig nem említett eljárás a kriptográfiai kivonat függvény (cryptographic hash
function). Egy ilyen eljárásnak biztosítani kell, hogy adott x és y esetén számítástechnikailag
nagyon nehéz legyen ilyen párokat képezni: H(x) = H(y). (Azaz ha ismert egy kivonat, akkor ne
tudjunk hozzá egyszerűen olyan számot találni, amely ugyanezzel a kivonattal bír) Ilyen eljárás az
2.10: Kivonatoló eljárás
volt sokáig MD5 amely 128 bites kivonatot készített, ma az SHA-1 et tartják biztonságosabbnak
(bár ezt is feltörték már), amely 160 bites kivonatot készít. Az üzenet integritásának ellenőrzésére
alkalmas az üzenet azonosító kód (MAC message authentication code). Ez esetben Tündérszép
Ilona és Árgyélus királyfi az alábbi lépéseket teszi meg:
2.2 Üzenet integritás, digitális aláírás 31
• Az üzenetet és egy titkos kulcsot - azonosító kulcs (authentication key) összefűzi és ezt
kivonatolja H(m + s)
• Tündérszép Ilona átküldi az üzenetet ( m ) és a MAC kódot H(m + s)
• Árgyélus királyfi ismeri az azonosító kulcsot, ezért ő a megkapott üzenetből elő tudja állítani
a H(m + s) kivonatot és amennyiben ez megegyezik a megkapott H(m + s)-sel, akkor az
üzenet nem lett megváltoztatva és Tündérszép Ilona küldte (mert csak ő ismeri s-t).
A fenti eljárás már működőképes, de az s elosztása továbbra is gond. Ezt a problémát oldja
meg a digitális aláírás (digital signature). Az előző eljárás annyiban módosul, hogy a kivonatot
2.11: Kivonatoló eljárás
Árgyélus királyfi a saját privát kulcsával titkosítja és azt mindenki vissza tudja fejteni akinek
megvan Árgyélus királyfi nyilvános kulcsa. Itt már csak az lehet a probléma, hogy honnan
tudjuk azt biztosan, hogy adott nyilvános kulcs valóban Árgyélus királyfié-e. Ebben viszont segít
a digitális tanúsítvány (digital certificate). Ennek a segítségével adott megbízható szervezet,
Tanúsító Hatóság (Certification Authority) biztosít bennünket arról, hogy adott publikus kulcs
adott személyhez tartozik. Az elv ugyanaz, mint a digitális aláírásnál, csak most a tartalom arról
2.12: Digitális tanúsítvány
szól, hogy adott publikus kulcs adott személyhez tartozik-e és ezt a tartalmat látja-e el digitális
aláírással a szervezet. Ennek egyik szabványos formája az X.509-es tanúsítvány. Honnan tudjuk,
hogy a tanúsító hatóság nyilvános kulcsa valóban az, amit megkaptunk? Egyrészt, mert az ezeket
leíró digitális tanúsítványok fel vannak töltve a használt operációs rendszerekbe, másrészt ezen
tanúsítvány biztosító hatóságok egy hierarchia mentén továbbadhatják a tanúsítványikadási jogot.
Ilyen digitális tanúsítványokat alkalmaz a HTTP alatt lévő TLS protokoll is, ettől lesz HTTPS. A
CA hierarchia a 2.13 ábrán látható. Az első két szinten online nem elérhető hatóság van annak
érdekében, hogy a privát kulcsok semmiképpen se szivárogjanak ki. A harmadik szint az operatív
(ő az aki üzemszerűen fogad igényeket), ahonnan további tanúsítványkiadó szintek nyílnak, de
2.13: Tanúsító hierarchia
persze normál tanúsítványokat is kiadnak. A következő táblázat az X.509 tanúsítvány főbb mezőit
foglalja össze. Amennyiben itt saját magunk által aláírt tanúsítványokat használunk, akkor az
2.14: X.509 tanúsítvány fontosabb mezői
közbeékelődéses támadásnak (man in the middle) lehet kitéve a kapcsolatunk, mivel ekkor a
másik oldalnak nincs lehetősége ezt egy független forrással validálni, így azt sem veszi észre,
hogy beült valaki a kommunikációs csatornába és kicserélte a tanúsítványt egy olyanra, ami
közbeékelődőé. Ezt a kommunikáló felek nem veszik észre.
2.15: Közbeékelődéses támadás (man in the middle)
Fontos A PKI tehát csak a tanúsítvány biztosító hierarchiával együtt nyújt megfelelő
biztonságot.
Jelen fejezet bővebb áttekintése a referencia könyv [2] 8. fejezetének 621-641 közötti részén
található meg. Egy mélyebb áttekintés például a [1] könyvben érhető el
2.3 Ellenőrző kérdések 33

• Ismertesd a hálózati biztonság alapvető igényeit és az alapvető támadási formákat!
• Ismertesd a szimmetrikus titkosítás alapjait, milyen problémák merülnek fel?
• Ismertesd a nyilvános kulcsú kriptográfia RSA verziójának alapjait!
• Ismertesd az üzenet integritás, azonosítás esetén felmerülő problémákat és megoldásokat!
• Ismertesd a man-in-the-middle támadást és ennek kezelését adó digitális tanúsítvány koncepciót!

[1] Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno. Cryptography Engineering: Design
Principles and Practical Applications. Wiley Publishing, 2010. ISBN: 0470474246 (cited on
page 32).
(7th Edition. Pearson, 2016 (cited on page 32).

Tisztában van a Elemzi saját Kritikusan szemléli Önálló javaslatokat
hálózati biztonság hálózatainak a hálózatok fogalmaz meg a
alapvető igényeivel biztonságát. biztonságát. biztonság növelése
és támadási érdekében.
formákkal. Ismeri a
kriptográfia alapjait.
3. Alkalmazás réteg

• Ma a legtöbb alkalmazás HTTP protokoll segítségével éri el háttérrendszert.
• Ma a legtöbb alkalmazás REST elvek alapján fér hozzá azt erőforrásokhoz.
• Ma a legtöbb alkalmazás OAuth 2 alapú azonosítást, erőforrás hozzáférés vezérlést
használ.
• A DNS az első pont a terhelés elosztásra.

Az Internet sikere az alkalmazások sikerében rejlik. Minden időszaknak megvoltak azok az

alkalmazásai amelyek sikere további területek bevonására ösztönözte a fejlesztőket. Az első
időszakban (1970-1980) a nagyszámítógépek távoli elérése, az email és a hír csoportok voltak az
ú.n. killer alkalmazások. A 1990-es években megjelent a WWW az üzenetküldés és P2P fájlcsere.
A 2000-es években a Google használhatóvá tette a keresést, majd a Facebook megváltoztatta
a kommunikációt. Ma a legnagyobb forgalmat az online videó platformok bonyolítják lassan
kiszorítva a klasszikus TV csatornákat. A fejezet követi a [3] könyv struktúráját esetenként attól
jóval részletesebben tárgyal területeket (pl.: HTTP) míg más esetben a [3] könyv 2. fejezetében
(111-212) van bővebb leírás (pl.: IMAP, POP3) ezért javasolt e témakör esetén is referencia könyv
átolvasása is.

Az alkalmazások architektúráját és futtatási környezetét alapvetően befolyásolta az okostelefonok
drasztikus elterjedése. 2019-ben a mobil felhasználók száma átlépte az ötmilliárdot. Így az
Internet és hálózati alkalmazás fogyasztás/alkalmazás elsődleges platformja a mobiltelefon lett.
A felhasználás célterülete is az egyéniből a csoportos kommunikáció felé, az ezt biztosító nagy
felhő szolgáltatások felé tolódott el. Ezen felhő alapú kiszolgálók hatalmas adatközpontokat
működtetnek, amelyeket igyekeznek egy-egy piachoz közel elhelyezni. Az adatközpontok felett
futó infrastruktúrájuk segítségével tudnak több százmillió felhasználót kiszolgálni. A felhő alapú
megoldások létrejöttét az Internet elterjedése tette lehetővé, ma már az Internet közmű bármikor,
36 3. fejezet - Alkalmazás réteg
3.1: Az Internet rövid története
3.2: Mobil felhasználók számának változása
bárhol elérhető. Erre a közműre lehet építeni olyan szolgáltatásokat ahol adott infrastruktúrát
bérelhetünk és csak annyit fizetek, amennyit ebből felhasználtunk. A felhő alapú számítástechnikai
infrastruktúra is egyfajta közmű lett.
Fontos A felhő lényege az, hogy a felhasználók önkiszolgáló jelleggel tudnak virtuális
erőforrásokat bérelni (pl.: virtuális gép, adatbázis, telefon teszt farm...) amelyet használat alapon
fizetnek ki.
A szoftverfejlesztés tehát két célkörnyezetben fut. Az egyik a felhő, a másik a mobiltelefon.

Az erőforrásmegosztás paradigmája mentén ez a kliens - szerver architektúra alkalmazását
vetíti előre. A másik jellemző architektúra a P2P architektúra amelynél nincs alá - fölé rendelt
szerepkör, hanem minden résztvevő erőforrást oszt meg és vesz is igénybe. A P2P architektúra
felhasználásával lehet igazán robusztus, hibatűrő megoldásokat létrehozni. A Google például a
több százezer gép index táblájának konzisztenciáját egy P2P szavazás alapú algoritmussal valósítja
meg. De ilyen P2P megoldások a hálózati rétegben a tantárgy során a későbbiekben ismertetett
forgalomirányító algoritmusok is. Azt fontos kiemelni, hogy mindkét paradigma esetén a hálózati
alkalmazások futtatása leginkább a végrendszerek feladata, maga a hálózati infrastruktúra
általában transzparens, azaz nem foglalkozik az alkalmazás réteggel (SDN esetén később látjuk,
hogy erre azért van mód).
A fejlesztő számára úgy a felhőben, mint a mobiltelefonon vagy egyéb futtató platformon (okosóra,
okos hűtő...), adott futtatási környezet áll rendelkezésre. Ez a környezet határozza meg, hogy
3.2 WWW 37
a program milyen erőforrásokat és hogyan érhet el. Egy ilyen alapvető környezet a különböző
operációs rendszerek által biztosított futtatási környezet. Itt a különböző alkalmazásokat és azok
futtatott példányait processzusokba (process) - futtatott példányokba - csomagolja a környezet.
Ezen példányok saját memóriával bírnak és ezek szeparálása, menedzsmentje az operációs rendszer
feladata. A programok egy alapvető építőeleme tehát a processzus (adott esetben pl.: IOS
programozás, ahol ez nem látható, de ott is ez az alapegység).
Az előzőekben láthattuk, hogy a hálózat rétegekre bontható és ezen rétegekben adott protokollok,
illetve ezek halmaza, a protokoll verem biztosítanak adott szolgáltatásokat. Ezen protokollok a
szoftverfejlesztő számára gyakran csőszerű interfészt biztosítanak. Az egyik oldalon belerakja
a csőbe az adatokat, a másik oldalon pedig kiszedi ezeket. Egy ilyen alapvető alacsony szintű
interfész a szoftvercsatorna (socket). A szoftvercsatorna lehetővé teszi a processzus - processzus
kommunikációt azzal, hogy a gépen túl a processzus is azonosítja és biztosítja a cső absztrakciót.
A cső absztrakció szolgáltatás szintje különböző lehet, mivel az alkalmazások is különböző
3.3: Alkalmazások és a hálózat viszonya1
igényekkel léphetnek fel. Az alapvető metrikákat már tárgyaltuk, ezek a csomagvesztés, átviteli
kapacitás és a késleltetés. A táblázat néhány alkalmazás igény mátrixát ábrázolja. Ebben nincs
szerepeltetve több, olyan fontos dimenzió mint például a biztonság és ennek metrikái, vagy az
energiahatékonyság és ennek metrikái.
A továbbiakban néhány szakmailag vagy didaktikailag fontos alkalmazás rétegbéli protokollt
fogunk áttekinteni.
3.4: Alkalmazások minőségi igényei
3.2 WWW
A legfontosabb protokoll család, a legtöbb mai alkalmazás alapja. A telefonok az itt specifikált
protokollal (HTTP) érik el a szervereket, maga a telefonon futó szoftver felhasználói interfésze
pedig gyakran a szintén itt specifikált felhasználói felületet leíró nyelvvel van megadva (HTML).
Az egyes szerveren lévő erőforrásokat pedig a szintén itt specifikált címzési módszerrel (URI)
címezi meg. A World Wide Web egy igaz sikertörténet, az 1990 évek elején Tim Berners-Lee
specifikálta az alapelveit és ezen alapelvek mentén az architektúráját és ennek alapelemeit. Az
ötlete az volt, hogy a hálózaton publikált tartalmakat (erőforrásokat) a megjelenítésre koncentráló

nyelv - hypertext segítségével dinamikusan összeollózhatóvá teszi. Minden tartalom marad a maga
helyén, a hypertext csak hivatkozik ezekre. A W3C konzorcium és az IETF által fejlesztett és
3.5: WWW elemei
szabványosított WWW egyik forradalmi újítása az erőforrások címzési módszerének kialakítása volt.
Ennek alapja az URI (Uniform Resource Identifier), ennek segítségével különböző területeken
(telefon, gps, SSBN...) globálisan egyedi azonosítókat lehet létrehozni. Az URI specializált verziói
3.6: URI példák
az URL (Uniform Resource Locator), mely a fenti ábrán is látható, vagy az URN (Uniform
Resource Name) és más ebből származtatott azonosító. Ezek napjaink szoftverfejlesztésben igen
fontosak, Android program fejlesztése esetén például a fent látható “tel: xxx“ minta alapján lehet
a telefonhívást, szolgáltatást (intent) kérni a rendszertől. Az URL lehetővé teszi élő, elérhető
erőforrások megcímzését. Ezen erőforrások elérésében segít a HTTP protokoll.
3.2 WWW 39
3.2.1 HTTP 1.1 alapok

A HTTP (HyperText Transfer Protocol) egy állapotmentes protokoll, mely adott parancshalmaz
segítségével lehetővé teszi az URL-lel azonosított erőforrások manipulációját. Ez a leggyakrabban
az erőforrás adott reprezentációjának betöltését jelenti (GET). Stabilitására jellemző, hogy az első
verziótól (0.9 -1991) kezdve a ma elterjedt (1.1 1999) verziója óta csak napjainkban merültek fel
komolyabb kiterjesztési, megújítási igények (2.0-2015, 3.0-2020). A protokoll a kliens szerver
paradigma mentén lett kialakítva: a kliens erőforrásokat kér a szervertől, aki ezeket biztosítja.
Mivel a robosztusság volt az egyik legfontosabb tervezési szempont, ezért a protokoll nem
feltételezi a szerver állapottartását. A szerver bármikor összeomolhat vagy újraindulhat, a
kliens nem várja el, hogy emlékezzen az előzőekben végrehajtott tranzakciókra (van GET de nincs
GETNEXT parancs). Ettől függetlenül a szerveren természetesen van perzisztens tárolás, csak a
protokoll erre nem épít. A kliens és a szerver közötti kommunikáció:
• A kliens kérést küld a szerverre (request)
• A szerver a kérdésre választ küld (response)
A kérés és a válasz is 3 részből áll, melyek szöveges ASCII elemekből állnak.
• Kérés /Válasz sor - Itt küldi el a kliens a parancsot és a parancshoz tartozó erőforrás címet,
a szerver itt válaszol egy állapotkóddal
• Fejlécek - céljuk olyan, a konkrét tartalomtól független ú.n. keresztülívelő információk
(cross cutting issue) átvitele mint az azonosítás, a konkrét szerver, böngésző típusa stb.
• Törzs - Itt van a kért információ, kérés esetén itt küldheti el a kliens a feltöltendő adatot
(POST)
A HTTP kérésben a kliens biztonságos (nem végez módosítást), idempotens (többszöri futtatása
is ugyanazt az eredményt adja) és nem idempotens parancsokat tud elküldeni (egy kérésben
egyet).
3.7: HTTP kérés, parancsok
3.2.2 HTTP Gyorsítótárazás, CDN

Egy nagyon fontos képesség a HTTP protokollban az, hogy a válasz gyorsítótárazható (cacheable).
A kommunikációs útvonal mentén lehetnek olyan eszközök, amelyek a HTTP forgalmat értik, a
tartalmat eltárolják és a cél szerver helyett ők válaszolnak a kérésre (analógia a főnök helyett
a titkárnő). Ilyen szerepkört tölthet be a böngésző is, ahol ha már egy kérésre ismert a válasz, akkor
nem kérdezi meg a szervert, hanem azonnal válaszol rá. Az ilyen a kommunikációs útvonalon
kiépített infrastruktúrát CDN (Content Delivery Network) Tartalom Elosztó Hálózatnak nevezzük.
E hálózatok célja, hogy a tartalmat / erőforrásokat közelebb vigye a felhasználókhoz, ezzel több
ponton is segít:
• késleltetés: a mai felhasználók néhány szempillantásnál többet nem hajlandóak várni a

program reakciójára/válaszára (késleltetés<0.1s: ekkor a felhasználó úgy érzi, hogy a konkrét
objektumot közvetlenül szerkeszti, késleltetés<1 s: ekkor a felhasználó folyamatosnak
érzékeli a navigációt,késleltetés >10 s: a felhasználó figyelmét már külön kezelni kell -
például előrehaladás indikátor segítségével). Amint azt láthattuk maga a tenger alatti kábel is
bevihet néhányszor 0.1 s-os késleltetést, így nincs más megoldás, mint fizikailag közelebb
vinni a felhasználóhoz a tartalmat.
• szerver terhelés csökkentése: statikus tartalmaknál ez akár 90%-os terhelés csökkentéssel
is járhat.
• robosztusság: az alkalmazás adott feltételek mellett (lásd.: PWA - Progressive Web Application)
a szerver megszólítása nélkül is üzemképes, így a szerver rendelkezésre állása nem blokkoló
tényező
A tartalomelosztó hálózatok saját infrastruktúrát működtetnek, melynek kiépítésében kétfajta
stratégiát követhetnek:
• lépj be mélyen (enter deep): a hozzáférési ISP-be telepíti a szervereit, így minimalizálja a
késleltetést
• vidd haza (bring home): saját központokba helyezi a szervereket úgy, hogy több Tier1-es
hálózathoz is közvetlen összeköttetéssel bírjanak. A késleltetés így nem lesz minimális, de a
karbantartás egyszerűbb.
A gyorsítótárazást a konkrét parancsnak is támogatnia kell, ezt szolgálják a feltételes kérések
(conditional request). A megoldás lényege, hogy maga a kérés, illetve annak a sikeressége
megváltoztatható az adott erőforrás és a megfelelő komparátor (comparator) összevetésével.
Biztonságos kérések (pl.: GET) esetén csak akkor küldik el a dokumentumot ha érdemes (pl.:
If-Modified-Since fejléccel megadott időpont óta módosították), nem biztonságos kéréseknél (pl.:
PUT) a feltöltés csak akkor lesz sikeres, ha az eredeti és a feltöltendő azonos verzióra alapul. A
validáció lehet:
• erős validáció: garantálja azt, hogy az erőforrás bájtról bájtra azonos az összevetendő
erőforrással (pl.: ETag: fejléccel)
• gyenge validáció: itt adott elemek egyezőségét vizsgálja csak meg
A gyorsítótárazást segítő fejléc mezők:
• If-Match: Akkor sikeres ha a távoli erőforrás ETag értéke megegyezik a fejlécben lévő
értékkel
• If-None-Match: Akkor sikeres ha a távoli erőforrás ETag értéke nem egyezik meg a fejlécben
lévő értékkel
• If-Modified-Since: Akkor sikeres ha a távoli erőforrás Last-Modified dátuma frissebb mint
a mező értéke.
• If-Unmodified-Since: Akkor sikeres ha a távoli erőforrás Last-Modified dátuma régebbi
mint a mező értéke.
A fenti feltételes kéréseket természetesen a szerver vagy a szintén HTTP szerverként funkcionáló
köztes proxy dolgozza fel. A válasz első sora a státusz, amely röviden jelzi a művelet kimenetét. A
válasz kódok az alábbiak lehetnek:
• 1xx - tájékoztató információk: A kérést megkapta a szerver, feldolgozás következik.
• 2xx - sikeres kérés: A kérést sikeresen megkapta, elfogadta, megértette a szerver.
• 3xx - átirányítás: További tevékenységekre van szükség a kérés befejezéséhez.
• 4xx - kliens hiba: A kérés rossz szintaxisú vagy nem teljesíthető.
• 5xx - szerverhiba: A szervernek nem sikerült egy helyes kérést végrehajtania.
Ezeken a kódokon belül vannak szabványosak és termékfüggők is, például:
• szabványos: 202 - elfogadva: A kérést elfogadta a szerver, de a feldolgozás nem fejeződött
be.
3.2 WWW 41
3.8: HTTP válasz
• egyedi: 440 - lejárt bejelentkezés: A munkamenet lejárt, így a kliensnek újra be kell
jelentkeznie (az Internet Information Server ezt használja).
A második sortól a válasz fejlécek helyezkednek el. Itt vannak azok, amelyek szabályozhatják
például a gyorsítótárazást (pl.: Cache-Control: max-age=3600), de itt kérik fel a kérést azonosításra
is (pl.: WWW-Authenticate: Basic).
A fejlécek után helyezkedik el törzs (body). A törzs tartalma és az egész protokoll szövegesen kerül
továbbításra. A tartalom értelmezésének módja a Content-Type fejléc mezőben kerül átküldésre. A
fejlécben megadható értelmezéseket az IANA által karbantartott MIME type lista adja meg. Lehet
például text/html, ekkor egyszerű szöveges leírásban HTML kódot várunk, de lehet image/heic,
ekkor a beágyazott tartalom adott kódolással szöveggé alakított HEIC formátumú kép.
Az előzőekben bemutatott kérés/válasz megközelítéssel a kliens a szervertől kér erőforrásokat. Van
azonban mód arra, hogy a szerver megkérje a klienst adott információk tárolására. Ezek a sütik
(cookie). Adott esetben a szerver (a rajta futó alkalmazás) szeretné valamilyen módon nyomon
követni a böngészőt. Az adott weboldal a felhasználó beléptetése/azonosítása nélkül is szeretne
személyre szabott tartalmat (ez gyakran reklám) biztosítani a felhasználónak. Ilyenkor a szerver
egy kis azonosítót ment el a kliensen, amit a kliens minden kérésnél elküld neki, így tudja, hogy
melyik böngészőtől/felhasználótól kapja a kérést. Precízebben leírva:
• a szerver a Set-cookie: x fejléc segítségével megkéri a böngészőt az x érték eltárolására
Set-Cookie: CSRF=e8b667; Secure; Domain=example.com - tárold el a CSFR névre az
e8b667 értéket, amikor az example.com doménen értelmezett URL-hez megy kérés, akkor
küldd ki, de csak akkor, ha a kapcsolat biztonságos
• a kliens minden kérésbe a elküldi a Cookie: CSRF=e8b667 sütit
A felhasználók adott oldalakra vagy globálisan is letilthatják a sütik küldését, tárolását.
A HTTP a fent látható kérés/válasz párok küldésére alkalmazhat perzisztens vagy nem perzisztens
kapcsolatot. Perzisztens kapcsolat esetén a kérés elküldésére létrehozott kommunikációs csatornát
nem zárják le a válasz beérkezése után, hanem ugyanazon a csatornán (TCP) további kérés-válasz
üzenetváltások mehetnek. A nem perzisztens kapcsolat esetén minden üzentváltásra újabb csatorna
lesz létrehozva.
3.2.3 HTTP Biztonság, azonosítás

Az eddigiekben a HTTP alapvető képességeit tekintettük át, nem említve a biztonsággal kapcsolatos
szolgáltatásait. Ezek igen szegényesek, ugyanis titkosítás, tartalom védelem nincs. Ezeket
a szolgáltatásokat a később megismert TLS protokoll fogja biztosítani. Amennyiben a TLS
segítségével már létrejött egy biztonságos csatorna, úgy az azonosítás marad mint megoldandó
feladat. Azonosításra nem csak a konkrét weboldalt megtekintő felhasználó esetén van szükség,
hanem amikor gép géppel kommunikál mint ahogyan azt később meglátjuk a REST esetén. A HTTP
protokoll konkrét fejléc mezők segítségével tudja az azonosítást támogatni. Adott esetekben a fejléc
és a törzs is szerepet játszik az azonosításban. A HTTP által támogatott azonosítási megoldásokat
az IANA tartja karban és ezek technikai részleteit az IETF RFC-k formájában szabványosítja.
Az azonosítást a legtöbb esetben kihívás/válasz (challenge/response) alapon valósítják meg. Ez
esetben a GET kérésre a szerver a 401-es kóddal és WWW-Authenticate fejléccel válaszol, ahol
adott esetben plusz információkat is megadhat (kihívás / challenge). Ilyen lehet a kívánt azonosító
eljárás és a védett tartomány neve (<type> <realm>). Erre a szerver ugyanúgy egy GET kéréssel
válaszol, csak abban meg lesz adva az Authorization fejléc is a megfelelő azonosítási módszernek
megfelelő tartalommal. A legegyszerűbb, csak a szervert és a klienst magába foglaló azonosítási
3.9: HTTP alap azonosítás
megoldások az alábbiak:
• alap (basic) - Ez esetben a felhasználónév: jelszó páros így, szabad szövegesen lesz átküldve
(pontosabban BASE64-es kódolással, ami egy 64 karakterből álló kódolási forma - NEM
TITKOSÍTÁS). Ekkor a szervernek ismernie kell a szabad szöveges jelszavat, ami ma komoly
biztonsági hibának minősül.
• kivonatolt (digest) - Ez esetben a szerver a visszajátszásos támadások elkerülésére egy
nagy véletlen karakterláncot küld át (nonce), ezt kell a kliensnek összefűznie a jelszó
kivonatával és kivonatolnia.
Sok esetben azonban nem csak két, hanem több entitás is szerepel az azonosítási láncban.
Ilyen amikor Proxy szerver van a böngésző és a web szerver között. Itt a folyamat ugyanaz lehet
mint az előzőekben, csak ilyenkor a Proxy és a kliens között játszódik le. A proxy a 407 Proxy
Authentication Required válasszal és
textbfglsproxy-Authenticate fejléccel szólítja fel a klienst az azonosítás adott típusára, a kliens pedig
a Proxy-Authorization fejléc segítségével a kijelölt módszerrel azonosítja magát a proxy-nak. A
Proxy alapú azonosításnak komoly szerepe van, amikor több webszerver előtt egy külön dedikált
ponton szeretnénk egy közös azonosítása és hozzáférés vezérlést tenni. Ettől egy komplexebb eset,
amikor az erőforrás (resource), azonosítás (authentication), jogosultságkezelés (authorization)
szerepkörök nem egy helyen vannak megvalósítva. Az előző példákban vagy a proxy vagy a
webszerver játszotta el az összes szerepkört, ezen túl az egyszerű kliens-szerver modell mentén
történt az információcsere. Ez a modell mobil alkalmazások esetén problémás, mert:
• Harmadik fél által készített mobil alkalmazásban ehhez le kell tárolni a felhasználó szabad
szöveges jelszavát (mivel nem szeretnénk másodpercenként megkérni arra, hogy írja be a
jelszavát)
• Az ilyen alkalmazások a jelszó birtokában a felhasználó kontrollja nélkül hozzáférhetnek a
3.2 WWW 43
3.10: Proxy azonosítás
védett erőforrásokhoz
• A felhasználó nem tudja ezt a jogot visszavonni
Az ilyen szeparált szerepköröket támogató eljárások egyik HTTP azonosítás típus a vivő (bearer)
típus. Ezt több módon is lehet használni, de a szabványos mód az OAuth azonosítás megvalósítása.
Az OAuth 2.0 a fenti problémák megoldására definiál egy keretrendszert. Az alapötlet, hogy az
erőforrásokhoz egy zseton (token) segítségével lehet hozzáférni, amelynek már szabályozható a
lejárata, hatóköre. Vegyük észre, hogy itt nem csak az azonosítás a kihívás, hanem a jogosultságkezelés
is. Az OAuth 2.0 által definiált szerepkörök az alábbiak:
• erőforrás birtokos (resource owner): általában a végfelhasználó (user) az ő erőforrásaihoz
(pl.: Tweetekhez) szeretne adott rendszer szereplő hozzáférni
• erőforrás szerver (resource szerver): a védett erőforrásokat kezelő szerver (pl.: tweeter.com,
a konkrét API amit el szeretnénk érni)
• kliens (kliens): a védett erőforrásokat elérni kívánó entitás (pl.: mobil alkalmazás)
• jogosultságkezelő szerver (authorization szerver): a zsetonokat kibocsátó szerver (amely
biztosítja azt a webes felületet ahol a felhasználó azonosítja magát)
Az OAuth 2.0 szabvány a kliens és a többi szerepkör közötti interakciókat szabványosítja, nem
foglalkozik például az erőforrás szerver és a jogosultságkezelő szerver közötti lehetséges protokollal.
Az interakciók a 3.11 ábrán láthatóak. Attól függően, hogy a felhasználó elérhető-e vagy nem,
3.11: OAuth 2.0 interakciók
illetve hogy a kód hol fut, négy fajta OAuth 2 folyamatot definiáltak. Ezen folyamatok alapvetően
a (B) lépés megvalósításáról szólnak, jogosultság biztosítás (authorization grant). Az alábbi 4

típusa van:
Feljogosító kód (authorization code): A feljogosító kódot a jogosultságkezelő szervertől kapja,
amely a kliens és az erőforrás szerver között helyezkedik el. A kliens átirányítja a felhasználót a
jogosultságkezelő szerver oldalára (
textbfglshttp Redirect), mely miután a felhasználó azonosítva lett és jóváhagyta az erőforrás elérését,
visszairányítja a klienshez, de elküldi a feljogosító kódot is. Vegyük észre, hogy a kliens (web
alkalmazás, mobil alkalmazás) nem tudja meg a felhasználó jelszavát, mivel nem az ő felületén
történik meg az esetleges jelszómegadás.
3.12: OAuth 2.0 Feljogosító kód alapú erőforrás hozzáférés
Implicit: Egyszerűsített azonosítási megoldás az olyan kliensek részére, amelyek böngészőben és

szkript nyelvben vannak megvalósítva (itt nem tudják biztonságosan tárolni a feljogosító kódot).
Az előzőtől annyiban különbözik, hogy nem egy feljogosító kódot kap hanem egy hozzáférési
zsetont. Mint ahogyan azt a 3.13 ábrán láthatjuk, itt a zseton az ami gyorsítótárazható a kliensen,
szemben az elsővel ahol ez biztonsági adatkötés két szintű volt és a jogosultságkezelő szervernek
több lehetősége van dönteni időtartamról, érvényességről (ha a zseton rövid életű, akkor adott
időközönként a feljogosító kóddal megjelenik a kliens és itt a szervernek döntési lehetősége van).
Erőforrás tulajdonos (felhasználó) azonosító adatok (resource owner password credentials):
Ez esetben tudjuk a felhasználónevet és a jelszavat, ezt pedig közvetlenül használhatjuk a zseton
igénylésére. Ezt csak akkor szabad használni, ha a kliens és az erőforrás között nagyon magas
biztonsági összerendelés van (pl.: a kliens az eszköz operációs rendszerének a része vagy nagyon
kivételes helyzetű alkalmazás).
A 3.15-n láthatunk egy döntési folyamatot a megfelelő azonosítási folyamat kiválasztására.
A hozzáférési zseton egy népszerű megvalósítása a JWT (JSON Web Token - RFC 7519). Segítségével
le lehet kódolni a jogosultság leírásához szükséges adatokat. A JWT a belseje egy fejlécből a
tartalomból áll és az aláírásból áll. Ezen részekben megadható mezők szabványosítva vannak (pl.:
alg-digitális aláírás algoritmus, iat - kibocsáját ideje - issued at, ...)
A struktúra először Base64-es kódolásúvá válik egyenként konvertálva, majd össze lesz fűzve. Ez
lesz a megfelelő http mezőben vagy a törzsben átküldve. A fenti megoldás segítségével tehát a
felhasználóhoz tartozó erőforrások hozzáférést szabályoztuk különböző módokon. Egy lefedetlen
és gyakran használt eset még említést érdemel. Ekkor nem a felhasználó erőforrásait, hanem az
3.2 WWW 45
3.13: OAuth 2.0 Implicit erőforrás hozzáférés
3.14: OAuth 2.0 Erőforrás tulajdonos (felhasználó) azonosító adatok alapú hozzáférés
alkalmazás készítőjének erőforrásait szeretnénk védeni. Ma gyakran van, hogy egy-egy mobil
alkalmazás nem az alkalmazás készítője által üzemeltetett háttérszolgáltatást használ (pl.: térkép),
ezen szolgáltatások jellemzően tranzakciószám vagy egyébb mért jellemző alapján számláznak
a szolgáltatás igénybevevőjének. A különböző alkalmazás fejlesztők API kulcsok (API key)
segítségével azonosítják a saját alkalmazásukat, ezeknél a szolgáltatóknál ez képezi a számlázás
alapját. Ez egy a szolgáltató által generált karakterlánc amelyet jellemzően az URL-ben küld el a
kliens. Az azonosítás és az ezzel kapcoslatos problémák részeletseb btárgyalását megtalálhatjuk
például ebben a könyvben: [7] illetve az OAuth-ról egy jó összefoglaló található ezen a weboldalon
[6]
3.2.4 HTTP 2.0, 3.0

A HTTP fejlődése 15 évig stagnált. 2015-ben jelent meg a HTTP 2.0 amely mint a 3.17 ábrán
látható, már mérhető penetrációjú. Szintén a 3.17 ábrán látható hogy a HTTP 2.0 meghagyja a
HTTP 1.1 protokollt, csak beburkolja azt egy bináris keretező protokollba annak érdekébe hogy:
• egy kapcsolaton párhuzamosan több kérést is küldhessen
• tömöríthesse a tartalmat, fejléceket
3.15: OAuth 2.0 megoldás kiválasztása
3.16: JWT szerkezete
• lehetővé teszi a kérések priorizálását

• hálózatbarát legyen (kevesebb TCP kapcsolat)
Az új bináris keretező protokoll folyamokba, majd üzenetekbe, majd keretekbe szervezi a kommunikációt.
A folyam absztrakció segítségével a kérések és a válaszok multiplexálva vannak, azaz egy kapcsolaton
egyidőben több kérés és válasz is mehet. Egy nagyon fontos újítása a szerver oldalról kezdeményezett
üzenetváltás (szerver push). Ekkor a szerver a kliens explicit kérése nélkül küld választ. Ilyen
lehet például ha egy adat megváltozott a szerveren, akkor ezt a szerver jelzi a weboldalnak, ami
ezt tudja frissíteni. A HTTP 3.0 egy további lépés a HTTP optimalizálásának irányában, ennek
legnagyobb újítása a TCP lecserélése UDP-re és a később ismertetett folyamatvezérlés HTTP
rétegben történő megvalósítása. A HTTP 2.0-ről egy bővebb áttekintést találunk például itt: [2].
3.2.5 REST
Az előzőekben már az azonosítás kapcsán is említettük, hogy a WWW a humán-gép interakció
mellett a gép-gép interakciót is támogatja. Ennek egy konkrét szoftver architekturális megvalósítása
a REST (Representative State Transfer). Az alapvető elképzelése az, hogy a szerverek erőforrásokat
tárolnak, ezekhez a kliensek úgy férnek hozzá, hogy adott reprezentációjukat letöltik, ezt manipulálják,
majd visszatöltik. Ezen architekturális mintát ma leginkább a WWW protokoll család segítségével
valósítják meg:
• URL segítségével azonosíthatjuk az erőforrásokat
• HTTP protokoll segítségével letölthetjük azokat egy reprezentációját
• a reprezentáció JSON vagy adott MIME enkódolású
• a REST infrastruktúrában a WWW fejezetben látott összes elve, protokoll megjelenik
(gyorsítótárazás, azonosítás, jogosultságkezelés, ...)
3.3 DNS 47
3.17: HTTP 2.0 szerkezete
3.18: HTTP 2.0 keretezés, push
A 3.19 ábrán látható egy REST API végpont lista amely a műveletek és azok paramétereit ábrázolja.
Mellette pedig egy munkakörnyezet entitás egy reprezentációja látható JSON formátumban.
3.3 DNS
A DNS szoftvejlesztés szempontjából azért is érdekes lehet, mert sokáig ez volt az emberiség
által létrehozott legnagyobb elosztott adatbázis. Mélyebb szakmai szempontból egy jó példa azon
rendszerekre, ahol a válaszképességet helyezik előtérbe a konzisztencia helyett. Ezzel a mai felhő
rendszerek egyik előfutáraként tekinthetünk rá. A DNS eredeti célja egészen egyszerű volt: ember
által is megjegyezhető neveket rendelni a gépek által ugyan kezelhető, de ember által kevésbé
megjegyezhető címekhez (IP címek). Az első hálózatokban ezt a hozzárendelést a gépeken lévő
fájlok segítségével oldották meg, ezek voltak a még ma is megtalálható hosts fájlok. Ezek ugyan
ellátták az alapvető hozzárendelést mint feladatot, azonban komoly kihívást jelentettek az alábbiak:
• lapos névtér - több azonos nevű géppel nem tudott mit kezdeni
• változások kezelése - minden gépen kézzel kellett átírni a bejegyzéseket
• a központi szervezés hiánya - a sok helyi fájlnak nem volt egy központi felelőse aki például
eldönthette volna hogy mi legyen a közös névvel
A fenti problémákat oldották meg több iterációban 1973 és 1987 között. A ma is ismert DNS
működését e két dokumentum írja le. RFC 1034 és RFC 1035. Ennek első referencia megvalósítása
a bind nevű ma is használt (azóta persze frissített) szoftver lett. A DNS alapvetései (az RFC 1034
alapján):
3.19: REST, JSON
3.20: A DNS rövid története
• konzisztens névtér - szabályozott felépítés, a neveknek nem kell a hálózati ID-t tartalmaznia
• elosztott rendszer - a kérések és frissítések gyakoriságát nem tudja egy központi rendszer
kiszolgálni
• nem a konzisztencia az első - kompromisszumot kell kötni a frissítések sebessége és a
gyorsítótárakban tárolt adatok pontossága között
3.3.1 DNS architektúra

Ezen tervezési alapelveket kielégítendő, a DNS egy hierarchikus névteret kezel. E hierarchia
az elsődleges rendezőelv a kiszolgálás és az adminisztráció leosztása között. A névteret adott
pontokból lefelé a levelek felé adott kiszolgálók szolgáltathatják, így elosztva a kiszolgálást és
delegálva az adminisztrációt, ez feladat adott csomópontokon tovább osztható, delegálható. Az
adminisztráció delegációja azonban megtartja a felsőbb szinteken lévő entitások adminisztratív
fennhatóságát a lejjebb lévő entitások fölött. A hierarchia csúcsa a gyökér tartomány, az alatta
3.21: A DNS hierarchia, delegálás
lévő TLD - Top Level Domain neveket a nonprofit ICANN tartja karban. Egy-egy TLD nevet
adott szervezet, cég, ország vesz meg és az alatta lévő névterek az ő tulajdonát képezik. Ezt a lépés
3.3 DNS 49
az adott domén (domain) delegálásának (delegation) nevezzük. Ez az elosztott adminisztráció

alapja. A delegálás persze nem csak a legfelsőbb szinten mehet végbe, hanem tetszőlege mélységben
a magasabban lévő csomópont delegálhatja az alatta lévő csomópontok egy halmazának kezelését
valakinek. E delegálás azonban nem jelenti azt, hogy e jogok nem vonhatóak vissza. A delegáláson
túl a fennhatóság (authority), mint fogalom is fontos mert adott szervezet az összes, alatta lévő
szervezet felett megtartja a fennhatóságát. Ezt a magyar terminológiában mérvadó szervezetnek
is nevezik.
3.3.2 DNS adatbázis

A hierarchikus névtér egy logikai felépítés ennek elosztott fizikai tárolását zóna fájlok segítségével
valósítja meg a rendszer. A zónafájlok hozzárendelése az adott doménhez általában egy-az-egy,
de követelményként csak a folyamatosság van megfogalmazva. A gyökér zónafájlt például 13
szervezetnél kb.: 400 darab szerveren tárolják. A zónafájlok általában egyszerű szöveges fájlok,
3.22: DNS gyökér szerverek, zóna fájlok
melyek egy-egy sora egy-egy bejegyzésnek (record) felel meg. Pontosabban:

• megjegyzések: “;”-vel kezdődő sorok
• direktívák: “$” jellel kezdődő sorok, a zónafájl feldolgozására tartalmaznak további információkat
• erőforrás rekordok: a konkrét sorokban tárolt információ típusát erőforrás rekord formátumban
ábrázolják és ennek a harmadik mezője adja meg a konkrét típusát
A fontosabb rekordok a következők (több mint 30 aktuális és számos elavult RR típus van):
• $ORIGIN direktíva: - a zónafájlhoz tartozó domén név (opcionális)
• Fennhatóság Kezdete (Start of Authority (SOA) RR): a zónafájlban leírt első RR rekord,
kötelező. A zóna globális információit tárolja, csak egy lehet belőle.
• Névkiszolgáló (Name Server (NS) RR): a zónafájlért felelős mérvadó névkiszolgálókat
sorolja fel. Kettő vagy több sor szükséges ide. Itt idegen és külső zónákért felelős szerverek
is megadhatóak (egy NS szerver több zónát is kiszolgálhat)
• Email kiszolgáló (Mail Exchanger (MX) RR): A zónáért felelős email kiszolgálót adja
meg. Ha adott zónában nincs email kiszolgálás akkor nem kell, egyébként lehet több is.
• Cím (Address (A) RR): A zónában lévő, publikusan látható hostok IPv4-es címét rendeli
hozzá egy névhez. (Az IPv6 az AAAA rekord típussal adható meg)
• CNAME RR: Egy alternatív nevet ad meg adott meglévő RR-ben megadott névhez (pl.:
www. előtag)
• Szolgáltatás (Service (SRV) RR): ugyanazt tudja mint az A rekord, de itt a cím mellett port
is megadható, így egy processz közvetlenül megcímezhető
A következő kivonat egy minta zóna fájl. Vegyük észre, hogy az egy vagy több MX és NS rekord a
magas rendelkezésre állás egyik megvalósítása. Egy-egy szolgáltatás mögött több szerver is lehet.
A későbbiekben majd látjuk, hogy a terhelés elosztást a DNS is megvalósíthatja, ebben segít a
preferencia. A másik fontos elem a TTL mező amely azt mutatja, hogy adott sor mennyi ideig
gyorsítótárazható az MX rekord esetében, ez például 3 hét. Ahol ez nem szerepel külön, ott az
alapértelmezett 2 nap a lejárati idő. Adott RR bejegyzéshez is tartozhat több sor, ez látható a 3.23
3.23: Zóna fájl
ábra alsó részén ahol a WWW tartoményt 3 IP-hez kötjük. Ilyenkor a DNS szerver round-robin
elven ad vissza más-más IP címet. Ez az első szint a webes rendszerek terheléselosztásában.
3.3.3 DNS protokoll

A tároló szerverek DNS protokollon érhetőek el. Itt jellemzően UDP csomagok formájában történik
a kommunikáció (mert egyszerűbb és állapotmentes - robosztus). Az UDP csomagoknak 512
bájtos méretkorlátja van. A DNS protokoll kérdés és válasz üzenetekből áll. Az üzenetet hordozó
csomag egy fejlécből és a kérdés illetve válasz RR-ekből áll. A mérvadó szerver feladata válaszok
3.24: DNS protokolll
biztosítása a beérkező kérdésekre. A kérdések jellemzően a DNS hierarchia gyökeréhez érkeznek.

Mivel itt csak a következő szintre mutató információ található meg, ezért a lekérdezés tovább
folytatódik a következő szinten lévő DNS szerver megszólításával. Ezt a kérdés láncot a DNS
feloldó szerver (DNS resolver) viszi végig. A DNS lekérdezéseket az alábbi módon kezelheti az
3.3 DNS 51
3.25: DNS lekérdezés hierarchia feloldó szerverrel
adott szerver:
• rekurzív lekérés: ez esetben a kérést megkapó DNS szerver mint feloldó működik és
végigjárja a hierarchiát (a válaszok alapján továbbkérdezősködik) annak érdekében, hogy egy
teljesen feloldott választ (azaz a végeredményt) tudjon visszaadni (vagy hibát). (opcionális
működésmód)
• iteratív lekérdezés: ez esetben amennyiben a DNS szerver tudja a választ, akkor válaszol rá,
egyébként csak egy a következő delegációs szintre mutató hivatkozással tér vissza (kötelezően
megvalósítandó működésmód)
Amennyiben több lehetséges DNS szerver is van, mint információforrás akkor a lekérdező DNS
szerver több módon is dönthet, hogy melyiket szólítja meg. Egy a BIND által megvalósított mód
az RTT mérése (megjegyzi, hogy melyik milyen gyorsan válaszolt) (round - trip -time a kérés
küldés és a válasz beérkezése között eltelt idő), ez alapján a legrövidebb válaszidejűt választja
ki.
A normál DNS kiszolgálás mellett a zóna fájlok menedzsmentje is a DNS protokoll segítségével
történik. A zóna fájlok elosztott tárolása a mester - szolga (master - slave) architekturális
minta mentén van megvalósítva. A mester lehet rejtett mester is, ekkor a TLD-ből a szolgákra
hivatkoznak. Minden zónafájlnak van egy mester szervere ahol ez írható és olvasható. Ezen
3.26: DNS rejtett mester vs. normál hirearchia
túl tetszőleges helyen tárolható, de csak olvasható formátumban (ezek a szolgák). A zónafájl
karbantartását (maintenance) több módon is meg lehet valósítani:
• teljes zóna átvitel (AXFR) - a szolga adott időközönként rákérdez a szerverre, hogy
van-e változás (a SOA sn - serial number mezője segítségével, ennek gyakori formája:
yyyymmddss), ha van, akkor átmásolja (AXFR - TCP-n keresztül). (a SOA refresh értéke
adja meg a gyakoriságot, ez általában 12 óra)

• különbségi zóna átvitel (incremental zone update IXFR) - nagy zóna fájlok teljes másolása
minden alkalommal nem hatékony. Az IXFR ugyanúgy működik mint az AXFR, csak
ilyenkor a különbséget küldi át a két verzió között.
• értesítés (NOTIFY): ugyanaz mint az IXFR, csak a mester változás esetén értesíti az NS
rekordokban megadott kiszolgálókat a változásról.
• dinamikus DNS frissítések (DDNS) - a DNS zóna információ klasszikus frissítése kézi
szerkesztést, majd a szerver újraindítását jelentette. Ez ma változékony vagy nagyszámú
bejegyzést kezelő környezetekben nem praktikus. A DDNS lehetővé teszi a zónafájl
futásidőbéli szerkesztését más folyamatok által.
3.3.4 DNS gyorsítótárazás

Az eddigiekben mester és szolga szerepkört különböztettünk meg, az alábbiakban a teljes DNS
rendszert áttekintjük, az egyes szerepköröket pedig funkcionálisan is. Ezen szerepkörök jellemzően
zóna fájlhoz kötődőek, azaz egy szerver adott zónafájlhoz lehet mester, míg másikhoz szolga.
Egy új, eddig nem említett szerepkör a proxy vagy gyorsítótár. Mint ahogyan a 3.27 ábrán
láthatjuk, ez lehet dedikált (3), de társult (1,2,4) is. A gyorsítótár név szerver az információ a
mérvadó szervertől szerzi be és a TTL-ben megadott ideig a beérkező kérdésekre ezen információ
alapján közvetlenül válaszol. Ilyenkor azonban jeleznie kell, hogy a válasza nem közvetlenül
a mérvadó szervertől érkezik - nem mérvadó válasz (non authoritative). A gyorsítótárazás a
3.27: DNS gyorsítótárak helyei
szolga szerverek mellett az a másik nagyon fontos architekturális minta, amely lehetővé teszi
a DNS extrém robosztusságát és skálázhatóságát. Vannak olyan DNS kiszolgálók is, akik nem
tárolnak zóna fájlokat, egy zónának sem mérvadó kiszolgálói. Az ilyen csak gyorsítótárazó DNS
szervereket továbbító (forwarding) névszervereknek nevezzük. Ezt olyan helyeken alkalmazzák,
ahol az Internetkapcsolat teljesítmény problémákkal bír. Az előzőekben említett rejtett mester
3.28: Továbbító DNS szerver
szerver akkor érdekes, amikor külön információt szeretnénk szolgáltatni a belső és a külső hálózatra.
Ilyenkor a mester csak szűrt információt ad át szolgának. Az eddigiekben a DNS név-azonosító
3.3 DNS 53
3.29: Belső és külső hálózat szeparált kiszolgálása
hozzárendelés képességéről beszéltünk. Vannak azonban olyan esetek, amikor az azonosító adott
(IP cím) és a névre vagyunk kíváncsiak (ez leginkább biztonsági ellenőrzés esetén szokott érdekes
lenni). Az ilyen jellegű keresésekhez külön név hierarchia van kialakítva (.IN-ADDR). Itt az
információ PTR rekordokban van tárolva. A lekérdezés a magasabb szintű (hálózati rész) IP cím
daraboktól halad az alacsonyabb szintű részekig.
3.30: IP - cím keresés, hozzárendelés
3.3.5 DNS biztonság

Az Internet egyik alapvető építőeleme, a DNS mivel az általa szolgáltatott adatok alapján dől
el, hogy ki kivel fog kommunikálni. Beírjuk a böngészőbe a bankunk URL-jét, a böngésző
megkérdezi a DNS szervertől és ha az egy hamis, a bank honlapjához kísértetiesen hasonlító
weboldal IP címét adja meg, akkor mi nyugodtan megadjuk ott minden adatunkat, mivel úgy
véljük, hogy a bank weboldalán vagyunk. De igaz ez például a később ismertetett email-re is,
ahol például 2014-ben kiderült, hogy adott körzetekben a Yahoo!, Hotmail és Gmail szerverek
helyett előbb köztes (rossz szándékú) szerverekre mentek a levelek. A DNS által adott válaszok
tehát kritikusak a mai hálózati infrastruktúra működése szempontjából. A DNS biztonsági
problémáit az alábbi kategóriákba sorolhatjuk:
• helyi veszélyek: ilyenkor a DNS szerver gépén vagy adott konkrét gépen a helyileg tárolt
DNS információ manipulációját kell megakadályozni (a zónafájl egy egyszerű fájl és ez a
helyi operációs rendszer megfelelő konfigurációjával megtehető)
• szerver-szerver veszélyek: itt a zónafájlok másolása, frissítése a védendő folyamat
• szerver-kliens veszélyek: a gyorsítótárak tartalma a kérdés, mennyire igaz a gyorsítótárban
lévő információ (itt találkozhatunk a gyorsítótár mérgezéssel, amikor egy DNS proxyhoz
kéretlenül egy választ küldünk adott A vagy egyébb rekorddal, ezt ő be fogja tenni a
gyorsítótárába és ezen adatot fogja a későbbi kérdésekre kiküldeni)
A fenti problémákra egy rendszerszintű megoldást nyújt a DNSSEC úgy, hogy kriptográfiai
aláírásokkal látja el az egyes rekordokat. Ezen aláírások validálásával a kliens meggyőződhet
arról, hogy adott információ hiteles vagy sem. Az aláírások a publikus kulcsú infrastruktúra
segítségével készülnek el, ami egy a gyökértől lefelé haladó hierarchia mentén van kialakítva
(ugyanúgy mint a delegáció). Ezen láncolat mentén vannak aláírva a zóna fájlok és az egyes
rekordok is. Ennek első lépése az azonos típusú rekordok halmazokba gyűjtése (RRset), ezek
együtt lesznek aláírva. Az aláírás és annak validálása a zónához tartozó privát és publikus
kulcspárral valósul meg (ZSK). Az RRSet aláírásokat RRSIG rekordokban tárolják. A publikus
kulcsot pedig a DNSKEY rekordban teszik elérhetővé. Adott rekord típusok lekérdezésekor a
DNS szerver az RRSIG rekordokat is visszaadja. Annak érdekében, hogy a DNSKEY is validálható
3.31: DNSSEC aláírás hierarchia, rekord típusok
legyen, a DNS kiszolgáló a saját privát kulcsával aláírja (KSK - key signing key) ez is egy RRSIG
rekord lesz de az a DNSKEY-hez. Ezt a kulcsot a szülő szerver is eltárolja kivonatolva, erre a DS
rekordot használja, így a kulcsot ugyan nem, de annak kivonatát át tudja adni adott lekérdezéshez,
melynek segítségével a kulcs validálható és ha az valid akkor az aláírt adat is.
A DNSSEC penetrációja a TLD szinten jelentős 90% fölötti a digitálisan aláírt zónák aránya,
de a második szinten ez az arány már csak 4%, a DNS lekérdezések 24%-a tartalmaz DNSSEC
validációt. Így ezen a területen van még tennivaló. A DNS egy jóval részletesebb bemutatását
találjuk meg itt: [1]
3.4 Email
Az email a Internet ősének (ARPANet) is az egyik első szolgáltatása volt (1998). Az akkor
kidolgozott protokollokat alkalmazzuk ma is. A szereplők a rendszerben:
• felhasználói ügynök (user agent): Ez a levelező kliensünk, ezt használja a végfelhasználó.
Enélkül is megvalósítható az email küldés/fogadás, csak ekkor a felhasználónak ismernie
kellene a megfelelő protokollokat.
• levelező szerver (mail szerver): A feladata a levelek tárolása és továbbítása.
3.5 SMTP protokoll 55
3.32: Email rendszer
3.5 SMTP protokoll

Az email küldés alapja az SMTP (Simple Mail Transfer Protocol) amely feladata a küldőtől
eljuttatni a címzett doménért felelős email szerverhez. Ezt az email cím mezője alapján teszi meg. A
címzettek doménjeiben a DNS segítségével megkeresi a felelős email kiszolgálókat (MX rekord)
és azokhoz közvetlenül kapcsolódva átadja nekik a levelet. Itt jellemzően nincs levél-szerver
hierarchia, hanem a küldő levelező szervere közvetlenül a címzettek levelező szervereihez fordul. A
szerverek közötti kommunikáció megbízható, TCP csatornán történik. Az SMTP protokoll hasonló
a HTTP-hez, szöveges és egyszerű utasításokból áll. Egy példa SMTP kommunikáció látható a
3.33 ábrán. Az SMTP, bár egy szép és egyszerű protokoll, sajnos a biztonság területén nem sok
3.33: SMTP protokoll1
szolgáltatással bír. Az email szolgáltatások egyik legkomolyabb kihívása a kéretlen levelek özöne,
a SPAM. Külön ajánlások vannak az email szerver üzemeltetők részére, hogy hogyan akadályozzák
meg a szerverük felhasználását SMAP küldésére. Az egyik legfontosabb elem a küldő szerver
érvényességének vizsgálata. Itt is a DNS-t használjuk mint tudásbázist, a fogadó szerver ott nézi
meg például, hogy a küldő szerver IP címe valóban a levél küldőjének doménjéhez tartozik-e.
A SPAM mellett az email-ek meghamisítása is komoly kihívás, mivel maga az email átviteli
formátum, egy egyszerű szöveges adat és hasonlóan a DNS-hez, csak egyszerű mezőket tartalmaz
mindenféle kriptográfiai validációs lehetőség nélkül. A levél felépítése a 3.34 ábrán látható. A
boríték tartalmazza az SMTP szerver által leginkább fontos információkat, míg a fejléc inkább a
3.34: Email felépítése1
felhasználónak szól.
Az SMTP protokoll segítségével tudja a levelező ügynök elküldeni a levelet a saját SMTP szervere
segítségével, amely szintén SMTP segítségével küldi el a címzettek SMTP szerverére. A protokoll
azonban nem alkalmas arra, hogy a levelező ügynök le is töltse a szerveren lévő leveleket.
Erre a feladatra az IMAP és a POP3 protokollokat szokták alkalmazni. A POP3 egy nagyon
egyszerű, csak a levelek letöltését támogató protokoll, míg az IMAP egy bonyolultabb protokoll, de
segítségével a szerveren tudjuk a leveleket kezelni, mappákba helyezni.
3.35: Email vég-vég kapcsolat1
3.5.1 Email biztonságossá tétele - PGP
Mint ahogy láthattuk, az email küldőjére és az email tartalmára semmilyen biztonsági validációs
lehetőséget sem ad az SMTP protokoll. Ezen hiányosság kezelésére számos protokoll kezdeményezés
látott napvilágot, ezek közül a legismertebb a PGP (Pretty Good Privacy). A PGP csak az
email törzsével foglalkozik, ott biztosít tartalom védelmet és igény esetén titkosítást. A megfelelő
működéséhez szükség van megfelelő tanúsítvány kiadó hierarchiával bíró publikus kulcsú infrastruktúrára.
Működésének áttekintése a 3.36 ábrán látható. Tündérszép Ilona az “ü” üzenetet szeretné elküldeni
Árgyélus Királyfinak, a digitális aláírás létrehozása érdekében kivonatolja az üzenetet H() ,majd
titkosítja a saját privát kulcsával. Ezt hozzáfűzi az üzenethez és egy, ehhez az egy email küldéshez
létrehozott szimmetrikus kulccsal titkosítja. Ezt a szimmetrikus kulcsot titkosítja Árgyélus Királyfi
publikus kulcsával és hozzáadja a levél törzséhez, ezt együtt küldi el Árgyélus Királyfinak. Mivel a
PGP nem az SMTP része, ezért a felhasználó ügynöknek kell ezt támogatnia. Van ahol egyszerűbb
és adott (pl.: GMAIL esetén FlowCript) és van ahol ez nehézkes (pl.: IPhone esetén).
3.6 P2P 57
3.36: PGP folyamat
3.37: PGP minta
3.6 P2P
Az eddig ismertetett protokollok és megoldások a kliens-szerver elven alapultak. A szerver
erőforrásait használták a kliensek. A gyakorlatban ezzel a megközelítésmóddal találkozunk a
leggyakrabban. Amennyiben azonban benézünk a motorház alá, kiderül, hogy számos kliens
szerver paradigmát kiszolgáló szerver oldali erőforrás kezelés a háttérben P2P (Peer to peer)
architektúrára épül. A mai nagy felhő infrastruktúra kivétel nélkül P2P protokollokra épít. Mint
ahogyan később látni fogjuk a klasszikus forgalomirányító algoritmusok is P2P elven működnek.
Ahol tehát nem 5-10 hanem több 10.000, akár több 100.000 elem együttműködését kell megoldani
úgy, hogy nem csak olvasást, hanem írást is ki kell szolgálni, ott csak a P2P megoldások jöhetnek
számításba. A P2P architektúra előnyei:
• Skálázhatóság: újabb kiszolgáló erőforrások hozzáadásával nagyobb adatmennyiséget,
lekérdezés számot tud kiszolgálni
• Robosztusság: nincs egy meghibásodási pont, a rendszer elviseli adott számú elem kiesését.
A továbbiakban két gyakorlati példa protokoll segítségével mutatjuk be a P2P elvet.
3.6.1 BitTorrent
A P2P rendszerek közös jellemzője az erőforrások egyenrangú megosztása. Ilyen erőforrás
lehet a tár kapacitás és a fel- illetve letöltési sávszélesség. A BitTorrent e két erőforrás koordinált
megosztását valósítja meg annak érdekében, hogy adott megosztott állományt minél gyorsabban el
lehessen osztani. A P2P megközelítés előnye a tárolókapacitások megosztásánál nyilvánvaló, de
ami sokkal fontosabb ebben az esetben, hogy a hálózati kapacitásokat is megosztják. Amennyiben
összevetjük a kliens-szerver elven és a P2P elven történő megosztást, úgy a következő formulákkal
tudjuk ezeket jellemezni:

NF F
Dcs = max , (3.1)
us dmin

F F NF
DP2P = max , , (3.2)
us dmin us + ∑Ni=1 ui
Itt Dcs a kliens szerver, míg DP2P a P2P, N a kliensek száma, F fájl mérete, us a szerver feltöltési
kapacitása, míg ui és di az i. résztvevő fel- és letöltési kapacitása. Látható, hogy a kliens-szerver
esetén a teljes igénylő csoport ellátását vagy a legkisebb letöltési kapacitással bíró elem, vagy a
szerver feltöltési sávszélessége korlátozza. A csoport méretének növelésével (N) az idő lineárisan
nő (lásd a 3.38 ábra középső részén lévő grafikonon). A P2P esetben viszont az N-től függő
harmadik tag esetén láthatjuk, hogy nem csak a nevezőben, hanem a számlálóban is van
N-től függő tag, így a teljes letöltési idő jóval a lineáris alatt fog lenni. A BitTorrent protokoll a
3.38: P2P vs. kliens-szerver tartalomelosztás1
fenti megközelítést alkalmazza és azontúl, hogy lehetővé teszi a felöltési sávszélességek megosztását,
tartalmaz néhány praktikus, gyakorlati heurisztikát is:
• a fájl darabokra bontása: Annak érdekében, hogy a nagy fájlok letöltése megszakítható
legyen, célszerű azokat darabokra bontani. Ezek után már egy-egy fájl darab letöltése a cél.
• nincs fájl tároló szerver: A fájlt a résztvevők egymás között osztják meg. Van ugyan olyan
elem, aki ezt kezdetben biztosítja (seed), de ez a csoporttag bármikor távozhat.
• központi adatbázis: Van egy kiemelt szerepkör (követő-Tracker), amely a központi tudást
biztosítja a csoportban résztvevők számára. Itt vannak nyilvántartva az egyes résztvevők,
és hogy kinél milyen fájl darab található. Ez a szerepkör lehet dedikált szerverként, de
elosztott algoritmussal is megvalósítva (pl.: DHT). a résztvevők fájl darabokat cserélgetnek
egymással: Egy-egy résztvevő a követő szerverből kiválasztja, hogy mely fájl darabokat
szeretné letölteni, és azt is, hogy melyik résztvevőtől fogja azt elkérni.
• legritkább darabok először: Mivel a BitTorrent csoportban önkéntesen vesznek részt
csomópontok, előfordulhat hogy egy csomópont, miután letöltötte a fájlt, kilép. Ekkor
előfordulhat, hogy adott fájldarabok csak nála vannak meg (itt nincs dedikált szerver, egymás
között osztják meg a fájlt). Az ilyen esetek elkerülése érdekében minden csomópont a
legritkább darabokat fogja letölteni, így lehetővé téve a darabok egyenletes elosztását
• legjobb szomszédok kiválasztása: A BitTorrent csoport akkor lesz sikeres, ha a résztvevők
nem mohók, azaz nem csak letölteni, hanem feltölteni is segítenek, azaz darabokat osztanak
meg a többiekkel. Ennek elősegítése érdekében a legtöbb társat a társak által biztosított
feltöltési sebesség alapján választja. Azaz a gyors fel/letöltési sebességgel bíró csoporttagok
3.6 P2P 59
egymással fognak leginkább fájl darabokat csereberélni. Ez azért jó, mert így a lehet
leggyorsabban szétteríthető a tartalom, és mindenki arra van kényszerítve, hogy ossza meg a
feltöltési kapacitását.
• véletlen szomszédok kiválasztása: Annak érdekében, hogy új és nem bizonyított résztvevők
is kaphassanak darabokat, illetve a kis sávszélességű résztvevők se maradjanak ki teljesen, a
csomópont adott számú szomszédját nem teljesítmény, hanem véletlenszerűen választja ki
(azaz enged neki letölteni).
A BitTorrent tehát egy jó példa arra, hogy egy igen változékony környezetben központi menedzsment
nélkül hogyan lehet megosztani a csomópontok között erőforrásokat. A következő algoritmus nem
elsősorban a sávszélesség, hanem a közös konzisztens tár létrehozásában játszik kulcsszerepet.
3.6.2 Paxos
Az elosztott, több helyen futó rendszerek esetén a konzisztencia kérdése kritikus fontosságú. A
programozók számára egy fontos kérdés, hogy mikor és milyen jellegű konzisztencia szintet
valósítanak meg. Gondoljunk csak egy egyszerű mobil telefonon futó játékra, ahol a a játékosok
versenyeznek. A pontszámok egy szerveren vannak eltárolva. Egy fontos kérdés, hogy a telefonon
futó alkalmazás milyen gyakran frissítse a saját adattárát a szerverről. Miről kell itt döntenünk? Egy
szempont lehet a szerver terhelése, vagy a telefon energia fogyasztása (az energia fogyasztás jelentős
részéért a vezetékmentes interfész felel) és az adat frissessége. Mennyire engedjük meg elavult
adatok megjelenését a képernyőn? Erre nincs általános válasz, adott esetben amikor ez egy külön
oldal amit ritkán néznek elfogadható az is ha néhány percenként frissül. A példánk egy viszonylag
egyszerű konzisztencia problémát vázolt, ahol az adat érvényes (adott időpontban az volt), és
ha a szerveren nem változik akkor a kliensen előbb-utóbb szintén érvényes, aktuális lesz. Ezt
nevezik BASE - Végsősoron konzisztens (Basic Availability Soft-state Eventual consistency)
megközelítésmódnak. Jóval komolyabb problémánk van amikor nincs egy ilyen kiemelt központi
szerver, hanem sok szerverünk van és nem csak az olvasás, hanem írás művelet is van. E probléma
szemléltetésére jó példa a két tábornok története.
Két hadsereg egy erődítményt szeretne megtámadni. Mindkét sereg a város mellett van egy-egy
völgyben melyeket a közöttük lévő hegyen átfutó ösvény köt össze. Ez azonban az erődítmény
védői által felügyelt terület ahol bármikor elfoghatják a futárokat. A két sereget vezető tábornok
megegyezett ugyan abban, hogy közösen támadnak, de az időpontban nem egyeztek meg. Ahhoz,
hogy az erődítményt elfoglalják egyszerre kell támadniuk. Amennyiben nem együtt támadnak
akkor a támadó sereg megsemmisül. Kommunikálniuk kell tehát egymással annak érdekében,
hogy a támadást koordinálják. Mivel bármelyik futárt elfoghatja az ellenfél ezért végtelen számú
futár esetén tudnak csak konszenzusra jutni. Ez az alapprobléma a számítógép hálózatokban is
megjelenik. A futárok a hálózaton átküldött üzenetek míg a tábornokok a programok melyeknek
szinkronba kellene lenniük. A fenti probléma egy ötletes kezelését valósítja meg a 2000 éves Paxos
algoritmus melyet ma a nagy felhő szolgáltatók alkalmaznak a több 100.000 gépes parkjaikban
a konzisztencia fenntartása érdekében. A két tábornok problémáját nem oldja meg a Paxos sem,
de azt garantálja hogy ha támadhatnak (azaz elegendő futár jutott át) akkor ez közös támadás lesz.
Azaz a konzisztencia garantált a haladás nem.
A továbbiakban a [4] cikk gondolatmenetét és ábráit követve mutatjuk be az algoritmust.
A 3.39 ábra A felén az alapprobléma látható az S1 szerver dolgozza fel a C1 és C2 kliensek kéréseit.
A kérdések mi -vel vannak jelölve. A kérések hatására a szerver állapota megváltozik és ennek
hatására σikl az i-szerver k és l üzenetek feldolgozása utáni állapotát mutatja (k és l ebben a
sorrendben) ezt az állapotot fogja elküldeni hσikl i. Az egy szerveres esetben 3.39 ábra A felén,
látható, hogy egy szerveres esetben a kliensek konzisztens állapotot látnak mivel a szerver az
üzeneteket az elküldés sorrendjében kapja meg és ez alapján változik az állapota is.
Egy szerverrel azonban nem tudunk üzembiztos rendszert megvalósítani mert ha az leáll akkor
3.39: Egy szerver két kliens, két szerver két kliens
a rendszerünk is leáll. A megoldás erre a problémára újabb szerverek beállítása, 3.39 ábra B
fele. Ez egy gyakori megoldás, elsődleges tartalék szervernek szokták nevezni. Ilyen megoldást
fogjunk látni a például DHCP protokoll esetén. A szerverek között nincs koordináció, a kliensek
egyszerűen nem egy hanem két szervernek küldik el üzeneteiket. A probléma az, hogy ezek
az üzenetek különböző sorrendben érkezhetnek be a szerverkehez amelyek ezeket különböző
sorrendben dolgozzák fel. Az S1 szerver m1 , m2 sorrendben kapja meg míg az S2 szerver m2 , m1
sorrendben. Ez alapján a szerver állapotok is különbözni fognak. C1 valószínűleg a σ11 , σ221
válaszokat kapja míg a C2 valószínűleg a σ22 , σ112 válaszokat kapja. A probléma valós, a hálózaton
a késleltetés nem determinisztikus. Első megoldásként megpróbálhatjuk a két szerver működését
koordinálni. Legyen az egyik szerver a vezető (mester). A vezető elfogadás üzenetet küld a másik
3.40: Szerver koordináció, üzenetvesztés kezelése
szervernek és feldolgozza a kéréseket. Az elfogadás üzenet hACC, mi , ji az mi üzenet helyét mondja

a sorszám segítségével (j) meg az abszolút sorrendben. Ezzel a megoldással, tehát egy központi
szerver abszolút sorrendbe teszi az üzeneteket 3.40 ábra A oldala.
Ez a megoldás addig tud jól működni amíg az üzenetek el nem vesznek 3.40 ábra B oldala.
Ekkor a hACC, m2 , 1i üzenet elveszik és a S2 szerver nem tud továbblépni, nem tudja az m1
üzenetet feldolgozni. Egy megoldás erre a problémára ha alkalmazunk egy elveszett üzenet
detektáló mechanizmust. Ekkor a vezető addig ismételi az üzenetet amíg pozitív választ nem kap rá
hLRN, mi i.
Az üzenet vesztéseket tehát megoldottuk a fenti rendszer jelen protokollja azonban még nem kezeli
a szerver újraindulásokat, leállásokat. Egyik szerver leállása a másik haladását blokkolja. Egy
naív megoldás a problémára, hogy amennyiben egyik szerver megáll akkor a másik folytatja a
3.6 P2P 61
munkáját mint ahogyan azt az egy szerveres üzemmódban is tette. A 3.41 ábra A részén láthatjuk a
3.41: szerver leállás naív protokoll probléma, várakozás amíg a közös állapot elterjed
problémát ezzel a naív megközelítéssel. A vezető szerver S1 válaszol az m1 kérésre még az előtt,
hogy S2 látta volna a hACC, m1 , 1i üzenetet. Az S1 leáll azelőtt, hogy ezt újraküldené. Az S2 átveszi
a vezérlést és mivel nem kapta meg a helyes információt a sorrendről ezért m2 -t fogja először
feldolgozni (nincs ismerete az abszolút sorrendről). A probléma itt az volt, hogy az S1 vezető úgy
küldött ki információt a belső állapotáról (hσ11 i) hogy megbizonyosodott volna arról, hogy ez már
közös tudás a másik szerverrel. A megoldás, tehát az, hogy előbb megbizonyosodik arról, hogy az
állapotváltozás ismerete elterjedt és csak ezután válaszol 3.41 ábra B oldala.
Az eddigiekben nem beszéltünk arról, hogy hogyan detektáljuk a hibát. Az, hogy a szerver leállt,
vagy nem elérhető ugyanazt jelenti a másik oldal számára, így a detektálás sima időtúllépésen
alapul. Rendszerszinten azonban nem mindegy, hogy a rendszer adott része leállt és ezért nem
érhető el, vagy működik ugyan de mondjuk hálózati hiba miatt nem érhető el.
Fontos Amikor egy rendszer több működő, de egymást el nem érő elemre esik szét hálózati
partíciónak nevezzük (network partition)
Amennyiben hálózati partíció lép fel (vagy túl kevés időt várunk a szerver válaszára ami tulajdonképpen
identikus hatású) akkor a 3.42 ábra A felén látható módon két párhuzamos rendszerre esik szét
a rendszerünk ahol a kliensek más-más állapotot fognak látni. Egy megoldás a fenti problémára,
3.42: Hálózat partíció párhuzamos futás, többségi protokoll
ha dönteni tudunk arról, hogy a működő ágak közül melyiket tekintjük helyesnek. Ennek egyik
megvalósítása a többségi elven történő döntés. A 3.42 ábra B felén láthatjuk, hogy a rendszerbe
még egy szervert vonunk be. Ekkor az a partícióm mehet tovább ahol a többség van.
Már majdnem jó a megoldásunk de nem tudja egyszerre kelezni a partíciót és az összeomlást.
A 3.43 ábrán A oldalán látható, hogy helytelen detektálás esetén (többen gondolják magukat
vezetőnek) még mindég inkonzisztens állapot alakulhat ki. Esetünkben S1 és S2 is állapot üzenetet
küld S3 -nak akinek a többségről döntenie kellene. Mivel S3 újraindul nem tudjuk, hogy melyik
3.43: Hálózat partíció párhuzamos futás, többségi protokoll
többséget szavazta meg (a gond nem ez, hanem, hogy közben köztes információt küldött C2 -nek).
Egy megoldás a fenti problémára, ha kizárjuk a több vezető egyidejű meglétét. A vezető csere előtt
az a szerver amely vezetőnek érzi magát előbb megígérteti a többi szerverrel, hogy a régi vezetőtől
nem fogadnak el üzeneteket. Csak ezen ígéretek (a többség) beérkezte után kezd el üzeneteket
fogadni az új vezető. Ezt láthatjuk a 3.43 ábrán B oldalán. Itt annak érdekében, hogy a vezetők
megkülönböztethetőek legyenek egy-egy azonosítót kapnak. Az ígérethez a hPREP, S2 i és az erre
érkező hPROM, −, S2 i üzenet kéri és erősíti meg. Annak érdekében, hogy tudják a többiek az
eddigi abszolút sorrendet, az elfogadott üzeneteket is elküldik (ez most üres .- jel a prom üzenetben).
Ha ez nem üres akkor az új vezető ezekre újra küldi az elfogadó üzenetet, hogy ezt az információt
elterjessze.
3.44: 5 szerveres működés
Amikor két partíció összeolvad akkor a vezető újraküldi az elfogadás üzeneteket azoknak a
szervereknek amelyek még ezt nem kapták meg. Előfordulhat, hogy az összeolvadt partíció
most több vezetővel is rendelkezik. A döntést itt prioritás segítségével lehet egyértelművé tenni.
Ez a fix prioritásos megoldás azonban adott szervereket bebetonozhat. A Paxos algoritmus ezért a
folyamat körökre van osztva és minden körhöz előre ki vannak jelölve azok a szerverek akik akkor
beszélhetnek (pl.: S1 1, 4, 7 körökben szólhat, az S2 2, 3, 6 körökben szólhat...)
A bemutatott megoldás 2 f + 1 szerver esetén f leállását tudja tolerálni amennyiben gondoskodunk
az információ elterjedéséről. A kliensek C1 ,C2 minden szervernek elküldik az üzenetet és a
szerverek csak akkor haladnak tovább ha a többségtől (itt most 3) megkapták a nyugtát. A
tranzakciót tehát a vezető indítja, de mindenki mindenkivel kommunikál és 3 egyetértés esetén
3.7 Videó 63
fogadják el azt.
3.7 Videó
Az internet legtöbb forgalmat produkáló alkalmazása a videó megosztás. E szolgáltatás ma már a
klasszikus televízió szolgáltatásokat is lassan lecseréli. A videótékák megszűntek, helyettük számos
online platform kínál videó nézési lehetőséget. Sokan úgy keresnek pénzt, hogy érdekes, nézett
videókat gyártanak és az ezekhez kapcsolt reklámok bevételéből részesednek. A videó szolgáltatás
tehát ma az egyik legnépszerűbb szolgáltatás az Interneten. A továbbiakban megnézzük ennek a
jelenleg is alkalmazott technológiai hátterét.
3.7.1 Videó tömörítés

Egy-egy videófolyam nagyon nagy adatmennyiséget jelent. Gondoljunk bele, hogy a ma népszerű
4k felbontás képkockánként 4096x2160 képpontot jelent, amelyek 36 biten ábrázolják a színeket,
azaz egy képkocka 39 MByte adatot jelent. Ez másodpercenként csak 24 képkockával számolva is
majdnem 1000 MByte/sec átviteli sebességet jelent. Bár a hálózat jelentős átviteli kapacitással bír,
de ez még nem igazán elérhető. Így szükség van az átvitel optimalizálására. Ennek ma alkalmazott
módja a tömörítés. Ezek segítségével 20-30 MBit/sec átviteli igénnyel lehet ma már ilyen minőségű
videókat átvinni. A videó tömörítésére két lehetőségünk is van:
• térbeli redundancia: Egy-egy képkockán adott részek például azonos színűek, ezt az
információt nem kell egyesével átvinnünk, hanem például azt is mondhatjuk, hogy 10
darab zöld színű pixel következik. Ettől persze jóval bonyolultabb és hatékonyabb eljárások
is vannak.
• időbeli redundancia: Videó esetén egymást követő képeink vannak. A természetben az
ritkán fordul elő, hogy egymás után teljesen más képkockák következnek. Gyakran adott
közös háttérrel adott objektumok mozognak, ekkor a hátteret és az objektumokat sem kell
másodpercenként 24-szer átvinni, hanem elegendő az objektum mozgását lekövetni és az
útvonalat átvinni.
A videó tömörítésre számos szabadon használható és szabadalommal védett eljárás van. Az
alkalmazott tömörítés függ a lejátszó platformtól és annak környezetétől is. A következőkben a
platform megoldást ismerjük meg. Jóval bővebb ismertetés található ebben a könyvben [5] mely a
h264-es tömörítést mutatja be.
3.7.2 Videó folyam

Az előző fejezetben láthattuk a videó tömörítés egy nagyon tömör ismertetését. A 4k felbontás
esetén számított sávszélesség igény nem feltétlenül áll mindenhol rendelkezésre és nem is biztos,
hogy egy kis kijelzős telefonon érdemes 4k tartalmat ilyen módon letölteni. A felhasználók
jellemzően azonnal szeretnék a filmet és nem várnak 1-2 órát, mire az letöltődik. Fontos tehát
a videófolyamok kezelése ahol a videó folyamatosan töltődik le és a lejátszó ezt folyamatosan
játssza le. Itt fontos még az alkalmazkodási képesség is. Ha nagyobb a sávszélesség, akkor
legyen jobb minőségű a videó, ha meg kisebb, akkor csökkenjen a minősége (a nézők jobban
elviselik a minőségromlást mint a szaggató, de jobb minőségű videót). A mai népszerű videó
kiszolgáló platformok kliens, azaz lejátszó vezérlésűek. A szerver nem sokat gondolkodik, amit
kérnek azt elküldi. Ezzel a megoldással lesz a rendszer robosztus és skálázható. Annak érdekében,
hogy a letöltés egyszerűbb algoritmussal legyen kezelhetőbb, a videókat adott méretű darabokra
bontják. Ezen darabokat kéri el a lejátszó egymás után. A beállítástól függően egy kicsit igyekszik
az aktuális játszott darab előtt járni, ez a lejátszási gyorsítótár (playout buffer). A szerver
úgy tud különböző felbontási igényeket kiszolgálni, hogy egy-egy videót több felbontásban is
eltárol (tipikusan 2-4 változat). A videók darabokra vannak bontva és a lejátszó mérve a saját
aktuális sávszélességét jobb vagy rosszabb minőségű film darabot kér a szervertől. Ezen koncepció
megvalósítása a HTTP felett a DASH (Dynamic Adaptive Streaming) protokoll. A böngésző
HTTP protokollon elkéri a videó mester lejátszási listáját (pl.: m3u8 formátumban) ez tartalmazza
az egyes felbontású videók lejátszási listáját (egyszerű szövegfájl, lásd a lenti ábrán) amelyek
magukat a fájl darabok hivatkozásait (URL) tartalmazzák. Ezeken az URL-eken lévő erőforrásokat
kéri el ezután a böngésző HTTP protokollon megfelelő GET kérés segítségével. A videó lejátszás
3.45: Videólejátszási lista és lejátszási lista hierarchia
egy olyan terület ahol kiemelten fontos a CDN alkalmazása, mivel egy központi szeverből, helyről
nem igazán lehetne a nagyszámú és nagy adatforgalmi igényű felhasználót kiszolgálni, így a videók
kiszolgálása a mai CDN megoldások egyik legfontosabb szolgáltatása. Egy gyakorlati példa mentén
szemléltetve látható a DNS és a HTTP infrastruktúra használatával megvalósított CDN kiszolgáló
által biztosított videó lejátszást.
3.46: CDN-nel támogatott videókiszolgáló példa1

1. Hol futnak a hálózati alkalmazások? Szemléltesd az alkalmazás és a hálózat viszonyát egy
ábrával!
2. Írd le kliens/szerver architektúra és a P2P architektúra alapvető elveit, különbségeit!
3. Írd le a Socket - szoftver csatorna szerepét és a viszonyát a processzukohoz!
4. Milyen szolgáltatásokat lehet az alkalmazások részére biztosítani a hálózatnak?
5. Vesd össze röviden az TCP és az UDP szolgáltatásait!
6. Írd le a WWW alap protokolljainak szerepét (HTTP, URI/URL, HTML)!

7. Írd le a HTTP alap működését, beleértve az állapot kezelést és a sütiket is!
8. Írd le a HTTP kérés/válasz formátumot!
9. Írd le a fontosabb HTTP metódusokat és ezek szerepét!
10. Írd le a web proxy szerverek jelentőségét, működését hogyan játszik ebben szerepet a
feltételes GET?
11. Írd le az SMTP felépítését, elemeit, működését!
12. Vesd össze a POP3 és az IMAP protokollt!
13. Ismertesd az email titkosítását, digitális aláírását, tartalom védelemmel ellátását (PGP)!
14. Mi a DNS szerepe, legfontosabb szolgáltatásai?
15. Miért elosztott a DNS?
16. Írd le a DNS hierarchia alapelemeit, felépítését!
17. Szemléltesd a DNS feloldást egy példával!
18. Milyen DNS biztonsági problémákat ismerünk?
19. Vesd össze a kliens szerver és P2P architektúra (fájl megosztás esetén)!
20. Írd le a fontosabb BitTorrent elveket, megoldásokat!
21. Ismertesd a videó tömörítés alapjait!
22. Ismertesd a DASH protokollt!
23. Írd le CDN motivációját, típusait!

[1] Ron Aitchison. Pro DNS and BIND 10. Berkeley, CA: Apress, 2011. ISBN: 978-1-4302-3049-6.
DOI : 10.1007/978- 1- 4302- 3049- 6_3. URL : https://doi.org/10.1007/978- 1-
4302-3049-6_3 (cited on page 54).
[2] Google. Introduction to HTTP/2. 2018. URL: https://developers.google.com/web/
fundamentals/performance/http2 (visited on 05/30/2020) (cited on page 46).
[4] Hein Meling and Leander Jehl. “Tutorial Summary: Paxos Explained from Scratch”. In:
Proceedings of the 17th International Conference on Principles of Distributed Systems
- Volume 8304. OPODIS 2013. Nice, France: Springer-Verlag, 2013, pages 1–10. ISBN:
9783319038490. DOI: 10.1007/978-3-319-03850-6_1. URL: https://doi.org/10.
1007/978-3-319-03850-6_1 (cited on page 59).
[5] Iain E. Richardson. The H.264 Advanced Video Compression Standard. 2nd. Wiley Publishing,
2010. ISBN: 0470516925 (cited on page 63).
[6] Lorenzo Spyna. An OAuth 2.0 introduction for beginners. 2018. URL: https://itnext.
io / an - oauth - 2 - 0 - introduction - for - beginners - 6e386b19f7a9 (visited on
05/30/2020) (cited on page 45).
[7] Yvonne Wilson and Abhishek Hingnikar. Solving Identity Management in Modern Applications:
Demystifying OAuth 2.0, OpenID Connect, and SAML 2.0. Jan. 2019. ISBN: 978-1-4842-5094-5.
DOI : 10.1007/978-1-4842-5095-2 (cited on page 45).


Tisztában van Megkülönbözteti a az Hajlandó az Önállóan feltérképezi
az alkalmazás alkalmazás rétegben ismertetett a hálózati
réteg feladatával ismertetett főbb alkalmazás rétegbeli alkalmazások
és a hálózati protokollokat. protokollokon közötti kapcsolatokat
alkalmazások túl továbbiak és az ott alkalmazott
alapjaival. megismerésére. protokollokat,
Azonosítja az szabványokat.
alkalmazás
architektúrákat
és érti működésüket.
Ismeri a Web
és a HTTP főbb
jellemzőit. Felsorolja
a legismertebb
levelezési
protokollokat (IMAP,
POP3, SMTP),
és megnevezi
alkalmazási
területüket.
Tisztában van a Bemutatja és elemzi Kritikusan Önállóan képes
DNS protokoll a kliens-szerver és figyeli meg már saját hálózatában a
alkalmazásával, P2P architektúrákat. ismert hálózati DNS beállításokat
valamint képes alkalmazások ellenőrizni.
megnevezni a működését és
DNS hierarchia architektúráját.
szintjeit. Ismeri a
P2P fogalmat, és meg
tud nevezni néhány
alkalmazási területet.
2
Általános rész
4 Szállítási réteg 69
5 Hálózati réteg 101

6 Adatkapcsolati réteg 127

6.1 Bevezetés
6.7 Ethernet
6.8 VLAN
6.13 WiFi
6.15 Mobilitás

4. Szállítási réteg

• IoT rendszerek esetén UDP felett kell gyakran adott szintű megbízható átvitelt megvalósítani.
• A TCP ma a legtöbb adatkapcsolat alapja, nem egyformán viselkedik adott fizikai közegek
felett, ennek finomhangolása fontos az IoT területén (pl.: NAT timeout).

Az alkalmazási és a hálózati réteg között található az ún. szállítási réteg, amely a réteges
hálózati architektúrának egyik központi alkotóeleme. Ez a réteg biztosítja közvetlenül a különböző
gépeken futtatott alkalmazás processzusok felé a logikai kommunikációt, amelyet a hálózati
rétegbeli kommunikációra épít. A kommunikáció alapelemei a gyakorlatban alkalmazott Internet
protokollokban is megtalálhatóak, a TCP-ben és az UDP-ben. Jelen fejezet terjedelmi korlátok
miatt csak a legfontosabb ismereteket mutatja be, a referencia könyv [1] 3. fejezetének (215-333)
olvasása ez esetben is javasolt.

4.1.1 A szállítási réteg alapelvei
Fontos A szállítási réteg felel a különböző végrendszereken futtatott alkalmazás processzusok

közötti logikai kommunikációért.
Az alkalmazások szemszögéből vizsgálva ez olyan, mintha a különböző végeszközökön futtatott

alkalmazások közvetlen kapcsolatban állnának egymással. Természetesen, a valós életben ezek a
végpontok a legritkább esetben sem állnak közvetlen kapcsolatban egymással; forgalomirányítók
és kapcsolódási formák sokaságán keresztül átívelő kommunikációról beszélünk. A szállítási
réteg által megvalósított logikai kommunikáción keresztül történik meg a processzusok közötti
üzenetváltás, a fizikai infrastruktúra részleteitől függetlenül.
Mint azt a 4.1 ábra is mutatja, a szállítási rétegbeli protokollok a végrendszereknél vannak
implementálva, de hogyan? A szállítási réteg a küldő oldalon a küldő alkalmazás processzus által
70 4. fejezet - Szállítási réteg
alkalmazás
szállítás
hálózat
adatkap.
fizikai
alkalmazás
szállítás
hálózat
adatkapcs.
fizikai
4.1: Logikai vég-vég kommunikáció1
kibocsátott - alkalmazás rétegbeli - üzenetet konvertálja át szállítási rétegbeli csomagokká. Ezeket

az Internet nevezéktana szerint szegmenseknek nevezzük. A konverzió során fontos az üzenet
megfelelő méretű feldarabolása. Mivel a küldő processzus üzenetei nagy méretűek is lehetnek, így
ezek jellemzően nem egy nagy darabként kerülnek továbbításra, hanem kisebb méretű csonkok
formájában. A feldarabolt üzenet csonkokat egy-egy szállítási rétegbeli fejléccel látunk el, melynek
eredménye a szállítási rétegbeli szegmens. Ezeket a szegmenseket továbbítja a küldő szállítási
rétege a küldő hálózati rétege felé, ahol további hálózati rétegbeli információkat rendelünk a
csomaghoz.
4.1.2 A szállítási réteg és más rétegek kapcsolatai
Fontos Fontos megemlíteni, mivel a szállítási réteg végrendszereken van implementálva, a

forgalomirányítók nem vizsgálják a csomag szállítási rétegének tartalmát.
A fogadó oldalon a hálózati réteg kibontja a szállítási rétegben található szegmenst és továbbítja azt
a szállítási réteg felé. A fogadott szegmenst a szállítási réteg feldolgozza, és a benne lévő tartalmat
továbbítja a fogadó alkalmazás processzus felé.
Az egyszerűbb megértés végett tekintsük az alábbi analógiát! Vegyünk két nagy családi házat,
amelyek elhelyezkedése az ország két egymástól legtávolabbi pontján található. Mindkét ház
egy-egy tucatnyi gyermeknek ad otthont, azonban a két házban élő testvérek egymással szoros
rokoni kapcsolatban állnak. A gyermekek szeretnek egymással levelezni, így minden héten írnak
egymásnak, a leveleket pedig postai úton küldik az ország egyik pontjából a másikba. Így mindkét
háztartás 144 levelet küld az ország másik végébe. Mindegyik háztartásban van egy-egy kijelölt
személy (Anna és Botond), aki felel a levelek összegyűjtéséért és kézbesítéséért. Az összegyűjtött
elküldendő leveleket el kell vinni a postára, a megérkezett leveleket pedig a címzett testvéreknek
át kell adni. Ebben a példában Anna és Botond valósítja meg a logikai kommunikációt a rokonok
között azzal, hogy a küldésre szánt leveleiket összegyűjtik és eljuttatják a posta felé, illetve a
postától beérkező leveleket eljuttatják a címzett testvérekhez. Mindketten a végpontokon vannak,
és szerves részei a kommunikációnak. Ha az analógiát tovább bontjuk alkotóelemekre, akkor az
alábbi megfeleltetések igazak.
4.2 Multiplexelés/Demultiplexelés 71
• alkalmazás üzenetek = levelek a borítékokban

• alkalmazás processzusok = testvérek
• végrendszerek = házak
• szállítási rétegbeli protokoll = Anna és Botond
• hálózati rétegbeli protokoll = posta (beleértve a kézbesítőket is)
A szállítási réteg szolgáltatásai a fentebb leírtakon túl - protokolltól függően - eltérőek lehetnek.
Például, az Internet két szállítási rétegbeli protokollja (a TCP és az UDP) különböző szolgáltatás
halmazokkal bír.
4.1.3 A szállítási réteg és az Internet

Az Internet két, egymástól eltérő szállítási rétegbeli protokollt kínál az alkalmazási rétegnek. Az
egyik az UDP (User Datagram Protocol), a másik pedig a TCP (Transmission Control Protocol).
Az UDP egy megbízhatatlan, nem rendezett kézbesítést nyújtó protokollt valósít meg, amely
tulajdonképpen a hálózati rétegbeli IP (Internet Protocol) legjobb szándék szerinti továbbításnak
(best effort) egy sallangmentes kiegészítése. Ezzel szemben a TCP nemcsak egy megbízható,
kapcsolatorientált megvalósítást biztosít, hanem ezt kiegészíti olyan képességekkel is, mint a
torlódásvezérlés és a folyamvezérlés. Mindkét protokoll alapvető feladata kiegészíteni a hálózati
réteg IP protokolljának kézbesítési szolgáltatását oly módon, hogy ne csak végrendszerek között
valósulhasson meg a kézbesítés, hanem a különböző végrendszereken futó alkalmazás processzusok
között is.
Fontos A processzus-processzus adatáramlást nevezzük a szállítási rétegbeli multiplexelésnek

és demultiplexelésnek.
Ahogy azt korábban tárgyaltuk, a szállítási réteg fogadja a szegmenseket a hálózati rétegtől,
melyeket kibontva és továbbítva az alkalmazás processzusokhoz jut az adat. Azonban egy
végrendszeren egy adott időpillanatban nem csak egyetlen processzus fut, így nem triviális, hogy
az üzenetet hogyan juttassuk el a kívánt processzushoz. Tekintsük az alábbi példát!
Tegyük fel, hogy egy felhasználó a számítógépe mögött ül, amelyen meg van nyitva egy
böngészőben egy web-oldal, eközben pedig él egy FTP és két Telnet kapcsolat is. Így összesen
négy aktív processzus van - egy HTTP, egy FTP és két Telnet. A szállítási réteg felel azért, hogy a
beérkező adat a négy processzus közül a megfelelőhöz eljusson... de hogyan?
Minden processzusnak van egy vagy több szoftvercsatornája (socket), amelyek mintegy
"ajtóként" funkcionálnak. Ezeken a csatornákon át jutnak az adatok a hálózatból a processzusba és
a processzusból a hálózatba. Mivel a végrendszeren egyidejűleg több szoftvercsatorna is élhet, így
a megkülönböztetés végett mindegyik csatorna rendelkezik egy egyedi azonosítóval. Az azonosító
formátumát a szállítási rétegbeli protokoll határozza meg. A beérkező szegmensben dedikált
fejléc mezők biztosítják azt, hogy az adat a megfelelő csatornába kerülhessen. Az adat megfelelő
csatornába juttatását nevezzük demultiplexelésnek. A fordított irányú adatáramlást - amikor az
adat csonkok fejléc információkkal szegmenseket alkotva a hálózati rétegbe jutnak - azt nevezzük
multiplexelésnek (4.2 ábra).
A korábbi fejezetben bevezetett analógiánkhoz visszatérve, tekintsük át a multiplexelés és
demultiplexelés folyamatát! Anna és Botond felel küldés esetén a levelek összegyűjtéséért, azok
postai feladásáért, fogadás esetén pedig a postástól átvett levelek szétosztásáért, hogy azok a
címzett személyhez kerülhessenek. Jelen analógiában Anna és Botond az, akik a multiplexelés és
demultiplexelés folyamatáért felelnek. A testvérek által feladni kívánt levelek összegyűjtése, és azok
eljuttatása a postára a multiplexelés művelet jelen forgatókönyv szerint. A küldemények átvétele, és
alkalmazás
alkalmazás P1 P2 alkalmazás szoftvercsatorna

P3 szállítási
P4
processzus
szállítási hálózati szállítási
hálózati adatkapcsolati hálózati
adatkapcsolati fizikai adatkapcsolati
fizikai fizikai
4.2: Multiplexelés és demultiplexelés1
azok átadása a címzett személy kezébe a demultiplexelés művelet.

Ahogy azt tárgyaltuk, a multiplexeléshez szükségünk van egy egyedi szoftvercsatorna azonosítóra,
illetve a szegmens fejlécben olyan mezőkre, amelyek leírják, hogy mely csatornába kell a szegmenst
juttatni. Ezeket a mezőket nevezzük forrás és cél portszám mezőknek. Minden portszám egy 16
bites szám a 0-65535 intervallumból. A portszámok nagy intervallumát két részre bonthatjuk. A
0-1023 közötti portszámok az ún. "bűvös" portszámok, amelyek használatára korlátozás áll fenn,
ugyanis ezeket az ismert alkalmazás rétegbeli protokollokhoz kötik (például HTTP használja a
80-as portot, FTP a 21-es portot). Az 1024 és 65535 közötti portok az ún. "szabad" portszámok,
amelyek használatára vonatkozó megszorításról nem szól szabvány. A portszámok azok az egyedi
azonosítók, amelyeket a szoftvercsatornákhoz rendelődnek hozzá, és azonosítják a processzust. Az
UDP és a TCP esetében a multiplexelés és a demultiplexelés egymástól eltérő módon történik, de
alapjaiban a korábban tárgyaltak igazak mindkét protokollra.
4.2.1 Kapcsolatmentes multiplexelés és demultiplexelés
Egy processzus, amely üzenetet szeretne küldeni egy másik processzusnak, tetszőlegesen nyithat
egy UDP csatornát. Egy csatorna létrejöttekor, a szállítási réteg automatikusan hozzátársít egy
olyan szabad portszámot az 1024-65535 intervallumból, amely az adott időpillanatban nincs más
processzushoz rendelve a kliens végrendszerén. Szerver oldalon a csatorna nyitás egy picit eltérő
módon történik, ugyanis a szerveren futó processzus megszólításához a kliensnek ismernie kell az
ott elérhető portszámot. Ezért jellemzően a szerver oldalon az alkalmazásban specifikált portszámon
történik a csatorna nyitás. Az UDP csatornák portszámának ismeretében tökéletesen leírható az
UDP multiplexelés és demultiplexelés.
Tekintsük meg a 4.3 ábrát! Az A számítógépen futó processzus adatcsonkot szeretne küldeni a
45124-es porton keresztül a B szervernek a 8080-as portján hallgató processzusához. Az A oldalon
a szállítási rétegben létrejövő szegmens tartalmazza az alkalmazás által küldeni kívánt adatot,
valamint a forrás (45124) és cél (8080) portszámokat. A létrejött szegmens továbbításra kerül a
hálózati réteg felé, ami a szegmenst beburkolja egy IP datagramba, majd továbbítja azt a fogadó
szerver felé. A B szerver által fogadott datagramból a szegmenst feldolgozza a szállítási réteg, és a
fejlécben megjelölt cél portszám (8080) alatt futó csatornába juttatja.
Az UDP csatornák egyértelműen azonosíthatóak egy cél IP-cím és cél portszám kettőssel.
Így kijelenthetjük, hogy a különböző forrásokból ugyanarra az IP-cím és port párosra érkező
szegmensek ugyanazon a csatornán keresztül ugyanabba a processzusba jutnak. Ettől függetlenül a
forrás IP-cím és portszám is fontos, hiszen ez alapján küldhető válasz üzenet.
4.3 Kapcsolatmentes átvitel: UDP 73
Kliens processzus
A hoszt Szoftvercsatorna B szerver
Forrás port Cél port

45124 8080
Forrás port Cél port

8080 45124
4.3: Kapcsolatmentes multiplexelés és demultiplexelés1
4.2.2 Kapcsolatorientált multiplexelés és demultiplexelés

A TCP multiplexelés és a demultiplexelés megértéséhez előbb rövid betekintést kell nyernünk a
TCP csatornák és a TCP kapcsolat kiépítés működésébe. Az UDP-nél láttuk, hogy a cél IP-cím
és portszám együtt elegendő a csatorna és a processzus azonosításához. A TCP-nél ez kibővül
további két információval, a forrás IP-címmel és a forrás portszámmal. Az így alkotott számnégyes
alkalmazásával levonható az a következtetés, hogy a különböző forrásokból érkező TCP szegmensek
különböző csatornába kerülnek továbbításra.
Tekintsük az alábbi példát (4.4 ábra)! Az A kliens egy HTTP kapcsolatot kezdemény a B
szerverrel, míg a C kliens egyidejűleg két HTTP kapcsolatot tart fenn ugyancsak a B szerverrel.
Tegyük fel, hogy mindhárom résztvevő rendelkezik egyedi IP-címmel. A C kliensnél a két HTTP
kapcsolathoz a 26145-ös és a 7532-es portot foglalta le. Az A kliens automatikusan választ
portszámot a HTTP kapcsolatához a szabadok közül. Így előfordulhat, hogy az A kliens szintén
a 26145-ös porton keresztül továbbítja a szegmenst a hálózati réteg felé. A B szerver ebben az
esetben is képes demultiplexálni a beérkező szegmenst, hiszen a forrás IP-cím eltérő.

Első megfontolásból tervezhetnénk egy igazán egyszerű, sallangmentes szállítási rétegbeli protokollt,
amely a küldő oldalon csak fogadja az üzenetet a processzustól, és továbbítja azt a hálózati rétegnek,
a fogadó oldalon pedig a hálózati rétegtől átvett szegmenst a megfelelő csatornába juttatja. Az
UDP pontosan annyit csinál csak, amennyit egy szállítási rétegbeli protokollnak mindenképp
kell. Fogadja az üzenetet a processzustól, felruházza a forrás és cél portszámokkal, valamint két
további apróbb mezővel kiegészíti, és továbbítja a hálózati réteg felé. Az RFC 768 szabvány
definiálja a protokollt. Mivel a küldést megelőzően nincs kapcsolat kiépítési folyamat, ezért
kapcsolatmentesnek nevezzük. Tipikus UDP-t használó alkalmazás rétegbeli protokoll a DNS.
Ennél fogva nincs kapcsolat kiépítéséért felelős "kézfogás" a kliens és a szerver között, így nincs
visszajelzés sem, ha a küldött csomag elveszett. Másik jellemző UDP-t használó alkalmazás
kategória a médiafolyam alkalmazások csoportja, ahol egy alkalmazásnak akkor is működnie kell,
ha nem garantálható az alacsony késleltetés, vagy ingadozó a sávszélesség.
Joggal felmerül a kérdés, hogy akkor mégis miért vagy épp milyen esetekben használna egy
Kapcsolatonkénti HTTP processzusok
B web-szerver
C hoszt
Forrás port: Cél port: Forrás port: Cél port:

7532 80 26145 80 demultiplexálás
Forrás IP: Cél IP: Forrás IP: Cél IP:
C B C B
A hoszt
Forrás port: Cél port:

26145 80
Forrás IP: Cél IP:
A B
4.4: Kapcsolatorientált multiplexelés és demultiplexelés1
szoftverfejlesztő UDP-t? A válasz: attól függ... Az UDP mellett szólnak az alábbi érvek:
• kifinomult alkalmazás szintű vezérlése annak, hogy milyen adatot és mikor küldünk,
• nincs kapcsolat kiépítés, így gyorsabb,
• nincs kapcsolatállapot sem a küldőnél, sem a fogadónál, amely további mezők és értékek
kezelését igényelné, kicsi fejléc méret.
4.3.1 UDP szegmens struktúra

Az UDP szegmens struktúrája az RFC 768-ban definiált. Felépítése roppant egyszerű, mindösszesen
négy fejléc mezőt és egy alkalmazás adatot (üzenetet) tartalmaz (4.5 ábra). Az alkalmazás rétegből
érkező adat a data mezőben foglal helyet, ez az a rész, amely a csatornán keresztül a megfelelő
alkalmazás processzusba jut. A szegmens fejléc minden mezője 2-2 bájtot foglal. Mint azt korábban
tárgyaltuk, a forrás és cél portszámok (source port és destination port) segítik a szállítási réteget
abban, hogy az adat a megfelelő csatornába és alkalmazás processzusba kerüljön a végrendszereken.
A hossz (length) mező mutatja meg explicit módon a szegmens teljes méretét bájtokban megadva,
mely tartalmazza a fejlécben levő információkat és az alkalmazás adatot is. Ennek tárolása azért
fontos, mert a különböző UDP szegmensek különböző méretű adat részeket tartalmazhatnak. Az
ellenőrző összeg (checksum) segíti a fogadó host-ot a hibadetektálásban. Az ellenőrző összeg
felépítéséről és működéséről a következő fejezetben beszélünk.
32 bit
forrásport # célport #
hossz ellenőrzőösszeg
alkalmazás adat
(tartalom)
4.5: UDP szegmens struktúra1

4.3 Kapcsolatmentes átvitel: UDP 75
4.3.2 UDP ellenőrző összeg

A korábbi fejezetekben megismerkedtünk az UDP működésével és a szegmens struktúrájával. A
tanultak alapján levonhatjuk azt a következtetést, hogy az UDP valóban egy minimalista protokoll,
amely pontosan annyit nyújt, amennyit egy szállítási rétegbeli protokollnak kell. Azonban az ördög
nem alszik. . .
Mint minden rendszerben, egy hálózatban is előfordulhatnak hibák (például zaj keletkezik),
amelyeket kezelni kell a hibás információáramlás elkerülése vagy esetleges javítása végett. Az UDP
egyszerűségén túl azonban ez a protokoll is rendelkezik hibadetektáló képességgel. Ezt hivatott
ellátni az ún. ellenőrőzösszeg (checksum), amelynek dedikált mezője van az UDP fejlécben.
Tekintsük meg az ellenőrző összeggel történő hibadetektálás menetét!
A küldő készíti el az ellenőrző összeget, amelyet a szegmens tartalma alapján állít elő. A teljes
szegmenst (beleértve a fejlécet is) 16 bit hosszúságú szavakra bontja. Az így kapott n darab 16
bit hosszú szónak veszi az összegét (a túlcsordult bitek az alacsonyabb helyiértéken levő bitekhez
adódnak hozzá), majd az eredményül kapott összeg 1-es komplemensét állítja elő.
Tekintsük meg ezt egy példán keresztül is!
Tegyük fel, hogy az előállt UDP szegmens az alábbi három 16 bit hosszúságú szóval egyenlő.
(Az összeadást jobbról balra folytatjuk!)
Példa 4.1 — Ellenőrző összeg.
0110011001100000 // 1. szó
0101010101010101 // 2. szó
1000111100001100 // 3. szó
Az első két szó összegeként az alábbi eredményt kapjuk.
0110011001100000 // 1. szó
0101010101010101 // 2. szó
————————
1011101110110101 // összeg
Most adjuk hozzá az összeghez a 3. szót is!
1011101110110101 // 1-2. szó összege

1000111100001100 // 3. szó
————————
0100101011000010 // végeredmény
(Az utolsó összeadásnál vegyük figyelembe, hogy az eredmény túlcsordult, így a sor elejére
kerülő 1-es bitet a sor végére mozgatjuk, és ennek megfelelően korrigáljuk jobbról balra haladva
ismét az értékeket.) Most vegyük a végeredményül kapott 16 bites egésznek az 1-es komplemensét,
azaz minden 0-t írjunk át 1-esre, és minden 1-est 0-ra.
Az így kapott ellenőrző összeg: 1011010100111101.

Ez az a szám, amely bekerül az elküldött UDP szegmens ellenőrző összeg mezőjébe. A fogadó
oldalon az ellenőrző összeg segítségével detektálható a hiba. De hogyan? A fogadó fél szintén
kiszámítja a fogadott UDP szegmens ellenőrző összegét, majd a kiszámított ellenőrző összeghez
hozzáadja a fogadott szegmensben lévő ellenőrző összeget. Hibamentes csomag esetén a két
ellenőrző összeg összeadásának eredménye 1111111111111111 kell, hogy legyen. Amennyiben

csak egyetlen bit is 0, úgy a fogadott csomagban hiba van.
Természetesen hibadetektálás más hálózati rétegekben is létezik, azonban a szállítási rétegbeli
ellenőrző összeg a vég-vég kommunikáció hibaellenőrzésében segít. Hozzá kell tennünk azt is,
hogy ezzel a módszerrel csupán a hibát detektáltuk, hibás csomag esetén megoldást még nem
nyújtottunk. Ez motiváljon bennünket abban, hogy betekintést nyerjünk a megbízható adatátvitel
rejtelmeibe!

Ha az adatátvitel megbízhatóságát egy általános kontextusban értjük, akkor nem csupán a szállítási
réteg az, ahol ez kardinális kérdés, hanem helyet foglal más rétegekben is, mint például az
alkalmazás réteg és az adatkapcsolati réteg. Ha a hálózatok és az adatátvitel kérdésköréről beszélünk,
biztosak lehetünk abban, hogy a megbízhatóság a 10 legfontosabb témák egyikeként kap helyet.
Ezért is fontos erről beszélnünk, és egy megoldást nyújtanunk a szállítási rétegben, hogy a felsőbb
rétegeknek biztosítani tudjunk egy olyan megbízható csatornát, amin a keresztül áramló bitek
helyes formában, veszteség nélkül és megfelelő sorrendben érkeznek meg. Ezt hivatott ellátni a
TCP az Internet alkalmazások felé.
A következő fejezetekben lépésenként fejlesztünk ki egy megbízható adatátvitelt biztosító
protokollt, amelynek komplexitása fokozatosan növekszik. Ehhez építsük a protokollt a nem
megbízható IP-re, azaz az alsóbb rétegeket tekintsük egy nem megbízható pont-pont összeköttetésként.
Feltevésünk az, hogy a csomagok küldés sorrendjének megfelelően kerülnek továbbításra egész
addig, amíg az átvitel során egyes csomagok el nem vesznek, és az átvitel alapjául szolgáló csatorna
nem rendezi az újraküldést követően a csomagokat. A 4.6 ábra prezentálja az adatátvitelért felelős
protokoll interfészét.
rdt_send() adat adat deliver_data()
megbízható adatátviteli megbízható adatátviteli

protokoll (küldő oldal) protokoll (fogadó oldal)
udt_send() csomag csomag rdt_rcv()
megbízhatatlan
csatorna
4.6: Megbízható átvitel megbízhatatlan csatornán1
A megbízható adatátvitel protokollját nevezzük rdt-nek (reliable data transfer). A küldő oldal
meghívja az rdt_send()-en keresztül az átviteli protokollt. Az rdt hívja meg az udt_send() utasítást,
hogy továbbítsa az adatot a nem megbízható csatornán. A fogadó oldalon az rdt_rcv() utasítás
hívódik meg, amikor csomag megérkezik a csatorna fogadó oldalára. A deliver_data() felel azért,
hogy az adat a magasabb rétegbe jusson. (Mivel a fejlesztésünk nem csak az Internet szállítási
rétegére vonatkozik, hanem általánosságban a számítógép hálózatokra, ezért maradjunk a "csomag"
szó használatánál "szegmens" helyett.)
4.4.1 Adatátvitel egy tökéletesen megbízható csatornán: rdt1.0

Először tekintsük a legegyszerűbb esetet, amelyben az átviteli csatorna teljesen megbízható! A
küldő és fogadó egyedek leírásához FSM-eket fogunk használni, amelyek definiálják az résztvevők
4.4 A megbízható átvitel alapjai 77
műveleteit. Ahogy a 4.7 ábrán is látható, mind a küldőnek és a fogadónak is csupán egyetlen
állapota van. A nyilak hivatottak az állapotátmeneteket jelölni, amelyek jelen esetben ugyanabba
az állapotba viszik a gépeket. Az átmenetet kiváltó eseményeket leolvashatjuk az állapot melletti
címkéről, a vízszintes vonal felett, az esemény bekövetkeztekor végrehajtandó műveleteket pedig a
vonal alatt találjuk. Amennyiben nincs esemény vagy művelet egy átmenet során, akkor azt a ∧
jellel jelöljük a vonal felett vagy alatt. A szaggatott vonallal ellátott nyíl jelöli a kezdőállapotot.
A küldő oldalon az rdt fogadja az adatot a felsőbb rétegtől az rdt_send(data) eseményen
keresztül, majd előállítja a csomagot a make_pkt(data) művelettel, és továbbítja azt a csatornába
(udt_send(packet)).
A fogadó oldalon az rdt fogadja a csomagot a csatornából az rdt_rcv(packet) eseményen
keresztül, kibontja a csomagot az extract(packet,data) művelettel, és továbbítja a magasabb réteg
felé az adatot (deliver_data(data)). Mivel a küldés sebességére és a visszaigazolásra nem tettünk
megszorításokat, így ez a protokoll hibátlanul működik ebben a környezetben.
rdt_send(data) Várakozik rdt_rcv(packet)

Várakozik az alulról
a felső packet = make_pkt(data) jövő extract (packet,data)
hívásra
udt_send(packet) hívásra deliver_data(data)
küldő fogadó
4.7: Az rdt1.0 protokoll állapot automatái1
4.4.2 Adatátvitel egy bithibás csatornán: rdt2.0

Az előző megengedő feltevéseink apróbb megszorításaival egy realisztikusabb modellhez jutunk
el. Tegyük fel, hogy a csatorna biteket fordíthat meg. Ilyen hiba tipikusan a hálózat fizikai
komponenseiben fordulhat elő szállítás vagy pufferelés közben. Ugyanakkor továbbra is igaz az,
hogy a csomagok helyes sorrendben kerülnek kiküldésre és fogadásra is, csak a bitek sérülhetnek.
Ilyen szituációkban a küldőnek szükséges van az ún. visszacsatolásra, hogy értesüljön a csomagok
helyes vagy a helytelen megérkezéséről. Így a küldő fél tudja, hogy mely csomagok érkeztek meg
hibamentesen, és melyek hibásan. A hibás csomagokat újra kell küldeni.
Fontos A bithibák detektálásához három alapvető képességgel kell egy megbízható adatátviteli
protokollt felruházni: hibadetektálás, visszaigazolás és újraküldés.
• Hibadetektálás: a korábbi fejezetekre hivatkozva visszaemlékezhetünk a megbízhatatlan

adatátvitel alapjaira, ahol az ellenőrző összeg (checksum) pontosan ezt a célt szolgálta.
Ezekkel az extra bitekkel bővítjük az rdt2.0 protokoll csomagját.
• Visszaigazolás: mivel a küldő és a fogadó fél jellemzően nem ugyanazon rendszeren
található, hanem több száz vagy több ezer kilométer is lehet közöttük, a fogadott csomag
helyességéről és megérkezéséről kizárólag a fogadó fél tájékoztathatja a küldőt. Ezen explicit
visszaigazolások lehetnek pozitívak (ACK) sikeresség vagy negatívak (NAK) sikertelen
vagy helytelen kézbesítés esetén. Az rdt2.0 protokoll ilyen visszaigazolásokat küld a küldő
félnek vissza. A visszaigazoláshoz elegendő csupán egyetlen bit, 0, ha sikertelen (NAK) volt
a küldés, 1, ha sikeres (ACK).
• Újraküldés: az a csomag, amely a fogadó oldalon hibásan érkezett meg, azt a küldőnek újra
el kell küldenie a fogadó részére.
A 4.8 ábrán látható az rdt2.0 FSM reprezentációja.
A küldő oldalon az rdt2.0-nak két állapota van. Az kezdőállapotban (bal oldalon) a protokoll
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
fogadó
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Felső ACK-ra rdt_rcv(rcvpkt) &&
hívásra vagy NAK- udt_send(sndpkt) corrupt(rcvpkt)
vár ra vár
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Alsó
Λ
hívásra
vár
küldő
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
várja a felsőbb rétegből érkező adatot. Amikor az rdt_send(data) esemény bekövetkezik, a küldő
összeállít egy csomagot (sndpkt), amely tartalmazza az adatot (data), az ellenőrző összeget
(checksum). Az így összeállt csomagot a udt_send(sndpkt) művelettel elküldi. A második
állapotban (jobb oldalon) a küldő protokoll vár egy visszaigazolást a fogadó féltől, amely vagy
egy ACK (pozitív visszaigazolás) vagy egy NAK (negatív visszaigazolás) lehet. Amennyiben a
visszaigazolás pozitív (rdt_rcv(pkt) && isACK(rcvpkt)), a küldő tudja, hogy a csomag hibamentesen
érkezett meg, így visszatér a kezdőállapotba, és vár egy újabb adatot a magasabb rétegből. Ha a
küldő NAK visszajelzést kap, úgy a küldő a legutóbb kiküldött csomagot újraküldi, és vár egy újabb
visszaigazolásra. Fontos megjegyezni azonban, hogy jelen protokollban a küldő fél mindaddig nem
fogad adatot a magasabb rétegtől, amíg a kiküldött csomagra nem kap ACK visszacsatolást. Azokat
a protokollokat, amelyek így viselkednek, "állj meg és várj" protokolloknak nevezzük, ilyen az
rdt2.0 is.
A fogadó oldal egyetlen állapottal rendelkezik. Csomag érkezésekor egy ACK vagy NAK
visszaigazolást küld a küldő félnek, függően attól, hogy a csomag helyesen vagy helytelenül érkezett
meg. Az rdt_rcv(rcvpkt) && corrupt(rcvpkt) esemény jelöli az, amikor a csomag megérkezik a
fogadó félhez, de hibásan.
Az rdt2.0 látszólag már hibatűrő, azonban mégis rejt egy komoly problémát. Amivel nem
számoltunk, az az ACK vagy a NAK bithelyes továbbítása. Ebből a bajból azonban két alprobléma
is megjelenik: a bithibás visszaigazolás következtében nem ismert, hogy a fogadónál mi történt,
illetve fölösleges újraküldés esetén duplikátum keletkezhet a fogadónál. A duplikátumok fő
problémája az, hogy a fogadónak a szállítási rétegben kellene a csomagban lévő adatot ellenőriznie.
Ezért az újraküldött csomagok kezelésére bevezetünk egy ún. szekvencia számot (sorszámot),
amellyel az újraküldendő csomagokat könnyen nyomonkövethetjük. Ehhez egy új mezőt kell
felvennünk a protokoll fejlécében, amellyel a fogadó már be tudja azonosítani a csomagról, hogy
az egy újraküldött vagy egy új adatot tartalmazó csomag. A visszaigazolások sorszámozására nincs
szükség, mivel a csatornáról feltettük, hogy nem veszít el csomagot. A továbbfejlesztett protokoll
neve legyen rdt2.1. A 4.9 és a 4.10 ábrákon látható az FSM reprezentációja a továbbfejlesztett
protokollnak a küldő és a fogadó oldalon.
Az új protokollnak mind a küldő, mind a fogadó oldalon kétszer annyi állapota lett, ugyanis
a küldőnek követnie kell, hogy milyen sorszámmal küldte el a csomagot, a fogadónak pedig
nyugtáznia kell, hogy milyen szekvencia számú csomag érkezett. A sorszámozáshoz elegendő
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
0-s hívásra ACK-ra vagy isNAK(rcvpkt) )
vár felülről NAK 0-ra vár
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Λ
Λ
ACK-ra vagy
NACK 1-re 1-re vár
rdt_rcv(rcvpkt) && vár felülről
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1,

make_pkt data, checksum)
udt_send(sndpkt
sndpkt)
4.9: Az rdt2.1 protokoll állapot automatája a küldő oldalon1
egyetlen bit (0 vagy 1), hiszen ebből jól látszik, hogy az adott csomag egy újraküldött üzenet
(a sorszám nem változott a legutóbb fogadott csomaghoz képest) vagy egy új csomag érkezett
(a sorszám eggyel nőtt az előző fogadott csomag sorszámához képest). A fent leírt változások
követéséhez elég a modulo-2-aritmetika.
Az rdt2.1 kétféle visszaigazolást használ: ACK és NAK. Azonban, ha egy hibásan megérkezett
csomag esetén az utoljára helyesen megérkezett csomagra vonatkozó ACK-t küld vissza a fogadó a
küldőnek, akkor a küldő ugyanúgy értesíthető arról, hogy a legutóbb elküldött csomag nem érkezett
meg helyesen. Ehhez azonban a küldőnek ellenőriznie kell azt, hogy melyik csomagra érkezett
ACK. A új, NAK-mentes megbízható csatornát nevezzük rdt2.2-nek. Az állapot automaták a 4.11
ábrán láthatóak.
4.4.3 Adatátvitel egy bithibás és adatvesztő csatornán: rdt3.0

Korábbi megengedő feltevéseinket tovább megszorítva elérkeztünk ahhoz az esethez, ahol nem
csak bitek fordulhatnak meg, hanem csomagok is elveszhetnek. Ez már nagyon jól modellezi a
mai számítógép hálózatok működését, például az Internetét is. A megoldáshoz két kérdést kell
megválaszolnunk:
• Hogyan detektáljuk a csomagvesztést?
• Mit tegyünk, ha csomagvesztés történt?
Az utóbbi kérdésre az rdt korábbi verzióiból meríthetünk választ, azonban az első probléma
megoldásához új protokoll mechanizmust kell kidolgoznunk. Számos megközelítés létezik a
csomagvesztés detektálására, azonban mi egy olyan változatot tekintünk meg, amely a küldő vállára
helyezi a terhet. Akár elveszett kiküldött csomagról, akár elveszett visszaigazolásról beszélünk,
egy biztos, a küldő fél nem kap explicit visszajelzést a fogadó féltől.
Mi történik, ha a küldő visszaigazolás hiányában "elegendő" várakozás után újraküldi a
csomagot?
• ha tényleg csomagvesztés történt vagy hibásan érkezett meg a csomag, akkor jól cselekedett
a küldő
• ha a visszaigazolás veszett el vagy bithibás a visszaigazolás, akkor duplikátum keletkezik
a fogadó oldalon, de ezt kezeli a szekvencia szám, illetve a nyugta tartalmazza a csomag
sorszámát
rdt_rcv(rcvpkt)) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt
rcvpkt)
extract(rcvpkt,data
rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK,
make_pkt chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Alulról Alulról
rdt_rcv(rcvpkt) && 0-ra vár 1-re vár rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
4.10: Az rdt2.1 protokoll állapot automatája a fogadó oldalon1
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
0-as 0-ás ACK- isACK(rcvpkt,1) )
hívsára vár ra vár
felülről udt_send(sndpkt)
küldő FSM
darab rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt) && && notcorrupt(rcvpkt)
(corrupt(rcvpkt) || && isACK(rcvpkt,0)
has_seq1(rcvpkt)) Felülről fogadó FSM Λ
0-ra vár
udt_send(sndpkt) darab
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
Úgy tűnik, hogy a várakozási idő egy jó taktika a csomagvesztés kezelésére, azonban mikor
mondhatjuk azt, hogy a várakozás "elegendő"?
Első megfontolásból mondhatnánk azt, hogy várjon annyit a küldő, amennyi egy csomag
"oda-vissza" útjához szükséges. Ez még nem tartalmazza a hálózatban résztvevő forgalomirányítók
puffereléssel töltött idejét, és a fogadó fél adatfeldolgozási idejét, de mindezekkel együtt becsülhető
lenne a késleltetés legrosszabb esete. Ez nagyon nehéz, továbbá a protokollnak a csomagveszteséget
a lehető leghamarabb észlelnie kellene. Egy idő alapú újraküldő mechanizmus implementációjához
szükség van egy visszaszámlálóra, amely megszakítja a küldőt egy adott idő elteltét követően. Így
a küldőnek három dolgot kell tudnia:
1. egy csomag elküldésekor az időzítőt elindítani
2. az időzítő megszakításakor a megfelelő műveletet végrehajtani
3. megállítani az időzítőt
A 4.12 ábrán nyomon követhető az rdt3.0 protokoll állapot automatája, mely a korábbi újraküldő
mechanizmuson túl az időzítő használatát is tartalmazza.
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer Λ
Λ 0-s
0-s felső ACK- timeout
hívsra vár ra vár udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
1-es
timeout ACK- 1-re vár
udt_send(sndpkt) ra vár felülről
start_timer rdt_rcv(rcvpkt)
rdt_send(data) Λ
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1,
make_pkt data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt
sndpkt)
start_timer
Λ
4.12: Az rdt3.0 protokoll állapot automatája1
A 4.13 ábrákon láthatjuk a protokoll működését az idő függvényében. Az a) képen csomagvesztés

nélküli adatátvitelt prezentáltunk, ahol bal oldalon a küldő, jobb oldalon a fogadó fél műveletei
láthatóak az idő előrehaladtával. A b), c). és d) rajz szemlélteti az időzítő szerepét és működését.
A küldő oldalon látható kapcsolójel jelzi az visszaszámláló indulása és leállása között eltelt időt.
Ezt nevezzük várakozási időnek, ameddig az rdt3.0 nem küldi újra a csomagot, és vár a fogadó
fél visszaigazolására. A b) ábrán egy tényleges csomagvesztést látunk, ami miatt újraküldés
történik, a c)-n az újraküldés a visszaigazolás elvesztéséből adódik, így duplikátum keletkezik a
fogadó oldalon, a d) esetben pedig a visszaigazolás a várakozási időn túl érkezett meg, így itt is
duplikátumot detektál a fogadó.
Mivel a csomagok szekvencia számai 0 és 1 között váltakoznak, így az rdt3.0-t alternáló-bit
protokollnak is nevezik. Ezzel elérkeztünk a megbízható adatátvitel alapjainak a végéhez, és van
egy működő megbízható adatátviteli protokollunk.
4.4.4 Cső szervezésű megbízható adatátviteli protokollok
A korábbiakban kifejlesztett rdt3.0 protokoll funkcionalitását tekintve hibátlan, azonban komoly

teljesítmény problémái vannak, különös tekintettel a mai nagy sebességű hálózatokat szem előtt
tartva.
A probléma gyökere a protokoll "állj és várj" stratégiája, azaz mindaddig nem kerül új adatot
tartalmazó csomag kiküldésre, amíg az azt megelőzőről nincs pozitív visszaigazolás adott várakozási
időn belül. A teljesítmény probléma érzékeléséhez tekintsük az alábbi példát és számokat!
Vegyünk két rendszert, amelyek egymástól több ezer kilométer távolságra vannak, Európa
két egymástól távoli pontján. Tegyük fel, hogy a két rendszer közötti adatátvitel fénysebességgel
történik, így az adat útjának oda-vissza megtételéhez körül-belül 30 milliszekundum szükséges,
ezt jelölje RTT (Round-Trip-Time). A két rendszer között egy 1 Gbps sebsségű vonal van (109 bit
másodpercenként), ez az R értékünk. Ha 1000 bájt (8000 bit) méretű csomagokat (L) tekintünk,
amely tartalmazza a fejléc mezőket és az adatot is, akkor egy csomag egy 1 Gbps sávszélességű
küldő fogadó küldő fogadó
pkt0 küldése pkt0 pkt0 küldése pkt0
pkt0 fogadása pkt0 fogadása
ack0 ack0 küldése ack0 ack0 küldése
ack0 fogadása ack0 fogadása
pkt1 küldése pkt1 pkt1 küldése pkt1
pkt1 fogadása X
ack1 ack1 küldése elveszett
ack1 fogadása
pkt0 küldése pkt0
pkt0 fogadása időtúllépés
ack0 ack0 küldése pkt1 újraküldése pkt1
pkt1 fogadása
ack1 ack1 küldése
ack1 fogadása
pkt0 küldése pkt0
(a) nincs csomagvesztés
pkt0 fogadása
ack0 ack0 küldése
(b) csomagvesztés
küldő fogadó
küldő fogadó pkt0 küldése pkt0
pkt0 küldése pkt0 rcv pkt0
pkt0 fogadása ack0 ack0 fogadása
ack0 ack0 küldése ack0 fogadása
ack0 fogadása pkt1 küldése pkt1
pkt1 küldése pkt1 pkt1 fogadása
pkt1 fogadása ack1 küldése
ack1 ack1 küldése ack1
X
elveszett időtúllépés
időtúllépés pkt1 újraküldése pkt1
pkt1 fogadása
pkt1 újraküldése pkt1 pkt1 fogadása ack1 fogadása pkt0 (duplikátum detektálása)
(duplikátum detektálása) pkt0 küldése ack1 küldése
ack1 ack1
ack1 küldése ack1 fogadása pkt0 fogadása
ack1 fogadása ack0 ack0 küldése
pkt0 pkt0 küldése pkt0
pkt0 küldése pkt0 fogadása
pkt0 fogadása ack0 (duplikátum detektálása)
ack0 ack0 küldése ack0 küldése
(c) ACK vesztés (d) túl hamar időtúllépés/ késleltetett ACK
4.13: Az rdt3.0 protokoll működése1
vonalon történő átviteléhez a szükséges idő:
L 8000 bit/csomag
dtrans = = = 8 mikroszekundum (4.1)
R 109 bit/másodperc
Ahogy a 4.14 és a 4.15 ábrákon látható, ha az "állj és várj" protokollt alkalmazzuk, akkor
a t = 0 időpillanatban kiküldött csomag utolsó bitje a t = L/R = 8 mikroszekundumban kerül
be csatornába a küldő oldalon. Ezt követően a csomag megteszi a 15 milliszekundumos útját a
fogadó fél felé, így a fogadó félnél az utolsó bit a t = RT T /2 + L/R = 15, 008 milliszekundum
időpillantban jelenik meg. Ha feltesszük, hogy a visszaigazolás (ACK) mérete olyan kicsi, hogy
az átviteli idő figyelmen kívül hagyható, és az utolsó bit megérkeztével azonnal küldhető, akkor a
visszaigazolás a t = RT T + L/R = 30, 008 milliszekundum időpillanatban érkezik meg a küldőhöz.
Ha a küldő (vagy a csatorna) kihasználtságát (Uküldő ) a küldő tényleges foglaltságának és az
oda-vissza úthoz szükséges idő hányadosaként írjuk fel, akkor az
L/R 0, 008
Uküldő = = = 0, 00027 milliszekundum (4.2)
RT T + L/R 30, 008
értéket kapjuk, ami szerint a küldő nincs megfelelő módon kihasználva.

Az ilyen elven működő protokollokat nevezzük cső szervezésű protokolloknak. A következőkben
két általános cső szervezésű protokollt vizsgálunk meg: vissza N-nel és szelektív ismétlés.
küldő fogadó
az első bitet átküldtük, t = 0
az utolsó bitet átküldtük, t = L / R
az első bit beérkezik

RTT az utolsó bit beérkezik, küldjük
az ACK-ot
az ACK beérkezik,
küldjük a következő
csomagot
, t = RTT + L / R
4.14: Az "állj és várj" művelet1
küldő fogadó
az első továbbítandó bit, t = 0
az utolsó továbbítandó bit, t = L
/R
az első bit beérkezik

RTT az utolsó bit beérkezik, küldjük az ACK-ot
a 2. csomag utolsó bitje beérkezik, ACK
a 3. csomag utolsó bitje beérkezik, ACK
ACK beérkezett, küldjük a
következőt
csomag, t = RTT + L / R
4.15: Cső szervezésű adatküldés1
Vissza N-nel
A Vissza N-nel protokoll esetében a küldő számára megengedett, hogy több csomagot is kiküldjön
visszaigazolásra történő várakozás nélkül. A megengedésnek természetesen van egy beállított N
felső korlátja, azaz legfeljebb N még nem visszaigazolt csomag lehet a csővezetékben egyidejűleg.
A 4.16 ábrán látható a küldő fél szemszögéből a szekvencia számok. Ha az első visszaigazolatlan
csomagot jelöli base, és nextseqnum a következő szabad szekvencia számot, akkor a szekvencia
számok tartománya 4 részre osztható:
• [0,base-1]: az elküldött és visszaigazolt csomagok
• [base,nextseqnum-1]: az elküldött, de még vissza nem igazolt csomagok
• [nextseqnum,base+N-1]: az azonnal küldhető csomagok
• [base+N,∞): nem használhatóak, amíg a csővezetékben levő csomagok közül nincs újabb
visszaigazolt
A maximálisan kiküldhető nyugtázatlan csomagok számát (N) szokták ablaknak nevezni. A
fogadó nyugtázása is ennek megfelelően történik. A küldő fél egy ún. összesítő (kumulált) nyugtát
fog kapni az n. csomagról. Az n. csomag nyugtáját a fogadó akkor küldi ki, ha az n. volt a
sorban következő csomag. Ha egy soron kívüli csomag érkezik, akkor azt elveti, és nyugtát küld az
utoljára helyesen fogadott csomagról. Az n. csomag nyugtája természetesen azt is jelenti, hogy az
n szekvencia számnál alacsonyabbal ellátott csomagok is helyesen megérkeztek.
A Vissza N-nel nevét a protokoll a küldő viselkedéséről kapta. Ismét visszaköszön az időzítő
használata, amellyel az adatvesztés adta problémákat kezeljük. Egyetlen időzítőt használva,
alkalmazzuk azt a legrégebben kiküldött még nem visszaigazolt csomagra. Ha nem érkezik adott
időn belül visszaigazolás, akkor a legrégebben vissza nem igazolt csomag újraküldésre és kerül, és
már visszaigazolt
base nextseqnum
elküldött, de még
nem visszaigazolt
használható, még
nem elküldött
ablak méret
N
nem használható
4.16: Szekvencia számok a küldő oldalon a Vissza N-nel protokollnál1
az összes ezt követő is, hiszen a sorrendhelyesség fontos a fogadónál. A 4.17 ábra szemlélteti a
Vissza N-nel protokoll működését.
küldő (N=4) ablak küldő fogadó

0123 45678 pkt0 küldése
0123 45678 pkt2 küldése pkt0 fogadása, ack0 küldése
0123 45678 pkt3 küldése X elveszett pkt1 fogadása, ack1 küldése
(várakozás)
pkt3 fogadása, kidob,
ack1 (újra) küldés
0 1234 5678 ack0 fogadása, pkt4 küldés
0 1 2345 678 ack1 fogadása, pkt5 küldés
pkt4 fogadása, kidob,
ack1 (újra) küldés
a duplikált ACK-ot elvetjük pkt5 fogadása, kidob,
pkt 2 időtúllépés ack1 (újra) küldés
01 2345 678 pkt2 küldése

01 2345 678 pkt3 küldése
01 2345 678 pkt4 küldése pkt2 fogadása, kézb.,ack2
01 2345 678 pkt5 küldése pkt3 fogadása, kézb., ack3
pkt4 fogadása, kézb., ack4
pkt5 fogadása, kézb., ack5
4.17: A Vissza N-nel működés közben1
Szelektív ismétlés
Ugyan a Vissza N-nel protokoll megnövelte küldő kihasználtságát az "állj és várj" stratégiához
képest, azonban vannak olyan esetek, amikor itt is mutatkoznak teljesítmény problémák. Például, ha
az ablak méret és a késleltetés is magas, akkor egyidejűleg rengeteg csomag lehet a csővezetékben.
Egyetlen csomaghiba nagy mennyiségű csomag újraküldését eredményezi, hiszen a hibás csomagtól
kezdve minden csomagot újra kell küldeni.
A szelektív válasz protokoll pontosan ezeket a szükségtelen újraküldéseket hivatott elkerülni.
Csak azokat a csomagokat fogja újraküldeni, amelyek hibásan érkeztek meg a fogadóhoz vagy
elvesztek. Az ablak méretet továbbra is alkalmazzuk az egyidejűleg a csővezetékben tartózkodó
csomagok számának maximális korlátozásához. A szekvencia számok tere azonban változik, melyet
a 4.18 ábrán szemléltetünk.

base nextseqnum
elküldött, de még
már visszaigazolt nem visszaigazolt
küldő
használható, még nem használható

nem elküldött
ablak méret
N
soron kívüli
(pufferelt), elfogadható,
de visszaigazolt az ablakon belül van
fogadó
elvárt, de még
nem érkezett be nem használható
ablak méret
N
rcv_base
4.18: Szekvencia számok a küldő és a fogadó oldalon a Szelektív ismétlés protokollnál1
A küldő és a fogadó az alábbi eseményeket és műveleteket hajtja végre.

Küldő: Fogadó:
• Adat fogadása felsőbb rétegtől: • Helyesen fogadott csomag az
megkeresi a sorban következő [rcv_base, rcv_base+N-1]
szabad szekvencia számot, és ha az intervallumba eső szekvencia
az ablakban van, akkor az adatot számmal: ebben az esetben a fogadott
csomagolja és küldi. Más esetekben csomag a fogadó ablakába esik, és
puffereli az adatot vagy visszaküldi a egy szelektív visszaigazolás kerül
felsőbb rétegnek. továbbításra a küldő felé. Ha a
• Időtúllépés: minden csomaghoz csomag még korábban nem volt
rendel egy időzítőt, ezzel minden fogadott, akkor a pufferbe kerül. Ha
csomag nyomonkövethető, és a csomag szekvencia száma az ablak
detektálható, ha elveszett. szerinti első szekvencia számmal
• Visszaigazolás fogadása: a (rcv_base) egyenlő, akkor a csomag
visszaigazolás alapján megjelöli és az őt megelőző pufferelt csomagok
az adott csomagot, hogy sikeresen továbbításra kerülnek a felsőbb réteg
megérkezett. Ha a csomag szekvencia felé. Így az fogadó ablaka tovább
száma az ablakban lévő első volt, mozgatható.
akkor az ablakot eggyel tovább • Helyesen fogadott csomag
mozgatja a még vissza nem igazolt az [rcv_base-N, rcv_base-1]
csomagok szekvencia számának intervallumba eső szekvencia
irányába. Ha az ablak pozíciója számmal: ilyenkor egy
változik, és van elküldetlen szekvencia visszaigazolást kell küldeni, még
számmal rendelkező csomag, akkor akkor is, ha a csomag már korábban
azt elküldi. vissza lett igazolva.
• Egyébként: figyelmen kívül hagyja a
csomagot.
A fenti működés (4.19 ábra) fő problémája azonban az, hogy a küldő és a fogadó ablaka
nincs szinkronban tartva, és nem látják egységesen, hogy mely csomagok lettek fogadva, melyek
nem. Ennek komoly következményei lehetnek, ha a szekvencia számok véges tartományának
problémájával szembesülünk.
Vegyük példaként a seq = 0,1,2,3 szekvencia számokat, és az ablak méret legyen 3. Tegyük fel,
küldő (N=4) ablakkal küldő fogadó
012345678 pkt0 küldése
012345678 pkt1 küldése
pkt2 küldése pkt0 fogadás, ack0 küldése
012345678
012345678 pkt3 küldése Xelveszett pkt1 fogadás, ack1 küldése
(várakozás)
pkt3 fogadása, buffer, ack3 küldése
01234 5678 ack0 fogadása, pkt4 küldése
012345 678 ack1 fogadása, pkt5 küldése
pkt4 fogadása, buffer, ack4 küldése
ack3 fogadása pkt5 fogadása, buffer, ack5 küldése
pkt 2 időtúllépés
012345 678 ack4 fogadása
012345 678 pkt2 fogadása; pkt2, pkt3, pkt4, pkt5
ack5 fogadása
012345 678 kézbesítése; ack2 küldése
4.19: A Szelektív ismétlés protokoll működés közben1
hogy a 0, 1 és 2 sorszámmal ellátott csomagok ki lettek küldve az ablak méretének megfelelően, és

helyesen fogadta és vissza is igazolta őket a fogadó fél. Ezen a ponton a fogadó ablaka a 4., 5. és 6.
csomag fölött van, amelyek szekvencia számai rendre 3, 0 és 1.
Vizsgáljuk az alábbi két szituációt (4.20 ábra):
a) az első három csomag (0, 1, 2) visszaigazolása elveszik, így a küldő ezeket újra fogja küldeni.
A fogadó következésképp egy 0-s sorszámmal ellátott csomagot fog kapni, ami az első csomag
másolata lesz.
b) az első három csomag (0, 1, 2) visszaigazolása sikeresen megérkezik. A küldő tovább
mozgatja ablakát, és elküldi a 4., 5. és 6. csomagot rendre a 3, 0 és 1 szekvencia számokkal.
A 3-as sorszámú csomag elveszik, de a 0-s sorszámú helyesen megérkezik, amely új adatot
tartalmaz.
küldő ablak fogadó ablak

(beérkezés után) (beérkezés után)
0123012 pkt0
0123012 pkt1 0123 012
0123012 pkt2 01230 12
X 012301 2
X
időtúllépés
újraküldés pkt0 X
0123012 pkt0
elfogadja a 0-s sorszámút
(a) probléma
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 0123012
012301 2
0123012 pkt3
X
0123012
pkt0 elfogadja a 0-s sorszámút
(b) nincs gond
4.20: A Szelektív ismétlés protokoll működése túl nagy ablak méret esetén1
4.5 Kapcsolatorientált átvitel: TCP 87
Ezek az esetek világítanak rá arra a problémára, ha a szekvencia számok halmazának méretéhez

képest 1-gyel kisebb az ablak mérete. Mivel a fogadó csak szekvencia számokat érzékel, így
nem tudja megkülönböztetni az 1. csomag újraküldését az 5. csomag első elküldésétől. Erre egy
megoldást adhat, ha az ablak mérete legfeljebb a szekvencia számok halmazának méretének a fele.
A továbbiakban a TCP-t vizsgáljuk, amely megoldásokat nyújt a korábban említett problémákra.

Az előző fejezetekben megvitattuk a megbízható adattovábbítás alapjait, a következőkben pedig az
Internet szállítási rétegének kapcsolatorientált, megbízható adatátvitelt garantáló protokolljáról lesz
szó, a TCP-ről. A TCP-ről az RFC 793, RFC 1122, RFC 1323, RFC 2018 és az RFC 2581 szól.
4.5.1 TCP kapcsolat kiépítés

A TCP-t kapcsolatorientáltnak nevezik, mert mielőtt egy processzus adatot küldene egy másiknak,
egy ún. “kézfogást” kell megejteniük. Ez a "kézfogás" jelenti a biztonságos adatátvitelhez
szükséges paraméterek egymással való megosztását, mint például mekkora méretű szegmensek
küldhetőek ki (MSS - Maximum Segment Size mező).
A TCP kapcsolat egy logikai kapcsolat, mivel a protokoll a végrendszereken fut. A két
processzus között létrejött kapcsolat kétirányú (mindkét irányba történik adatcsere) és pont-pont
összeköttetésű (egy küldő és egy fogadó). Az ún. többesküldés (multicasting) TCP felett nem
kivitelezhető.
A TCP kapcsolat kiépítésének megértéséhez tekintsük meg az alábbi példát!
Vegyünk két végrendszert, egy klienst és egy szervert, amelyeken 1-1 processzus kíván egymással
kapcsolatba lépni. A kliens processzus kezdeményezi a kapcsolatot, ehhez a processzus szól a
szállítási rétegnek, hogy a szerveren futó processzushoz szeretne kapcsolódni. A szerver elérhetőségei
adott (IP-cím - port), így a kliens megszólítja a szervert egy speciális TCP szegmenssel. A szegmenst
fogadva a szerver is visszaszolgáltat egy speciális TCP szegmenst. Ezekben a szegmensekben nincs
alkalmazás rétegbeli tartalom. Végül a kliens válaszol a szervertől kapott TCP szegmensre egy
harmadik speciális szegmenssel, amely már tartalmazhat alkalmazás réteg adatot is.
Ezt a kapcsolat kiépítési folyamatot nevezik három lépéses kézfogásnak (three-way handshake).
Ha a kézfogás sikeres, akkor a processzusok elindíthatják az adatforgalmat egymás felé.
4.5.2 TCP szegmens struktúra

A kapcsolat kiépítésének gyors áttekintése után térjünk rá a szegmens felépítésére. A szegmens
struktúrája a 4.21 ábrán látható. A TCP szegmens tartalmaz egy fejléc (header) és egy adat (data)
részt. Az adat rész az alkalmazás rétegtől kapott adatot tartalmazza az ott használt protokoll fejléc
mezőivel együtt. A fejléc az UDP-hez hasonlóan tartalmazza a forrás és cél portszámokat, amelyek
a multiplexelés és demultiplexelés műveletekhez kellenek. Hasonló módon megjelenik az ellenőrző
összeg (checksum) mező is, amely hibadetektálást hivatott ellátni.
Ezeken kívül a TCP fejléc az alábbi mezőkkel és funkciókkal bír:
• a 32 bites szekvencia és nyugta számok (sequence number, acknowledgement number)
segítségével valósul meg a megbízható adatátvitel.
• a 16 bites vevőablak, amely meghatározza a vevő által fogadható bájtok számát
• a 4 bites fejléc hossz mező írja le a TCP fejléc hosszát
• az opciók mező változó hosszúságú lehet. Ezt használja tipikusan a kapcsolat kiépítés során
a paraméterek megosztására a TCP.
• a flag mező 6 bitet tartalmaz, melyek az alábbiak: URG, ACK, PSH, RST, SYN, FIN, CWR,
ECE.
– URG: sürgős adat
32 bit
URG: sürgős adat adat bájtonként
(átl. nem használt) forrásport # célport # (nem szegmens!)
szekvenciaszám
ACK: ACK #
érvényes nyugtaszám
fejléc nem
PSH: adat átnyomás hossz hasz.
UAP R S F vevőablak
most (ált. nem hasz.) a vevő által
ellenőrző összeg Sürgős adat mut.
fogadható
RST, SYN, FIN: bájtok
opciók (változó
változó hossz.)
kapcsolat létrehozás száma
(felépítés, lebontás
parancsok)
alkalmazás adat
Internet (változó hosszúságú)
hosszúságú
ellenőrző összeg
(mint az UDP-nél)
4.21: TCP szegmens struktúra1
– ACK: nyugta érvényessége

– PSH: adat továbbítása azonnal a felsőbb réteg felé
– RST, SYN, FIN: kapcsolat felépítés és lezárás bitjei
– (CWR, ECE: explicit torlódás értesítés bitjei)
A két talán legfontosabb mezője a TCP szegmens fejlécnek a szekvencia szám és nyugta szám.
Ezek komoly meghatározói a TCP megbízható adatátvitelének. A szekvencia szám a bájt folyam
száma a szegmens első bájtjának. A nyugta szám a következő bájt sorszámára mutat. Mivel a
TCP csak az első hiányzó bájtig küld visszaigazolást a folyamra vonatkozóan, így ezt összesített
(kumulatív) nyugtázásnak nevezzük. A TCP azonban nem szól a soron kívül érkezett szegmensek
kezeléséről, így ezek sorsáról a megvalósító dönt.
A 4.22 ábrán egy TCP feletti Telnet alkalmazás működése látható.
A gép B gép
A gép
‘C’-t küld
Seq=42, ACK=79, data = ‘C’
B gép nyugtázza
‘C’-t, visszaküldi
‘C’-t
Seq=79, ACK=43, data = ‘C’
A gép nyugtázza a
visszaküldött
‘C’-t
Seq=43,
=43, ACK=80
egyszerű telnet
4.22: Szekvencia számok és nyugta számok egy egyszerű TCP feletti Telnet alkalmazás esetén1
4.5.3 Megfordulási idő és időtúllépés

A TCP az rdt protokollhoz hasonlóan az időtúllépés/újraküldés mechanizmust alkalmazza az
elveszett szegmensekből adódó hibák kezeléséhez. A legnyilvánvalóbb kérdés az időtúllépések
hossza. Az időtúllépésnek biztosan hosszabbnak kell lennie, mint a csomagok oda-vissza megtett
útjához szükséges idő (RTT). Ha ennél rövidebb időt állítunk be, akkor fölösleges újraküldések
fordulnának elő. Nagyon hosszú időtúllépés esetén pedig nagyon sok idő telik el egy újraküldésig.
A becslés mégis nagyon nehéz, hiszen az RTT változékony.

A TCP próbálja megbecsülni az RTT-t, azaz a kiküldéstől a nyugtázásig eltelt időt. Ezt jelölje
SampleRTT. Ez természetesen nem kerül kiszámításra minden kibocsátott szegmensnél, de milyen
gyakran kell újraszámítani ezt?
Elegendő RTT-nként újramérni?
Ha RTT-nként mérünk, akkor RTT még mindig nagyon változékony lesz, ennél stabilabb értékre
lenne szükség.
A TCP az RTT stabil kezelése végett átlagolja a SampleRTT értékeket, ez jelöli EstimatedRTT.
Ennek kalkulációja az alábbi formula szerint történik egy SampleRTT beérkezése esetén:
EstimatedRT T = (1 − α) ∗ EstimatedRT T + α ∗ SampleRT T (4.3)
Az α érték meghatározásához az RFC 6298-ban leírtak szerint érdemes az 18 = 0, 125 értéket

használni. A 4.23 grafikon jól szemlélteti, hogy az EstimatedRTT értéke így mennyivel stabilabb,
mint ha csak a SampleRTT-vel dolgoznánk.
300
SampleRTT
EstimatedRTT
250
RTT (milliszekundum)
200
150
100
50
0
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
Idő (másodperc)
4.23: SampleRTT és EstimatedRTT értékek stabilitása1
Az RTT jó közelítésében segíthet az RTT változékonyságának mérése is. RFC 6298 szerint
DevRTT közelíti SampleRTT eltérését EstimatedRTT-től. DevRTT az alábbi formulával számítható:
DevRT T = (1 − β ) ∗ DevRT T + β ∗ |SampleRT T − EstimatedRT T | (4.4)
Az ajánlott β érték a 0,25. A legjobb időtúllépés meghatározásához a fent számított két értéket
kellene kombinálni, ezért a becsült RTT-re számolunk egy kis ráhagyást, és az így kapott időtúllépés
(TimeoutInterval) az alábbi képletből kapható meg.
TimeoutInterval = EstimatedRT T + 4 ∗ DevRT T (4.5)
Az időtúllépés iniciális értéke 1 másodperc, és a SampleRTT értékek begyűjtésével folyamatosan

változik EstimatedRTT, DevRTT, illetve az időtúllépés értéke.
4.5.4 Megbízható adatátvitel

A TCP egy megbízható adatátviteli szolgáltatást biztosít az IP megbízhatatlan legjobb szándékú
szolgáltatása felett. A TCP garantálja, hogy a vevőnél a pufferből kiolvasott adatfolyam hibamentes,
hiánytalan, duplikáció mentes és sorrendhelyes, azaz a fogadott bájtfolyam tökéletesen megegyezik

a kiküldött bájtfolyammal. A TCP megbízható adatátvitelének mélyebb megértéséhez két lépésre
bontjuk a működési folyamatot. Először egy egyszerűsített TCP küldőt vizsgálunk meg, amely csak
időzítést használ az elveszett csomagokból adódó hiba kezelésére, majd megnézzük a duplikált
nyugták kezelését is.
A TCP küldő adat továbbításához és újraküldéséhez három fő esemény kapcsolódik:
• adat fogadása az alkalmazástól: a TCP fogadja az adatot az alkalmazástól, majd azt beágyazza
egy szegmensbe és továbbítja az IP-nek. Minden szegmens tartalmaz egy szekvencia számot,
amely a bájtfolyam első bájtjára mutat a szegmensben. Továbbá ha nincs futó időzítő más
szegmensre, akkor az IP-nek történő átadáskor elindítja az időzítőt, és kiszámítja az aggregált
időtúllépési mutatót (TimeoutInterval).
• időtúllépés: időtúllépés esetén a TCP újraküldi azt a szegmenst, amely kiváltotta az időtúllépést,
és újraindítja az időzítőt.
• nyugta fogadása: nyugta beérkeztekor a TCP összehasonlítja a nyugta számot (y) a legrégebben
kiküldött nyugtázatlan szegmens szekvencia számával (SendBase). Mivel összesítő nyugtákkal
dolgozik a TCP, így a nyugta számmal több szegmens is nyugtázásra kerül. y > SendBase
esetén több korábban kiküldött nyugtázatlan szegmens is visszaigazoltnak tekintendő. Ekkor
a szekvencia szám frissítésre kerül, a legutolsó még nem nyugtázott csomag szekvencia
számára állítódik.
A 4.24 ábrán láthatóak az újraküldés esetei. A bal oldali esetben az elveszett nyugta okozta
újraküldést szemléltetjük, míg a jobb oldalon láthatón az időtúllépésből adódó újraküldést.
A gép B gép A gép B gép
SendBase
SendBase=92
Seq=92, 8 adatbájt Seq=92, 8 adatbájt
időtúllépés
időtúllépés
Seq=100, 20 adatbájt
ACK=100
X
ACK=100
ACK=120
Seq=92, 8 adatbájt Seq=92, 8

SendBase=100 adatbájt
SendBase=120
ACK=100
ACK=120
SendBase=120
elveszett ACK korai időtúllépés
4.24: Újraküldés elveszett nyugta és korai időtúllépés miatt1
Az időtúllépés által kiváltott újraküldés egyik problémája, hogy az időtúllépési periódus nagy
is lehet. Egy szegmens elvesztésével a hosszú időtúllépési periódus miatt a küldő csak nagy
késleltetéssel tud újraküldeni, amellyel a vevő oldalon is megnövekszik a késleltetés.
Szerencsére a küldő képes detektálni csomagvesztést az időzítő lejárta előtt is, mégpedig, ha
duplikált nyugtát kap. A 1 táblázat összefoglalja a nyugta generálásának eseteit, amely az RFC
1122-ben és az RFC 2581-ben definiáltak.
Mivel a küldő sok szegmenst küld egymás után, így egy szegmens elvesztésével sok duplikált
ACK jelenne meg. Ha egy TCP küldő három duplikált nyugtát kap, az azt jelenti, hogy a háromszor
nyugtázott szegmenst követő szegmensek elvesztek. A három duplikált nyugta esetén a TCP egy
Vevőnél bekövetkezett esemény Vevő TCP lépés

Sorrendhelyes szegmens érkezik, és az összes A nyugta késleltetése. Legfeljebb 500
eddig beérkezett szegmens nyugtázva lett. milliszekundumot vár a következő szegmensre.
Ha nincs következő, akkor kiküldi a nyugtát.
Sorrendhelyes szegmens érkezik, de egy Azonnal egy összesített nyugtát küld mindkét
szegmens nyugtája még nem lett elküldve. szegmensre.
Egy olyan szegmens érkezik, melynek Azonnal duplikált nyugta kiküldése, ezzel
szekvencia száma nagyobb, mint a várt (lyuk jelezve a várt szekvencia számmal ellátott
keletkezik). szegmenst.
Olyan szegmens érkezik, amely részben vagy Ha a lyuk alsó részét tölti ki, akkor azonnali
egészben kitölti a lyukat. nyugta küldés.
1: TCP nyugta előállítási ajánlások (RFC 5681)
gyors újraküldést (RFC 5681) indít a szegmensre vonatkozóan, mielőtt az időzítője lejárna. Ezt az
esetet szemlélteti a 4.25 ábra.
A gép B gép
Seq=92,
=92, 8 adatbájt
Seq=100,
=100, 20 adatbájt
X
ACK=100
időtúlléps
ACK=100
ACK=100
ACK=100
Seq=100,
=100, 20 adatbájt
tripla duplikált ACK után gyors újraküldés
4.25: Gyors újraküldés: a hiányzó szegmens újraküldése, mielőtt az időzítő lejár1
Folyamvezérlés
A csőszervezésű protokolloknál használtunk először puffereket (gyorstárakat), amellyel sikeresen
megoldottuk a nem megfelelő sorrendben érkező csomagok újraküldésének problémáját. Ez a
puffer mindkét résztvevőnél létezik, és az elvárt működés szerint az alkalmazások innen olvassák be
az adatokat, de nem garantálható, hogy a szegmensek érkezésének sorrendjében kerül a pufferből ki
az adat. Ha az alkalmazás relatív lassan dolgozza fel az adatokat, akkor egy nagy sebességű küldő
esetén a vevő puffere könnyen túlcsordulhat.
Ezen probléma megoldására kínál a TCP egy ún. folyamvezérlési szolgáltatást, amellyel
megakadályozható a fogadó fél pufferének túlcsordulása. A folyamvezérlés tulajdonképpen egy
sebesség egyeztető szolgáltatás, amellyel összeegyeztethető a küldő küldési sebessége és a vevő
feldolgozási képessége. A TCP egy vevő ablak változót tart fenn a küldőnél, amely megmondja a
küldőnek, hogy a vevőnél a puffer mekkora része szabad.
Mivel a TCP kétirányú adatforgalmat von maga után, így mindkét résztvevőnél ismert a másik
vevő ablaka. Vizsgáljuk meg az alábbi példát!
Tegyük fel, hogy A egy nagy fájlt küld B számára TCP kapcsolat felett. B allokál egy RcvBuffer
méretű puffert a kapcsolathoz, amelyből a processzus folyamatosan olvassa az adatokat. Bevezetünk
két változót, LastByteRead jelölje az adatfolyam utoljára kiolvasott bájtját a B pufferéből, és
LastByteRcvd az utolsó pufferba betöltött (megérkezett) bájtot. Mivel a TCP nem engedi túlcsordulni
B pufferét, ezért igaz az alábbi egyenlőtlenség.
LastByteRcvd − LastByteRead ≤ RcvBu f f er (4.6)
A vevőablakot jelölje rwnd, amely az alábbi módon számítható:
rwnd = RcvBu f f er − (LastByteRcvd − LastByteRead) (4.7)
Mivel a puffer szabad területe folyamatosan változik, így rwnd dinamikus. Hogyan szabályozza
B az A küldő által kiküldött bájt folyamot?
A vevő minden visszaküldött szegmensben elküldi az aktuális rwnd értéket, ezzel tájékoztatva
a küldőt a puffer jelenlegi helyzetéről. Kezdetben az rwnd értéke RcvBuffer értékével egyenlő.
Kapcsolatkezelés
Fontos A megbízható adatátvitel megvalósításához a TCP kapcsolat mindkét résztvevőjének

szinkronizálnia kell állapotát a másikkal.
A korábbiakban felvázolt három lépéses kézfogást (three-way handshake) vesszük gorcső alá.
Ahogy azt már említettük, a kapcsolat létrejöttekor kiküldött szegmensek speciálisak. A három
lépés három TCP szegmenst jelent, amelyek az alábbi struktúrával és mező értékekkel bírnak.
1. lépés: A kliens-oldali TCP kiküld egy szegmenst a szerver-oldali TCP felé. A kiküldött
szegmens nem tartalmaz alkalmazás rétegbeli adatot, azonban a flag bitek közül a SYN beállításra
kerül 1-es értékkel. Ezért az 1. lépésben összeállított szegmenst SYN szegmensnek is nevezik.
Ezen túl a kliens véletlenszerűen választ egy iniciális szekvencia számot, amelyet bele is helyez a
kezdő TCP SYN szegmensbe. A szegmens beágyazásra kerül egy IP datagramba, és elküldésre
kerül a szerver felé.
2. lépés: A szerverhez beérkező IP datagramból kibontásra kerül a TCP SYN szegmens,
allokálásra kerül a TCP puffer, és visszaküld egy olyan szegmenst, amellyel a kapcsolódást
engedélyezi a szerver a kliensnek. Ebben a szegmensben sincs alkalmazás adat, viszont ez is
tartalmaz speciális értékeket és flag-eket. Elsőként a SYN és ACK flag bitek kerülnek beállításra
(1-es érték), valamint a nyugta mezője a TCP fejlécnek (acknowledgement number) 1-gyel nagyobb
értéket kap, mint a kliens által választott szekvencia szám. Végül, a szerver is választ egy szekvencia
számot véletlenszerűen. Ezt a szegmenst SYNACK szegmensnek szokták nevezni.
3. lépés: A SYNACK szegmens fogadásával a kliens elismeri a kapcsolódás jogát, és allokálja
a puffert és a változókat a kapcsolathoz. A kliens ilyenkor visszaküld egy nyugtát a szerver felé,
amellyel elfogadja a kapcsolódási jogot. A szegmensben kizárólag az ACK flag bit kerül beállításra
(1-es érték), a SYN ilyenkor 0-t kap. Ezt a szegmenst nevezik ACK szegmensnek is.
A 4.26 ábra szemlélteti a három lépéses kézfogást és annak lépéseit.
A nyitás áttekintése után nézzük meg a kapcsolat zárását! A kliens alkalmazás processzus le
szeretné zárni a kapcsolatot, és kibocsát egy zárás parancsot. Ezzel a kliens TCP egy speciális
szegmenst küld ki, amelyben a FIN flag bit kap 1-es értéket. Ha a szerver egy ilyen szegments
kap, akkor a kapcsolat lezárást nyugtázza (ACK), majd ő is küld egy beállított FIN bittel ellátott
szegmenst a kliensnek. A kliens szintén küld egy nyugtát a szervernek, amelyet követően minden
foglalt erőforrás felszabadul.
4.6 A torlódásvezérlés alapjai 93
Kliens Szerver
iniciális szekvencia szám választása (x),

TCP SYN üzenet kiküldése
SYNbit=1, Seq=x
iniciális szekvencia szám választása (y),
TCP SYNACK üzenet kiküldése, SYN visszaigazolása
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
TCP SYNACK(x+1) fogadása,
ACK küldése a SYNACK-ra;
(ez a szegmens már tartalmazhat ACKbit=1, ACKnum=y+1

ACKnum
alkalmazás adatot is)
ACK fogadása (y+1)
4.26: TCP három lépéses kézfogás1

A következőkben megvitatjuk a torlódásvezérlést alapjait, amelynek célja, hogy egy általános képet
kapjunk a problémáról és annak velejáróiról. A téma fontosságát az is érzékelteti, hogy a hálózati
problémát top 10-es listájában is helyet kap.
Ámbár hasonló a problémák eredete, fontos, hogy a torlódásvezérlés nem összekeverendő a
folyamvezérléssel! Egy hálózatban torlódás egyszerűen abból adódik, ha túl sok küldő túl sok adatot
bocsát ki, de azt a hálózat nem nem tudja kezelni. A torlódás következménye lehet csomagvesztés,
például a forgalomirányítók pufferei betelnek, és az extra csomagokat el kell dobnia, vagy hosszú
késleltetések, például a forgalomirányítók puffereiben sorakoznak az csomagok. Első körben csak
a problémára és annak megértésére fókuszálunk néhány eseten keresztül.
1. eset: Vegyük a legegyszerűbb példát, amelyet a 4.27 ábra is szemléltet! Két küldő (A,
B) és két vevő (C, D) van, ahol a vevőket és a küldőket egy forgalomirányító köt össze (egy
ugrás). Az A hosztnál futó alkalmazás küldési rátája λin bájt/másodperc. A szállítási rétegbeli
protokollunk legyen egyszerű, nincs hibadetektálás, újraküldés, folyamvezérlés és torlódásvezérlés
sem. Figyelmen kívül hagyva az alsóbb réteg által hozzáadott információk méretét az A számítógép
λin bájt/másodperccel forgalmaz. Az egyszerűség végett a B gép is hasonló paraméterekkel
dolgozik, szintén λin bájt/másodperc forgalmazással. Az adatok a túl oldalra egy közös, osztott
vonalon keresztül haladnak, amelynek kapacitása R. A router rendelkezik pufferrel, amelyben
sorakozhatnak a csomagok, de tegyük fel, hogy ennek a kapacitása végtelen.
A 4.28 ábra grafikonjai szemléltetik, hogy az áteresztőképesség és a késleltetés hogyan változik
a forgalom nagyságának növelésével. Ha a küldési ráta 0 és R/2 közötti, akkor az áteresztő képesség
a fogadónál egyenlő a küldési sebességgel, minden véges késleltetéssel érkezik meg. Ha bármely
küldő fél küldési sebessége R/2 felé megy, az áteresztőképesség nem változik, továbbra is R/2
marad, hiszen a vonal kapacitása nem enged többet, viszont a késleltetés egyre csak nő és nő, tart a
végtelen felé.
2. eset: A második forgatókönyv szerint ugyancsak két küldőnk (A és B) és két fogadónk
(C és D) van, azonban a router puffere ezúttal véges. Ennek következménye, hogy ha a puffer
megtelik, akkor a többi érkező csomag nem fér be, így azok eldobásra kerülnek. Ezen kívül minden
kapcsolatról feltételezzük, hogy megbízható, azaz, ha egy csomagot eldob a router, akkor újraküldés
történik (időzítő használatával). Mivel az újraküldés engedélyezett, így a küldési sebességet nagy
figyelemmel kell kezelnünk. Az eredeti adatküldést továbbra is λin bájt/másodperccel történik,
0
azonban az újraküldéseket is beleszámítva ez λin ≥ λin bájt/másodpercet jelent. A teljesítmény
eredeti adat: in átviteli kapactitás: out

A gép
végetelen, megos
ztott, kimeneti
buffer
B gép
4.27: Két kapcsolat megosztott végtelen pufferrel1
R/2
késleltetés
out
in R/2 in R/2
4.28: Az áteresztőképesség és a késleltetés alakulása a forgalom növelésével1
nagyban függ az újraküldéstől, ezért bontsuk három felé a szcenáriónkat (4.29 ábra)!
a) Tekintsük azt a valótlan(!) esetet, amikor a küldő (A) meg tudja jósolni, hogy a forgalomirányító
puffere szabad vagy sem. Csak akkor forgalmaz, ha a puffer üres. Ebben az esetben
0
adatvesztés nem történik, és teljesül a λin = λin egyenlőség. Ilyenkor az áteresztőképességet
tekintetében a teljesítmény ideális. Fontos megjegyezni, hogy a küldési sebesség itt sem
lehet R/2-nél magasabb, mivel a csomagvesztést kizártuk.
b) A küldő újraküld, ha a csomag elveszett. Tegyük fel, hogy a teljes forgalmazási ráta (eredeti
0
adat + újraküldés) λin = R/2. Ebben az esetben a vevő terhelése R/3 értéken van, hiszen az
újraküldésekre is kell sávszélességet biztosítani, de aszimptotikusan R/2 a sávszélesség még
mindig.
c) Végül vegyük azt az esetet, amikor az időzítő túl hamar lejár, és a küldő azelőtt újraküldi
csomagot, mielőtt az elveszett volna. Ilyenkor az eredeti csomag és az újraküldött is
megérkezhet a vevőhöz. Természetesen, a vevő az újraküldött csomagot eldobja, azonban az
újraküldés "pazarolta" a forgalomirányító kapacitását. Ha minden csomagot kétszer küldünk
el, akkor az áteresztőképesség aszimptotikusan eléri az R/4 sebességet, míg a terhelés közelíti
az R/2 értéket.
3. eset: Végül tekintsük azt az esetet, amikor négy küldő van, több ugrásos utak, ahogy
a 4.30 ábrán is látható. Minden hoszt megbízható adatátvitelt garantál időtúllépés és újraküldés
mechanizmusával. Minden számítógép λin bájt/másodperccel forgalmaz, és minden forgalomirányító
R bájt/másodperc kapacitással bír. Ahogy az ábrán is látható a kapcsolatok osztoznak a forgalomirányítókon:
az A-C kapcsolat R1-et és R2-t használja, a B-D kapcsolat R2-t és R3-at, a C-A R3-at és R4-et, a
D-B pedig R4-et és R1-et.
Extrém kicsi λin érték esetén a a túlcsordulás ritka, valamint az áteresztőképesség és a
kihasználtság közel egyforma. A λin kismértékű növelésével a torlódás mértéke nem növekszik, de
4.7 TCP torlódásvezérlés 95
R/2 R/2 R/2

R/3
out
out
R/4
out
’in R/2 ’in R/2 λ’in R/2
4.29: 2. eset teljesítménye véges pufferekkel
A gép
in : eredeti adat out
B gép
'in: eredeti adat, plusz
újraküldött adat
véges, megosztott,
kimeneti vonali
pufferek
R4 R1
D gép
C gép
R2
R3
4.30: Négy küldő, forgalomirányítók véges pufferrel és több ugrásos utakkal1
az áteresztőképesség és kihasználtság párhuzamosa nő.

0
Amennyiben viszont λin (és λin ) értéke jelentősen nagyobb, akkor az áteresztőképesség a
forgalomirányítóknál lecsökken és közelíti a 0-t, miközben a kihasználtság tovább növekszik,
hiszen a kialakuló torlódás következtében a később érkező csomagok eldobásra kerülnek. Ennek a
jelenségnek a grafikonja a 4.31 ábrán látható.
C/2
out
in’ C/2
4.31: 3. eset teljesítménye véges pufferekkel és több ugrásos utakkal1
Ezzel látható a torlódás másik ára, azaz amikor egy csomagot eldobnak az addig igénybevett
továbbító kapacitás feleslegessé válik.

Visszakanyarodva a TCP-hez, megvizsgáljuk a torlódásvezérlés mechanizmusát.
Fontos Mivel az IP nem szolgáltat explicit információt a hálózatban kialakuló esetleges

torlódásról, ezért a TCP-nek vég-vég torlódásvezérlést kell alkalmaznia.
A TCP megközelítésmódja az, hogy az érzékelt hálózati torlódás alapján próbálja növelni az küldési
sebességet. Ha kis torlódást érzékel, akkor növeli a sebességet, ha nagy torlódást érzékel, akkor
csökkenti.
A küldési sebesség meghatározásához a TCP fenntart egy változót, amely a torlódási ablakot
jelöli (cwnd). Az itt tárolt érték határozza meg a küldési sebességet, konkrétan a küldő nyugtázatlan
szegmenseinek a száma nem haladhatja meg az ütközési ablak és a vevő ablak minimumát.
LastByteSent − LastByteAcked ≤ min{cwnd, rwnd} (4.8)
A torlódásvezérlésre koncentrálva vizsgáljuk meg az alábbi feltételezést! Legyen a TCP vevő

pufferének a mérete olyan nagy, hogy a vevő ablak megszorítás figyelmen kívül hagyható. Ennél
fogva (az előző formulából is látszik) a küldőnél a nyugtázatlan szegmensek számát a torlódási
ablak határozza meg (cwnd). Mivel a nyugtázatlan adatra adtunk egy felső korlátot, így ez indirekt
módon korlátozza a küldő küldési sebességét is. Ahhoz, hogy ezt belássuk, a csomagvesztés és
az átviteli késleltetés elhanyagolható. Így nagyjából minden RTT elején a küldő cwnd bájtot tud
küldeni, és RTT végén kap visszaigazolást is az adatokra. Így a küldő küldési sebessége cwnd/RT T
bájt/másodperc.
Ezek tudatában azonban még mindig felmerül a kérdés, hogy a TCP hogyan határozza meg
a küldési sebességet? Erre ad választ a TCP torlódásvezérlés algoritmus, melyet először Van
Jacobson írt le 1988-ban, majd az RFC 5681-ben szabványosítottak. Az algoritmus három fő
komponensből áll:
1. lassú indulás
2. torlódás elkerülés
3. gyors helyreállás
4.7.1 Torlódásvezérlés algoritmus

Lassú indulás
Egy TCP kapcsolat indításakor a cwnd értéke 1 MSS. Így az iniciális küldési sebesség körül-belül
MSS/RTT. Például, ha MSS=500 bájt és RTT=200 ms, akkor az induló küldési sebesség körül-belül
20 kbps. A TCP számára elérhető legmagasabb sávszélességnek természetesen nagyobbnak
kell lennie, mint MSS/RTT, és ezt szeretné a lehető leggyorsabban elérni. Éppen ezért a cwnd
értékét minden visszaigazolt szegmens után megnöveli 1 MSS-sel, így a második küldéskor már
két MSS méretű szegmenst küld ki. A kiküldött két szegmensre 1-1 visszaigazolás érkezik, így
visszaigazolásonként újabb 1-1 MSS-sel növeli a küldési sebességet, ahogy azt a mellékelt 4.32 ábra
is mutatja. Ezért kijelenthetjük, hogy a lassú indulás valójában exponenciális sebesség növekedést
jelent.
Mikor kell megállni a sebesség növelésével?
Ha csomagvesztés történik (pl.: torlódás miatt), akkor a TCP küldő visszaállítja cwnd értékét
1 MSS-re, és újraindítja a lassú indulás komponensét az algoritmusnak. A cwnd értékén túl
beállításra kerül egy második állapotváltozó, az ssthresh ("slow start threshold"), amely az ütközés
detektálásakor használt cwnd érték felére lesz beállítva. Ez garantálja azt, hogy a lassú indulás
folyamata újból ne jusson el az ütközés pontjáig a túl nagy küldési sebesség miatt. Ily módon cwnd
újbóli növelése az ssthresh értékig megengedett. Ha ezt az értékek elérte cwnd, akkor az algoritmus
átlép a torlódás elkerülés fázisába.
Torlódás elkerülés
Ebben a fázisban cwnd értéke körül-belül fele akkora, mint a torlódás bekövetkeztekor. Így ahelyett,
hogy az aktuális cwnd értéket megkétszerezzük, inkább csak növeljük mindig 1 MSS-sel minden
RTT után. Azonban felmerül a kérdés, hogy ez a lineáris növekedés meddig tarthat? A következő
4.7 TCP torlódásvezérlés 97
A gép B gép
RTT
idő idő
4.32: TCP lassú indulás1
csomag vesztésig, amelyet egy háromszorosan duplikált nyugta igazol. Ilyenkor a ssthresh
értékét frissítjük azon cwnd érték felére, amelyet a háromszorosan duplikált nyugta pillanatában
tároltunk, cwnd-t pedig visszaállítjuk a felére. Ezzel átlépünk a gyors helyreállás fázisba.
Gyors helyreállás
Ebben a fázisban cwnd értékét 1 MSS-sel növeljük minden duplikált nyugta esetén. Amikor a
hiányzó szegmensről megérkezik a nyugta a küldőhöz, az algoritmus visszalép a 2-es fázisba
(torlódás elkerülés). Időtúllépés esetén visszalépünk a lassú indulás lépéshez, és cwnd értéke ismét
1-ről indul.
A gyors helyreállás ajánlás a TCP-nél, nem szükségszerű komponens. A TCP korai verziójánál,
a TCP Tahoe-nál a torlódási ablak mindig visszaállításra került 1 MSS-re, ezzel visszalépve a lassú
indulás fázisába, függetlenül hogy az adatvesztést háromszorosan duplikált nyugta vagy időtúllépés
okozta. Az újabb, TCP Reno implementáció már tartalmazza gyors helyreállás komponenst. A
4.33 ábrán látható diagram szemlélteti a TCP különböző verzióinak működését.
A lassú indulástól eltekintve a TCP torlódásvezérlés voltaképp a torlódási ablak lineáris
növekedéséből (cwnd növelése 1 MSS-sel minden RTT után), majd annak lefelezéséből áll.
Ezt szokták nevezni a torlódásvezérlés "additív növekedés, multiplikatív csökkenés" (AIMD)
formájának is. Ez a "fűrészfog" viselkedés, mely látható a 4.34 ábrán is, igazából a sávszélesség
próbálgatását jelenti. A következő rövid fejezet azonban rávilágít arra, hogy ennek miért és mikor
van jelentősége.
4.7.2 TCP igazságosság

A TCP célja az igazságosság, mely szerint ha K TCP kapcsolat ugyanaz az R sávszélességű vonalat
használja, akkor mindegyiknek R/K sávszélességet kell biztosítani (4.35 ábra).
Ha feltételezzük, hogy a vonalon csak TCP kapcsolatok vannak, akkor a torlódásvezérlés
következtében ez valóban kivitelezhető, és ezzel a küldési sebesség is korlátozható. UDP esetében
azonban más a helyzet, ott nincs torlódásvezérlés. Az UDP-t használó protokollok nem szeretnék,
ha a torlódásvezérlés lefojtaná a rendelkezésükre álló sávszélességet. Például a multimédia
alkalmazások leggyakrabban így működnek, ugyanakkor ezek tolerálják is a csomagvesztést.
16
Ütközési ablak (szegmensekben)

14
12
10
8 ssthresh
6 TCP Tahoe
TCP Reno
4
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Átviteli körök
4.33: TCP torlódási ablak evolúciója (Tahoe és Reno)1
W
Ütközési ablak
W/2
Idő
4.34: Additív növekedés, multiplikatív csökkenés (AIMD) jelenség1
Azonban, ha az UDP még igazságos is volna, akkor sem oldódna meg teljesen a sávszélesség
megosztásának a problémája, hiszen vannak olyan TCP feletti alkalmazások, amelyek párhuzamos
kapcsolatokat nyithatnak. Ilyen elven működnek a Web böngészők is. Példaként vegyünk 9
kliens-szerver alkalmazást, amelyek mindegyike TCP felett kommunikál egy R sávszélességű
vonalon. Ha megnyílik egy 10. alkalmazás, akkor minden alkalmazás küldési sebessége lekorlátozódik
R/10-re. De, ha egy új alkalmazás 11 párhuzamos TCP kapcsolatot használ, akkor az új alkalmazás
egy igazságtalan allokációval él, ami nagyobb, mint R/2.
4.7.3 Explicit torlódás értesítés (ECN)
Ahogy azt a TCP bevezetésekor tárgyaltuk, egy megbízható protokollt helyezünk a megbízhatatlan
IP-re. Mivel az IP nem ad explicit visszajelzést a TCP-nek a hálózati torlódásról, ezért ez az ő
feladata erre következtetni a csomagvesztésekből. Azonban készült egy olyan kiegészítés az IP-hez
és a TCP-hez, amellyel a hálózat explicit jelezheti a küldőnek és a fogadónak, ha torlódás van.
Az IP csomag fejlécében a ToS mezőt (2 bit) használhatja a forgalomirányító a torlódás jelzésére.
A vevő gép kezeli a torlódásvezérlést, ezért ha a vevő lát az IP-ben ECN-t a ToS mezőben, akkor a
TCP nyugtában az ECE flag bit 1-re állításával jelzést adhat a küldőnek.
1. TCP kapcsolat
R kapacitású vonal
2. TCP kapcsolat
4.35: Két TCP kapcsolat egy közös vonalon1

1. Ismertesd röviden a szállítási réteg szolgáltatásait és protokolljait.
2. Mi a szerepe a szállítási réteg multiplexelés/demultiplexelés képességének?
3. Ismertesd az UDP szolgáltatásait, mire használjuk, hogyan néz ki a szegmens fejléc?
4. Hogyan működik az Internet ellenőrző összeg? Ismertesd ezt egy példával.
5. Ismertesd a megbízható adatátvitel alapjai. Ismertesd az RDT 3.0 alapelveit vázlatos FSM
modell segítségével.
6. Milyen cső szervezésű protokollokat ismerünk? Mi ezek szerepe?
7. Lehet-e UDP felett is megbízható átvitel? Ha igen, hogyan?
8. Az RDT protokollban miért volt szükség sorszámra?
9. Az RDT protokollban miért volt szükség időzítőre?
10. Ismertesd a TCP fontosabb képességeit alapelveit.
11. Ismertesd a TCP szegmens struktúra fontosabb elemeit, azok szerepét.
12. Ismertesd a TCP szekvenciaszámok szerepét és a nyugták elveit.
13. Ismertesd a TCP megfordulási idő, fogalmát, mérési módját, az időtúllépés meghatározását.
14. Ismertesd a TCP megbízható adatátvitel során használt elveket.
15. Ismertesd a TCP folyamvezérlés lépéseit a TCP ACK generálás eseteit.
16. Ismertesd TCP kapcsolatmenedzsment feladatát.
17. Ismertesd a torlódásvezérlés alapjai, motivációját.
18. Ismertesd TCP torlódásvezérlést.

19. Miért használják a TCP csatornát hang és videó továbbítására is?


Tisztában van a Különbséget Érdeklődik Önállóan
szállítási réteg tesz a szállítási megbízható meghatározza
feladatával, és a rétegbeli protokollok megoldások iránt. egy alkalmazáshoz a
kapcsolatmentes felhasználási Szem előtt tartja használható szállítási
átvitel alapjaival. területeiben. a kapcsolatmentes rétegbeli protokollt.
Ismeri a átvitel problémáit
multiplexelés és az alkalmazás
demultiplexelés rétegbeli protokollok
fogalmait. használata során.
Tisztában van a Különbséget Nyitott a megbízható Ellenőrzi valós
kapcsolatorientált tesz a szállítási átvitelnél látottak rendszeren a
átvitel alapjaival. rétegbeli protokollok alkalmazására sikertelen átvitel
Felismeri a leírásában és megbízhatatlan hibáit és önállóan
kapcsolatorientált működésében. átvitel esetén. javaslatot fogalmaz
szállítás protokollját meg a hiba javítására
(TCP). Tisztában van vonatkozóan.
a folyamvezérlés
és torlódásvezérlés
alapjaival.
5. Hálózati réteg

• Az alkalmazások háttér rendszerei felhőben, vagy valóságban IP hálózatként vannak
megvalósítva, a biztonság/replikációs/alkalmazás zónákra bontáshoz kritikus az alhálózatok
kialakítása és forgalomirányítók konfigurálása.
• IoT rendszerek esetében a különböző NAT variációk kezelése ezek mély megértését
igényli.
• Az SDN mutatja azt az irányt ami ma már elérhető, illetve elérhető lesz a felhő szolgáltatások
hálózat virtualizációs képességeiben.

Az előző fejezetben ismertetett réteg lehetővé teszi a hálózat szélein elhelyezkedő résztvevők
processzusai közötti kommunikáció. Ezt egy cső absztrakció segítségével teszi függetlenné az alatta
lévő rétegtől. Az eddig megismert rétegek mind a hálózat szélein futottak, akár kliens és szerver
környezetben, akár szerver-szerver környezetben. A végfelhasználóink tehát megvoltak, de a képből
hiányzott az, aki ezen adatokat ténylegesen eljuttatja egyik helyről a másikra. Ennek megszervezése
és megvalósítása a hálózati réteg feladata. Mint ahogyan eddig is, itt sem egyedül oldja meg a
feladatát. Épít az adatkapcsolati és a fizikai rétegre. A posta analógiára visszavezetve a hálózati réteg
adja az irányítószámokat és a postahivatalokat, az felhasználókhoz a levelet közvetlenül eljuttató
postások vagy a nagyobb hivatalok között közlekedő furgonok, postavagonok az adatkapcsolati és
fizikai rétegnek felelnek meg. A hálózati réteget szokták még a homokóra modellben is ábrázolni,
ami jól mutatja a kitüntetett szerepét. A fejezet terjedelmi korlátok miatt nem tud mindent kellő
mélységben tárgyalni, így javasoljuk a [6] tankönyv olvasását is részletek megismerése, mélyebb
megértés érdekében. Fölötte és alatta is specifikus célú protokollok vannak. De az IP minden
kapcsolatban közös. Ezt használják az üzemkritikus kórházi rendszereken túl a filmnézésen át
az okosórák frissítéséig minden kommunikációs viszonylatban. Jelen fejezetben a hálózati réteg
feladatait, felépítését és néhány fontos protokollját fogjuk áttekinteni.
102 5. fejezet - Hálózati réteg
5.1: Hálózati réteg feladata, IP homokóra

A hálózati részben a postahivatalok hálózati megfelelői a forgalomirányítók (forgalomirányító).
Ők alkotják a hálózatot. A végfelhasználók és a szerverek forgalomirányítókhoz kapcsolódnak
amelyek tudják hogy merre kell továbbítani az adatcsomagot és továbbítják is azt. Egy-egy
forgalomirányítónak több interfésze van. Az a dolga, hogy az adott interfészén beérkező csomagot
a célnak megfelelő másik interfészén kiküldje. Ezek az interfészek vannak kapcsolatban a konkrét
adatkapcsolati réteggel és fizikai réteggel (optika, WiFi, Ethernet...). A számítógép hálózat tehát
ilyen forgalomirányítókból és a közöttük lévő fizikai kapcsolatokból áll (látjuk majd később, hogy
itt lehetnek még egyébb eszközök is az útvonalon, de most maradjunk ezen az absztrakciós szinten).
A megoldandó probléma méretére jó támpont az, hogy a forgalomirányítók számára egy jó becslés
az, hogy több mint 750.000.000 darab van belőlük (majd látjuk, hogy a forgalomirányítónak is több
kategóriája van). Ezekhez kapcsolódik 4.500.000.000 felhasználó, akik naponta 4.000.000.000
GByte adatot küldenek át. E rendszert kell működtetni, megtalálni a legjobb útvonalat a 750 millió
eszköz között és továbbítani a forgalmat a vonalakon. Hogy a probléma még érdekesebb legyen, ez a
hálózat igen dinamikusan változik mert a felhasználók mozognak, a forgalom dinamikus és mert
hibák mindig előfordulnak. Fontos azt megjegyezni, hogy a rétegben szereplő forgalomirányítók
csak a protokollverem első 3 rétegével foglalkoznak. Egy forgalomirányító nem nézi meg a
HTTP üzenetek mezőit. A hálózati réteg a hálózatot, mint gráfot tekinti, ahol a gráf csomópontjai a
forgalomirányítók, a végpontjai pedig a felhasználók, szerverek.

A hálózati rétegnek tehát szállítania kell az információkat és a szállításhoz szükséges döntéseket is
meg kell hoznia. Melyik út a legcélszerűbb? Ezen problémák kezelése érdekében két síkra bontják:
• adat sík: Feladata az sdatok továbbítása (forwarding), ehhez megfelelő csomagolás
megvalósítása.
• vezérlő sík: Feladata a hálózat topológiájának megismerés és a helyi döntésekhez szükséges
információk begyűjtése összegezve - a forgalomirányítás (routing).
Az adatsík és a vezérlési sík a forgalomirányító táblájában (routing table) ér össze, ezt tölti,
frissíti a vezérlés és ezt olvassa a továbbítás.

Az adatsík dolga tehát, mint ahogyan láttuk, a csomagok továbbítása. A rétegben kezelt információegységet
csomagnak (packet) nevezzük. A hálózat entitásai a rétegen belül ezen csomagok plusz információi
5.3 Hálózati réteg: adatsík 103
5.2: Hálózati rétegek, eszközök1
segítségével kommunikálnak egymással. A szállítási rétegből megkapják a szegmenst és azt

kiegészítik, becsomagolják a hálózati réteg alapegységébe, a csomagba. Ilyen csomag az IPv4-es
és az IPv6-os csomag. Ezen csomagok magukban hordozzák a cél és a forráscímet. Az adatsíkban a
forgalomirányító a csomagokat egyesével kezelve megnézi a csomagban lévő cél címet, megnézi az
ennek megfelelő bejegyzést a forgalomirányító táblában és az ott megjelölt interfészre továbbítja.
5.3.1 A forgalomirányítók felépítése

A forgalomirányító tehát a forgalomirányító tábla bejegyzései alapján az interfészei között továbbítja
a csomagokat. Részletesebb felépítése látható a 5.4 ábrán. Az interfészeit portoknak is szokták
nevezni. A portokat/interfészeket egy-egy csomag szempontjából feloszthatjuk bemeneti és
kimeneti portra. Ha portokat pontosabban szeretnénk meghatározni, akkor ezek olyan logikai
elemek melyek hálózati rétegbeli címekkel bírnak. Az interfész tehát általában fizikai (pl.:
Ethernet), míg a port jellemzően logikai (egy Ethernet interfészen két logikai cím/port). Ezen
portokat megvalósító szoftver megoldások (adott esetben egy-egy processz) a bejövő csomagokat
egy memória területre másolják. Ezt nevezzük bemeneti portnak (input port), vagy bemeneti
várakozási sornak (input buffer/queue). Az itt lévő csomagokat a kapcsoló motor (switch
matrix) segítségével átmásolja a forgalomirányító a megfelelő interfész megfelelő portjának
memória területére. Ez a kimeneti port (output port) és kimeneti várakozási sor (output
buffer/queue).
Kiemelt jelentősége van annak, hogy mind a bemeneti, mind a kimeneti memória területen több
csomag is elfér. Ennek akkor van jelentősége, amikor több csomag érkezik mint amennyit a kapcsoló
motor át tudna másolni a kimeneti sorhoz, vagy ami sokkal jellemzőbb, több csomag érkezik be
a bemenő porton mint amennyit továbbítani lehetne a kimeneti porton. Ekkor a memóriában
várakoznak.
Fontos Amennyiben a memória megtelik, akkor a forgalomirányító adott csomagokat

egyszerűen figyelmen kívül hagy. Ezt gyakran a csomag törlésével valósítja meg. Ez az a pont,
ahol a legjobb szándék szerinti továbbítás, az Internet egyik alapelve leginkább megfigyelhető.
Azt a jelenséget amikor bemeneti port várakozási sorában a csomagokat sorban dolgozza fel
és épp a továbbítandó csomagot nem tudja továbbítani a célport foglaltsága miatt HOL (sor
5.3: Hálózati réteg adatsík vs. vezérlősík1
5.4: várakozási sorok és HOL blokkolás1
eleji blokkolásnak - head of line blocking) nevezzük. Ezt lehet úgy kezelni hogy a sorrendet
felborítva azokat továbbítja amelyeket tudja ez a nem sorrendhelyes továbbítás (out of order
delivery). Látjuk, hogy fizikai hibák nélkül is felborulhat a csomagok sorrendje és eltűnhetnek
csomagok. Ezek kezelését végzi a már megismert TCP. A várakozási sorok kezeléséhez az
eddigiekben a FIFO (először be, először ki - First In First Out) megoldásról beszéltünk, mint
legtermészetesebb algoritmusról. Van azonban olyan eset, amikor meg szeretnénk különböztetni a
forgalmat. Például a telefon hívásokat előnyben szeretnénk részesíteni a fájl letöltésekkel szemben.
Ezt a mai Internet architektúrában csak itt, a várakozási sor menedzsmentben tudjuk megoldani.
Ennek egyik lehetséges módja a prioritásos ütemezés (priority queueing). Ekkor több várakozási
sor van és a magasabb prioritásúak vannak előnyben részesítve, azaz ha ott van csomag akkor
azokat kezeli. Itt probléma lehet az alacsonyabb prioritású sorok kiéheztetése. Erre megoldást nyújt
a WFQ súlyozott igazságos ütemezés (weighted fair queuing). Ekkor adott súlynyi darabot
továbbít minden sorból. A várokozási sorok elmélete nagyon komoly múlttal és mélységgel bír a
távközlésben. Egy jó kiinduló pont lehet ez a könyv a terület mélyebb megismerésére [1].
A kapcsoló motor több módon is megvalósítható. Lehet egyszerű memória másolás, vagy osztott
memória a részvevő processzusok között. Ez a megoldás gyors, de ekkor perifériák (interfészek) is
5.5: Prioritásos és súlyozott prioritásos várakozási sorok1
fizikailag ugyanazon az alaplapon helyezkednek el, így ennek a skálázhatósága korlátos. Lehet busz
rendszerű is, amikor a perifériák már saját memóriával bírnak, ilyenkor egy elosztott rendszerünk
(a perifériák képesek önálló programot futtatni, különálló kis számítógépek) van és az egyes
perifériák, illetve a központ a buszon keresztül kommunikálnak egymással. Ez a megoldás már
skálázhatóbb, mert a buszra újabb és újabb perifériákat köthetünk, ezeket kicserélhetjük stb.,
de a busz sávszélessége és az, hogy egyszerre csak egy kommunikációs viszonyt engedélyez,
komoly szűk keresztmetszetet okoz. A legnagyobb kapacitású forgalomirányítók teljes rács
(crossbar) megoldással bírnak, amely egy adott pillanatban minden portot minden porttal a teljes
port sávszélességgel tud összekötni. Itt tehát egyidőben az összes port adhat/vehet bármelyik másik
porttal. Itt is probléma persze, ha több port akar egy porttal beszélni, ekkor az adott port várakozási
sora kezeli ezt az ütközést.
5.6: Kapcsoló megoldások1
Azt hogy a kapcsoló motor honnan tudja, hogy kit kivel kell összekötni, az mint ahogy említettük,
csomagonként dől el: a bemeneti várakozási sorban egy helyi vagy központi processzus kiválasztja
a továbbküldendő csomagot és kiolvassa annak megfelelő mezőjét (ez IP csomagoknál a cím
mező, de mint látjuk később a szoftverrel definiált hálózatok esetén itt több mezőt is figyelembe
vehet). Ezt a mezőt vagy ezen mezőket összeveti a forgalomirányító vagy továbbítási táblázat
a megfelelő mezővel és megkeresi ott a pontosan (vagy legjobban) egyező sort és abban a
sorban megadott kimeneti portra másolja, vagy mint látni fogjuk SDN esetén adott utasításokat
hajt végre. Ez a keresés, bár egyszerűnek tűnik, korántsem triviális feladat. Ma a gerinc
forgalomirányítókon kb.: 500.000 bejegyzés van, ez még nem is olyan sok, de gondoljunk bele,
hogy olyan gyakran jönnek be csomagok, hogy ezt meg kell tenni másodpercenként 1.000.000
és 10.000.000 közötti alkalommal egy 10 GBits-os vonalon csomag mérettől függően. Ezt a
feladatot ezért jellemzően nem szoftveresen, hanem hardveresen oldják meg speciális ASIC
alkalmazásspecifikus integrált áramkör (application-specific integrated circuit) segítségével,
amely egy memória ciklus alatt visszaadja az egyező CAM - tartalommal címezhető memória
(content addressable memory) vagy a leginkább egyező TCAM - hármas tartalommal címezhető
memória (ternary content addressable memory) bejegyzést. Az eddig leírt működésben általánosságban
kezeltük a csomagokat, a következőekben konkrét hálózati rétegbeli protokollokat tekintünk át.
5.3.2 Az IP protokoll
Ma az Internet alapja az IP Internet Protocol. Sikere az egyszerűségében rejlik. A felső rétegből
érkező UDP vagy TCP szegemenesek jellemzően IP csomagokba burkolva lesznek elküldve
(persze ezek a fizikai közeg és az adatkapcsolati protokoll függvényében további beágyazásokba,
burkolásokba kerülnek.) Az IP csomag felépítése a 5.7 ábrán látható. Legfontosabb mezői a 32
5.7: IP csomag
bites cél és forrás cím. Az adat mezőben található az UDP vagy TCP szegmens. Fontos mező még
a Time-to-live TTL, amely a nevétől eltérően ma nem időt, hanem ugrás számot jelent. A küldő
megmondhatja e mező segítségével, hogy maximálisan mennyi forgalomirányítón keresztül mehet
a csomag. A forgalomirányítók e mezőt minden továbbítás előtt csökkentik eggyel, ha ez nulla,
akkor hibajelzést küldenek vissza és a csomagot kidobják. Ennek a megoldásnak nagy jelentősége
van az Internet stabilitása szempontjából. Láttuk, hogy több 100.000 forgalomirányítónak kell
együttműködnie. Vannak olyan esetek, amikor nem érvényes információ alapján döntenek és így
hurkok keletkezhetnek (a csomag körbejár). Enélkül a mező nélkül ezen csomagok végtelenségig
keringhetnének, nem kicsi terhelést okozva. Később majd látjuk, hogy az Ethernet protokollnak
nincs ilyen mezője, ami komoly gondot okoz a helyi hálózatokban. Egy kevésbé fontos, de érdekes
mező a Fragmentation offset (darabolás eltolás).
Fontos Az adatkapcsolati rétegbeli protokollok a konkrét fizikai közeg képességei mentén

adott méretű csomagot tudnak csak továbbítani, ez az MTU - maximálisan továbbítható
egység (maximal transfer unit). Ez a kényszer a hálózati réteg és az adatkapcsolati réteg
között jelenik meg.
A felsőbb rétegekben, hogy mekkora egy szegmens, vagy mekkora információ darabot küldök
át egy HTTP kérésben, nincs ilyen szinten korlátozva. Itt viszont Ethernet esetén például 1500
bájtos lehet egy csomag, amit át tudunk küldeni. Ezt a problémát az IP réteg kezelte régen azzal,
hogy a nagyobb szegmenseket darabolta és azok darabjait küldte át. Ez a megoldás azonban
szembe megy az Internet alapelveivel - azzal hogy a gerinc állapotmentes - tehát esetünkben a
forgalomirányítónak meg kell jegyezni, hogy egy-egy csomagnál melyik darabot küldték már át.
Emiatt és egyéb problémák miatt (ha elveszett egy darab akkor újra küldheti az egészet) ma a
forgalomirányítók nem darabolnak, hanem jelzik, hogy adott csomag nagyobb mint az MTU és a
csomagot kidobják.
Az eddig bemutatott elemek a fix fejléc elemei voltak. Igény van azonban arra, hogy a protokoll
fejlődjön újabb képességekkel bővüljön. Az új igényeket opcionális fejlécek segítségével lehet
megvalósítani. Ilyen például a forrás specifikus forgalomirányítás fejléc, (LSR loose specific
routing) amikor a forrás állomás megad egy forgalomirányító listát, hogy a forgalomirányítók ezen
lista mentén küldjék a csomagot. Ezeket a mezőket ma a legtöbb forgalomirányító figyelmen kívül
hagyja.
5.3.3 IP címzés
Az IP protokoll legfontosabb képessége a címzésben rejlik. Az előzőekben láttuk, hogy a
gerinc forgalomirányítókon másodpercenként 1.000.000 és közötti 10.000.000 keresés történik
a forgalomirányító táblában minden interfészhez. Nagyon lényeges tehát e tábla mérete. Azt
is láttuk, hogy ez tipikusan 500.000 bejegyzést tartalmaz. Az előző részben ismertetett csomag
fejlécben 32 bites címek vannak amelyek segítségével a függően kb.: 2.000.000.000 címet lehet
megadni. Legrosszabb esetben a forgalomirányító táblának minden címet tartalmaznia kellene.
Így működnek a lapos címteret megvalósító címzési sémák (pl.: Ethernet). Belátható, hogy
nagyon nehéz lenne olyan rendszert megvalósítani, amely minden felhasználó 2.000.000.000
IP címét folyamatosan karban tartaná 700.000.000 forgalomirányítón és ezek képesek lennének
ennyi címben másodpercenként 1.000.000 keresést megvalósítani. Az IP címzés ezért nem lapos,
hanem hierarchikus címzési sémát alkalmaz. Az IP címek hierarchiája nagyjából követi a fizikai
hálózat hierarchiáját és a DNS hierarchiáját. A hierarchia kezelése az IANA kezében van, mely nagy
5.8: IP címek kiosztási és a fizikai infrastruktúra hierarchia
címtartományokat ad ki nagy cégeknek vagy országoknak. Ezek részben kontinens szinten rögzített
szabályok mentén valósulnak meg. Ezen nagy cégek, vagy országok pedig tovább osztják kisebb
cégeknek. Így a fizikai felépítést követi a logikai IP címzés szintű hierarchia.
Fontos Az IP címek 32 bitesek. Ezt két részre szokták bontani, az első néhány bit a hálózatot
határozza meg, a maradék bitek meg amennyiben a legalsó szinten vagyunk, akkor az állomást.
Az, hogy egy IP cím mekkora része hálózat és mekkora host, helyi jelentőségű hálózati
maszkkal szokás megadni.
A hálózati maszk egy 32 bites szám, ahol egyesek jelölik azokat a biteket, amelyek hálózati részhez
tartoznak. A 255.255.255.0 azt jelenti, hogy az első 24 bit az adott IP címben a hálózati címet adja
meg. Ezt egyszerűsítve szokták egy számmal is jellemezni /24. A forgalomirányítók a beérkező
csomagok cél címéből mindig csak a hálózati részre kíváncsiak, mivel nem gépet, hanem
hálózatokat keresnek. Az, hogy adott esetben milyen hosszú a hálózati maszk, a forgalomirányító
tábla bejegyzés hordozza magában. A hálózati címet szokták még előtagnak (prefix) nevezni.
Egy-egy szervezet egy IP cím tartományt kaphat, amit saját belátása szerint tovább oszthat.
5.9: IP cím belső ábrázolás, alhálózati maszk értelmezése
Az ilyen tovább osztott hálózatokat nevezzük alhálózatoknak (subnet). Régen az IP címeket

cím osztályokra bontották, ennek végét jelentette a ma is alkalmazott CIDR - Osztálymentes
Tartományok közötti forgalomirányítás (classless interdomain routing). Itt nem csak az osztályok
tűntek el, hanem megjelent a cím aggregálás is. Ez volt az az eljárás, amellyel sikerült megállítani
az Internet gerinc forgalomirányítók tábláinak robbanásszerű növekedését. Az aggregálás azt jelenti,
hogy ahelyett, hogy adott címtartomány minden hálózatát külön-külön meghirdetnénk, csak egy,
ezeket lefedő hálózatot hirdetek meg. Ezzel akkor lehet gond, ha az alhálózatok nagy része egy
szolgáltató kezében van, de vannak kivételek. Az ilyen helyzet lehetetlenné tenné az aggregálást,
ha nem lenne a forgalomirányító táblákban a pontos egyezés helyett a leghosszabb előtag szerinti
keresés. Így az, akinek a kezében van az adott hálózati címek nagy része, meghirdetheti az
egészet egy sorban pl.: /12-es hirdetésben. Akinek viszont ezekből darabjai vannak meg, azok
azokat a darabokat hirdetik meg specifikusabb előtaggal pl.: /16. A forgalomirányító mindkét
bejegyzést egyezőnek veszi, de azon célcímek esetén, melyek ebbe a /16-os tartományba esnek,
ez egy specifikusabb egyezés lesz, így ez az útvonal lesz kiválasztva. Ma a gerincben nem lehet
5.10: Cím aggregálás és tartomány hirdetés1
/16-os hálózatnál specifikusabbat meghirdetni. Így védik a gerinc forgalomirányító táblát a cím
robbanástól.
5.3.4 Hálózati címfordítás, NAT

Láthattuk, hogy a 32 bites címzéssel nagyjából 2.000.000.000 végpontot lehet megcímezni, de azt
is láttuk az előzőekben, hogy nagyjából 4.500.000.000 felhasználó van. Ez alapján nem jut minden
felhasználónak IP cím. Az IP sikeres működéséhez viszont elengedhetetlen, hogy egy IP cím csak
egy helyen legyen használva. Gondoljuk a postás analógiára, ha ugyanazt a címet többször is
használjuk, akkor a postás nem tudná, hogy az azonos címek mögött lévő különböző emberek
közül kinek és hova kézbesítse a levelet (pl.: Budapesten vannak azonos nevű utcák, melyeket a
kerület tesz egyedivé). Az IP címtartomány kimerülése nem mai probléma, még a 1990-es évek
második felében felmerült a forgalomirányító tábla méret robbanással együtt. A címtartomány
kimerülésére akkor “ideiglenes” megoldást dolgoztak ki, mert a végső, korrekt megoldásnak az
IPv6-ot szánták (a maga 128 bites címtartományával). Ez az “ideiglenes” hack azóta is működik
és annyira sikeres, hogy az IPv6 penetrációja még mindig 30% alatti. Az ötlet lényege az volt,
hogy kezeljük az IP címeket és UDP/TCP portokat együtt. Egy-egy IP címhez 65.000 TCP és
65.000 UDP port tartozik. Az így létrejövő címtartomány kellően nagy. Az egyes programok,
operációs rendszerek azonban külön kezelik (helyesen) az IP címet és a TCP vagy UDP portot. Ezen
címek összevonására és kicserésélésre köztes dobozokat helyeznek a hálózatba. Ezen dobozok a
bejövő/kimenő IP címeket és portokat más IP címre és portra cserélik mindkét irányban. Ezt nevezik
NAT - hálózati címfordításnak (network address translation). Ezt az ötletet valósították meg új
címosztályok és új hálózati elemek/funkciók kialakításával. Az IP címtartományból kiválasztottak
3 tartományt, amelyek szabad felhasználásúvá váltak. Ezek a privát címtartományok. Ezek nem
5.11: Privát címtartományok
egyediek világszinten, ezeket bárki bárhol használhatja. Ezzel megoldódott a hálózat hozzáférési
részein a címtartomány kimerülése, hiszen ezeket a tartományokat bárki újrahasznosíthatta. Ezen
címeket tartalmazó csomagok azonban értelemszerűen nem küldhetőek tovább az interneten,
mivel több helyre is mehetnének. Itt jönnek képbe az új elemek. A megoldás lényege, hogy
ahogyan azt leírtuk eddigi állapotmentes rendszerben beiktatunk köztes dobozkat (middle box),
amelyek állapottartóak és átírják a rajtuk áthaladó csomagok cél és forrás címét, illetve cél és
forráspontját. Azaz a helyi hálózat és az Internet hozzáférési pont között (vagy mélyebben ez a
CGNAT) van egy olyan eszköz amely a privát IP cím és port párokat publikus IP cím port párra
cseréli a kifelé tartó csomagokban és ugyanezt megteszi visszafelé is. Az hogy mit mire cserélt ki,
a memória táblában van nyilvántartva (állapot tartás). Így ha a szolgáltatótól kapok egy darab
publikus IP címet az otthoni hálózatomban ehhez a címhez és külső porjaihoz rendelhetek 65000
darab eszközt amennyiben mindegyik egy-egy kapcsolatot tart fenn. Összegezve tehát, a privát
IP cím tartományokkal és a köztes dobozokkal (NAT átjáró) megoldódott az IPv4 címtartomány
kimerülése. Mert itt egy-egy IP cím mögé 65.000 másik címet tudok elrejteni. A NAT szembe
megy az Internet filozófiájával, ha ugyanis egy NAT átjáró újraindul, akkor az összes rajta
keresztülmenő adatfolyamot újra kell indítani, mert nem tudja, hogy melyik címet melyik címre és
portra cserélt le. Nagyobb gond az, amikor a NAT mögött lévő eszközök egymással szeretnének
beszélgetni. Ilyenkor különböző eljárásokra van szükség, hogy megtalálják egymás publikus IP/port
párját. Van olyan eset is, amikor ez nem lehetséges. Ennek ellenére ma az Interneten lévő eszközök
nagyon nagy hányada (90% feletti része) NAT mögött van.
5.12: NAT működése1
5.3.5 Dinamikus cím kiosztás (DHCP)

Láthattuk, hogy a cím tartományokat az IANA osztja ki a különböző szervezeteknek, akik ezt
felbontják és eladják, majd ezt újra felbontják és újra eladják. Ez azonban csak logikai kiosztás volt.
Arra továbbra sem válaszoltunk, hogy ha elindul egy PC, akkor az honnan tudja hogy mi az ő IP címe.
Erre a problémára több megoldás is van különböző környezetekben. A legelterjedtebb megoldás
a DHCP - dinamikus host konfiguráló protokoll - (dynamic host configuration protocol)
protokoll. Ez egy kliens-szerver protokoll. A kliens címet kér, a szerver pedig ad neki egy címet. Az
5.13: DHCP működése1
IP protokollal kapcsolatban eddig csak a pont-pont kommunikációs képességről beszéltünk, azaz

egy állomás megcímez egy másik állomást. Ezt nevezik egyes küldésnek (unicast). Van azonban
olyan eset is, amikor egy állomás mindenkinek szeretne üzenet küldeni. Ez Internet méretben persze
értelmetlen, az ilyen forgalmat a forgalomirányítók nem továbbítják, de helyi hálózaton az ilyen
kommunikációs paradigma teszi lehetővé a P2P szerver mentes megoldások megvalósítását. Amikor
egy állomás mindenkihez szólni szeretne, azt üzenetszórásnak (broadcast) nevezzük. A DHCP
esetén is ez jelenti a megoldást. A PC elindul és nem tud a világról semmit sem. Elkezd “kiabálni”
hogy kér egy IP címet. Ezt minden, az adott alhálózaton lévő állomás megkapja és a szerver meg
is érti, majd válaszol is rá. Az üzenetszórásnak speciális IP cím van minden hálózaton dedikálva
(minden host részen lévő bit 1-es értékkel). Az ilyen csomagokat minden gép, amely megkapta
feldolgozza. Az üzenetszórás egy finomabb formája a csoportküldés (multicast), ilyenkor nem
mindenkinek, hanem csak a csoportnak szól. Ekkor az egyes állomások amelyek megkapják (ha
előtte nincs intelligens eszköz, amely csak a célokhoz küldi ki), megnézik, hogy a célcím által
leírt csoport érdekli-e őket. A csoportküldésnek egy speciális címtartomány van kijelölve amely,
hasonlóan a privát címtartományokhoz, helyi jelentőségű. A DHCP protokollban a kliens tehát
csoportküldés, vagy üzenet szórás segítségével kér címet. A szerver nem örökre, hanem adott időre
adja bérbe a címet a kliensnek. Ezt is üzenetszórás csatornán hirdeti meg. A kliens kérésére több
szerver is válaszolhat. Ez egy jó példája annak, hogy hogyan lehet magas rendelkezésre állást
megvalósítani protokoll szinten (több szerver is lehet, ezeknek nem kell egymásról tudnia).
A kliens ezután kiválasztja a címet amelyet újra üzenetszórással, vagy csoportküldéssel tudat a
szerverekkel. A kiválasztott szerver által adott IP címet az a szerver nyugtázza.
Fontos A forgalomirányítók nem továbbítják az üzenetszórás és csoportküldés csomagokat.

Ez nem véletlenül van így, az ilyen tartományt, ahol mindenki hallja mindenki kiabálását,
üzenetszórási tartománynak (broadcast domain) nevezzük. Célszerű teljesítmény és biztonsági
okok miatt a hálózatot minél kisebb üzenetszórási tartományokra bontani.
Ez a bontás akkor jelenthet gondot, ha nincs minden üzenetszórási tartományban DHCP szerver
(ami valószínű), ez esetben több megoldási lehetőség is van. Az egyik, hogy a forgalomirányítót
bekonfiguráljuk a DHCP üzenetek továbbítására (DHCP relay). A másik gyakori eset, hogy
maga a forgalomirányító játssza el a DHCP szerepet. A DHCP protokoll nem csak IP címek
kiosztására szolgál, hanem itt lehet meghirdetni a helyi DNS szerver címét, a helyi nyomtatót, az
alhálózati maszkot és sok egyéb paramétert is. A DHCP az eszköz menedzsment első szintje.
5.3.6 IPv6
Az IPv6 protokoll tervezésekor nem szerettek volna forradalmat csinálni, csak az IPv4 hiányosságait
szerették volna kiküszöbölni az új protokollal. A 5.14 ábrán látható, hogy bár a WWW-vel egyidős,
korántsem futott be olyan sikeres életutat. Ma is csak 30% alatti az elterjedtsége (azaz azon
eszközök száma, amelyek IPv6 hálózathoz is hozzáférnek). Nincs az IPv4-hez összemérhető
világméretű IPv6-os gerinc. Több helyen hiába szeretne adott helyi hálózat vagy felhasználó
IPv6-ot használni, ha a szolgáltatója nem biztosít ilyen szolgáltatást. Az IPv6 legfontosabb újításai:
5.14: IPV6 penetráció, csomagformátum
• 128 bites címtér: ez ma kifogyhatatlannak tartott címtér. Gyakran két 64 bites részre osztják,
az első 64 bit a prefix - hálózati cím, míg a második 64 bites rész pedig az eszköz hardver
azonosítója.
• nincs csomag darabolás: van de alapértelmezésben nem támogatja az IP csomagok darabonkénti
továbbítását
• nincs fejléc ellenőrző összeg: ezen összeg számítása minden egyes csomag továbbítása
esetén igen komoly dedikált hardver megoldást igényelt az IPv4-nél. Itt a hop count
csökkentése után nem kell újraszámolni a CRC-t, mert nincs.
• fejléc szkóp: az opcionális fejléceket nem kell minden egyes ugrásnál feldolgozni, vannak
olyan fejlécek, amelyek csak a végállomáson feldolgozandók.
• nincs üzenetszórás: viszont van egy új kommunikációs paradigma a bárkinek küldés
(anycast), ekkor egy csoportnak küldi az állomás de elegendő ha a csoportagokból csak egy
állomás kapja meg. Ilyen lehet pl.: a DNS kérés elég ha egy DNS szerver megkapja. A
kliensnek meg elegendő tudnia egy világszinten elfogadott DNS szervereknek szánt anycast
címet.
Az IPv6 ma még szigetekként jelenik meg az IPv4 tengerben. Ezen szigetek között leginkább
alagutakkal teremtik meg a transzparens összeköttetést. Az alagút bejáratánál IPv4-es csomagba
teszik az IPv6-os csomagot, míg a kijáratnál a beérkező IPv4-es csomagból kiveszik az IPv6-os
csomagot és azt továbbítják.
5.15: IPv4 alagút IPv6 csatorna részére1
5.3.7 Általánosított továbbítás - Szoftverrel Definiált Hálózat - SDN

A fent vázolt elvek alkalmazása: állapotmentes forgalomirányító, gyors döntés a cél cím alapján,
sokáig elegendő volt az Internet gerincén de még mélyebben, a hozzáférési hálózatokban is. Ahogy
azonban megjelentek a plusz funkciókat megvalósító köztes dobozok, egyre bonyolultabbá vált
a hálózatok menedzsmentje. Külön elv mentén ment a forgalomirányítás és továbbítás, külön
elv mentén az olyan funkcionalitások mint az NAT, tűzfal, adott folyamok megkülönböztetése,
HTTP szintű terheléselosztás stb. Egy másik kritikus terület a felhő szolgáltatók világa, ahol a
nagyon nagyfokú virtualizációt a hálózati virtualizációnak is követnie kellett volna. Itt nagyon nem
váltak be a klasszikus számítógép hálózati protokollok. Ezen problémák megoldására két irányból
kezdtek el egy jóval dinamikusabb, programozhatóbb megoldást fejleszteni. Az adatközpontok
irányából érkezett az SDN szoftverrel definiált hálózat (software defined networking). A
távközlés világából érkezett az NFV hálózati funkcionalitás virtualizálás (network function
virtualization). Az SDN megközelítésmód a vezérlés és az adattovábbítás elkülönítéséről szól.
Az adattovábbítás továbbra is a hálózati eszközök dolga, de a vezérlés ki van szervezve jellemzően
egy felhő alapú platformra. A vezérlő algoritmusok, protokollok fejlesztése sokkal gyorsabb, erről a
következő fejezetben bővebben írunk. Magával a konkrét fizikai eszközzel, annak megvalósításával
nem foglalkozik. Az NVF más utat követett, a fő cél itt minden virtualizációja egy virtualizációs
réteg felett (hypervisor) megjelenik olyan mint virtuális forgalomirányító, virtuális kapcsoló, stb...
A továbbiakban az adathálózatokban jóval elterjedtebb és praktikusabb SDN-nel foglalkozunk.
Az SDN nem csak a vezérlést szervezi ki, hanem az egyes hálózati eszközökben új képességet is
specifikál. Ez az általánosított továbbítás (generalized forwarding). A forgalomirányító tábla
helyett folyamtáblánk van amely találat - akció (match - action) alapon írja le egy-egy folyam
kezelési módját. A találat szemben a klasszikus továbbítás IP célcím fókuszával, mely ezzel csak a
3. rétegbéli információra fókuszál, itt 3 réteg mezőit öleli át (L4,3,2). Ezzel egy helyen mindhárom
réteg információira hivatkozó szabályokat lehet megadni. A mezők a 5.16 ábrán láthatóak. Ilyen
5.4 Hálózati réteg: vezérlősík 113
5.16: Hálózati réteg adatsík vs. vezérlősík, általánosított továbbítás szűrő mezők1
szabály lehet például a 5.16 ábrán látható, mely az egyes bemeneti porton érkező csomagoknál
azokat, amelyek a 10.3.x.x cím tartományból érkeztek és a 10.2.x.x címtartományba mennek,
továbbítja a 4. porton. Az alapvető akciók az alábbiak lehetnek:
• továbbítás: adott portján továbbítja
• eldobás: tűzfal funkcionalitás
• mező módosítás: ilyen lehet a NAT megvalósítása
A témával részletesebben foglalkozunk a vezérlősík fejezetben.

Az előző fejezetben láttuk, hogy a helyi döntések vagy a forgalomirányító tábla vagy a folyam tábla
alapján történnek meg. Egy igen fontos kérdés az, hogy hogyan és ki tölti és ki frissíti ezeket a
táblákat? Gondoljunk bele, hogy ezen tábláknak valamilyen módon konzisztensnek kell lennie.
Legyen A és B forgalomirányító, problémát okoz ha az A forgalomirányító úgy gondolja hogy B
felé kell adott forgalmat terelnie míg a B szomszéd meg úgy gondolja, az A helyes irány. Ekkor
hurok alakul ki. Fontos, hogy a forgalomirányító táblák konzisztens és a valóságnak megfelelő
világképet képviseljenek. Ezzel a feladattal foglalkozik a vezérlés.
5.4.1 Bevezető
Ahogyan láttuk a vezérlés lehet elosztott és központosított. Elosztott vezérlés esetén a forgalomirányítók
egy-egy szoftvert futtatnak és ezek a szoftverek egymással együttműködve kialakítják a világképüket
és ez alapján mindegyik kitölti a helyi forgalomirányító táblát. Ez egy valós P2P rendszer
központi szerver nélkül, csak az egyenrangú szoftverek együttműködéséből tud építkezni. Ezen
szoftvere forgalomirányító protokollokat valósítanak meg, ezen protokollok mentén kommunikálnak
egymással. A másik irány az SDN/NFV ahol a vezérlés egy központban van kihelyezve, itt nem
kell P2P algoritmust megtervezni és megvalósítani, az elosztott rendszer komplexitása el van fedve
alattunk (SDN vezérlő platform pl.: OpenDaylight).
5.4.2 Forgalomirányító protokollok

A klasszikus hálózatokban és az internet gerincében ma ilyen protokollok biztosítják a forgalomirányító
táblák helyes tartalmát.
Fontos A hálózati réteg forgalomirányító és link szinten modellezi a hálózatot. E modell

absztrakt reprezentációja egy gráf amely csomópontjai a forgalomirányítók, míg élei linkek. Az
éleknek súlyai vannak, ezek mentén kell meghatározni a legrövidebb útvonalat (G=(N,E)).
A csomópontok nem hordoznak fontos információt az útvonalválasztás számára ezzel szemben az

élek súlya kritikus fontosságú. Hogyan mérjük a jó útvonalat? Mi a legrövidebb útvonal? Egy naiv
megközelítés lehet a távolság mérésére az ugrásszám (A és B pont között található forgalomirányítók
száma), ez azonban nem veszi figyelembe a linkek kapacitását. Vegyük akkor figyelembe a linkek
kapacitását. Mi a jobb egy leterhelt nagy sávszélességű link vagy egy üres kis sávszélességű vonal.
Gyorsan eljutottunk oda, hogy valamilyen fizikai mennyiség dinamikus változó értéke lehet a
legjobb metrika. Azt is láttuk azonban, hogy nagyon fontos a forgalomirányítókon átívelő tudás,
/ információ homogenitása - azaz minden forgalomirányító ugyanazt kell, hogy lássa a világról.
Minél változékonyabb metrikákat választunk ez annál nehezebben valósítható meg. Majd látni
fogjuk, hogy nincs egy mindenhol alkalmas metrika. A hálózat különböző szintjein különböző
metrikákat alkalmaznak.
5.17: Hálózat gráf modell1
A forgalomirányító protokollokat többféleképpen tudjuk csoportosítani. Első körben a dinamizmus

alapján a forgalomirányítás lehet:
• statikus - ekkor az útvonalak be vannak égetve és nem függnek az aktuális valóságtól. Ez
egy nagyon kedvezőtlen megközelítésnek tűnhet - nem alkalmazkodik a valósághoz. Ahol
azonban nincs alternatív útvonal ilyenek például a vég hálózatok, ahol csak egy Internet
kijárat van ott célszerű ilyen egyszerű forgalomirányítást használni. Használjak ezt nagy
léptékben is amikor adott típusú forgalmakat adott szabályok szerint szeretnének terelni.
• dinamikus - ez a legtermészetesebb, a világképe dinamikus és ez alapján alakítja a forgalomirányító
tábláját.
Az információ pontossága alapján lehet:
• globális: Ez esetben a résztvevő forgalomirányítónak globális és részletes ismerete van a
hálózat adott részleteiről. E megközelítésmód előnye a pontosság, mivel minden forgalomirányító
tud mindenkiről mindent (kinek milyen szomszédai vannak, ezek között milyen linkek
vannak), ezért itt minden egyes helyi döntés tökéletes szinkronban van. Ez a megoldás
bár jónak tűnik a skálázhatósága miatt, csak adott méretű hálózatig alkalmazható (egyrészt
a túl pontos ismeret folyamatos fluktuációt okoz a rengeteg részlet ismerete miatt - miért
kell nekem tudnom a legtávolabbi forgalomirányító összes interfészének adott állapotát?,
másrészt komoly terhelés okoz az állapotinformáció folyamatos elárasztása). Ebbe az

osztályba tartoznak a link-állapot (link-state) alapú forgalomirányító algoritmusok.
• pletyka alapú vagy lokális: Itt senkinek sincs pontos információja, mindenki csak feldolgoztt
információt ad át (pl.: “azt hallottam, hogy tőlem balra x távolságra van a Z hálózat”). Ilyen
információval nem lehet egy teljes hálózati gráfot felépíteni, de mivel fel van dolgozva,
ezért az atomi változások kevésbé propagálódnak. Ennek a megoldásnak viszont komoly
problémája a konvergencia, azaz hogy mennyi idő után lesz minden forgalomirányítónak
egységes a világképe. Egyes esetekben soha sem lesz az. Ebbe az osztályba tartoznak
a távolságvektor (distance vector) és a távolság - út vektor (distance - path vector)
algoritmusok.
A link állapot alapú protokollok alapja az, hogy minden forgalomirányító ismeri minden forgalomirányító
szomszédjait és az ezekhez tartozó távolságokat, metrikákat. Ennek az információnak a kialakítása
általában elárasztásos megoldással valósul meg: minden változásnál mindenkinek elküldi a
változásokat az adott forgalomirányító. Így kialakul minden forgalomirányítóban a G(N,E) gráf
adathalmaza. Ezen a gráf adathalmazon futtatja le minden egyes forgalomirányító a Dijkstra féle
feszítőfa kereső algoritmust. Így alakítja ki mindenki saját számításokkal a forgalomirányító táblát.
A Dijkstra algoritmus rövid összefoglalása látható a 5.18 árbrán. A jelölések a következőek: D(v) a
legkisebb költségű útvonal a futtató csomóponttól a v csomópontig az adott iterációban, p(v) az adott
csomópont és v csomópont közötti úton a v-t megelőző csomópont, N’ azon csomópontok halmaza
amelyekhez ismert a legrövidebb útvonal. Dinamikus metrika (pl.: terheltség, aktuális sávszélesség)
5.18: Dijsktra algoritmusa1
esetén a hálózat instabil lesz, mert adott linkek súly változása folyamatos újraszámolást eredményez.
5.19: Változó metrika okozta fluktuáció1
Távolságvektor alapú protokollok esetén nincs meg a precíz információ a világról. Ennek az
algoritmus családnak jól ismert képviselői a Bellman Ford egyenlőségre építő megoldások. Ez azt
mondja ki, hogy az x és y csomópontok között úgy tudjuk meghatározni a legrövidebb útvonalat,
ha minden lehetséges v köztes csomópontra megkeressük a v és y közötti legrövidebb útvonalat.
dx (y) = minv {c(x, v) + dv (y)} (5.1)
Ezen egyenletre alapuló elosztott algoritmus pszeudokódja és egy lefutása látható a 5.20 ábrán. A
5.20: Távolságvektor alapú forgalomirányítás algoritmusa1
távolságvektor alapú protokollok számára ugyanolyan gond a dinamikus metrikák alkalmazása,

azonban itt az információ vesztéssel (pletyka) megjelennek olyan problémák, amellyel a link állapot
alapú protokollnál nem találkoztunk. Egy ilyen probléma a jó hír gyors (megfelelő) terjedése és
a rossz hír lassú (nem jó) terjedése. Amikor egy útvonalon egy link költsége csökken, akkor
ez a hír gyorsan eljut mindenhova, mivel nem tud senki sem ettől jobbat mondani, azaz a hír
gyorsan terjed. A rossz hírnél viszont, mivel a hír forrása nem ismert, ezért a náluk lévő jobb
információt hirdetik meg, míg az ő forrásuk el nem évül, de ekkor a meghirdetett információt már a
szomszéd is hirdeti (persze teljesen alaptalanul). A 5.21 ábrán B részén az eddig jó útvonalon a
4-es költség felmegy 60-ra. Ezt az y érzékeli, de meghallja z hirdetéseit aki csak annyit állít, hogy
tud egy 5 távolságú utat x-hez (ezt ugye y-tól “hallotta”, de ezt nem tartja nyilván). Ezután y is
elkezdi hirdetni ezt az útvonalat 6 távolságra. Z ezt meghallva ismét növeli a távolságot és elkezdi
hirdetni 7 távolságban, ez addig pattog oda-vissza, míg 50 fölé nem megy, mert akkor az 50-es
link már jó lesz. Láthatjuk, tehát, hogy egy igen egyszerű hálózatban is komoly gondot okozhat az
információvesztés (pletyka). Erre több megoldást is szoktak alkalmazni, de ezek mindegyike csak
5.21: Hír terjedése pletyka alapú hálózaton1
tüneti kezelés, nem oldja meg garantáltan a problémát. Ilyen heurisztikák:

• adott szám a végtelen - RIP (Routing Information Protocol) esetén például 15 távolságnál
nagyobb távolság esetén azt mondják, hogy nincs útvonal. Ezzel a végtelen ideig tartó
iterációt korlátozza, de ezzel egy korlátot ad a hálózat méretére is.
• osztott horizont (split horizon) - Itt megjegyzi, hogy honnan hallotta és oda nem mondja
vissza ugyanazt az információt. Ez a megoldás egy egyszerű háromszög és egy csomóponthoz
kapcsolódó további csomópont esetén sem működik, ott is visszaér az információ, csak más
úton.
• mérgezett hirdetések (poisoned updates) - Ekkor egy visszafelé végtelen távolságot hirdetnek
meg az útvonalon (amikor z, y után következik az útvonalon akkor y felé nem, hogy nem
hirdeti meg ugyanazt, hanem végtelen távolsággal hirdeti azt meg). Itt ismét egy kicsit
bonyolultabb topológián visszatérhet a régi információ.
Ebben a fejezetben két elméleti protokollt ismertünk meg, a következő fejezetben ezen elméleti
protokollok konkrét megvalósításával fogunk találkozni. Az elméleti és gyakorlati protokollok
összevetéséhez számos elvet, metrikát szoktak alkalmazni, ezek közül a legfontosabbak:
• üzenet komplexitás - Az információ terjesztéshez mennyi üzenetre van szükség. A link
állapot alapú algoritmusoknál ez O(N), azaz a forgalomirányítók számával arányos a küldendő
üzenetek száma. Ha figyelembe vesszük azt, hogy ezt minden link megváltozásakor meg kell
tenni, akkor inkább O(NE) lesz. Ezzel szemben a távolságvektor alapú forgalomirányításnál
nem jelentkezik ez az E tényező (mivel ha adott link változása nem hat a teljes költségre
akkor nem is megy frissítés).
• konvergencia sebessége - Ez a link állapot alapú algoritmusoknál belátható korlátok közé
szorítható, míg a távolságvektor alapú megoldásoknál nincs garantált felső korlátja
• robosztusság - Hogyan reagál a rendszer, ha adott csomópont rossz információkat hirdet
meg? A link állapot alapú megoldásoknál ez pontszerű hiba, nem feltétlenül érinti a rendszer
egészét. A távolságvektor alapúnál teljesen át tudja alakítani a világképet egy-egy rossz
hirdetés.
Ezekből a metrikákból is látható, hogy nem létezik optimális megoldás.
Visszaidézve az Internet alapelveit azt láttuk, hogy megkülönböztetjük az adott belső hálózaton
belüli forgalomirányító protokollokat azoktól, amelyek ezen rendszere között végzik a forgalomirányítást.
Fontos Ma a világháló forgalomirányítás kétszintű, a határokat az autonóm rendszerek

képviselik. Autonóm adminisztratív övezetnek tekintjük azokat, ahol egy kézben van az
irányítás (cég, ország, szervezet).
Ezekhez viszonyított protokollok az alábbiak:

• autonóm rendszeren belüli (IGP intra gateway protocol): Olyan protokollok, amelyek
egy-egy autonóm rendszeren belül futnak. Ezen protokollok fókuszában a fizikai képességek
maximális kihasználása van. Az eddig látott absztrakciós szinten mozognak (forgalomirányító,
mint csomópont link, mint gráf él)
• autonóm rendszerek közötti (EGP - exterior gateway protocol): Itt születik meg a
hálózatok hálózata. Ezek (ebből ma egy van) a protokollok az egyes autonóm rendszerek
fölött valósítják meg a forgalomirányítást. Itt más az absztrakciós szint. Az autonóm
rendszerek mint csomópontok jelennek meg (akár belül több ezer forgalomirányítóval) és az
ezek közötti összeköttetések a gráf élei.
A továbbiakban ezen protokollokat tekintjük át.
5.4.3 Autonóm rendszeren belüli protokollok

Ezek között a legismertebb az OSPF (Legrövidebb Útvonal Először - Open Shortest Path First).
A protokoll a link állapot alapú protokoll gyakorlati megvalósítása. Az alábbi konkrét heurisztikákat,
képességeket valósítja meg az elméleti protokollon túl:
• hierarchikus felépítés egy AS-en belül: Ez a leglényegesebb plusz heurisztika. Láttuk,
hogy a link állapot alapú forgalomirányításnál az információ elárasztás segítségével jut el
mindenkihez. Ez a megoldás nem skálázható. Adott méret fölött túl sok változást kapnak a
forgalomirányítók, ami miatt folyamatosan újra kell futtatniuk a Dijkstra algoritmust. Erre egy
megoldás az, ha az OSPF rendszert belső körzetekre osztjuk. Ezen körzetek határán speciális
szerepkörű forgalomirányítók vannak. Ezek az ABR (Körzet Határ Forgalomirányító
Area Border Router)-ek. Az ő feladatuk, hogy a körzetek között szűrt információt adjanak
át. A 5.22 ábrán például az Area1-ben lévő ABR nem küldi be az Area0-ba az összes
frissítést, csak egy összegzést küld be, hogy ez a hálózat merre van. Az, hogy ezen belül
egyes forgalomirányító interfésze milyen állapotban van, nem megy át. Vegyük észre, hogy
ezzel az adott határokon távolságvektor alapú viselkedésre álltunk át, azaz nem adunk pontos
információt, csak összegzettet. Azért, hogy ebből ne legyen hurok, csak a lenti kétszintű
topológia engedélyezett. Egy 0-s gerinc körzet és ehhez csatlakozó csonk körzetek. Egy
másik speciális szerepkörű eszköz van még a hierarchiában: az ASBR (autonóm rendszer
Határ Eszköz - Autonomous System Border Router), az ő szerepe hasonló, mint az
ABR-é csak ő autonóm rendszerek között közvetít aggregált információt.
• azonosítás, tartalomvédelem az OSPF csomagoknak: Láthattuk, hogy a forgalomirányító
információ kritikus fontosságú. Nem jó, ha bárki OSPF csomagokat küldhet egy forgalomirányítónak
tetszőleges tartalommal. Itt lehetőség van minden egyes csomaghoz egy jelszó + időbélyeg
kivonatot adni, így csak azonosított csomagot fogad el majd az OSPF processzus.
• több azonos költségű útvonal kezelése: Ha több azonos költségű útvonal van, akkor
közöttük terheléselosztást képes megvalósítani. (Mi van akkor, ha több van, de nem egyforma
költségű? Az OSPF nem tud ezzel mit kezdeni. Itt jön be a képbe az MPSL vagy ma az
SDN)
5.22: OSPF helló csomag, OSPF többszintű hálózat
Az OSPF protokoll segítségével 400-600 forgalomirányítót tartalmazó hálózatok építhetőek ki.

Ma ez a leggyakrabban alkalmazott IGP. Jóval részletesebb leírás megtalálható például ebben a
könyvben [7].
5.4.4 Autonóm rendszerek közötti protokollok

Az IGP protokollok, mint láthattuk a fizikai képességek mentén keresnek legrövidebb útvonalat.
Az autonóm rendszerek között más elvet kell követni. Itt adott esetben az adatküldés és fogadás
pénzbe kerül, így adott autonóm rendszernek nagyon nem mindegy, hogy kinek a forgalmát és hova
engedi át, illetve saját forgalmát hova engedi és hova nem. Az EGP forgalomirányítást szabály
alapú forgalomirányításnak (policy based routing) is nevezzük. A szomszéd által meghirdetett
útvonalakat a bemeneti szabályrendszer mentén szűri, mivel itt cégek, szervezetek működnek együtt
egymással, ezért bizalmatlanok, nem fogadnak el mindent a másiktól. Ha például egy kis cég
EGP kapcsolatot létesít egy nagy szolgáltatóval (ez lehetséges), akkor itt meghirdetheti a nagy
szolgáltatónak, hogy a Google felé egy nagyon rövid utat ismer. A nagy szolgáltató, ha nincs a
beérkező hirdetésekre szabályrendszere, akkor a Google felé menő forgalmát a kis cég felé tereli,
aki lehet hogy csak egy gyenge műholdas kapcsolat miatt tudott rövidebb útvonalat mondani. De
hasonlóan fontos a kimenő hirdetések szűrése is.
Fontos Amit meghirdetek, arra vállalom a kézbesítést.
Így a kis cég, bár ismer egy rövid útvonalat a Google felé, nem biztos hogy érdekelt abban hogy
minden szomszédja rajta keresztül küldje a Google felé a forgalmát. Azt láttuk, hogy itt az autonóm
5.23: Tranzit hálózat vs. vég hálózat
rendszerek jelennek meg, mint csomópontok, a közöttük lévő összeköttetések pedig a gráf élei.
Ma egyetlen EGP protokollt használnak, ez a BGP (Border Gateway Protocol). Az autonóm
rendszerek itt a csomóponthoz tartozó prefixeket (hálózatokat) hirdetnek meg egymásnak. A
távolság az ugrásszám, azaz hogy két pont között mennyi autonóm rendszeren kell keresztülmenni.
A forgalomirányítás egy finomított pletyka alapú protokoll. A csomópont nem csak a távolságot
küldi tovább egy adott hálózattól, hanem az úton lévő autonóm rendszerek azonosítóit (AS number
32 bites szám, ezt az IANA kezeli) is, ez az útvonal vektor forgalomirányító algoritmus.
A BGP forgalomirányítók TCP csatornán stabil kapcsolatot építenek ki a szomszédos BPG
forgalomirányítókkal. Ezen a csatornán küldik egymásnak az útvonal hirdetéseket különböző
attribútumokkal kiegészítve. Ilyen az AS-PATH ahol az útvonalhoz tartozó AS listát küldi el, de
ilyen a NEXT-HOP is, amely a következő ugrás IP címét tárolja. Számos egyéb argumentum/címke
csatolható egy-egy prefixhez, általában a kimeneti és bemeneti szabályok ezen attribútumokra
tartalmaznak reguláris kifejezéseket (pl.: ha COMMUNITY értéke privát, akkor nem adja tovább
ezt a prefixet a szomszédnak). A BGP protokollnak két verziója szokott futni:
• eBGP: Az eBGP az autonóm rendszerek közötti összeköttetésért felel. Adott útvonal
befogadásának a hurkokat úgy kerüli el, hogy megnézi, hogy szerepel-e az AS-PATH
vektorban, ha igen, az azt jelenti, hogy hurok keletkezne, akkor nem fogadja el a hirdetést.
• iBGP: Az autonóm rendszeren belül köti össze a BGP forgalomirányítókat. Mivel az
AS-PATH-ban szerepel (ugyanazon a rendszeren belül adja tovább, de előbb beleteszi magát),
ezért a hurkok elkerülését csak úgy lehet elérni, ha külső információt a BPG csak attól
fogadja el, aki ezt közvetlenül kívülről kapta. Ez azzal is jár, hogy nem játszhatják át
egymásnak közvetett módon az információkat, azaz minden forgalomirányítónak minden
forgalomirányítóval kapcsolatot kell fenntartania. Ez ugyan nem jelent fizikai kapcsolatot,
csak egy TCP csatornát, de nem teszi egyszerűvé nagy hálózatok menedzselését.
Láttuk tehát a BGP működését és egy IGP, az OSPF működését. Amit azonban nem tárgyaltunk,
hogy ezek egymással hogyan működnek együtt. A 5.24 ábrán látható hálózat esetében tegyük
fel, hogy az AS1-ben az 1C BGP-t és OSPF-et futtat, míg a többi OSPF-et. Az AS2-ban a 2a és
2c BGP-t és OSPF-et, míg a 2b és 2d csak OSPF-et. Hogyan jut el a 10 forgalomirányító egyik
interfészén lévő PC-ről az IP csomag az AS3-ban lévő X hálózathoz? Az AS1-ben az 1c-nek van
erről információja, mivel megtudta AS2-től, aki megtudta ezt AS3-tól. Az 1a viszont OSPF-et
futtat. Megoldható a BGP információ beinjektálása az OSPF rendszerbe, de nem célszerű, mert az
500.000 bejegyzés kezelése az OSPF forgalomirányítókat túlterhelné, ha egyáltalán kezelni tudnánk.
Így az 1a nem ismeri a célcímet és annak elérhetőségét. Ha egy forgalomirányító nem ismeri egy
5.24: iBGP vs eBGP1
csomag cél címének elérhetőségét, akkor azt figyelmen kívül hagyja (törli). Ezen segíthetnek a
statikus útvonalak. Az AS1-nél például csak egy kijárata van a világra: az 1c. Ezért belül lehet
olyan statikus útvonalakat használni, hogy amit nem ismer, azt küldje az 1c felé. Az ilyen útvonalat
szokták alapértelmezett útvonalnak (default route) is nevezni. Ez egyszerű, amikor egy kijárat
van. Amikor azonban több van, akkor a forró krumpli (hot potato) megoldást szokták alkalmazni:
az alapértelmezett útvonal mindig a legközelebbi kijárathoz mutat. Ez a megoldás nem igen segít
a tranzit hálózatok esetében (olyan hálózat, ami nem saját, hanem átmenő forgalmat szolgál ki).
Ilyen az AS2 az ábrán. A 2a tudja, hogy a 2c felé kellene továbbítani, de ezt nem tudja elmondani
a 2b és 2d forgalomirányítóknak. Erre a problémára az MPLS fog megoldást biztosítani, ahol a
bejáratnál megcímkézik a csomagokat és a hálózaton belül ezen címkék alapján továbbítják őket.
Jelen fejezetben a BGP-t csak érintettük jóval részletesebb képet kaphatunk róla és a gyakorlati
problémákról ebben a könyvben [5]. Egy igen jó az IP forgalomiránytó protokollokat összefoglaló
könyv a következő [2].
5.4.5 Az SDN vezérlő síkja

Láthattuk a fejezet eddigi részében, hogy a forgalomirányító algoritmusok elosztottak, P2P elven
működnek és arra szorítkoznak, hogy a változó környezetben is megtalálják a legrövidebb útvonalat.
Ez a képesség azonban ma több esetben is kevés. Hogyan tudom megoldani azt, ha adott forrásból
származó forgalmat más úton szeretnék átvinni? Az ilyen és ehhez hasonló kérdésekkel foglalkozik
a TE (Forgalom Tervezés - Traffic Engineering). Itt adott forgalom típusokat adott időszakban
(néhány órától a folyamatosanig) külön szeretnének kezelni, ezek a forgalom típusok jellemzően
nagyobb aggregátumok (pl.: AS szintű). Az adatközpontokban ettől sokkal gyakoribb és atomi
szintűbb igények jelentkeznek. A felhasználók számára virtuális hálózatot is létre kell hozni a
virtuális gépek összekötésére, ezen hálózatoknak viszont a felhasználók igényei mentén bármikor
változtathatóaknak kell lenniük. Látható tehát, hogy egy teljesen más megközelítésmódra van
szükség a vezérlésben az ilyen igények kielégítésére. Az adatsíkban már láthattuk az eszközök
képességeit. Most a vezérlés tipikus rétegezését tekintjük át.
Az SDN vezérlő feladata, hogy elfedje a fejlesztő elől a hálózat bonyolultságát és egy egyszerű
interfészt adjon a különböző szolgáltatások megvalósítására. Az eszközök az ú.n. déli (southbound
interface SBI) interfésze hagyományosan az az interfész, amely absztrakciós szinten alacsonyabb
szintre lép. Esetünkben ez az eszközök felé néző interfész. A vezérlő északi interfésze(northbound
interface NBI) a komplexebb, magasabb szintű szolgáltatások felé néző interfész (a vezérlő
szempontjából). A vezérlő alatt tehát az egyes HW megoldások találhatóak. A vezérlő fölött
pedig az egyes szolgáltatásokat megvalósító programok, alkalmazások. A vezérlő célja, hogy
a földrajzilag, technológiailag és elérhetőségben is heterogén valóságot elfedve magas szintű
absztrakciót adjon. A vezérlőt 3 rétegre szokták bontani. A legfelső rétege a szoftverfejlesztők
felé nyújtott specifikus technológiai interfész, ez általában REST API formájában publikált és
5.25: SDN vezérlő sík1
a hálózatot különböző absztrakciós formában ábrázolja, ilyen például a gráf. A középső réteg
a legbonyolultabb. Itt valósul meg a különböző forrásból származó információk egyesítése és
adott absztrakciós szintű adattárak kialakítása. Ez az a réteg, amely technológiai értelemben
megvalósítja az elosztottságot (gyakran P2P algoritmussal). A klasszikus forgalomirányító
algoritmusokban megtalálható P2P konzisztencia felé mutató algoritmusoknak a megfelelő
eljárások itt vannak megvalósítva, de ezzel az átlagos fejlesztőnek nem kell foglalkozni. A
legalsó rétege különböző zárt vagy nyílt protokollok, technológiák mentén illeszti az eszközöket.
Az adatáramlás vezérlő és réteg szinten is kétirányú. Azaz a legalsó rétegben például nem csak
olvasnak, hanem írnak is az eszközökbe.
Az SDN koncepcióval együtt kialakított protokoll az OpenFlow. A protokoll egy TCP csatorna
segítségével olvassa és írja az OpenFlow képes eszközök adatait. Fontosabb üzenetei:
• konfiguráció (configuration) - a vezérlő le tudja kérdezni az eszköz konfigurációs paramétereit
• állapot módosítás (modify state) - a vezérlő az eszköz folyam tábláját tudja szerkeszteni
(sorok hozzáadása, eltávolítása)
• állapot olvasás (read state) - a vezérlő statisztika és számláló értékeket olvashat le az eszköz
adott eleméről (pl.: adott porton fogadott Ethernet kertek száma)
• csomag küldés (send packet) - a vezérlő tetszőleges szerkezetű csomagot tud küldeni az
eszköz adott portján; ez nagyon fontos képesség, amely segítségével egyszerűen és gyorsan
lehet új protokollokat bevezetni.
• folyam eltávolítva (flow removed) - az eszköz értesíti a vezérlőt, hogy adott folyamot
eltávolított (pl.: adott ideig nem volt forgalom)
• port státusz (port status) - szintén az eszköz szól a vezérlőnek, amelyben jelenti a dott
prot állapot változását (pl.: fizikailag bekapcsolt, vagy lekapcsolt, mert megszakadt az
összeköttetés)
• csomag be (packet in) - adott mintára illeszkedő csomagokat átküldi a vezérlőnek, ez a
protokoll megvalósítási lehetőség másik fele (csomag küldés mellett)
SDN háttérrel egy link állapot alapú forgalomirányító algoritmus megoldása is jóval egyszerűbb.
Az 5.26 ábrán látható módon az algoritmusnak adott a hálózat gráf reprezentációja. Amikor
a hálózatban változás következik be (1-es lépés), akkor ez eljut a REST API segítségével az
alkalmazáshoz, de úgy mint a meglévő gráf adott élének változása. Ezen lefuttatja a Dijsktra
algoritmust és ennek eredményeképpen adott folyam táblákat frissíti. Itt a folyam táblák közvetlen
vagy modell alapú manipulációja a vezérlő képességétől függ. Láthatjuk tehát, hogy nem
egy P2P algoritmust, nem egy párhuzamos futtatásra képes algoritmust, hanem csak egy
5.26: Dijsktra algoritmus megvalósítása SDN segítségével1
egyszerű feszítőfa kereső algoritmust kellett megvalósítani adott eseménykezelő metódusokkal.

Minden mást az SDN vezérlő csinált. A problémát gyakorlatilag szoftverfejlesztő tudással meg
tudjuk oldani. Ezzel a megoldással hasonló forradalom várható, mint amit a telefon nyílt (olyan
értelemben nyílt, hogy bárki fejleszthet telefonos alkalmazást), egyszerű fejlesztői környezetével
elért a Google és az Apple. Az SDN és az NVF ma a legdinamikusabban fejlődő terület a számítógép
hálózatokban, egy jó alapszintű átteknitést ad ez a könyv [3] ez pedig az SDN-ről ad egy mélyebb
hálózat centrikus képet [4]
5.4.6 Az ICMP protokoll

Láthattuk, hogy a különböző protokollokat megvalósító entitások a protokollok mezőin keresztül
kommunikálnak egymással. Az IP csomag küldője például a fejlécben elhelyezett IP célcímmel
tudatja a többiekkel, hogy kinek szánja a csomagot. Annak érdekében, hogy maga az IP protokoll
egyszerű maradjon, nem terveztek bele telemetriát, monitoring/menedzsment képességet. Ezeket
külön az IP-re épülő protokollokban valósították meg. Ilyen protokoll az ICMP és az SNMP. Az
ICMP (Internet Control Message Protocol) protokoll az egyes csomópontok közötti hibajelzésre,
mérések megvalósítására és egyéb visszajelzések küldésére lett kidolgozva. Ha például egy
forgalomirányítóba beérkezik egy olyan csomag, amelyet nem tud továbbítani, mert nem tudja
hogy hova kell, akkor egy ICMP üzenetben hibát jelez a küldő felé. Bár a protokoll nagyon sok
lehetőséget biztosít a hiba jelzésre, behatárolásra, ezek töredékét engedélyezik a mai infrastruktúrákon.
Ennek egyszerű oka a biztonság. Az egyes hálózatok minél kevesebb információt szeretnének
elárulni magukról. Az ICMP-hez hasonló protokoll van az IPv6-ban és ott ennek használata kiterjedt,
mivel az üzenetek titkosíthatóak és tartalom védelemmel is elláthatóak. Az ICMP protokoll az
IP protokollra épít, az IP csomag adat részében van az ICMP fejléce, mely tartalmazza az ICMP
típus és kód mezőt. Az ICMP mező típusok közül a legismertebb és ma leginkább engedélyezett a
8-as típusú, 0-s kódú echo request és az erre válaszul küldött 0-s típusú és 0-s kódú echo reply.
Egy másik ICMP típus a 11-es típusú és 0-s kódú TTL expired. Ezt a forgalomirányító küldi ki
a forrásnak, amikor a TTL mező eléri a nullát. Ezt az üzenetet szokták felhasználni az útvonal
felderítésére. A forrás a célnak csomagokat küld 1-el kezdődő és csomagonként (3 csomagonként)
növekvő TTL-lel, így az útvonal mentén egyre távolabb lévő forgalomirányítók fognak visszajelezni,
hogy lejárt a TTL. Ez persze nem kötelező, ugyanis vannak olyan forgalomirányítók, amelyek nem
jeleznek vissza, de ez a módszer általában alkalmazható úgy az útvonal felderítésére, mint az adott
5.27: ICMP datagram és Típus/Kód kombináció
késleltetések lemérésére.
5.28: Traceroute kimenet
5.4.7 Hálózatmenedzsment - SNMP

Az ICMP az adott eszközök közötti információáralmást, problémakezelést támogatta és nem
alkalmas arra, hogy rendszerszinten kezeljünk egy hálózatot. Erre a célra lett kidolgozva az
SNMP (Simple Network Management Protocol) protokoll. Segítségével teljes értékű monitorozó
és menedzsment képességet tudunk megvalósítani nagyszámú eszköz fölött. Az SNMP maga egy
egyszerű a HTTP-vel összevethető protokoll. Támogatja a pull (lekérés) jellegű adat lekérést és a
push (kérés nélküli üzenet) jellegű értesítés megvalósítását is. A táblázatban láthatjuk a protokoll
5.29: SNMP üzenet típusok
parancsait. Mint láthatjuk, nem csak információ lekérés (pl.: GetRequest) van, hanem beavatkozás
is (SetRequest), amellyel az adott eszköz adott paramétereit lehet módosítani (pl.: letiltani egy
portot, átírni az OSPF link értéket, ...). Ezen túl a push jellegű viselkedés megvalósítását láthatjuk a
SNMPv2-Trap üzenetben. Itt az adott eszközön lehet érték figyeléseket beállítani amelynek elérése
esetén az eszköz üzenet küld (pl.: ha adott portja kikapcsol, akkor ezt jelezze a központnak). Az
SNMP protokoll kliens-szerver paradigmát valósít meg. Egy vagy több SNMP szerver és az
aktív eszközök (menedzselhető eszközök) alkotják az SNMP menedzsment tartományt. Az
SNMP funkcionalitást a menedzselt eszközökön dedikált programok, SNMP ügynökök (SNMP
agent) valósítják meg. Maga az SNMP üzenetváltás UDP protokoll felett történik. Amit eddig
leírtunk, már működőképesnek tűnhetne, de nem beszéltünk arról, hogy egy GetRequest konkrétan
mit kér el, annak milyen ábrázolása van. Mivel az SNMP nem csak a hálózati eszközök, hanem a
hálózatra kötött eszközök menedzsmentjére, monitorozására szolgál, ezért méginkább szükség van
a közös adatmodellre. Ugyanúgy kellene lekérni egy PC-nek, telefonnak és a Cisco/HP/Huawei stb.
hálózati eszköznek is a CPU terhelését. Ezt a közös adatmodellt hozza létre a MIB (Menedzsment
Információ Bázis - Management Information Base). A MIB egy módszertan ad arra, hogy
hogyan lehet adat szintaktikát és szemantikát leírni. Ezen túl az adatmodellnek egyedi azonosítót
is (ez ma lehetne URL és JSON séma). Vannak szabványos minden gyártó által támogatott
adatmodellek (pl.: MIBII) és gyártó specifikus MIB-ek. Ezek a MIB-ek egy névtár hierarchiába
vannak rendezve, ahol a gyártók saját névteret tudnak venni maguknak. A lekérdezés is ezen
névterekből összeállított azonosítók alapján történik. Egy-egy eszköztől lekérhető a támogaott
MIB-ek listája. Az 5.30 ábra jobb oldalán látható a névtér felépítése. Ha például a MIB-2
5.30: SNMP rendszer1 , MIB fa
IPv4-es információ részét szeretnénk lekérdezni, az a GetReuqets 1.3.6.1.2.1.4. címtér alatti adatok
azonosítóival tudjuk megtenni. Az azonosítókat OID-nek (Object Idenfier) nevezik. A 5.31 ábrán
5.31: MIB bejegyzés definíció
egy számláló van specifikálva, amely a hibás fejlécű IPv4-es csomagok számát adja meg. Ha ezt
szeretnénk lekérni, akkor GetRequest 1.3.6.1.2.1.4.4 paranccsal tudjuk ezt megtenni.
Jelen fejezet bővebb áttekintése a referencia könyv [6] 4. és 5. fejezetében (333-464) található meg.

• Ismertesd a hálózati réteg két fontos síkját, ezek rövid leírását!
• Vesd össze a P2P és az SDN vezérlősíkot!
• Ismertesd a forgalomirányítók lehetséges felépítéseit!
• Ismertesd a cél alapú továbbítás, és leghosszabb előtag egyezés alapelveit!
• Ismertesd a várakozási sorok helyét és szerepét a kapcsolóban!
• Ismertesd a várakozási sorokban alkalmazható ütemezési algoritmusokat!
• Ismertesd az Internet hálózati réteg fontosabb elemeit!
• Ismertesd az IP datagram fontosabb mezőit!
• Ismertesd az IP darabolás és összeállítás motivációját!
• Ismertesd az IPv4 címzés motivációját, felépítését!
• Ismertesd a DHCP motivációját, vázlatos működését!
• Ismertesd a hierarchikus címzés motivációját a CIDR elvét!
• Milyen motivácó húzódik meg a NAT mögött? Hogyan működik a NAT?
• Milyen fontosabb újításokat hozott az IPv6?
• Mi a lényege az általánosított továbbításnak és az SDN-nek?
• Melyek az OpenFlow adatsík absztrakció fontosabb képességei?
• Ismertesd a forgalomirányító protokollok fontosságát, szerepét és az általuk alkalmazott
absztrakciót! (gráf, metrikák...)
• Ismertesd a link állapot alapú forgalomirányító protokollok elveit. Mutasd be a működését
egy példán keresztül!
• Ismertesd a távolságvektor alapú forgalomirányító protokollok elveit, mutasd be egy példán
keresztül a működését!
• Ismertesd a forgalomirányító családok AS hez köthető csoportosítását! Mit ad az OSPF a
klasszikus link állapot alapú elvi algoritmushoz képest?
• Ismertesd az ISP közötti forgalomirányítás kihívásait! Röviden ismertesd a BGP protokollt!
• Ismertesd az ICMP motivációját és magát Internet Control Message Protocol-t!
• Ismertesd a hálózat menedzsment alapjait és az SNMP protokollt!

[1] Attahiru Sule Alfa. Queueing Theory for Telecommunications: Discrete Time Modelling
of a Single Node System. 1st. Springer Publishing Company, Incorporated, 2010. ISBN:
1441973133 (cited on page 104).
[2] Paul Cernick, Mark Degner, and Keith Kruepke. Cisco IP Routing Handbook. 1st. USA:
John Wiley and Sons, Inc., 2000. ISBN: 0764546953 (cited on page 120).
[3] Jim Doherty. SDN and NFV Simplified: A Visual Guide to Understanding Software Defined
Networks and Network Function Virtualization. 1st. Addison-Wesley Professional, 2016.
ISBN : 0134306406 (cited on page 122).
[4] Paul Goransson and Chuck Black. Software Defined Networks: A Comprehensive Approach.
1st. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2014. ISBN: 012416675X
(cited on page 122).
[5] Vinit Jain and Brad Edgeworth. Troubleshooting BGP: A Practical Guide to Understanding
and Troubleshooting BGP. 1st. Cisco Press, 2016. ISBN: 1587144646 (cited on page 120).
(7th Edition. Pearson, 2016 (cited on pages 101, 124).
[7] William R. Parkhurst. Cisco OSPF Command and Configuration Handbook. Pearson
Education, 2002. ISBN: 1587050714 (cited on page 118).

Tisztában van Különbséget tesz Figyelembe veszi az Hálózati eszközök
a hálózati réteg a különböző IP-címek használata konfigurációjában
feladatával és típusú IP-címek során bekövetkező képes az
az Internet között. Feltárja változásokat. Nyitott önellenőrzésre
Protokoll (IP) saját hálózatának az IP-címekről és a hibák önálló
felépítésével. Érti eszközeit, és annak tanultak gyakorlati javítására.
a forgalomirányítók logikai címzését. alkalmazására.
architektúráját.
Ismeri az IP-címzési
módszereket.
Ismeri a Különbséget Szem előtt tartja Önállóan

forgalomirányító tesz a tanult az autonóm kategorizálja a
protokollok főbb forgalomirányító rendszereken belüli forgalomirányító
kategóriáit (link protokollok között és az autonóm protokollokat.
állapot alapúak, (melyiket hol, rendszerek közötti
távolságvektor hogyan használjuk). forgalomirányítási
alapúak). megoldásokat.
Ismeri az Interneten Képes elemezni a Kész a megismert Önállóan ellenőrzi
alkalmazott csomagok hálózati ICMP protokollt a hálózati eszközök
forgalomirányítás és útvonalát. a gyakorlatban is elérhetőségét.
hálózati címfordítás alkalmazni. Hajlandó
elveit. Tisztában alkalmazások
van az ICMP segítségével a saját
használatával és hálózatán méréseket
működési elvével. végezni.
6. Adatkapcsolati réteg

• Mert WiFi-t mindenki használ. Jó ha értjük, hogy mi és miért biztonságos, illetve nem
biztonságos.
• Ezzel a réteggel kerek az IP hálózat, ez a mai felhő szolgáltatók virtuális hálózati
kínálatában is megjelenik (pl.: VLAN)

A fizikai hardver felett elhelyezkedő utolsó réteg az adatkapcsolati, amely a hálózati kommunikációra
előkészített keretek célbajuttatásáért felel a fizikai eszközök között, továbbá felel a különböző
átviteli közegek együttműködéséért és a kommunikációs vonalakon előforduló esetleges konfliktusok,
problémák feloldásáért is. Jelen fejezet terjedelmi korlátok miatt csak a legfontosabb ismereteket
mutatja be, a referencia könyv [2] 6. és 7 fejezetének (467-621) olvasása ez esetben is javasolt.
6.1 Bevezetés
Az adatkapcsolati rétegben két fontos résztvevőt különböztetünk meg: adottak a csomópontok,
amelyek az összes hálózatra kapcsolat állomást, forgalomirányítót, kapcsolót és WiFi Access
Pointot jelölik, őket kötik össze az átviteli közegek, azaz vonalak, amelyek egyaránt jelölhetnek
vezetékes vagy vezetékmentes megoldást, illetve helyi hálózatot (LAN) is. Annak érdekében, hogy
az adat eljusson a hálózat egyik végpontjából a másikba, át kell haladnia minden köztes vonalon,
amelyek a forrás és a cél közötti útvonalat kötik össze
Fontos Az adatkapcsolati réteg feladata a felsőbb rétegek által küldött datagram keretbe
foglalása, majd a keret továbbítása az adott csomóponttól a fizikailag szomszédos csomóponthoz
az őket összekötő vonalon keresztül.
Ez közel sem egyszerű feladat, hiszen egy csomag átvitele során szinte kizárólagosan vegyes
fizikai közegeket kombináló, más-más protokollok szerint felépülő útvonalak kötik össze a forrást a
céllal, az adatkapcsolati rétegnek pedig össze kell hangolnia ezeket, és garantálnia a csomag sikeres
128 6. fejezet - Adatkapcsolati réteg
célba juttatását.
A fejezet során az adatkapcsolati réteg következő elemeivel fogunk megismerkedni:
• alapvető szolgáltatások
• hibadetektálás és javítás - ha egy bit értéke megváltozik az átvitel során, azt hogyan tudjuk
detektálni és esetleg javítani a fogadó félnél
• többszörös hozzáférési protokollok (MAC-protokollok) - mi történik, ha egy átviteli közegben
egyszerre több eszköz szeretné a küldő szerepét betölteni
• LAN-ok felépítése - hogyan épülnek fel a helyi hálózatok és milyen protokollok segítségével
valósul meg a funkcionalitásuk
• vonal virtualizáció - MPLS protokoll, működése és előnyei
• adatközpont hálózatok - hogyan épül fel az adatkapcsolati réteg egy nagy vállalat több ezer
szervert tároló központjában
• vezetékmentes hálózatok - a WiFi és GSM hálózatok felépítése és működése
• mobilitás - hogyan kerül lekezelésre az, ha egy eszköz vezetékmentes hálózatot vált egy
kommunikáció folyamat közben?
6.1: adatkapcsolati réteg elemei és szolgáltatásai1
Az adatkapcsolati réteg számos szolgáltatást biztosít annak érdekében, hogy megvalósuljon a
biztonságos kommunikáció az egyes csomópontok között.
• keretezés - a felsőbb rétegektől érkező datagramokat keretekbe foglalja
• vonalhozzáférés - szabályok biztosítása olyan esetre, amikor az adott közegben egyszerre
több adó lehetséges
• megbízható átvitel a szomszédos csomópontok között (jellemzően a vezetékmentes vonalakon
• folyamvezérlés - a szomszédos küldő és fogadó csomópontok között ütemezés a keret ekbe
foglalt bitek segítségével
• bithibák detektálása és javítása
• egyirányú vagy kétirányú kapcsolatok menedzselése
A keretezés az az eljárás, melynek során a felsőbb rétegektől érkező datagramot az adatkapcsolati

6.3 Megvalósítása 129
réteg keretbe foglalja, ellátja a szükséges fejléccel, lezárással, illetve MAC-címekkel a fizikai
rétegen való továbbításhoz. A vonalhozzáférés definiálja a közeghozzáférési, avagy MAC-protokollt,
mely meghatározza a szabályokat, amelyek alapján a keret átvitelre kerül, amennyiben a használt
átviteli közeghez egyszerre több adó is csatlakozik. A megbízható átvitel gondoskodik róla, hogy
az átvitel során előfordulható hibák kijavításra kerüljenek
Fontos A megbízható átvitel már eleve megbízható, alacsony bithibájú átviteli közeg (optika,
csavartérpár) esetén nem kimondottan fontos, és előfordulhat, hogy ilyen esetben nem is
implementálják, ám amennyiben adott egy gyakori hibákra hajlamos vonal (a vezetékmentes
megoldások jellemzően ilyenek), az adatkapcsolati réteg hatalmas terhet képes levenni a felsőbb
rétegek protokolljairól, és nagyban növeli a kommunikáció hatékonyságát azáltal, hogy a
szállítási rétegben látott megoldásokhoz hasonló eszközökkel (újraküldés és a sikeres célbaérést
jelző elismervények) már ezen a szinten javítják a hibákat.
A hibadetektálás és javítás azért szükséges a rétegben, mert a fogadó fél tévesen 0-ként
érzékelhet biteket, amelyek eredetileg 1-esek voltak és fordítva. Emiatt számos protokoll használ
hibadetektáló biteket, melyek révén megakadályozhatják a hiba továbbterjedését. A hibajavítás
ennek egy fejlettebb formája, mely képes a hiba pontos helyét is megállapítani, és korrigálni ott a
hibás biteket.
Fontos Az adatkapcsolati rétegben használt MAC-címek nem azonosak az IP címekkel! Míg

a 32 bites (vagy újabban 128 bites) IP cím a szolgáltatótól és az eszközök konfigurációjától
függően változhat és a hálózati rétegben zajló forgalomirányítás során játszik szerepet, addig
a 48 bites MAC-cím állandó, nem véletlenül ismert "beégetett címként" is. Az adatkapcsolati
réteg protokolljainak működéséhez a MAC-címre van szükség, ennek segítségével kerül ”helyi”
szinten a keret az egyik interfész (fizikai)ről a fizikailag kapcsolt másik interfész (fizikai)re.
felsőbb rétegek felsőbb rétegek
datagram datagram
Adatkapcsolati réteg Adatkapcsolati réteg
vezérlő vezérlő
küldő állomás fogadó állomás
keret datagram
6.2: adatkapcsolati réteg működési elve1
Az adatkapcsolati réteg helyes működésének elengedhetetlen feltétele, hogy a hálózat minden
csomópontján implementálva legyen. A megvalósítás helye jellemzően a hálózati adapter, melyet
gyakran hálózati illesztőkártya (NIC) néven is ismernek. Az eszköz MAC-címe jellemzően a NIC
ROM-jáben van beégetve. Az interfész (fizikai) kulcsfontosságú komponense az adatkapcsolati
kontroller, egy integrált chip, mely hardveres implementációként tartalmazza az adatkapcsolati réteg
által biztosított szolgáltatásokat, a chip aktiválását és a címzési információk előállítását azonban
a szoftver végzi, az adapter így hardverre, szoftverre és az adapterre írt firmware kombinációja
révén működik. Az adapter maga a host rendszer buszához kapcsolódik, lényegében ugyanúgy,
mint bármely másik I/O eszköz. A hálózati adapterek egymás között keretek segítségével
kommunikálnak, melybe becsomagolják a felsőbb rétegektől kapott datagramot, ellátva a hibadetektáláshoz,
folyamvezérléshez szükséges információkkal, amelyek alapján a fogadó fél ellenőrizni tudja a keret
sértetlenségét, ütemezni az újabb keret ek küldését, fogadását, valamint helyreállítani a datagramot
és továbbítani a saját felsőbb rétegeihez a [6.2] ábrán látható módon. Ezen a szinten a keretek
hordozzák a réteg szolgáltatásaihoz szükséges információkat.
alkalmazás
szállítás
hálózat cpu memória
adatkapcs.
állomás
busz
vezérlő (pl.: PCI)
adatkapcs.
fizikai
fizikai
átvitel
hálózati illesztőkártya
6.3: adatkapcsolati réteg hardveres megvalósítása1
A bit szintű hibadetektálás és javítás természetesen nem egyszerű művelet. Az itt megismert
módszerek egyike sem fog garantált hibadetektálást megvalósítani.
Fontos A hibadetektálás megvalósításához az adatkapcsolati réteg a keretbe foglalt értékes

adatot jelölő biteket (ezeket jelöljük most D-vel - az adatkapcsolati réteg által átadott fejléc
adatok is D részeit képezhetik) kiegészíti az értékes adat sértetlenségének ellenőrzését szolgáló
hibadetektáló - és javító bitekkel (ezeket EDC-vel jelöljük a továbbiakban). A detektáló
módszerek nem tévedhetetlenek; ugyan minél nagyobb az EDC, annál nagyobb eséllyel
detektálhatóak és javíthatóak az átvitel során keletkezhető bithibák, azonban még egy kellően
nagy EDC rész esetén is sor kerülhet észrevétlen bithibák keletkezésére, amelyekben az átvitelt
6.4 Hibadetektálás 131
követően az egyes bitek tévesen kerülnek 0 vagy 1 értékkel felismerésre. A hibadetektáláson az

ilyen átvitel során bekövetkezett bit értékváltozások detektálását értjük
Az egyik legegyszerűbb hibadetektálási módszer az úgynevezett paritásteszt. Ezt a gyakorlatban

meglehetősen ritkán használják, ám esetünkben kiválóan megfelel arra a célra, hogy megismerkedjünk
a hibadetektálási módszerek alapjaival, és innen léphessünk majd tovább jóval komplexebb (és
gyakorlatiasabb) módszerek felé. Képzeljük el, hogy a keret értékes D része pontosan d bitből áll.
Ehhez az EDC részbe felveszünk pontosan 1 darab extra bitet, melynek értékét úgy állítjuk 0-ra
vagy 1-re hogy a D részben található 1-es bitek száma ezzel az extra bittel együtt páros legyen.
Ezt az extra bitet nevezzük paritásbitnek. Amennyiben csak egyetlen bithiba történt az átvitel
során, a felek ennek köszönhetően könnyen detektálhatják, hiszen ha az 1-esek száma a fogadónál
a paritásbittel együtt is páratlan, akkor biztos, hogy legalább egy bit értéke megváltozott az átvitel
során. Ekkor a fogadó fél eldobja a sérült keretet és megkéri a küldőt az újraküldésre.
sor paritás
oszlop
paritás
paritás
hiba
nincs hiba paritás

0 0
hiba
korrigálható
paritáshiba
6.4: Hibadetektálás paritásbitek segítségével1
A hangsúly itt az egy biten van - a fenti faék egyszerűségű, úgynevezett egydimenziós
paritásteszt ugyanis csak olyan megbízható vonal esetén használható bármire, amin még egyetlen
bithiba esélye is kicsi, kettő vagy több egyenesen lehetetlen - ilyen esetben ugyanis ha nem egy,
hanem kettő, vagy több, páros számú bit kerül hibás átküldésre, a paritásbit ellenére helyesnek
fogjuk detektálni a D részt, és detektálatlan bithiba keletkezik. Közel sem elhanyagolható tény,
hogy ezek az átviteli hibák ha bekövetkeznek, a gyakorlatban nem egy, hanem több bitet érintenek.
Épp emiatt fejlesszük tovább a paritástesztünket egy kétdimenziós formára az alábbi módon:
rendezzük a D rész bitjeit sorokba (i) és oszlopokba (j) kb. mátrix formában, és minden sor, minden
oszlop kapjon egy paritásbitet, továbbá az paritásbit ek oszlopának és sorának keresztmetszete is
kapjon egy extra paritásbitet a [6.4] számú ábrán látható módon
Mi is történt? Egyrészt, ha egy soron vagy oszlopon belül esetleg több bithiba is történik, meg
tudjuk őket fogni, és javítani is tudjuk őket, hiszen a mátrixos elrendezésnek köszönhetően a bithiba
helye automatikusan kideríthető. Másrészt maguk a paritásbitek is kaptak egy ellenőrzőbitet, így ha
esetleg az átvitel során pont az egyik paritásbit sérülne meg, immár azt is detektálni tudjuk. Kicsit
érezhető, hogy ez a módszer még mindig sántít (mi történik, ha a paritásbitek ÉS a paritásbitek
paritásbitje is sérülnek?), ám ha feltételezzük, hogy ez a módszer eleve olyan esetekben használható
csak, ahol kicsit a bithiba esélye, a hiba pedig ha be is következik, egymáshoz közeli bitek
csoportját érinti majd, nagy valószínűséggel el tudja majd látni a szerepét. A módszereket, amelyek
képesek detektálni és javítani is az átviteli hibákat összefoglaló néven, FEC vagyis Forward Error
Correction technikáknak hívjuk.
Lépjünk kicsit tovább a gyakorlatiasabb irányba. Az ellenőrző összeges módszert már élesben
is használjuk az adatkapcsolati rétegben is. Az ötlet maga itt is egyszerű. A d bitből álló értékes
D részt úgy kezeljük, mintha k-bites integer számok sorozata lenne. Ezen az elven alapul az
internetes ellenőrző összeg is - az adatot 16-bites számok sorozataként kezeljük. Vesszük ezeknek
a 16 bites számoknak az összegét, majd ellenőrző összegként a keret fejlécébe írjuk az összeg
1-es komplementerét. A fogadó egyszerűen újraszámolja az összeget, majd az ellenőrző összeggel
kiegészítve megvizsgálja, minden helyiértéken 1-es áll-e. Amennyiben igen, az átvitelt helyesnek
ítéli, még eltérés esetén detektálja az átviteli hibát. A módszer nem tévedhetetlen, ám nagy előnye,
hogy hardveresen implementálható, és számos esetben már ki tudja számolni az esetleges hibákat,
míg egy szinttel feljebb, az adapterben már lehetőségünk van hatékonyabb, komplexebb megoldások
számítására is az esetleges átcsusszant hibák elfogására.
A leggyakrabban használt, adapterben szoftveresen implementált ilyen módszer a ciklikus
redundancia ellenőrzés vagyis CRC kódok, más néven polinomiális kódok, mivel az átküldendő
bitsor tekinthető polinomnak is, melyben a 0 és 1 értékek a társegyütthatók, a műveletek pedig a
polinimális aritmetika részei. A CRC használatának alapja lényegében egy matematikai számítás,
a keret értékes D részét úgy kezeli, mintha azok bináris számok lennének. A küldő és fogadó
felek az adatküldés előtt megegyeznek egy r+1 bitből álló úgynevezett generátor mintán, G-n,
melynek legbaloldalibb értéke 1. Miután ez megvan, a küldő minden esetben hozzácsatol a D
értékes részhez r darab bitet úgy, hogy az összefűzött <D,R> rész elosztva a G mintával pontosan
0 maradékot eredményezzen, azaz <D,R> = n*G. Amennyiben ennek az osztásnak a maradéka
nem nulla, a fogadó fel fogja ismerni, hogy hiba keletkezett az átvitel során. Az összes CRC
műveletet 2-es modulójú aritmetikával végzik, melyben az összeadás és kivonás műveletek egyaránt
megfeleltethetőek a bitenkénti XOR műveletnek, például:
1011 XOR 0101 = 1110

1011-0101 = 1110
A matematikai képlet, amit a CRC során használunk pedig:
D ∗ 2r XOR R = nG (6.1)
R megfelelő értékét pedig a fenti képlet átrendezésével az alábbi módon számítjuk ki hatékonyan:
R = maradek((D ∗ 2r )/G) (6.2)
R kiszámítására a [6.5] ábrán láthattok példát.

A CRC módszer képes minden r+1 bitnél rövidebb hibát detektálni.

Az adatkapcsolati réteg kétfajta vonal összeköttetést lesz lehetővé - az egyszerűbb a pont-pont
összeköttetés (PPP), amelynél az átviteli közeg mindössze két szomszédos csomópontot köt
össze, és amely nem igényel speciális megoldásokat sem. Ennél azonban a gyakorlatban sokkal
gyakrabban fordulnak elő úgynevezett többszörös hozzáférési vagy broadcast közegek, amelyekben
egyszerre több kommunikáló fél próbálja küldeni és fogadni az értékes kereteket - ilyen közeg
például a régi, céges Ethernet hálózat, de a LAN is.
6.5 Többszörös hozzáférési protokollok 133
1001 101110000
1001 D
101
000
1010
1001
110
000
1100
1001
1010
1001
110
6.5: R értékének kiszámítása1
Fontos Többszörös hozzáférésű interferenciára, vagyis ütközésre kerülhet sor, amikor egy
csomóponthoz egyszerre érkezik kettő vagy több forrásból keret, a felek pedig képtelenek
értelmezni és javítani a kavarodást, így minden átküldött, értékes adat elveszik. Az ilyen eseteket
nevezzük többszörös hozzáférési problémának, és megoldásukra használja az adatkapcsolati
réteg a többszörös hozzáférési protokollokat (MAC-protokollokat), amelyek lényegében
meghatározzák a vonalak megosztási szabályait, vagyis azt, hogy mikor melyik csomópont
hogyan töltheti be az adó szerepét. Ezeket a szabályokat a kommunikáló feleknek már a
kapcsolat kialakításakor meg kell határozniuk (viszont más megoldás híján szintén a többszörös
hozzáférésű csatornán keresztül).
Amennyiben adott egy átviteli közeg, melyen keresztül másodpercenként R bit haladhat át és
egy minden tekintetben ideális protokoll felelne a hozzáférési probléma feloldásáért, akkor:
• amennyiben egy csomópont szeretne adóként funkcionálni az adott pillanatban, annak

másodpercenként R bites átviteli sebességgel kell tudnia adni
• M adni szándékozó csomópont esetén átlagosan M/R átviteli sebességgel kell tudniuk adni
• teljesen elosztott állapotban kell működnie, nem lehet semmilyen kitüntetett, koordinátor
vagy vezérlő szerepet betöltő csomópont, sem óra vagy rés alapú szinkronizálás (ám emiatt
egyetlen csomópont kiesése sem vezethet a protokoll hibás vagy helytelen működéséhez)
• Az algoritmus maga egyszerű, vagyis költséghatékonyan implementálható a csomópontokon
megosztott drót (pl.:, megosztott RF megosztott RF emberek a rendezvényen

vastag kábeles Ethernet) (pl.: 802.11 WiFi) (műhold) (megosztott levegő, akusztikailag)
6.6: Többszörös hozzáférésű közegek1
Természetesen ezek teljes megvalósítása egy mérhetetlenül költséges és komplex feladat

lenne, így a valós MAC-protokollok bár hatékonyságukban próbálják közelíteni egy ideális
protokoll működését, ahogy azt a következő alfejezetek során láthatjuk majd, nem ideálisak.
A MAC-protokollokat három nagy csoportba szoktuk sorolni a működési elveik alapjáni:
• csatorna particionáló protokollok: a rendelkezésre álló csatornát valamilyen elv alapján
(idő, frekvencia, kód) felosztja, a keletkezett szegmenseket pedig kizárólagos használatra
osztja szét a csomópontok között
• véletlen hozzáférésű protokollok: a csatornát nem osztjuk fel, az ütközések megengedettek,
ám biztosítunk módot az ütközések hatékony kezelésére
• felváltott protokollok: a csomópontok felváltva férnek hozzá az átviteli közeghez annak
függvényében, hogy melyiknek mennyi közlésre szánt adata van
Most pedig vegyük kicsit alaposabban szemügyre ezeket az osztályokat néhány példán keresztül.
6.5.1 Csatorna Partícionáló Protokollok

A legegyszerűbb csatorna partícionáló protokoll a TDMA, vagyis Time-Division Multiplexing
Access, időosztásos hozzáférés. Ez az algoritmus a csatornahozzáférést gyakorlatilag körökre osztja,
amelyek egy fix időtartamot ölelnek fel, egy kört pedig annyi azonos méretű szegmensre oszt, ahány
adásra képes csomópont kapcsolódik a közeghez. Ezek a rések biztosítják az adott időegységen
belül a csomag adási időt. A módszer szépsége egyben a legnagyobb hátránya is: a csomópontok
számára akkor is üresen fenn van tartva az adott körön belül a csomag adási idő, ha éppen nem
szándékoznak küldeni semmilyen keretet. Vagyis egy nagy terhelés alatt álló hálózaton garantált,
hogy minden egyes csomópont egységes arányban adhat, egy alacsony terheltségű hálózatban
azonban az átviteli kapacitás kihasználatlan, és az adni szándékozó csomópontok feleslegesen meg
vannak lassítva, mivel minden körben ki kell várniuk a sorukat, és csak a számukra biztosított ideig
küldhetik a kereteket, még akkor is, ha közben egyetlen más csomópont sem szándékozik adni.
6 rés 6 rés
keret keret
1 3 4 1 3 4
6.7: TDMA - idő alapú csatornfelosztás1
Egy fokkal hatékonyabb a TDMA közeli rokona, az FDMA, amely a felosztás alapjául az
idő helyett az átviteli közeg spektrumát bontja frekvenciasávokra, és minden csomóponthoz fixen
egy ilyen sávot rendel. Itt már nagyobb előny, hogy akár egyszerre több csomópont is adhat
az ütközés veszélye nélkül, hiszen az adás lényegében szeparált csatornákon keresztül történik
meg, ám az alacsony terheltségű hálózatok itt is hátrányokba ütköznek: amennyiben a közeget
N frekvenciasávra bontjuk le az N darab csomópont számára, az egyes csomópontok bármely
időpillanatban csak R/N bites átviteli sebességgel küldhetnek - még akkor is, ha a közeget épp más
nem használja küldésre.
idő
frekvencia sávok
FDM kábel
6.8: FDMA - frekvencia alapú csatornfelosztás1
A legfejlettebb csatorna partícionáló protokoll azonban a CDMA, vagyis kód alapú felosztás,
mely minden résztvevő csomópont számára egy egyedi kódot oszt. Megfelelően kiválasztott kódok
esetén akár egyszerre küldhet a csatornát használó összes csomópont, mégsem keletkezik ütközés,
hiszen a fogadó felek a kód alapján ki tudják szűrni a számukra lényeges biteket. A CDMA-t
elsősorban vezetéknélküli hálózatokon, különösen mobilhálózatokon szokták használni - ott egy
kicsit részletesebben foglalkozunk majd vele mi is.
6.5.2 Véletlen hozzáférésű protokollok

Ha szellemes motivációs szövegként szeretnénk megfogalmazni a véletlen hozzáférésű protokollok
lényegét, valahogy úgy hangzana, hogy “nem az a gond, ha ütközés történik, hanem az, amikor
ebből nem tudsz helyreállni”. A véletlen hozzáférésű protokollokat követő csomópontok nem
végeznek semmiféle egyeztetést a közeget használó szomszédjaikkal: a teljes R bites sávszélességet
igénybe véve próbálnak sugározni, amikor küldendőjük van, ami természetesen, ha egynél több
csomópont próbálkozik ugyanabban a pillanatban, elkerülhetetlenül ütközéshez vezet.
Fontos A véletlen hozzáférésű protokollok feladata, hogy detektálják az ütközés bekövetkeztét,

majd valamilyen egyszerű módszerrel - például késleltetett újraküldéssel - akadályozzák meg
az ismételt bekövetkezését az elindított küldési folyamatok sikeres végbemenetele mellett.
(nagyjából mintha egy karambol után a kereszteződésből visszatolatna minden érintett, majd
olyan módon indulnának el újra, hogy ne történjen újra baj).
Az első véletlen hozzáférésű protokollunk a réselt ALOHA. Az ALOHA protokollok a Hawaii

Egyetem által 1971-ben kifejlesztett ALOHAnet hálózat megoldásain és protokolljain alapulnak. A
réselt ALOHA ezek közül az egyik legegyszerűbb. Feltételezi, hogy az adatkapcsolati rétegben
minden keret azonos méretű (L bit), ezek adási ideje alapján az idő résekre (L/R másodperces
résekre) osztható, továbbá a csomópontok szinkronizáltak, csak az egyes rések kezdetén kezdenek el
adni, és ha ütközés történik, azt mind egységesen érzékelik. Amennyiben egy felső rétegtől küldésre
szánt adat érkezik, a réselt ALOHA elvei szerint az adatkapcsolati réteg a keretezést követően vár a
következő időrés kezdetéig és ekkor indítja meg automatikusan a keret küldését. Ha ez ütközés
nélkül lement, akkor teljes a siker, és minden halad tovább, míg ha ütközésre került a sor, a küldő
szerepét betöltő csomópont minden következő rés kezdetén p valószínűséggel megpróbálkozik
az újraküldéssel, amíg az sikeresnek nem bizonyul. Erre a p valószínűségre gondolhatunk kocka
vagy érmedobásként is - amennyiben a megfelelő oldalra érkezik a feldobott tárgy, a csomópont
újrapróbálkozik, ám az egyes csomópontok egymástól függetlenül dobálnak, így ütközésre még az
újraküldések során is sor kerülhet.
A réselt ALOHA erősségei közé tartozik az elosztottság, és sikeres küldés esetén a teljes
elérhető bitsebességgel történő kommunikáció, azonban amint több aktív, vagyis keret küldésre
1. csomópont 1 1 1 1
2. csomópont 2 2 2
3. csomópont 3 3 3
C E C S E C E S S
6.9: Réselt ALOHA potenciális ütközései 3 csomóponttal1
készülő csomópontunk van a közegre kapcsolva, a hatékonyságunk máris jelentős mértékben

csökkent. Az egyszerűség kedvéért definiáljuk a következő két fogalmat: egy rést sikeresnek
tekintünk, amennyiben ütközés nélkül, sikeres átvitelre került sor benne, és sikertelennek vagy
elvesztegetettnek, ha ütközésre került sor. Továbbá az algoritmusunk hatékonyságát tekintsük
a sikeres rések arányának hosszútávon. Amennyiben folyamatosan több csomópontunk próbál
keretet küldeni, a hatékonyságunk már lényegesen csökken, nem is beszélve két igen szélsőséges
esetről: amennyiben egy adott időrésben egyik csomópont sem próbálkozik újraküldéssel, az
üresen, kihasználatlanul marad, holott lehetőséget biztosított volna egy sikeres küldésre, míg ha
sok aktív csomópontunk van, amelyek közül legalább kettő vagy több minden résben küldéssel
vagy újraküldéssel próbálkozik, a hatékonyságunk gyakorlatilag a nullához konvergálhat. Ha
megpróbáljuk matematikailag megbecsülni a hatékonyságot, akkor a következőre juthatunk: az
esélye annak, hogy bármely csomópont sikeresen küld egy időrésben:
N ∗ p(1 − p)N−1 (6.3)
ahol p a küldési valószínűség, N pedig a csomópontok száma. Ha meg is találjuk p* -ot, vagyis azt
a küldési valószínűséget, amely maximalizálni tudja a réselt ALOHA hatékonyságát, végtelenhez
közelítő N-el becsülve és némi kalkulus gyakorlattal azt az eredményt kaphatjuk, hogy a hatékonyságunk
1/e = 0,37 - ami azzal egyenlő, hogy a legeslegjobb esetben is csak a rések 37%-a lesz majd sikeres.
Tervezzük kicsit át a dolgokat: ha javítani próbálunk a fenti modellen, könnyen felmerülhet,
hogy talán elegendő lenne az egyik legszigorúbb korlátozást eltörölni, az időkeretek szerinti
szinkronizálást, vagyis a küldeni szándékozó csomópontok bármikor adhassanak, ne csak a keret
ek elején. Ezzel a feloldással máris megkaptuk a következő véletlen hozzáférésű protokollunkat,
az egyszerű ALOHA-t. A helyzet viszont az, hogy bármennyire is tűnik ez ésszerű megoldásnak,
valójában csak rontottunk a saját helyzetünkön. Tételezzük ugyanis fel, hogy elküldünk egy
keretet a t0 időpontban, egy keret átküldése pedig egy időegységet venne igénybe. Ha a küldések
lehetséges időpontját nem szinkronizáljuk, az azt jelenti, hogy a t0-kor elindított keretünk ütközni
fog minden olyan más kerettel, amit a [t0-1 ; t0+1] időintervallumon belül küldtek. A hatékonyságot
számoló képletünk ekkor az alábbi módon változik (a P() függvény az alábbiakban a mesterséges
intelligencia tárgyak jelölésrendszeréhez módon van értelmezve, vagyis a paraméterként megadott
esemény bekövetkezési valószínűségét jelöli)
P(sikeres küldés) = P(a kijelölt csomópont ad) * P(más csomópont nem ad [t0-1, t0] időintervallumban)
* P(más csomópont nem ad [t0, t0+1] időintervallumban)
Ami kifejtve úgy fest, hogy
p ∗ (1 − p)N−1 ∗ (1 − p)N−1 = p ∗ (1 − p)2(N−1) (6.4)

Ami ahelyett, hogy jobb lenne mint a réselt ALOHA, durván felére csökkenti a hatékonyságot,
és alig 18% esélye lesz csak annak, hogy egy adott időegységen belül sikeres küldésre kerül sor.
Ütközik
Ütközikaa Ütközik a
keret keret
kezdetével végével
I csomópont kerete
6.10: Egyszerű ALOHA ütközési intervallumok1
Ezek után tartsunk egy kis biztonságos távolságot az ALOHA családfájától és tapogatózzunk
más irányban. Tanítsuk meg a csomópontjainkat egy kis alapvető illemre - még ha van is
közölnivalójuk, azt ne kezdjék el azonnal küldeni, ha közben valaki épp használja azt a csatornát.
Ez az egyszerű technika az alapja a vevő érzékelésű többszörös hozzáférésnek, vagyis carrier
sense multiple access (CSMA) protokollnak - küldés előtt a csomópont hallgasson bele az
átviteli közegbe, és csak akkor kezdjen el adni, ha épp más nem használja azt. Ettől függetlenül
természetesen még előfordulhat ütközés, ha két adásra készülő csomópont nem érzékeli egymás
adásának kezdetét, és ugyanabban a pillanatban kezdik el használni a csatornát (ezt hívjuk terjedési
késleltetésnek), és ekkor odaveszhet a teljes közlésre szánt keret. Az ütközés bekövetkezésének
valószínűsége a terjedési késleltetés és a csomópontok között távolság alapján becsülhető és
érzékelhető csupán. Erre az esetre a CSMA -nak létezik egy bővítése is, a CSMA/CD ahol a
CD utótag értelemszerűen a collision detection, ütközésészlelés jelölése. Ekkor ütközés esetén az
összes érintett csomópont befejezi az adást, majd egy véletlenszerűen meghatározott időtartamig
várakoznak, mielőtt ismét megpróbálkoznának a hallgatózással és küldéssel.
Jól hangzik, igaz? Bökkenő csak egy nagyon kézenfekvő ponton van: a gyakorlatban sajnos
közel sem egyszerű olyan gyorsan észlelni azt, hogy ütközés történt, és az átviteli közegben már
nem egy, hanem több csomópont adása vegyült értelmezhetetlen bitfolyamot előidézve. A vezetékes
LAN-okon még van egy ütőkártyánk ilyenkor, ugyanis elég, ha az adó és vevő összehasonlítják az
átviteli közegben az adott és fogadott jelerősséget - míg ütközésmentes esetben ez meg fog egyezni,
ütközés esetén a fogadó nagyobb jelerősséget fog észlelni. Vezetékmentes közegben azonban már
ezt a taktikát sem alkalmazhatjuk, hiszen ott a közegben észlelt jelerősséget befolyásolhatja a zaj is,
mint például a helyi adás.
A CSMA/CD hatékonysága így erősen függ attól is, hogy pontosan milyen közegben van
megvalósítva, továbbá a fenti detektálásos dilemmán felül a stratégiától, mellyel az összeütközött
adók eldöntik, mennyit várakoznak a következő adási kísérlet előtt. Az Etherneten implementált
CSMA/CD algoritmus például az ütközés észlelésekor egy megszakító JAM jelet ad le a közegben,
majd az érintett csomópontok a várakozási idő K értékeként egy véletlenszerű 2 hatványt választanak
- minél több csomópont volt érintett az ütközésben, lehetőség szerint annál nagyobbat. Ezt a típusú
várakozást nevezzük bináris exponenciális visszaszámlálásnak. Egy teljes, CSMA/CD működés
Etherneten így a következő módon összegezhető:
1. A csomópont NIC-je a felsőbb rétegektől megkapja a datagramot, amit keretbe foglal
2. Hallgatózik a csatornán, ha nem érzékel rajta adást, megkezdi a küldést pont ugyanabban a
pillanatban, amikor hasonló események hatására B is ugyanezt teszi

3. Létrejön az ütközés, kis idő elteltével mind az adók, mind a vevők érzékelik a megváltozott
jelerősség hatására, hogy baj van
4. Mindkét adó leállítja az adást és kiküldik a JAM jeleket a csatornára
5. Mindketten elkezdenek várakozni random, kettő-hatvány alapú várakozási idővel, A például
4*512 bit (ahol az 512 bit a keret mérete) átviteli időtartamáig, B pedig 32*512 bit időtartamig
6. Ha ezután újrapróbálkoznak, és mégis ismét ütköznek, növelik a várakozási idejüket a
következő nekifutás előtt
tér
t0
t1
idő
ütközés
Ütközésdetektálási /
megszakítási idő
6.11: Ütközésdetektálás két adóval1
A hatékonyság becsléséhez a CSMA/CD esetében fontos, hogy kicsit finomítsunk a definícióinkon

is: hatékonyságnak most tekintsük azt, hogy egy kellően hosszú időtartam mekkora részén került
sor ütközésmentes kommunikációra úgy, hogy sok küldésre kész csomópontunk van viszonylag
nagy mennyiségű küldésre szánt adattal. A képletünkhöz pedig vegyünk fel két további változót is:
t prop legyen a maximális késleltetés két csomópont között, ttrans pedig az idő, amire szükség van
ahhoz, hogy egy maximális méretű keret eljusson az egyik csomópontról a másikra. A képlet ekkor
e f f iciency = 1/(1 + 5t prop /ttrans )
Ami jobb, mint az ALOHA algoritmusok hatékonysága, ráadásul olcsó és kellően egyszerű is.
Fontos A csatornafelosztásos protokollok tehát jól működnek, ha nagy terhelés van a

csatornán, mert igazságosan és egységesen osztják fel, kis terhelésnél azonban a hatékonyságuk
nagyon lecsökken, az adóknak feleslegesen sokat kell várakozniuk.
A véletlen hozzáférési protokolloknál pont fordul a helyzet - alacsony terhelésnél a csomópontok
a csatorna teljes sávszélességét igénybe veheti a gyors, hatékony küldéshez, magas forgalom
intenzitás esetén azonban folyamatos ütközésekre és várakoztatásokra kerül sor.
6.5.3 Felváltott protokollok

A végére maradtak a váltott megoldást alkalmazó protokollok, amelyek lényegében a két világ,
a csatorna particionáló és a véletlen hozzáférésű megoldások legjobb elemeit ötvözik. Ugyan
ahogy a fenti két osztályból, ezekből is meglehetősen sok létezik, két különösen fontos példát
fogunk megnézni alaposabban is. Az első ezek közül a lekérdező protokoll, mely kapásból
szakít a korábbi megközelítések decentralizált megközelítésével, és az egyik csomópontot kinevezi
mesternek. A mester csomópont feladata megszólítani a szolga csomópontokat, round-robin
szerinti sorrendben értesíti a soron következőt, amelyik elkezdhet adni, és megadja számára azt
is, hogy maximum hány keretet küldhet el egy körben. Ez a megközelítés különösen hatékony,
ha többnyire alacsonyabb teljesítményű, “buta” csomópontok alkotják a hálózatot és lényegében
teljes mértékben eliminálja az ütközéseket az átviteli közegből, azonban rendelkezik pár elég
egyértelmű hátránnyal is: egyrészt, mivel lemondtunk a decentralizált megvalósításról, elég ha
egyetlen csomópont (a mester) meghibásodik, és máris borult minden, a mester - szolgák közötti
kommunikáció költségeivel is számolnunk kell, valamint ha egy szolgának küldenivalója van, a
többinek pedig nincs, még akkor is ki kell várnia azt a késleltetést, amíg a mester megszólítja és
átadja neki a küldés jogát.
adat
lekérdezés
mester
adat
szolgák
6.12: Lekérdező protokoll1
A következő megközelítés, a jelátadó protokoll épp a fenti problémák orvoslására leszámol a

fix mester csomópont koncepciójával, és helyette egy engedélyt/zsetont használ, amit a csomópontok
egymásnak adnak át. Amelyik csomópontnál épp ott van az engedély, annak van joga küldésre,
azonban egy csomópont csak akkor tartja magánál az engedélyt, ha van is küldenivalója, ellenkező
esetben automatikusan küldi tovább a következőnek, ám ha van is küldenivalója, csak egy meghatározott
maximális keret számig küldhet, így egyetlen csomópont sem bitorolhatja el a többi elől a
küldési lehetőséget. Itt továbbra is kell számolni a küldési és késleltetési költségekkel, de bár
a meghibásodási pont nincs kizárva (elég ha továbbküldés közben elveszik az engedély vagy
megsérül az azt épp birtokló csomópont), ez a megoldás mégis hatékonyabb és hibatűrőbb a
lekérdező protokollnál (más kérdés, hogy nagyjából egységes teljesítményű és hatékonyságú
csomópontokat feltételez, míg a lekérdező pont ezt a problémát tudta megoldani).
6.5.4 DOCSIS
Most, hogy alaposabban megismerkedtünk az adatkapcsolati réteg közeghozzáférési protokolljaival
és azok főbb osztályaival, vegyünk szemügyre egy gyakorlati példát, melyben mindhárom osztály
egyaránt alkalmazva van. Ez a Data-Over-Cable Service Interface Specification ( DOCSIS
), mely meghatározza a kábelhálózat architektúráját és a működéséhez szükséges protokollok
adat
adat
6.13: Jelátadó protokoll1
használatát. A modell középpontjában a CMTS, vagyis kábel fejállomás áll, amely több vonalon
összeköti a szolgáltatói ISP hálózatot a helyi egységekkel.
Internet keretek, TV csatornák, a vezérlést lefelé különböző frekvenciákon

küldik
kábel fejállomás
CMTS
…
elosztó kábel
kébelmodem … modem
végződtető rendszer
ISP
felfelé tartó Internet keretek, TV vezérlés, különböző frekvenciákon
és időszletekben küldik
6.14: DOCSIS infrastruktúra1
A DOCSIS FDMA-t használ arra, hogy felossza a kábel fejállomást modemekkel összekötő
felfelé és lefelé is irányuló frekvenciafolyamokat, minden ilyen partícionált csatorna 6 MHz széles
és csatornánként maximum 40 Mbps áteresztőképességgel rendelkezik, míg a felfelé irányuló
csatornák 6,4 MHz szélességgel és 30 Mbps maximális áteresztőképességgel rendelkeznek. Mind a
felfelé, mind a lefelé irányuló csatornák broadcast típusúak, amely a lefelé irányuló esetben nem
probléma, hiszen ezen a végponton mindösszesen egy CMTS fejállomás helyezkedik el, mely az
alá tartozó csomópontok felé sugározhat. Az ellentétes eset azonban már bonyolultabb, mivel a
CMTS felé egyszerre több állomás is küldhet, ezért a felfelé irányuló csatornákon időalapú TDM
van használatban, mégpedig egy speciális opció, a MAP vezérlőüzenet bevonásával, amit a lefelé
6.6 Helyi hálózatok 141
irányuló csatornán küld ki a CMTS a modemeknek és meghatározza számukra, hogy melyikük

melyik időrésben kezdhet el adni, ezáltal teljesen kizárva az ütközési lehetőségeket. Ahhoz azonban,
hogy MAP üzenetekhez juthassanak, még szükség van véletlen hozzáférésű protokollra is - ilyen
logika szerint küldik ugyanis a modemek a CMTS felé a MAP-igényeiket egy erre a célra fenntartott
mini-résen belül. Amennyiben nem kapnak választ a kiküldött kérésekre, a modemek érzékelik a
potenciális ütközést és bináris exponenciális visszaszámlálással várakoznak az újrapróbálkozásig.
Egy ilyen kábelhálózat így a gyakorlatban egyszerre használja a TDM, FDM, random hozzáférés
és központilag kiosztott időrések elveit egyetlen hálózaton belül.

Most, hogy kellő alapossággal megismerkedhettünk az adatkapcsolati réteg nyújtotta szolgáltatásokkal
és a megvalósításukhoz használt protokollokkal, fordítsuk figyelmünket a hálózatmodellekre,
amelyek ezek révén kerülnek megvalósításra. Az adatkapcsolati rétegben működő kapcsolók
(switchek) a MAC-címek alapján azonosítják egymást, és számos, a felsőbb rétegek által alkalmazott
protokollal nem rendelkeznek, amely egyszerre biztosít több tekintetben szabad teret számunkra - és
számos, igen komoly kihívást is, amelyeket természetesen végigveszünk az elkövetkező fejezetek
során.
Fontos A MAC-címet szokás beégetett címként, fizikai címként vagy LAN címként
is emlegetni, az IP címmel ellentétben ugyanis, mely a hálózati paraméterek függvényében
változhat, a MAC az adott hardveres eszközön jellemzően állandó, a NIC ROM-jában van
beégetve - tehát ha ugyanazt a hálózati kártyát átteszem egy másik irodában egy másik gépbe,
a MAC-cím változatlan marad. A MAC-cím hat bájtból áll, melyek közül az első három
magát a gyártót, a maradék pedig a gyártó által meghatározott azonosítót jelöli, például
00-40-96-9D-68-16, ahol a 00-40-96 a Cisco által gyártott eszközök azonosítója. A MAC-cím
tartományokat az IEEE kezeli.
Amikor egy hálózatunk egy adaptere egy másik adapter számára küld keretet az adatkapcsolati
rétegben, a keretben címzettként a célpont MAC-címét helyezi el, és a helyi hozzáférési hálózaton
keresztül indítja el a küldési folyamatot. A MAC-címek közül megkülönböztetjük a speciális
felhasználású broadcast MAC-címet, melynek értéke FF-FF-FF-FF-FF-FF, amennyiben a címzettben
ez a cím szerepel, a keretet a hálózat minden csomópontja meg fogja kapni - más kérdés, hogy a
tartalma alapján csak az vagy azok fognak válaszolni is, amelyekre a tartalma vonatkozik.
Kezdjük a legalapvetőbb kihívással: a MAC-címek beégetett címek, vagyis szemben az
IP címekkel, minden csomópontnak egy fix, a gyártó által kibocsátott ilyen azonosítója van
függetlenül attól, hogy épp milyen hálózatra és hogyan csatlakozik, ellenben ez önmagában még
nem magyarázat arra, hogy hogyan találják meg így egymást ezek a helyi szinten kapcsolódó
eszközök. Itt jön be a képbe az Address Resolution Protocol vagyis az ARP.
Fontos A hálózat minden csomópontja rendelkezik egy ARP táblával, mely tartalmazza
az IP és MAC-cím megfeleltetéseket, bejegyzései pedig az IP címek dinamikus jellege miatt
rendelkeznek egy TTL (time-to-live, szavatosság) attribútummal, mely megadja, egy bejegyzés
a bekerülését követően meddig érvényes és maradhat a táblázatban.
Amennyiben a küldeni szándékozó csomópont olyan IP címre kell keretet küldenie, melynek
MAC-címe még ismeretlen számára, előbb ARP felderítő csomagokat küld a hálózat szórási
MAC-címére (FF-FF-FF-FF-FF-FF), melyet minden, az átviteli közegre csatlakoztatott csomópont
meg fog kapni. Az ARP úgynevezett plug-and-play protokoll - a táblázatok automatikusan,
rendszergazdai beavatkozás nélkül jönnek létre és töltődnek fel az érvényes, “puha” (vagyis
1A-2F-BB-76-09-AD
LAN
(vezetékes hálózati illesztő
vagy
71-65-F7-2B-08-53
vezetékmentes)
58-23-D7-FA-20-B0
0C-C4-11-6F-E3-98
6.15: LAN minta infrastruktúra1
elavulásra képes) információval, mely ráadásul, mivel az általa hordozott információ az adatkapcsolati
és a hálózati rétegre is vonatkozik, lényegében a két réteg közötti határon működik.
Nézzünk egy példát az ARP pontos működésére, ha mindkét fél azonos helyi hálózatban
található:
1. adott két csomópont azonos helyi hálózaton, az egyik, a küldő fél a 192.168.10.1-es IP
címmel, míg a másik a 192.168.10.14-es címmel
2. a küldő ismeri a célpontja IP címét, a MAC-címét azonban nem, ekkor összeállít egy ARP
csomagot, benne a lekérdezés pontos paramétereivel, köztük az IP címmel, melynek MAC
megfelelőjét keresi
3. ezt a csomagot a szórásos MAC-címre küldi (FF-FF-FF-FF-FF-FF), így az ARP csomagot
megkapja a helyi hálózat minden csomópontja
4. az ARP-nek nem feltétlenül kell eljutnia a célponthoz, vagyis ahhoz a csomóponthoz, mely
majd az IP cím alapú kommunikáció célpontja is lesz - elegendő egy olyan csomópontig
eljutnia, amely a saját ARP táblázatában már rendelkezik az érvényes hozzárendeléssel,
melyet ekkor egy válasz ARP üzenetben visszaküld a kérdezőnek
5. a kérdező a választ elmenti a saját ARP táblájában egy érvényességi, time-to-live (TTL)
értékkel, majd ezt követően már képes belekezdeni az eredetileg tervezett küldésbe is.
A helyzet bonyolultabb, ha a célpont nem azonos LAN-on helyezkedik el. Ekkor, [6.16] ábrán
is látható esetben az alábbi lépések hajtódnak végre a sikeres ARP felderítéshez:
1. feltesszük, hogy a küldő A ismeri B IP címét, továbbá ismeri a saját hálózatában az R átjáró
IP és MAC-címét is konfigurációjából és korábbi működéséből
2. Az A által létrehozott datagramot ekkor a réteg keretbe ágyazza az R átjáró MAC-címével és
B IP címével
3. R megkapja a datagramot, és továbbítja azt a saját hálózati rétegének, mely értelmezi az IP
címet és ellenőrzi a forgalomirányítási szabályait
4. Amennyiben nem rendelkezik B MAC-címével, ARP csomagot küld ki a célhálózaton,
amennyiben igen, készít egy újabb keretet, mely tartalmazza A és B IP címeit, valamint B
MAC-címét
6.7 Ethernet 143
MAC src: 1A-23-F9-CD-06-9B

MAC dest: 49-BD-D2-C7-56-2A
IP src: 111.111.111.111
IP dest: 222.222.222.222
IP
IP Eth
Eth Phy
Phy
A B
R
111.111.111.111
222.222.222.222
74-29-9C-E8-FF-55
49-BD-D2-C7-56-2A
222.222.222.220
1A-23-F9-CD-06-9B
111.111.111.112 111.111.111.110 222.222.222.221

CC-49-DE-D0-AB-7D E6-E9-00-17-BB-4B 88-B2-2F-54-1A-0F
6.16: ARP felderítő folyamat1
6.7 Ethernet
A LAN-ok kialakítására több lehetséges technológia is létezik, közülük a legnépszerűbb és
legszélesebb körben használt az Ethernet, köszönhetően relatív olcsóságának, könnyű kiépíthetőségének
és magas sebességének. A 80-as évek során bukkant fel az egyik első széleskörben alkalmazott
LAN technológiaként és tett szert egyre nagyobb népszerűségre, míg a 90-es évekre a legtöbb
cég más LAN megoldások helyett már Ethernetet használt. Azóta is tartja a lépést, folyamatos
szabványai révén, melyek egyre gyorsabb, megbízhatóbb megvalósítást specifikálnak. Míg a
90-es években népszerű volt a busz topológia, melyen a csomópontok sínszerűen csatlakoztak
koaxiális kábellel egy ütközési tartományra, ezt később leváltotta az úgynevezett csillag topológia,
melyben a hálózat csomópontjai egy központi eszközön keresztül csatlakoznak egymáshoz direkt
kapcsolatok nélkül. A 90-es években a csillag középpontjában még egy hub nevű eszköz állt, mely
keretek helyett bitekként kezelte az áthaladó adatforgalmat - ezt váltotta le a 2000-es évek során a
lényegesen hatékonyabb switch vagy más néven kapcsoló.
kapcsoló
csillag
busz: koaxiális kábel
6.17: Csillag Ethernet topológia1
A hatékony működés megvalósításában a hardveres kiépítés mellett nagy szerepet játszik az

Ethernet keret felépítése is, mely egy speciális, fix formátumot követ.
A keret előtagja a kommunikáló felek közötti óraszinkronizációt szolgálja és egy előre
meghatározott mintát követ, amely 7 darab 10101010 mintájú bájtot, majd egy 10101011 mintájú
bájtot tartalmaz. A cél és forrás címek az eszközök MAC-címeit jelölik, míg a típus pedig a
felsőbb szintek által meghatározott protokollt, amely általában az IP, de lehet más is. Az adat vagy
payload értelemszerűen a keretben átvinni kívánt adatot tartalmazza, például az IP datagramot,
amely a felsőbb rétegek által összeállított csomag, ellátva a megfelelő headerekkel, míg a keretet
típus
cél forrás adat

előtag cím cím CRC
6.18: Ethernet keret felépítése1
záró CRC a ciklikus redundancia ellenőrző összeg a hibák detektálására a fogadó oldalán.
Fontos Az Ethernetet több szabvány is implementálja, amelyekben a keret formátumon kívül

még közös vonás, hogy mind kapcsolatmentes kommunikációt használ, vagyis szemben a
magasabb szintek protokolljaival, nem indít kézfogást a kommunikáló felek között, egyszerűen
elindítja az Ethernet kereteket. Ebből fakadóan megbízhatatlanok is - a fogadó fél nem küld
megerősítéseket a keretek sikeres érkezését követően, az esetleges veszteségeket csak a felsőbb
szintek protokolljai detektálhatják, mint a TCP, és kezdeményezhetik az újraküldésüket.
Az átviteli közeg kezelésére CSMA/CD MAC-protokollt használnak az ütközések elkerülése

érdekében. A különböző Ethernet-szabványok különböző sebességeket (2 Mbps, 10 Mbps, . . . .
40 Gbps) és különböző fizikai rétegbeli médiumokat definiálnak (optika, kábel). A legkorábbi
Ethernetet például koaxiális kábelszegmensek formájában tervezték, így az ezt leíró korai 10BASE-2
és 10BASE-5 szabványok például legfeljebb 500 méter hosszú koaxiális kábeleken megvalósított,
maximum 10 Mbps sebességet határoz meg, ennél hosszabb kiterjedést pedig csak egy speciális
eszköz, az ismétlő segítségével érhettek el, mely képes volt rá, hogy az egyik interfész (fizikai)én
beérkező jeleket automatikusan továbbítsa egy másikon. A koaxiális kábel, mint átviteli közeg
mellesleg tökéletes implementációja az eddig emlegetett koncepcióinknak: a rajta áthaladó kereteket
minden interfész (fizikai) elkaphatja, a CSMA/CD protokoll megoldhatja rajta a többszörös
hozzáférési problémát, a csomópontoknak pedig mindössze rá kell csatlakozniuk a hálózatra,
és máris működőképes helyi hálózatunk van. A 90-es években ezt bővítették a réz (100BASE-T) és
üvegszálas (100BASE-FX, SX, BX), lényegesen magasabb sebességet elérhetővé tevő szabványok,
melyek az átviteli sebességet a 10-szeresére növelték. Később ezeket bővítette az IEEE 802.3z,
vagyis Gigabit Ethernet szabvány, mely amellett, hogy kompatibilis maradt a korábbi szabványokkal,
melyek már optikai kábelek és akár 40 Gbps sebesség elérését definiálták.
MAC protokoll
alkalmazás és keret formátum
szállítás
hálózat 100BASE-TX 100BASE-T2 100BASE-FX
adatkapcs. 100BASE-T4 100BASE-SX 100BASE-BX

fizikai
réz (csavart optika, fizikai réteg

érpár) fizikai réteg
6.19: Ethernet szabványok1
Már a fentiekből is kitűnhet, hogy mindennek a hatékony megvalósításához egy meglehetősen

komoly összekötőre van szükség, épp emiatt vegyük kicsit alaposabban szemügyre most az
6.7 Ethernet 145
Ethernet magját hajtó kapcsolót. Igen komoly elvárásoknak kell megfelelnie - tudnia kell tárolni
és továbbítani az Ethernet-kereteket, értelmezni és elemezni a beérkező keretekben található
MAC-címeket, CSMA/CD-vel megakadályozni az ütközéseket (ütközések esetén ahogy pár alfejezettel
korábban tanultuk, bináris visszalépéssel).
Fontos A kapcsoló transzparens (vagyis a kommunikáló csomópontok nem érzékelik a

jelenlétét), két fő funkciója a szűrés, melynek segítségével szabályokat adhatunk meg egyes
keret ek eldobására és a továbbítás, mely a beérkező keret információi alapján megállapítja,
melyik interfész (fizikai)én kell továbbküldeni azt a cél felé, és a küldést végre is hajtja.
Működésének alapja a kapcsolótábla, egy információs struktúra, amely tartalmazza, hogy
a kapcsoló melyik portjára milyen eszköz, milyen MAC-címmel kapcsolódik. A kapcsoló
öntanuló, a táblázata a használat során töltődik ki beavatkozás nélkül.
A csatlakozó állomások közvetlenül a kapcsolóhoz csatlakoznak. Mivel a jelenlétét nem

érzékelik (még a csomagok bufferelése is transzparensen történik), a kapcsolón keresztüli kapcsolat
gyakorlatilag egy kétirányú, szeparált ütközési tartomány (melyekhez mivel csak két állomás
csatlakozik, a kommunikáció ütközésmentesen folyhat)
A kapcsolók öntanuló algoritmusa az alábbi módon működik:
1. A kapcsolóhoz az egyik portján keret érkezik.
2. A kapcsoló feljegyzi a kapcsolótáblájában az interfész (fizikai)t és a forrás MAC-címét.
3. A cél MAC-címét keresni kezdi a táblázatban.
4. Ha megtalálja és a cél interfész (fizikai) megegyezik a forrás interfésszel, eldobja a keretet,
különben a megfelelő interfész (fizikai)én továbbítja.
5. Ha nem találja a cél MAC-címét, elárasztáshoz folyamodik és a bejövő interfész (fizikai)
kivételével mindegyiken továbbküldi a keretet
A kapcsolók a 6.20 ábrán látható módon egymással is összeköthetőek. Ekkor egy adott interfész
(fizikai)re több MAC-cím csatlakozhat, így képesek kezelni és tanulni az olyan eseteket, amikor
az egyik interfész (fizikai)en egy másik kapcsolóval van összekötve - ezeket nevezzük heterogén
vonalaknak. Ekkor, ha például az egyik kapcsoló találkozik az ismeretlen MAC-cím problémájával,
ismét a fenti elárasztásos algoritmussal próbálja meg feloldani a címet, ám a szomszédos kapcsolók,
amennyiben már rendelkeznek a szükséges információval, nem folytatják az elárasztást, hanem
a saját kapcsolótáblájuk információinak megfelelően továbbítják a keretet a cél felé, a válasz
visszaküldése során pedig az eredeti küldő is feljegyzi a MAC-címet a kapcsolótáblájában. Lássuk
ezt egy példán keresztül is:
1. A keretet szeretne küldeni I-nek. S1 és S3 ismerik a hozzájuk közvetlenül csatlakozó
eszközök MAC-címeit, a többiét azonban nem, és S4 kapcsolótáblája is üres (erre ilyen
topológia esetén a gyakorlatban elég kicsit az esély, hacsak nem közvetlenül a kiépítés után
járunk, de a példánk legalább komplexebb így)
2. S1 továbbítja a keretet S4 felé, majd S4, mivel nem tudja, melyik interfész (fizikai) én
csatlakozik I, S2-nek és S3-nak is továbbítja azt (előbb persze feljegyzi A MAC-címét a
kapcsolótáblájában).
3. S2 amennyiben még nem rendelkezett A MAC-címével, feljegyzi azt, majd szintén mindegyik
interfész (fizikai)én továbbítja a keretet, ám miután egyikről sem kap választ, eldobja azt,
S3 viszont a kapcsolótáblájából tudja, melyik interfész (fizikai)én csatlakozik I, és már csak
neki továbbítja a keretet.
4. A válasz keret küldése során mind S4, mind S1 feljegyzik I MAC-címét a megfelelő interfész
(fizikai)eiken
Egy kapcsolókkal felépített LAN egyúttal képes teljesen eliminálni az ütközéseket, a kereteket
S4
S1
S3
A S2
F
D I
B C
G H
E
6.20: Több kapcsoló összekötése1
ugyanis bufferelhetik és csak egyenként, egyenletes tempóban engedik át. Továbbá a kapcsolók
révén lényegesen könnyebbé válik a hálózat menedzselése is, ugyanis számtalan hasznos mechanizmussal
- például egy hiba hatására ugyanazt a keretet ismételgetve küldő, úgynevezett dadogó adapterek
letiltása, a különböző interfész (fizikai)ekről statisztikák gyűjtése a potenciális teljesítménybeli
problémák és hibák detektálásához.
Fontos A kapcsolók nem forgalomirányítók, és az állítás fordítva sem igaz, bár funkcionalitásuk
elsőre hasonlónak tűnhet, és mindkettő rendelkezik egy saját kapcsolótábla -típussal is, ám a
forgalomirányítók a hálózati réteg eszközei és az IP címekkel foglalkoznak, míg a kapcsolók az
adatkapcsolati réteg fejléceivel dolgoznak és a MAC-címeket veszik alapul.
A forgalomirányítók különböző hálózatokat, alhálózatokat kötnek össze és a hálózati réteg

fejléc-információit elemzik (IP cím), majd ennek tartalma alapján forgalomirányító algoritmusokkal
számolják ki, merre kell továbbítaniuk azt a célpont eléréséhez. A kapcsolók egy hálózaton belül
működnek, és a MAC-cím, valamint az öntanuló algoritmusokkal feltöltött kapcsolótáblák alapján
továbbítják a kereteket. Ugyan léteznek úgynevezett L3 kapcsolók, amelyek a hálózati réteg és
az adatkapcsolati réteg protokolljait is képesek megvalósítani, ezek azonban nincsenek általános
használatban.
6.8 VLAN
Viszont a kapcsoló és az átjáró közötti különbségeknek van egy súlyosabb következménye is: még
ha a hálózati réteg szintjén el is tudjuk különíteni a különböző logisztikai egységek kommunikációját
az alhálózatokra bontással, ezt már az adatkapcsolati rétegben nem tudjuk megtenni, nincs
lehetőség a forgalom izolálására: hiába rendelkezik két csomópont különböző alhálózatokba
tartozó IP címmel, ha ugyanahhoz a switchhez kapcsolódnak, igenis lesznek csomagok az adatkapcsolati
rétegben, amelyek a MAC-címeket használva eljuthatnak mindkettejükhöz.
Ez a hálózat típusától függően számtalan kockázati tényezővel járhat a biztonsági kockázattól
kezdve a teljesítménybeli romlásig a felhasználók kezelését illetően (gondoljunk csak bele mi
történne, ha a menedzsment ugyanazon a LAN-on próbálna cégen belüli konferenciabeszélgetést
bonyolítani, amit épp az informatikusok is leterhelnek egy épp fejlesztett hálózati alkalmazással),
amit legfeljebb több, teljes hatékonyságuknak csak töredékét kihasználó fizikai kapcsoló
bevonásával orvosolhatnánk - és egyúttal teremtenénk is magunknak új problémát, hiszen ettől
kezdve elég lenne, ha egy felhasználónak csak ideiglenesen kellene munkaállomást váltania, az
máris kábelek újrakötésével, infrastrukturális akadályokkal járna.
6.8 VLAN 147
Forrás: A
Cél: A’
A A A’
C’ B
6 1 2
AA A’
A’
5 4 3
B’ C
A’ A
A’
6.21: Kapcsolótáblák tanulása Ethernet hálózaton1
Ezt a problémát oldják meg a virtuális helyi hálózatok, vagyis VLAN-ok, melyek képesek egy
fizikai hálózatot több virtuális hálózatra felbontani úgy, hogy azoknak az adatkapcsolati rétegbeli
forgalma is el legyen szeparálva.
Fontos A kapcsolók alapértelmezésben minden interfész (fizikai)üket access hozzáférési

módban egyetlen nagy, közös VLAN-hoz sorolják, amíg ezt a konfigurációjuk megváltoztatásával
át nem írjuk. Ekkora különböző VLAN-okba tartozó eszközök forgalma a közös kapcsoló
ellenére teljesen izolálódik, egy interfész (fizikai)en pedig csak akkor mehet át több VLAN
kerete, ha azt úgynevezett trunk hozzáférési módra állítjuk.
A trunk átviteli mód alapja a IEEE 802.1Q (Dot1Q) szabvány által definiált bővített keret
formátum, mely egy 4 bájtos VLAN címke mezőt helyez a keretek headerjébe és eltárolja benne a
keret eredeti VLAN-jának azonosítóját, mely a trunk vonal másik végpontján így helyreállítható.
Ez a címke mező egy két bájtos azonosítóból és egy szintén kétbájtos vezérlőinformációból tevődik
össze (természetesen az ilyen beágyazáskor, majd visszanyeréskor szükséges a CRC ellenőrző
összeg újraszámolása is). Ám önmagában még a trunk móddal sem oldható meg olyan helyzet,
amikor két különböző VLAN-ba tartozó állomás próbál kommunikálni egymással.
Fontos Amennyiben mégis szükséges a VLAN-ok közötti átjárhatóság, akkor fontos, hogy a
különböző VLAN-ok egyúttal különböző hálózati vagy álhálózati címtartományokra kerüljenek,
email szerver
külső hálózathoz
web szerver
forgalomirányító
IP alhálózat
6.22: Intézményi Ethernet hálózat1
ekkor ugyanis a forgalomirányítókat vehetik igénybe ahhoz, hogy egyik VLAN-ról áthelyezzék
a másikra a csomag okat.
Három inter- VLAN forgalomirányítási módszert különböztetünk meg:

• hagyományos: minden VLAN külön hálózatra vagy alhálózatra kerül, a forgalomirányítóhoz
pedig annyi access módú vonal csatlakozik, ahány VLAN -unk van. Minden VLAN saját,
teljesértékű forgalomirányítót kap - ez a megoldás sajnos egyszerű, de elég költséges
• Router-on-a-Stick: az összes VLAN egyetlen trunk módú vonalon csatlakozik a forgalomirányítóhoz,
a forgalomirányítón pedig aktiváljuk a Dot1Q keret formátum beágyazásainak felismerését,
melyek révén a használatba vett fizikai interfész (fizikai)t logikai alinterfészekre bontjuk,
melyek mind különböző hálózatokba, alhálózatokba tartozó IP címeket kaphatnak. Ekkor
ugyan csak egy fizikai csatlakozót vettünk igénybe, azon minden VLAN a saját alhálózata
átjáróját látja
• L3 kapcsoló - a korábban is emlegetett L3-as kapcsolók képesek arra, hogy logikai átjárókat
definiáljanak a VLAN-ok számára, ekkor a trunk módú vonalakon keresztül érkező keretek
mindegyike a saját átjárójaként érzékeli az L3 kapcsolót, mely képes mozgatni is a kereteket a
VLAN-ok között. Az L3 kapcsolót gyakran szokták kombinálni a hagyományos forgalomirányítókkal,
hogy levegyék az inter-VLAN forgalomirányítás terhét a klasszikus forgalomirányítókról

A fentiekből is sejthetjük, hogy a rétegek és szabványok első definiálása óta jelentősen átalakult
egyes fogalmak jelentése, gyakorlati megvalósítása, ez alól pedig nem képez kivételt maga a
vonal, az átviteli közeg sem. Elég ha csak a régi betárcsázós internetet tekintjük példaként - a
kommunikáló csomópontok lényegében direkt kapcsolatot érzékeltek, holott a vonal, az összekötő
közeg valójában a komplett telefonhálózat volt!
Ahhoz, hogy a kommunikáció ilyen komplex közegeken át is hibátlanul működjön, kifejezetten
az ilyen esetekre kidolgozott, egyedi megoldásokat, keret formátumot használó protokollokra van
szükség. Ilyen a multiprotokoll címkekapcsolás (MPLS) is, egy csomagkapcsolt, virtualizált
vonalakra épülő hálózati modell, melynek eredeti célja mindössze annyi volt, hogy az IP cím helyett
egy kötött hosszúságú címke alapján címezze meg a kommunikációban résztvevő csomópontokat,
6.9 Vonal virtualizáció, MPLS 149
router
1 7 9 15
2 8 10 16
… …
Szoftverfejlesztés Irinyi épület

(1-8 VLAN port) (9-15 VLAN port)
6.23: Port alapú VLAN-ok1
1 7 9 15 1 3 5 7
2 8 10 16 2 4 6 8
… …
Szoftverfejlesztés Irinyi épület A 2,3,5 portok az SZF VLAN-hoz tartoznak

(1-8 VLAN port) (9-15 VLAN port) A 4,6,7,8, portok az IR VLAN-hoz tartoznak
6.24: VLAN modell az Informatika Kar épületei között1
ezáltal pedig jelentős teljesítménybeli gyorsulást eredményezhessen gyorsabb keresésekkel, de a

kompatibilitás érdekében saját keretébe beágyazta az IP datagramot is. Bár az IP címek leváltásában
végül nem aratott sikert, az MPLS számos esetben bizonyulhat igen hatékony megoldásnak,
amennyiben a kommunikáló feleket összekötő forgalomirányítók képesek az MPLS címkéket
is értelmezni a hagyományos IP-k mellett. Az ilyen típusú forgalomirányítók összefoglaló neve a
címke-kapcsolt router,
Fontos A címke-kapcsolt forgalomirányítók úgy képesek továbbítani a kereteket, hogy

pusztán az MPLS címkét és az ezekhez kapcsolódó MPLS irányítótáblák információit veszik
figyelembe, az IP feldolgozásával nem foglalkoznak. Az MPLS kulcsa a rugalmasság, a forrás
és a cél alapján más-más útvonal kerülhet kiválasztásra. Hálózati hibák esetére az MPLS előre
kiszámítja a tartalék útvonalakat, ezt az elvet nevezzük gyors átirányításnak.
Az MPLS hierarchiába tartozó forgalomirányítók szerepe eltér annak függvényében, hogy azok
az MPLS aktív részén peremén vagy azon belül helyezkednek el. A keretekbe ágyazott címke verem
a klasszikus verem adatstruktúrához hasonlóan működik - az MPLS router leveszi a legfelsőt, elemzi
azt a címke alapú forgalomirányító tábla szerint, majd a meghatározott szabály szerint továbbítja
típus
előtag cél forrás

adat CRC
cím cím 802.1 keret
típus
cél forrás
előtag
cím cím adat CRC 802.1Q keret
2-bájtos Címke Protokoll Azonosító

Átszámított
(értéke: 81-00)
CRC
Címke Vezérlés Információ (12 bites VLAN ID mező,

3 bites prioritás mező, IP TOS-hoz hasonló)
6.25: VLAN keret felépítése1
PPP vagy Ethernet

MPLS fejléc IP fejléc az adatkapcsolati réteg többi része
fejléc
címke Exp S TTL
20 3 1 5
6.26: MPLS keret beágyazás1
a megfelelő irányba úgy, hogy általában továbbítás előtt egy új címkét helyez el a verem tetején.
Az MPLS peremén elhelyezkedő routerek feladata az első címke elhelyezése, illetve távozáskor
az utolsó címke eltávolítása. A címkék mozgatását az MPLS forgalomirányítók az az LDP -
címke elosztó protokoll által meghatározott elvek alapján végzik. Az MPLS forgalomirányítók,
amennyiben nem áll rendelkezésükre címke a veremben, vagy érvényes bejegyzés, képesek az IP
alapú forgalomirányító tábla bejegyzéseihez is fordulni.
Fontos A [6.26] ábrán látható módon egy csomag MPLS fejlécébe egy vagy több MPLS
címke kerülhet beágyazásra, melyeket az MPLS forgalomirányításra is képes routerek értelmeznek.
A címkéket tartalmazó rész a címke verem, melyben minden bejegyzés egy 20 bites címke
részből, egy 3 bites Forgalmi Osztály és Explicit Torlódási Jelzés mezőből, egy 1 bites
veremfenék jelzőből (mely akkor kerül beállításra, ha az adott címke az utolsó a veremben) és
egy 8 bites TTL mezőből áll.
A legnagyobb előnye, hogy míg IP alapú forgalomirányításnál a forgalomirányítók tisztán

a célpont címe alapján számítják ki az útvonalat, addig az MPLS képes a forrást, a célpontot,
valamint az egyes útvonalak terheltségét is figyelembe venni a megfelelő útvonal kijelölésénél, mely
lényegesen nagyobb kontrollt és tervezést tesz lehetővé a hálózat forgalmát illetően. Hátránya,
hogy az MPLS hatékony kiépítése és használata érdekében a hagyományos IP alapú protokollok
kiterjesztett változatait kell alkalmazni a hálózaton, hogy az IP protokollra vonatkozó információk
mellett (hiszen nem várhatjuk el, hogy minden áthaladó keret MPLS címkéket tartalmazzon) az
6.9 Vonal virtualizáció, MPLS 151
bemenő forg. ir. (R4) más MPLS utakat használhat A-

hoz, pl.: forráscím alapon
R6
D
R4 R3
R5
R2
6.27: MPLS és IP alapú forgalomirányítás egy hálózaton belül1
MPLS protokollra vonatkozóakat is terjesszék. A linkek, vonalak állapotát jelző OSPF és IS-IS
protokollok kiegészíthetőek ezzel az információval, a szállítási rétegbeli RSVP esetében viszont egy
speciális RSVP-TE protokollra van szükség annak érdekében, hogy az erőforrások lefoglalásakor
az MPLS információk is átvitelre kerülhessenek. Az MPLS kapcsán fontos még megemlíteni egy
másik fontos felhasználási módjukat is: segítségükkel megvalósíthatóak virtuális magánhálózatok
(VPN), az ISP ugyanis képes az MPLS címkéi révén izolálni és címezni egy adott felhasználó
virtuális magánhálózatát az ISP-t használó többi felhasználótól. Az MPLS egy lényeges, igen
gyakran alkalmazott technológia a TE (Traffic Engineering) igényekkel bíró hálózatokon, egy igen
jó áttekintést ad róla ez a könyv [1]
címke címke
be ki cél interfész
10 A 0 címke címke
12 D 0 be ki cél interfész
8 A 1 10 6 A 1
12 9 D 0
R6
0 0
D
1 1
R4 R3
R5
0 0
A
R2 címke címke
R1
be ki cél interfész
címke címke
be ki cél interfész 6 - A 0
8 6 A 0
6.28: MPLS forgalomirányító tábla minták1


Mivel a virtualizált hálózatokkal és közegekkel kellő mélységig bejárhattuk az adatkapcsolati réteg
gyakorlati megvalósításait és bővítéseit, ideje rátérnünk néhány speciális esetre, mint például a
nagy adatközpontokon belüli kihívásokra. Adatközpontok alatt természetesen az olyan cégek,
mint a Google, Facebook, Amazon, Microsoft, stb. szerverközpontjait értjük, melyek alaphangon
tízezer, de inkább több százezer szerver t kötnek össze egy-egy ilyen központban. Az alkalmazások,
amelyek ezeken a szerver eken futnak, minden esetben nagyszámú kérést kell, hogy kiszolgáljanak,
az ugyanazon funkciót ellátó szerverek között pedig megfelelően kell elosztaniuk a terhelést is,
hogy se üresjáratok, se túlterhelések, szűk keresztmetszetek (bottleneck), legfőképp pedig ebből
fakadó teljesítménybeli problémák ne keletkezhessenek.
6.29: A Microsoft Chicago-i adatközpontja1
Felépítésüket tekintve az adatközpontban található szervereket bladeknek, avagy pengéknek

nevezzük, és első pillantásra leginkább vaskos pizzásdobozokra vagy kilapított gépházakra emlékeztetnek,
a központon belül pedig egymás tetejére, rackekbe vagy másnéven szerver rendezőkbe kerülnek
elhelyezésre. Minden egyes rack rendelkezik egy úgynevezett TOR vagyis Top-Of-Rack kapcsolóval,
mely lehetővé teszi, hogy az azonos rackbe tartozó blade-ek kommunikálhassanak egymással
és a többi rackkel. A TOR kapcsolók felett több rétegnyi, hierarchikusan felépített kapcsoló
réteg működhet - a TOR felett közvetlenül a 2-es szintű, azaz Tier 2-es forgalomirányítók,
melyeket a terheléselosztókkal együttműködő Tier 1-esek fognak össze, felettük helyezkednek
el a határ-forgalomirányítók, melyek az adatközponton belüli világot kötik össze egy külső
hálózattal, jellemzően a nyilvános internettel. A rendezőszekrények és a forgalomirányítók között
sok redundáns összeköttetést építenek ki annak érdekében, hogy a rendszer robosztusabb legyen,
a több lehetséges útvonalnak köszönhetően pedig magasabb sebességet érhessenek el a rendezők
közötti kommunikációs folyamatok.
Az adatközpontok jellemzően több terheléselosztóval rendelkeznek, melyek feladata a kérések
hatékony elosztása a központon belüli szerverek közt, valamint alapszintű NAT-olás: a külvilágból
ne is sejthessék az adatközpont belső felépítését. A kérés kiszolgálását végző szerver is szigorúan
a terheléselosztón keresztül küldi a választ, így a pontos identitását nem lehet megállapítani az
adatközpontból. Mivel a hatékony elosztásban kulcsfontosságú szerepe van a kérések pontos
típusának, a terheléselosztó logikát magát jellemzően az alkalmazás rétegben implementálják.
Az adatközpontok világa természetesen folyamatosan fejlődik és felépítésében, strukturálásában
újabb és újabb trendek jelennek meg. Ilyen például az úgynevezett teljesen összekapcsolt
topológia. Ennek lényege, hogy az elosztott hierarchia helyett az adatközponton belül minden
6.11 Egy webkérés életútja 153
Internet
Terheléselosztó
Határ forg. ir. Terheléselosztó
Hozzáférés forg. ir.
Tier-1 kapcsolók
B
A C Tier-2 kapcsolók
TOR kapcsolók
Szerver rack szkrények
4 5 6 7 8
6.30: Adatközponton belüli infrastruktúra1
felsőbb szintű kapcsoló csatlakozik az összes, hierarchiában alatta elhelyezkedő kapcsolóhoz,

kivéve a TOR kapcsolókat, melyek továbbra is exkluzívan egy-egy alacsony rangú kapcsolóhoz
tartoznak. Ez a modell, bár kialakítása némileg költségesebb, lényegesen nagyobb kommunikációs
kapacitást tesz lehetővé az adatközpontban. Hasonló új trend a konténer alapú moduláris adatközpontok
használata - egy-egy egyedi rack helyett komplett mini-adatközpontokat vásárolnak és kötnek
be az adatközpontba, melyek több ezer hostot tartalmaznak, a modul későbbi elavulása vagy
meghibásodása esetén pedig nem csak egy-egy hostot, hanem a komplett modult cserélik.

Mielőtt rátérnénk a jóval komplexebb megoldásokat igénylő vezetékmentes átviteli közegekre,
foglaljuk össze az eddig tanultakat. Vázoljuk fel egy html oldal betöltését azzal a lépéssel indítva,
hogy bekapcsoltuk a gépünket.
6.11.1 IP cím szerzése

A bekapcsolást követően a gépünk természetesen még nem rendelkezik IP címmel - ekkor az
első lépés természetesen ennek megszerzése lesz. A DHCP szerver jellemzően a helyi hálózatok
alapértelmezett átjárójaként üzemelő routeren belül helyezkedik el. A gépünk a bekapcsolást
követően generál egy DHCP kérést, majd azt beágyazza egy UDP szegmensbe (a DHCP protokoll
szerinti 67-es portot célozva), mely egy IP datagramba kerül (mintha csak egy matrjoska babát
építenénk), mely az IP címek hiányában a forrás címeként a 0.0.0.0-át, célként pedig a 255.255.255.255-ös
szórási címet írja be. Az IP datagram egy Ethernet keretbe kerül, melynek forrás MAC-címe a
saját gépünk hálózati interfész (fizikai)ének MAC-címe lesz, míg a célpont helyére a szórásos
FF-FF-FF-FF-FF-FF cím kerül. Az Ethernet keret elküldésre kerül, majd ahogy eléri a helyi
hálózatunk kapcsolóját, az szétküldi a helyi hálózat összes csomópontjára, beleértve a routernek.
A router, miután megkapta a keretet, rétegenként kibontja azt, a routeren futó DHCP szerver
így az UDP csomag feldolgozását követően megkapja a neki szóló kérést. Tegyük fel, hogy a
DHCP szerver képes bármelyik IP címet allokálni a CIDR tömbből. Ekkor a szerver például
kiosztja számunkra a 68.80.2.15/24-es címet egy DHCP ACK válasz csomagban, amelyben
már megadja a saját IP címét is forrásként (68.80.2.100), valamint olyan, a helyi hálózatra
böngésző DNS szerver

Comcast hálózata
68.80.0.0/13
egyetemi hálózat
68.80.2.0/24
weboldal
webszerver Google hálózata

64.233.169.105 64.233.160.0/19
6.31: A webkérés életútja során bejárt teljes modell1
vonatkozó alapinformációkat, mint az alapértelmezett átjáró címe (68.80.2.1), a DNS szerver címe
(68.80.0.120) és a CIDR blokk címét, vagyis más néven az alhálózati maszkot is. A DHCP ACK egy
UDP keretbe kerül, az egy IP datagramba, az pedig egy Ethernet keret be, mely azonban ekkor már
szórásos címek helyett egyértelműen rendelkezik a két kommunikáló fél MAC-címeivel. A DHCP
ACK előbb a kapcsolóhoz kerül amely, mivel öntanuló és a gépünk eredeti, szórásos üzenete alapján
eltárolta a MAC-címünket, felismeri, hogy melyik csatlakozóján kell azt továbbítania. Miután a
kapcsoló továbbítja gépünkre a keretet, a gépünk kiolvassa belőle a DHCP ACK csomagot, és
annak tartalma alapján konfigurálja a hálózati paramétereit.
DHCP DHCP
DHCP UDP
DHCP IP
DHCP Eth
Phy
DHCP
DHCP DHCP
DHCP
UDP
DHCP
IP
DHCP
Eth forgalomirányító
(DHCP-t futtat)
Phy
6.32: DHCP protokoll alapú IP cím szerzés1

6.11 Egy webkérés életútja 155
6.11.2 Alapértelmezett átjáró MAC címének kiderítése

Tegyük fel, hogy újdonsült hozzáférésünk révén indítottunk egy böngészőt, és ekkor nagy valószínűséggel
megindul az alapértelmezett kezdőoldal, például a Google betöltése. Vagyis indulna - ha a
gépünk tudná, hogy a google.com milyen IP címet takar, márpedig egy ennyire friss indítás esetén
feltételezhetjük, hogy a helyi DNS gyorsítótár bizony meglehetősen kong az ürességtől. Ezért
előbb összeállításra kerül egy DNS kérés, mely egy, a célpont 53-as portját célzó UDP szegmensbe
kerül, majd egy IP datagramba, melynek forrása immár újdonsült IP címünk, a 68.80.2.15 lesz,
míg a célpont a DHCP ACK csomagban kapott 68.80.0.120, vagyis a DNS szerver címe lesz.
Mivel a DNS szerver láthatóan egy külső hálózaton helyezkedik el, a kommunikáció a hálózatunk
átjáróján keresztül fog zajlani, ehhez azonban előbb meg kell szereznünk annak MAC-címét. Az
adatkapcsolati réteg így a küldésre kész Ethernet csomag elindítását megelőzően még összeállít egy
felderítő ARP csomag ot, benne célpontként az alapértelmezett átjáró IP címével (68.80.2.1), és
kiküldi azt a szórásos MAC-címre. Amikor a router megkapja ezt a csomagot, érzékeli, hogy az
ARP csomag célpontja megegyezik a saját IP címével az interfész (fizikai)én, amelyikre a keret
érkezett, így összeállítja az ARP választ, benne a saját MAC-címével forrásként. Miután a gépünk
megkapta ezt az ARP választ, véglegesíti a DNS kérést tartalmazó Ethernet keretet és megindítja
azt az átjáró felé.
DNS
DNS UDP DNS szerver
DNS IP
DNS DNS DNS Eth
DNS UDP DNS Phy
DNS IP
DNS Eth
Phy
DNS
Comcast hálózat
68.80.0.0/13
forgalomirányító
(DHCP-t futtat)
6.33: DNS kérés futtatása1
6.11.3 Forgalomirányítás a szerver felé

A router megkapja az Ethernet keretet és az IP cím alapján felderíti, hogy merre kell továbbküldenie
a csomagot. Az IP datagramot újracsomagolja egy Ethernet keretbe, amely a DNS szerver hálózata
felé irányul, és továbbküldi. Tegyük fel, hogy a keret szerencsésen megérkezik a DNS szervert is
tartalmazó hálózat routeréhez, mely az IP cím kiolvasását követően felismeri, hogy a címzett a saját
hálózatán van és továbbítja azt. A DNS kérés így végül megérkezik a DNS szerverre, mely kiolvassa
belőle a szükséges paramétereket és elkezdi keresni a saját táblázatában a google.com-hoz tartozó
bejegyzést. Ha a cachében megtalálta (ez egy olyan gyakran felkeresett domain esetében, mint a
Google, elég valószínű), összeállítja a DNS választ, benne a hostnév - IP cím leképezéssel, majd
UDP, IP, végül Ethernet keretbe foglalva elindítja azt vissza a gépünkhöz. Ha a forgalomirányítást
követően a gépünk megkapta ezt a választ, végre tudni fogja, hogyan vegye fel a kapcsolatot a
Google oldalait kiszolgáló szerverrel.
6.11.4 Kliens-szerver kapcsolat

Az információk birtokában a gépünk végre elkezdheti a TCP socket építését, melyen keresztül
lebonyolíthatja majd az oldal betöltéséhez szükséges HTTP forgalmat. A kiépítés természetesen a
három lépéses kézfogással fog indulni - a gépünk előbb elkészíti a TCP SYN szegmenst a cél 80-as
portjára irányítva (a HTTP kéréseket a 80-as port szolgálja ki, így ehhez kell kiépítenünk a socketet
is), ezt belehelyezi egy IP datagramba, melynek címzettje a DNS szerver válaszából kapott Google
IP cím lesz, ez egy Ethernet keretbe kerül, melyben a célpont MAC-cím az alapértelmezett átjárónk
címe. A routerek a forgalomirányítási szabályok alapján ezt a keretet eljuttatják a google.com-ot
kiszolgáló szerverre, amely a csomag értelmezését követően válaszol egy TCP SYNACK csomaggal,
benne a socket kiépítésének elfogadott paramétereivel, majd visszaküldi azt a gépünknek. Miután a
gépünk egy TCP ACK csomaggal válaszol, végre minden kész a google.com lekérésére, mely meg
is történik egy HTTP GET kérés formájában, mely a kiépített TCP socketen keresztül ér célba. A
google.com-ot kiszolgáló szerver HTTP választ állít elő, 200-as státuszkóddal, melyben elhelyezi a
google.com html kódját is, és a socketen keresztül ezt visszaküldi. Miután a gépünk megkapta ezt a
választ, a böngészőben megjelenik a Google kezdőoldala.
HTTP
HTTP HTTP
HTTP
HTTP TCP
HTTP
HTTP IP
HTTP
HTTP Eth
Phy
forgalomirányító
HTTP HTTP (DHCP-t futtat)
HTTP TCP
HTTP
IP
HTTP Eth
Phy
webszerver
64.233.169.105
6.34: Weboldal betöltése1
Elég hosszadalmas folyamat, ugye? Gondoljatok csak bele, ez a másodperc töredéke alatt
szokott lezajlani - sőt, bármennyire is hangzik nevetségesen, a fenti folyamat még mindig egy
borzalmasan optimista és leegyszerűsített folyamat volt: nem foglalkoztunk biztonsággal, hitelesítéssel,
titkosítással, gyorsítótárazással, nem vettük számításba azt az esetet sem, ha a kért domain IP címe
nem szerepel a DNS szerver cachében! Sőt, még ha bele is vettük volna a folyamatba, még mindig
nem kaptunk volna teljes képet - a modell további bonyolításához ugyanis bőven elegendő, ha a
gépünk esetleg kábel helyett vezetékmentes hálózatra kapcsolódik - vagy klasszikus asztali gép
helyett laptopról vagy okostelefonról próbálkozunk az oldalbetöltéssel.

Ideje áttérnünk egy elég méretes alfejezetre, a vezetékes hálózatok témakörére. A méretes
kifejezés itt nem túlzás, elég sok elméletről van szó, amelyek ráadásul egyre jelentősebbé és
fontosabbá válnak a hálózatok világában - elég csak figyelembe venni, hogy a vezetékmentes
6.12 Vezetékmentes hálózatok 157
mobilfelhasználók száma milyen mértékben haladja meg a klasszikus, vezetékes telefonelőfizetőket,

illetve a vezetékmentes internethasználó eszközök a vezetékesek számát. A fejezet során két fontos
témakörrel fogunk megismerkedni:
• a vezetékmentes infrastruktúrák felépítése és működése
• a mobilitás problémaköre, azaz az olyan esetek kezelése, amikor egy eszköz a szolgáltatás
megszakadása nélkül át kell hogy kerüljön egyik vezetékmentes hálózatól a másikba
Első körben ismerkedjünk meg, pontosan milyen elemeket különböztetünk meg a vezetékmentes
topológiában betöltött szerepük alapján.
Fontos A vezetékmentes topológia alján helyezkednek el a vezetékmentes állomások -

ezek alatt értjük a laptopokat, okostelefonokat, WiFi-re csatlakozó asztali gépeket, amelyek
hálózati igényekkel rendelkező alkalmazásokat futtatnak. Ezek kapcsolódnak a vezetékmentes
vonalon keresztül a bázisállomásokra, amelyek az átjátszó szerepét töltik be a vezetékes és
vezetékmentes közegek között.
A vonal többszörös hozzáférésű közeg, melynek elérését a “Többszörös hozzáférésű protokollok”

fejezetben látott módszerek segítségével szabályozzák. A vezetékmentes közeg jellemzésekor két
fontos tulajdonságot emelünk ki: a hatótávolságot, vagyis a bázisállomástól számított maximális
távolságot, amíg egy eszköz még csatlakozhat, illetve a Mbps-ben számolt adatátviteli sebességet.
A vezetékmentes hálózatokat definiáló szabványok, mint például az IEEE 802.11 családja jellemzően
definiálják ezt a két tulajdonságot is. A résztvevők számától és viszonyuktól függően két jelentősebb
módot különböztetünk meg a vezetéknélküli topológiák szervezésére: az infrastruktúra módban
jelen van a fent felsorolt összes elem, az állomások a bázisállomáson keresztül csatlakoznak a
hálózatra, az egyes eszközök pedig a mobilitásuk függvényében képesek akár a bázisállomás
váltására is. Az ad hoc mód esetén viszont nincs bázisállomás, a vezetékmentes állomások
viszonylag kis hatótávolságon belül kapcsolódnak egymáshoz, az elérési útvonalak detektálásáról,
feltérképezéséről pedig maguk gondoskodnak. Ha a vezetékmentes állomás hordozható is, előfordulhat,
hogy egyik hálózattípusról a másikra vált, vagy bázisállomást kell cserélnie - az utóbbi eseményt
nevezzük átadásnak (handoff), magát a problémakört pedig a mobilitással kapcsolatos kihívásoknak.
Ennek a két kategóriának további két-két alkategóriáját különböztetjük meg annak függvényében,
hogy pontosan hogyan kapcsolódnak a külső hálózathoz. Az egyugrásos infrastruktúra hálózatokban
a bázisállomás közvetlenül csatlakozik az internethez, így elegendő mindössze egyetlen ugrás
bármely állomásról a vezetékmentes közegen keresztül a bázisállomásra, és a keretek máris a
nyilvános hálózatra kerülhetnek. Egyugrásos adhoc hálózatról beszélünk olyan esetben, amikor
egy hálózat valamilyen kitüntetett erőforrással rendelkezik, és ugyan nem a bázisállomás szerepét
tölti be az eszközök között, koordinálja a többi eszközt. A többugrásos infrastruktúra esetén a
bázisállomás egy nagyobb hálózat részét képezi, így miután elhagyta a vezetékmentes közeget,
a keretnek még több kapcsolón és forgalomirányítón kell átjutnia, mire a nyilvános internetre
kerülne. A többugrásos adhoc hasonló, nincs bázisállomás, ám egy-egy keretnek több relén kell
keresztüljutnia, mire a nyilvános hálózatba érne, amennyiben az állomások mobilisak, akkor ezeket
szokás emlegetni mobile ad hoc network (MANET), ha ezen belül konkrétan járművek, akkor
pedig vehicular ad hoc network (VANET) néven.
6.12.1 Vezetékmentes vonalak

A vezetékes vonal, mint átviteli közeg számos területen eltér vezetékes megfelelőjéhez képest.
• a rádiójelek erőssége csökken a bázisállomástól távolodva, illetve különböző közegeken
áthaladva
hálózati
infrastruktúra
6.35: Vezetékmentes hálózati infrastruktúra1
• számos forrásból származó zaj szennyezheti a közegen áthaladó jeleket, amelyek interferenciához
vezethetnek - például ugyanaz a frekvenciasáv más eszközök között is meg van osztva
• bizonyos jelek konkrétan visszaverődhetnek egyes fizikai közegekről (ezt többutas terjedésnek
is nevezzük), mely a célbaérésig akár jelentős késleltetés formájában is jelentkezhet
A fenti elemek figyelembevételével definiálunk egy igen jelentős attribútumot a csomópontokon,

ez lesz a signal-noise ratio (SNR) vagyis a jel-zaj arány.
Fontos Az SNR arány minél nagyobb, annál könnyebb az értékes jeleket megkülönböztetni a
vezetékmentes közeget szennyező zajtól, mértékegysége jellemzően a decibel (dB). Az SNR-t

általában a bit-error ratio (BER), vagyis az adott közegen a bitenkénti hibák arányával szokták
összevetni.
Az ilyen összehasonlítások segítségével az alábbi tényeket sikerült megállapítani a két metrika
viszonyáról:
• Ha a fizikai közeg adott, vagyis fix tulajdonságokkal rendelkezik, akkor minél jobban növeljük
az adó teljesítményét, annál nagyobb lesz az SNR és kisebb a BER érték.
• Ha az SNR érték konstans, akkor az átviteli teljesítmény növelése a BER értéket is növeli.
• Az SNR és a BER értékek is változhatnak mobilitás esetén a fizikai réteggel együtt.
A helyzetet csak tovább komplikálja, hogy a vezetékmentes közeg jellegéből adódóan olyan
ütközésekre is sor kerülhet, amelyekkel az adatkapcsolati réteggel foglalkozó korábbi részekben
még nem foglalkoztunk. Előfordulhat olyan eset például, amikor valamilyen fizikai közeg olyan
mértékű jelgyengülést okoz két eszköz között, hogy azok egészen egyszerűen nem érzékelik egymás
forgalmát (ekkor ezeket rejtett állomásoknak nevezzük), ám egy harmadik eszköz, melynek
mindketten keretet próbálnak küldeni igen, és ütközés is alakul ki nála anélkül, hogy azt bármelyik
kommunikáló fél észlelné. Hasonló jelenséget érhetünk el akkor is, ha fizikai akadály nincs, pusztán
6.12 Vezetékmentes hálózatok 159
10-1
10-2
10-3
BER
10-4
10-5
10-6
10-7
10 20 30 40
SNR(dB)
QAM256 (8 Mbps)
QAM16 (4 Mbps)
BPSK (1 Mbps)
6.36: SNR - BER metrikák viszonya1
a két potenciális adó jelerőssége gyenge, elhalványult annyira, hogy a hatótávolságuk határán
elhelyezett harmadik fél még megkapja mindkettejük kereteit, ám ők egymást, és így a közös
közeghasználat következtében létrejött ütközéseket már nem.
A B C
C
A jel C jel
erőssége
B erőssége
A
tér
6.37: Rejtett állomás és elhalványulás problémák1
Épp ezért van szükség az esetek többségében egy újfajta többszörös hozzáférési megoldásra,
amely a korábbi fejezet során futólag említett CDMA, vagyis kód alapú csatornafelosztás lesz.
Fontos CDMA felosztás során a küldő egy saját, egyedi kód szekvencia segítségével kódolja
a küldeni kívánt adatot, így amennyiben a kódoló szekvenciák nem egyeznek, ugyanabban
a közegben, ugyanazon a frekvencián, ugyanabban az időpontban küldhetnek úgy, hogy a
potenciális ütközés ellenére a keret eredeti feladója és tartalma szinte mindig visszaállítható
a kódoló szekvencia ismeretében. Ennek kulcsa, hogy minden egyes küldésre került bitet
lekódolnak a kapott kódszekvencia szorzásával (ezt szokás kenő szekvenciának is hívni a
használata miatt), mely sokkal gyorsabban váltakozik (a sebességbeli különbség a daráló
arány), mint az eredeti bitszekvencia.
Hogy ezt kicsit jobban megértsük, tegyük fel a következőt: tegyük fel, hogy az időmérésünk
alapja az idő, amely alatt az eredeti bitszekvencia egy bitje eléri a CDMA kódolót, vagyis minden
egyes bit egy bitnyi résidőt igényel. Jelöljük di-vel a bitszekvenciának azt a bitjét, amely az i.
időrésben kerül átvitelre. Továbbá képzeljük el, hogy minden időrés tovább van tagolva M darab
minirésre. A kód ekkor, amit a CDMA használ, M darab értékből áll majd. A gyakorlatban M
egy meglehetősen nagy szám, a példánkban azonban legyen M = 8 a követhetőség kedvéért, a
kenő szekvenciánk pedig 11101000. Ekkor az m-edik minislot tartalma a di bit kódolásakor Zi,m
= di*cm. A továbbiakban a matematikai számítások követhetősége érdekében a 0-kat (-1)-gyel
helyettesítjük, az új ábrázolásban így a következő a kenő szekvencia: (1,1,1,-1,1,-1,-1,-1).
Ha egy egyszerű környezetben dolgoznánk, a fogadó, miután megkapta a kódolt biteket, az
alábbi képlet segítségével már vissza is nyerhetné az eredeti bitet:
1 M
di = ∗ ∑ zi,m ∗ cm (6.5)
M m=1
A gyakorlatban viszont a fogadás és visszafejtés műveletei olyan környezetben kell, hogy

működjenek, ahol egyszerre több állomás is próbál adni és venni. Így egy adott fogadóhoz mind az
N küldő bitjeinek összege megérkezik, amelyek ugyanabban az időablakban próbáltak adni:
N
∗ s
Zi,m = ∑ Zi,m (6.6)
s=1
Ám, ha sikerült jól megválasztani a kenő szekvenciát, és azok eltérnek egymástól, a fogadó
még ebből is képes visszafejteni az eredeti jelet:
1 M ∗
di = ∗ ∑ Zi,m ∗ cm (6.7)
M m=1
A CDMA működésére a [6.38] ábrán láthattok példát.
6.12.2 PAN
Joggal merülhet fel a kérdés, hogy vajon mennyivel kevesebb problémával kellene foglalkoznunk,
és mennyivel hatékonyabbak lennének a vezetékmentes hálózataink, ha egészen egyszerűen
meghatároznánk, hogy viszonylag kicsit fizikai távolságra helyezkedhetnek el egymástól. A
Bluetooth alapján definiált IEEE 802.15-ös szabvány implementációja, a personal area network
(PAN) világába. Ennek lényege a lefoglalt frekvenciasáv és nagy teljesítmény révén elérhető nagy
bitsebesség, melynek ára az alacsony hatótáv - a lefedettség egy legfeljebb 10 méter átmérőjű
területet érint, a kommunikációt ráadásul ad hoc módon kialakított mester-szolga architektúra
menedzseli. Ez igazán komplex hálózatok kiépítésére természetesen alkalmatlan, ám kiváló a
különböző eszközök és perifériák vezetékmentes csatlakoztatásához és használatához.
6.13 WiFi 161
Zi,mcsatorna kimenet
Zi,m= di.cm
adat d0 = 1
1 1 1 1 1 1 1 1
d1 = -1
bitek -1 -1 -1 -1 -1 -1 -1 -1
küldő
1 1 1 1 1 1 1 1 1. rés 0. rés
kód csatorna csatorna
-1 -1 -1 -1 -1 -1 -1 -1
kimenet kimenet
1. rés 0. rés
M
Di = S Zi,m.cm
megkapott m=1
bemenet M
1 1 1 1 1 1 1 1
d0 = 1
-1 -1 -1 -1 -1 -1 -1 -1
d1 = -1
1 1 1 1 1 1 1 1 1. rés 0. rés
kód csatorna csatorna
-1 -1 -1 -1 -1 -1 -1 -1
vevő kimenet kimenet

1. rés 0. rés
6.38: CDMA a küldő és a fogadó oldalán1
6.13 WiFi
Most hogy megismerhettük a vezetékes hálózatok általános sajátosságait és kihívásait, ideje,
hogy szemügyre vegyük, pontosan hogy is jelennek meg ezek három széles körben használt
vezetéknélküli hálózat esetén. A hármasból az első a WiFi, vagyis az IEEE 802.11-es szabvány
által meghatározott vezetékmentes LAN. A 802.11-es szabvány valójában több különböző kisebb
szabványt ír le például 802.11a, 802.11b, melyek különböző antennaszámot, frekvenciát és
bitsebességet írhatnak le, ám kulcsfontosságú elemeik, többek közt a fenti kihívásokra adott
válaszaik és megoldásaik megegyeznek. Egy speciális CSMA/CA protokollt használnak a
közeghozzáférésre, valamint mind definiálnak infrastruktúra és ad hoc kiépítésen alapuló megvalósítást
is. A klasszikus 802.11-es szabvány például a 2.4 és 2.4835 GHz közötti frekvenciatartományban
működik, melyet 11, egymást részlegesen átfedő csatornára (két csatorna csak akkor nincs átfedésben,
ha legalább négy csatorna távolság van közöttük) oszt. A 802.11b azonos kenő szekvenciát definiál
minden állomásra. A WiFi szabványok mindegyike definiál bázis állomással és ad hoc szervezéssel
létrejött változatot is.
Fontos A WiFi elemeit cellának vagy Basic Service Set-nek (BSS) Alap Szolgáltatási
Halmaznak nevezzük. Ez infrastruktúra esetén magába foglalja a bázisállomást, amit hozzáférési
pontnak is nevezünk ( Access Point ), valamint a vezetékmentes állomásokat, amelyek a
szabvány által meghatározott módon kommunikálnak a vezetékmentes közegen keresztül.
Amennyiben az adott WiFi szabvány több lehetséges csatornafrekvenciát is engedélyez, az

hozzáférési pont adminisztrátora választhatja ki, hogy konkrétan melyiket használja a bázisállomás a
kapcsolatok kiépítéséhez. Ez a választás kulcsfontosságú a WiFi-k hatékonyságának meghatározásához,
ugyanis egy jól kiválasztott frekvencia esetén csak a lokális ütközésekkel és interferenciával kell
megküzdenünk, ám ha egy olyanra esik a választás, amelyet más, fizikailag közeli bázisállomások
is használnak, potenciálisan interferencia léphet fel a különböző hálózatok között.
Ám míg a rendszergazdáknak ilyen problémákkal kell foglalkozniuk, addig a mezei felhasználók
egy sokkal gyakoribb jelenséggel szoktak találkozni: a megfelelő WiFi megkeresésével és csatlakozásával.
P
S
P
fedettség
M átmérője
S P
S
P
M Mester eszköz
Szolga eszköz
S
Parkoló eszköz (nem aktív)
P
6.39: PAN hálózati infrastruktúra1
Ennek a jelenségnek a pontos neve társulás, a vezetéknélküli állomásoknak társulniuk kell a

Hozzáférési Pontokhoz (Access Point), hogy rácsatlakozhassanak az adott vezetékmentes hálózatra,
ennek első lépése pedig hogy információkat kell szereznie az adott hozzáférési pont létezéséről
és pontos MAC-címéről. WiFi dzsungelnek nevezzük azokat a fizikai közegeket, ahol egy
vezetékmentes állomás egyszerre több hozzáférési ponttól foghat egyforma erősségű jelet, ahol
az állomásnak egy konkrét hozzáférési ponthoz kell csatlakoznia, hogy valóban hozzáférést is
nyerhessen a hálózathoz
Fontos Annak függvényében, hogy a keresést az hozzáférési pont vagy az állomás kezdeményezi,
passzív és aktív felderítést különböztetünk meg. A passzív esetben a hozzáférési pontok
küldik meghatározott rendszerességgel a jelző kereteket, bennük az azonosításukra használható
SSID-vel és MAC-címmel, aktív esetben ezzel szemben az állomások sugároznak szonda vagy
felderítő keret eket, amelyekre a hozzáférési pontok válaszolnak az azonosításukra szolgáló
adatokkal. A csatlakozást opcionálisan megelőzheti egy azonosítási folyamat, melynek sikerét
követően az állomás kiküldheti a DHCP csomagokat az IP cím igénylésére és a hálózat részévé
válhat.
A 802.11-es szabvánnyal kapcsolatban kicsit feljebb volt róla szó, hogy egy speciális, CSMA/CA
nevű protokollt használ a közeghozzáférésre. Ennek egy nagyon gyakorlatias oka van: a WiFi-re
csatlakozó eszközök nagyon nehezen tudnak venni, amikor az adott pillanatban adnak is, így bár az
adás előtt belehallgathatnak a csatornába, az ütközéseket már nem képesek hatékonyan detektálni,
nem is beszélve az olyan esetekről, amikor a vezetékmentes hálózatok általános jellemzésénél is
felsorolt speciális körülmények révén egyáltalán nem is értesülhetünk az ütközésekről.
6.13 WiFi 163
BBS 1 BBS 2 BBS 1 BBS 2
1
1 1 2 2 AP 2
AP 1 AP 2 AP 1
2 3
3 4
H1 H1
6.40: WiFi társulási folyamat aktív és passzív kereséssel1
Fontos Ütközésdetektálás helyett (CD) a WiFi esetén ütközéselkerülést (CA) alkalmazunk.

Ennek működési alapja két meghatározott időintervallum az elosztott DIFS és a rövid SIFS.
A DIFS azt az időtartamot jelöli, ameddig a küldeni szándékozó csomópont várakozik a küldés
megkezdése előtt. Ha a DIFS időtartamon belül bármelyik másik csomópont elkezd adni a közegben,
azonnal visszalép, és egy véletlen időtartamú várakozást követően kezd csak ismét hallgatózni. Az
üres DIFS időtartamot követően kezd adni, mire a célpont a keret megérkezését követően hasonlóan
SIFS időtartamig hallgatózik mielőtt egy ACK keretben visszajelezne a csomag sikeres sikeres
célbaéréséről. Ha a küldő nem kap ACK-t, feltételezi az észrevétlen ütközést rejtett állomás vagy
jelgyengeség miatt, megnövelt visszalépési időtartammal ismét várakozni kezd, majd újrapróbálja
a küldési folyamatot.
Ugyan ez optimálisnak tűnhet, valójában felvet egy, a MAC-protokollok vizsgálata során
gyakran felbukkant problémát - a küldésre készülő félnek akkor is ki kell várnia a DIFS időtartamot,
ha közben senki sem készül adni, ha pedig két csomóponton pont egyszerre jár le a DIFS, az
illedelmes várakozás ellenére is ütközhetnek. Emiatt született meg az ötlet a módszer javítására,
amit RTS-CTS módszerként ismernek. Ennek lényege, hogy az adó a folyamat indítása előtt
egy aprócska request-to-send csomagot küld a bázisállomásnak, mely ekkor kiküld egy szórásos
ugyanúgy apró clear-to-send csomag ot az állomásoknak, melyben jelzi, hogy a közeget lefoglalták,
minden más küldeni szándékozó csomópont lépjen vissza. Az adó ezután ütközés veszélye nélkül
küldheti a keretét, a foglaló csomagok apró méretéből fakadóan pedig a módszer nem is növeli
túlságosan a folyamat költségeit.
Nézzünk egy példát, hogy is működik ez a gyakorlatban:
1. A és B is adni szeretnének, A azonban egy kicsit korábban kezdte meg a folyamatot és a
DIFS időtartam kivárását
2. A elküldi a BS-nek az RTS csomagot
3. BS megkapja az RTS csomagot és kiküldi a CTS-t minden állomásnak
4. B erre visszalép és várakozik, A elküldi a csomagot C-nek
5. C SIFS idő elteltével elküldi az ACK-t A-nak
6. ha a csatorna tiszta és a DIFS lejárt, B ismét megkísérli az RTS küldését BS-nek
Méltán merülhet fel ezen a ponton, hogy ha a WiFi esetén ennyi különleges opcióval és elemmel
kell számolnunk, mégis mennyire lehet bonyolult az általa definiált keret? Szerencsére a helyzet
közel sem vészes
A keret kezdetén egy kétbájtos vezérlő rész áll, amely a keret típusáról, protokolljáról, általános
céljáról tartalmaz információkat - 2 bit a protokoll verzió, 2 a protokoll típus, 4 a protokoll altípus
számára, 1-1 flag jelzi, hogy a csomag a hozzáférési ponthoz vagy hozzáférési ponttól érkezik,
majd ezt további 1 bites flagek sora követi, mint az újrapróbálkozást vagy több részben érkező
keret szekvencia #
a foglalt adás ideje (RTS/CTS)
(az RDT-hez)
2 2 6 6 6 2 6 0 - 2312 4
keret szekv 4. cím
időtartam 1. cím 2. cím 3. cím adat CRC
vezérlés vezérlés
2 2 4 1 1 1 1 1 1 1 1
Protokol További Teljes. Több
Típus Altípus AP-hez AP-től Újrapr. WEP Rsvd
verzió frag. mgmt adat
kerettípus
(RTS, CTS, ACK, adat)
6.41: WiFi keret formátum1
adatot jelölő mező. Ezt a vezérlő részt követi szintén két bájtban az időtartamot leíró rész, mely
meghatározza a foglalt adás idejét az RTS-CTS módszer révén. Ezt három egymást követő hatbájtos
cím mező követi, melyek közül az első a cím, a második a forrás, a harmadik pedig a hozzáférési
ponthoz csatlakozó forgalomirányító címe. A kétbájtos szekvenciavezérlő mezőt követő negyedik
címet kizárólag ad hoc megvalósítás esetén veszik igénybe. A negyedik cím után következik a
maximum 2312 bájt terjedelmű opcionális adat vagy payload mező, majd a 4 bájtos CRC ellenőrző
összeg zárja.
Még mielőtt esetleg úgy tűnne, hogy a WiFi és a vezetékmentes világ csak és kizárólag
kihívásokat és megoldandó problémákat vet fel a mérnökök számára, fontos kitérnünk azokra
az erősségekre, amelyekkel más megoldásokkal szemben rendelkezik: a WiFi komoly öntanuló
képességekkel rendelkezik
• ha egy állomás például változatlan alhálózathoz próbál csatlakozni változatlan IP címmel,
viszont más hozzáférési ponton keresztül, képes újrabeazonosítani azt, amint megpróbál adni
• az SNR változásának függvényében automatikusan képes állítani a bázis és az állomás közötti
átvitel sebességét a BER minimalizálásnak érdekében
• képes a csatlakozott csomópontok teljesítményét is optimalizálni
A csomópontok optimalizálása a következő módon zajlik - amennyiben egy darabig nincs
kommunikáció a csomópont és a bázis között, a csomópont jelezhet, hogy a bázis következő
felderítést szolgáló jelzőkereteinek kiküldéséig nem fogad adást, majd a jelzőkeret észlelésére
felébred, és ekkor fogadja az időközben felgyülemlett beérkező csomópontokat is. Ez mobil
eszközök esetén, mivel az energiatakarékosság itt kiemelten fontos, nem elhanyagolható előny.
6.13.1 WiFi hálózatok biztonsága

A WiFi nem áll meg a falnál. Ellentétben a vezetékes hálózatokkal (pl.: Ethernet ) itt nem
volt megkerülhető a biztonsági képességeknek megfelelő szempontok befoglalása a protokollba.
Erre szolgál a WiFi WEP (Vezetékessel Egyenértékű Biztonság - Wired Equivalent Privacy)
kiterjesztése. Alapvető képességei:
• azonosítás: a hozzáférési pont azonosítani tudja a klienst megosztott titok (általában jelszó)
segítségével
6.13 WiFi 165
• titkosítás: mivel egyes keretek elveszhetnek azért a folyam alapú titkosítás magában nem
alkalmazható, majd látni fogjuk, hogy egyedi kulccsal titkosít minden keretet
• tartalomvédelem: CRC van hozzácsapva
Az azonosítás csak közös titkon alapulhat, nincs felhasználó kezelés (ma már van de nem
itt hanem a 802.11i-ben). A kilens jelzi, hogy azonosítani szeretné magát. A szerver átküld egy
szöveget (véletlen számot) ezt a kliens a közös titokból készült szimmetrikus kulccsal titkosítja.
A szerver ezt ugyanazzal a kulccsal visszafejti. ha egyezik azzal amit átküldött akkor beengedi a
klienst. Ez a megoldás ma már számos problémát vet fel (nincs felhazsnáló kezelés, egy közös titok
mindenkinek, a kliens nem azonosítja a szervert, visszajátszásos támadás ellen sem védett...), ezért
a 802.11i protokollt érdemes alkalmazni.
Fontos A titkosításnak robosztus csomagvesztést tűrő megoldásnak kell lennie. A közös
kulcs nem feltétlenül erős ezért azt minél ritkábban érdemes használni. A WEP minden egyes
keretet más kulccsal titkosít. A kulcs sorozatok leegyeztetés nincs benne a protokollba ehelyett
mindkét oldal azonos algoritmussal készíti a kulcs sorozatot. Annak érdekében, hogy ne lehessen
kitalálni a következő kulcsot egy álvéletlen generátort használnak megfelelő inicializációs
vektorral (IV).
IV
IV(keretenként)
(per frame)
KK – :40104-bit
s S
bites keysorozat
Kulcs sequence generator
generátor
secret
szimmetrikus ( for given KS, IV)
symmetric
k1IV k2IV k3IV … kNIV kN+1IV… kN+1IV 802.11
802.11 WEP-encrypted
WEP data
titkosítású adat
key fejléc IV
plaintext
Szabad header és CRC plus ICV
szöveges adat
&
ésframe
CRC data d1 d2 d3 … dN CRC1 … CRC4
plus CRC
c1 c2 c3 … cN cN+1 … cN+4
új IV7.8-new1:
Figure minden keretre
802.11 WEP protocol
6.42: WEP titkosítás1
A közös kulcs 40 bites, ezt egészíti ki minden egyes kertre egy 24 bites IV bitsorozat. Ez az
IV minden kerethez hozzá van csapva és minden keretnél más (ez nem biztos, ez a sérülékeny
pontja). Ezzel a 64 bites kulccsal XOR műveletet hajtanak végre az adat és CRC biteken ez lesz a
titkosított tartalom. Több gyenge pontja is van a megoldásnak. Egyik legismertebb probléma az
IV 24 bites tere. Ez egy 11 MBs-os vonalon néhány másodperc múlva 99%-os eséllyel ugyanaz
lesz. Ezt ki lehet használni egy ismert szöveges támadással. Ha tudjuk a titkosított tartalmat (mert
küldtünk egy email-t és a megfigyelt személy megnyitja ezt) akkor a tartalom ismeretében meg
tudjuk határozni a kulcs + IV párost. Ezután ha ugyanezzel az IV-vel érkezik üzenet azt vissza
tudjuk fejteni.
Egy korrektebb megoldás a fenti problémára az azonosítás és a jogosultságkezelés kiszervezése
(nem a hozzáférési ponton szeretné egy cég a felhasználói listát menedzselni) ez lehetővé teszi
központosított (jellemzően címtár alapú) rendszerek alkalmazását. A ragasztó a hozzáférési pont
és a központi azonosító, jogosultság kezelő rendszer között a RADIUS protokoll. A kliens és
a hozzáférési pont között a 802.11i teremti meg annak a lehetőségét, hogy a hozzáférési pont
transzparens módon átjátssza az azonosító protokollt.
Ezzel a megoldással a konkrét azonosítás protokoll a két végpont képességétől függ nem
a hozzáférési pont képességeit. A 802.11i az EAP (Kiterjeszthető Azonosítási Protokoll -
Extensible Authentication Protocol) segítségével absztrahálja az azonosítási protokollt. Ez egy
AP: hozzáférési pont

STA: AS:
vezetékes
kliens állomás Azonosító
hálózat
szerver
1 A biztonsági képességek felderítése
2 Az STA és az AS kölcsönsöen azonosítja egymást, közösen gyártanak egy

Mester Kulcsot (MK). Az AP mint “átjátszó” működik
3 Az STA legyártja
Pár Mester Kulcsot 3 Az AS legyártja ugyanazt
a PMK,
(PMK)
elküldi az AP-nak
4 Az STA, AP a PMK-t használja az

Ideiglenes Kulcs(TK) legyártására
amelyet az üzenet titkosításhoz, tartalom védelemhez
használnak
6.43: WEP azonosítás kiszervezett azonosító szerverrel1
keret protokoll ahol a két oldal megbeszélheti, hogy a beépülő modulként a két oldalon rendelkezésre
álló protokollokból melyiket alkalmazzák. Az EAP alkalmazásán túl TLS csatorna is kiépül és
közösen rakják össze a viszonykulcsot.
A kis kitérőnket követően viszont ideje rátérni az igazi nagy falatra, melynek révén végre behatóbb
képet kaphatunk arról, mégis hogyan tudjuk elérni az internetet az okoseszközeink révén még akkor
is, ha épp egy tisztán védett WiFi-kel korülvett helyen tartózkodunk a használatukhoz szükséges
adatok hiányában. A technológia pontos neve Cella Alapú Internet hozzáférés, alapjai pedig a
cellák, amelyek földrajzi területeket fednek le. A terminológia ismertetéséhez a Global System
for Mobile Standards vagyis GSM szabványhalmaz nevezéktanát használjuk, mely a 90-es évek
elején jelent meg, majd napjainkra a hordozható telefonok 80%-ának működését határozza meg.
Fontos Egy klasszikus cellán belül a felépítés az IEEE 802.11-es szabványnak megfelelő
felépítéssel van dolgunk: adott egy bázisállomás, melyhez a mobilfelhasználók csatlakozhatnak.
A különböző cellákat a Mobil Kapcsoló Központok (MSC) fogják össze, melyek összekötik
őket a vezetékes hálózattal, valamint intézkednek a hívásokkal és a mobilállomások cellák
közötti mobilitásával kapcsolatos teendőkkel kapcsolatban is.
Az egyes cellákon belül a közeg megosztására kombinált FDMA / TDMA módszer (a csatornát
előbb frekvenciákra bontjuk, majd az egyes frekvenciacsatornákat időrésekre) vagy pedig CDMA
van alkalmazva. A kapcsolóközpontokat és a hozzájuk tartozó alállomásokat együttesen nevezzük
Mobil Kapcsoló Alrendszernek (MSA). A korai 2G hálózatok esetén, ez volt a meghatározó
topológia, a rendszerek a közeg megosztására TDMA és FDMA technológiákat használtak, az
alállomásokhoz csatlakoztak, a hálózat pedig még csak tisztán hang átvitelére volt képes.
6.14 Mobilhálózatok 167
Bázisállomás rendszer (BSS)

MSC
BTS BSC G
Nyilvános
telefonhálózat
Átjáró
MSC
Jelmagyarázat
Bázisállomás adó-vevő (BTS)
Bázisállomás vezérlő (BSC)
Mobil Kapcsoló Központ (MSC)
Mobil felhasználók
6.44: Klasszikus 2G hálózat infrastruktúra1
6.14.1 3G
A már vegyesen adat és hang átvitelére is képes 3G még megőrizte az eredeti topológiát, ám
kibővítette azt olyan extra elemekkel, amelyek képessé tették a hanggal párhuzamosan az adatok
átvitelét is - lényegében implementálnia kellett az általunk immár jól ismert TCP/IP protokollhalmazt.
Ennek működéséhez az MSC-k korábbi helyét átvette az RNC vagyis Rádió Hálózati Irányítóközpont,
mely egységesen fogadta a telefonok hang és adatalapú csomagjait, ám a továbbítást két külön
irányba végezte - a hang alapú üzenet ment tovább az MSC-nek, míg az adatok Általános
Csomagalapú Rádiószolgáltatókon keresztül (GPRS) átkerültek az IP gerinchálózatra, majd ki a
publikus internetre.A GPRS hálózaton belül kétféle csomópontot különböztetünk meg, a hálózaton
belüli forgalomirányítást bonyolító SGSN szolgákat és a publikus internettel kommunikáló átjáró
GGSN-eket. A cél ezzel elsősorban az volt, hogy az új szolgáltatások megjelenése mellett a GSM
hálózat magja érintetlen maradjon.
6.14.2 4G
Ám a fejlődés következő lépcsőfoka, a 4G Long-Term Evolution (LTE) szabvány már nem
finomkodott ilyen téren, és egy lényegesen fejlettebb Rádió Hozzáférési Közeg definiálásán túl a
hálózat magját egy tisztán IP alapú hálózatra cserélte. A 4G hálózatban az adatsík és vezérlősík
teljes elkülönítésre kerültek, ahogy az eszközöket összekötő rádióhálózat és az IP alapú hálózatmag
is, az adat és a hang viszont már nem kerül elválasztásra, a teljes adatforgalom az IP magon kerül
továbbításra. Az LTE hálózaton frekvencia - és idő alapú csatornafelbontás zajlik, minden aktív
csomópont egy vagy több félmásodperces időrést kap egy vagy több csatornafrekvencián. Egy
eszköz minél több időrést kap, annál nagyobb magasabb átviteli arányt képes elérni a hálózaton, az
időrések kiosztása, allokálása pedig nagyon gyorsan, milimásodpercek alatt végbemehet. A döntés,
hogy egy adott időrésben melyik eszköz fog ténylegesen adni, az LTE üzemeltetők algoritmusaitól
függ, melyet befolyásolhatják a szolgálatók és a felhasználók közti megállapodás paraméterei. A 4G
kulcsfontosságú eleme az eNodeB - a 2G bázisállomásának és a 3G rádióközpontok örököse, mely
az LTE rádióhálózat forgalmát továbbítja az IP gerinchálózat felé GPRS alagút protokoll (GTP)
csomagba foglalva, amelyek aztán UDP, majd IP keretbe kerülnek - az így létrejött, megnövekedett
méretű IP csomag kerül továbbításra az S-GW felé. Az eNodeB-t követik a vezérlősíkon a
Mobilitás Vezérlő Entitások (MME) és Otthoni Feliratkozó Szerverek (HSS), melyek pontos
MSC
G Nyilvános
telefonhálózat
rádió
hálózat Átjáró
vezérlő MSC
G Nyilvános
SGSN Internet
GGSN
Kiszolgáló GPRS Támogató

Csomópont (SGSN)
Átjáró GPRS Támogató

Csomópont (GGSN)
6.45: 3G hálózat infrastruktúra1
funkcióival és feladatával a következő, mobilitással foglalkozó fejezetben ismerkedünk meg

bővebben, őket követi az S-GW (Service Gateway), mely a szolgáltatások adminisztrációs részéért
felel, mint a számlázás, összegzés, valamint jogtalan felhasználások meggátolása. Az S-GW
mögött, a nyilvános internet előtt helyezkedik el a P-GW (Packet Data Network Gateway), mely
képes keretbe foglalni, illetve azokból kibontani a datagramokat, valamint ellátni a szolgáltatás
minőségének (bitráta, késleltetési küszöbértékek, stb.) biztosításához szükséges lépéseket.
Mobilitás Otthoni Feliratkozó

Kezelő Szerver(HSS)
Kiszolgáló Adatcsomag
Entitás (MME) (like HLR+VLR)
Átjáró hálózat
UE eNodeB Átjáró
HSS (S-GW)
(felhasználó elem)(bázisállomás) (P-GW)
MME
vezérlés
G G
Nyilvános
adat internet
S-GW P-GW
rádió hozzáférési hálózat Fejlett Csomag Mag
Universal Terrestrial Radio
Access Network (UTRAN) (EPC)
6.46: 4G hálózat infrastruktúra1
6.14.3 5G
A jegyzet írásakor a legfrissebb, még bevezetés alatt álló mobilkommunikációs szabvány az 5G
, mely azonban a hosszútávú tervek szerint, köszönhetően rendkívül magas sebességének és
stabilitásának, már nem csak okostelefonok számára biztosítaná a vezetékmentes internetelérést,
hanem akár laptopok és asztali számítógépek számára is. Ennek eléréshez a 5G jelentősen magasabb
frekvenciatartományt használ a 4G-hez képest, azonban ennek van egy jelentős hátránya is -
magasabb frekvencia egyúttal alacsonyabb hatótávolsággal jár a klasszikus 4G bázisállomásokkal
6.15 Mobilitás 169
szemben. Épp ezért az 5G hálózatok három frekvenciatartományban működnek majd - alacsony,

közepes és magas - melyekkel összhangban három típusú cellát különböztet meg, melyekben a
hatótávolság fordítottan arányos a biztosított letöltési sebességgel. Az alacsony tartomány a 4G
hálózatokhoz hasonló frekvencián működik, ám némileg gyorsabb, 30-50 Mbps sebességet biztosít,
hatótávolsága pedig szintén nagyjából megegyezik a 4G bázisállomásokéval. A közepes tartomány
már 2.5 - 3.7 GHz közti frekveniákkal dolgozik 100-900 Mbit/s sebességgel, a bázisállomások pedig
ugyan már kisebb hatótávolsággal rendelkeznek, még mindig több kilométeres területet képesek
lefedni. (A tervek szerint egyúttal ez lesz a közeljövőben a legelterjedtebb frekvenciatartomány is).
A magas tartomány ezzel szemben már 25 - 39 GHz-es frekvenciákkal dolgozik, a sebessége pedig
a leggyorsabb kábeles internetelérésével vetekedhet - cserébe egy bázisállomásának hatótávolsága
alig másfél kilométert képes csak lefedni, így a teljes lefedettség rengeteg, kicsi, költséges cella
létesítését igényelné.
Kiépítés tekintetében két 5G infrastruktúrát különböztetünk meg - nem-önálló (NSA) és önálló
5G infrastruktúrát, melyek közül előbbi jellemzően már valamilyen létező - például 4G LTE
infrastruktúrára - épül rá. Egy nem-önálló modellben például a rádió hozzáférési közeg már
lehet az 5G által kínált alacsony frekvenciájú tartomány, mely biztosítja a 5G szabványban előírt
képességeket, ám a bázisállomásokat követően az adat a 4G LTE hálózatára kerül.
Az önálló 5G viszont a hozzáférési közegből már nem az LTE-re, hanem a saját, felhő-natív
hálózati magjába továbbítja az adatot (a közös hozzáférési közeg lehetővé teszi a szolgáltatók
számára, hogy a hálózatmag fizikai kiépítéséig is megkezdhessék a 5G bevezetését), mely szolgáltatásalapú,
virtualizált architektúra révén dolgozza fel az adatokat. Ilyen szolgáltatás például a Felhasználói
Sík Funkció (UPF), mely a 4G-ben látott adat és vezérlősík ok elválasztásának következő lépése, és
lehetővé teszi, hogy az adatátvitel a hálózat peremén, a belső műveletektől függetlenül folyhasson.
A Hozzáférés és Mobilitás Menedzselő Funkció (AWF) fogadja a felhasználói eszközökre
vonatkozó információkat, ám azokból csak a hívások vezérlését, átadását, mobilitását kezeli, minden
mást továbbít a harmadik virtuális funkciótípus, a Session Kezelő Funkció (SMF) irányába, mely
a létrejött kapcsolat vezérléséért, fenntartásáért és menedzseléséért felel, mint például a DHCP
protokoll implementálása és a csatlakozott felhasználók számára IP címek kiosztása. Az 5G jó
illusztrálja a technológiák fúzióját, egy mély áttekintést ad róla ez a könyv [3]
6.15 Mobilitás
Egyetlen utolsó simítás van csak hátra ahhoz, hogy az adatkapcsolati réteget is magunk mögött
tudhassuk és rátérhessünk a hálózati biztonság minden réteget átható témakörére, ez pedig a
mobilitás kérdése. A WiFi kapcsán már kitértünk egy olyan esetre, amikor egy állomás az IP
címe és alhálózata nélkül másik hozzáférési pontot próbált használni. Ott szerencsénk volt mivel a
WiFi az ilyen jellegű problémákat megoldja a tanulási funkcióival. De mihez kezdjünk egy olyan
esetben, amikor a) a telefon több alkalommal is hozzáférési pontot vált, melynek során az IP címe
is változik, miközben b) folyamatosan forgalmat bonyolít és c) ennek hatékony megvalósítása
érdekében ezt képesnek kell lennie úgy megtenni, hogy minél kevesebb késleltetést vagy hibát
észleljen az hozzáférési pont váltások ellenére?
Ahhoz, hogy megértsük, ezt hogyan éri el az adatkapcsolati réteg, szükségünk lesz néhány
kitüntett fogalom bevezetésére.
Fontos Az otthoni hálózat az adott eszköz állandó otthona. Ezen belül a mobilitás kezeléséért
felelő elem az otthon ügynök, ezzel kommunikál a mobil eszköz, ha épp az otthoni hálózaton
kívül helyezkedik el. Az otthoni hálózaton belül az eszköz azonosítására az állandó cím szolgál,
mely az eszközön mindig megmarad, és mellyel bárhol beazonosítható. A meglátogatott
hálózat a mobil eszköz tartózkodási hálózata, melynek funkcióit az abban elérhető idegen
nincs mobilitás magas mobilitás
válozatlan AP-t DHCP segítségével több AP-n is

használó mobil kapcsolódó, majd keresztülahaldó és a
vezetékmenetes eltűnő felhasználó. forgalmat
felhasználó folyamatosan
fenntartó
felhasználó(mint a
mobiltelefon)
6.47: Mobilitási fokozatok1
ügynök segítségével használja. A probléma magja a társ entitás - egy másik mobil eszköz, ami
a tartózkodási helytől függetlenül el akarja érni az eszközünket.
Az első ,
állandó cím
(pl.: 128.119.40.186)
otthon ügynök vendég cím

otthoni hálózat (pl.: 79,129.13.2)
(pl.: 128.119.40/24)
meglátogatott
hálózat
wan jellegű
hálózat
állandó cím idegen ügynök
pl.: 128.119.40.186
társ entitás
6.48: Mobilitási alapfogalmak viszonya1
Naív megközelítésben csábító lenne mindössze annyival letudni ezt a problémát, hogy ha
egyszer a különböző forgalomirányítóink amúgy is képesek a táblázataik és információik automatikus
frissítésére, miért nem adjuk át nekik ezt a terhet, és frissítgetik, cserélgetik a táblázataikat úgy,
hogy mindig nyomon tudják követni, egy adott mobil eszköz épp hol található?
Mert irreálisan költséges lenne! Képzeljünk csak el 100 olyan eszközt, amelyek folyamatos
mozgásban és hozzáférési pont váltogatásban vannak a fent meghatározott abc feltételek mellett.
A forgalomirányítóknak lényegében megállás nélkül cserélgetniük kellene az információikat és
fennállna a veszély, hogy mire a hálózat egyik pontjára eljutna az információ, az már rég elavult is
lenne. Helyette a felelősség a végrendszerekre - az otthoni és meglátogatott hálózatokra, valamint
6.15 Mobilitás 171
magukra a mobil eszközökre helyeződik. A cél az, hogy a társ entitás eléréséhez pusztán annak
otthoni ügynökével kelljen felvennünk a kapcsolatot, az pedig bármely időpontban rendelkezzen
az elérni kívánt entitás pontos tartózkodási helyével - mintha csak lenne egy személyes inas, aki
mindig tudja, a munkaadója pontosan hol tartózkodik. A megvalósítása még csak nem is bonyolult:
ahogy az eszközünk belép egy meglátogatott hálózatra, első lépése, hogy regisztrál a hálózat
idegen ügynökénél, amely azonnal propagálja ezt a tartózkodási információt az otthoni ügynökének,
beleértve a vendég címet, amelyen a saját hálózatában elérhető lesz az otthontól távol tartózkodó
eszköz.
az idegen ügynök
megkapja és
a társ entitás továbbítja a mobilnak
az idegen ügynöknek vendég
továbbítja hálózat
otthoni
hálózat
3
1 2
4
a mobil
a társ entitás
közvetlenül a társ
elkéri és megkapja a
entitásnak
vendég címet
válaszol
6.49: Közvetlen forgalomirányítás1
Így ha az eszközt egy másik keresni próbálja, nem kell tudnia semmit az aktuális tartózkodási
helyéről és épp használt címéről - bőven elegendő az állandó cím és az otthoni ügynök elérése,
mivel a megoldás transzparens, sőt, arra az esetre, ha a hálózatváltások gyorsan következnének be,
a már megnyitott kapcsolatok nyitva maradnak a váltások ellenére is.
1. A társ entitás kommunikálni próbál az eszközzel az otthoni címe alapján
2. Az otthon ügynök elkapja a csomagokat és továbbítja az eszköz legutoljára regisztrált idegen
ügynöke felé
3. Az idegen ügynök átadja a csomagokat az eszköznek
4. Az eszköz képes közvetlenül válaszolni a társ entitásnak
A módszer egyedül akkor nem hatékony, ha a két kommunikálni szándékozó fél azonos
hálózatban tartózkodik úgy, hogy arról egyikük sem tud. Az ilyen, háromszöges forgalomirányítási
problémának is nevezett esetek kiküszöbölésére van lehetőség a közvetlen forgalomirányításra
is. Ekkor a kommunikáló entitás az otthoni ügynöktől elkéri a vendég címet és azon közvetlenül
szólítja meg a másik felet.
1. A társ entitás nem az otthoni címén szólítja meg az eszközt, hanem elkéri a vendég címét
2. A társ entitás továbbítja ezt a kérést az idegen ügynöknek
3. Az idegen ügynök elküldi a vendég címet a társ entitásnak
4. A társ entitás és az eszköz közvetlen kommunikációba kezdenek
A módszer hátránya, hogy mivel ebben az esetben a kommunikáció nem az ügynökökön

keresztül valósul meg, a társ entitás számára megszűnik a transzparencia, és ezáltal a kapcsolat
fenntartása is problémákba ütközhet, ezért szükséges a mobil felhasználót lokalizáló protokoll
implementálása. Ennek a protokollnak a kulcsfontosságú elemei a horgony idegen ügynökök.

Horgony ügynök mindig a legelső meglátogatott idegen hálózat ügynöke lesz, egyben egy továbbítási
lánc első láncszeme. Minden egyes hálózatváltásnál az elhagyott hálózat idegen ügynöke újabb
horgony ügynökké válik, így a társ entitásnak elegendő csak az első horgony ügynököt ismernie, az
már képes eljuttatni a láncon a csomagokat az eszközhöz.
Fontos Összefoglalva tehát, a végrendszerek által vezérelt mobilitás két típusa:

• közvetett: a forgalmat az otthoni ügynök továbbítja a távoli ügynöknek, majd az a
céleszköznek
• közvetlen: a társ entitás megszerzi az otthon ügynöktől az eszköz aktuális IP címét, és
közvetlenül kommunikál vele
Ahhoz, hogy ebben a modellben a címzés továbbra is hatékonyan működjön, szükségessé vált
egy új szabvány bevezetése, melyet az RFC 3344 ismertebb nevén pedig a mobil IP szabvány jelöl.
A szabvány lényegében magába foglalja a fent említett szolgáltatások gyakorlati implementációját,
és megvalósítja a hatékony ügynökfelderítést, hálózatokon belüli regisztrációt, valamint a közvetett
forgalomirányítást. Az ügynökök felfedezéséhez például speciális ICMP üzeneteket definiál,
melyek segítségével az ügynökök hirdethetik magukat a saját hálózatukon belül, és a belépő
eszközök is küldhetnek felhívó üzeneteket az ügynök csomópontok számára.
1. Miután egy ilyen üzenetváltás hatására az idegen ügynök és az eszköz egymásra találtak, az
eszköz regisztrál az ügynöknél, mely biztosítja számára a vendég címet
2. Az idegen ügynök ezt a regisztrációs információt továbbítja az otthon ügynökhöz
3. Az otthon ügynök jóváhagyja a hozzárendelést, mire az idegen ügynök is jelzi az eszköz
számára, hogy minden rendben van
4. Az eszköz a vendég cím használatával kommunikál
A mobil IP szabvány érdekessége, hogy az ügynökök a csomagok egymásba ágyazásával oldják

meg az eszköz azonosítását - az otthon ügynök, miután a társ entitástól elkap egy csomagot, azt
beburkolja egy csomagba, melynek címzettje az idegen ügynök IP címe lesz. Az idegen ügynök
helyreállítja belőle az eredeti csomagot, majd a mobilitás kezelő táblázata alapján kikeresi az eszköz
vendég címét, és továbbítja számára a csomagot.
A mobilitás logikai változásokat nem idézhet elő a felsőbb rétegekben, mind a szolgáltatásmodell,
mind a TCP és UDP protokollok változatlanul működhetnek, ám a teljesítmény terén ez már nem
garantálható - a sávszélesség, a késleltetés, a hálózatváltások költségei, a horgony ügynökökön
alapuló láncolt megoldások egytől-egyig hatással vannak a teljesítményre.
Fontos A mobilitás kezelésének transzparens folyamatnak kell lennie, a meglevő kapcsolatok

nem szakadhatnak meg és a felhasználók, magasabb szintű protokollok nem észlelhetik a váltást.
A gyakorlatban viszont előfordulhat késleltetés, bithibák miatti csomagvesztés, tévesen érzékelt
torlódás és a sávszélességben is bekövetkezhet változás.
6.15.1 Mobilitás cella alapú hálózatokban

Ugyan a fenti technológia nem kifejezetten mobilhálózatokra vonatkozott, az abban megismert
koncepciókat nagyon könnyen át tudjuk ültetni a komplex cella alapú hálózatokra is. A bázisállomások
által kezelt hálózatok rendelkeznek két lokáció regiszterrel, egy otthonival (HLR), mely a saját
eszközök pontos információit, beleértve aktuális tartózkodási helyét, és egy vendéggel (VLR),
amely pedig az épp hálózaton belül tartózkodó vendég eszközök adatait tartalmazzák. Ez a két
regiszter valósítja meg a fenti modellben látott ügynökök koncepcióját. A regisztereket a 3G
6.15 Mobilitás 173
-s hálózatokban a Mobil Kapcsoló Központok (MSC) kezelik, míg 4G és LTE hálózatokban az

MME-k és eNodeB-k valósítják meg. A mobiltelefonok rendelkeznek továbbá egy roaming, vagyis
vándorlási címmel, amelyen az otthoni és a távoli MSC-k elérhetik egymást, ez a cím nem érhető el
sem a telefon, sem a felhasználó számára.
A cella alapú hálózatokban a hangsúlyos rész azonban nem pusztán a mobilitás, a forgalomirányítás
és a hálózatok közötti váltogatás - ezt a fenti elemek megoldják a cella alapú hálózatokban.
Probléma akkor van, amikor a váltás közben az adott telefon nem egyszerűen adatforgalmat bonyolít,
hanem hívásban van - ekkor ugyanis úgy kell megvalósítani a hívásátadást az MSC-k (vagy LTE
esetben az eNodeB-k) között, miközben az eszköz egyre távolodik az egyik bázisállomástól és
közeledik a másikhoz, hogy az átadás közben nem szakadhat meg a kapcsolat, ellenkező esetben
ezt a felhasználó az “elment a térerő” néven ismert kellemetlen jelenség formájában tapasztalhatja
(legalábbis jobb esetben, rosszabb esetben ilyenkor a cellák hatótávolságán kívül került az eszköz).
otthoni hálózat
társ entitás
Home MSC
horgony MSC
PSTN
MSC
MSC
MSC
6.50: Sikeresen megvalósult hívásátadás1
A hívásátadás pontos végrehajtása elsősorban attól függ, hogy az átadás során pusztán
bázisállomást váltunk ugyanazon MSC fennhatósága alatt, vagy MSC-k között is át kell adni
a folyamatban levő hívást. Előbbi esetben:
1. előkészítési fázis: az aktuális állomás értesíti az MSC-t a közelgő átadásról, mire az értesíti
a leendő állomást, hogy kezdje el allokálni a csatornákat az új mobil számára. Ha elkészült,
az új állomás az MSC-n keresztül jelez a réginek - minden készen áll, következhet az átadás
2. végrehajtási fázis: ha a régi állomás megkapta a jelzést, értesíti erről a hívásban levő mobilt,
mire az megszólítja a leendő állomását, hogy nyissa meg számára a lefoglalt csatornákat.
Ahogy az új csatorna megnyílt előtte, a mobil jelzi az MSC-nek, hogy átadhatja a hívást az
új bázisállomásnak, minden kész, majd miután az MSC ezt megtette és minden átkerült az új
bázisállomás alá
3. befejezési fázis: a régi állomás felszabadítja az erőforrásokat, amelyeket a telefon használt a
hívás lebonyolításához
Amennyiben MSC váltás is szükséges, a horgony ügynökök korábban bemutatott koncepcióját

hívjuk segítségül - az MSC-k elintézik egymás között a bázisállomások szinkronizációját, viszont

hogy a hívás ne szakadjon meg, az eredeti MSC horgony szerepet vállal magára és miután az
már kilépett a celláiból, elindít egy láncolt listát, melynek révén a másik félnek elegendő vele
kapcsolatban maradnia, a hívás adatforgalmát pedig továbbítja a következő MSC felé. A listán
belül, amennyiben tovább növekszik, a szolgáltatók implementálhatnak útvonal optimalizációt,
mely képes lerövidíteni a horgony MSC-k listáját az eredeti és az aktuális között.
Fontos LTE esetén kicsit más a helyzet, itt ugyanis a felhasználó (UE) szabadon mozoghat
a cellák között, a hálózat nem tárol pontos információkat az aktuális tartózkodási helyéről.
Amennyiben szükség van erre az információra, a mobilitást kezeleő MME üzenetet küld ki
minden eNodeB-nek, hogy kiderítse, épp melyikhez kapcsolódik az eszköz.

1. Ismertesd az adatkapcsolati réteg szerepét, szolgáltatásait!
2. Ismertesd az adatkapcsolati rétegben alkalmazott hibadetektálás elveit! (CRC/Internet)
3. Ismertesd a MAC-protokollok motivációját! Mi az ideális többszörös hozzáférésű protokoll,

ezek fontosabb osztályai?
4. Ismertesd a TDMA és FDMA megosztás módokat!
5. Ismertesd a réselt ALOHA protokollt! Mi a hatékonysága?
6. Ismertesd a nem réselt ALOHA protokollt! Mi a hatékonysága?
7. Ismertesd a CSMA protokollt! Mi a hatékonysága?
8. Ismertesd a CSMA/CD protokollt! Mi a hatékonysága?
9. Ismertesd a felváltva MAC protokollokat!
10. Ismertesd az Ethernet MAC-címeket! Vesd össze az IP címmel!
11. Ismertesd az ARP protokollt!
12. Ismertesd az Ethernet keretet, ennek fontosabb mezőit!
13. Ismertesd az Ethernet kapcsoló működését, szerepét!
14. Vesd össze a kapcsolót és a forgalomirányítót!
15. Mi a motivácó a VLAN mögött? Hogyan megy át a VLAN információ a kapcsolók között?
16. Ismertesd az MPLS mögötti motivációt! Hogyan működik?
17. Ismertesd a vezetékmentes hálózatok elemeit, ezek jellemzőit! (egy vs több ugrás)
18. Ismertesd a vezetékmentes vonal karakterisztikáját!
19. Ismertesd a CDMA-t, írj le egy konkrét példát!
20. Ismertesd az IEEE 802.11 Vezetékmentes LAN jellemzőit, elemeit!
21. Ismertesd a 802.11 csatorna keresést!
22. Ismertesd a 802.11 CSMA/CA protokollt, miért van szükség CA-ra?
23. Ismertesd a 802.11 keretet és fontosabb mezőit! MIért van szükség 4 cím mezőre? Ezeket
hogyan használjuk?
24. Ismertesd a WEP protokollt és annak biztonsági problémáját!
25. Ismertesd a 802.11i és EAP protokollok alapjait!
26. Ismertesd a cella alapú hálózatok elemeit, ezek jellemzőit! (2,3,4G)
27. Ismertesd az 5G hálózat frekvenciatartományait és hálózatmagjának funkcióit!
28. Ismertesd a hálózati mobilitás problémáját, jellemzőit, elemeit, terminológiáját!
29. Ismertesd a hálózati mobilitás lehetséges megoldási módjait!
30. Hogyan működik a mobilitás közvetett forgalomirányítással?
31. Hogyan működik a mobilitás cella alapú hálózatokban?
32. Vesd össze a mobil IP és a cella alapú mobilitás elemeit!

[1] Luc De Ghein. MPLS Fundamentals. 1st. Cisco Press, 2006. ISBN: 1587051974 (cited on
page 151).
[3] Patrick Marsch et al. 5G System Design: Architectural and Functional Considerations and
Long Term Research. 1st. Wiley Publishing, 2018. ISBN: 1119425123 (cited on page 169).
7. Hálózati biztonság

• Ma gyakorlatilag minden SSL felett megy.
• Adott szolgáltatások integrálásához (pl: mobil szolgáltatótól APN végződtetése) szükséges
a VPN, és ez a legtöbb esetben IPSec.
• Meg kell védeni az IT rendszereket.

A jegyzet eddigi fejezeteiben áttekintettük a hálózati biztonság alapjait és az egyes protokollokhoz

szorosan kötődő biztonsági megoldásokat. E fejezet célja, hogy a rendszerszinten érdekes, fontos
megoldásokra adjon egy magasszintű áttekintést.
Az IPv4-es protokoll verem egyik rétege sem nyújt semmilyen biztonsági szolgáltatást sem. Az
adatkapcsolati rétegben ugyan vannak ilyen szolgáltatások, de azok csak vonal szintűek, fontos
azonban a kapcsolat szintű vég-vég biztonsági képességek megléte. A HTTP esetén láttuk
például azt, hogy az adat szabad szöveges formátumban megy át a TCP csatorna és az alatta
lévő beágyazásokon át. Itt részmegoldást adhat, hogy például ha telefonról nyitjuk meg a weboldalt
és a telefon GSM hálózaton van, akkor az adat titkosítva lesz a GSM és az általa megvásárolt
nemzetközi kapcsolat biztosító cég kapcsolódási pontjáig (valójában addig sem). De ezután az
adatunk már úgy utazik a különböző hálózatokban, hogy bárki írhatja, olvashatja és mi ezt nem
tudjuk a végén detektálni. Egy megközelítésmód lehetne, hogy minden protokoll megoldja magának
a problémát - azaz minden protokollt (IMAP, POP3, Telnet, HTTP...) átalakítunk és belevesszük a
biztonsághoz szükséges képességeket a protokoll kiterjesztésével. Az SHTTP ezen az úton indult
el, de nem lett elterjedt. Sokkal praktikusabb az, ha ez a szolgáltatás ezen protokollok alatt valósul
meg. Így nem kell például minden protokollnál külön - külön javítani a biztonsági problémákat,
csak egy alattuk lévő közös protokollnál. Ilyen közös megoldás az SSL mely a TCP protokoll fölött
helyezkedik el és az IPSec, mely az IP protokoll fölött helyezkedik el.

Az SSL (Biztonságos Szoftvercsatorna Réteg - Secure Socket Layer) és a szabványos elnevezése:
TLS (Szállítási rétegbéli biztonság - Transport Layer Security) a leggyakrabban alkalmazott
megoldás a nem biztonságos protokollok biztonságossá tételére. A HTTPS, az IMAPS, az
SSH mind a klasszikus protokollokat képviselik, csak alattuk van az SSL/TLS. Mivel a TCP
fölött helyezkedik el, ezért működés a TCP-hez hasonlóan csatornaszerű: adatfolyamot vár és
adatfolyamot ad ki. Ugyanúgy viselkedik tehát mint a TCP, csak hozzáadja az alábbi szolgáltatásokat:
• tartalomvédelem: adatfolyam szinten validálhatjuk, hogy változott-e
• titkosítás: adatfolyam szinten titkosít (mint látjuk, szimmetrikus és aszimmetrikus kulcs
kombinációval)
• azonosítás: itt nincs felhasználói szintű azonosítás, csak a digitális tanúsítvánnyal azonosítja
a másik oldalt, ezért kell az adott protokoll saját azonosítási megoldását is alkalmazni (pl.:
HTTP Basic Auth)
Az SSL protokoll a TCP csatorna megnyitása után egy SSL kézfogás üzenetváltással kezdődik. Itt
a két oldal azonosítja egymást a digitális tanúsítványa segítségével. Kritikus fontosságú, hogy a
szervernek korrekt, a tanúsítvány hierarchiába illesztett tanúsítványa legyen. Ha csak saját
maga által aláírt tanúsítványa van, akkor az egész nem ér semmit sem, mert az ember a
középen támadással kijátszható. Miután megtörtént a tanúsítvány csere, akkor már van egy
biztonságos csatorna (a publikus kulcsok). E kulcsok segítségével összerakják a közös titkot, amely
a szimmetrikus titkosítás kulcsaként lesz használva. Az SSL ugyan használhatná ugyanazokat az
7.1: SSL helye a hálózati rétegek között, SSL üzenetváltás
elveket, amelyeket PGP esetén láttunk, de az nem lenne praktikus. Ott egy darab email titkosítása
volt a feladat, itt egy adatfolyamé. A kézfogás protokoll alatt/után helyezkedik az SSL rekord
protokoll, amely az adatfolyamot darabokra bontja, tömöríti, MAC-kel (üzenet azonosító kód
- message authentication code) tartalomvédelemmel látja el, majd titkosítja a szimmetrikus
kulccsal és ellátja egy fejléccel. A fejléc az SSL verzióját és a tartalom hosszát tartalmazza.
Az SSL képes egy transzparens, biztonságos csatornát kiépíteni a TCP csatorna felett. Az
alkalmazóknak a TCP-hez képest annyi plusz feladata van, hogy paraméterezze és egy-egy érvényes
digitális tanúsítványt adjon a két végéhez. Nem mindenhol használható azonban a csatorna
absztrakció. UDP felett például nem lenne hatékony minden egyes csomag előtt a kézfogás
lefuttatni, így szükség van egy alacsonyabb szintű csomag alapú megoldásra is. Ez az IPSec.

Az IPv4 tervezésekor a biztonság nem volt szempont, ennek hibáit ismerve az IPv6 számára a
biztonság, mint szempont már alapvető tervezési szempont. Az IPSec-ben bemutatandó képességek
7.2 Biztonságos hálózati réteg: IPSec és VPN 179
7.2: SSL rétegek, SSL műveletek
az IPv6-nak szerves részei, ott ki tudunk küldeni egy ping üzenetet titkosított tartalommal. Az
IPv4-be ezt az IPv6 képességeit egy csomagba szervezve IPSec néven valósították meg. A
továbbiakban az IPSec-től beszélünk, de az eredeti, ezzel egyenértékű képességek az IPv6-ban
is megtalálhatóak. Az IPSec segítségével egyes csomagokat, de még csomagok folyamát is el
tudjuk látni biztonsági képességekkel. Egy gyakori felhasználása a VPN (Virtuális Magánhálózat
- Virtual Private Network) kialakítása. Ilyenkor az összekötött hálózat szigetek között Internet
kapcsolatot használunk az összeköttetésre (bank központ és bank helyi telephely), a belső rendszerek
a szigetek között transzparens módon összeköthetőek. A 7.3 ábrán láthatóak a különböző permutációk.
Maga az elv az, hogy IP csomagba IP csomagot tesszük, azaz a belső forgalmat az interneten
átküldött IP csomagokba csomagoljuk, csak ezt ellátjuk biztonsági képességekkel. Ennek megvalósítását
végzik az IPSec fejlécek. Az IPSec kapcsolat végződhet gépen (például egy laptopon) - ezt nevezzük
szállítási (transport) módnak - ekkor a gépen egy virtuális (szoftveres) interfész lesz létrehozva
és a gépen futó programok megfelelő belső forgalma a gép forgalomirányító táblájában erre lesznek
terelve. A gépen futó programok ebből semmit sem érzékelnek, ugyanúgy IP vagy TCP vagy HTTP
protokollokkal foglalkoznak, számukra a VPN transzparens. A másik mód az alagút (tunnel)
7.3: IPSec VPN módok
mód amikor nem gépeket, hanem hálózatokat kötünk össze, ekkor ez a virtuális interfész nem egy
felhasználói gépen, hanem egy VPN átjárón (VPN gateway) lesz létrehozva és a forgalomirányító
tábla bejegyzései alapján adott forgalmat betereli a virtuális interfészébe. Itt nem csak a gépeken
futó programok, hanem résztvevő gépek sem tudnak a VPN létezéséről, számukra ez transzparens.
7.2.1 AH és ESP protokollok

Az IPSec egy eléggé komplex protokoll, egyik leglényegesebb része az AH és ESP protokollok.
Az AH - Azonosító Fejléc (Authentication Header) a tartalom védelmet tudja biztosítani. Az
ESP Titkosító Biztonsági Beágyazás (Encapsulation Security Payload ) pedig a titkosítást és

azonosítást biztosítja. Ezek egymástól függetlenül alkalmazhatóak de egymásba is ágyazhatóak.
Az 7.4 ábrán látható AH és ESP fejléc. Az AH fejlécben a kivonat lesz hozzácsapva az eredeti
7.4: IPSec AH és ESP fejlécek
tartalomhoz (Authentication Data) - beszúrva, mint fejléc. Az ESP esetén a titkosított tartalom az,
amely a fejlécek után következik és a csomag végén van az azonosítás. Mindkét csomag elején van
egy sorszám, mely a visszajátszásos támadások ellen véd és egy SPI - Biztonsági Paraméter
Index(Security Parameter Index) mező. Ezekről bővebben a következő fejezetben írunk.
7.2.2 Biztonsági Asszociációk (SA - Security Associations)
Az SSL elején láttuk, hogy a kommunikáló felek a kapcsolat elején azonosítják egymást, megegyeznek
a közös kulcsban és még néhány paraméterben. Az IPSec esetén ugyanilyen igények merülnek
fel, itt erre az SA-t használják. Az SA egy adatbázis, ahol nem egy, hanem sok közös kulcs van
egy listában minden egyes IPSec kapcsolathoz. Itt vannak a szomszédok digitális tanúsítványai
is. Amikor egy-egy csomagot küldenek akkor a listából választott kulccsal titkosítják és/vagy
látják el tartalomvédelemmel. Az SPI azt mondja meg, hogy melyik kulcsot használjuk az
adott csomaghoz. Ha tehát a két kommunikáló fél oldalán az SA szinkronban van akkor szépen
működik a rendszer. Honnan van az SA adatbázis? Egyszerű esetben ezt kézzel hozza létre a
rendszer-adminisztrátor, ha sok csomópont sok kapcsolatát kell menedzselni, akkor erre külön
protokoll van: az IKE - Internetes Kulccsere Protokoll (Internet Key Exchange), ez hasonlóan
működik mint az SSL kézfogás.
7.5: IKE üzenetváltás

7.3 Rendszerszintű biztonság:Tűzfal, IDS 181
7.2.3 IPSec csomag

Láthattuk tehát a kapcsolat felépítést és az AH, ESP protokollokat. A nagy kép maradt még ki.
Hogyan vannak ezek a gyakorlatban egymásba ágyazva? A 7.6 ábrán láthatjuk az alagút mód
megvalósítását ESP-vel. Az ESP fejléc utáni tartalom titkosítva van az ESP fejlécében megadott
7.6: IPSec beágyazás
SA sorban megtalálható kulccsal. A titkosított tartalom és a fejléc kivonatolva van adott kulccsal,
és ez még a csomag végére van rakva. Így az adat titkosított és ha a titkosított részét kicserélik, azt
észrevesszük a MAC segítségével.

Az eddig megismert megoldások pont-pont viszonylatban (pl.: TLS) vagy hálózat-hálózat viszonylatban
(pl.: IPSec) segítettek a forgalmat titkosítani, a másik oldalt azonosítani. Ezek fontos protokollok,
de csak ezekre alapozva nehéz lenne egy hálózat biztonsági szintjét jelentősen emelni. Hol és
hogyan szabályozzuk, hogy mikor és milyen forgalmat engedek be a hálózatomra, gépemre?
Hogyan veszem észre, ha a hálózatomon mások garázdálkodnak? Látszik, hogy eddig még nem
említett képességek kellenek. Egyrészt proaktív képességek arról, hogy döntsünk adott forgalom
engedélyezéséről vagy tiltásáról (mint ahogyan az országhatár a valóságban), értenem, látnom is
kell a rendszerem belsejében zajló folyamatokat és észrevenni, ha gond van, ez a reaktív ág, azaz
jó eséllyel bekövetkezett a baj, de szeretném a folytatását megakadályozni (ilyen a rendőrség, vagy
a nyomozók).
7.3.1 Proaktív rendszerek

A proaktív rendszerek a rendszer állapota alapján hozzák meg a döntéseiket. Ezek közül a
legismertebb a tűzfal (firewall). A tűzfal feladata, hogy a rajta átmenő forgalomra szabályokat
kényszerítsen. Az, hogy ezek a szabályok mennyire komplexek és milyen rétegeibe érnek a protokoll
veremnek, a tűzfal képességétől függ. Jellemzően a tűzfalak az első 4 rétegben dolgoznak, azaz
ezen rétegek mezői alapján tudunk szabályokat hozni és a tűzfal a csomagok ezen beágyazásaiban
található mezők alapján hozza meg adott csomag továbbküldéséről vagy kidobásáról. A tűzfalakat
7.7: Tűzfal helye az infrastruktúrában

tűzfal szabályokkal lehet programozni. Az alapvető megközelítés az, hogy minden tilos, kivéve
ami explicit engedélyezve van. Ilyen minta szabály látható a 7.8 ábrán. Az állapotmentes
7.8: Minta tűzfal szabályok
tűzfalak képessége arra terjed ki, hogy a csomagok adott mezőire lehet szabályokat mondani.
Ezzel jó lehet kezelni az IP cím csalással (IP spoofing) kapcsolatos szabályokat (külső hálózatról
nem engedek be olyan csomagot, amelynek a forrás címe az én hálózatomról származik, vagy az én
hálózatomról nem engedek ki olyan csomagot, amelynek a forrás címe nem az én hálózatomhoz
tartozik). Ez a képesség azonban nem elegendő a számítógép hálózatokban alkalmazott alapvető
koncepció megvalósításához.
Fontos A hálózati biztonság egyik alapvetése: a magasabb biztonsági szintről szabad

kapcsolatot létesíteni az alacsonyabb biztonsági szintre, de az alacsonyabb biztonsági szintről
nem szabad kapcsolatot létesíteni a magasabb biztonsági szintre.
A gyakorlatban ez azt jelenti, hogy a tűzfal mögött ülő felhasználók (magasabb biztonsági szint)
kapcsolatot nyithatnak az Interneten elérhető webszerver felé (alacsonyabb szint, az Internet esetén a
préri, 0 biztonsági garanciával), de a webszerver nem kezdeményezhet csak úgy magától kapcsolatot
a felhasználókhoz. Ilyen típusú képességekkel az állapottartó tűzfalak bírnak. Itt ugye nem úgy
általában szeretném a forgalmat tiltani, hanem azt a forgalmat szeretném engedélyezni, amit a
magasabb biztonsági szinten lévő kezdeményez, erre válaszolhat az alacsonyabb biztonsági szinten
lévő entitás. Az állapottartó tűzfalak a NAT-hoz hasonlóan egy táblázatban könyvelik, hogy milyen
folyamok vannak és folyam nyitást csak magasabb szintről alacsonyabb szint felé engedélyeznek.
A tűzfalak által érintett rétegek, mint az elején említettük, az első négy hálózati réteg. Adott
megvalósítások ugyan képesek lehetnek mély csomagelemzésre (deep packet inspecktion), azaz
a magasabb rétegekben lévő adatokra mintaillesztésekre, de ez nagyon erőforrásigényes, azért
nem jellemző, hogy ezt a feladatot tűzfal látná el. Ezt a feladatot proxy-val vagy alkalmazás
szintű átjáróval (application gateway) érdemes megvalósítani. Ezek mélyebb képességű elemek
azonban nem olyan általánosak mint a tűzfal, hanem specializálódtak. Míg a tűzfal nem érti a
HTTP protokollt és jellemzően nem is lehet a mezőire szűrni, egy HTTP proxy érti a HTTP
protokollt és olyat is tudok mondani, hogy a HTML felnőtt tartalmat jelző mezője alapján
adott időszakban nem engedem be a forgalmat. A proxy/alkalmazás szintű átjáró tehát adott
protokoll kezelésére alkalmas, ha több különböző protokollt szeretnénk mélyen szűrni, akkor
több, az adott protokollokat értő proxy/alkalmazás szintű átjáró kell.
Az eddigi példáinkban egyszerű hálózati architektúrát láttunk: belső hálózat - tűzfal - külső
hálózat. Bár ez az architektúra is gyakran használt, de komoly problémát okoz az olyan belső
7.3 Rendszerszintű biztonság:Tűzfal, IDS 183
7.9: Adatút, alkalmazás szintű átjáróval és tűzfallal, HTTP proxy
szerverek kezelése, amelyek kifelé is szolgáltatásokat biztosítanak. Ilyen lehet a cég webszervere,
itt nem tudom azt mondani, hogy majd ő nyit kapcsolatokat a felhasználók felé, mert pont azt
várom, hogy az Interneten lévő felhasználók látogassák meg a weboldalt. Az ilyen az alacsonyabb
biztonsági szint felé nyitott elemeket kevésbé biztonságosnak tartjuk, ezért ezeket célszerű a
többi elemtől elkülöníteni. Erre alkalmas a DMZ - Demilitarizált Zóna (Demilitarized Zone).
A DMZ-be helyeznek el minden olyan szolgáltatást, amelyek kifelé nyitottak, ezekre külön
7.10: Demilitarizált Zóna (Demilitarized Zone)
szabályokat lehet definiálni a belső rendszer határán lévő tűzfalon. Komolyabb cégek a DMZ-be
helyezik adott protokollokat megvalósító proxy-kat is és a belső forgalom a külvilág felé csak
ezeken a proxy-kon mehet keresztül. Láthattuk tehát, hogy a forgalom adott mélységben lévő
információi alapján szabályokat tudunk kényszeríteni a forgalomra. Mi van azonban, ha a tűzfal
mögött történik valami kevésbé várt esemény? Egy kolléga bevisz egy pendrive-ot és arról egy
vírus szabadul el a hálózatunkon. Hogyan vesszük ezt észre? Erre jók a reaktív rendszerek.
7.3.2 Reaktív rendszerek

A reaktív rendszerek célja monitorozni a rendszer állapotát és jelezni, ha gond van. Ezt így leírni
nem nehéz, de megvalósítani már trükkösebb. Hogyan vesszük észre, hogy gond van? Nézhetjük a
hálózati forgalmat, nézhetjük a gépek processzorainak terhelését, nézhetjük, hogy ki jelentkezett be
utoljára. . . Ahogyan eddig is volt, az ilyen komplex problémára a megoldás is komplex lesz. A
rendszer legfelső szintjét a SIEM- Biztonsági Incidens és Esemény Kezelés (Security Incident
and Event Management), ezek a rendszerek képesek a sok különböző eseményforrásból érkező
adatot normalizálni, adott szabályok mentén feldolgozni ezeket, a független eseményfolyamokat
korreláltatni egymással idő és egyéb dimenziók mentén. Ezen korreláltatott eseményfolyamra
szabályokat lehet írni, melyek újabb eseményeket hoznak létre (pl.: tűzfalon két sikertelen
kapcsolatfelvétel adott címről, majd egy rendszergazdai bejelentkezés valamelyik gépre, majd
több fájl megváltozott adott háttértárban). Ilyen azabályhierarchia segítségével lehet akár aktív
beavatkozásokat indítani (tiltsuk le a tűzfalban az előbb említett küldő IP címet). Az belátható,
hogy a rendszerek komplexitásának növekedésével az ilyen, kézzel összerakott szabályrendszerek
7.11: SIEM- Biztonsági Incidens és Esemény Kezelés (Security Incident and Event Management)
egyre nehézkesebbek. Ezért a 3. generációs SIEM rendszerek gépi tanulást alkalmaznak

például az anomália detekcióra. A SIEM rendszerek egy fontos építőelemét még érdemes megemlítenünk,
ami az IDS - Behatolás Detektáló Rendszer (Intrusion Detection System). Ez a rendszer a
hálózatba helyezett mérőpontok/ügynökök segítségével mély csomagelemzést végeznek adott
pontok forgalmán. Itt IDS képességtől függően különböző szabályokat lehet mondani a tartalomra.
Ilyen szabály lehet akár egy vírusra jellemző bájt mintázat is. A Snort egy ismert, nyílt forrású IDS.
Szabálynyelv segítségével lehet megadni akár felvett protokoll vagy forgalommintákat is.
7.12: IDS - Behatolás Detektáló Rendszer (Intrusion Detection System) minta folyamat és leírónyelv
Fejezetünkben áttekintettük a rendszerszinten fontos technológiákat. Jóval részletesebb leírás

található a referencia könyvben [1] a 8. fejezetben (665-701), a VPN igen alapos áttekintését pedig
a [2] könyvben találhatjuk meg.

• Ismertesd az SSL protokollt!
• Ismertesd az IPSec protokollt!
• Ismertesd az IKE protokollt!
• Ismertesd a tűzfal szerepét, képességeit, ezek részleteit!
• Ismertesd a behatolás érzékelő rendszerek szerepét!

7.6 Kompetenciák és tanulási eredmények 185
[2] Jon C. Snader. VPNs Illustrated: Tunnels, VPNs, and IPsec. Addison-Wesley Professional,
2005. ISBN: 032124544X (cited on page 184).

alapvető igényeivel biztonságát. biztonságát. biztonság növelése
és támadási érdekében.
formákkal. Ismeri a
kriptográfia alapjait.
Ismeri a gyakorlatban Biztonságossá teszi Kezdeményezi Betartja és betartatja
alkalmazott az Internet különböző saját hálózatának a a rendszerek
biztonsági rétegeit. biztonságossá tételét. biztonsági
technikákkal és kritériumait.
technológiákkal.
Tisztában van a
tűzfal képességével
és fontosságával.
3
Függelékek
Bibliográfia 189
Szójegyzék 193
Kompetenciák és tanulási eredmények 215
Ábrajegyzék 218
Bibliográfia
Ron Aitchison. Pro DNS and BIND 10. Berkeley, CA: Apress, 2011. ISBN: 978-1-4302-3049-6.
DOI : 10.1007/978-1-4302-3049-6_3. URL : https://doi.org/10.1007/978-1-4302-
3049-6_3 (cited on page 54).
Attahiru Sule Alfa. Queueing Theory for Telecommunications: Discrete Time Modelling of a Single
Node System. 1st. Springer Publishing Company, Incorporated, 2010. ISBN: 1441973133 (cited
on page 104).
Paul Cernick, Mark Degner, and Keith Kruepke. Cisco IP Routing Handbook. 1st. USA: John
Wiley and Sons, Inc., 2000. ISBN: 0764546953 (cited on page 120).
Jim Doherty. SDN and NFV Simplified: A Visual Guide to Understanding Software Defined
Networks and Network Function Virtualization. 1st. Addison-Wesley Professional, 2016. ISBN:
0134306406 (cited on page 122).
Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno. Cryptography Engineering: Design
Principles and Practical Applications. Wiley Publishing, 2010. ISBN: 0470474246 (cited
on page 32).
Kocsis Gábor. Hálózati architektúrák és protokollok előadás. 2015. URL: http : / / irh . inf .
unideb.hu/~kocsisg (visited on 05/30/2020) (cited on pages 194, 195, 197, 199, 201, 202,
210).
Luc De Ghein. MPLS Fundamentals. 1st. Cisco Press, 2006. ISBN: 1587051974 (cited on page 151).
Robert Gibb. What is TCP Slow Start? 2016. URL: https://blog.stackpath.com/tcp-slow-
start/ (visited on 05/30/2020) (cited on page 205).
IGI Global. IGI Global - Publisher of Timely Knowledge. 2020. URL: https : / / www . igi -
global.com (visited on 05/30/2020) (cited on page 197).
Google. Introduction to HTTP/2. 2018. URL: https : / / developers . google . com / web /
fundamentals/performance/http2 (visited on 05/30/2020) (cited on page 46).
190
Paul Goransson and Chuck Black. Software Defined Networks: A Comprehensive Approach. 1st.
San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2014. ISBN: 012416675X (cited
on page 122).
IETF OAuth Working Group. OAuth 2.0. 2020. URL: https : / / oauth . net / 2/ (visited on
05/30/2020) (cited on page 206).
HTE. HTE Infokommunikációs Fogalomtár. 2020. URL: https://www.fogalomtar.hte.hu/
(visited on 05/30/2020) (cited on pages 193–213).
Vinit Jain and Brad Edgeworth. Troubleshooting BGP: A Practical Guide to Understanding and
Troubleshooting BGP. 1st. Cisco Press, 2016. ISBN: 1587144646 (cited on page 120).
Keith Ross (Author) James Kurose (Author). Computer Networking: A Top-Down Approach (7th
Edition. Pearson, 2016 (cited on pages 2, 9, 20, 32, 35, 69, 101, 124, 127, 184, 211).
Zaigham Mahmood. Fog Computing: Concepts, Frameworks and Technologies. Springer, 2018
(cited on page 10).
Stan Gibilisco Margaret Rouse Matthew Haughn. confidentiality, integrity, and availability (CIA
triad). 2020. URL: https://whatis.techtarget.com/definition/ (visited on 05/30/2020)
(cited on pages 196, 210, 211).
Patrick Marsch et al. 5G System Design: Architectural and Functional Considerations and Long
Term Research. 1st. Wiley Publishing, 2018. ISBN: 1119425123 (cited on page 169).
Hein Meling and Leander Jehl. “Tutorial Summary: Paxos Explained from Scratch”. In: Proceedings
of the 17th International Conference on Principles of Distributed Systems - Volume 8304.
OPODIS 2013. Nice, France: Springer-Verlag, 2013, pages 1–10. ISBN: 9783319038490. DOI:
10.1007/978-3-319-03850-6_1. URL: https://doi.org/10.1007/978-3-319-03850-
6_1 (cited on page 59).
Mozilla. MIME types (IANA media types). 2019. URL: https://developer.mozilla.org/
(visited on 05/30/2020) (cited on page 206).
Inc. Network Sorcery. Network Sorcery. 2020. URL: http://networksorcery.com/ (visited on
05/30/2020) (cited on page 199).
Ruckus Networks. Autonomous System Boundary Routers. 2020. URL: http://docs.ruckuswireless.
com/ (visited on 05/30/2020) (cited on page 195).
OmniSecu.com. OmniSecu.com. 2020. URL: https://www.omnisecu.com/ (visited on 05/30/2020)
William R. Parkhurst. Cisco OSPF Command and Configuration Handbook. Pearson Education,
RFC. Introducing JSON. 2020. URL: https://www.json.org/ (visited on 05/30/2020) (cited on
page 203).
RFC. RFC. 2020. URL: https://tools.ietf.org/ (visited on 05/30/2020) (cited on page 195).
Iain E. Richardson. The H.264 Advanced Video Compression Standard. 2nd. Wiley Publishing,
SDxCentral. SDxCentral. 2020. URL: https://www.sdxcentral.com (visited on 05/30/2020)
(cited on pages 193, 197).
Servira. Servira. 2020. URL: https://servira.com/fogalomtar (visited on 05/30/2020) (cited
on page 206).
Jon C. Snader. VPNs Illustrated: Tunnels, VPNs, and IPsec. Addison-Wesley Professional, 2005.
ISBN : 032124544X (cited on page 184).
191
Lorenzo Spyna. An OAuth 2.0 introduction for beginners. 2018. URL: https://itnext.io/an-
oauth-2-0-introduction-for-beginners-6e386b19f7a9 (visited on 05/30/2020) (cited
on page 45).
Vajda Tamás. Számítógép-hálózatok. 2020. URL: https : / / ms . sapientia . ro / ~vajdat /
education/computernetworks/Szamitogep%20Halozatok%20kabelezese.pdf (visited
on 05/30/2020) (cited on pages 204, 212).
Techopedia. Techopedia. 2020. URL: https://www.techopedia.com/ (visited on 05/30/2020)
(cited on pages 194, 207).
tutorialspoint. tutorialspoint. 2020. URL: https : / / www . tutorialspoint . com/ (visited on
05/30/2020) (cited on pages 206, 212).
Wikipedia. Wikipedia Free Encyclopedia. 2020. URL: https://wikipedia.org/ (visited on
05/30/2020) (cited on pages 193–213).
Yvonne Wilson and Abhishek Hingnikar. Solving Identity Management in Modern Applications:
Demystifying OAuth 2.0, OpenID Connect, and SAML 2.0. Jan. 2019. ISBN: 978-1-4842-5094-5.
DOI : 10.1007/978-1-4842-5095-2 (cited on page 45).
Szójegyzék
Ü, Á, 0-9 | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Z
Ü, Á, 0-9
üzenet azonosító kód Az üzenet azonosító kód (MAC, message authentication code) egy kis
méretű információ, amely a küldőt igazolja, azaz az üzenet az állított küldőtől érkezett és
az nem változott. Az üzenet azonosító kód ezentúl védi az üzenetet is. A vizsgáló a kulcs
ismeretében mindenféle módosítást képes detektálni.[19] 30
üzenetszórási tartomány Az üzenetszórási tartomány egy számítógép hálózat logikai felbontása,
ahol minden csomópont elér minden másikat szórásos üzenet segítségével az adatkapcsolati
rétegben. Egy szórási tartomány értelmezhető ugyanazon a LAN szegmensen belül vagy
áthidalással más LAN szegmensekben is.[19] 111
áramkör-kapcsolt Áramkör-kapcsolt hálózatoknak nevezzük azokat a hálózat típusokat, ahol
a végeszközök közötti kommunikáció csak a beállítást követően jöhet létre. A beállítást
követően az áramkör rendelkezésre áll az eszközök teljes kapcsolatának idejére. Pl.: analóg
telefonhálózat. [14] 14
átjáró Az átjárók azonos protokollokat használó hálózatokat összekapcsoló eszközök, például az
internetszolgáltatók azon eszközeit is szokás átjárónak nevezni, amelyekre a felhasználók
közvetlenül kapcsolódnak, támaszkodva arra az érvelésre, hogy a felhasználó által menedzselt
otthoni hálózatot és a szolgáltató által menedzselt hálózatot köti össze.[5] 109, 142, 146, 148,
153–156, 167, 179, 182, 183, 227
átviteli kapacitás Az átviteli kapacitás egy frekvencia, ami megadja, hogy hány bit halad át egy
adott (fizikai vagy elméleti) „ponton” keresztül. Mértékegysége a bit per szekundum (bit/s).
[19] 14, 15, 37, 63, 134
3DES A 3DES (Triple DES, Triple Data Encryption Algorithm (TDEA)) egy szimmetrikus kulcsú
blokk alapú titkosítás, amely a DES rejtjelező algoritmust háromszor alkalmazza minden
blokkra.[19] 28
3G A 3G egy vezeték nélküli mobilinternet szabvány. A harmadik generációt képviseli, és jóval
nagyobb adatátviteli sebességre képes (akár 21 Mbit/s HSPA + használatával, egyébként
194 Szójegyzék
max. 384 kbit/s), mint a második generációs (2G), GSM-szabványnál legfeljebb 220 kbit/s
az adatátviteli sebesség (EDGE).[19] 10, 16, 167, 168, 172, 227
4G Az információtechnológia 4G-vel a negyedik generációs vezeték nélküli szolgáltatásokat
jelöli. A 2G és a 3G rendszerek utódját, a 4G rendszereket a szakértők szerint egy átfogó
IP-infrastruktúra, nagy adatátviteli sebesség, nagy kapacitás és a nyílt internetes szabványok
használata fogja jellemezni. A 4G-nél a mobil széles sávú rendszer továbbfejlesztett
multimédiás szolgáltatásokkal bővül.[19] 10, 12, 16, 167–169, 173, 175, 227
5G Az 5. generációs mobilhálózat vagy 5. generációs vezeték nélküli hálózat, az angol név alapján
rövidítve 5G, a telekommunikációban az 1G (analóg), 2G (GSM), 3G és 4G/IMT-Advanced
után az 5. generációt képviselő technológiai standard, amelynek bevezetését Dél-Korea
kezdte meg 2019 áprilisában.[19] 16, 168, 169, 175
A
ablak Az adatátvitel gyorsítása érdekében a TCP protokoll nem várja meg a nyugtát minden egyes
szegmens elküldése előtt, mivel az nagyon lassú kapcsolatot eredményezne, helyette több
szegmens elküldését is engedélyezi a nyugta beérkezése előtt. A nyugta előtt elküldhető
szegmensek alkotják az ablakot.[19] 83–87, 91, 96–98, 225
ABR Az ABR (Area Border Router) olyan forgalomirányító, amely egy vagy több OSPF terület
határán található. Ezek jellemzően a gerinc hálózatok vagy az OSPF területek közötti
kapcsolatot teremtik meg.[17] 118
ACK Nyugtázó üzenetet jelölő bit, ezzel jelezvén az üzenet átvételét.[19] 77–79, 82, 87, 88, 90,
92, 153–156, 163
adatkapcsolati réteg Megbízható adatátvitelt biztosít egy fizikai összeköttetésen keresztül. Ezen
réteg problémaköréhez tartozik a fizikai címzés, hálózati topológia, közeghozzáférés, fizikai
átvitel hibajelzése és a keretek sorrendhelyes kézbesítése. Az IEEE két alrétegre (MAC,
LLC) bontotta az adatkapcsolati réteget.[1] 127–130, 132, 133, 135, 139, 141, 146, 147, 152,
155, 158, 169, 174, 226
adatsík A hálózati forgalomirányításban az adatsík a forgalomirányító architektúra azon része,
amely segíti továbbítani a beérkezett csomagokat a megfelelő kimenő interfészre.[19]
102–104, 113, 120, 125, 167, 225, 226
AES Az Advanced Encryption Standard (AES) egy módszer elektronikus adatok titkosítására. Az
AES a Rijndael kódolás olyan változata, ahol a blokkméret szigorúan 128 bit, a kulcs pedig
128, 192 vagy 256 bit.[19] 28–30
AH Az AH (Authentication Header) egy IPSec protokoll, amely adatintegritás, adat eredet
hitelesítés szolgáltatásokat ad hozzá az IP-hez.[11] 179–181, 227
alhálózat Egy alhálózat egy IP hálózat logikai felbontása. Ezt a gyakorlatot nevezik alhálózatokra
bontásnak.[19] 101, 108, 110, 146, 148, 154, 164, 169, 225
API Az API egy program vagy rendszerprogram azon eljárásainak (szolgáltatásainak) és azok
használatának dokumentációja, amelyet más programok felhasználhatnak. Egy nyilvános
API segítségével lehetséges egy programrendszer szolgáltatásait használni anélkül, hogy
annak belső működését ismerni kellene. Az API általában nem kötődik programozási
nyelvhez: bármilyen programnyelvből lehetséges azok meghívása, amennyiben a megfelelő
paramétereket a hívás biztosítja, és képes lekezelni az esetleges eredményt.[5] 43, 45, 47,
120, 121
ARP Az ARP az adatkapcsolati réteg egy protokollja. Elsődleges funkciója, hogy a hierarchikus
kiosztású, hálózatfüggő IP-címet egyszintű (flat) címzési struktúrájú, az eszköz fizikai
címeként használható MAC-címre oldja fel. A lokális számítógép-hálózatokban a csomagok
a fizikai címüket használva juttathatók el a címzetthez, mivel a hálózati csatolók – legalábbis
alapértelmezés szerint – csak azoknak az Ethernet-kereteknek a csomagtörzsét adják fel a
felsőbb rétegek felé, amelyek fejrészében a célpont MAC-cím mező tartalma megegyezik a
Szójegyzék 195
saját címükkel. Az Address Resolution Protocolt az RFC 826 írja le, ez az Internet Standard
STD 37.[5] 141–143, 155, 174, 226
ASBR Egy ASBR (Autonomous System Boundary Router) egy olyan forgalomirányító, amely
több protokollt futtat, és átjáróként szolgál azoknak a forgalomirányítóknak, amelyek az
OSPF tartományon kívül vannak.[10] 118
ASIC Egy alkalmazásspecifikus integrált áramkör (application-specific integrated circuit vagy
ASIC) olyan integrált áramkör, amit nem általános felhasználásra, hanem egy-egy vásárló
specifikus igényének kielégítésére terveznek. Általában több funkciót egyesítenek egy csipen.
Például egy mobiltelefon vezérlését ellátó csip is egy ASIC.[19] 105
aszimmetrikus kulcsú titkosítás Olyan kriptográfiai eljárások, melyek algoritmusai egyetlen
(titkos) kulcs helyett különböző kulcsokat, egy titkos és egy ebből származtatott nyilvános
kulcsot használnak. A rejtjelezés mellett publikus kulcsú kriptográfia segítségével megvalósíthatók
digitális aláírás sémák és kulcsmegegyezés protokollok is. A publikus kulcsú rejtjelező
eljárások (pl. RSA) egy üzenet címzettjének nyilvános kulcsával történő titkosítást tesznek
lehetővé, mely a címzett titkos kulcsával dekódolható. A szimmetrikus kulcsú eljárások
esetén felmerülő kulcscsere-probléma ezzel arra egyszerűsödik, hogy biztosítani kell a
publikus kulcs hitelességét, ami lehetséges pl. hitelesített (de nem feltétlenül titkos) kommunikációs
csatorna használatával vagy PKI segítségével.[5] 30
autonóm rendszer Egy autonóm rendszer (AS, autonomous system) egy vagy több IP-prefix
összekapcsolt csoportja, amelyet egy vagy több hálózati operátor működtet, és amely
egységes és világosan definiált útválasztási elvekkel rendelkezik.[13] 117–119, 126
B
Base64 A Base64 kódolás 64 karakterből álló ábécén alapuló tartalomkódolási forma, melynek
segítségével bináris, illetve speciális karaktereket tartalmazó adatokból ASCII karaktersorozat
állítható elő. Az ily módon kódolt adatok akár a karaktereket 7 biten ábrázoló rendszereken
is könnyen átvihetők.[19] 44
BER A BER (Number of Bit Errors) azon fogadott bitek száma, amelyek az adatfolyamban
módosultak zaj, interferencia, torzítás vagy bit szinkronizáció következtében.[19] 158, 159,
164, 227
beágyazás A (felsőbb szintről érkező) információ egy bizonyos protokoll fejléccel történő becsomagolása
(mint pl. levél küldésekor a borítékba helyezés és boríték címzés).[1] 19, 92, 106, 147, 148,
150, 177, 181, 223, 227
BGP A BGP (Border Gateway Protocol) egy autonóm rendszerek (AS) közötti forgalomirányító
protokoll, mely a különböző AS-ek hálózati adminisztrátorai által meghatározott útvonalak,
hálózati politikák és szabályrendszerek alapján hozza meg az útvonalválasztási döntéseket.
A protokoll két részre osztható: a belső átjáró protokoll (internal BGP, iBGP) egy adott
autonóm rendszer BGP-útválasztói közötti kommunikációt biztosítja, míg a külső átjáró
protokoll (external BGP, eBGP) különböző autonóm rendszerek BGP-útválasztóit köti össze,
azok kommunikációját támogatja. A BGP-protokoll első verzióját 1989-ben publikálták, a
jelenleg használatban levő BGP-4 protokollt 2006-ban szabványosították (RFC 4271), bár
azóta is számos frissítése jelent meg.[5] 119, 125
BitTorrent A hálózati sávszélesség szűkössége növeli a népszerű – gyakran nagyobb méretű –
tartalmakat szolgáltató szerverek válaszidejét. Ennek a problémának a kezelésére szolgál a
BitTorrent protokoll, amely révén a felhasználók nem arról az egyetlen gépről töltik le az
általuk kért tartalmat, amelyen az először volt elérhető, hanem minden más olyan gépről
is érkezhet adat, amelyen már megvan a keresett állomány (nyilván egy korábbi letöltés
eredményeként). A BitTorrent protokoll feltételezi valamely p2p-hálózat létét a háttérben.[5]
57–59, 65
blokk alapú titkosítás A kriptográfiában a blokk alapú titkosítás egy determinisztikus algoritmus,
196 Szójegyzék
amely rögzített hosszúságú bitsorozatokon (blokkokon) hajt végre műveletet változatlan

átalakításokkal, amelyet a szimmetrikus kulcs definiál.[19] 28
botnet A botnet megfogalmazható számítógépek csoportjaként, melyek egymással rosszindulatú
támadások végrehajtása céljából vannak koordinálva. Ezt a számítógépekből álló hálózatot
egy harmadik személy irányítja, hogy rosszindulatú vírusokat, kéretlen elektronikus leveleket
továbbítson vagy indítson támadást meghatározott szerverek ellen.[5] 19, 20
BSS A BSS (Basic Service Sets) olyan eszközcsoportok, amelyek ugyanabba a szolgáltatáshalmazba
tartoznak, és ugyanazzal a fizikai rétegbeli karakterisztikával bírnak (pl.: rádió frekvencia,
biztonsági beállítások).[19] 161
C
CA A Tanúsító Hatóság (Certification Authority, CA) digitális tanúsítványok kibocsátásáért felel.
Egy digitális tanúsítvány hitelesíti egy publikus kulcs tulajdonjogát. Ezen alapszik a digitális
aláírás vagy a publikus kulcsokhoz tartozó privát kulcsok megbízhatósága.[19] 31
CAM A CAM a számítógépes memória azon speciális típusa, amely nagysebességű kereső
alkalmazásoknál használt. A bemenetként megadott (keresett) adatot (tag-et) összeveti
a táblájában tárolt adatokkal, és visszajuttatja azt a címet, amelynél egyezést talál.[19] 106
CDMA A kódosztásos többszörös hozzáférés (CDMA) egy olyan közeghozzáférési megoldás
osztott közegű hálózatoknál, ahol több felhasználó egyszerre használhatja ugyanazt a kommunikációs
csatornát, időszeletek és frekvenciaosztás nélkül. Az interferenciák elkerülésére minden
felhasználó egy külön kódot kap, melynek segítségével az átvinni kívánt keskenysávú jelet
egy szórt spektrumú szélessávú jellé alakítja. A kiosztott kódok egymásra ortogonálisak, azaz
ha a vevő oldalon ugyanazt a kódot alkalmazzuk, vissza tudjuk állítani az eredeti keskenysávú
jelet, egy másik kód alkalmazása esetén viszont ezt a jelet elnyomjuk, mivel az ortogonális
kódok skaláris szorzata nulla.[5] 15, 135, 159–161, 166, 175, 227
CDN Az internet fölötti magánhálózat, mely a globális internet számos pontján, a nyilvános
internethez kapcsolódó szerverekből áll. A CDN-hálózat felépítésében a kiindulópontot a
forrásszerver (Origin Server) jelenti, ahol az eredeti tartalom érhető el. Ezt egészítik ki a
területileg különböző helyeken elhelyezett ún. másolat-szerverek (CDN server), amelyeken
az eredeti tartalom másolata található, földrajzilag elosztva. A szervereket egy nagysebességű,
optimalizált, a belső forgalmat bonyolító magánhálózat kapcsolja össze. A tartalomelosztó
hálózatok lehetővé teszik, hogy a fogyasztókat egy viszonylag közeli szerverről szolgálják
ki, így a tartalomhoz való hozzáférés ideje megrövidül, és kisebb valószínűséggel lesznek
szűk keresztmetszetek az átviteli sávszélességben.[5] 39, 64, 65, 224
CGNAT A CGNAT (Carrier-Grade Network Address Translation) az IPv4-es hálózati tervezés
egyik módszere, ahol a privát címről publikusra történő címfordítást egy köztes dobot
(middlebox) végzi, mint a hálózat része.[19] 109
CIA A CIA (Confidentiality, Integrity and Availability), azaz a Titoktartás, Integritás, Elérhetőség
egy modell, amelynek segítségével adják meg a hálózatok biztonsági leírásait. A titoktartás
jelenti azt a szabályhalmazt, amely az információkhoz való hozzáférést szabályozza, az
integritás garantálja, hogy az információ megbízható és pontos, az elérhetőség pedig a
megbízható hozzáférést írja le a jogosult személyek számára.[7] 23
CIDR A CIDR (Classless Inter-Domain Routing), azaz az Osztálymentes Tartományok Közötti
Forgalomirányítás az IP címzés és forgalomirányítás egyik módszere. 1993-ban leváltotta
az címosztályokra épített címzés architektúráját az Interneten. Célja volt, hogy lelassítsa
a forgalomirányító táblák méretének növekedését az Interneten és az IPv4-es címek gyors
kimerítését.[19] 108, 125
CMTS A CMTS (Cable Modem Termination System) egy berendezés, amelyeket nagy sebességű
adatszolgáltatások (pl.: Internet, VoIP) esetén használnak.[19] 140, 141
CRC A CRC egy hibadetektáló kód, amely segít a nyers adatban bekövetkező változások észlelésében.
Szójegyzék 197
Az adatblokkokhoz egy rövid ellenőrzőösszeg társul, amelyek a maradékos polinomosztás

segítségével kerülnek kódolásra.[19] 132, 144, 147, 164, 165, 174
csillag topológia A csillag topológia csökkenti a hálózati meghibásodás esélyét azzal, hogy minden
csomópont kapcsolatban áll a központi csomóponttal.[19] 143
CSMA A vivőérzékeléses többszörös hozzáférés egy olyan közeghozzáférést vezérlő (medium
access control, MAC) protokoll, amelyben a hálózati csomópont a megosztva használható
szállítóközeg igénybevétele előtt meggyőződik arról, hogy a közeg „üres”, vagyis másik
csomópont által generált forgalom nincs jelen. Ezt olyan módon teszi, hogy a közegben
ellenőrzi az adás („vivő”) jelenlétét és amennyiben észleli azt a csatornán, akkor a saját
forgalomtovábbítását késlelteti.[5] 137, 174
CSMA/CA A CSMA/CA az ütközés elkerülésének az a formája, amikor a csomópontok az
ütközést azzal próbálják meg elkerülni, hogy a forgalmazást csak kihasználatlannak érzékelt
csatornán indítják el. Ha egy csomópont forgalmaz, akkor a teljes csomag adatot forgalmazza.[19]
161, 162, 175
CSMA/CD A CSMA kiegészítéseként használatos technika. Az ütközés érzékelésekor a csomópont
az adatkeret továbbítását leállítja és helyette meghatározott ideig tartó zavarójelet (jam signal)
küld, majd véletlenszerűen kisorsolt időtartamig várakozik az újraküldés lehetőségére. A
CSMA/CD-t a régebbi Ethernet-hálózatokon használták, de a visszafelé való kompatibilitás
miatt még ma is tartalmazza az IEEE 802.3-as szabvány (802.3-2015 - IEEE Standard for
Ethernet).[5] 137, 138, 144, 145, 174
csomag Egy csomag a csomagkapcsolt hálózatok által szállított adat megfelelően formázott
egysége. Egy csomag tartalmazza a vezérlési információkat (fejléc) és az adatot (törzs). A
vezérlési információ biztosítja a szállítási információkat (pl.: forrás és cél címek, hibajavító
kódok, szekvencia információk, stb.)[19] 17, 20, 50, 70, 73, 75–88, 90, 91, 93–98, 103–107,
111, 118–122, 127, 134, 141–143, 145, 146, 148, 150, 153–156, 162, 163, 167, 171, 172,
178, 180, 181, 225, 226
csomageldobás Csomageldobásnak nevezzük azt az eseményt, amikor egy vagy több hálózaton
futó csomag nem ér célba. Csomageldobás bekövetkezhet adatátviteli hiba, pl.: ütközés
miatt.[19] 17
csomagkapcsolt Csomagkapcsolat hálózatok esetén az eszközök között a kommunikáció csomagokra
van bontva. A legtöbb Internet-alapú forgalom csomagkapcsolt hálózatok felett történik.[14]
14, 21, 148
csomagvesztési arány A csomagvesztési arány a fogadóhoz meg nem érkezett csomagok és az
összes elküldött csomag hányadosa.[3] 17
D
DASH A hálózati erőforrásokhoz és a felhasználó eszközének képességeihez alkalmazkodó
streaming megoldás. Általában HTTP-protokoll segítségével történik az adaptív átvitel,
melynek feltétele, hogy az adott médiatartalom különböző minőségben (felbontásban)
rendelkezésre álljon. A rendszer folyamatosan figyeli a felhasználói sávszélességet és
buffer-töltöttséget, majd ennek megfelelően képes a tartalom megfelelő minőségű példányát a
hálózaton továbbítani, akár átvitel közben változtatva azt. Legismertebb adaptív HTTP-streaming
megoldások a HTTP Live Streaming (HLS) és a Dynamic Adaptive Streaming over HTTP
(DASH).[5] 64, 65
demultiplexelés Az kommunikációs csatornán érkező szegmenseket a portszám alapján a csomóponton
belüli folyamatokhoz rendeli.[1] 71, 72
DES A DES a Data Encryption Standard rövidítése. 56 bites kulcs bemenetű szimmetrikus kulcsú,
azaz 1 kulccsal rendelkezik ami privát és csak a titkosítást és visszafejtést végző felek képesek
az adott kulccsal titkos üzeneteket egymással közölni egy csatornán.[19] 28, 30
DHCP Ez a protokoll azt oldja meg, hogy a TCP/IP hálózatra csatlakozó hálózati végpontok
198 Szójegyzék
(például számítógépek) automatikusan megkapják a hálózat használatához szükséges beállításokat.

Ilyen szokott lenni például az IP-cím, hálózati maszk, alapértelmezett átjáró stb.[19] 60, 110,
111, 125, 153–155, 162, 169, 226, 227
DHT A DHT egy decentralizált, elosztott számítógépes rendszerben használt protokoll, ami
lehetővé teszi, hogy adatokat lehessen kikeresni kulcsérték alapján. Az adatpárok a DHT-ben
tárolódnak, és bármely résztvevő el tudja érni ezeket az adatpárokat egy értékük alapján.
A kulcsok és értékek egymáshoz rendelése dinamikusan történik, elosztva a kapcsolódási
pontok között olyan módon, hogy nagy számú kapcsolódási pont kezelhető. A DHT kezeli a
kapcsolódási pontok belépését a rendszerbe, kilépését és az ezek során fellépő hibákat.[19]
58
Diffie-Hellman kulcscsere A Diffie-Hellman kulcscsere egy módszer kriptográfiai kulcsok publikus
csatornán történő biztonságos cseréjére. Ez volt az első publikus kulcsú protokoll, amelyet
Ralph Merkle gondolt ki, valamint Whitfield Diffie és Martin Hellman után neveztek el.[19]
29
digitális aláírás A digitális aláírás lehetővé teszi, hogy a digitális aláírás létrehozója bárki számára
bizonyítsa, hogy egy adott digitális üzenet vagy dokumentum valóban tőle származik és azt
nem módosították. Mindemellett az aláírásnak letagadhatatlannak is kell lennie. A digitális
aláírás megvalósítása publikus kulcsú kriptográfia segítségével lehetséges: az aláíró a titkos
kulcsa és az üzenet segítségével hozhat létre aláírást, amit bárki ellenőrizhet az üzenet és az
aláíró publikus kulcsa segítségével. A publikus kulcsok személyekhez (vagy más entitáshoz)
rendelése a publikus kulcsú infrastruktúra segítségével történik.[5] 31, 44, 56, 65
Dijkstra algoritmus A Dijkstra-algoritmus egy mohó algoritmus, amivel irányított vagy irányítás
nélküli gráfokban lehet megkeresni a legrövidebb utakat egy adott csúcspontból kiindulva.
Az algoritmust Edsger Wybe Dijkstra holland informatikus fejlesztette ki.[19] 115, 118
DMZ Az informatikai biztonság területén a katonai használatra utaló nevű demilitarizált zóna
(DMZ), más néven demarkációs zóna vagy határhálózat egy olyan fizikai vagy logikai
alhálózat, ami egy szervezet belső szolgáltatásait tartalmazza és tárja fel egy nagyobb, nem
megbízható hálózatnak, általában az Internetnek.[19] 183
DNS Az emberek által könnyebben megjegyezhető szimbolikus neveket az IP-hálózati vezérlők
által értelmezhető számokká (IP-címekké) alakító rendszer. A DNS felépítését és működését
az RFC 1034 és az RFC 1035 írják le. Egy fa-struktúrájú rendszer, amelynek gyökereit a
legfelsőbb szintű domain-ek (top level domains) kiszolgálásért felelős eszközök adják.[5] 35,
47, 48, 50–55, 64–66, 73, 107, 111, 112, 154–156, 224, 227
DOCSIS A DOCSIS (Data Over Cable Service Interface Specification) egy nemzetközi távközlési
szabványcsalád, mely lehetővé teszi szélessávú internet-szolgáltatás biztosítását a meglévő
HFC-hálózatokon, melyeket korábban kizárólag kábelTV-szolgáltatás nyújtására használtak.[5]
139, 140, 226
E
EAP Az EAP (Extensible Authentication Protocol) egy autentikációs keretrendszer, amelyet
hálózati kapcsolatok esetén gyakran használnak.[19] 165, 166, 175
ECN Az ECN (Explicit Congestion Notification) az IP kiterjesztése (RFC 3168). Az ECN lehetővé
teszi a vég-vég értesítést a hálózaton előforduló torlódásokról úgy, hogy csomag eldobás
nem történik.[19] 98
EGP Az EGP (Exterior Gateway Protocol) protokoll az Internet forgalomirányítási proktolljla,
amelyet Eric C. Rosen of Bolt és társai specifikáltak 1982-ben. Ezt a protokollt használva
cserél forgalomirányítási információkat egymással két szomszédos átjáró autonóm rendszerek
hálózatában.[19] 117–119
ellenőrző összeg Általános elnevezése az adategységnek arra a részére, amelyet hibadetektálás
vagy hibajavítás céljából adunk hozzá a hasznos bitsorozathoz. Az ellenőrző összeget az
Szójegyzék 199
adatrészből egy specifikus szabály alkalmazásával állítjuk elő.[5] 74–77, 87, 111, 132, 144,
147, 164
elégséges kulcstér elv Egy titkosítási eljárásnak elégséges kulcsteret kell biztosítania annak érdekében,
hogy a nyers erő támadások ne legyenek megvalósíthatóak. 26
Email Privát, címzett, aszinkron, közel valós idejű, írásos, hálózati kommunikációs forma. Megengedi
tetszőleges állomány csatolását az üzenethez.[5] 24, 49, 55, 56, 224
ESP Az ESP fejléc biztonsági szolgáltatásokat nyújt az IPv4-nek és az IPv6-nak. Az ESP
alkalmazható önállóan is, de kombinálva is az AH-val.[9] 179–181, 227
Ethernet A DEC, Intel és Xerox cégek által kidolgozott alapsávú LAN-ra vonatkozó specifikáció.
Az Ethernet hálózatok az ütközések feloldására a CSMA/CD-t használják. Számos kábeltípuson
(koax, csavart érpár, stb.) működik legalább 10 Mbps sebességgel.[19] 12, 18, 102, 103, 106,
107, 121, 132, 137, 143–145, 147, 148, 153–156, 164, 174, 226
F
FDMA A frekvenciaosztásos többszörös hozzáférés (FDMA) egy olyan közeghozzáférési megoldás
osztott közegű hálózatoknál, ahol a különböző felhasználók egy vagy több dedikált frekvencián
kommunikálhatnak folyamatosan, egymástól függetlenül. A frekvenciák kiosztása lehet
statikus vagy dinamikus, attól függően, hogy a kiosztásnál figyelembe vesszük-e az adott
felhasználó aktuális forgalmát.[5] 15, 134, 135, 140, 166, 174, 223, 226
FEC Az előremutató hibajavítás, angolul forward error correction – FEC a hibajavítás egy
rendszere a telekommunikációban. Abban különbözik az általánosan használt hibajavító
rendszerektől, eljárásoktól, hogy arra tervezték, hogy a hibajavításhoz ne legyen szükséges –
ellentétben a többi hibajavító rendszerrel – az üzenet újraküldése.[19] 132
fejléc A távközlésben a fejléc olyan kiegészítő adatokat jelent, amelyek a továbbítandó adatblokkot
megelőzően találhatóak. Az adatot (üzenetet), amely a fejléc után található, törzsnek (body)
szoktuk nevezni.[19] 40–42, 44, 45, 50, 55, 71, 74, 81, 87, 107, 111, 122, 124, 129, 130, 132,
146, 150, 178–181, 227
felhő Az IT infrastruktúrát mint közművet megvalósító szolgáltatás. A felhő infrastruktúra lényege,
hogy virtualizált erőforrásokat bárki bármikor igénybeveheti és ezért annyit fizet amennyit
használta. 9, 10, 26, 35, 36, 47, 57, 59, 101, 112, 127, 169
FIFO A FIFO (First-In-First-Out) elv egy módszer egy adatstruktúrában lévő elemek manipulálására.
Az adat struktúrába legrégebben (elsőként) bekerült elem kerül leghamarabb feldolgozásra.[19]
104
FIN Kapcsolat bontására irányuló kérést jelölő bit.[19] 87, 88, 92
fizikai réteg Elektromos és mechanikai jellemzők procedurális és funkcionális specifikációja két
(közvetlen fizikai összeköttetésű) eszköz közötti jeltovábbítás céljából. Bitek csatornára
bocsátása.[1] 129, 144, 158
folyam alapú titkosítás A folyam alapú titkosítás egy szimmetrikus kulcsú titkosítás, ahol a nyílt
szöveget pszeudorandom rejtjel folyammal kombinálják.[19] 28, 165
folyamvezérlés A folyamvezérlés az a folyamat, amely az adatküldési arányt szabályozza két
csomópont között annak érdekében, hogy a gyors küldők ne árasszák el a lassú fogadót.
Ez a mechanizmus a fogadó kezében van, ő kontrollálja a küldési sebességet az elárasztás
elkerülése érdekében.[19] 71, 91, 93, 128, 130
forgalom intenzitás A forgalom intenzitás mértéke a beérkező csomagok és a kibocsátó képesség
hányadosa.[19] 17, 138
forgalomirányító Egy képesség/szolgáltatás, gyakran egy eszköz amely a hálózati réteg információi
alapján csomagok továbbítását végzi. 11, 14, 15, 17, 18, 20, 36, 57, 69, 70, 80, 93–95, 98,
101–103, 105–108, 110–115, 117–122, 125–127, 146, 148–150, 152, 157, 164, 170, 174,
179, 225
forgalomirányító protokoll Egy forgalomirányító protokoll specifikálja, hogy a forgalomirányítók
200 Szójegyzék
hogyan kommunikálnak egymással (osztják el az információkat). Ez teszi lehetővé két pont

közötti útvonal választását.[19] 18, 113, 114, 117, 125, 126
forgalomirányító tábla A forgalomirányító tábla egy adattábla, amely a forgalomirányítóknál
kerül eltárolásra, amely alapján meghatározza a lehetséges útvonalakat a cél felé. A
forgalomirányító tábla a forgalomirányítót közvetlenül körülvevő hálózatról tartalmaz információkat.[19]
103, 108, 109, 112, 113, 149–151, 179, 227
forró krumpli A forró krumpli (hot potato) kifejezés egy forgalomirányítási gyakorlat, ahol az
autonóm rendszerek közötti forgalomirányítást olyan gyorsan véghez kell vinni, amilyen
gyorsan csak lehet.[19] 120
FSM Egy véges állapot automata (FSM) a működés matematikai modellje, egy olyan absztrakt
gép, amely adott időpillanatban véges állapothalmaz pontosan egy állapotában van.[19] 17,
76–78
FTP IETF szabvány, a TCP/IP protokollcsalád tagja, kliens-szerver protokoll, melyet egy fájlszerverbe
való bejelentkezésre, az ottani fájlkönyvtárak listázására és fájlok átvitelére használnak. Az
FTP ehhez azonosítja a felhasználókat, engedélyezi, hogy átvigyenek fájlokat, listázza a
könyvtárakat, és az idegen szerveren töröljenek és átnevezzenek fájlokat, továbbá végezzenek
wild-card átvitelt. [5] 18, 71, 72
féreg A számítógépes féreg (worm) a számítógépes vírushoz hasonló önsokszorosító számítógépes
program. Míg azonban a vírusok más végrehajtható programokhoz vagy dokumentumokhoz
kapcsolódnak hozzá illetve válnak részeivé, addig a férgeknek nincs szükségük gazdaprogramra,
önállóan fejtik ki működésüket. A férgek gyakran a számítógép-hálózatokat használják fel
terjedésükhöz. Gyakran a felhasználók már csak akkor veszik észre a fertőzést, amikor a
féreg egy duplikációja a rendszer erőforrásait használva lelassítja annak rendes működését.[5]
21
G
gerinc hálózat A gerinc hálózat a számítógép hálózatok azon része, mely biztosítja az információ
(adat) áramlását a hálózat komponensei (helyi hálózatok, alhálózatok) között. A gerinc
hálózat kapacitása jellemzően nagyobb, mint azon hálózatoké, amelyek kapcsolódnak
hozzá.[19] 12–14
GPRS A GPRS egy 2.5G mobil adatátviteli technológia, azaz a második generációs (2G) és
harmadik generációs (3G) mobil hálózatok közötti átmeneti megoldás. Az áramkörkapcsolt
GSM-hez képest a GPRS egy csomagkapcsolt IP-alapú technológia, azaz nincs egy folyamatosan
rendelkezésre álló áramkör kiépítve két végfelhasználó kommunikációjának biztosítására,
hanem helyette IP-csomagok egymást követő független továbbításával valósul meg az
adatátvitel.[5] 167
GSM A GSM a legismertebb és legnagyobb felhasználói bázissal rendelkező második generációs
(2G) mobilkommunikációs technológia, melyet az ETSI szabványosított 1991-ben, és rövid
időn belül a világ több mint 200 országában elterjedt.[5] 128, 166, 167, 177
gyorsítótár A gyorsítótár (cache) a számítástechnikában az átmeneti információtároló elemeket
jelenti, melyek célja az információ-hozzáférés gyorsítása. A gyorsítás egyszerűen azon
alapul, hogy a gyorsítótár gyorsabb tárolóelem, mint a hozzá kapcsolt, gyorsítandó működésű
elemek, így ha ezen területek tartalma korábban már bekerült a gyorsítótárba (mert már
valaki/valami hivatkozott rá korábban), az ilyen adatokat nem a lassú működésű területről,
hanem a gyors cache tárolóból lehet előhívni.[19] 39–41, 44, 46, 48, 50, 52–54, 63, 155, 156,
224
H
heurisztika A problémamegoldás, a felfedezés, a feltalálás, felismerés alkotó tevékenységének
törvényszerűségeit és módszereit tanulmányozza. A heurisztika általában olyan eljárások
Szójegyzék 201
tanulmányozását tűzi ki célul, amelyek függetlenek az eljárások konkrét tárgyától és mindenféle

feladatra alkalmazhatók. A heurisztikus okosodás célja a kitűzött feladat megoldása: nem
végleges és szigorú, hanem csak átmeneti és plauzibilis, sokszor sejtekből indul ki és
eredményesen alkalmazza az indukciós és az analogikus módszereket.[gisfigyelo] 117
HOL A számítógép hálózatokban a HOL (Head-of-line blocking) egy teljesítmény korlátozó
jelenség, amikor egy csomag feltartja csomagok egy egész sorát.[19] 103, 104, 225
hozzáférési hálózat Mindazon egységeket (mint pl. kábelhálózat, átviteli eszközök, stb.) tartalmazó
hálózati rendszer, amely a távközlési szolgáltatások nyújtásához szükséges jelhordozó
képességeket biztosítja a szolgáltatási csomóponti interfész (SNI) és valamennyi hozzá
tartozó felhasználó-hálózat interfész (UNI) között.[5] 15, 20, 141
hozzáférési pont Az előfizetői hozzáférési pont azon hálózati végpont, amelyen keresztül az
előfizető vagy felhasználó egy elektronikus hírközlő végrendszer fizikai és logikai csatlakoztatása
révén hálózati funkciókat és a hálózaton nyújtott szolgáltatásokat vehet igénybe.[5] 161–165,
169, 170
HTML A WWW-projekt által kidolgozott lapleíró nyelv, amely lehetővé teszi, hogy a http-protokollon,
böngészőkön keresztül elérhető, szövegekből, audiovizuális részdokumentumokból, linkekből
álló hálózati dokumentumokat lehessen létrehozni. A tartalmi összetevők mellett tartalmaz
olyan metaadatokat (html-címkéket) is, amelyek a dokumentumok képernyős megjelenítése
miatt szükségesek a gépek számára. Előzménye az SGML volt, amelyet le kellett egyszerűsíteni
annak érdekében, hogy könnyen lehessen vele hipertext-dokumentumokat létrehozni.[5] 37,
41, 65, 182
HTTP A WWW-projekt keretében kidolgozott protokoll (IETF-szabvány), amelyen keresztül
html-nyelven írt hipertext-, hipermédia-jellegű dokumentumokat lehet megjeleníteni és
meghivatkozni hálózatba kötött gépek között. Legfrissebb változata az RFC 7230 szabvány.[5]
9, 17, 18, 23, 31, 35, 37–43, 45–47, 55, 64–66, 71–73, 102, 106, 112, 123, 156, 177–179,
182, 183, 224, 227
HTTPS A https egy URI-séma, amely biztonságos http kapcsolatot jelöl. Szintaktikailag megegyezik
a http sémával, amelyet a HTTP protokollnál használnak, de a https nem önálló protokoll,
hanem csak egy URI séma, mely azt jelzi, hogy a HTTP protokollt kell használni a szerver
443-as TCP portján a HTTP és a TCP szintek közé titkosító/autentikáló SSL vagy TLS réteg
beiktatásával. (A titkosítatlan HTTP rendszerint a 80-as TCP portot használja.)[19] 31, 178
hypervisor A hypervisor olyan szoftver vagy hardver, ami virtuális számítógépek futtatását végzi.
A számítógépet, ami a hypervisort működteti hosztnak (kiszolgáló, virtualizációs szerver)
nevezzük.[19] 112
hálózati réteg Összeköttetést és útvonalválasztást biztosít két hálózati csomópont között. Ehhez a
réteghez tartozik a hálózati címzés és az útvonalválasztás (routing).[1] 69–73, 76, 129, 142,
146
három lépéses kézfogás A TCP kapcsolat kiépítésének három lépését tartalmazza: SYN, SNY-ACK
és ACK lépések. 87, 92, 93, 156, 225
hátsó ajtó A hátsó ajtó egy rejtett módszer az autentikáció vagy titkosítás megkerülésére egy
számítógépben, termékben, beépített eszközben. Leggyakrabban számítógép távoli hozzáférésére
vagy rejtjelező rendszerekben szöveges objektumok kinyerésére használják.[19] 19
I
IANA Az IANA (Internet Assigned Numbers Authority) az ICANN (Internet Corporation for
Assigned Numbers and Names) egy szervezeti egysége, mely felelős az internetes szabványokban
használt globálisan egyedi nevek és számok kiosztásáért. Ide tartozik egyfelől az IP-címek és
az autonóm rendszer azonosítók (AS number) globális tartományának felosztása a különböző
Regionális Internet Regiszterek (RIR) között, a tartománynévrendszer (DNS) gyökérzónájának
a kezelése, illetve egyedi értékek társítása is egy internetes szabványban leírt protokoll
202 Szójegyzék
bizonyos paramétereihez.[5] 41, 42, 107, 110, 119

ICANN Az Internet Corporation for Assigned Names and Numbers (ICANN) egy 1998-ban
alapított nonprofit szervezet, amely az Internet név- és címterére vonatkozó adatbázisok
fenntartását és karbantartását végzi annak érdekében, hogy a hálózat megbízhatóan és
biztonságosan működjön.[5] 48
ICMP Az ICMP (Internet Control Message Protocol) egy interneten használt protokoll, melynek
segítségével értesülhetünk a hibákról illetve azok típusáról, valamint hálózati diagnosztizálásban
lehet a segítségünkre. Az ICMP (az UDP-hez hasonlóan) datagram-orientált kommunikációs
protokoll, mert egyáltalán nem garantált a csomagok megérkezése vagy sorrendje. Az ICMP
(a TCP-hez és az UDP-hez hasonlóan) az IP-t használja borítékként (ICMP csomagok csak
IP hálózaton mehetnek). Az ICMP-t részletesen az RFC 792-ben definiálták.[19] 122, 123,
125, 126, 172, 226
IDS A hálózat és adatvédelmi rendszerek legbonyolultabb és érdekesebb típusa az illetéktelen
hálózati behatolást jelző rendszer (IDS, intrusion detection system). Az IDS legfontosabb
célja és feladata, hogy azonosítsa a hálózatban a gyanús vagy kártékony aktivitásokat,
észrevegyen minden olyan tevékenységet amely eltér a rendszerek normális működésétől.
Naplózza, katalogizálja és osztályozza a rendszerfolyamatokat.[19] 184, 227
időtúllépés Egy hálózati paraméter, amely egy előre rögzített idő elteltével kikényszerített esemény
bekövetkeztére utal.[19] 61, 88–90, 94, 97, 225
IEEE A világ egyik legnagyobb professzionális szervezeteként (több mint 160 országból több
mint 423 ezer taggal), célja világszínvonalú publikációkkal, konferenciákkal, nemzetközi
szabványokat előkészítő tanulmányokkal és szabványokkal elősegíteni az innovációt az
elektronika és az elektrotechnika területén.[5] 11, 141, 144, 147, 157, 160, 161, 166, 175
IETF Az Internet Engineering Task Force (IETF) egy nyitott, nemzetközi szervezet, amely
az internet legfontosabb szabványait definiálja. Az IETF munkacsoportokban (working
group) működik, ezek definiálják a szabványokat RFC (Requests For Comments) formában.
A szabványosítás folyamatát is RFC-k írják le. A munkacsoportok területekbe (area)
szerveződnek, amelyeknek igazgatói tagsággal rendelkeznek az IETF működését irányító
Internet Engineering Steering Groupban. Az IETF-et az Internet Architecture Board (IAB)
felügyeli.[5] 11, 38, 42
IGP Az IGP (Interior Gateway Protocol) protokoll segítségével cserélnek forgalomirányítási
információkat egymással az átjárók az autonóm rendszereken belül.[19] 117–119
IKE Az IKE az a protokoll, amely felállítja az SA-t (Security Association) az IPSec protokoll
használatánál.[19] 180, 184, 227
IMAP Az IMAP-protokoll segítségével történik az elektronikus levelező rendszerekben a levélszervereken
tárolt levelek lekérése a levelező kliensek számára. A másik erre a célra való protokoll a POP,
amelynél az IMAP több szolgáltatást nyújt. Alapelve, hogy a leveleket a levélszerver tárolja,
ezeket a kliens többször is letöltheti, illetve más kilensek is megtehetik ezt. A szerveren
lehetőség van a levelek mappákba szervezésére.[5] 17, 56, 65, 66, 177
interfész (fizikai) Kapcsolódási felület. Az informatika számos területén előforduló fogalom.
Való életből vett példa: Az autót a sofőr egy interészen keresztül irányítja (kormány, pedálok,
kapcsolók).[1] 129, 130, 144–148, 153, 155
IoT A dolgok Internete a hálózatra kötött egymással kommunikálni képes szenzorok és beavatkozó
egységek együttese. 10, 69, 101
IP Az internetprotokoll (angolul Internet Protocol, rövidítve: IP) az Internet (és Internetalapú)
hálózat egyik alapvető szabványa (avagy protokollja). Ezen protokoll segítségével kommunikálnak
egymással az Internetre kötött csomópontok (számítógépek, hálózati eszközök, webkamerák
stb.). A protokoll meghatározza az egymásnak küldhető üzenetek felépítését, sorrendjét
stb.[19] 47, 50, 53, 55, 71, 72, 89, 90, 92, 95, 98, 101, 102, 105–112, 119, 122, 125–127,
Szójegyzék 203
129, 141–143, 146, 148–151, 153–156, 162, 164, 167, 169, 172, 174, 175, 177, 179, 182,
183, 224, 225, 227
IPSec Az Internet Protocol Security (IPsec) egy protokoll csomag az Internet Protokoll (IP) alapú
kommunikáció biztonságosabbá tételére a kommunikációs viszony minden egyes csomagja
hitelesítésével és titkosításával.[19] 177–181, 184, 227
IPv4 Az IPv4 az Internet Protocol 4. verziója, az internetet működtető alapvető protokollok
egyike, amelyet az RFC 791 definiál. Az IPv4 a csomagkapcsolt hálózatokban használható
összeköttetésmentes protokoll, amelynek fő feladatai a végpontok közötti legjobb szándék
szerinti (best effort) csomagtovábbítás – vagyis a címzés egy 32 bites címmel és ennek
alapján a csomag célbajuttatása – és a csomagok feldarabolásának és újbóli összeállításának
támogatása.[5] 18, 49, 103, 109, 111, 112, 124, 125, 177–179, 226
IPv6 Az IPv6 az Internet Protocol 6. verziója, amelyet a jelenleg is széleskörűen használatos
IPv4 leváltására terveztek. Az IPv4 32 bites címeivel szemben 128 bites címeket használ
két 64 bites részre osztva amelyek a hálózatot és azon belül a hosztot azonosítják. Egy
hálózati csatolóhoz több címet is hozzárendelhetünk, lehetővé téve az eszközök nagyobb
mobilitását.[5] 18, 49, 103, 109, 111, 112, 122, 125, 178, 179, 226
ISO-OSI modell Az ISO által szabványosított modell összekapcsolt rendszerek architektúrájának
leírására. A hierarchikus, hét egymásra épülő rétegből álló modell lényege, hogy egy adott
réteg funkcionalitását, valamint a felette ill. alatta lévő rétegek felé az illeszkedést (interfészt)
definiálták, de az adott funkció megvalósítását, tehát a réteg “belsejét” nem. Ez lehetővé tesz
különböző megvalósításokat. Az OSI-modell (gyakran: ISO-OSI-modell) ma már kevésbé
használatos, szerepét más referenciamodellek ill. referencia-architektúrák vették át, mint
amilyen a TCP/IP-architektúra az internet világában, vagy az IEEE 802.X architektúra a
lokális hálózatoknál. [5] 17, 18
ISP Az internetszolgáltató (angolul Internet Service Provider, ISP) egy olyan üzleti vállalkozás
vagy nonprofit szervezet, amelynek feladata a publikus internethez való csatlakozás fizikai és
adminisztratív kialakítása.[19] 12, 21, 40, 125, 140, 151
IXP Egy forgalomkicserélő pont (IXP) egy fizikai infrastuktúrát valósít meg, amelyen keresztül
az Internet szolgáltatók (ISP-k) és a tartalomelosztó hálózatok (CDN-ek) kapcsolódnak, és
Internet forgalmat biztosítanak a hálózataiknak.[19] 12
J
JSON A JSON (JavaScript Object Notation) egy könnyűsúlyú adatcserélő formátum. Ember
számára könnyen írható és olvasható, gépek számára pedig könnyen feldolgozható és
generálható. A JSON alapjai a JavaScript programozási nyelv szabványából (ECMA-262)
származnak. Ez egy szöveges formátum, amely teljesen nyelv független, de más ismert
programozási nyelvekből ismert konvenciókat alkalmaz.[12] 44, 46–48, 124, 224
K
kapcsoló Egy képesség/szolgáltatás, gyakran egy eszköz amely az adatkapcsolati réteg információi
alapján keretek továbbítását végzi. 11, 18, 112, 125, 127, 141, 143, 145–148, 152–154, 157,
174, 226
kapcsoló motor A kapcsoló motor egy topológia, amelyben különböző hálózati csomópontok
vannak egymással összekötve számos kapcsolóval.[19] 103–105
Kerckhoff elve A titkosító metódust nem szabad titokban tartani, az nyugodtan az ellenség kezébe
kerülhet. A titkosság csak a kulcs titkosságán kell, hogy múljon. 25
keret Egy keret a digitális adatátvitel egysége a számítógép hálózatoknál és a távközlésben.
Csomagkapcsolt hálózatok esetén a keret egy egyszerű tárolója a csomagnak.[19] 18, 45, 46,
127–139, 141–150, 153–159, 162–168, 174, 175, 226, 227
kliens Eredeti jelölésben olyan program, amely erőforrásokat, szolgáltatásokat vesz igénybe egy
204 Szójegyzék
ugyanazon vagy másik gépen futó másik programtól, azonban gyakran jelölik vele magát a
kliens programot futtató eszközt is. 11, 36, 39, 41–46, 53, 54, 57–66, 72, 73, 87, 92, 98, 101,
110–112, 124, 164, 165, 224
koaxiális kábel Ez a széles körben használt átviteli közeg. Egy tömör rézhuzalból áll, amelyet
szigetelő burkol. A szigetelőt egy hengeres vezetőveszi körbe, amelyet árnyékolja, a kábelt a
külső zajokkal szemben. Az árnyékolást ismét egyműanyagburkolat zárkörül. Felépítésének
köszönhetően nagyon védett zajokkal szemben, és hosszú távú átvitelre is alkalmas.[16] 15,
143, 144
kommunikációs protokoll Szabályrendszer, mely meghatározza, hogy két kommunikáló fél
hogyan képes egymással kapcsolatot kiépíteni, majd kommunikálni egy kommunikációs
vonalon keresztül. Lehet nyílt és zárt is, előbbieket különböző szervezetek szabányosítják.
Jellemzően egyértelmű interfészeket specifikálnak a szoftverek számára, amelyek a szabályaik
szerint próbálnak kommunikálni. 11
kommunikációs vonal A médium, a közeg, amelyen keresztül a kommunikáló felek kiépítik és
fenntartják egymással a kapcsolatot, lehet vezetékes és vezetékmentes is. 11, 16, 18, 127
kriptográfia A kriptográfia az információvédelem algoritmikus módszereivel foglalkozó tudományág.[5]
25, 33, 54, 55, 185
kriptográfiai kivonat függvény Egy kriptográfiai kivonat függvény (CHF, cryptographic hash
function) egy matematikai algoritmus, amely tetszőleges méretű adatot (üzenetet) rögzített
méretű bit karakterláncként (hash) feleltet meg. Ez egy egyirányú függvény, amely gyakorlatilag
visszafordíthatatlan.[19] 30
kérés-válasz Kérés-válasz az egyik alapvető módszere a számítógépek közötti kommunikációnak,
ahol a kezdeményező számítógép küld egy adatra vonatkozó kérést, majd a fogadó fél
válaszol a kérésre.[19] 41
késleltetés A késleltetés a jel átvitelének ideje a rendszerben vagy hálózaton, pontosabban a jel
adása és vétele között eltelő idő értéke. Digitális átvitelnél a bitfolyam adott bitjének az
adása és ugyanennek a bitnek a vevőoldalon történő vétele közötti időintervallum. Szokás
végpontok közötti (end-to-end) késleltetésnek nevezni. Csomagkommunikációs hálózatokban
egy adott csomag átvitelének ideje a hálózatban.[5] 30, 37, 40, 60, 73, 80, 84, 90, 91, 93, 94,
96, 123, 137–139, 158, 168, 169, 172, 225
kézfogás A biztonságos adatátvitelhez szükséges paraméterek a résztvevők közti megosztása. 73,
87, 144, 178, 180
köd A számítás és a tárolás a vég rendszerekben valósul meg. pl.: kamera feldolgozza a videót és
csak a megszámlát autók számát küldi tovább. 9, 10
közbeékelődéses támadás A közbeékelődéses támadás vagy középreállásos támadás (angolban:
man-in-the-middle attack, MITM) során a két fél közötti kommunikációt kompromittálja
egy támadó úgy, hogy a kommunikációs csatornát (tipikusan valamilyen számítógépes
hálózatot) eltérítve mindkét fél számára a másik félnek adja ki magát. Így a két fél azt
hiszi, hogy egymással beszélget, miközben valójában mindketten a támadóval vannak
csak kapcsolatban, aki így kijátszhatja az ilyen támadásra fel nem készített kihívás/válasz
protokollokat, egyszerűen továbbítva a kihívást a másik félnek, majd visszaküldve annak
válaszát.[19] 32
köztes doboz A köztes doboz (middlebox) egy hálózati eszköz, amely manipulálja a forgalmat, de
nem forgalomirányítási célból.[19] 109, 112
L
LAN A számítógép- és távközlő hálózatokban elterjedt a lefedett terület szerinti osztályozás, mely
szerint megkülönböztetünk LAN-okat (Local Area Network - helyi hálózat), MAN-okat
(Metropolitan Area Network - nagyvárosi hálózat) és WAN-okat (Wide Area Network –
nagyterületű hálózat). A helyi hálózat egy jól körülhatárolt, kis kiterjedésű (tipikusan néhány
Szójegyzék 205
km-es méretű) földrajzi környezetben köt össze felhasználókat egymással, a helyi hálózat
erőforrásaival, illetve a hálózati hierarchia magasabb szintjeivel, mivel a helyi hálózatok
általában egy nagyobb kiterjedésű, sokszor hierarchikus szervezésű hálózatok részei.[5] 11,
127, 128, 132, 137, 141–143, 145, 146, 161, 175, 226
lassú indulás A lassú indulás a TCP által használt algoritmus, amely a hálózati kapcsolat sebességét
hivatott egyensúlyozni. A lassú indulás fokozatosan növeli az elküldött adat mennyiségét
egészen addig, amíg a hálózat maximális fogadó képességét el nem éri.[2] 96, 97, 225
leghosszabb előtag szerinti keresés Mivel forgalomirányító tábla bejegyzései egy alhálózatot
specifikálnak, egy cél cím több tábla bejegyzéssel is egyezhet. A leghosszabb előtag
egyezés szerint az a bejegyzés kerül kiválasztásra, ahol a legmagasabb helyiértékű biteken a
legnagyobb egyezés mutatkozik.[19] 108
legjobb szándék szerinti továbbítás A legjobb szándék szerinti továbbítás esetén a hálózat maga
nem garantálja sem az adat megérkezését, sem a szállításra vonatkozó szolgáltatás minőségét
(QoS).[19] 71, 103
LEO Az alacsony Föld körüli pálya (Low Earth Orbit, rövidítve LEO) olyan műholdpálya, ahol
a Föld felszínétől legfeljebb 2000 km távolságra lévő műholdak keringenek. Mivel a 200
km alatt keringő testek gyorsan veszítenek a magasságukból, ezért általánosan a földfelszín
fölött 200–2000 km-re keringő műholdakra használják ezt a kifejezést. Pályájuk nagy
általánosságban kör alakú, és nagyjából 90 perc alatt kerülik meg a Földet. [19] 13, 16
LSR Az LSR (Loose Source Routing) egy IP opció, amelyet címfordításra használnak. Az IP
hálózatoknál a mobilitást is LSR segítségével implementálják.[19] 107
LTE Az LTE (mozaikszó az angol Long Term Evolution kifejezésből, tükörfordításban „hosszútávú
fejlődés”) egy negyedik generációs vezeték nélküli adatátviteli szabvány, melyet a 3GPP
Release 8 szabvány ír le.[19] 12, 16, 167, 169, 173, 174
M
MAC-cím A MAC-cím (Media Access Control) egy hexadecimális számsorozat, amellyel még a
gyártás során látják el a hálózati kártyákat.[19] 129, 130, 141–143, 145, 146, 153–156, 162,
174
MAC-protokoll Az IEEE 802.X protokollarchitektúra alrétege, amely lokális hálózatokban a
közös átviteli közeg megosztásáért felel. Közös átviteli közeg lehet a legrégebbi lokális
hálózatokban alkalmazott koaxiális kábel, a sokpontos ismétlő (multiport repeater), vagy
vezeték nélküli LAN-oknál a rádiócsatorna.[5] 128, 129, 133, 134, 144, 163, 174
MAN A számítógép- és távközlő hálózatokban elterjedt a lefedett terület szerinti osztályozás, mely
nagyterületű hálózat). A MAN-ok a LAN-oknál lényegesen nagyobb, de nem korlátlanul
nagy területet lefedő hálózatok. Az elnevezés arra utal, hogy tipikusan egy nagyváros területe
az, amelyet a vonatkozó technológiák kifejlesztésénél megcéloztak.[5] 11
MANET A MANET (Mobil Ad-Hoc Network) egy folyamatosan önkonfigurálódó, önszerveződő,
infrastruktúra-mentes mobil eszköz hálózat, ahol vezetékmentes kapcsolat van.[19] 157
metrika Mérési adatok és statisztikák halmaza, amelyek leírják a teljesítményt vagy monitorozzák
az outputok, eredmények és hatások fejlődését. A metrikariportokban mutatókat (indikátorok)
azonosítanak, valamint alapvonalakat, időtartományokat, amelyekben egy előre kitűzött célt
kellene elérni.[5] 16, 17, 114, 115, 158, 226
MIB Az SNMP protokollt kifejezetten bővíthetőre tervezték. Ezt a MIB-ek (management information
base: menedzsment információk csoportja) segítségével érik el. Egy MIB bizonyos eszközök
által használt speciális tulajdonságokat ír le, így külön MIB áll rendelkezésre például
nyomtatók, routerek, vagy szerverek számára.[19] 124, 226
MIME A MIME (Multipurpose Internet Mail Extension) egy szabvány, amely egy dokumentum
206 Szójegyzék
vagy fájl formátumát írja le. Az RFC 6838 definiálja.[8] 18, 41, 46
MPLS Az MPLS, magyarul többprotokollos címkekapcsolás (RFC 3031), csomagkapcsolt hálózatokban
használatos technológia. Az IP feletti szolgáltatások megvalósítását is támogatja. Ez olyan
módon történik, hogy az MPLS-t használó hálózatba való belépéskor a 2. rétegbeli fejléc után
beillesztünk egy MPLS-fejlécet. Az MPLS-fejléc legnagyobb eleme a 20 bites címke. Ezután
az MPLS-képes eszközök a csomagot a címke alapján kezelik, vagyis az IP-hálózatokban
a csomagtovábbítás nem egyedileg, a csomag fejléce alapján történik, hanem az azonos
címkéjű csomagokat ugyanazon az úton továbbítjuk, tulajdonképpen kapcsoljuk. Ezeket
az útvonalakat címkekapcsolt utaknak (label switched path, LSP) hívjuk. Ahhoz, hogy a
kiosztott címkéket – és azt, hogy az egyes címkékhez milyen kezelési szabályok (irányítás,
prioritás) tartoznak – az MPLS-hálózat (tulajdonképpen egy overlay) elemeivel tudassuk,
szükség van az információ terjesztésére, amire a Label Distribution Protocol (LDP, RFC
5036) használatos.[5] 120, 128, 148–151, 174, 227
MSC Az MSC (Mobile Switching Station) egy 2G gerinc hálózat elem, amely vezérli a hálózat
kapcsoló alrendszer elemeit.[19] 166, 167, 173, 174
MSS Maximális szegmens méret, amely a TCP fejlécének egyik mezője. Ez jelöli a szegmensenkénti
adat méretet bájtokban megadva. 87, 96, 97
MTU Az MTU a Maximum Transmission Unit, vagyis a Maximális Átviteli Egység rövidítése.
Az MTU egy hálózati kifejezés, és azt határozza meg, hogy mekkora az a maximális
csomagméret, melyet a hálózaton keresztül küldhetünk.[15] 106, 107
multiplexelés Multiplexelés alatt a telekommunikációban azt az eljárást értik, amikor két vagy több
csatornát összefognak egy csatornába úgy, hogy a demultiplexeléssel elő tudják állítani az
eredeti csatornákat. Az eredeti csatornák egy úgynevezett kódolási sémával azonosíthatóak.[19]
71–74, 87, 225
N
NAT A nevéből következően a NAT (Network Address Translation vagy Network Address
Translator) egy hálózati címeket cserélő/fordító/virtualizáló protokoll. A NAT egy aktív
hálózati építőelem, amelyet tipikusan két hálózatot köt össze. A belső hálózaton általában
olyan IP-címtartományt használunk, amelyet az útvonalválasztók nem továbbítanak. A külső
hálózat irányában általában néhány, a belső hálózaton elhelyezkedő számítógépek számához
képest kevesebb számú csatolóval (és ennek következtében hálózati címmel) rendelkezik,
viszont az ezekről származó forgalmat a hálózati útvonalválasztók továbbítják. Ennek az
eljárásnak az általános szaknyelvi megnevezése az IP masquerading.[5] 69, 101, 109, 110,
112, 113, 125, 182, 226
NFV Az NFV (Network Functions Virtualization) a hálózati szolgáltatások (pl.: tűzfal, forgalomirányítás)
virtualizációja, amelyeket hagyományosan fizikai eszközök valósítanak meg. A szolgáltatások
virtuális gépek formájában érhetőek el.[19] 112, 113
NIC Az NIC (Network Interface Card) egy hardver komponens, amelynek hiányában egy számítógép
nem tud hálózathoz csatlakozni. Ez egy számítógépbe telepített áramköri lap, amely hálózati
kapcsolatra kínál lehetőséget.[18] 130, 137, 141
nyugta A megbízható kézbesítés garantálja, hogy a kommunikáció során elküldött adatok veszteség,
vagy kettőződés nélkül elérik a céljukat.[19] 79, 87, 88, 90–92, 97, 225
O
OAuth 2.0 Az OAuth 2.0 ipari szabvány protokoll a jogosultságkezelésre. Az OAuth 2.0 a
fejlesztők tekintetében az egyszerűségre fókuszál, miközben specifikus autorizációs megoldásokat
biztosít web-alkalmazásoknak, asztali alkalmazásoknak, mobil alkalmazásoknak és egyéb
eszközöknek. A specifikáció és annak kiterjesztései az IETF OAuth Working Group
fejlesztésein belül történik.[4] 43–46, 224
Szójegyzék 207
optikai kábel Az optikai szál egy igen tiszta, néhány tíz (a technológia megjelenése idején
még néhány száz) mikrométer átmérőjű üvegszálból és az ezt körülvevő, kisebb optikai
törésmutatójú héjból álló vezeték. Működési elve a fénysugár teljes visszaverődésén alapul:
A fénykábel egyik végén belépő fényimpulzus a vezeték teljes hosszán teljes visszaverődést
szenved, így a vezeték hajlítása esetén is – minimális energiaveszteséggel – a szál másik
végén fog kilépni.[19] 12, 13, 15, 144, 223
OSPF Az Open Shortest Path First (OSPF) az egyik legismertebb tartományon belüli (intra-domain)
útválasztó algoritmus, mely kapcsolat-állapot hirdetések használatára épül. Minden útválasztó
hirdeti a teljes hálózatban, hogy mely másik útválasztóval áll közvetlen kapcsolatban, és
milyen ennek a kapcsolatnak az állapota, mekkora a költsége. E hirdetések alapján minden
csomópont egységes módon felépíti saját magánál a tartományon belüli teljes hálózati
topológiát, ezen pedig a Dijkstra-algoritmust futtatva kiszámolja a legrövidebb utakat bármely
forrás-cél címpárra.[5] 117–119, 123, 125, 151, 226
P
P2P A Peer-to-Peer (P2P, magyarul kb. egyenrangú) modell olyan hálózati architektúra, melyben
nincs központosított erőforrás-elosztás és a csomópontok kliens- illetve szerverfunkciókat
is egyszerre látnak el. A P2P-hálózatba kötött számítógépek egyikének sincs kitüntetett
szerepe a hálózati architektúra szempontjából, ellentétben a hagyományos kliens-szerver
modellel, ahol az erőforrásokat, szolgáltatásokat dedikált szerverek nyújtják a hozzájuk
kapcsolódó kliensek számára. A gépek emellett erőforrásaik egy részét a többi gép számára
is rendelkezésre bocsátják a hálózaton keresztül. A P2P-hálózat két csomópontja tehát
közvetlenül egymással kommunikál, az üzenetküldésnél nincs szükség további szereplőre.
A P2P modell legismertebb alkalmazási területét az ingyenes zene- és filmletöltést segítő
fájlcserélő rendszerek jelentették, de erre a modellre épülnek a közösségi gazdaság (sharing
economy) egyre népszerűbb alkalmazásai is.[5] 35, 36, 57, 58, 64–66, 110, 113, 120, 121,
125
PAN A személyi hálózatok a PAN-ok (Personal Area network) olyan számítógép hálózatok,
amelyet egyes embereknek szántak. Például egy vezeték nélküli hálózat, amely az egeret
összeköti a számítógéppel.[19] 11, 160, 162, 227
paritásbit Egy paritásbit egy karakterlánc bináris kódjához hozzáadott bit. A paritásbit használata
a hibadetektáló kód legegyszerűbb formája.[19] 131, 226
paritásteszt A paritásteszt az a folyamat, amely alátámasztja, hogy az adatátvitel két csomópont
között pontosan megtörtént.[17] 131
PGP A PGP (Pretty Good Privacy) egy széles körben elterjedt szoftver, mely fájlok (e-mailek)
digitális aláírását, rejtjelezését és visszafejtését teszi lehetővé. A kereskedelmi forgalomban
lévő PGP mellett, az eredeti PGP-forráskódból kiinduló OpenPGP nyílt szabvány szabadon
hozzáférhető.[5] 56, 57, 65, 178, 224
PKI A nyilvános kulcsú infrastruktúra (angol nevén: public key infrastructure, röviden: PKI)
szerepek, irányelvek, eljárások sorozata, amely ahhoz szükséges, hogy létrehozzunk, kezeljünk,
terjesszünk, használjunk, tároljunk és visszavonjunk digitális tanúsítványokat, illetve kezeljük
a nyílt kulcsú titkosításokat. A PKI célja, hogy megkönnyítse az információ biztonságos
áramlását és továbbítását számos munkaterületen, többek között az e-kereskedelem, az
internetes bankolás, illetve a bizalmas e-mailezés terén.[19] 23, 32
pont-pont Egy-egy ágens van a kommunikációs helyzet két oldalán, az adó és vevő pontokon.
Általában címzési technikával lehet biztosítani. Példa rá a telefonálás, két ember közti
párbeszéd, email, levél, chat. Ugyanebben az értelemben használják még a 1:1-es vagy az
egy az egyhez kommunikáció kifejezéseket is.[5] 76, 87, 110, 132, 181
POP3 A POP-protokoll segítségével történik az elektronikus levelező rendszerekben a levélszervereken
tárolt levelek lekérése a levelező kliensek számára. A POP a legegyszerűbb erre a célra
208 Szójegyzék
alkalmazott protokoll, egy másik, fejlettebb, több szolgáltatást lehetővé tevő lekérdező
protokoll az IMAP. A kliens és a szerver közötti azonosítást követően a kliens letölti a levelet
és leggyakrabban törli is a szerverről. Lehetőség van arra is, hogy a szerveren ne törlődjön,
ebben az esetben egy másik kliensről a levél újra lekérdezhető. Jelenleg használt változata a
POP3.[5] 56, 65, 66, 177
port A számítógép hálózatoknál a port egy kommunikációs végpontot jelöl. Szoftver szinten, a
port egy logikai objektum, amely azonosít egy processzust vagy hálózati szolgáltatást.[19]
18, 49, 72, 74, 87, 103, 109, 121, 145, 153, 155, 156
PPP A Pont-pont protokoll (általánosan használt rövidítéssel: PPP az angol Point-to-Point Protocol
kifejezésből) egy magas szintű adatkapcsolati protokoll kétpontos vonalakhoz. Széleskörűen
alkalmazott megoldás az Internetben.[19] 132
processzus Egy processzus egy számítógépes program példánya, amelyet egy vagy több szál
futtat. Operációs rendszertől függően egy processzus futhat több szálon is, ahol a műveletek
konkurens módon futhatnak.[19] 18, 37, 101, 105, 118
protokoll verem A protokoll verem egy vagy több protokoll (szoftveres) implementációja.[19] 20,
37, 177, 181
Proxy Proxy szervernek nevezzük az olyan szervereket, amelyek kliensek megbízásából tevékenykednek,
és azok kéréseit (request-jeit) továbbítják azokhoz a szerverekhez, vagy azon szerverek
felé, amelyek a kéréseket ki tudják szolgálni, továbbá a szerverek felől érkező válaszokat
(response-okat) továbbítják a klienseknek. Szűrik és feldolgozzák valamennyi hozzájuk
érkező IP-csomagot, és eldöntik, hogy a klienstől hozzájuk érkező kérésekből melyek azok,
amelyeket saját gyorsítótárolójukból ki tudnak szolgálni és melyeket küldjenek ki egy távoli
szerverre a kliens nevében. A proxyk legfontosabb feladatai: szűrés vírusok és kártékony
szoftverek ellen, erőforrások elérésének felgyorsítása.[5] 42, 43, 224
PWA A PWA olyan web-alkalmazás, amely a legismertebb web technológiákkal készült (HTML,
CSS, JavaScript). Működését tekintve elvárt, hogy minden olyan platformon működjön,
amely a szabványoknak megfelelő böngészőket támogatja. Funkcionalitásai közé tartozik
az offline működés, push értesítés, eszköz hardveres hozzáférése. Asztali gépen és mobil
eszközön is hasonló a felhasználói élménye a natív alkalmazásokéhoz. [19] 40
Q
QoS A szolgáltatásminőség (quality of service, QoS) az infokommunikációs hálózatok egyes
szolgáltatási osztályaira előírt műszaki jellemző paraméterek összessége, amely biztosítja
az egyes szolgáltatásosztályok megfelelő minőségét a szolgáltatási osztályok felhasználói
számára, bármely időszakban.[5] 16
R
REST A REST (Representational State Transfer) egy szoftverarchitektúra típus, elosztott kapcsolat
(loose coupling), nagy, internet alapú rendszerek számára, amilyen például a világháló. A
Representational State Transfer kifejezést Roy Fielding vezette be és definiálta 2000-ben a
doktori disszertációjában. Fielding egyike a HTTP (HyperText Transfer Protocol) specifikáció
szerkesztőinek.[19] 35, 41, 46–48, 120, 121, 224
RSA Ronald Rivest, Adi Shamir és Leonard Adleman (valamint tőlük függetlenül Clifford Cocks)
által kifejlesztett publikus kulcsú rejtjelező eljárás, mely napjainkra széles körben elterjedt.
Az SSL/TLS protokoll része.[5] 29, 33
RTS-CTS Az RTS-CTS jeleket eredetileg egyidejűleg egyirányú modemekre tervezték (pl.: Bell
202). Az adó és a vevő között az RTS és CTS üzenetek jelzik az adatküldés kezdetét, és
egyidejűleg a többi küldő csomópont tiltását.[19] 163, 164
RTT Az RTT (round-trip-time) a távközlésben az adat küldésétől a megérkezésről szóló nyugta
fogadásáig eltelt idő.[19] 51, 81, 88, 89, 96, 97
Szójegyzék 209
S
SA Az SA (Security Association) teszi lehetővé, hogy közös biztonsági attribútumokat alkalmazzon
két egyed, ezzel is támogatva a biztonságos kapcsolatot.[19] 180, 181
SDN Egy megoldás olyan számítógép-hálózatok létrehozására, melyekben elkülönül az úgynevezett
kontroll-sík, azaz az alrendszer mely eldönti hova küldjük a forgalmat, és az adat-sík, mely
magát az adattovábbítást végzi a választott célállomás felé. Ez a technológia egyszerűsíti a
hálózatok működését, és lehetővé teszi, hogy a kontroll-sík közvetlenül programozható legyen
egy hálózati adminisztrátor által, aki így központilag felügyelheti a hálózati forgalmat anélkül,
hogy fizikai hozzáférésre lenne szüksége a különböző hálózati hardver eszközökön.[5] 36,
101, 105, 112, 113, 118, 120–122, 125, 226
set-top-box DVB-jeleket vevő, dekódoló és videó- és audiójelekké visszaalakító előfizetői eszköz.[5]
12
SIEM A SIEM (Security Information and Event Management) a számítógépes biztonság egy
részterülete, ahol a szoftver termékek és a szolgáltatások egyesítik a biztonsági információ
menedzsmentet (SIM) és a biztonsági esemény menedzsmentet (SEM). Lehetővé teszik az
alkalmazások és a hálózati eszközök által generált riasztások valós idejű vizsgálatát.[19] 183,
184, 227
SMTP Az SMTP az elektronikus levelező rendszerekben a levelek továbbítását végző protokoll.
Amikor az SMTP-kliens levelet szeretne küldeni, kétirányú kapcsolatot hoz létre az SMTP-levélszerverrel,
amely lehet a levél végső állomása. Ha nem az, akkor a küldő levélszerver SMTP-protokoll
segítségével továbbítja a levelet a címzett kliens levélszerveréhez. A kliensek és a szerverek
közötti, illetve a szerverek közötti adatcsere az SMTP-protokoll alkalmazásával történik.
Az SMTP az üzenetek továbbítására a TCP-protokollt használja. Megjegyezzük, hogy az
SMTP-protokollnak nem feladata a leveleknek a címzett kliensnek való eljuttatása, ezt a
feladatot más protokollok, a POP ill. az IMAP látják el.[5] 55, 56, 65, 66, 224
SNMP Az SNMP a Simple Network Management Protocol, azaz az egyszerű hálózat menedzsment
protokoll rövidítése. A TCP/IP család része, az IETF hozta létre. AZ SNMP protokoll egy
egyszerű "kérdezz-felelek" protokollnak tekinthető, ahol az NMS-en (Network Management
System) futó alkalmazások folyamatosan vagy egy előre meghatározott időközönként lekérdezik
a felügyeleti eszközökhöz rendelhető változókat, amelyek valamilyen választ fognak adni
további feldolgozás céljából. Lényeges, hogy egy elosztott felügyeletű protokollról van szó,
amely a hálózatra kötött eszközök vezérlését, adatainak lekérdezését szolgálja.[19] 122–125,
226
SNR Jel-zaj viszony, angol kifejezéssel Signal-to-noise ratio (rövidítésekben SNR vagy S/N)
a hasznos és a zavaró jel (zaj) aránya dB-ben kifejezve. Általában a villamosmérnöki
gyakorlatban használatos, de informálisan, a kifejezést használják különböző internet szolgáltatásokkal
kapcsolatosan tágabb értelemben is, például Usenet.[19] 158, 159, 164, 227
SPAM A spam a fogadók által nem kért, elektronikusan, például e-mailen keresztül tömegesen
küldött hirdetés, felhívás vagy lánclevél. [19] 55
SPI Az SPI egy azonosító mező hozzárendelése a fejléchez IPSec használatakor. Ez a mező segít
megkülönböztetni két forgalmat egymástól, ahol eltérő titkosítási szabályok és algoritmusok
lettek alkalmazva.[19] 180
SSID Minden vezeték nélküli helyi hálózatot (WLAN) egy egyedi hálózatnév azonosít. Ez más
néven az SSID (Service Set Identifier, szolgáltatáskészlet-azonosító). A WiFi hálózati adapter
beállításakor meg kell adni az SSID-t. Ha létező WLAN-ra szeretne csatlakozni, akkor annak
a nevét kell használnia. Ha saját WLAN-t hoz létre, akkor Ön választhat nevet, és minden
számítógépen ezt a nevet kell használnia. A név legfeljebb 32 karakterből állhat, és csak
betűket és számokat tartalmazhat. Az SSID vagy hálózatnév a hozzáférési pontban vagy
vezeték nélküli útválasztóban adható meg.[19] 162
210 Szójegyzék
SSL Az SSL (Secure Sockets Layer) egy kriptográfiai protokoll, amellyel biztonságos HTTP feletti
kommunikációt tettek lehetővé a hálózaton.[19] 177–180, 184, 227
SYN Szinkronizációs üzenet, kapcsolat létrehozására, illetve fenntartására irányuló kérést jelölő
bit. Emellett a sorszámok szinkronizálása is ezen bit segítségével történik.[19] 87, 88, 92,
156
szegmens Az Internet terminológiában szegmenseknek nevezzük a szállítási rétegben előállított
csomagrészeket, melyek tartalmazzák az alkalmazás rétegbeli üzenetet. 18, 70, 72, 74–76,
87, 88, 90–92, 96, 103, 106, 153, 155, 156, 225
szekvencia szám A szekvencia szám az aktuálisan küldendő adat első bájtját jelöli, amelynek
értéke a legutóbb beérkezett nyugtaszámnál 1-gyel nagyobb.[19] 78, 79, 81, 83–88, 90–92
szerver Egy ugyanazon vagy másik eszközön futó program vagy processz, amely szolgáltatásokat,
erőforrásokat biztosít a kliens alkalmazások számára. A klienshez hasonlóan a szerver is
jelölheti magát az eszközt is, melyen a szerver alkalmazás fut. 10, 11, 17, 20, 24, 36, 37,
39–44, 46, 49–66, 72, 73, 87, 92, 98, 101, 102, 110–113, 124, 128, 152–156, 165, 166, 178,
182, 183, 224, 227
szimmetrikus kulcsú titkosítás A szimmetrikus kulcsú rejtjelező eljárásokban a titkosításhoz
és dekódoláshoz használt kulcs azonos. Ennek megfelelően a biztonságos kommunikáció
megkezdése előtt a feleknek meg kell egyezniük a felhasznált (titkos) kulcsban.[5] 28
szoftvercsatorna A számítógép-hálózatokban a szoftvercsatorna, csatlakozó, Internet socket vagy
egyszerűen socket egy Internet Protocol-alapú számítógépes hálózatban, például az interneten
valamely kétirányú folyamatközi kommunikációs (IPC) hálózati folyam végpontja.[19] 37,
71, 72
szállítási réteg Megbízható hálózati összeköttetést létesít két csomópont között. Feladatkörébe
tartozik pl. a virtuális áramkörök kezelése, átviteli hibák felismerése/javítása és az áramlásszabályozás.[1]
69–76, 78, 87, 93, 129, 151
sávszélesség Sávszélességen az elektromos jelek frekvenciatartománybeli komponensei – röviden:
spektruma – által elfoglalt, illetve ezek által igényelt tartomány nagyságát értjük.[5] 16, 17,
57–59, 63, 64, 73, 94, 97, 98, 105, 114, 115, 135, 138, 172
T
TCAM A TCAM (Ternary Content-Addressable Memory) egy speciális típusa a nagy sebességű
memóriának, amelyben a keresési műveletek a teljes tartalmon egyetlen órajelen belül.[7]
106
TCP A TCP/IP-protokollarchitektúra összeköttetés-alapú szállítási protokollja, amely a hálózat
végpontjaiban futó alkalmazások (pontosabban:processzek) közötti kapcsolatok felépítéséről,
fenntartásáról és lebontásáról gondoskodik. Fő szolgáltatásai a processzek közötti megbízható
adatátvitel biztosítása. A megbízható átvitelt nyugtázási-újraküldési mechanizmus alkalmazásával
valósítja meg. A végpontok egyes alkalmazásait speciális címek, ún. portszámok segítségével
éri el.[5] 14, 18, 41, 46, 51, 55, 64, 69, 71–73, 76, 87–93, 95–99, 104, 106, 109, 119, 121,
144, 156, 172, 177–179, 225
TCP/IP A TCP/IP-architektúra az internet elődjének, az ARPANET-hálózatnak a megalkotásakor
bevezetett négy rétegű protokoll-architektúra, az internet és a számítógép-hálózatok világában
ma is elterjedten használatos, gyakran internet-protokollarchitektúrának is nevezik. A
négy réteg közül a két középső, a hálózati vagy internetworking réteg és a szállítási vagy
host-to-host réteg a legfontosabbak, az azokat megvalósító IP- ill. TCP-protokollokkal, innen
az architektúra neve. Minden további, a TCP/IP-protokollegyüttest használó internet-protokollt
a legfelső, alkalmazási (application) rétegbe soroltak, és minden, az IP-csomagokat továbbító
protokoll - mint amilyenek a lokális hálózaton belüli és a fizikai kommunikációt megvalósító
protokollok -, pedig a legalsó, az ún. interfész-, vagy link-rétegbe tartozik.[5] 17, 18, 21, 167,
223
Szójegyzék 211
TDMA Az időosztásos többszörös hozzáférés (TDMA) egy olyan közeghozzáférési megoldás

osztott közegű hálózatoknál, ahol több felhasználó használhatja párhuzamosan ugyanazt
a frekvenciacsatornát, különböző időszeletekben. Az időszeletek kiosztása lehet statikus,
amikor a felhasználók egyforma hosszúságú időszeleteket kapnak, függetlenül a forgalomtól,
illetve dinamikus (adaptív), amikor az időszeletek mérete az egyes felhasználók aktuális
forgalmi igényétől függ. A TDMA-rendszerek működéséhez szükséges az, hogy azok a
csomópontok, melyek ugyanazt a rádiós csatornát használják, egymással folyamatosan
szinkronizálva legyenek.[5] 15, 134, 166, 174, 223, 226
TE A TE segítségével oszlik meg a sávszélesség terhelése a teljes hálózati vonalon.[7] 120
teljes rács Egy teljes rács (crossbar) kapcsolók sorozata egy mátrix konfigurációba szervezve
(rendezve). Egy teljes rácsnak több bemeneti és kimeneti vonala is van, amelyek rács
mintában metszik egymást, a metszéspontok pedig kapcsolókat jelölnek.[19] 105
Telnet A Telnet lényege, hogy a saját számítógépéről be tud jelentkezni egy másik (mindegy,
hogy a világ melyik részén lévő) számítógépre. Az FTP-vel és a Gopher-rel csak az ott lévő
adatokat érte el, Telnet esetében programokat is futtathat a távoli (remote) gépen.[19] 71, 88,
177, 225
TLS A TLS (Transport Layer Security) egy, az interneten használt biztonsági protokoll, mely
biztonságos hálózati kommunikációt tesz lehetővé a TCP-t használó alkalmazások között.
Mivel a web-szerverek és böngészők szinte kivétel nélkül támogatják, a TLS felel a hitelesített
és biztonságos kliens-szerver kommunikációért, lehetővé téve a biztonságos elektronikus
kereskedelmet és web-böngészést.[5] 31, 41, 166, 178, 181
TOR A TOR (Top of Rack) tervezés során a szerverek egy vagy két Ethernet kapcsolóhoz
csatlakoznak, amelyek egy rack-ben találhatóak, így a szerver minden kábele ugyanabban a
rack-ben fut. A rack az adatközpontba egyetlen vonalat használva kapcsolódik.[19] 152, 153
torlódásvezérlés A torlódásvezérlés a TCP által használt algoritmus, amely az AIMD (additive
increase/multiplicative decrease), lassú indulás és ütközési ablak sémákra épít. A TCP
torlódásvezérlés az Interneten alkalmazott torlódásvezérlés alapja.[19] 71, 93, 95–97
trójai Számítógépes értelemben a trójai program olyan rosszindulatú program, amely mást tesz
a háttérben, mint amit a felhasználónak mutat. A vírusokkal ellentétben általában nem
többszörözi önmagát, terjedése főként egyedi támadásoknak és az emberi hiszékenységnek
köszönhető.[19] 19
TTL Az internetprotokoll esetében ez a csomagok fejlécében található számláló. Valójában nem
idő mérőszáma, hanem „hop count”, amit minden aktív eszköz (útválasztó (router)) csökkent.
Ha egy aktív eszköz 0-nak látja a TTL-t, akkor egyszerűen eldobja a csomagot.[19] 50, 52,
106, 122, 141, 142, 150
távolságvektor A távolságvektor az egy pontból minden más elérhető pontba irányuló útvonalak
becsült költségeinek a vektora.[6] 115–118, 125, 126
törzs A távközlésben a törzs a továbbított adat azon része, ami a fogadónak szánt tényleges üzenet.
A fejléc és metaadatok teszik lehetővé a törzs továbbítását.[19] 41, 42, 44, 56
tűzfal A tűzfal egy hálózati biztonsági rendszer, amely egy előre megadott szabályrendszert
követve megfigyeli és vezérli a beérkező és a kimenő forgalmat. Felfogható úgy is, mint az
általunk biztonságosnak tekintett és a nem megbízható hálózat közötti elválasztó korlát. A
tűzfal lehet egy konkrét hálózati eszköz vagy egy hálózati eszközbe telepített szoftver illetve
egy számítógépen futó processz vagy démon. Az előbbi esetben két hálózat között szűri a
forgalmat, az utóbbiban egyetlen számítógép hálózati forgalmát kontrolálja.[19] 112, 113,
181–185, 227
U
UDP A TCP/IP-protokollarchitektúra összeköttetésmentes szállítási protokollja, amely a hálózat
végpontjaiban futó alkalmazások (pontosabban: processzek) közötti kommunikációról
212 Szójegyzék
gondoskodik. A végpontok egyes alkalmazásait speciális címek, ún. portszámok segítségével

éri el. Szemben a TCP-vel, nem biztosít megbízható adatátvitelt a processzek között,
mindössze két egyszerű szolgáltatást nyújt: portkezelést és hibaellenőrzést. Az UDP-t
késleltetés-érzékeny alkalmazásoknál, pl. beszédátvitelnél célszerű használni, ahol nem
megengedhető a megbízható átvitelt megvalósító TCP által okozott késleltetés. Ugyanakkor
nem is kell megkövetelni azt, hogy minden egyes adategységet biztosan és hibamentesen
megkapjon a címzett, bizonyos, nem túl nagy számú adatcsomag “elvesztését” az alkalmazás
tolerálja.[5] 69, 71–75, 87, 97, 98, 153–155, 167, 172, 225
URI Egységes erőforrás azonosító. Adott protokollon keresztül, valahogyan hozzáférhető dokumentumok,
erőforrások egységes és egyértelműsített azonosítását és elérését biztosító technika, megoldás.
Két fő típusa van, az URL és az URN.[5] 37, 38, 65, 224
URL Az URL (Uniform Resource Locator) egységes erőforráscímző megoldás: adott protokoll
szerint, a világhálón keresztül hozzáférhető dokumentumok, erőforrások elérését biztosító
hálózati cím megadása.[5] 38, 39, 41, 45, 46, 53, 64, 65, 124
URN Az URN (Uniform Resource Name) egységes erőforrás megnevezés olyan hivatkozási
rendszer, amely során a dokumentum, erőforrás egyértelmű azonosítását névterek segítségével
oldják meg.[5] 38
UTP A legrégebbi és még ma is elterjedt átviteli közeg acsavart érpár (Unshielded Twisted Pair =
UTP). Két szigetelt rézhuzalból áll tipikusan 1 mm-es átmérővel. A huzalok egymás köré
spirálisan vannaktekerve, hogy csökkentsék az egymás közöttielektromos kölcsönhatást.[16]
15
V
VANET A VANET-et (Vehicular Ad-Hoc Network) járművek és országúti berendezések közti
kommunikációra használják. Az InVANET (Intelligent Vehicular Ad-Hoc Network) egy
mesterséges intelligenciával felruházott megoldás, amely segíti a járműveket a döntéshozásban
(pl.: ütközés, baleset felismerése). A járművek rádióhullámokat használnak a kommunikációra.[19]
157
vezérlősík A hálózati forgalomirányításban a vezérlősík a forgalomirányító architektúra azon
része, amely a forgalomirányító táblában tárolt információkat kezeli. Ez definiálja, hogy egy
beérkező csomagot mely útvonalon kell továbbítani.[19] 104, 113, 125, 167, 169, 225, 226
VLAN A számítógép-hálózatok körében a virtuális helyi hálózat vagy látszólagos helyi hálózat
(röviden VLAN) hálózati eszközök egy olyan csoportja, aminek tagjai úgy kommunikálnak,
mintha ugyanabba a szórási tartományba tartoznának, fizikai elhelyezkedésüktől függetlenül.[19]
127, 147–150, 174, 226, 227
VPN A virtuális magánhálózat (Virtual Private Network) koncepciója lehetővé teszi a felhasználóknak,
hogy úgy kommunikáljanak egymással, úgy vegyenek igénybe szolgáltatásokat a nyilvános,
nyílt hozzáférésű hálózaton keresztül, mintha az eszközeik közvetlenül a – többnyire zárt és
védett – magánhálózathoz csatlakoznának. [5] 151, 177, 179, 227
várakozási sor A várakozási sor egy absztrakt adatstuktúra, amely a vermekkel ellentétben
mindkét oldalán nyitott. A sor egyik végén az adatok beszúrása, a másik oldalon az adatok
kivétele történik. A várakozási sor a FIFO (First-In-First-Out) elvet követi, azaz az elsőként
behelyezett elem kerül ki legelőször.[18] 14, 17, 103–105, 125, 223, 225
végfelhasználói végpont A végfelhasználói pont (PoP) egy hozzáférési pont vagy fizikai hely,
ahol hálózati eszközök osztoznak egy kapcsolaton. Például, egy Internet végfelhasználói pont
egy olyan hozzáférési pont, ahol több felhasználó kapcsolódhat az Internethez a szolgáltatón
(ISP-n) keresztül.[19] 12
végrendszer A számítógép hálózat szélein lévő rendszer, jellemzője az, hogy mások forgalmát
nem továbbítja adatot fogat, vagy szolgáltat. 11, 18, 19, 36, 69–72, 74, 87, 170, 172
vírus A számítógépes vírus olyan programkód, amely saját másolatait helyezi el más, végrehajtható
Szójegyzék 213
programokban vagy dokumentumokban. Többnyire rosszindulatú, más állományokat használhatatlanná,

sőt teljesen tönkre is tehet.[19] 19, 21, 183, 184
W
W3C A W3C nemzetközi konzorcium, amelyik protokollokat és nyílt szabványokat („ajánlásokat”)
dolgoz ki a Web hosszú távú működésének biztosítása érdekében. Céljuk, hogy a mindenhol,
mindenki által elérhető internet szolgálja az együttműködést, a tudás megosztását, és ezáltal
a globális szinten megvalósuló bizalom kiépülését.[5] 38
WAN A számítógép- és távközlő hálózatokban elterjedt a lefedett terület szerinti osztályozás, mely
nagyterületű hálózat). A WAN-technológiák gyakorlatilag területi megkötés nélkül, akár
globális hálózatok kialakítására alkalmasak. WAN-hálózat volt a klasszikus telefonhálózat,
ilyenek a mai távközlési hálózatok és a nyilvános Internet is. [5] 11, 12
Web A WWW-projekt keretében definiált protokollok és szabványok mentén kialakult, böngészőn
keresztül elérhető, hálózati hipertextrendszer.[5] 10, 37, 40, 66
WEP A Wired Equivalent Privacy (WEP) = Vezetékessel Egyenértékű (Biztonságú) Hálózat
mára már egy korszerűtlen algoritmus az IEEE 802.11-ben megfogalmazott vezeték nélküli
hálózatok titkosítására. A vezeték nélküli hálózatok rádiójelek segítségével sugározzák szét
az üzeneteket, ami sokkal könnyebben lehallgatható, mint a vezetékes hálózatok. A WEP
1997-es bemutatásakor arra szánták, hogy hasonló bizalmas hálózatként működjön, mint egy
általános vezetékes hálózat.[19] 164–166, 175, 227
WFQ A WFQ (Weighted Fair Queueing) egy hálózati ütemező algoritmus, amely egy vonal teljes
kapacitását egyenlő részekre osztja a folyamok között, és ütemezi, hogy adott folyam részére
mely kapacitás hányadokat bocsátja rendelkezésre.[19] 104
WiFi A WiFi az IEEE által kifejlesztett vezeték nélküli mikrohullámú kommunikációt (WLAN)
megvalósító, széleskörűen elterjedt szabvány (IEEE 802.11) népszerű neve.[19] 11, 12, 16,
18, 102, 127, 128, 157, 161–164, 166, 169, 227
WWW Az 1990-es évek elején a WWW-projekt létrehozta azokat az eszközket, megoldásokat,
szabványokat, amelyek laikus felhasználók számára is lehetővé tették az IP-protokollon
keresztül megvalósuló hálózati kommunikációt. Ahhoz, hogy bárki könnyedén kommunikáljon
a hálózat világában, szükség volt egy szabványos dokumentumleíró nyelvre (HTML), amely
révén egységesen lehetett a tartalmak rögzítését, megjelenítését kezelni, szükség volt arra,
hogy könnyen lehessen a tartalmakat felkínálni az adó, és elérni a vevő oldalán.[5] 9, 10, 35,
38, 41, 46, 50, 65, 111, 224
X
X.509 Az X.509 egy szabvány, amely definiálja a publikus kulcsok formátumát. X.509 tanúsítványokat
számos Internet protokollnál használnak, pl.: TLS/SSL, amely a HTTPS alapja, a megbízható
protokoll a böngészéshez.[19] 31, 32, 224
Z
zsaroló program A zsaroló program olyan rosszindulatú program, amely érzékeny adatok nyilvánosságra
hozásával fenyegeti a felhasználót, vagy blokkolja a hozzáférést, amíg a váltságdíj nem kerül
kifizetésre.[19] 19
zseton Egy objektum, ami (gyakran kizárólagos) jogot biztosít egy művelet elvégzéséhez: munkamenet
azonosítás, hozzáférés, meghívás, stb.[19] 43, 44, 139
[1] Kocsis Gábor. Hálózati architektúrák és protokollok előadás. 2015. URL: http://irh.inf.
unideb.hu/~kocsisg (visited on 05/30/2020) (cited on pages 194, 195, 197, 199, 201,
202, 210).
214 Szójegyzék
[2] Robert Gibb. What is TCP Slow Start? 2016. URL: https://blog.stackpath.com/tcp-
slow-start/ (visited on 05/30/2020) (cited on page 205).
[3] IGI Global. IGI Global - Publisher of Timely Knowledge. 2020. URL: https://www.igi-
global.com (visited on 05/30/2020) (cited on page 197).
[4] IETF OAuth Working Group. OAuth 2.0. 2020. URL: https://oauth.net/2/ (visited on
05/30/2020) (cited on page 206).
[5] HTE. HTE Infokommunikációs Fogalomtár. 2020. URL: https://www.fogalomtar.hte.
hu/ (visited on 05/30/2020) (cited on pages 193–213).
[7] Stan Gibilisco Margaret Rouse Matthew Haughn. confidentiality, integrity, and availability
(CIA triad). 2020. URL: https://whatis.techtarget.com/definition/ (visited on
05/30/2020) (cited on pages 196, 210, 211).
[8] Mozilla. MIME types (IANA media types). 2019. URL: https://developer.mozilla.
org/ (visited on 05/30/2020) (cited on page 206).
[9] Inc. Network Sorcery. Network Sorcery. 2020. URL: http : / / networksorcery . com/
(visited on 05/30/2020) (cited on page 199).
[10] Ruckus Networks. Autonomous System Boundary Routers. 2020. URL: http : / / docs .
ruckuswireless.com/ (visited on 05/30/2020) (cited on page 195).
[11] OmniSecu.com. OmniSecu.com. 2020. URL: https://www.omnisecu.com/ (visited on
05/30/2020) (cited on page 194).
[12] RFC. Introducing JSON. 2020. URL: https://www.json.org/ (visited on 05/30/2020)
[13] RFC. RFC. 2020. URL: https://tools.ietf.org/ (visited on 05/30/2020) (cited on
page 195).
[14] SDxCentral. SDxCentral. 2020. URL: https : / / www . sdxcentral . com (visited on
05/30/2020) (cited on pages 193, 197).
[15] Servira. Servira. 2020. URL: https://servira.com/fogalomtar (visited on 05/30/2020)
[16] Vajda Tamás. Számítógép-hálózatok. 2020. URL: https://ms.sapientia.ro/~vajdat/
education/computernetworks/Szamitogep%20Halozatok%20kabelezese.pdf (visited
on 05/30/2020) (cited on pages 204, 212).
[17] Techopedia. Techopedia. 2020. URL: https : / / www . techopedia . com/ (visited on
05/30/2020) (cited on pages 194, 207).
[18] tutorialspoint. tutorialspoint. 2020. URL: https://www.tutorialspoint.com/ (visited
on 05/30/2020) (cited on pages 206, 212).
[19] Wikipedia. Wikipedia Free Encyclopedia. 2020. URL: https://wikipedia.org/ (visited
on 05/30/2020) (cited on pages 193–213).
Kompetenciák és tanulási eredmények
Tantárgy neve: Számítógép hálózatok előadás Kreditértéke: 2

A tantárgy besorolása: kötelező / választható
A tantárgy elméleti vagy gyakorlati jellegének mértéke, "képzési karaktere":
• elméleti: 80%
• gyakorlati: 20%
A tanóra[1] típusa: előadás és óraszáma: 30 óra az adott félévben, (ha nem (csak) magyarul
oktatják a tárgyat, akkor a nyelve: angol (Computer Networkings).
Az adott ismeret átadásában alkalmazandó további (sajátos) módok, jellemzők[2] (ha

vannak): előadás, magyarázat, közös megbeszélés.
Az előadás javarészt az oktató aktivitására épül. Azon technikák, technológiák tárgyalásakor,

amelyek a hétköznapjainkban is felbukkannak, interaktív módon az oktató a hallgatókkal
diszkussziót folytathat.
A számonkérés módja (koll. / gyj. / egyéb[3]): kollokvium
Az ismeretellenőrzésben alkalmazandó további (sajátos) módok[4] (ha vannak):
Évközi számonkérés: a félév közepén a hallgatók az addig érintett témakörökből zárthelyi

dolgozatot írnak az előadás helyszínén és időpontjában, amelynek 50%-os teljesítése szükséges
a kollokviumi vizsgára bocsáthatósághoz.
Év végi írásbeli számonkérés: a tematika témaköreit érintve egy ábrázolt hálózati modell
segítségével a résztvevő hálózati eszközök közötti kommunikációnak a leírása szükséges
"beugró" szinten, majd további kérdések megválaszolása a tematika különböző témaköreihez
kapcsolódóan jobb érdemjegyért.
216 Kompetenciák és tanulási eredmények
Jeles: A hallgató a felrajzolt modell és a hozzá kapcsolódó leírás alapján hibátlanul fel tudja
sorolni a komponensek közötti kommunikáció egyes lépéseit a megfelelő sorrendben, és a
leírtak alapján helyesen ki tudja tölteni a feladathoz tartozó összefoglaló táblázat minden celláját.
Ismeri az alapvető hálózati fogalmakat és azokat megfelelő kontextusban tudja használni. A
feltett elméleti kérdések közül mind a hármat ki tudja fejteni néhány mondatban, a lényeget
összefoglalva, a témakörhöz tartozó szakkifejezések megfelelő használatával.
Jó: A hallgató a felrajzolt modell és a hozzá kapcsolódó leírás alapján hibátlanul fel tudja
feltett elméleti kérdések közül legalább kettőt ki tud fejteni néhány mondatban, a lényeget
Közepes: A hallgató a felrajzolt modell és a hozzá kapcsolódó leírás alapján hibátlanul fel tudja
feltett elméleti kérdések közül legalább egyet ki tud fejteni néhány mondatban, a lényeget
Elégséges: A hallgató a felrajzolt modell és a hozzá kapcsolódó leírás alapján hibátlanul fel
tudja sorolni a komponensek közötti kommunikáció egyes lépéseit a megfelelő sorrendben, és a
Ismeri az alapvető hálózati fogalmakat és azokat megfelelő kontextusban tudja használni.
Elégtelen: A hallgató a felrajzolt modell és a hozzá kapcsolódó leírás alapján nem tudja leírni
a hálózati komponensek közötti kommunikáció egyes lépéseit vagy a feladat összefoglaló
táblázatát helytelenül tölti ki.
A tantárgy tantervi helye (hányadik félév): 1. félév

Előtanulmányi feltételek (ha vannak): -
217
Tantárgy-leírás: az elsajátítandó ismeretanyag tömör, ugyanakkor informáló leírása

A tantárgy célja, hogy megismertesse a hallgatókkal a számítógép hálózatok alapjait.
Részletesen tárgyalja a hálózati referenciamodelleket, azok alkalmazását a gyakorlatban, a
mai technológia verem által használt technológiát támogató protokollok (HTTP, DNS, stb.) és
rendszerek (Proxy) fókuszával. További cél, hogy a hallgató átlássa a hálózati eszközök közötti
kommunikáció alapelveit, az Internet és a tárgyalt protokollok működését, valamint a hálózatok
helytelen konfigurációjából eredő hibák feltárására és javítására.
Témakörök/tartalom:
1. Bevezető, a félév áttekintése
2. Alkalmazás réteg I.
3. Alkalmazás réteg II.
4. Szállítási réteg I.
5. Szállítási réteg II.
6. Hálózati réteg - adatsík
7. Hálózati réteg - vezérlés I.
8. Hálózati réteg - vezérlés II.
9. Adatkapcsolati réteg I.
10. Adatkapcsolati réteg II.
11. Vezetékmentes technológiák
12. Hálózati biztonság I.
13. Hálózati biztonság II.
A 2-5 legfontosabb kötelező, illetve ajánlott irodalom (jegyzet, tankönyv) felsorolása

bibliográfiai adatokkal (szerző, cím, kiadás adatai, (esetleg oldalak), ISBN)
• James Kurose, Keith Ross: Computer Networking: A Top-Down Approach (7th Edition),
Pearson; 7 edition (May 6, 2016), ISBN: 978-0133594140
• Andrew S. Tanenbaum, David J. Wetherall: Számítógép hálózatok, Panem Kft.; Harmadik,
bővített kiadás (2013), ISBN: 978-9635455294
Azoknak az előírt szakmai kompetenciáknak, kompetencia-elemeknek (tudás, képesség stb.,

KKK 7. pont) a felsorolása, amelyek kialakításához a tantárgy jellemzően, érdemben hozzájárul.
a) tudása
• Ismeri és érti az informatikai szakterület legfontosabb általános elméleteit,
összefüggéseit, tényanyagát és az ezekhez szükséges felépítő fogalomrendszert,
különösen az alábbi területen: számítógépes hálózatok.
• Ismeri az informatikai szakterület tervezési, fejlesztési, működtetési és irányítási
folyamatainak alapvető feladatmegoldási elveit, módszereit és eljárásait, különösen
- választott specializációjának megfelelően - a következő területeken: internet
eszközök és szolgáltatások fejlesztése, információbiztonság.
• Ismeri a szakszerű és hatékony szakmai kommunikáció speciális informatikai
eszközeit és módszereit.
• Ismeri és érti az informatikai szakterület legfontosabb etikai és jogi, közgazdasági
vonatkozásait, társadalmi hatásait.
b) képességei
• Képes az informatikai szakterület tudásanyagát alkalmazni WEB-es alkalmazások
fejlesztésére.
• Anyanyelvén képes szakmai szakterületi kommunikációra és kooperációra.
• Képes a szakmai információforrások használatára, a megoldandó problémához
szükséges ismeretanyag megkeresésére.
c) attitűdje
• Nyitott a képesítésével, szakterületével kapcsolatos szakmai, technológiai fejlődés
és innováció megismerésére és befogadására.
• Elfogadja az informatikai szakma munka- és szervezeti kultúra szabályait, etikai
elveit.
• Munkája során figyelembe veszi az informatikai szakterület jogi előírásait.
d) autonómiája és felelőssége
• Felelősséget vállal szakmai tevékenységéért.
• Törekszik a hatékony és minőségi munkavégzésre.
• Felelősséggel dönt saját tudásának fejlesztéséről és karrierjének építéséről.
• Munkáját az információbiztonsági szempontok tiszteletben tartásával végzi.
219
A tantárggyal kialakítandó konkrét tanulási eredmények:

Érti a számítógép Különbséget tesz a Törekszik a Autonóm módon
hálózatok és az referenciamodellek számítógép alkalmazza a
Internet felépítését. (OSI, TCP/IP) hálózatokkal számítógép
Ismeri a hálózati között. kapcsolatos hálózatokkal
referenciamodelleket megfelelő kapcsolatos
(OSI, TCP/IP), fogalomhasználat fogalmak használatát
azok felépítését és elsajátítására. megnyilatkozásaiban.
működési elvét.
Ismeri az Internet
felépítését.
Tisztában van Megkülönbözteti a az Hajlandó az ismertett Önállóan feltérképezi
az alkalmazás alkalmazás rétegben alkalmazás rétegbeli a hálózati
réteg feladatával ismertetett főbb protokollokon alkalmazások
és a hálózati protokollokat. túl továbbiak közötti kapcsolatokat
alkalmazások megismerésére. és az ott alkalmazott
alapjaival. protokollokat,
Azonosítja az szabványokat.
alkalmazás
architektúrákat
és érti működésüket.
Ismeri a Web
és a HTTP főbb
jellemzőit.
Felsorolja a
legismertebb
levelezési
protokollokat (IMAP,
POP3, SMTP),
és megnevezi
alkalmazási
területüket.
Tisztában van a Bemutatja és elemzi Kritikusan Önállóan képes
DNS protokoll a kliens-szerver és figyeli meg már saját hálózatában a
alkalmazásával, P2P architektúrákat. ismert hálózati DNS beállításokat
valamint képes alkalmazások ellenőrizni.
megnevezni a DNS működését és
hierarchia szintjeit. architektúráját.
Ismeri a P2P
fogalmat, és meg
tud nevezni néhány
alkalmazási területet.
Tisztában van a Különbséget Érdeklődik Önállóan
szállítási réteg tesz a szállítási megbízható meghatározza
feladatával, és a rétegbeli protokollok megoldások iránt. egy alkalmazáshoz a
kapcsolatmentes felhasználási Szem előtt tartja használható szállítási
átvitel alapjaival. területeiben. a kapcsolatmentes rétegbeli protokollt.
Ismeri a átvitel problémáit
multiplexálás és az alkalmazás
demultiplexálás rétegbeli protokollok
fogalmait. használata során.
Tisztában van a Különbséget Nyitott a megbízható Ellenőrzi valós

kapcsolatorientált tesz a szállítási átvitelnél látottak rendszeren a
átvitel alapjaival. rétegbeli protokollok alkalmazására sikertelen átvitel
Felismeri a leírásában és megbízhatatlan hibáit és önállóan
kapcsolatorientált működésében. átvitel esetén. javaslatot fogalmaz
szállítás protokollját meg a hiba javítására
(TCP). vonatkozóan.
Tisztában van a
folyamvezérlés és
torlódásvezérlés
alapjaival.
Tisztában van Különbséget tesz a Figyelembe veszi az Hálózati eszközök
a hálózati réteg különböző típusú IP-címek használata konfigurációjában
feladatával és az IP-címek között. során bekövetkező képes az
Internet Protokoll (IP) Feltárja saját változásokat. önellenőrzésre
felépítésével. hálózatának Nyitott az és a hibák önálló
Érti a eszközeit, és annak IP-címekről javítására.
forgalomirányítók logikai címzését. tanultak gyakorlati
architektúráját. alkalmazására.
Ismeri az IP-címzési
módszereket.
Ismeri a Különbséget Szem előtt tartja Önállóan
forgalomirányító tesz a tanult az autonóm kategorizálja a
protokollok főbb forgalomirányító rendszereken belüli forgalomirányító
kategóriáit (link protokollok között és az autonóm protokollokat.
állapot alapúak, (melyiket hol, hogyan rendszerek közötti
távolságvektor használjuk). forgalomirányítási
alapúak). megoldásokat.
Ismeri az Interneten Képes elemezni a Kész a megismert Önállóan ellenőrzi
alkalmazott csomagok hálózati ICMP protokollt a hálózati eszközök
forgalomirányítás és útvonalát. a gyakorlatban is elérhetőségét.
hálózati címfordítás alkalmazni.
elveit. Hajlandó
Tisztában van az alkalmazások
ICMP használatával segítségével a saját
és működési elvével. hálózatán méréseket
végezni.
Felsorolja az A hibadetektáló Kötelezőnek tartja az Önállóan vizsgálja
adatkapcsolati módszerek adatkapcsolati réteg meg egy csomag
réteg feladatait. segítségével elemzést céljait és elfogadja a adatkapcsolati
Ismerteti a hiba- és végez a hálózaton. tanult módszereket. rétegbeli
ütközés-detektálás Osztályozza és beágyazódását.
módszereit. összehasonlítja a
MAC-protokollokat.
Megérti a Megkülönbözteti Érdeklődik Önállóan javaslatot
LAN-on működő a kapcsolót és a a különböző tesz virtuális
címfelderítési forgalomirányítót. adatkapcsolati hálózatok
módszert. rétegbeli alkalmazására.
Tisztában van a technológiák iránt. Ellenőrzi a
virtuális hálózatok címfelderítés
motivációjával. sikerességét.
221
Felsorolja a vezeték Bemutatja a Szem előtt tartja Önállóan vizsgálja

nélküli hálózatok vezetékmentes LAN a mobilitás a mobil hálózatok
elemeit. IEEE szabványait. megközelítésmódjait. működését.
Ismerteti a cella alapú Érdeklődik az új
hálózatok elemeit. cella alapú hálózatok
Tisztában van a szabványai iránt.
hálózati mobilitás
fogalmával.
alapvető igényeivel és biztonságát. biztonságát. biztonság növelése
támadási formákkal. érdekében.
Ismeri a kriptográfia
alapjait.
Ismeri a gyakorlatban Biztonságossá teszi Kezdeményezi Betartja és betartatja a
alkalmazott az Internet különböző saját hálózatának a rendszerek biztonsági
biztonsági rétegeit. biztonságossá tételét. kritériumait.
technikákkal és
technológiákkal.
Tisztában van a tűzfal
képességével és
fontosságával.
Tantárgy felelőse (név, beosztás, tud. fokozat): Dr. Bilicki Vilmos, adjunktus
Tantárgy oktatásába bevont oktató(k), ha van(nak) (név, beosztás, tud. fokozat):
• Jánki Zoltán Richárd, PhD-hallgató

• Szabó Zoltán, PhD-hallgató
Ábrajegyzék
1.1 IT trendek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Caption for LOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Óceánok alatti optikai kábelek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Szolgáltató szintek1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Starlink műholdas hálózat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Csomagkapcsolás várakozási sor1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Forgalomirányító döntés 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8 TDMA és FDMA közegmegosztás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.9 Népszerű vezetett hullámú megoldások . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.10 Csomagtovábbítás késleltetések1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.11 ISO OSI és TCP/IP referencia modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.12 Egymásra épülő rétegek és azonos szinten lévő rétegek együttműködése
beágyazással1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.13 Kártékony programok kategóriái . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Biztonság-Funkcionalitás-Hasznosság . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 IT rendszer feltörés lépései . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Biztonsági probléma rendszer modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Rejtjelezés alapelemei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Ceasar titkosítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Az angol nyelv betűinek gyakorisága . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Blokk titkosítás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8 Véletlenszerűen permutált tábla1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.9 Asszimmetrikus kulcsú titkosítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.10 Kivonatoló eljárás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.11 Kivonatoló eljárás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.12 Digitális tanúsítvány . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.13 Tanúsító hierarchia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
224 ÁBRAJEGYZÉK
2.14 X.509 tanúsítvány fontosabb mezői . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.15 Közbeékelődéses támadás (man in the middle) . . . . . . . . . . . . . . . . . . . 32
3.1 Az Internet rövid története . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Mobil felhasználók számának változása . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Alkalmazások és a hálózat viszonya1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Alkalmazások minőségi igényei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 WWW elemei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 URI példák . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7 HTTP kérés, parancsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.8 HTTP válasz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9 HTTP alap azonosítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 Proxy azonosítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.11 OAuth 2.0 interakciók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.12 OAuth 2.0 Feljogosító kód alapú erőforrás hozzáférés . . . . . . . . . . . . . . . 44
3.13 OAuth 2.0 Implicit erőforrás hozzáférés . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.14 OAuth 2.0 Erőforrás tulajdonos (felhasználó) azonosító adatok alapú hozzáférés
45
3.15 OAuth 2.0 megoldás kiválasztása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.16 JWT szerkezete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.17 HTTP 2.0 szerkezete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.18 HTTP 2.0 keretezés, push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.19 REST, JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.20 A DNS rövid története . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.21 A DNS hierarchia, delegálás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.22 DNS gyökér szerverek, zóna fájlok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.23 Zóna fájl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.24 DNS protokolll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.25 DNS lekérdezés hierarchia feloldó szerverrel . . . . . . . . . . . . . . . . . . . . . . 51
3.26 DNS rejtett mester vs. normál hirearchia . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.27 DNS gyorsítótárak helyei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.28 Továbbító DNS szerver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.29 Belső és külső hálózat szeparált kiszolgálása . . . . . . . . . . . . . . . . . . . . . . 53
3.30 IP - cím keresés, hozzárendelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.31 DNSSEC aláírás hierarchia, rekord típusok . . . . . . . . . . . . . . . . . . . . . . . . 54
3.32 Email rendszer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.33 SMTP protokoll1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.34 Email felépítése1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.35 Email vég-vég kapcsolat1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.36 PGP folyamat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.37 PGP minta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.38 P2P vs. kliens-szerver tartalomelosztás1 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.39 Egy szerver két kliens, két szerver két kliens . . . . . . . . . . . . . . . . . . . . . . . 60
3.40 Szerver koordináció, üzenetvesztés kezelése . . . . . . . . . . . . . . . . . . . . . . 60
3.41 szerver leállás naív protokoll probléma, várakozás amíg a közös állapot
elterjed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.42 Hálózat partíció párhuzamos futás, többségi protokoll . . . . . . . . . . . . . . 61
3.43 Hálózat partíció párhuzamos futás, többségi protokoll . . . . . . . . . . . . . . 62
3.44 5 szerveres működés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.45 Videólejátszási lista és lejátszási lista hierarchia . . . . . . . . . . . . . . . . . . . . 64
3.46 CDN-nel támogatott videókiszolgáló példa1 . . . . . . . . . . . . . . . . . . . . . 64
ÁBRAJEGYZÉK 225
4.1 Logikai vég-vég kommunikáció1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2 Multiplexelés és demultiplexelés1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3 Kapcsolatmentes multiplexelés és demultiplexelés1 . . . . . . . . . . . . . . . . . 73
4.4 Kapcsolatorientált multiplexelés és demultiplexelés1 . . . . . . . . . . . . . . . . 74
4.5 UDP szegmens struktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.6 Megbízható átvitel megbízhatatlan csatornán1 . . . . . . . . . . . . . . . . . . . . 76
4.7 Az rdt1.0 protokoll állapot automatái1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.8 Az rdt2.0 protokoll állapot automatái1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.9 Az rdt2.1 protokoll állapot automatája a küldő oldalon1 . . . . . . . . . . . . . 79
4.10 Az rdt2.1 protokoll állapot automatája a fogadó oldalon1 . . . . . . . . . . . 80
4.11 Az rdt2.2 protokoll állapot automatái1 . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.12 Az rdt3.0 protokoll állapot automatája1 . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.13 Az rdt3.0 protokoll működése1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.14 Az "állj és várj" művelet1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.15 Cső szervezésű adatküldés1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.16 Szekvencia számok a küldő oldalon a Vissza N-nel protokollnál1 . . . . . . 84
4.17 A Vissza N-nel működés közben1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.18 Szekvencia számok a küldő és a fogadó oldalon a Szelektív ismétlés protokollnál1
85
4.19 A Szelektív ismétlés protokoll működés közben1 . . . . . . . . . . . . . . . . . . . 86
4.20 A Szelektív ismétlés protokoll működése túl nagy ablak méret esetén1 . 86
4.21 TCP szegmens struktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.22 Szekvencia számok és nyugta számok egy egyszerű TCP feletti Telnet alkalmazás
esetén1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.23 SampleRTT és EstimatedRTT értékek stabilitása1 . . . . . . . . . . . . . . . . . . . . 89
4.24 Újraküldés elveszett nyugta és korai időtúllépés miatt1 . . . . . . . . . . . . . . 90
4.25 Gyors újraküldés: a hiányzó szegmens újraküldése, mielőtt az időzítő lejár1 91
4.26 TCP három lépéses kézfogás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.27 Két kapcsolat megosztott végtelen pufferrel1 . . . . . . . . . . . . . . . . . . . . . 94
4.28 Az áteresztőképesség és a késleltetés alakulása a forgalom növelésével1 94
4.29 2. eset teljesítménye véges pufferekkel . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.30 Négy küldő, forgalomirányítók véges pufferrel és több ugrásos utakkal1 95
4.31 3. eset teljesítménye véges pufferekkel és több ugrásos utakkal1 . . . . . . 95
4.32 TCP lassú indulás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.33 TCP torlódási ablak evolúciója (Tahoe és Reno)1 . . . . . . . . . . . . . . . . . . 98
4.34 Additív növekedés, multiplikatív csökkenés (AIMD) jelenség1 . . . . . . . . . 98
4.35 Két TCP kapcsolat egy közös vonalon1 . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1 Hálózati réteg feladata, IP homokóra . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.2 Hálózati rétegek, eszközök1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.3 Hálózati réteg adatsík vs. vezérlősík1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.4 várakozási sorok és HOL blokkolás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5 Prioritásos és súlyozott prioritásos várakozási sorok1 . . . . . . . . . . . . . . . . 105
5.6 Kapcsoló megoldások1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.7 IP csomag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.8 IP címek kiosztási és a fizikai infrastruktúra hierarchia . . . . . . . . . . . . . . . . 107
5.9 IP cím belső ábrázolás, alhálózati maszk értelmezése . . . . . . . . . . . . . . . 108
226 ÁBRAJEGYZÉK
5.10 Cím aggregálás és tartomány hirdetés1 . . . . . . . . . . . . . . . . . . . . . . . . 108

5.11 Privát címtartományok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.12 NAT működése1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.13 DHCP működése1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.14 IPV6 penetráció, csomagformátum . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.15 IPv4 alagút IPv6 csatorna részére1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.16 Hálózati réteg adatsík vs. vezérlősík, általánosított továbbítás szűrő mezők1
113
5.17 Hálózat gráf modell1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.18 Dijsktra algoritmusa1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.19 Változó metrika okozta fluktuáció1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.20 Távolságvektor alapú forgalomirányítás algoritmusa1 . . . . . . . . . . . . . . 116
5.21 Hír terjedése pletyka alapú hálózaton1 . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.22 OSPF helló csomag, OSPF többszintű hálózat . . . . . . . . . . . . . . . . . . . . 118
5.23 Tranzit hálózat vs. vég hálózat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.24 iBGP vs eBGP1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.25 SDN vezérlő sík1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.26 Dijsktra algoritmus megvalósítása SDN segítségével1 . . . . . . . . . . . . . . 122
5.27 ICMP datagram és Típus/Kód kombináció . . . . . . . . . . . . . . . . . . . . . . 123
5.28 Traceroute kimenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.29 SNMP üzenet típusok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.30 SNMP rendszer1 , MIB fa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.31 MIB bejegyzés definíció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.1 adatkapcsolati réteg elemei és szolgáltatásai1 . . . . . . . . . . . . . . . . . . . 128

6.2 adatkapcsolati réteg működési elve1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.3 adatkapcsolati réteg hardveres megvalósítása1 . . . . . . . . . . . . . . . . . . 130
6.4 Hibadetektálás paritásbitek segítségével1 . . . . . . . . . . . . . . . . . . . . . . . 131
6.5 R értékének kiszámítása1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.6 Többszörös hozzáférésű közegek1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.7 TDMA - idő alapú csatornfelosztás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.8 FDMA - frekvencia alapú csatornfelosztás1 . . . . . . . . . . . . . . . . . . . . . . . 135
6.9 Réselt ALOHA potenciális ütközései 3 csomóponttal1 . . . . . . . . . . . . . . . 136
6.10 Egyszerű ALOHA ütközési intervallumok1 . . . . . . . . . . . . . . . . . . . . . . . . 137
6.11 Ütközésdetektálás két adóval1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.12 Lekérdező protokoll1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.13 Jelátadó protokoll1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.14 DOCSIS infrastruktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.15 LAN minta infrastruktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.16 ARP felderítő folyamat1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.17 Csillag Ethernet topológia1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.18 Ethernet keret felépítése1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.19 Ethernet szabványok1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.20 Több kapcsoló összekötése1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.21 Kapcsolótáblák tanulása Ethernet hálózaton1 . . . . . . . . . . . . . . . . . . . 147
6.22 Intézményi Ethernet hálózat1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.23 Port alapú VLAN-ok1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
ÁBRAJEGYZÉK 227
6.24 VLAN modell az Informatika Kar épületei között1 . . . . . . . . . . . . . . . . . 149

6.25 VLAN keret felépítése1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.26 MPLS keret beágyazás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.27 MPLS és IP alapú forgalomirányítás egy hálózaton belül1 . . . . . . . . . . . 151
6.28 MPLS forgalomirányító tábla minták1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.29 A Microsoft Chicago-i adatközpontja1 . . . . . . . . . . . . . . . . . . . . . . . . . 152
6.30 Adatközponton belüli infrastruktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.31 A webkérés életútja során bejárt teljes modell1 . . . . . . . . . . . . . . . . . . 154
6.32 DHCP protokoll alapú IP cím szerzés1 . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.33 DNS kérés futtatása1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.34 Weboldal betöltése1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.35 Vezetékmentes hálózati infrastruktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.36 SNR - BER metrikák viszonya1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.37 Rejtett állomás és elhalványulás problémák1 . . . . . . . . . . . . . . . . . . . . 159
6.38 CDMA a küldő és a fogadó oldalán1 . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.39 PAN hálózati infrastruktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.40 WiFi társulási folyamat aktív és passzív kereséssel1 . . . . . . . . . . . . . . . . . 163
6.41 WiFi keret formátum1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.42 WEP titkosítás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.43 WEP azonosítás kiszervezett azonosító szerverrel1 . . . . . . . . . . . . . . . . . 166
6.44 Klasszikus 2G hálózat infrastruktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.45 3G hálózat infrastruktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.46 4G hálózat infrastruktúra1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.47 Mobilitási fokozatok1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.48 Mobilitási alapfogalmak viszonya1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.49 Közvetlen forgalomirányítás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.50 Sikeresen megvalósult hívásátadás1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.1 SSL helye a hálózati rétegek között, SSL üzenetváltás . . . . . . . . . . . . . . . 178

7.2 SSL rétegek, SSL műveletek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
7.3 IPSec VPN módok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
7.4 IPSec AH és ESP fejlécek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.5 IKE üzenetváltás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.6 IPSec beágyazás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.7 Tűzfal helye az infrastruktúrában . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.8 Minta tűzfal szabályok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.9 Adatút, alkalmazás szintű átjáróval és tűzfallal, HTTP proxy . . . . . . . . . . . 183
7.10 Demilitarizált Zóna (Demilitarized Zone) . . . . . . . . . . . . . . . . . . . . . . . . . 183
7.11 SIEM- Biztonsági Incidens és Esemény Kezelés (Security Incident and Event
Management) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
7.12 IDS - Behatolás Detektáló Rendszer (Intrusion Detection System) minta folyamat
és leírónyelv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Számítógép Hálózatok Programozóknak v1.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Számítógép Hálózatok Programozóknak v1.0

Uploaded by

Copyright:

Available Formats

Számítógép hálózatok programozóknak

Dr. Bilicki Vilmos, Szabó Zoltán, Jánki Zoltán Richárd

1 Programozó centrikus rész 7

6 Adatkapcsolati réteg 127

7 Hálózati biztonság 177

Kompetenciák és tanulási eredmények 215

Miért érdekes ez a fejezet egy programozónak?

Kedves olvasó, jelen jegyzet célja a számítógép hálózatok bemutatása szoftverfejlesztőknek. A

1.1 Az információs technológia (IT) jelene

eszköztárral (Excel, Access...). A következő nagy lépést az Internet és annak legnépszerűbb

1.2 Az Internet fogalma

Fontos Az Internet tehát fekete dobozként tekintve a végrendszereket összekötő különböző

1.3 Számítógép hálózatok felépítése

1.2: Hálózati szintek1

1.3: Óceánok alatti optikai kábelek

egymással jellemzően kölcsönösségi alapon kötik össze a hálózataikat. Ez a méretbeli szeparáció ad

1.4: Szolgáltató szintek1

1.5: Starlink műholdas hálózat

1.6: Csomagkapcsolás várakozási sor1

A helyi döntés meghozatalához globális információra is szüksége van a forgalomirányítónak. Mi

1.7: Forgalomirányító döntés 1

1.8: TDMA és FDMA közegmegosztás

1.9: Népszerű vezetett hullámú megoldások

szabályozzák a különböző elektromágneses frekvencia sávok hozzáférését. Vannak a licenc

1.6 Számítógép hálózati szolgáltatások teljesítménymutatói

• átküldési késleltetés (transmission delay): ez az adott médium aktuális sávszélességétől

1.10: Csomagtovábbítás késleltetések1

1.7 Számítógép hálózatok gyakorlati felépítése

1.11: ISO OSI és TCP/IP referencia modell

• Alkalmazási réteg (Application Layer): itt találhatóak az alkalmazásokat megvalósító,

1.8 Számítógép hálózatok biztonsága

1.13: Kártékony programok kategóriái

1.9 A számítógép hálózatok elméleti alapjai

1.10 Ellenőrző kérdések

9. Sorold el a legnépszerűbb vezetékmentes hozzáférési technológiákat és vesd össze őket.

1.11 Irodalomjegyzék, további olvasnivalók

1.12 Kompetenciák és tanulási eredmények

Tudás Képesség Attitűd Autonómia-felelősség

Miért érdekes ez a fejezet egy programozónak?

Az előző fejezetben láthattuk, hogy a számítógép hálózatok elsődleges tervezési szempontja

• Jelszó szabályok: leírja a jelszavak struktúráját, életútját és minden egyéb betartandó

2.2: IT rendszer feltörés lépései

A következőekben a kriptográfia alapjait tekintjük át egy egyszerű modell segítségével. A

2.3: Biztonsági probléma rendszer modell

2.1 A kriptográfia alapjai

Az érvek ezen elv mellett:

• Minden kommunikáló félnek más-más algoritmust kellene alkalmaznia (gondoljuk el egy

2.4: Rejtjelezés alapelemei

A különböző algoritmusok bemutatását egy egyszerű Julius Cesar-hoz kötődő algoritmussal

Ma a felhő és GPU korszakában ez 1030 nagyságrendű. Ha úgy módosítjuk Caesar algoritmusát,

2.5: Ceasar titkosítása

2.6: Az angol nyelv betűinek gyakorisága

A titkosított tartalom elleni támadások az alábbi megközelítéseket alkalmazhatják:

megmarad és például a fizetés rész hossza utalhat a fizetés nagyságára.

2.7: Blokk titkosítás1

2.8: Véletlenszerűen permutált tábla1

2.9: Asszimmetrikus kulcsú titkosítás

Az algoritmus a moduló aritmetikán alapul, alapvető összefüggések:

2.2 Üzenet integritás, digitális aláírás

2.10: Kivonatoló eljárás

2.11: Kivonatoló eljárás

2.12: Digitális tanúsítvány

2.13: Tanúsító hierarchia

2.14: X.509 tanúsítvány fontosabb mezői