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

Kapitoly

A meglepő igazság

Mi történik a háttérben?

Az internet telefonkönyve

A DNS Feloldás Lépései

A háromutas kézfogás

A titkosított TLS kézfogás

A digitális igazolvány

A titkosított csevegés

A HTTP Kérés Anatómiája

A Szerver Válasza

Összegzés és Elköszönés

Přepis

Sara: A legtöbben azt gondolják, hogy amikor beírnak egy webcímet a böngészőbe, az olyan, mintha kikeresnének egy szót egy szótárból. Begépeled, és bumm, ott az oldal.

James: De valójában ez egyáltalán nem így működik. Képzeld el inkább úgy, mint egy villámgyors, globális kincsvadászatot, ahol a böngésződ egy sor különböző „térképet” kérdez meg, hogy eljusson a célhoz.

Sara: Egy globális kincsvadászat? Ez sokkal izgalmasabban hangzik, mint egy szótár. Ez a Studyfi Podcast, ahol ma azt fejtjük meg, mi is történik valójában, amikor megnyomsz egy Entert.

James: Pontosan. Szóval, a böngésződnek először is meg kell értenie, mit is kértél tőle. Ez az URL, vagyis az egységes erőforrás-azonosító, ami tele van rejtett információkkal.

Sara: Mint például a https://www.example.com/termekek? A https a protokoll, ami a kommunikáció szabályait adja meg, a www.example.com pedig a hosztnév, a weboldal emberi neve.

James: Így van! A /termekek pedig az útvonal, ami megmondja, a szerveren belül pontosan mit is keresünk. Néha láthatsz még portszámot, kérdőjeles lekérdezéseket vagy kettőskeresztes fragmentumokat is, amik további utasításokat adnak.

Sara: Rendben, a böngésző érti az utasítást. De a hosztnév, mint example.com, csak egy név. A gépeknek IP-címekre van szükségük, nem igaz?

James: Dehogynem! És itt jön a DNS, a Domain Név Rendszer, amit gyakran az internet telefonkönyvének is neveznek. Ez fordítja le a nevet egy IP-címre, mint például a 93.184.216.34.

Sara: Szóval csak kikeresi a számsort a könyvből?

James: Majdnem, de a folyamat ennél rafináltabb. Először a böngésző a saját gyorsítótárában néz körül: „Jártam én már itt mostanában?” Ha nem, megkérdezi az operációs rendszert.

Sara: És ha ott sincs meg az IP-cím?

James: Akkor jön a valódi „nyomozás”. A kérés eljut a helyi DNS szerverhez, amit általában az internetszolgáltatód üzemeltet. Ha ő sem tudja a választ, rekurzív lekérdezést indít.

Sara: Várj, ez azt jelenti, hogy több szervert is megkérdez?

James: Pontosan! Megkérdezi a gyökér DNS szervert, hogy ki felel a .com domainekért. Utána a .com szervertől kérdezi meg, hogy ki kezeli az example.com-ot. Végül az example.com autoritatív szervere adja meg a végső IP-címet.

Sara: Hűha! És mindez a másodperc töredéke alatt történik meg. Hihetetlenül hangzik.

James: Teljesen az! És amint megvan az IP-cím, a böngészőnk készen áll a következő lépésre: felvenni a kapcsolatot a szerverrel. De hogy ez hogyan történik, az már a következő témánk lesz.

Sara: Szóval, James, eljutottunk a DNS lekérdezés utolsó lépéseihez. Mi történik, miután a kérésünk megtalálta a megfelelő autoritatív szervert?

James: Ez a legjobb rész! Az autoritatív szerver, ami az example.com „tulajdonosa”, végre megadja a www.example.com IP-címét. Mondjuk, hogy az 93.184.216.34.

Sara: És a böngészőm máris tudja, hova csatlakozzon?

James: Majdnem! A válasz először visszamegy a te internetszolgáltatód DNS-szerveréhez. Ez a szerver eltárolja a választ a gyorsítótárában – ez később még fontos lesz –, és csak ezután küldi el a böngészőnek.

Sara: Oké, ez egy kicsit olyan, mint egy bonyolult postai kézbesítés.

James: Pontosan! Gondolj bele: a böngésződ először megnézi a saját és a géped gyorsítótárát. Nincs találat. Ezután a kérés elmegy a szolgáltatód DNS szerveréhez, ami megkérdezi a gyökérszervert, hogy „Hol vannak a .com szerverek?”

Sara: A gyökérszerver pedig elirányítja a megfelelő helyre?

James: Igen, a .com TLD szerverhez. Az pedig megmondja, hol van az example.com autoritatív szervere. Végül ez az utolsó szerver adja meg a konkrét IP-címet, amit a böngésződ használhat.

Sara: Elképesztő, hogy ez az egész egy szempillantás alatt megtörténik! De említetted a gyorsítótárazást… gondolom, ez segít, hogy ne kelljen mindig végigcsinálni ezt a hosszú utat?

Sara: Szóval, James, most már megvan az IP-cím. Ez olyan, mintha tudnánk a szerver telefonszámát. De mi a következő lépés? Egyszerűen csak elkezdjük kiabálni az adatokat felé?

James: Jó a hasonlat! De nem, nem egészen. Mielőtt bármit is küldenénk, egy megbízható kapcsolatot kell kiépítenünk. Képzeld el, hogy nem csak kiabálni akarsz, hanem biztos akarsz lenni benne, hogy a másik oldalon hallanak, és mindent pontosan értenek.

Sara: Rendben, ez logikus. Szóval hogyan hozzuk létre ezt a megbízható vonalat?

James: Erre használjuk a TCP-t, vagyis a Transmission Control Protocol-t. A kapcsolatfelvétel egy híres folyamattal történik, amit háromutas kézfogásnak hívnak.

Sara: Háromutas kézfogás? Ez elég hivatalosan hangzik.

James: Pedig valójában nagyon udvarias. Gondolj rá úgy, mint egy telefonhívásra. Először a böngésző, vagyis a kliens, küld egy SYN csomagot. Ez a "Szia, szeretnék veled beszélni, itt vagy?".

Sara: Oké, ez az első lépés. Mi a második?

James: A szerver, ha készen áll, visszaküld egy SYN-ACK csomagot. Ez annyit tesz: "Szia! Igen, itt vagyok, és én is szeretnék veled beszélni. Megkaptam a kérésed."

Sara: És a harmadik lépés a miénk, gondolom. Az utolsó bólintás.

James: Pontosan. A kliens küld egy utolsó, ACK csomagot, ami azt jelenti: "Szuper, vettem az adást, kezdhetjük!". Ezzel a három lépéssel mindkét fél biztos lehet benne, hogy a kapcsolat létrejött és stabil.

Sara: Ez zseniális. De mi a helyzet a biztonsággal? Amikor a bankom oldalára megyek, ott van az a kis lakat ikon. Az mikor kerül a képbe?

James: Nagyszerű kérdés! Az a TCP kapcsolat felépítése *után* következik, de csak ha HTTPS oldalt látogatsz. Ezt hívják TLS kézfogásnak. Ez a digitális világ titkos kézfogása.

Sara: Titkos kézfogás? Ez tetszik! Hogy működik?

James: A böngésző elküld egy "Client Hello" üzenetet. Bemutatkozik, és elmondja, milyen titkosítási nyelveket ismer. A szerver válaszol egy "Server Hello"-val, kiválaszt egy közös nyelvet, és elküldi a digitális tanúsítványát.

Sara: A digitális tanúsítványát? Ez olyan, mint egy személyi igazolvány?

James: Pontosan! A böngésződ leellenőrzi ezt az igazolványt. Megnézi, hogy egy megbízható hatóság adta-e ki, érvényes-e, és tényleg ahhoz a weboldalhoz tartozik-e. Ha valami gyanús, a böngésző azonnal figyelmeztet.

Sara: És ha minden rendben van?

James: Akkor a böngésző létrehoz egy titkos kulcsot, becsomagolja a szerver nyilvános kulcsával – ami a tanúsítványon van –, és elküldi neki. Innentől kezdve csak ők ketten tudják, mi a közös titok, és minden további kommunikáció titkosítva zajlik.

Sara: Fantasztikus. Tehát van egy stabil vonalunk a TCP-vel, és egy titkosított csatornánk a TLS-sel. Elképesztő, mennyi minden történik, mielőtt egyáltalán betöltene az oldal.

James: Így van. És most, hogy a csatorna biztonságos és megbízható, végre készen állunk arra, hogy lekérjük magát a weboldal tartalmát. Ez pedig elvezet minket a HTTP kéréshez.

Sara: Oké, James, szóval lezajlott ez a bonyolult "kézfogás", és megvan a közös munkamenet kulcs. Most mi jön? Innentől már minden simán megy?

James: Pontosan! A nehezén túl vagyunk. Mostantól a további kommunikáció már ezzel a szimmetrikus kulccsal titkosítva zajlik. Minden üzenet, amit küldesz, egy olvashatatlan katyvasszá változik.

Sara: És ez a kulcs meddig érvényes? Olyan, mint egy bérlet, amit újra és újra használhatok?

James: Hát, nem egészen. Inkább egy egyszeri mozijegy. A kulcs csak az adott munkamenetre érvényes. Abban a pillanatban, hogy bezárod a lapot vagy megszakad a kapcsolat... a kulcs megsemmisül.

Sara: Tényleg? Akkor minden egyes alkalommal, amikor felmegyek egy weboldalra, ez az egész folyamat lezajlik a háttérben?

James: Igen, minden egyes alkalommal. És ez a szépsége. Így ha valaki meg is szerezné egy munkamenet kulcsát, azzal semmire sem menne a következő kapcsolatnál.

Sara: Ez zseniális. Tehát a TLS alapvetően garantálja, hogy senki sem tudja elolvasni az üzeneteimet, vagy módosítani azokat?

James: Pontosan. Összefoglalva, a TLS biztosítja, hogy az adatok ne legyenek lehallgathatók, ne legyenek módosíthatók, és hogy a kommunikáció a valódi szerverrel történjen, nem egy csalóval.

Sara: Ez egy igazi digitális testőr. Nagyon megnyugtató ezt tudni. De felmerül a kérdés: létezik egyáltalán olyan, hogy feltörhetetlen rendszer? Beszéljünk a lehetséges támadásokról.

Sara: Oké, James, szóval megvan a biztonságos, titkosított kapcsolatunk a TLS-sel. Most jön a lényeg, igaz? El kell kérnünk a tényleges weboldalt.

James: Pontosan. És itt lép a színre a HTTP, vagyis a Hypertext Transfer Protocol. Gondolj rá úgy, mint egy nagyon udvarias, de részletes megrendelőlapra, amit a böngésződ kitölt.

Sara: Megrendelőlap? Ez jó! És mi van ezen a lapon?

James: Az első és legfontosabb a kérés sora, a 'Request Line'. Ez valami ilyesmi: GET /index.html. Magyarul: 'Szia, szeretném elkérni az index.html oldalt.'

Sara: Világos. A GET a módszer, hogy mit csináljon a szerver.

James: Így van. Aztán jönnek a fejlécek, a 'Headers'. Ezek olyan kiegészítő infók, mint például a Host, ami a domain név, vagy a User-Agent, ami a böngésződ típusa.

Sara: Tehát a böngésző bemutatkozik, és elmondja, milyen tartalmat szeretne fogadni?

James: Pontosan. Még a preferált nyelvet is elküldi, mint az Accept-Language. A legtöbb kérésnek nincs is 'Body'-ja, vagyis törzse, csak ha például egy űrlapot küldesz el.

Sara: Rendben, a 'megrendelést' elküldtük. Hogyan válaszol a szerver?

James: Egy HTTP válasszal, ami nagyon hasonló szerkezetű. Az első sora az állapotsor, vagy 'Status Line'. Ha minden rendben, akkor ezt látod: HTTP/1.1 200 OK.

Sara: A 200 OK a 'minden szuper' jelzés?

James: Igen, ez a siker kódja. De biztosan találkoztál már a 404 Not Found hibával is. Az azt jelenti, hogy a szerver nem találta meg a kért fájlt.

Sara: Mintha a pincér közli, hogy elfogyott a kért étel.

James: Pontosan! Vagy ott van az 500 Internal Server Error, ami azt jelenti, hogy a konyhában valami nagyon elromlott. Ezután a válasz fejlécei jönnek, mint a Content-Type, ami megmondja, hogy HTML oldalt küld-e vagy egy képet.

Sara: És végül a válasz törzsében, a 'Body'-ban kapom meg magát a weboldalt, a HTML kódot?

James: Igen! És a böngésződ ezt fogja megjeleníteni neked. Egyszerű, nem?

Sara: Fantasztikus! Szóval, ha összefoglaljuk az egész utazást: a böngésző DNS-sel megkeresi a szerver címét, TCP-vel felépíti a kapcsolatot, TLS-sel titkosítja azt, majd HTTP-vel lekéri a tartalmat. Hűha!

James: Ez a modern web varázslata másodpercek alatt. Nagyon sokat vettünk ma át, de remélem, érthető volt.

Sara: Szerintem szuper voltál, James, köszönjük! És köszönjük nektek is, hogy velünk tartottatok a Studyfi Podcast mai adásában. Sziasztok!

James: Sziasztok!