Mi történik, amikor beírsz egy címet a böngészőbe

Podcast

Hogyan működik az internet?0:00 / 12:06

0:001:00 remaining

1x

Mi történik, amikor beírsz egy címet a böngészőbe? A weboldalak titka

Amikor beírsz egy címet, például a www.example.com címet a böngésződbe, és megnyomod az Entert, egy látszólag egyszerű műveletet hajtasz végre. Azonban a háttérben egy rendkívül komplex folyamat indul el, amely számos hálózati protokollt és technológiát foglal magában, mielőtt a kért weboldal megjelenik a képernyődön. Ez a folyamat másodpercek töredéke alatt zajlik le, és magában foglalja a cím feloldását, a szerverrel való kapcsolatfelvételt, az adatok titkosított átvitelét és az oldal megjelenítését. Ennek a cikknek a célja, hogy lépésről lépésre bemutassa ezt a bonyolult, de alapvető webes mechanizmust, és elmagyarázza, mi történik, amikor beírsz egy címet a böngészőbe.

Az URL felépítése és értelmezése

Az első lépés a böngészőben beírt Uniform Resource Locator (URL) értelmezése. Az URL egy webes erőforrás egyedi azonosítója, amely megadja annak helyét és az eléréséhez szükséges protokollt. Egy tipikus URL a következő részekből áll:

protokoll://hosztnév:port/útvonal?lekérdezés#fragmentum

• Protokoll: Meghatározza, hogyan kommunikáljon a böngésző a szerverrel (pl. http, https, ftp). A weboldalak esetében leggyakrabban a HTTP vagy a HTTPS (titkosított HTTP) protokollokat használjuk.
• Hosztnév: A weboldal domain neve (pl. www.example.com). Ez egy ember által olvasható cím, amelyet a DNS-nek IP-címmé kell alakítania.
• Port: A szerveren futó szolgáltatás azonosítója. A HTTP alapértelmezett portja a 80, a HTTPS-é a 443. Ha nincs megadva, a böngésző az alapértelmezettet használja.
• Útvonal: Az erőforrás pontos helye a szerveren (pl. /index.html, /termekek/konyvek).
• Lekérdezés: Kiegészítő paraméterek, amelyeket a szervernek küldünk (pl. ?kereses=alma&oldal=2).
• Fragmentum: Az oldal egy adott részére mutató hivatkozás (pl. #fejezet3). Ezt a részt a böngésző dolgozza fel, a szerver nem kapja meg.

1. lépés: DNS feloldás – A domain nevek megfejtése

A böngésző elsődleges feladata, hogy a beírt hosztnevet (pl. www.example.com) egy numerikus IP-címmé alakítsa át (pl. 93.184.216.34), mivel a hálózati kommunikáció az IP-címek alapján történik. Ezt a feladatot a Domain Név Rendszer (DNS) végzi. A DNS egy elosztott adatbázis-rendszer, amely a domain neveket IP-címekre fordítja, és fordítva. Gyakran nevezik az internet „telefonkönyvének”.

A DNS lekérdezés részletes folyamata

A DNS lekérdezés több lépcsőben zajlik:

1. Böngésző gyorsítótára (Browser Cache): A böngésző először ellenőrzi, hogy a kért domain név IP-címe szerepel-e a saját gyorsítótárában. Ha igen, a folyamat itt véget ér.
2. Operációs rendszer gyorsítótára (OS Cache): Ha a böngésző gyorsítótárában nincs találat, az operációs rendszer gyorsítótárát (pl. Windows hosts fájl) ellenőrzi.
3. Helyi DNS szerver (Local DNS Resolver): Ha még mindig nincs találat, a kérés továbbítódik a helyi DNS szerverhez, amelyet általában az internetszolgáltató (ISP) biztosít (pl. 8.8.8.8).
4. Rekurzív lekérdezés: A helyi DNS szerver megpróbálja feloldani a címet. Ha nem tudja, rekurzív lekérdezést indít a gyökér DNS szerverek felé.

• Gyökér DNS szerverek: Ezek a szerverek ismerik az összes legfelső szintű domain (TLD) szerver címét (pl. .com, .org, .hu). A helyi DNS szerver megkérdezi a gyökér szervertől (pl. A.ROOT-SERVERS.NET), hogy hol találja a .com TLD szervert.
• TLD DNS szerverek: A gyökér szerver válaszol a .com TLD szerver címével (pl. A.GTLD-SERVERS.NET). A helyi DNS szerver ezután megkérdezi a .com TLD szervertől, hogy ki a felelős az example.com domainért.
• Autoritatív DNS szerverek: A TLD szerver válaszol az example.com autoritatív DNS szerverének címével (pl. NS1.EXAMPLE.COM). Ez az a szerver, amelyik ténylegesen tárolja az example.com domainhez tartozó összes rekordot, beleértve a www.example.com IP-címét is. A helyi DNS szerver végül megkérdezi az autoritatív szervertől a www.example.com IP-címét.

5. Válasz: Az autoritatív szerver megadja a www.example.com IP-címét (pl. 93.184.216.34). Ezt az IP-címet a helyi DNS szerver eltárolja a gyorsítótárában, majd visszaküldi a böngészőnek.

2. lépés: TCP kapcsolat felépítése – Háromutas kézfogás

Miután a böngésző megkapta a weboldal IP-címét, fel kell építenie egy megbízható kapcsolatot a szerverrel. Erre a célra a Transmission Control Protocol (TCP) szolgál, amely egy kapcsolat-orientált protokoll, garantálja az adatok sorrendjét és megbízható kézbesítését. A kapcsolatfelvétel a TCP háromutas kézfogással (three-way handshake) történik.

A TCP háromutas kézfogás folyamata

A TCP háromutas kézfogás lépései a következők:

1. SYN (Synchronize): A kliens (böngésző) elküld egy SYN csomagot a szervernek a megadott IP-címre és portra (pl. 443 HTTPS esetén). Ez a csomag jelzi a kliens szándékát a kapcsolatfelvételre és tartalmazza a kliens kezdeti sorszámát (pl. Seq=X).
2. SYN-ACK (Synchronize-Acknowledge): A szerver, ha fogadni tudja a kapcsolatot, válaszol egy SYN-ACK csomaggal. Ez a csomag megerősíti a kliens kérését (ACK a kliens SYN-jére, Ack=X+1), és tartalmazza a szerver saját kezdeti sorszámát (SYN a szerver részéről, Seq=Y).
3. ACK (Acknowledge): A kliens egy ACK csomaggal nyugtázza a szerver SYN-ACK válaszát (Ack=Y+1). Ezzel a három lépéssel a kapcsolat létrejön, és mindkét fél tudja, hogy a másik készen áll az adatátvitelre.

Ez a folyamat biztosítja, hogy mindkét fél egyidejűleg tudja, hogy a kapcsolat létrejött, és mindkét fél kezdeti sorszáma szinkronizálva van, ami elengedhetetlen a megbízható adatátvitelhez.

3. lépés: TLS titkosított kapcsolat – A biztonság garantálása

Ha az URL https:// protokollal kezdődik, a TCP kapcsolat felépítése után egy Transport Layer Security (TLS) kézfogás következik. A TLS (korábbi nevén SSL) biztosítja a kommunikáció titkosságát, integritását és hitelességét a kliens és a szerver között. Ez a lépés alapvető fontosságú a személyes adatok védelmében.

A TLS kézfogás főbb lépései

A TLS kézfogás lépései:

1. Client Hello: A kliens elküldi a szervernek a TLS verzióját, a támogatott titkosítási algoritmusokat (cipher suite), egy véletlenszerű számot és a kért domain nevet (Server Name Indication – SNI).
2. Server Hello: A szerver válaszol a kiválasztott TLS verzióval, a kiválasztott titkosítási algoritmussal, egy másik véletlenszerű számmal, és elküldi a digitális tanúsítványát. A tanúsítvány tartalmazza a szerver nyilvános kulcsát, a domain nevet, a tanúsítvány kibocsátóját (Certificate Authority – CA) és az érvényességi idejét.
3. Tanúsítvány ellenőrzése: A kliens ellenőrzi a szerver tanúsítványát. Meggyőződik arról, hogy a tanúsítványt egy megbízható CA írta alá, érvényes a domain névre, és nem járt le. Ha az ellenőrzés sikertelen, a böngésző figyelmeztetést jelenít meg.
4. Kulcscsere: Ha a tanúsítvány érvényes, a kliens generál egy „pre-master secret” kulcsot, amelyet a szerver nyilvános kulcsával titkosít, és elküldi a szervernek. Mindkét fél ezután a „pre-master secret” kulcsból és a korábbi véletlenszerű számokból generálja a munkamenet titkos kulcsát (session key).
5. Titkosított kommunikáció: A további kommunikáció már ezzel a szimmetrikus munkamenet kulccsal titkosítva zajlik. Ez a kulcs csak az adott munkamenetre érvényes, és minden új kapcsolatfelvételnél újra generálódik. A TLS biztosítja, hogy az adatok ne legyenek lehallgathatók, módosíthatók, és hogy a kommunikáció a valódi szerverrel történjen.

4. lépés: HTTP kérés és válasz – Az adatcsere

A titkosított kapcsolat létrejötte után a böngésző elküldi a tényleges Hypertext Transfer Protocol (HTTP) kérést a szervernek, hogy lekérje a weboldal tartalmát. Ez a részletes HTTP kérés és válasz elemzés segít megérteni, milyen információk cserélődnek a kliens és a szerver között.

HTTP kérés (Request) összetevői

A HTTP kérés a következő fő részekből áll:

• Kérés sor (Request Line): Tartalmazza a HTTP metódust (pl. GET, POST), az erőforrás útvonalát (pl. /index.html) és a HTTP verziót (pl. HTTP/1.1).
• Példa: GET /index.html HTTP/1.1
• Fejlécek (Headers): Kiegészítő információkat tartalmaznak a kérésről, a kliensről és a szerver elvárásairól. Példák:
• Host: www.example.com (a kért domain)
• User-Agent: Mozilla/5.0... (a böngésző típusa)
• Accept: text/html,application/xhtml+xml,... (milyen típusú tartalmat fogad el a kliens)
• Accept-Language: hu-HU,en-US;q=0.7 (preferált nyelvek)
• Cookie: PHPSESSID=... (korábbi munkamenetből származó sütik)
• Üres sor: Elválasztja a fejléceket a törzstől.
• Törzs (Body): Csak POST vagy PUT kérések esetén tartalmaz adatokat, például űrlapok elküldött adatait.

Példa: Egy GET kérés (www.example.com/index.html)

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br
Accept-Language: hu-HU,en-US;q=0.7
Connection: keep-alive

HTTP válasz (Response) szerkezete

A szerver feldolgozza a kérést, és HTTP választ küld vissza a böngészőnek. A válasz a következő részekből áll:

• Állapotsor (Status Line): Tartalmazza a HTTP verziót, egy állapotkódot és egy rövid leírást.
• Példa: HTTP/1.1 200 OK (sikeres kérés)
• Gyakori állapotkódok: 200 OK (sikeres), 301 Moved Permanently (átirányítás), 404 Not Found (erőforrás nem található), 500 Internal Server Error (szerverhiba).
• Fejlécek (Headers): Kiegészítő információkat tartalmaznak a válaszról, a szerverről és a tartalomról. Példák:
• Content-Type: text/html; charset=UTF-8 (a tartalom típusa és kódolása)
• Content-Length: 12345 (a tartalom mérete bájtokban)
• Server: Apache/2.4.1 (Unix) (a szerver szoftvere)
• Set-Cookie:... (új sütik beállítása)
• Üres sor: Elválasztja a fejléceket a törzstől.
• Törzs (Body): A kért erőforrás tényleges tartalma, pl. HTML kód, képfájl, JSON adat.

Példa: Szerver válasz egy sikeres GET kérésre

HTTP/1.1 200 OK
Date: Tue, 16 Apr 2024 10:00:00 GMT
Server: Apache
Last-Modified: Mon, 15 Apr 2024 09:00:00 GMT
ETag: "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
Content-Type: text/html; charset=UTF-8
Content-Length: 56789
Connection: keep-alive

<!DOCTYPE html>
<html>
<head>
 <title>Üdvözöljük az example.com-on!</title>
</head>
<body>
 <h1>Ez az example.com főoldala.</h1>
 <p>Ez egy példa weboldal.</p>
</body>
</html>

Összegzés

Ahogy láthatod, egy egyszerű címtípus bevitele a böngészőbe egy rendkívül összetett, mégis hihetetlenül gyors folyamatot indít el. A DNS feloldástól kezdve a TCP és TLS kézfogásokon át egészen a HTTP kérés és válasz cseréjéig minden lépés kulcsfontosságú ahhoz, hogy a kívánt weboldal biztonságosan és hatékonyan megjelenjen a képernyődön. Reméljük, ez a lépésről lépésre bemutatott elemzés segített megérteni a web működésének alapjait, és mi történik a színfalak mögött, amikor beírsz egy címet a böngészőbe.

Gyakran Ismételt Kérdések (GYIK)

Hogyan gyorsítható fel a weboldalak betöltése?

A weboldalak betöltését többek között DNS gyorsítótárazással, TCP keep-alive kapcsolattal, CDN (Content Delivery Network) használatával, böngésző gyorsítótárának optimalizálásával és a weboldal tartalmának (pl. képek, CSS, JS) minifikálásával lehet felgyorsítani.

Mi a különbség a HTTP és HTTPS protokoll között?

A HTTP (Hypertext Transfer Protocol) egy alapvető protokoll weboldalak átvitelére, de az adatok titkosítás nélkül, nyíltan utaznak. A HTTPS (Hypertext Transfer Protocol Secure) a HTTP titkosított változata, amely TLS/SSL protokoll segítségével titkosítja a kommunikációt, így biztonságossá téve az adatcserét, különösen érzékeny információk (jelszavak, bankkártya adatok) esetén.

Miért fontos a DNS feloldás a weboldalak eléréséhez?

A DNS feloldás azért elengedhetetlen, mert az emberek által használt domain neveket (pl. www.example.com) olyan numerikus IP-címekké alakítja át, amelyeket a hálózati eszközök (routerek, szerverek) értelmezni tudnak. Az internet gerincét az IP-címek alkotják, és a DNS biztosítja, hogy a böngésző megtalálja a megfelelő szervert.

Mi az a 404-es hibaüzenet, és mit jelent?

A 404-es Not Found (Nem található) HTTP állapotkód azt jelzi, hogy a kliens sikeresen kommunikált a szerverrel, de a szerver nem találta meg a kért erőforrást az adott URL-en. Ez általában azt jelenti, hogy a link hibás, az oldal törlődött, vagy áthelyezték, és nem történt megfelelő átirányítás.