HTTP/3: teljes útmutató

A HTTP/3 a HTTP protokoll harmadik fő verziója, amely a TCP helyett a UDP-re épülő QUIC protokollon fut. A titkosítás beépített része, a kapcsolat gyorsabban épül fel, és egy elveszett csomag csak a saját folyamát tartja vissza, a többit nem. Mobil- és gyenge hálózaton hozhat érezhető javulást. Bekapcsolása többnyire CDN- vagy szerverbeállítás, és a böngésző automatikusan visszaesik HTTP/2-re, ha kell.

Alapfogalmak

A HTTP/3 nem a HTTP jelentését változtatja meg. Ugyanazok a metódusok, státuszkódok, fejlécek és URL-ek maradnak, a webhely tartalmához és a keresőoptimalizálási jelzésekhez nem kell hozzányúlni. Az változik, hogy az üzenetek milyen szállítási rétegen utaznak. A HTTP/1.1 és a HTTP/2 a TCP-re épül, a HTTP/3 a QUIC-re, amely maga a UDP fölött működik. A QUIC a Google kísérleti fejlesztéseként indult, később az IETF szabványosította, a HTTP/3-mal együtt.

A váltás oka a TCP egy alapvető tulajdonsága. A TCP a bájtok szigorú sorrendjét garantálja egy kapcsolaton belül. Ha egy csomag elvész, a mögötte érkező adatokat addig nem adja át az alkalmazásnak, amíg a hiányzó csomagot újra meg nem kapja. A HTTP/2 egyetlen TCP-kapcsolaton multiplexel sok folyamot, így egy elveszett csomag az összes folyamot megállítja. A QUIC a folyamokat maga kezeli, és a veszteséget folyamonként pótolja, ezért a többi folyam haladhat tovább.

A legfontosabb fogalmak

Fogalom	Jelentés	Gyakorlati következmény
QUIC	UDP-re épülő, titkosított szállítási protokoll	A HTTP/3 alapja, a TCP és a TLS szerepét egyesíti
UDP	Egyszerű, kapcsolat nélküli szállítási protokoll	A tűzfalaknak engedniük kell a UDP-forgalmat a 443-as porton
Beépített TLS 1.3	A titkosítás a QUIC része, nem külön réteg	Titkosítatlan HTTP/3 nincs, és a kézfogás rövidebb
Folyamonkénti veszteségkezelés	Egy elveszett csomag csak a saját folyamát tartja vissza	Csomagvesztéses hálózaton egyenletesebb betöltés
Kapcsolatazonosító	A kapcsolatot nem az IP-cím és a port, hanem egy azonosító jelöli	Hálózatváltáskor, például wifiről mobilra, a kapcsolat megmaradhat
QPACK	A HTTP/3 fejléctömörítése	A HTTP/2 HPACK-jének a QUIC-hez igazított utódja
Alt-Svc	Válaszfejléc, amely jelzi, hogy a szerver HTTP/3-at is kínál	A böngésző ebből tudja meg, hogy megpróbálhatja a HTTP/3-at

Mit jelent a HTTP/3 a keresőnek?

A HTTP/3 a keresőoptimalizálásban közvetett tényező. A böngészők oldalán a betöltési sebességre és a stabilitásra hat, így a felhasználói élményre és a Core Web Vitals terepi mutatóira. A Googlebot feltérképezéséről szóló Google-dokumentáció a HTTP/1.1-et és a HTTP/2-t említi. A HTTP/3 bekapcsolása tehát nem változtat a feltérképezésen, és nincs olyan nyilvános Google-közlés, amely szerint rangsorolási előnyt jelentene. A haszon a valós látogatóknál jelentkezik, különösen mobilon.

A HTTP-verziók összevetése

Szempont	HTTP/1.1	HTTP/2	HTTP/3
Szállítási réteg	TCP	TCP	QUIC (UDP)
Párhuzamos kérések egy kapcsolaton	Nem	Igen	Igen
Sor eleji blokkolás	Alkalmazás szintjén is	TCP szintjén	Folyamonként kezelve
Titkosítás	Opcionális	A böngészőkben kötelező	Beépített
Hálózatváltás	Új kapcsolat kell	Új kapcsolat kell	A kapcsolat átvihető

Hogyan működik?

A HTTP/3 működését két oldalról érdemes nézni: hogyan találja meg a böngésző, és mi történik, amikor már használja. Az első a felfedezés, a második a QUIC-kapcsolat működése.

Felfedezés: honnan tudja a böngésző, hogy lehet HTTP/3?

A böngésző egy új domain első látogatásakor általában nem tudja, hogy a szerver támogatja-e a HTTP/3-at. Ezért hagyományos, TCP-alapú kapcsolattal indul, HTTP/2-n vagy HTTP/1.1-en. A szerver a válaszban az Alt-Svc fejléccel jelzi, hogy HTTP/3 is elérhető. A böngésző ezt megjegyzi, és a következő kapcsolatoknál már QUIC-kel próbálkozik. Létezik egy másik út is: a DNS-ben elhelyezett HTTPS típusú rekord, amely már a névfeloldáskor jelezheti a támogatott protokollokat, így az első kapcsolat is indulhat HTTP/3-on, ha a böngésző ezt a rekordtípust használja. A névfeloldásról a DNS útmutató ír részletesebben.

A kapcsolat felépítése

TCP és TLS esetén a kapcsolat felépítése két külön kézfogás: előbb a TCP-é, utána a TLS-é. A QUIC a kettőt egyesíti, így a kapcsolat és a titkosítás egy lépésben jön létre. Ez kevesebb oda-vissza üzenetváltást jelent, ami nagy késleltetésű hálózaton, például mobilon vagy földrajzilag távoli szervernél érezhető. Korábban már látott szervernél a QUIC lehetővé teszi, hogy a kliens az első üzenettel együtt adatot is küldjön. Ez a gyors újrakapcsolódás biztonsági szempontból megkötésekkel jár, ezért a szerverek jellemzően csak ismételhető, mellékhatás nélküli kéréseknél engedik.

Folyamok és veszteségkezelés

A QUIC-kapcsolaton belül minden kérés és válasz saját folyamot kap, hasonlóan a HTTP/2-höz. A különbség az, hogy a QUIC maga felel a csomagok sorrendjéért és pótlásáért, folyamonként. Ha egy csomag elvész, csak az a folyam vár, amelyhez tartozott. Egy kép letöltése akadozhat, miközben a stíluslap és a szkript zavartalanul megérkezik. Jó minőségű, vezetékes hálózaton ez a különbség kicsi, csomagvesztéses mobilhálózaton nagyobb.

Kapcsolatmigráció

A TCP-kapcsolatot a két fél IP-címe és portja azonosítja. Ha a telefon wifiről mobilhálózatra vált, az IP-cím megváltozik, és minden kapcsolatot újra kell építeni. A QUIC a kapcsolatot egy saját azonosítóval jelöli, ezért hálózatváltáskor a kapcsolat folytatódhat. Ez főleg a hosszabb munkamenetekben, például sok oldalt böngésző mobillátogatóknál számít.

A visszaesés mechanizmusa

Mivel a HTTP/3 UDP-t használ, egyes vállalati tűzfalak, nyilvános hálózatok vagy régi hálózati eszközök blokkolhatják. A böngészők erre fel vannak készülve: ha a QUIC-kapcsolat nem jön létre, TCP-alapú HTTP/2-re vagy HTTP/1.1-re esnek vissza. A látogató ebből nem érzékel semmit, legfeljebb azt, hogy az oldal a korábbi sebességgel tölt. Ezért a HTTP/3 bekapcsolása mindig kiegészítés, soha nem a HTTP/2 kiváltása.

Fő módszerek

A legtöbb webhelynél a HTTP/3 bekapcsolása egy beállítás a CDN-en vagy a peremszerveren. A saját szerveren való üzemeltetés több munkával jár, mert a webszervernek támogatnia kell a QUIC-et, a tűzfalnak engednie kell a UDP-forgalmat, és a hálózati környezetet is fel kell rá készíteni.

1. Bekapcsolás a CDN-en

A nagy CDN-szolgáltatók támogatják a HTTP/3-at, sokszor egyetlen kapcsolóval. Ez a legegyszerűbb és legkevésbé kockázatos út, mert a QUIC-megvalósítás karbantartása a szolgáltató dolga. A látogató a CDN peremszerverével kommunikál HTTP/3-on, a CDN és a saját szerver közötti kapcsolat ettől független. A CDN útmutató a peremszerverek szerepét is bemutatja.

2. Bekapcsolás saját szerveren

Ha nincs CDN, a webszerver vagy a terheléselosztó QUIC-támogatását kell engedélyezni, és a válaszokba be kell állítani az Alt-Svc fejlécet. A tűzfalon a UDP 443-as portot is meg kell nyitni. Ha a szerver több gép mögött fut, a terheléselosztónak kezelnie kell, hogy a QUIC-kapcsolat azonosítója alapján ugyanahhoz a géphez irányítsa a csomagokat. Ez összetettebb, mint a TCP-nél, és a megvalósítás érettsége szerverenként eltér.

3. A HTTP/2 megtartása

A HTTP/3 mellett a HTTP/2-t és a HTTP/1.1-et is elérhetően kell hagyni. Az első kapcsolat jellemzően TCP-n indul, és a visszaesésnek is szüksége van rá. A régi protokollok kikapcsolása azokat a látogatókat zárná ki, akiknek a hálózata blokkolja a UDP-t.

4. A felfedezés gyorsítása

Az Alt-Svc fejléc érvényességi ideje határozza meg, meddig emlékszik a böngésző a HTTP/3 elérhetőségére. A DNS HTTPS rekordja lehetővé teszi, hogy az első kapcsolat is HTTP/3-on induljon, azokban a böngészőkben, amelyek ezt a rekordtípust használják. Ezt a CDN-szolgáltatók egy része automatikusan kezeli.

Döntési szabály: bekapcsoljam?

Helyzet	Javaslat
A webhely olyan CDN mögött fut, amely támogatja	Bekapcsolni, a visszaesés automatikus
Sok mobil- vagy nemzetközi látogató	Kiemelten érdemes, itt a legnagyobb a várható haszon
Saját szerver, egy gép, modern webszerver	Bekapcsolható, de a UDP-portot és a tűzfalat ellenőrizni kell
Összetett, több gépes saját infrastruktúra	Előbb tesztkörnyezetben, a terheléselosztó képességeinek ellenőrzésével
Belső vállalati alkalmazás, UDP-t szűrő hálózat	Kis haszon, alacsony prioritás

Kidolgozott példa: mobilforgalmú tartalmi webhely

Egy receptoldal forgalmának nagy része mobilról érkezett, sokszor gyenge lefedettségű helyekről. A webhely már egy CDN mögött futott HTTP/2-vel. A csapat bekapcsolta a HTTP/3-at a CDN-en, majd a böngésző hálózati nézetében ellenőrizte, hogy az első betöltésnél h2, a második betöltésnél már h3 jelenik meg a protokoll oszlopban. A hatást a saját terepi mérésükben követték, a protokoll szerinti bontással, és a mobillátogatók betöltési idejét hasonlították össze a bekapcsolás előtti időszakkal. A változtatást külön, más fejlesztések nélkül vezették be, hogy a hatás elkülöníthető legyen.

Kidolgozott példa: a saját szerver, amely nem válaszolt

Egy saját szerveren futó webhelyen a fejlesztő bekapcsolta a QUIC-támogatást és az Alt-Svc fejlécet, a böngésző mégis mindig h2-t mutatott. Kiderült, hogy a szolgáltató hálózati tűzfala csak a TCP 443-as portot engedte, a UDP-t nem. A böngésző megpróbálta a HTTP/3-at, nem kapott választ, és visszaesett. A hiba nem okozott leállást, csak a HTTP/3 előnye maradt el. A tűzfalszabály bővítése után a h3 megjelent. A tanulság: a HTTP/3 hibái csendesek, ezért a bekapcsolás után mindig ellenőrizni kell, hogy tényleg használatban van-e.

Gyakori hibák

A HTTP/3-mal kapcsolatos hibák a legtöbbször nem okoznak látható kárt, mert a visszaesés elrejti őket. Éppen ezért könnyű azt hinni, hogy működik, miközben a látogatók továbbra is HTTP/2-n kapják az oldalt. A másik hibacsoport a túlzott elvárás: a HTTP/3 nem oldja meg a lassú szerverválaszt vagy a nehéz oldalakat.

Tipikus hibák

Zárt UDP-port. A szerver támogatja a QUIC-et, de a tűzfal nem engedi a forgalmat, így minden kapcsolat visszaesik.
Hiányzó vagy hibás Alt-Svc fejléc. A böngésző nem tudja meg, hogy HTTP/3 is elérhető.
A HTTP/2 kikapcsolása. A UDP-t blokkoló hálózatok látogatói elveszítik a gyors protokollt, vagy rosszabb esetben a hozzáférést.
Az első betöltés mérése. A csapat az első, TCP-n induló kapcsolatot nézi, és arra jut, hogy a HTTP/3 nem működik.
Csodavárás. A lassú háttérrendszer, a nagy képek és a blokkoló szkriptek ugyanúgy lassítanak HTTP/3 mellett.
Hiányos terepi mérés. Csak laboratóriumi, jó hálózati mérés készül, amely épp azokat a körülményeket nem mutatja, ahol a HTTP/3 előnye jelentkezik.

Tévhit: a HTTP/3 minden esetben gyorsabb

Jó minőségű, alacsony késleltetésű vezetékes hálózaton a HTTP/2 és a HTTP/3 közötti különbség kicsi lehet. A QUIC előnyei, a gyorsabb kézfogás, a folyamonkénti veszteségkezelés és a kapcsolatmigráció, főleg nagy késleltetésű vagy csomagvesztéses hálózaton érvényesülnek. A UDP-forgalom feldolgozása egyes szervereken több processzoridőt igényelhet, mint a jól optimalizált TCP. A haszon tehát a látogatók hálózati körülményeitől függ, és mérni kell, nem feltételezni.

Tévhit: a HTTP/3 SEO-tényező

A HTTP/3 nem rangsorolási jelzés, és a Googlebot feltérképezésére sincs közvetlen hatása. A keresőoptimalizálás szempontjából annyiban számít, amennyiben a valós látogatók gyorsabb és stabilabb betöltést kapnak. Ha a webhely terepi mutatói már jók, a HTTP/3 bekapcsolása keresőoldalon nem hoz látható változást.

Ellenpélda: a haszon, amely máshol volt

Egy webáruház a lassú mobilbetöltés miatt a HTTP/3 bevezetésétől várt javulást. A bekapcsolás után a mutatók alig mozdultak. A vízesésdiagram megmutatta, hogy a betöltési idő nagy részét a szerver első válaszára való várakozás tette ki, mert a termékoldalak minden kérésnél lassú adatbázis-lekérdezéseket futtattak. A protokoll a hálózati átvitelt gyorsította, de a szerver belső feldolgozására nem volt hatása. A valódi javulást a gyorsítótárazás bevezetése hozta.

Mérés

A HTTP/3 mérésénél először azt kell igazolni, hogy a látogatók valóban HTTP/3-on kapják az oldalt, és csak utána érdemes a teljesítményhatást vizsgálni. Mivel a visszaesés csendes, a használat aránya legalább olyan fontos, mint a sebesség.

A protokoll ellenőrzése

A böngésző fejlesztői eszközeinek hálózati nézetében a protokoll oszlopban a h3 jelzés mutatja a HTTP/3-at. Az első betöltésnél gyakran h2 látszik, ezért az oldalt újra kell tölteni, vagy egy új lapon újra megnyitni. A válaszfejlécek között ellenőrizhető az Alt-Svc megléte. Parancssorból HTTP/3-támogatással fordított curl-lel is tesztelhető a kapcsolat, és nyilvános tesztelő szolgáltatások is jelzik a támogatást.

Terepi mérés

A valós felhasználói adatok mutatják meg, hogy a HTTP/3 hoz-e javulást. Ha a saját mérőkód rögzíti a használt protokollt, amelyet a böngésző Navigation Timing felülete elérhetővé tesz, a mutatók protokoll szerint is bonthatók. A CDN-ek egy része a naplóiban és a statisztikáiban is kimutatja, a kérések mekkora része érkezik HTTP/3-on. A bevezetés előtti és utáni időszakot azonos sablonokon, eszköztípus szerint bontva érdemes összevetni.

Laboratóriumi összehasonlítás

A terepi adatok mellett hasznos egy kontrollált összehasonlítás is. A laboratóriumi mérőeszközök egy részében beállítható a hálózati késleltetés és a csomagvesztés, így ugyanaz az oldal lemérhető jó és rossz hálózati körülmények között, HTTP/2-vel és HTTP/3-mal. A vízesésdiagramon a kapcsolat felépítésének ideje és az erőforrások érkezési sorrendje is összevethető. Egy ilyen mérés nem helyettesíti a valós felhasználói adatokat, de megmutatja, milyen körülmények között várható előny, és segít eldönteni, érdemes-e a bevezetéssel foglalkozni.

A Googlebot oldala

A szervernapló, ha rögzíti a protokollt, megmutatja, milyen protokollon érkeznek a Googlebot kérései. A HTTP/3 bekapcsolása után érdemes ellenőrizni, hogy a feltérképezés zavartalan maradt-e, vagyis nem nőtt meg a hibás válaszok aránya a Search Console feltérképezési statisztikáiban.

Ellenőrzőlista

Ellenőrzés	Eszköz	Jó eredmény
Alt-Svc fejléc	Böngésző, curl	Jelen van, és a HTTP/3-at hirdeti
Protokoll ismételt betöltésnél	Böngésző hálózati nézet	h3 a fő dokumentumnál
UDP 443	Tűzfalszabályok, tesztelő szolgáltatás	Nyitva, a QUIC-kapcsolat létrejön
Visszaesés	UDP-t blokkoló hálózatból próba	Az oldal HTTP/2-n betölt
Használati arány	CDN-statisztika, saját mérés	A kérések jelentős része HTTP/3
Terepi mutatók	Saját mérés, Chrome felhasználói élmény jelentés	Mobilon nem romlanak, lehetőleg javulnak

Mérési ritmus

A bekapcsolás után néhány hétig érdemes sűrűbben figyelni a használati arányt és a terepi mutatókat, utána elég negyedévente, illetve minden infrastruktúra-változás után ellenőrizni. Egy CDN-csere, egy új tűzfal vagy egy szerverfrissítés csendben kikapcsolhatja a HTTP/3-at, és ezt csak a rendszeres ellenőrzés veszi észre.