18 - Számítógépes hálózatok és Internet eszközök Rétegmodellek
Fizikai réteg
Alapsáv: avagy angolul baseband
- A digitális jel dirákt árammá vagy feszültséggé alakul
- A jel minden frekvencián átvitelre kerül
- Átviteli korlátok
Szélessáv: avagy broadband
- Egy széles frekvencia tartományban történik az átvitel
- A jel modulására az alábbi lehetőségeket használhatjuk:
- Adatok vivőhullámra "Ültetése" (amplitudó moduláció)
- Vivőhullám megváltoztatása (frekvencia vagy fázis moduláció)
- Különböző vivőhullámok felhasználása egyidejűleg Digitális kódolások:
-
A digitális kódok 3 lényeges momentumban térnek el:
-
Mi történik egy szignál intervallum elején?
- Mi történik egy szignál intervallum közepén?
-
Mi történik egy szignál intervallum végén? Néhány konkrét digitális kód:
-
Biphase-Mark (váltás, 1-es bit esetén váltás, semmi)

- Biphase-Space (váltás, 0-ás bit esetén váltás, semmi)

- NRZ-L (1-es bit, magas jelszint / 0-s bit alacsony jelszint, semmi, semmi)

- NRZ-M (1-es bit jelszint váltás / 0-ás bit esetén nincs váltás, semmi, semmi)

- RZ (1-es bit magas jelszint / 0-s bit alacsony jelszint, 1-es bit esetén váltás, semmi)

- Differential Manchester (0-s bit esetén váltás, váltás, semmi)

- Delay-Modulation (semmi, 1-es bit esetén váltás, 0-s bit következik váltás)

- Manchester (semmi, 1-es bit magasról alacsonyra / 0-s alacsonyról magasra, semmi)

Moduláció:
-
Amplitudó moduláció:
- Az
s(t)szignált a szinus görbe amplitudójaként kódoljuk, azaz: \(f_A(t) = s(t) * \sin(2\pi ft + \varphi)\)- Analóg szignál: Amplitudó moduláció - Digitális Szignál: amplitudó keying (szignál erőssége egy diszkrét halmaz értékeinek megfelelően változik)
- Az
-
Frekvencia moduláció:
-
Az
s(t)szignál a görbe frekvenciáján kóduljuk, azaz: \(f_F(t) = a * \sin(2\pi s(t)t + \varphi)\) -
Analóg szignál: Frekvencia moduláció
- Digitális szignál: Frekvencia-eltolás keying (például egy diszkrét halmat szimbólumaihoz különböző frekvenciák hozzárendelésével)
-
-
Fázis moduláció:
-
Az
s(t)szignált a szinusz görbe fázisában kódoljuk, azaz: \(f_P(t) = a * \sin(2\pi ft + s(t))\) -
Analóg szignál: fázis moduláció (nem igazán használjuk)
- Digitális szignál: fázis-eltolás keying (például egy diszkrét halmaz szimbólumaihoz különböző fázisok hozzárendelésével)
-
Adatkapcsolati réteg
Keretezés
- A bitek kódolását a fizikai réteg határozza meg
- A következő lépés az adatblokkok "kódolása"
- Minden csomag útvonal infót is tartalmaz
- Az adathatárokat ismernünk kell a fejlécek olvasásához
- A fizikai réteg nem garantálja a hibamentességet, az adatkapcsolati réteg feladat a hibajelzés illetve a javítás, amennyiben szükséges
- Megoldás: Keretekre tördelése a bitfolyamnak, és ellenörző összeget számítása
Fontos! A keretezés nem egyszerű feladat, mivel megbízható időzítésre nem nagyon van lehetőség.
Keret képzés fajtái:
- Bájt alapú protokollok
- A keretben lévő karakterek számának megadás a keret fejlécében lévő mezőben
- A vevő adatkapcsolati rétege tudni fogja a keret végét
- Probléma: nagyon érzékeny hibára a módszer
- Speciális FLAG bájt jelzi az adatkeret elejét és végét.
- Mi van ha szerepel a FLAG az adat között? Beszúrúnk egy ESC (Escape) bájtot, ha ESC is szerepel, elé is beszűrünk egy ESC-et.
- Pont-pont alapú protokollok használják: modem, DSL, cellular.
- Bit alapú protokollok
- Minden keret speciális bitmintával kezdődik és végződik
- A kezdő és záró bitsorozat ugyan az.
- A küldő az adatban előforduló minden 11111 részsorozat mögé 0 bitet szúr be, ezt nevezzük bit beszúrásnak
- A fogaó miután az 11111 részsorozattal találkozik a fogadott adatban:
- 111110 -> eltávolítja a 0-t (mivel ez a beszúrás eredménye volt)
- 11111 -> ekkor még egy bitet olvas
- 1111110 -> keret vége
- 1111111 -> ez hiba, hisz ilyen nem állhat elő a küldő oldalon. ELDOBJUK A KERETET.
- Hátránya: legrosszabb esetben 20% teljesítmény csökkenés
- Minden keret speciális bitmintával kezdődik és végződik
- Óra alapú protokollok
- Synchronous Optical Network azaz SONET
- Nagyon gyors optikai kábelen való átvitel
- pl. STS -> STS-1
- STS-1 keretei rögzített méret
- 9*90 = 810 bájt -> 810 bájt fogadása után újabb keret-kezdő mintázat keresése
- Minden keret küldése / fogadása pontosan 125 μs
- Synchronous Optical Network azaz SONET
Hiba felügyelet: Egyszerű bithiba: egy bit 0 -> 1 vagy 1 -> 0 az adategységben Csoportos bithiba(burst): Fogadott bitek folytonos sorozata amelynek első és utolsó szimbóluma hibás.
Észlelés: Naív: Küldjünk két kópiát minden egyes keretből -> túl magas ár, nem hatékony, gyenge hibavédelem Paritás bit: Egy extra bit minden bitsorozathoz, hogy az egyesek száma végül páros legyen. - Példa: 7 bites ASCII karakterek + 1 paritásbit - 1 bit hiba detektálható, 2 nem, burst esetén nem megbízható
Vezérlés:
- Hiba javító kódok:
- Előre hibajavítás
- Forward Error Correction (FEC)
- Kevésbbé megbízható csatornákon célszerű
- Hiba detektálás és újraküldés
- Automatic Repet Request (ARQ)
- Megbízható csatornák -> olcsóbb
- Célok:
- Hiba detektálás
- Javítással
- Fordward error correction
- Javítás nélkül -> pl. eldobjuk a keretet
- utólagos hibajavítás
- A hibás keret újraküldése
- Javítással
- Hiba javítás:
- Hiba detektálás nélkül:
- pl. Hangátvitel
- Hiba detektálás nélkül:
- Hiba detektálás
Redundancia:
- Redundancia szükséges a hibavezésléshez
- Redundancia nélkül:
- 2^m lehetséges üzenet írható le m biten
- Mindegyik helyes (legal) üzenet és fontos adatot tartalmazhat
- Ekkor minden hiba egy új helyes (legal) üzenetet eredményez
- A hiba felismerése lehetetlen
- Egy keret felépítése:
- m adat bit (ez az üzenet)
- r redundáns / ellenörző biz
- Az üzenetből számolt, új infót nem hordoz
- A teljes keret hozza n = m+r
CRC (Ciklikus Redundancia-Ellenőrzés)
A CRC alapötlete és célja
A Ciklikus Redundancia-Ellenőrzés (CRC) egy nagy hatékonyságú, széles körben elterjedt hibadetektáló kód, amelyet digitális adatok sértetlenségének ellenőrzésére használnak adatátvitel (pl. hálózatok) és adattárolás (pl. merevlemezek) során. A célja, hogy az átviteli közegben keletkező véletlen hibákat (bit-hibákat) a vevő oldalon nagy valószínűséggel észlelje.
Nem hibajavító, hanem hibajelző eljárás. Ha a vevő hibát észlel, jellemzően az adó újraküldi az adatcsomagot. Az Adatkapcsolati réteg (Data Link Layer) egyik kulcsfontosságú feladatát látja el.
A CRC működési elve
A CRC az adatblokkokat egy előre definiált, mind az adó, mind a vevő által ismert generátor polinommal (\(G(x)\)) veti össze. A működés lényege a polinomosztás maradékképzésén alapul.
A folyamat lépései (Adó oldal):
- Polinomiális reprezentáció: A küldendő adat bit-sorozatát (üzenet, \(M\)) tekintsük egy bináris együtthatós polinomnak, \(M(x)\)-nek.
- Előkészítés az osztáshoz: Az \(M(x)\) polinomot megszorozzuk \(x^k\)-nal, ahol k a generátor polinom (\(G(x)\)) fokszáma. Ez a gyakorlatban azt jelenti, hogy az üzenet végére k darab 0-ás bitet fűzünk.
- Polinomosztás: Az így kapott \(x^k \cdot M(x)\) polinomot elosztjuk a \(G(x)\) generátor polinommal (modulo 2 aritmetika szerint, ami a gyakorlatban XOR műveletekkel valósul meg).
- Ellenőrző összeg (Checksum) képzése: Az osztás után kapott maradékot (\(R(x)\)) nevezzük CRC checksumnak vagy Frame Check Sequence-nek (FCS). Ez egy k bites sorozat.
- Adatkeret összeállítása: Az eredeti üzenet (\(M\)) végére a k darab 0 bit helyére beillesztjük a kiszámított maradékot (\(R(x)\)). Az így kapott adatkeret (\(T(x) = x^k \cdot M(x) + R(x)\)) már maradék nélkül osztható a \(G(x)\) polinommal. Ezt a keretet küldi el az adó.
A folyamat lépései (Vevő oldal):
- Ellenőrző osztás: A vevő a teljes vett adatkeretet (üzenet + CRC kód) elosztja ugyanazzal a \(G(x)\) generátor polinommal.
- Maradék vizsgálata:
- Ha az osztás maradéka nulla, akkor a vevő feltételezi, hogy az átvitel hibamentes volt, és elfogadja az adatot.
- Ha a maradék nem nulla, az átvitel során hiba történt. A vevő eldobja a hibás keretet, és tipikusan egy negatív visszaigazolást (NACK) küld vagy egyszerűen nem küld pozitív visszaigazolást (ACK), ami az adót az adat újraküldésére készteti.
3. Generátor polinom (\(G(x)\))
A CRC eljárás hatékonysága nagyban függ a generátor polinom megfelelő megválasztásától. A gyakorlatban szabványosított polinomokat használnak, amelyek bizonyítottan jó hibadetektálási képességekkel rendelkeznek.
- A \(G(x)\) polinom legmagasabb és legalacsonyabb rendű tagjának együtthatója mindig 1.
- Jó hibadetektálási képességűek a prímpolinomok.
Néhány szabványos polinom:
- CRC-8: \(x^8 + x^2 + x + 1\)
- CRC-16-CCITT: \(x^{16} + x^{12} + x^5 + 1\) (pl. HDLC, X.25)
- CRC-32: \(x^{32} + x^{26} + x^{23} + x^{22} + x^{16} + x^{12} + x^{11} + x^{10} + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1\) (pl. Ethernet, Wi-Fi)
4. Hibadetektálási képesség
A CRC rendkívül hatékony a csatornazaj által okozott tipikus hibák detektálásában:
- Minden páratlan számú bithibát észlel.
- Minden egyszeres löketszerű hibát (burst error) észlel, amelynek hossza nem nagyobb, mint a generátor polinom fokszáma (k).
- Nagy valószínűséggel észlel minden, a generátor polinom fokszámánál hosszabb löketszerű hibát.
- Nem észlelhető hiba csak akkor fordul elő, ha a hiba által okozott változás (a hibapolinom, \(E(x)\)) pont a generátor polinom (\(G(x)\)) egy többszöröse. Ez statisztikailag nagyon valószínűtlen.
5. Összefoglalás és előnyök
| Jellemző | Leírás |
|---|---|
| Típus | Hibajelző kód |
| Módszer | Polinomiális aritmetika (osztás maradéka) |
| Implementáció | Hardveresen rendkívül gyors (léptetőregiszterekkel és XOR kapukkal), szoftveresen is hatékony. |
| Előnyök | Magas hibadetektálási arány, különösen a löketszerű hibákkal szemben. Alacsony számítási overhead. |
| Hátrányok | Nem tudja javítani a hibát. Előfordulhat (bár nagyon kicsi az esélye) olyan hiba, amit nem vesz észre. |
| Alkalmazás | Ethernet, Wi-Fi, Bluetooth, SATA, PCI Express, ZIP, PNG és még sok más. |
Forgalomszabályozás
- Gyors adó lassú vevő problémája (elárasztás)
- Még hibamentes átvitel esetén se lesz képes a vevő kezelni a bejövő kereteket Megoldási lehetőségek:
- Visszacsatolás alapú forgalomszabályozás (avagy angolul feedback-based flow control)
- Az adó a vevőtől/hálózattól kapott visszajelzésekre reagálva szabályoz.
- Sebesség alapú forgalomszabályozás (avagy angolul rate-based flow control)
- Protokollba integrált sebességkorlát
- Az adatkapcsolati réteg nem használja
- Az adó egy előre meghatározott sebességi korlátot tart be.
Dinamikus csatornakiosztás
A dinamikus csatornakiosztás (Dynamic Channel Allocation - DCA) egy olyan stratégia a vezeték nélküli hálózatokban, ahol a frekvenciacsatornákat nem fixen, előre meghatározott módon rendelik hozzá az egyes cellákhoz vagy bázisállomásokhoz, hanem egy központi készletből (pool) dinamikusan, a pillanatnyi igényeknek megfelelően osztják ki.
A működés lényege
- Igényalapú kiosztás: Amikor egy felhasználó hívást kezdeményez vagy adatátvitelre van szüksége, a hálózat valós időben választ számára egy szabad csatornát a rendelkezésre álló készletből.
- Ideiglenes használat: A felhasználó csak a kommunikáció időtartamára kapja meg a csatornát. A kapcsolat bontása után a csatorna felszabadul és visszakerül a közös készletbe, így mások számára is elérhetővé válik.
- Optimalizálás: A rendszer a csatorna kiválasztásakor figyelembe veszi az aktuális forgalmi terhelést és az interferenciaviszonyokat is, hogy a lehető legjobb minőségű kapcsolatot biztosítsa.
Előnyei
- Nagyobb spektrális hatékonyság: A csatornák rugalmas felhasználása miatt kevesebb erőforrás marad kihasználatlanul, így a hálózat több felhasználót tud kiszolgálni ugyanazon a frekvenciasávon.
- Jobb alkalmazkodóképesség: A rendszer hatékonyan kezeli a hirtelen forgalmi csúcsokat, mivel a kevésbé terhelt cellák szabad csatornáit át tudja csoportosítani a zsúfoltabb területekre.
- Kevesebb blokkolt hívás: Mivel a teljes csatornakészlet elérhető bármely cella számára, kisebb az esélye annak, hogy egy felhasználó nem kap szabad csatornát.
Hálózati réteg
Távolságvektor protokoll (distance vector) Minden router-nek egy táblázatot kell karbantartania, amelyben minden célhoz szerepel a legrövidebb ismert távolság, és annak a vonalnak az aonosítója, amelyikben a célhoz lehet eljutni. A táblázatokat a szomszédoktól szármató információ alapján frissítik.
- Elosztott Bellman-Ford forgalomirányítási algoritmusként is nevezik (Side note: A Bellman-Ford algoritmus egy gráfelméleti módszer, ami megtalálja a legrövidebb utat egy adott kezdőcsomópontból az összes többi csomópontba, még akkor is, ha a gráfban negatív súlyú élek vannak.)
- ARPANET eredeti forgalomirányító algoritmusa ez volt. RIP azaz Routing Information Protocol néven is ezt használták.
Rövid leírás, környezet és működés:
- Minden csomópont csak a közvetlen szomszédjaival kommunikálhat
- Aszinkron működés
- Minden állomásnak van saját távolság vektora. Ezt periodikusan elküldi a direkt szomszédoknak
- A kapott távolság vektorok alapján minden csomópont új táblázatot állít elő.
Probléma: Végtelenig számolás problémája:
- A "jó hír" gyorsan terjed.
- A "rossz hír" lassan terjed.
- Azaz ciklusok keletkezhetnek
- Lehetséges megoldás:
- "Split horizon with poisoned reverse": Negatív információt küld vissza arról a szomszédjának, amit tőle "tanult".
Kapcsolatállapot Protokoll (Link-State Protocol)
A kapcsolatállapot protokollok a dinamikus útválasztó protokollok egyik fő kategóriáját képezik a számítógépes hálózatokban. Működésük alapja, hogy minden útválasztó (router) ismeri a hálózat teljes topológiáját, vagyis az összes többi útválasztót és az őket összekötő kapcsolatok (linkek) állapotát.
Működési elv
A protokoll működése a következő lépésekre bontható:
- Szomszédok felderítése: Minden útválasztó "Hello" csomagok segítségével felderíti a közvetlenül hozzá csatlakozó szomszédait.
- Kapcsolatállapot-hirdetések (LSA) küldése: Miután a szomszédok ismertek, az útválasztó létrehoz egy kis méretű csomagot, az úgynevezett Kapcsolatállapot-hirdetést (Link-State Advertisement - LSA). Ez a csomag tartalmazza az adott útválasztó azonosítóját, a szomszédos útválasztók listáját és az összeköttetések "költségét" (cost), ami egy metrika (pl. sávszélesség).
- LSA-k elárasztása (Flooding): Az útválasztók elárasztják a teljes hálózatot az LSA csomagjaikkal, továbbítva azokat minden szomszédjuknak, kivéve azt, akitől kapták. Ennek eredményeként minden útválasztó megkapja az összes többi útválasztó LSA csomagját.
- Kapcsolatállapot-adatbázis (LSDB) építése: Minden útválasztó a beérkezett LSA-kból felépíti a saját, egységes kapcsolatállapot-adatbázisát (Link-State Database - LSDB). Ez az adatbázis lényegében a hálózat teljes térképe.
- A legrövidebb út kiszámítása (SPF algoritmus): Az LSDB birtokában minden útválasztó lefuttatja a Dijkstra-féle "legrövidebb út először" (Shortest Path First - SPF) algoritmust. Ennek segítségével kiszámítja a hálózat minden más útválasztójához vezető legrövidebb (legkisebb költségű) útvonalat, és ezeket betölti a saját útválasztó táblájába.
Jellemzők
- Gyors konvergencia: Mivel a topológia változásakor (pl. egy kapcsolat megszakadásakor) csak a változást tartalmazó LSA-t kell elküldeni, a hálózat nagyon gyorsan képes alkalmazkodni az új helyzethez.
- Nagyobb erőforrásigény: Az LSDB tárolása és az SPF algoritmus futtatása több memóriát és processzoridőt igényel, mint a távolságvektor-alapú protokollok.
- Skálázhatóság: Jól skálázhatók nagy és összetett hálózatokban is, gyakran hierarchikus területekre (area) osztással (pl. OSPF).
- Hurokmentesség: Mivel minden router a teljes topológiát ismeri, az SPF algoritmus garantálja a hurokmentes útvonalakat.
Példák
A két legelterjedtebb kapcsolatállapot-protokoll:
- OSPF (Open Shortest Path First): Az egyik legnépszerűbb, széles körben használt protokoll, különösen nagyobb vállalati hálózatokban.
- IS-IS (Intermediate System to Intermediate System): Szintén elterjedt, főleg internetszolgáltatói (ISP) hálózatokban használatos.
Border Gateway Protocol (BGP) Az internet egy két szintű hierarchiába van rendezve, ahol az első szint az autonóm rendszerek azaz AS-ek. Ezek egy adminisztratív tartomány alatti hálózatok pl. ELTE, Comcast. AS-en belül pedig ún. intra-domain routing protokolokat használunk, ugyebár a korábban említett Distance Vector vagy Link State, viszont AS-ek között ún. inter-domain routing protokollokat használunk, pl. BGP vagy napjainkban BGP-4.
Általános leírás:
- AS-ek közötti (exterior gateway protocol) Eltérő célok vannak forgalomirányítási szempontból, mint az AS-eken belüli protokollnál. Politikai szempontok szerepet játszhatnak a forgalomirányítási döntésben. pl. Ne legyen átmenő forgalom bizonyos AS-eken kereszült, vagy Albánián csak akkor haladjunk át, ha nincs más út a célhoz.
- A politikai jellegű szabályokat azonban kézzel konfigurálják a BGP routereten
- A BGP router szempontjából a világ AS-ekből és közöttük átmenő vonalakból áll.
Triviális, két AS összekötött ha van köztik a BGP routere-eiket összekötő él.
- Csonka hálózatok: Csak egyetlen összeköttetés a BGP gráffal.
- Töbszörösen bekötött hálózatok, amelyeket használhatna az átmenő forgalom de ezek ezt megtagadják
- Tranzit hálózatok, amelyek némi megkötéssel általában fizetségért készek kezelni harmadik fél csomagjait Jellemzők:
- A BGP router-ek páronként TCP-összeköttetést lérehozva kommunikálnak egymással.
- A BGP alapvetően távolságvektor protokoll, viszont a router nyomon követi a használt útvonalat, és az útvonalat mondja meg a szomszédjainak.

Útvonal vektor protokoll
- AS-útvonal: AS-ek sorozata melyeken áthalad az útvonal
- Hasonló a távolságvektorhoz, de további információt is tartalmaz
- Hurkok, körök detektálása és különböző továbbítási politikák alkalmazása
- Pl. válaszd a legolcsóbb / legrövidebb utat
- Routing a leghosszabb prefix egyezés alapján
- A távolságvektor protokoll kiterjesztése
- Rugalmas továbbítási politikák
- Megoldja a végtelenig számolás problémáját
- Útvonalvektor: Célállomás, következőugrás (nh), AS útvonal
- Ötlet: a teljes útvonalat meghirdeti
- Távolságvektor: távolság metrika küldetése célállomásonként
- Útvonalvektor: a teljes útvonal küldése célállomásonként
IPv4 vs. IPv6
Az internetprotokoll (IP) az eszközök azonosítására és a hálózati kommunikációra szolgál. Az IPv4 és az IPv6 a protokoll két különböző verziója, jelentős eltérésekkel.
Címzési kapacitás és formátum
| Jellemző | IPv4 (Internet Protocol version 4) | IPv6 (Internet Protocol version 6) |
|---|---|---|
| Címhossz | 32-bit | 128-bit |
| Címek száma | Körülbelül 4,3 milliárd (2^32) | Körülbelül 340 szextillió (2^128) - gyakorlatilag kimeríthetetlen |
| Formátum | Decimális, pontokkal elválasztva (pl. 192.168.1.1) |
Hexadecimális, kettőspontokkal elválasztva (pl. 2001:0db8:85a3:0000:0000:8a2e:0370:7334) |
Technológiai különbségek és előnyök
Sebesség és hatékonyság Az IPv6 egyszerűsített fejléc-struktúrával rendelkezik, ami csökkenti a routerek feldolgozási idejét. Megszünteti a NAT (Network Address Translation) szükségességét, ami az IPv4-nél a címek szűkössége miatt gyakori, és lassíthatja a kommunikációt. Ezáltal az IPv6 gyorsabb és hatékonyabb adatátvitelt tesz lehetővé.
Biztonság Az IPv6-ba alapértelmezetten beépítették az IPsec (Internet Protocol Security) protokollt, ami végpontok közötti titkosítást és hitelesítést biztosít. Bár az IPsec használható IPv4-gyel is, ott az alkalmazása nem kötelező és bonyolultabb lehet.
Hálózatkezelés és konfiguráció Az IPv6 támogatja az állapotmentes automatikus címkonfigurációt (SLAAC), ami lehetővé teszi az eszközök számára, hogy központi szerver (pl. DHCP) nélkül, automatikusan generáljanak maguknak egyedi IP-címet a hálózathoz csatlakozva. Ez jelentősen egyszerűsíti a hálózat adminisztrációját.
Összefoglalva: Miért van szükség az IPv6-ra? Az internethez csatlakozó eszközök számának rohamos növekedése (IoT) miatt az IPv4-címek szinte teljesen kimerültek. Az IPv6 hatalmas címtartománya megoldást nyújt erre a problémára, miközben modernizálja a hálózati kommunikációt a jobb teljesítmény és a beépített biztonsági funkciók révén. Az átállás folyamatos, és a két protokoll még sokáig egymás mellett fog működni ("dual-stack" megoldások).
Szállítói réteg
UDP:
- 8 bájtos UDP fejlét
- Egyszerű, kapcsolatnélküli átvitel
- C socketek:
SOCK_DGRAM
- C socketek:
- Port számok teszik lehetővé a demultiplexálást (az a folyamat, amelynek során a hálózati rétegről (IP) érkező adatcsomagokat a szállítási réteg (UDP) a megfelelő célalkalmazáshoz továbbítja a portszám segítségével.)
- 16 bit = 65535 lehetséges port
- 0 port nem engedélyezett
- Kontrolösszeg hiba detektáláshoz
- Hibás csomagok felismerése
- Nem teketálja az elveszett, duplikátum és helytelen sorrendben beérkező csomagokat (UDP esetén nincs ezekre garancia)
TCP után vezették be, de miért?
- TCP nem minden alkalmazásnak megfelelő
- UDP felett egyedi protokollok pl. Facebook datacenter protocol, media streaming
TCP:
- Megbízható, sorrend helyes, két irányú bájt folyamok
- Port számok a demultiplexáláshoz
- Kapcsolat alapú
- Folyam vezérlés
- Torlódás vezérlés, és fair viselkedés
- 20 bájtos fejléc + options fejlécek
Itt szükség van kapcsolatfelépítésre, hogy kialakítsunk egy állapotot mindkét végponton: sorszámok Flagek:
- SYN - szinkronicázciós, kapcsolat felépítéshez
- ACK - fogadott adat nyugtázása
- FIN - Vége, kapcsolat lezáráshoz

- Kétirányú kapcsolat, azaz mindkét fél küldhet és fogadhat adatot -> különböző sorszámok a két irányba
- TCP egy absztakt bájtfolyam, minden bájt számozott, 32 bites érték, egy idő után körbefordul, kezdetben véletlen érték
- A bájt folyamot szegmensekre bontjuk ezek a TCP csomagok
- Maximum szegmens méret
- Úgy, hogy elkerüljük a fregmentációt
- Minden csomag egyedi sorszám
Kapcsolat felépítés problémája:
- Kapcsolódási zűrzavar
- Azonos hoszt kapcsolatainak egyértelműsítése
- VÉletlenszerű sorszámmal - biztonság
- Forrás hamisítás
- Kapcsolat állapotának kezelése
- Minden SYN állapotot foglal a szerveren
- SYN Flood = Denial of Service támadása
- Megoldás: SYN cookies

Torlódás
-
A hálózat terhelése nagyobb, mint a kapacitása
- A kapacitás nem egyenletes a hálózatban
- Modem vs Cellular vs Cable vs Fiber Optics
- Számos folyam verseng a sávszélességért
- Otthoni kábel modem vs corporate datacenter
- A terhelés időben enm egyenletes
- A kapacitás nem egyenletes a hálózatban
-
Mihez vezet?
- Csomagvesztés
- Routerek véges pufferrel rendelkeznek, ahogy telítődik elkezd csomagokat eldobni
- Gyakorlati következmények:
- Routerek sorai telítődnek, késleltetés
- Sávszélesség pazarlása
- Alacsony hálózati átvitel
- Csomagvesztés
Könyök pont - az a pont ami után:
- Az átvitel szinte alig nő
- A késleltetés viszont gyorsan emelkedik

A Probléma: Torlódás
- Mi az? A hálózatra több adat érkezik, mint amennyit az fel tud dolgozni.
- Következmény: A routerek pufferei megtelnek, ami csomagvesztéshez, megnövekedett késleltetéshez és alacsony átvitelhez vezet.
A TCP Megoldása A TCP proaktívan próbálja megbecsülni a hálózat teherbírását és ehhez igazítja a küldési sebességét.
- Fő eszköz: A küldő oldali torlódási ablak (
cwnd- Congestion Window), ami korlátozza az elküldhető, még nem nyugtázott adatmennyiséget. - Alapszabály: A ténylegesen küldhető adat:
min(cwnd, rwnd), aholrwnda fogadó oldali puffer mérete.
Működési Fázisok
- Slow Start (Lassú Indítás): A
cwndexponenciálisan nő (duplázódik minden Round-Trip Time alatt). Cél: a szabad kapacitás gyors feltérképezése. - Congestion Avoidance (Torlódás Elkerülése): Amikor a
cwndelér egy küszöbértéket (ssthresh), a növekedés lineárissá válik (+1 MSS minden RTT alatt). Cél: a hálózat kapacitásának óvatos megközelítése.
Reakciók Csomagvesztésre: Tahoe vs. Reno A torlódás legfőbb jele a csomagvesztés. A TCP verziók abban térnek el, hogyan reagálnak erre.
Csomagvesztés típusai:
- Időtúllépés (Timeout): Súlyos torlódásra utal.
- 3 Duplikált ACK: Enyhébb, egyedi csomagvesztést jelez.
TCP Tahoe (a "buta") A Tahoe minden csomagvesztésre (timeout ÉS 3 duplikált ACK) egyformán, drasztikusan reagál:
cwnd-t visszaállítja 1 MSS-re.- Újraindítja a Slow Start fázist.
TCP Reno (az "okosabb") A Reno már különbséget tesz a csomagvesztés típusai között:
- Timeout esetén: Ugyanazt teszi, mint a Tahoe (visszaáll 1-re, Slow Start).
- 3 Duplikált ACK esetén: Bevezeti a Fast Retransmit & Fast Recovery mechanizmust:
- Azonnal újraküldi az elveszett csomagot.
cwnd-t csak megfelezi (nem állítja vissza 1-re!).- Kihagyja a Slow Startot és egyből Torlódás Elkerülése fázisba lép.
A lényegi különbség: A Reno egy enyhe hiba után nem lassul le teljesen, így sokkal hatékonyabb tud maradni.
Alkalmazási réteg
DNS:
- Címek, pl. 129.10.117.100
- Számítógépek által használt címkék a gépek azonosítására
- A hálózat szerkezetét tükrözi
- Nevek, pl. www.northeastern.edu
- Ember számára értelmes címkék a gépeknek
- A szervezeti struktúrát tükrözi
- Hogyan képezzünk az egyikről a másikra?
- Domain Name System azaz DNS A DNS:
- Egy Elosztott adatbázis
- Tehát nem központosított
- Egyszerű kliens-szerver architektúra
- UDP 53-as port, vannak TCP impl.-ok is.
- Rövid kérések - rövid válaszok; kérés-válasz típusú kommunikáció.
- Hierachikus névtér
- Szemben a hosts.txt alapú flat megoldással
- Pl. .com -> google.com -> mail.google.com
A Név Hierarchia:
- A legfelső szint: Top Level Domains (TLDs, pl.: .com)
- Maximális famélység: 128
- Minden Domain Név egy részfa:
- .edu -> neu.edu -> css.neu.edu
- Nincsenek névütközések:
- neu.com vs neu.edu
Adminisztráció:
- A fa zónákra bomlik
- Minden zóna rendelkezik egy felügyeleti szervvel ami a hierarchia egy részéért felelős
- Pl.: CCIS vezérli: *.css.neu.edu
Szerver hierarchia:
- Egy DNS szerver funkciói:
- A hierarchia egy részét felügyeli
- Nem szükséges minden DNS nevet tárolnia.
- A zónájához tartozó host és domén rekordjainak tárolása
- Ismeri a root szerver címét
- A root szerverek mindent TLD-t ismernek
- A hierarchia egy részét felügyeli
TLDk:
- Általános: pl. .com
- Ország: pl. .dk (Dánia)
Root Name Servers:
- Root Zone Fájlért felelős
- Listát vezet a TLD-kről és hogy ki felügyeli őket
Lokális névszerverek:
- Minden ISP / cég rendelkezik eggyel
- Gyakran DHCP konfigurálja fel
- A DNS lekérdezések itt kezdődnek
- Gyakran cachel
Authoratív Névszerverek: név -> IP leképezéseket tárol.
Két fajta lekérdezés:
- Rekurzív: Ha a névszerver végzi el a névfeloldást és tér vissza a válasszal
- Iteratív: Ha a névszerver adja vissza a választ vagy legalább azt, hogy kitől kapható meg a következő válasz. (Manapság így működik a DNS!)
DNS Rekordok Rövid Leírása
A Domain Name System (DNS) különböző típusú rekordokat használ a domain nevekkel kapcsolatos információk tárolására és kezelésére. Az alábbi táblázat a leggyakoribb rekordtípusokat foglalja össze.
| Rekord | Teljes Név | Leírás |
|---|---|---|
| A | Address Record | Egy domain nevet (vagy aldomaint) egy IPv4-címhez rendel. Ez a legalapvetőbb rekordtípus. |
| AAAA | IPv6 Address Record | Egy domain nevet egy IPv6-címhez rendel. Az A rekord modern, 128-bites megfelelője. |
| CNAME | Canonical Name | Egy domain nevet egy másik domain névre irányít át (alias). A böngésző végül a cél domain A/AAAA rekordját fogja lekérni. |
| MX | Mail Exchange | Meghatározza a domainhez tartozó levelezőszervereket és azok prioritását. E-mailek kézbesítéséhez elengedhetetlen. |
| TXT | Text Record | Tetszőleges szöveges adat tárolására szolgál. Gyakran használják e-mail hitelesítési protokollokhoz (pl. SPF, DKIM, DMARC) és domain tulajdonjogának igazolásához. |
| NS | Name Server | Megadja, hogy melyik DNS-szerverek az "autoritatívak" (illetékesek) egy adott domain zónájáért. |
| SOA | Start of Authority | Egy DNS zóna legfontosabb adminisztratív információit tartalmazza, például a zóna fő névszerverét és a zóna adminisztrátorának e-mail címét. |
| SRV | Service Record | Speciális szolgáltatások (pl. VoIP, azonnali üzenetküldés) helyét (szervernév és portszám) határozza meg egy domainen belül. |
| PTR | Pointer Record | Az A rekord fordítottja: egy IP-címet rendel egy domain névhez. Ezt leggyakrabban a reverz DNS-lekérdezésekhez használják. |

HTTP**
A HTTP (HyperText Transfer Protocol) egy alkalmazásréteg-protokoll, amely a Világháló (World Wide Web) adatkommunikációjának alapját képezi. Elsődleges célja a HTML oldalak és más webes erőforrások (képek, szkriptek, stíluslapok stb.) lekérése a webszerverekről és megjelenítése a webböngészőkben.
A HTTP egy kliens-szerver modellen alapuló, kérés-válasz (request-response) típusú protokoll.
Működése
A kommunikáció mindig a kliens (jellemzően egy webböngésző) által kezdeményezett kéréssel (request) indul, amelyre a szerver egy válasszal (response) felel. A folyamat lépései a következők:
- Kapcsolatfelvétel: A kliens TCP/IP kapcsolatot létesít a szerverrel, jellemzően a 80-as porton (a titkosított HTTPS esetében a 443-as porton).
-
HTTP Kérés (Request) küldése: A kliens elküld egy szöveges üzenetet a szervernek, amely a következőkből áll:
- Kezdősor (Start Line): Tartalmazza a kérés módszerét (pl.
GET,POST), a kért erőforrás URL-címét és a használt HTTP verziót (pl.HTTP/1.1). - Fejlécek (Headers): Kulcs-érték párok, amelyek további információkat és metaadatokat tartalmaznak a kérésről (pl.
Host,User-Agent,Accept). - Törzs (Body): Opcionális rész, amely adatokat tartalmazhat, például egy űrlap kitöltött adatait
POSTkérés esetén.GETkérésnél általában nincs törzs.
- Kezdősor (Start Line): Tartalmazza a kérés módszerét (pl.
-
Szerver feldolgozása: A szerver fogadja és feldolgozza a kérést. Megkeresi a kért erőforrást, vagy végrehajtja a kérésben foglalt logikát.
-
HTTP Válasz (Response) küldése: A szerver visszaküld egy válaszüzenetet a kliensnek, amelynek szerkezete hasonló a kéréséhez:
- Állapotsor (Status Line): Tartalmazza a HTTP verziót, egy státuszkódot és egy rövid szöveges magyarázatot (pl.
HTTP/1.1 200 OK). - Fejlécek (Headers): Kulcs-érték párok, amelyek a válaszról hordoznak információt (pl.
Content-Type,Content-Length,Server). - Törzs (Body): Maga a kért erőforrás (pl. a HTML oldal forráskódja, egy kép bináris adatai stb.).
- Állapotsor (Status Line): Tartalmazza a HTTP verziót, egy státuszkódot és egy rövid szöveges magyarázatot (pl.
-
Kapcsolat bontása: A válasz elküldése után a kapcsolat lezárulhat. A HTTP/1.1 bevezette a "keep-alive" kapcsolatokat, amelyek lehetővé teszik több kérés és válasz lebonyolítását ugyanazon a TCP kapcsolaton keresztül, csökkentve ezzel a terhelést.
Fontosabb HTTP metódusok
- GET: Egy adott erőforrás (pl. weboldal) lekérésére szolgál. Nem módosítja a szerveren lévő adatokat.
- POST: Adatok küldésére szolgál a szerver felé feldolgozásra (pl. űrlap adatok, fájlfeltöltés). Ez a metódus már módosíthatja a szerver állapotát.
- PUT: Egy adott erőforrást hoz létre vagy cserél le a kérés törzsében küldött adatokkal.
- DELETE: Törli a megadott erőforrást.
Gyakoribb Státuszkódok
A szerver válaszában szereplő háromjegyű szám, amely a kérés kimeneteléről tájékoztat. A kódok első számjegye kategóriát jelöl:
- 2xx (Sikeres): A kérést sikeresen fogadta és feldolgozta a szerver.
200 OK: A kérés sikeres volt.
- 3xx (Átirányítás): A kliensnek további műveletet kell végrehajtania a kérés teljesítéséhez.
301 Moved Permanently: Az erőforrás véglegesen új helyre költözött.
- 4xx (Klienshiba): A kérés hibás szintaktikájú vagy nem teljesíthető.
404 Not Found: A kért erőforrás nem található a szerveren.403 Forbidden: A kliensnek nincs jogosultsága hozzáférni az erőforráshoz.
- 5xx (Szerverhiba): A szerver nem tudta teljesíteni a formailag helyes kérést.
500 Internal Server Error: Általános szerveroldali hiba.
A HTTP egy hontalan (stateless) protokoll, ami azt jelenti, hogy a szerver nem tárol semmilyen információt a kliens korábbi kéréseiről. Minden kérést teljesen függetlenként kezel. A felhasználói munkamenetek (session) kezelését ezért más technológiákkal, például sütikkel (cookies) oldják meg.
DHCP (Dynamic Host Configuration Protocol)
A DHCP egy hálózati protokoll, amelynek feladata, hogy a hálózathoz csatlakozó eszközöknek automatikusan kiosztson minden szükséges hálózati beállítást. Ezzel rendkívül leegyszerűsíti a hálózati adminisztrációt, mivel nem kell minden gépet egyenként, manuálisan konfigurálni.
A legfontosabb kiosztott adatok:
- IP-cím
- Alhálózati maszk
- Alapértelmezett átjáró
- DNS szerver(ek) címe
A DHCP működése: A DORA folyamat
A címkiosztás egy négylépéses, kérés-válasz alapú folyamat, melynek mozaikszava a DORA.
- Discover (Felfedezés): A hálózatra újonnan csatlakozó kliens egy
DHCPDISCOVERbroadcast üzenetet küld szét, amivel egy elérhető DHCP szervert keres. ("Van itt valaki, aki tudna nekem IP címet adni?") - Offer (Ajánlat): A hálózaton lévő DHCP szerver(ek) egy
DHCPOFFERüzenettel válaszolnak, amelyben egy konkrét IP-címet és további konfigurációs adatokat ajánlanak fel a kliensnek. - Request (Kérés): A kliens kiválasztja a legszimpatikusabb (jellemzően az elsőként kapott) ajánlatot, és egy
DHCPREQUESTbroadcast üzenetben jelzi, hogy melyik szerver ajánlatát fogadja el. Ez értesíti a többi szervert is, hogy az általuk felajánlott címek felszabadíthatók. - Acknowledge (Visszaigazolás): A kiválasztott szerver egy
DHCPACKüzenettel véglegesíti a címkiosztást, és elküldi a "bérleti időt" (lease time), ami meghatározza, hogy a kliens meddig használhatja az adott IP-címet újabb kérés nélkül.
ARP (Address Resolution Protocol)
Az ARP egy alapvető hálózati protokoll, amely egy IP-címhez (3. rétegbeli logikai cím) párosítja hozzá a megfelelő MAC-címet (2. rétegbeli fizikai cím) egy helyi hálózaton (LAN) belül.
Erre azért van szükség, mert bár a kommunikációt az IP-címek alapján kezdeményezzük, a csomagok tényleges továbbítását a switchek a fizikai (MAC) címek alapján végzik a helyi hálózaton.
Az ARP működése
A folyamat egy egyszerű kérés-válasz mechanizmus.
-
ARP Kérés (ARP Request): Ha egy "A" eszköz kommunikálni akar egy "B" eszközzel és ismeri annak IP-címét, de a MAC-címét nem, akkor küld egy broadcast üzenetet a teljes helyi hálózatra. A kérés lényege: "Ki használja a
192.168.1.5-ös IP-címet? Mi a MAC-címe?" -
ARP Válasz (ARP Reply): A hálózat összes eszköze megkapja a kérést, de csak az az egy ("B" eszköz) válaszol rá, amelyik a kérdezett IP-címmel rendelkezik. A válaszát (
ARP Reply) már nem broadcastként, hanem közvetlenül (unicast) "A" eszköznek küldi vissza. A válasz tartalma: "Az enyém ez az IP-cím, a MAC-címem pedigAB:CD:EF:12:34:56." -
ARP Gyorsítótár (ARP Cache): A kérdező eszköz a kapott IP-MAC párost elmenti egy ideiglenes táblázatba, az ARP cache-be. Így a következő kommunikáció során már nem kell újra kérdeznie, hanem a helyi gyorsítótárból azonnal ki tudja olvasni a szükséges MAC-címet, felgyorsítva a folyamatot.
Forrás
- Telekom EA - 2024-25
- Gemini 2.5 Pro Preview