HTTP/2: teljes útmutató

A HTTP/2 a HTTP protokoll második fő verziója, amely a kéréseket és válaszokat bináris keretekre bontja, és egyetlen kapcsolaton párhuzamosan továbbítja őket. A fejléceket tömöríti, így kevesebb adat utazik feleslegesen. A böngészők csak titkosított kapcsolaton használják, a Googlebot pedig ott, ahol előnyös, már HTTP/2-n is feltérképez. Közvetlen rangsorolási előnyt nem ad, a gyorsabb betöltésen keresztül hat.

Alapfogalmak

A HTTP az a nyelv, amelyen a böngésző és a szerver egymással beszél: a böngésző kérést küld, a szerver választ ad. A HTTP/1.1 évtizedekig szolgálta a webet, de egy olyan korban tervezték, amikor egy oldal néhány fájlból állt. A mai oldalak tucatnyi, sokszor száznál is több erőforrást töltenek be: stíluslapokat, szkripteket, képeket, betűkészleteket. A HTTP/1.1 egy kapcsolaton egyszerre egy kérést tud kiszolgálni, ezért a böngészők több párhuzamos kapcsolatot nyitottak, a fejlesztők pedig trükkökhöz folyamodtak, hogy kevesebb kéréssel boldoguljanak.

A HTTP/2 ezt a korlátot oldja fel. A kérések jelentése nem változott: ugyanazok a metódusok, státuszkódok és fejlécek maradtak, ezért a webhely tartalmán és az URL-eken semmit nem kell módosítani. Az változott meg, ahogyan ezek az üzenetek a hálózaton utaznak. A protokollt az IETF szabványosította, a Google korábbi SPDY kísérleti protokolljának tapasztalataira építve.

A legfontosabb fogalmak

Fogalom	Jelentés	Gyakorlati következmény
Bináris keretezés	Az üzenetek szöveg helyett bináris keretekben utaznak	Hatékonyabb feldolgozás, kevesebb értelmezési hiba
Folyam (stream)	Egy kérés és a hozzá tartozó válasz önálló csatornája a kapcsolaton belül	Sok folyam futhat egyszerre ugyanazon a kapcsolaton
Multiplexelés	A különböző folyamok keretei összefésülve haladnak egy kapcsolaton	Nincs szükség több párhuzamos kapcsolatra
Fejléctömörítés (HPACK)	Az ismétlődő fejlécek tömörítve, hivatkozással utaznak	Sok kis kérésnél jelentős adatmegtakarítás
Prioritás	A kliens jelezheti, mely erőforrások fontosabbak	A megvalósítás szerverenként eltér, nem mindig érvényesül
Server push	A szerver kérés nélkül küld erőforrást	A gyakorlatban nem vált be, a nagy böngészők kivezették

HTTP/2 és titkosítás

A szabvány elvben titkosítatlan kapcsolaton is engedi a HTTP/2-t, a böngészők azonban csak TLS-en, vagyis HTTPS-en támogatják. A gyakorlatban tehát a HTTP/2 előfeltétele a működő HTTPS. A böngésző és a szerver a TLS-kézfogás során, egy ALPN nevű bővítménnyel egyezik meg arról, hogy HTTP/2-t vagy HTTP/1.1-et használnak. Ha a szerver nem ajánlja fel a HTTP/2-t, a kapcsolat automatikusan HTTP/1.1-en megy tovább, a látogató ebből semmit nem érzékel. A titkosításról a HTTPS útmutató szól részletesen.

Mit jelent a HTTP/2 a keresőnek?

A Google közölte, hogy a Googlebot bizonyos webhelyeken HTTP/2-n térképez fel, ha ez a webhelynek és a keresőnek is előnyös. A döntést a Google hozza meg, a webhelytulajdonos ezt nem tudja kikényszeríteni. A Google azt is egyértelművé tette, hogy a HTTP/2-n történő feltérképezés nem jelent rangsorolási előnyt. Az előny erőforrás-oldali: egy kapcsolaton több oldal is lekérhető, ami a szervert és a keresőt is kevésbé terheli. A felhasználók szempontjából a HTTP/2 a betöltési sebességen keresztül hat, ami a Core Web Vitals mutatóiban és az élményben jelenhet meg.

Hogyan működik?

A HTTP/2 legfontosabb újítása, hogy egyetlen TCP-kapcsolaton több kérést és választ tud egyszerre kezelni. A HTTP/1.1-ben ha egy kapcsolaton a böngésző kért valamit, meg kellett várnia a választ, mielőtt a következő kérést ugyanazon a kapcsolaton elküldte volna. Ha egy válasz lassú volt, minden mögötte álló kérés várt. Ezt nevezik a sor eleji blokkolás (head-of-line blocking) problémájának az alkalmazás szintjén.

Keretek és folyamok

A HTTP/2 minden üzenetet kisebb, bináris keretekre bont. Van fejléckeret és adatkeret, és mindegyik keret tartalmazza annak a folyamnak az azonosítóját, amelyhez tartozik. A böngésző egymás után több kérést is elindíthat, mindegyik saját folyamot kap. A szerver a válaszok kereteit összefésülve küldi vissza, a böngésző pedig az azonosítók alapján rakja össze őket. Így egy nagy kép letöltése közben egy kis stíluslap is megérkezhet, nem kell kivárnia a kép végét.

Egy kapcsolat a sok helyett

A HTTP/1.1-es böngészők egy gépnévhez jellemzően néhány párhuzamos kapcsolatot nyitottak. Minden új kapcsolat felépítése idő: TCP-kézfogás, TLS-kézfogás, és a kapcsolat kezdeti, óvatos adatküldési szakasza. A HTTP/2 egy kapcsolatot használ gépnevenként, és azon mindent továbbít. Ez kevesebb kézfogást, jobb kapcsolatkihasználást és kisebb szerverterhelést jelent. Bizonyos feltételek mellett a böngésző ugyanazt a kapcsolatot több gépnévhez is újrahasznosíthatja, ha azok ugyanarra a szerverre mutatnak, és a tanúsítvány mindegyiket lefedi.

Fejléctömörítés

Egy oldalbetöltésnél a kérések fejlécei nagyrészt ismétlődnek: ugyanaz a böngészőazonosító, ugyanazok a sütik, ugyanazok az elfogadott formátumok. A HTTP/1.1 ezeket minden kérésnél teljes terjedelmükben elküldte. A HTTP/2 HPACK nevű tömörítése egy közös táblázatot tart fenn a két fél között, és a már elküldött fejlécekre csak hivatkozik. Sok kis kérésnél, különösen nagy sütiknél, ez érezhető adatmegtakarítás.

Ami megmaradt: a TCP-szintű blokkolás

A HTTP/2 az alkalmazás szintjén megszüntette a sor eleji blokkolást, a TCP szintjén azonban nem. Mivel minden folyam egyetlen TCP-kapcsolaton utazik, ha egy csomag elvész, a TCP addig tartja vissza a mögötte érkező adatokat, amíg az elveszett csomag újra meg nem érkezik. Ilyenkor az összes folyam vár, akkor is, ha az elveszett csomag csak az egyikhez tartozott. Jó minőségű hálózaton ez ritkán okoz gondot, csomagvesztéses mobilhálózaton viszont érezhető lehet. Ezt a korlátot a HTTP/3 oldja fel, amely a TCP helyett a QUIC protokollra épül.

A server push sorsa

A HTTP/2 eredeti ígéretei között szerepelt a server push: a szerver a HTML mellé kérés nélkül is elküldhette volna a szükséges stíluslapot vagy szkriptet. A gyakorlatban ez ritkán hozott mérhető javulást, mert a szerver nem tudta, mi van már a böngésző gyorsítótárában, és gyakran feleslegesen küldött adatot. A Chrome kivezette a támogatását, ezért ma nem érdemes rá építeni. Helyette az előtöltési tippek, például a preload, illetve a 103 Early Hints válasz a használt eszközök.

Fő módszerek

A HTTP/2 bekapcsolása a legtöbb webhelynél konfigurációs kérdés, nem fejlesztési projekt. A modern webszerverek, terheléselosztók és CDN-ek támogatják, sokszor alapértelmezés szerint be is kapcsolják. A valódi munka az, hogy a HTTP/1.1 korában bevett optimalizációkat felülvizsgáljuk, mert némelyik HTTP/2 mellett már nem segít, sőt árthat.

1. Bekapcsolás a kiszolgálón vagy a CDN-en

Ha a webhely CDN mögött fut, a látogató a CDN peremszerverével beszél, ezért a HTTP/2-t ott kell engedélyezni. A CDN és a saját szerver közötti kapcsolat protokollja ettől független. Ha nincs CDN, a webszerver konfigurációjában kell bekapcsolni a HTTP/2-t a HTTPS-es virtuális hosztokra. Előfeltétel a működő TLS és egy olyan szerververzió, amely támogatja a protokollt. A CDN útmutató bővebben foglalkozik a peremszerverek szerepével.

2. A régi trükkök felülvizsgálata

A HTTP/1.1 korában három trükk terjedt el a kérések számának csökkentésére vagy a párhuzamosság növelésére. HTTP/2 mellett mindhármat újra kell gondolni.

Domain sharding. Az erőforrásokat több aldomainre osztották, hogy a böngésző több kapcsolatot nyisson. HTTP/2 mellett ez felesleges kézfogásokat okoz, és megakadályozza, hogy minden egy kapcsolaton menjen. Általában érdemes megszüntetni.
Fájlok összefűzése. Minden szkriptet egy nagy fájlba csomagoltak. HTTP/2 mellett a kisebb, külön gyorsítótárazható fájlok gyakran jobbak, mert egy apró változás nem érvényteleníti az egész csomagot. A szélsőséges szétbontás viszont más költségekkel jár, ezért a mérés dönt.
Képsprite-ok és beágyazás. A kis képeket egy nagy képbe vagy közvetlenül a kódba ágyazták. HTTP/2 mellett ez kevésbé indokolt, és a gyorsítótárazhatóság szempontjából hátrányos lehet.

3. Kritikus erőforrások előtöltése

A multiplexelés nem jelenti azt, hogy a böngésző mindent egyszerre és azonnal kér le. Azt kéri le, amiről tud. Ha egy fontos betűkészletre vagy a fő képre csak egy stíluslap mélyéről derül ki, hogy kell, a HTTP/2 sem segít a késői felfedezésen. Ilyenkor a preload tipp vagy a 103 Early Hints válasz hozza előre a lekérést. Erről a preload útmutató ír részletesen.

4. Gyorsítótárazás és tömörítés rendben tartása

A HTTP/2 a hálózati átvitel módját javítja, a letöltendő adat mennyiségét nem. A szöveges erőforrások tömörítése, a képek megfelelő mérete és formátuma, valamint a helyes gyorsítótár-fejlécek ugyanúgy fontosak maradnak.

Döntési szabály: mi marad, mi megy?

Régi gyakorlat	HTTP/2 mellett	Indok
Domain sharding	Megszüntetni	Felesleges kapcsolatok, gyengébb kihasználás
Minden szkript egy fájlban	Mérés alapján mérsékelten bontani	Jobb gyorsítótárazás, de nem végtelen szétbontás
Kis képek beágyazása a kódba	Csak nagyon apró, kritikus elemeknél	A beágyazott tartalom nem gyorsítótárazható külön
Server push	Nem használni	A böngészők kivezették, helyette preload vagy Early Hints
Tömörítés, képoptimalizálás	Megtartani	A protokoll nem csökkenti az adatmennyiséget

Kidolgozott példa: egy hírportál aldomainjei

Egy hírportál a HTTP/1.1 korából megörökölt felépítéssel dolgozott: a képek három külön aldomainről töltődtek be, a szkriptek egy negyedikről. A szerver már régóta támogatta a HTTP/2-t, a böngészők mégis négy-öt külön kapcsolatot nyitottak, mindegyikhez saját TLS-kézfogással. A csapat a böngésző hálózati nézetében, a kapcsolatazonosítók alapján látta, hogy az erőforrások nem egy kapcsolaton érkeznek. A képeket és szkripteket egy, a fő domainnel azonos tanúsítványú gépnévre vonták össze. Az új felállásban a hálózati nézet kevesebb kapcsolatot és kevesebb kézfogást mutatott, és a terepi adatokban a nagy tartalmi elem megjelenési ideje javult. A változtatás előtt és után ugyanazokon az oldalsablonokon mérték az eredményt, hogy a hatás elkülöníthető legyen.

Kidolgozott példa: a bekapcsolás, amely nem látszott

Egy webáruház csapata a webszerveren bekapcsolta a HTTP/2-t, de a böngésző továbbra is HTTP/1.1-et mutatott. A vizsgálat kiderítette, hogy a webáruház egy terheléselosztó mögött futott, amely a TLS-t lezárta, és csak HTTP/1.1-et ajánlott fel a látogatóknak. A webszerver beállítása így hatástalan volt, mert a látogató soha nem beszélt vele közvetlenül. A HTTP/2-t a terheléselosztón kellett engedélyezni. A tanulság, hogy a protokollt mindig azon a ponton kell beállítani, ahol a látogató kapcsolata véget ér.

Gyakori hibák

A HTTP/2 bevezetésének hibái ritkán okoznak leállást. Tipikusan az a baj, hogy a protokoll be van kapcsolva, de a várt előny elmarad, vagy a csapat túl sokat vár tőle, és közben a valódi szűk keresztmetszet máshol van.

Tipikus hibák

Rossz ponton bekapcsolva. A webszerveren él a HTTP/2, de előtte egy CDN vagy terheléselosztó csak HTTP/1.1-et ajánl.
Megmaradt domain sharding. A régi aldomainek miatt a böngésző továbbra is sok kapcsolatot nyit.
Server push konfiguráció a régi időkből. Felesleges beállítás, amely a böngészők többségében már nem hat.
Túlzott fájlszétbontás. Száz apró szkript a nagy csomag helyett. A kérésenkénti költség kisebb, de nem nulla, és a tömörítés is gyengébb lehet.
A HTTP/2-től várt csoda. Egy lassú szerverválasz, egy túl nagy kép vagy egy blokkoló szkript ugyanúgy lassú marad.
Hibás TLS-beállítás. Ha az ALPN-egyeztetés nem működik, a kapcsolat csendben visszaesik HTTP/1.1-re.

Tévhit: a HTTP/2 rangsorolási tényező

A Google kifejezetten közölte, hogy a HTTP/2-n történő feltérképezés nem jár rangsorolási előnnyel. Aki a HTTP/2-t SEO-trükként kezeli, rossz helyen keresi a hatást. A protokoll a betöltési sebességen és a szerverterhelésen keresztül számít, és csak annyiban, amennyiben a webhely valóban profitál a párhuzamos kérésekből.

Tévhit: HTTP/2 mellett a kérések száma nem számít

A multiplexelés olcsóbbá tette a kéréseket, de nem ingyenessé. Minden kérésnek van feldolgozási költsége a böngészőben és a szerveren, és minden erőforrást le kell tölteni. Egy oldal, amely több száz erőforrást tölt be, HTTP/2 mellett is lassú lehet. A cél továbbra is az, hogy csak a szükséges erőforrások töltődjenek be, a kritikusak pedig korán.

Ellenpélda: rossz hálózaton lassabb

Egy csapat összehasonlító mérést végzett HTTP/1.1 és HTTP/2 között, és meglepődve látta, hogy erősen csomagvesztéses, szimulált mobilhálózaton a HTTP/2 nem volt jobb, egyes méréseknél rosszabbul teljesített. Ennek oka a TCP-szintű blokkolás: több párhuzamos kapcsolatnál egy csomag elvesztése csak az egyik kapcsolatot fogja vissza, egyetlen kapcsolatnál viszont mindent. Ez nem ok a HTTP/2 kikapcsolására, hiszen átlagos körülmények között előnyös, de jól mutatja, miért jött létre a HTTP/3.

Mérés

A HTTP/2 mérése két kérdésből áll: valóban HTTP/2-n érkezik-e a forgalom, és ebből származik-e mérhető előny. Az első egyszerű technikai ellenőrzés, a második összehasonlító teljesítménymérés.

A protokoll ellenőrzése

A böngésző fejlesztői eszközeinek hálózati nézetében bekapcsolható a protokoll oszlop, ahol a h2 jelzés mutatja a HTTP/2-t. Ugyanitt a kapcsolatazonosító oszlopból kiderül, hány külön kapcsolat nyílt. Parancssorból a curl --http2 kapcsolóval és részletes kimenettel ellenőrizhető, hogy a szerver elfogadja-e a HTTP/2-t. Nyilvános tesztelő szolgáltatások is megmutatják, mely protokollokat ajánlja a szerver.

Teljesítménymérés

A teljesítményt laboratóriumi és terepi adatokkal is érdemes mérni. Laboratóriumban a vízesésdiagram mutatja, hogyan töltődnek be párhuzamosan az erőforrások, és hol vannak üres, várakozó szakaszok. Terepen a valós felhasználók adatai, például a Chrome felhasználói élmény jelentés vagy a saját mérés, mutatják a Core Web Vitals mutatók alakulását. A változtatás előtti és utáni időszakot azonos oldalsablonokon érdemes összevetni.

A Googlebot oldala

A Search Console feltérképezési statisztikák jelentése nem bontja protokoll szerint a kéréseket, a szervernapló viszont igen, ha a naplóformátum tartalmazza a protokollt. Ebből kiderül, hogy a Googlebot kérései HTTP/2-n vagy HTTP/1.1-en érkeznek-e. A Google dokumentációja szerint ha egy webhely nem szeretné, hogy HTTP/2-n térképezzék fel, a szerver egy erre szolgáló, 421-es válasszal jelezheti ezt.

Ellenőrzőlista

Ellenőrzés	Eszköz	Jó eredmény
Protokoll a látogatóknál	Böngésző hálózati nézet	h2 vagy h3 a fő dokumentumnál és az erőforrásoknál
Kapcsolatok száma	Kapcsolatazonosító oszlop	Gépnevenként egy kapcsolat, kevés gépnév
Protokoll a bekapcsolási ponton	curl, tesztelő szolgáltatás	A CDN vagy terheléselosztó felajánlja a HTTP/2-t
Régi trükkök	Forráskód, hálózati nézet	Nincs felesleges sharding, nincs server push
Kritikus erőforrások	Vízesésdiagram	Korán indulnak, nem késve derülnek ki
Googlebot protokollja	Szervernapló	Ismert, és nincs hiba a kéréseknél

Mérési ritmus és értelmezés

A HTTP/2 bekapcsolása egyszeri esemény, a hatását mégis érdemes néhány hétig követni. Rögzítsd a kiinduló állapotot: a fő oldalsablonok vízesésdiagramját, a kapcsolatok számát és a terepi Core Web Vitals értékeket. A bekapcsolás után ugyanezeket nézd meg újra, és csak a protokollváltást változtasd, hogy a hatás ne keveredjen más fejlesztésekkel. Ha a mérés nem mutat javulást, az nem hiba: kevés erőforrású, egyszerű oldalaknál a HTTP/1.1 és a HTTP/2 közötti különbség kicsi lehet. Ilyenkor a figyelmet a szerverválaszra, a képekre és a blokkoló szkriptekre érdemes fordítani. Egy CDN- vagy szervercsere után mindig ellenőrizd újra a protokollt, mert egy új beállítás csendben visszaállíthatja a HTTP/1.1-et.