A webes kérés útja a címsortól a képernyőig

Célok

A lecke végére képes vagy egy oldal megnyitását egyetlen folyamatként végigkövetni (URL, névfeloldás, kapcsolat, védelem, HTTP, feldolgozás), meg tudod mondani, melyik lépésnek mi a feladata, és mely megfigyelési pontból mit látsz a folyamatból.

Miért kell egyben látni?

Az URL, a DNS, a kapcsolat, a HTTP és a böngésző feldolgozása külön-külön könnyen érthető. A felhasználó azonban csak egyetlen műveletet érzékel: megnyit egy oldalt. Ha valami elromlik, a hibakereséshez tudni kell, melyik lépésnek mi a dolga, és mi történt már meg, mi nem. Ez a lecke a korábbi leckék darabjait egy folyamatba fűzi.

A folyamat

A hallgató beírja a https://kurzuspont.example/kurzusok címet.

flowchart LR
    U[URL] --> D[DNS és IP-cím]
    D --> C[TCP + TLS]
    C --> Q[HTTP-kérés]
    Q --> S[Szolgáltatói rendszer]
    S --> V[HTTP-válasz]
    V --> B[Böngészős feldolgozás]
    B --> O[Használható oldal]

Lépésről lépésre:

1. URL felbontása (2.1). A séma HTTPS-t kér, a hosztnév a szolgáltatást nevezi meg, az útvonal az erőforrást azonosítja.
2. Névfeloldás (4.1). A DNS a hosztnévhez IP-címet ad (vagy többet). Ha van érvényes gyorsítótári válasz, ez a lépés rövid.
3. Kapcsolat és védelem (4.2). A böngésző kapcsolatot épít (TCP, HTTP/3-nál QUIC), TLS-kézfogást végez, ellenőrzi a tanúsítványt, és közben egyeztet a HTTP-verzióról.
4. HTTP-kérés (2.2–2.5). A böngésző elküldi a metódust, a célt és a fejléceket (GET /kurzusok, Accept stb.).
5. Közvetítők és szerver (4.4). A kérés CDN-en vagy reverse proxyn át az alkalmazáshoz jut, vagy valamelyik közvetítő gyorsítótárából kap választ.
6. Alkalmazás és adat. Az alkalmazás jogosultságot ellenőrizhet, adatot kérhet, és HTML-t vagy más tartalmat állít elő.
7. HTTP-válasz (2.4). Státuszkód, fejlécek, törzs érkezik vissza.
8. Feldolgozás a böngészőben (3.3, 3.4). DOM és CSSOM épül, további erőforrások töltődnek, az oldal elrendeződik és kirajzolódik.

Egy valódi kérés, a curl -v szemével

A lépéseket a curl -v kimenetében is felismerjük. Egy lerövidített kimenet az example.com oldaláról (2026. október 11.), az egyes sorok előtt megjelölve, melyik lépéshez tartoznak:

*   Trying [2606:4700:10::6814:179a]:443...               ← névfeloldás kész, kapcsolat
* ALPN: curl offers h2,http/1.1                            ← protokoll-egyeztetés
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
*  subject: CN=example.com                                 ← tanúsítvány
*  issuer: C=US; O=SSL Corporation; CN=Cloudflare TLS Issuing ECC CA 3
* ALPN: server accepted h2
* using HTTP/2
> GET / HTTP/2                                             ← HTTP-kérés
> Host: example.com
> Accept: */*
< HTTP/2 200                                               ← HTTP-válasz
< content-type: text/html; charset=utf-8
< server: cloudflare
< cf-cache-status: HIT

(A > a kimenő, a < a bejövő üzenet; a * sorok a curl saját megjegyzései. A kimenetet lerövidítettük.)

Idő és lépések: mi mennyibe kerül?

A curl a lépések idejét is kiírja. Két mérés az example.com címről (másodperc, a kérés kezdetétől számítva):

1. mérés: dns=0.0378 tcp=0.0492 tls=0.0660 ttfb=0.0833 total=0.0834
3. mérés: dns=0.0021 tcp=0.0115 tls=0.0281 ttfb=0.0447 total=0.0448

A számok halmozottak; a lépések saját idejét a különbségükből kapjuk:

Lépés	1. mérés	3. mérés
Névfeloldás (dns)	37,8 ms	2,1 ms
TCP-kapcsolat (tcp − dns)	11,4 ms	9,4 ms
TLS-kézfogás (tls − tcp)	16,8 ms	16,6 ms
Várakozás az első bájtra (ttfb − tls)	17,3 ms	16,6 ms
Letöltés (total − ttfb)	0,1 ms	0,1 ms

Az első mérésnél a névfeloldás volt a legdrágább (nem volt még gyorsítótárban), a harmadiknál már csaknem semennyi. A TCP, a TLS és a szerver várakozása viszont nagyjából állandó maradt. A következő leckében látjuk, mit jelentenek ezek a számok a késleltetés és a hibák szempontjából.

Válaszból oldal

A HTML megérkezése után a böngésző dokumentumfát épít, további erőforrásokat fedez fel, stílust alkalmaz, elrendezést számol és kirajzol (3.3). A link, script, img hivatkozások újabb kéréseket indíthatnak, amelyek egy része ugyanahhoz a szolgáltatáshoz, más része külső végponthoz vezet. Egy oldal ezért nem egyetlen válasz eredménye. Az első HTML-válasz 200 státusza szükséges, de nem elégséges bizonyíték a használhatóságra: hiányozhat a stíluslap, hibázhat egy program, késhet egy adatlekérés.

A folyamat megfigyelési pontjai

Megfigyelési pont	Mit mutat?
Címsor	A megnyitott URL-t, a védettségi állapotot.
Hálózati panel (Network)	A böngésző által indított kéréseket, azok státuszát, fejléceit és időzítését.
Elements / Inspector	Az aktuális DOM-ot és a stílusokat (3.2).
curl	Egyetlen kérés nyers üzeneteit és időzítését, a böngésző feldolgozása nélkül.
Felhasználói próba	Hogy a cél valóban teljesíthető-e.

Együtt erősebb bizonyítékot adnak, mint egyetlen státuszkód vagy képernyőkép.

Végigvezetett példa: a Kurzuspont kurzuslistája

Amikor a hallgató megnyitja a https://kurzuspont.example/kurzusok címet:

1. A böngésző a DNS-ből megkapja a belépési pont címét (a gyorsítótár miatt gyors).
2. TLS-kapcsolatot épít; a tanúsítvány a kurzuspont.example névre szól.
3. GET /kurzusok kérést küld; a CDN továbbítja, mert a lista személyre szabott.
4. Az alkalmazás ellenőrzi a bejelentkezést, lekéri a kurzusokat, és HTML-t küld 200 státusszal.
5. A böngésző feldolgozza a HTML-t, és további kéréseket küld a stíluslapért (CDN-ből) és a szkriptért.
6. Az oldal kirajzolódik; a szkript betöltődése után a szűrő is működik.

Ha az 1. lépés hibázik, nincs kapcsolat; ha a 2., tanúsítványhiba; ha a 4., 4xx vagy 5xx státusz; ha az 5., az oldal megjelenik, de rendezetlenül vagy működésképtelenül.

Gyakori tévhitek

Állítás	Pontosítás
„Az URL közvetlenül az alkalmazásszerver IP-címe.”	Az URL nevet és erőforrást ad; a név feloldása külön lépés.
„A DNS után már a HTTP-kérés következik.”	Kapcsolat- és védelmi lépések is kellenek.
„A 200-as HTML-válasz kész oldalt jelent.”	A böngészőnek további erőforrásokra és feldolgozásra is szüksége lehet.
„Minden megnyitás ugyanazt a teljes láncot ismétli.”	A gyorsítótár és a kapcsolat-újrahasználat lépéseket hagy ki.

Röviden

• A kérés útja: URL → DNS → kapcsolat és TLS → HTTP-kérés → közvetítők és szerver → HTTP-válasz → böngészős feldolgozás.
• Minden lépésnek külön szerepe és külön hibamódja van.
• A gyorsítótár és a kapcsolat-újrahasználat miatt nem minden megnyitás azonos.
• A hálózati panel, az Elements nézet, a curl és a felhasználói próba különböző szeletet mutat.

Ellenőrző kérdések

1. Sorold fel a kérés útjának lépéseit a címsortól a képernyőig!
2. Melyik lépésnél jelenik meg először a tanúsítvány?
3. Miért kerülhet kevesebbe a második kérés ugyanahhoz a szerverhez?
4. Mit mutat a hálózati panel, és mit nem mutat?

Tanulási források

• How the web works (MDN) — a teljes út áttekintése angolul.
• Critical rendering path (MDN) — a válaszból oldal lépései.