SZC logo

Kecskeméti SZC

OM kód: 203041/002 | 6090 Kunszentmiklós, Apostol P. u. 2-6.

Intézmény logo

Kecskeméti SZC Virágh Gedeon Technikum

HírekKözérdekű adatokCLASSROOMKRÉTA

10. évf: OSI és TCP/IP modell

10. évf: OSI és TCP/IP modell

 

 

 

OSIplakat.jpg

MI TÖRTÉNIK, AMIKOR MEGNYITUNK EGY WEBOLDALT?

Nézzünk végig egy konkrét példát!

A számítógépünkön megnyitjuk a böngészőt, és beírjuk:

www.pelda.hu

Megnyomjuk az Enter billentyűt.

Első pillantásra úgy tűnik, hogy a weboldal egyszerűen „megjelenik”. A háttérben azonban rengeteg hálózati művelet történik. A böngészőnek először meg kell találnia a szervert, majd kapcsolatot kell létrehoznia vele, biztonságos kommunikációt kell kialakítania, végül pedig le kell kérnie a weboldal tartalmát.

1. A DNS megkeresi a szerver IP-címét

A böngészőben nem egy IP-címet írtunk be, hanem egy könnyen megjegyezhető nevet:

www.pelda.hu

A hálózat azonban az IP-címek alapján tudja megtalálni a célállomást.

Ezért a számítógép DNS-szolgáltatást használ, amely megkeresi a domainhez tartozó IP-címet.

Például:

www.pelda.hu → 203.0.113.25

A DNS-feloldás tipikusan az alkalmazási réteghez kapcsolódó szolgáltatás. A DNS-lekérdezés a hálózaton ugyanúgy különböző rétegeken keresztül jut el a DNS-szerverhez.

Fontos megjegyezni, hogy a DNS nem feltétlenül minden alkalommal történik meg. Ha a számítógép, a böngésző vagy egy köztes DNS-szerver már ismeri az eredményt a gyorsítótárból, a lekérdezés elmaradhat.


2. A számítógép megtalálja a következő hálózati eszközt

Miután ismertté vált a webszerver IP-címe, a számítógépnek el kell juttatnia hozzá az adatokat.

Ha a célállomás nem ugyanabban a helyi hálózatban található, akkor a számítógép általában a default gateway, vagyis az alapértelmezett átjáró felé küldi a csomagot.

A helyi hálózatban ehhez szükség lehet a router interfészének MAC-címére is.

IPv4 esetén ezt például ARP segítségével lehet meghatározni:

IP-cím → MAC-cím

Ezután a számítógép létrehozza az Ethernet-keretet, amelyben szerepel a cél MAC-címe.

Itt már jól látható a 2. és 3. réteg különbsége:

3. réteg: IP-cím → hová kell eljutni?

2. réteg: MAC-cím → a következő helyi eszköz melyik?


3. A TCP-kapcsolat létrehozása

HTTPS esetén klasszikus TCP-alapú kapcsolatnál a böngésző először kapcsolatot hoz létre a webszerverrel.

Ehhez a TCP úgynevezett háromlépéses kézfogást, vagyis three-way handshake-et használ.

A folyamat:

SYN →

← SYN-ACK

ACK →

Ezzel a két végpont létrehozza a TCP-kapcsolatot.

A TCP a 4. OSI-réteghez kapcsolódik.

A TCP gondoskodik többek között a szegmensek sorrendjéről, a nyugtázásról, az elveszett adatok újraküldéséről és a megfelelő adatátvitel szabályozásáról.


4. A biztonságos HTTPS-kapcsolat létrehozása

Mivel ma a weboldalak jelentős része HTTPS-t használ, a TCP-kapcsolat után TLS-kapcsolat is létrejöhet.

A TLS feladata többek között a kommunikáció titkosítása és a szerver hitelesítése.

A böngésző és a szerver egyezteti a szükséges kriptográfiai paramétereket, majd létrejön a titkosított kommunikáció.

Az OSI-modell szemléletében a titkosítást gyakran a 6. megjelenítési réteghez kapcsoljuk, de a valós TCP/IP hálózatokban a TLS-t nem lehet ilyen egyszerűen egyetlen OSI-rétegbe beszorítani.

Ez fontos különbség a tankönyvi modell és a valódi hálózatok között.


5. A böngésző elküldi a HTTP-kérést

Most már létrejött a szükséges kapcsolat.

A böngésző elküldi a webszervernek a HTTP-kérést.

Egyszerűsített formában például:

GET / HTTP/1.1

A kérés azt jelenti:

„Add vissza nekem a kezdőoldalt.”

A HTTP az alkalmazási réteghez, vagyis a 7. réteghez kapcsolódik.

A szerver megkapja a HTTP-kérést, feldolgozza azt, majd válaszol.


6. A szerver visszaküldi a weboldalt

A webszerver válasza tartalmazhat HTML-kódot.

Például:

HTML → CSS → JavaScript → képek → betűtípusok

A böngésző azonban általában nem egyetlen adatcsomagot kap.

A nagyobb adatfolyamot a hálózati protokollok kisebb egységekre bontják, majd ezek az adatok végighaladnak a hálózat különböző rétegein.

A TCP-adatokból szegmensek, az IP-rétegben csomagok, az Ethernet-rétegben pedig keretek lesznek.


7. Az adatok végighaladnak az OSI-rétegeken

Most kapcsoljuk össze az egészet az OSI-modellel!

A küldő számítógépen az alkalmazás létrehozza az adatot.

7. Alkalmazási réteg:
A böngésző HTTP-kérést készít.

6. Megjelenítési réteg:
Az adatok formátuma, kódolása és a titkosított kommunikációhoz kapcsolódó funkciók jelennek meg. A TLS pontos helye a gyakorlati protokollstackben nem azonosítható tökéletesen egyetlen OSI-réteggel.

5. Viszonyréteg:
A kommunikációs viszony kezeléséhez kapcsolódó feladatok jelennek meg.

4. Szállítási réteg:
A TCP gondoskodik a végpontok közötti szállításról.

3. Hálózati réteg:
Az IP-címzés és az útválasztás alapján a csomag elindul a célhálózat felé.

2. Adatkapcsolati réteg:
Az Ethernet-keret MAC-címek segítségével jut el a következő hálózati eszközig.

1. Fizikai réteg:
A keret bitjei elektromos, optikai vagy rádiós jelek formájában továbbítódnak.


8. Mi történik a routereknél?

A csomag út közben több routeren is áthaladhat.

Egy router megvizsgálja az IP-csomag célcímét, majd az útválasztási táblája alapján kiválasztja a következő útvonalat.

A router továbbítja a csomagot a következő hálózati szakasz felé.

Nagyon fontos, hogy a MAC-címek szakaszonként változhatnak, miközben az IP-címek a végpontok közötti kommunikációt azonosítják.

Ezért mondhatjuk leegyszerűsítve:

IP-cím: végponttól végpontig

MAC-cím: helyi hálózati szakaszonként


9. A webszerver megkapja a kérést

A kérés végül eljut a webszerverhez.

A szerver feldolgozza a HTTP-kérést, majd elküldi a választ.

A fogadó oldalon a korábban bemutatott folyamat fordított irányban történik.

A fizikai réteg fogadja a jeleket, a 2. réteg feldolgozza az Ethernet-keretet, a 3. réteg az IP-csomagot, a 4. réteg pedig a TCP-adatokat.

Felfelé haladva történik a dekapszuláció, vagyis a rétegenként hozzáadott információk feldolgozása és eltávolítása.

Végül a HTTP-adatok eljutnak a böngészőhöz.


10. A böngésző felépíti a weboldalt

A böngésző megkapja a HTML-kódot.

A HTML azonban önmagában gyakran még nem elég.

A böngésző további erőforrásokat kérhet a szervertől:

CSS-fájlokat a megjelenítéshez,

JavaScript-fájlokat a működéshez,

képeket,

videókat,

betűtípusokat és más erőforrásokat.

Ezekhez további HTTP- vagy HTTPS-kérések tartozhatnak.

A böngésző végül feldolgozza ezeket az adatokat, felépíti a weboldal dokumentumstruktúráját, alkalmazza a CSS-formázást, futtatja a JavaScriptet, majd megjeleníti az oldalt a képernyőn.

És mi ebből az egészből csak annyit látunk, hogy:

„Megnyomtam az Entert, és bejött a weboldal.”

A számítógép közben végigjárta a hálózati kommunikáció meglehetősen hosszú bürokratikus folyamatát. 

A TELJES FOLYAMAT EGYBEN

Egy weboldal megnyitását leegyszerűsítve így követhetjük végig:

1. Domainnév beírása

↓

2. DNS-feloldás

www.pelda.hu → IP-cím

↓

3. A cél elérésének meghatározása

IP-cím → útvonal

↓

4. Helyi MAC-cím meghatározása

IP → MAC

↓

5. TCP-kapcsolat létrehozása

SYN → SYN-ACK → ACK

↓

6. TLS-kapcsolat létrehozása HTTPS esetén

↓

7. HTTP-kérés

GET /

↓

8. Az adatok enkapszulációja

Adat → szegmens → IP-csomag → Ethernet-keret → bitek

↓

9. Továbbítás a hálózaton

PC → Switch → Router → Internet → Router → Szerver

↓

10. A szerver válasza

↓

11. Dekapszuláció

Bitek → keret → IP-csomag → szegmens → alkalmazási adat

↓

12. A böngésző feldolgozza a HTML, CSS és JavaScript adatokat

↓

13. Megjelenik a weboldal


Partnereink

SZC logo

Kecskeméti SZC


Kecskeméti SZC Virágh Gedeon Technikum

6090 Kunszentmiklós, Apostol P. u. 2-6.

Telefon: 76/550-180

E-mail: viragh(kukac)kecskemetiszc.hu

OM azonosító: 203041/002

Felnőttképzési nyilvántartás száma: Fnysz: E-001288/2015


2026 • Kecskeméti SZC Virágh Gedeon Technikum