Kapcsolatfelépítés: TCP, TLS és a HTTP-verziók

Célok

A lecke végére meg tudod mondani, mit ad a TCP és mit a TLS, le tudod írni a kapcsolatfelépítés lépéseit, és ismered a HTTP/1.1, a HTTP/2 és a HTTP/3 fő különbségeit.

Miért nem elég az IP-cím?

Az IP-cím ismerete még nem jelenti, hogy a böngésző HTTP-kérést küldhet. Két gondot kell megoldani. Egyrészt a hálózat az adatot kisebb darabokban továbbítja, amelyek elveszhetnek, késhetnek vagy felcserélődhetnek, a böngészőnek pedig rendezett, hiánytalan adatfolyam kell. Másrészt a forgalom idegen gépeken is áthalad, ezért kell valami, ami védi, és biztosítja, hogy tényleg a keresett szolgáltatással beszélünk. Az első feladatot a TCP, a másodikat a TLS oldja meg.

A lépések egymás után

flowchart LR
    N[Hosztnév és IP-cím] --> T[TCP-kapcsolat]
    T --> L[TLS-kézfogás]
    L --> H[HTTP-üzenetek]

A hagyományos HTTPS-kapcsolat útja: a névfeloldás után a böngésző TCP-kapcsolatot épít, rajta TLS-kézfogást végez, és csak ezután küldi a HTTP-kérést.

TCP: rendezett, megbízható adatfolyam

A TCP (Transmission Control Protocol) az RFC 9293 szerint „megbízható, sorrendtartó bájtfolyam-szolgáltatást” nyújt az alkalmazásoknak. Kapcsolatot létesít a két végpont között, a hiányzó adatot sorszámok alapján észreveszi, a hibás szegmenseket ellenőrző összeggel kiszűri, és újraküldéssel pótol. A portszám azonosítja, melyik szolgáltatáshoz fordulunk (lásd 2.1). A böngészőnek így nem kell maga összevadásznia a HTML hiányzó vagy felcserélődött darabjait.

A TCP nem értelmezi a webes útvonalat, a HTTP-státuszkódot vagy a HTML-t, csak az adat szállítását kezeli. Sikeres TCP-kapcsolat mellett is hibázhat a TLS-kézfogás vagy az alkalmazás. A rétegek szétválasztása ezért diagnosztikai eszköz: más a „nem tudok kapcsolódni”, és más a „404-et kaptam”.

TLS: védett kommunikáció

A TCP rendezett átvitelt ad, de nem titkosít és nem azonosítja a szolgáltatót. A TLS (lásd 1.1) három tulajdonságot ad: titkosságot (kívülálló nem olvassa), sértetlenséget (módosítás nem maradhat észrevétlen) és hitelesítést (a szerver bizonyítja, hogy az, akinek mondja magát). A TLS 1.3 aktuális leírása az RFC 9846; ez egy kisebb frissítés, amely az eredeti RFC 8446-ot (2018) váltja ki, és ugyanazt a protokollverziót írja le.

A kézfogás (handshake) lépései TLS 1.3-nál (az RFC alapján):

1. A kliens ajánlatot küld (ClientHello): milyen paramétereket támogat, és kulcsegyeztetési adatot.
2. A szerver válaszol: kiválasztja a paramétereket, elküldi a tanúsítványát és egy aláírást, amellyel bizonyítja, hogy birtokolja a tanúsítványhoz tartozó titkos kulcsot.
3. A kliens ellenőrzi a tanúsítványt, és lezárja a kézfogást. Ezután az adat titkosítva folyik.

Az alapkézfogás egy oda-vissza utat (1-RTT, round trip time) igényel az alkalmazásadat küldése előtt. Az RFC egy 0-RTT változatot is leír, amelyben a kliens korábbi kapcsolat alapján az első üzenetében már adatot küldhet, de ezt biztonsági kompromisszumok árán.

A tanúsítvány (certificate) a szerver kulcsát egy domainnévhez köti, és egy bizalmi láncon keresztül a böngésző által ismert hitelesítésszolgáltatóig vezethető vissza. A böngésző a tanúsítvány érvényességét, megbízhatóságát és azt ellenőrzi, hogy a megnyitott névre szól-e. A tanúsítvány a szervert azonosítja a domainnévhez, nem a felhasználót (a bejelentkezés alkalmazásszintű kérdés, 7. fejezet).

Egy valódi tanúsítvány adatai (openssl kimenet az example.com szerveréről, 2026. október 11.):

subject=CN=example.com
issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com
Protocol: TLSv1.3
Verify return code: 0 (ok)

Látható a név (example.com és a *.example.com helyettesítő minta), a kiállító, az érvényességi időszak (kb. 90 nap) és az, hogy a kapcsolat TLS 1.3-mal jött létre.

HTTP-verziók: ugyanaz a jelentés, más csomagolás

A HTTP fogalmai (metódus, útvonal, státuszkód, fejlécek, törzs) a verziók között közösek (RFC 9110). A verziók abban különböznek, hogyan viszik át az üzenetet a hálózaton.

Verzió	Jellemző	Szállítás
HTTP/1.1	Szöveges üzenetek; tartós kapcsolatok (egy TCP-kapcsolaton több kérés); a lassú válasz feltartja a mögötte várakozókat (head-of-line blocking), ezért a böngészők több kapcsolatot is nyitnak	TCP (+TLS)
HTTP/2	Bináris keretezés; multiplexelés (több kérés párhuzamosan egyetlen kapcsolaton); fejléctömörítés	TCP (+TLS)
HTTP/3	Ugyanazok a szemantikák, de a QUIC protokollon; egy elveszett csomag csak az érintett folyamot állítja meg	QUIC, UDP fölött (a TLS 1.3 beépül)

A HTTP/2 hátránya, hogy egyetlen TCP-kapcsolaton fut: az RFC 9114 szerint egy elveszett vagy felcserélődött csomag minden folyamatban lévő tranzakciót megakaszt, akkor is, ha a többi nem érintett. A HTTP/3 ezt úgy kerüli el, hogy a QUIC folyamatonként kezeli a megbízhatóságot. A QUIC (RFC 9000) UDP-datagramokban közlekedik, és a TLS 1.3 kézfogását használja kulcsegyeztetésre. (A QUIC a protokoll neve; itt nem rövidítésként kezeljük.)

Kiderítheti-e a kliens, melyik verziót használhatja? A TLS-kézfogás során a kliens és a szerver egyeztet az alkalmazási protokollról (ALPN, Application-Layer Protocol Negotiation). Egy valódi példa a curl -v kimenetéből:

* ALPN: curl offers h2,http/1.1
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* using HTTP/2
< HTTP/2 200
< alt-svc: h3=":443"; ma=86400

A kliens h2-t és http/1.1-et ajánlott, a szerver h2-t, azaz HTTP/2-t választott. Az alt-svc fejléc azt hirdeti, hogy a szolgáltatás h3 (HTTP/3) alatt is elérhető ugyanezen a porton; a kliens a következő kapcsolatnál élhet ezzel. (A curl ebben a verzióban HTTP/3-at nem használt; a böngészők a támogatásuk szerint váltanak.)

Költség és kapcsolat-újrahasználat

A névfeloldás, a TCP-kapcsolat és a TLS-kézfogás időt vesz igénybe, de nem kell minden kéréshez elölről kezdeni. A kapcsolat több kérésre újrahasználható. Ugyanazt a curl hívást két kéréssel futtatva:

1. kérés: connect=0.047  tls=0.065  ttfb=0.085  total=0.085  new_conn=1
2. kérés: connect=0.000  tls=0.000  ttfb=0.020  total=0.020  new_conn=0

Az első kérés idejébe a kapcsolat- és a TLS-kézfogás is beletartozik (az idők másodpercben, a kérés kezdetétől számítva). A második kérés ugyanazt a kapcsolatot használta (new_conn=0), így az első byte-ig csak kb. 20 ms kellett. A böngésző időskálája eltérhet, de az elv ugyanaz: a már felépített kapcsolat spórolja a kézfogásokat.

Fontos az is, hogy a tanulási ábra egyszerűsítés: nem minden megnyitás ismétli a teljes sort (gyorsítótár, újrahasznált kapcsolat), és nem minden HTTPS-kapcsolat TCP-n fut (HTTP/3).

Végigvezetett példa: a Kurzuspont kapcsolata

A hallgató a könyvtár hálózatáról megnyitja a Kurzuspontot. A böngésző a DNS-ből megkapja a címet, TCP-kapcsolatot épít a 443-as porthoz, TLS-kézfogást végez, ellenőrzi, hogy a tanúsítvány a kurzuspont.example névre szól-e (a példában kitalált szolgáltatás tanúsítványa), és közben egyeztet a HTTP-verzióról. Ha ez sikerült, elküldi a GET /kurzusok kérést. Ha a tanúsítvány lejárt, a böngésző figyelmeztet, és még HTTP-kérés sem indul: nincs státuszkód, nincs oldal.

Hol akad el?	Tünet	Mi nem történt még meg?
DNS	„A szerver nem található”	kapcsolat
TCP	időtúllépés, elutasított kapcsolat	TLS, HTTP
TLS	tanúsítványhiba	HTTP-kérés
HTTP	státuszkód (404, 500...)	– (a szerver válaszolt)

Gyakori tévhitek

Állítás	Pontosítás
„A TCP titkosít.”	A TCP a megbízható szállítást adja; a TLS a védelmet.
„A DNS-válasz után azonnal megjelenik az oldal.”	Kapcsolat, HTTP-válasz és böngészős feldolgozás is kell.
„A tanúsítvány a felhasználó bejelentkezését igazolja.”	A szerver azonosítását szolgálja.
„Minden HTTPS-kapcsolat TCP-n megy.”	A HTTP/3 a QUIC-ot használja, amely UDP-n fut.
„A HTTP/2 mást jelent, mint a HTTP/1.1.”	Ugyanazokat a fogalmakat másként csomagolja.

Röviden

• A TCP megbízható, rendezett bájtfolyamot ad; a TLS titkosságot, sértetlenséget és szerverhitelesítést.
• A kézfogás során a szerver tanúsítványt és bizonyítékot ad a kulcs birtoklására.
• A HTTP/1.1, HTTP/2 és HTTP/3 ugyanazt a jelentést másként viszi át; a HTTP/3 a QUIC-ot használja.
• A kapcsolat újrahasználható, így nem minden kérés fizeti meg a teljes kézfogást.
• A rétegek különválasztása segít megmondani, hol akadt el a kérés.

Ellenőrző kérdések

1. Mi a különbség a TCP és a TLS feladata között?
2. Miért nem kap státuszkódot a böngésző, ha a tanúsítvány lejárt?
3. Mi a multiplexelés, és mi a HTTP/2 fő hátránya a HTTP/3-hoz képest?
4. Honnan tudja a kliens, hogy HTTP/2-t vagy HTTP/1.1-et használjon?

Tanulási források

• Transmission Control Protocol, RFC 9293 — a TCP hivatalos leírása; haladó olvasmány.
• The Transport Layer Security (TLS) Protocol Version 1.3, RFC 9846 — a TLS 1.3 hivatalos leírása; haladó olvasmány.
• Transport Layer Security (MDN) — mit ad a TLS, angolul.
• Evolution of HTTP (MDN) — a HTTP-verziók története angolul.
• HTTP/3, RFC 9114 és QUIC, RFC 9000 — haladó olvasmány.