19 min. olvasd el

HTTP/2: A modern webes teljesítmény teljes útmutatója

A hipertext-transzfer protokoll drámai fejlődésen ment keresztül a kezdetek óta, és a HTTP/2 az egyik legjelentősebb előrelépést jelenti a világhálón keresztüli adatátvitelben. Ha az elmúlt néhány évben gyorsabban töltődtek be a weboldalak, akkor jó eséllyel a HTTP/2 dolgozik a színfalak mögött.

Ez az útmutató mindent leír, amit a HTTP/2-rőltudni kell –az alapvető mechanikától és teljesítményelőnyöktől kezdve a gyakorlati telepítési lépésekig. Akár fejlesztőként szeretné optimalizálni webkiszolgálóját, akár egyszerűen csak kíváncsi arra, hogy mitől működnek a modern weboldalak, itt hasznos információkhoz juthat.

Gyors válasz: Mi a HTTP/2 és miért fontos

A HTTP/2 az 1.1-es verziójú hipertext-továbbítási protokoll jelentős módosítása, amelyet az Internet Engineering Task Force az RFC 7540-es RFC-ben (2015. május) szabványosított. A késleltetés csökkentésére, a hálózati erőforrások jobb kihasználására és a weboldalak jelentősen gyorsabb betöltéséreösszpontosít – mindezta meglévő HTTP-szemantikával való teljes visszafelé kompatibilitás fenntartása mellett.

2026-ban a HTTP/2 elfogadása már szinte mindenhol elterjedt. A W3Techs adatai szerint a legnépszerűbb webhelyek több mint 1/3-a aktívan használja a HTTP/2-t, és a legtöbb nagy CDN (Cloudflare, AWS CloudFront, Fastly) alapértelmezés szerint engedélyezi a HTTPS-forgalom számára. Ha webhelye HTTPS-en fut egy modern webkiszolgálóval, akkor valószínűleg már minden további konfiguráció nélkül kihasználja a HTTP/2 előnyeit.

A protokoll számos olyan új funkciót vezet be, amelyek a HTTP 1.1 teljesítménybeli szűk keresztmetszeteit kezelik:

Multiplexelés: Több adatfolyam egyidejűleg halad egyetlen TCP-kapcsolaton keresztül.
Fejléc tömörítés (HPACK): A fejlécmezők tömörítésének bevezetése, amely drámaian csökkenti a felesleges HTTP-fejléc metaadatokat.
Bináris keretezési réteg: Egy teljesen általános keretréteg, amely a szövegalapú parancsokat hatékony bináris üzenetkeretezéssel helyettesíti.
Kiszolgáló push: Az erőforrások proaktív kézbesítése, mielőtt a böngésző kifejezetten kérné azokat.
Patakok rangsorolása: A kliensek jelzik a kiszolgálóknak, hogy mely erőforrások a legfontosabbak.

Ez a gyakorlatban a következőket jelenti:

Gyorsabb oldalbetöltés, különösen erőforrás-igényes oldalakon
Kevesebb TCP-kapcsolat szükséges eredetenként
Jobb teljesítmény nagy késleltetésű mobilhálózatokon
Javított hálózatkihasználás minden területen

A HTTP/0.9-től a HTTP/2-ig: Egy rövid történet

A HTTP protokoll hosszú utat tett meg azóta, hogy Tim Berners-Lee 1991-ben bemutatta a HTTP/0.9 protokollt, amely egy egyszerű mechanizmus volt a HTML dokumentumok lekérdezésére. A HTTP/1.0 1996-ban következett, fejlécekkel és állapotkódokkal kiegészítve, a HTTP/1.1 pedig az RFC 2068-ban (1997) került szabványosításra, majd később az RFC 2616-ban (1999) továbbfejlesztésre. Közel két évtizeden át a HTTP/1.1 szolgált a kliens-szerver kommunikáció gerinceként a világhálón.

De a világháló drámaian megváltozott. A modern weboldalak egyszerű dokumentumokból összetett alkalmazásokká váltak, amelyek JavaScript-csomagok, CSS-fájlok, képek és API-hívások tucatjait töltik be. A HTTP/1.1 architektúrája még szélessávú kapcsolatok és nagy teljesítményű hardverek esetén is szűk keresztmetszeteket okozott:

A sor elejének blokkolása: Minden TCP-kapcsolat egyszerre csak egy kérést tudott kezelni, ami szükségtelen hálózati forgalmat okozott, mivel az erőforrások sorban álltak.
Kapcsolati többletköltségek: Az asztali webböngészők és a mobil webböngészők általában 6-8 párhuzamos TCP-kapcsolatot nyitottak eredetenként, hogy megkerüljék ezt a korlátozást.
Redundáns fejlécek: Minden HTTP-kérelem ugyanazokat a bő fejléceket (cookie-k, user-agent, accept headerek) küldte el többször.

A Google felismerte ezeket a problémákat, és 2009-ben elindította az SPDY projektet. Az SPDY, amelyet először a Chrome-ban vezettek be 2010 körül, számos újítást vezetett be:

Bináris keretezés a szövegalapú protokollok helyett
Több kérés multiplexelése egyetlen kapcsolaton keresztül
Fejléc tömörítés a rezsiköltségek csökkentése érdekében
A kritikus erőforrások prioritásainak meghatározása

Az IETF HTTP munkacsoportja meglátta az SPDY-ban rejlő lehetőségeket, és 2012-ben elfogadta azt a HTTP/2 kiindulópontjaként. Az ietf http munkacsoportjának kiterjedt munkája után 2015 májusában megjelent az RFC 7540 (HTTP/2) és az RFC 7541 (HPACK).

A böngészők elfogadása gyorsan haladt:

A Chrome a Chrome 51-től kezdve (2016. május) a HTTP/2 javára lemondott az SPDY-ről (HTTP/2).
A Firefox a 36-os verzióban (2015. február) hozzáadta a HTTP/2 támogatást.
A Safari követte a 9-es verzióban (2015. szeptember)
A Microsoft Edge már a kezdeti kiadásától kezdve HTTP/2-támogatással rendelkezik
Még az Internet Explorer 11 is megkapta a HTTP/2 támogatást a Windows 8.1 és újabb operációs rendszereken.

Tervezési célok és fő különbségek a HTTP/1.1-től

A HTTP/2 teljes mértékben kompatibilis a HTTP/1.1 szemantikájával. Az olyan módszerek, mint a GET és a POST ugyanúgy működnek. Az állapotkódok változatlanok maradnak. Az URI-k és a HTTP fejlécek ugyanazokat a szabályokat követik. Ami változik, az az, hogy hogyan mozognak ezek az adatok a vezetéken – a szállítási réteg mechanikája határozza meg a tényleges terhelési sebességet.

A protokoll tervezési céljai egyértelműek voltak:

Cél	Hogyan éri el a HTTP/2
A késleltetés csökkentése	A multiplexelés kiküszöböli a HTTP-szintű vonalfej blokkolását
Jobb kapcsolathasználat	Egyetlen TCP-kapcsolat kezeli az összes kérést a származási helyhez.
Vágott fejléc fejléc	A HPACK tömörítés összezsugorítja a korábban átvitt fejlécértékeket
A mobil teljesítmény javítása	Kevesebb kapcsolat és kisebb fejlécek a nagy késleltetésű hálózatok számára előnyösek

Ennek a kialakításnak a szépsége a visszafelé kompatibilitás az alkalmazás szintjén. A meglévő webes alkalmazás kódját – útvonalak, kezelők, válaszlogika – nem kell megváltoztatni. Csak az ügyfél és a kiszolgáló stacknek kell támogatnia a HTTP/2-t ahhoz, hogy az előnyöket élvezhesse.

Ez éles ellentétben áll a HTTP/1.1-es verzió megoldási lehetőségeivel, amelyeket a fejlesztőknek kézzel kellett megvalósítaniuk:

Tartományi megosztás: Az eszközök elosztása több tartományban, hogy több kapcsolatot nyisson meg
Eszközök összekapcsolása: CSS és JavaScript fájlok összevonása a kérések csökkentése érdekében
Image sprite-ok: Több kép egyesítése egyetlen fájlba
Bélelés: CSS és JavaScript beágyazása közvetlenül a HTML-be

A HTTP/2 alapvető mechanikája, amely ezeket a hackeket helyettesíti:

Bináris keretezési réteg: A keretekre osztott üzenetek hatékonyan szállítják az adatokat bináris protokollegységek formájában.
Multiplexelt adatfolyamok: Több párhuzamos adatcsere történik ugyanazon a kapcsolaton keresztül.
HPACK fejléc tömörítés: Dinamikus táblázatok követik a fejléceket, kiküszöbölve a redundanciát
Kiszolgáló push: A szerverek proaktívan küldenek erőforrásokat, amelyekre az ügyfélnek szüksége lesz.
Patakok rangsorolása: Az ügyfelek a folyamfüggőségi súlyokon keresztül jelzik, hogy mely erőforrások a legfontosabbak.

Bináris keretezés, streamek, üzenetek és multiplexelés

A HTTP/2 középpontjában a bináris keretezési réteg áll, ami alapvető eltérés a HTTP/1.1 szövegalapú formátumától. Minden HTTP-üzenet bináris keretekre bomlik, következetes keretelrendezéssel: egy 9 bájtos keretfejléc, amely tartalmazza a hossz, a típus, a zászlók és az adatfolyam-azonosítókat, majd az opcionális hasznos adatok következnek.

A hierarchia megértéséhez három fogalom megértése szükséges:

A streamek független, kétirányú csatornák egyetlen kapcsolaton belül. Minden adatfolyam egyedi 31 bites azonosítóval rendelkezik. A kliensek páratlan számozású azonosítókkal (1, 3, 5…) indítanak streameket, míg a kiszolgálók páros számozású azonosítókat (2, 4, 6…) használnak a kiszolgáló által kezdeményezett streamekhez, mint például a push. Egy váratlan folyamazonosító hibát vált ki. A maximum concurrent streams beállítása szabályozza, hogy hány stream lehet aktív egyszerre.

Az üzenetek teljes HTTP-kéréseket vagy -válaszokat jelentenek. Egy teljes fejlécblokk egy vagy több keretből áll, és a válaszok több adatkeretet is tartalmazhatnak a testhez. Amikor a vevő a fejlécblokk töredékeivel találkozik, újra összerakja azokat, hogy rekonstruálja a teljes üzenetet.

A keretek a legkisebb egységek a vezetéken. A leggyakoribb keret- és hibatípusok a következők:

ADATKERETEK: A kérés/válasz testének tartalmát hordozza
FEJEZETEK keret: HTTP fejléc mezők, esetleg több keretre osztva, úgynevezett fejléc blokk töredékeket tartalmaz.
BEÁLLÍTÁSOK: Kapcsolatvezérlő üzenetek a konfigurációhoz
WINDOW_UPDATE: Folyamatvezérlő ablak beállításai
PUSH_PROMISE: Bejelenti a szerver push-t
RST_STREAM: Egy folyam hibakóddal történő befejezése
AJÁNDÉK: Kezdeményezi a kapcsolat kíméletes leállítását

A varázslat a multiplexelésen keresztül történik. Mivel a több, egyidejűleg nyitott folyamból származó képkockák egyetlen TCP-kapcsolaton keresztül átlapolhatók – bármelyik végpont szükség szerint átlapolja a képkockákat -, nincs várakozás. A vevő a kereteket folyamazonosító szerint rakja össze újra.

Gondoljunk egy tipikus weboldal betöltésére, amelynek szüksége van:

index.html (10 KB)
styles.css (25 KB)
app.js (100 KB)
logo.png (15 KB)
hőskép.jpg (200 KB)

A HTTP/1.1 esetén a böngésző több kapcsolatot nyit meg, hogy ezeket párhuzamosan lekérje, és így is korlátok közé ütközik. A HTTP/2 esetében mind az öt erőforrás egyidejűleg, egy kapcsolaton keresztül, több adatfolyamként továbbítódik. A különböző adatfolyamokból származó adatkeretek egymásba kapcsolódnak, és mind az ügyfél, mind a kiszolgáló hatékonyan kezeli a teljes kapcsolatot.

Ez kiküszöböli a többszörös TCP-kapcsolatok szükségességét, csökkentve a kapcsolat áramlásvezérlő ablakának terhelését és jelentősen javítva a webes teljesítményt.

Fejléctömörítés HPACK-kel

A HPACK, amelyet az RFC 7541-ben határoztak meg (a HTTP/2-vel együtt jelent meg 2015 májusában), kifejezetten a HTTP/2-hez tervezett fejléctömörítést biztosít. Ez azért fontos, mert a HTTP/1.1 fejlécek bőbeszédűek és teljesen tömörítetlenek voltak, ami minden egyes kérésnél szükségtelen hálózati forgalmat okozott.

Tekintsük egy tipikus HTTP-kérelem fejléceit:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9...
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123def456; tracking=xyz789...

Ezek a fejlécek gyakran meghaladják a 700-800 bájtot kérésenként. A cookie-kkal együtt akár több kilobájtra is duzzadhatnak. Ha ezt megszorozzuk oldalanként több tucatnyi kéréssel, máris jelentős sávszélességet pazarolunk – ez különösen a mobilhálózatokon fájdalmas.

A HPACK három mechanizmuson keresztül tömöríti a fejléceket:

Statikus táblázat: módszer: GET vagy :status: 200), amelyeket soha nem kell továbbítani.
Dinamikus táblázat: A kliens és a kiszolgáló együttesen építi fel a kapcsolatra jellemző táblázatot, amely a korábban átadott fejlécértékeket tárolja az újrafelhasználás érdekében.
Huffman-kódolás: A karakterlánc-értékek kódolása egy előre meghatározott Huffman-táblázat segítségével történik, ami a szöveges ábrázolások összezsugorodását eredményezi.

Az eredmény drámai. Miután az első kérés létrehozza a közös fejléceket a dinamikus táblázatban, a következő kérések csak indexhivatkozásokat továbbíthatnak. A kilobájtosnak induló fejlécek több tíz bájtra zsugorodnak.

A HPACK-et kifejezetten azért tervezték, hogy elkerülje az olyan biztonsági réseket, mint a CRIME és a BREACH, amelyek a korábbi tömörítési sémákat, például az SPDY DEFLATE-jét érintették. A HPACK statikus Huffman-kódok és gondos táblázatkezelés alkalmazásával megakadályozza, hogy a támadók a tömörítési arány elemzését arra használják, hogy titkokat nyerjenek ki a támadó és az áldozat vegyes adataiból.

Érdemes megjegyezni, hogy a HPACK csak a HTTP-fejlécekkel dolgozik. A választestek továbbra is a HTTP-rétegben használják a szabványos tartalomkódolási mechanizmusokat, mint például a gzip vagy a Brotli, teljesen függetlenül a fejléctömörítéstől.

Kiszolgálói push és folyamprioritás

A HTTP/2 két optimalizálási funkciót vezet be, amelyek a HTTP/1.1 megoldások helyettesítésére szolgálnak: a szerver push a proaktív erőforrás-kézbesítéshez és a folyam priorizálása az intelligens erőforrás-rendezéshez.

Kiszolgáló Push

A szerver push lehetővé teszi a webkiszolgáló számára, hogy erőforrásokat küldjön az ügyfélnek, mielőtt az kifejezetten kérné azokat. A mechanizmus a PUSH_PROMISE kereteken keresztül működik:

Ügyfél kérések /index.html
A szerver HTML-tel válaszol, de PUSH_PROMISE kereteket is küld, amelyek bejelentik, hogy a /styles.css és /app.js fájlokat tolja.
A kiszolgáló ezeket az erőforrásokat új, kiszolgáló által kezdeményezett adatfolyamokon küldi (páros számokat használó adatfolyam-azonosítókkal, az alacsonyabb értékű adatfolyam-azonosítók hozzárendelési szabályai szerint).
A böngésző megkapja az erőforrásokat, mielőtt a HTML elemzése felfedezi, hogy szüksége van rájuk

Ez kiküszöböli a körutazásokat. Ahelyett, hogy:

HTML kérése → HTML fogadása
HTML elemzése, a szükséges CSS felfedezése → CSS kérése
CSS elemzése, a szükséges betűtípusok felderítése → Betűtípusok lekérése

A szerver push a 2-3. lépést az 1. lépésben foglalja össze.

A szerver push azonban a gyakorlatban problémásnak bizonyult:

A böngészőkben már vannak gyorsítótárazva erőforrások, ami pazarlóvá teszi a tologatást.
A rosszul konfigurált szerverek túl agresszívan nyomják, pazarolva a sávszélességet
A cache digest mechanizmusok soha nem értek el széles körű elfogadottságot.
Sok CDN és böngésző már alapértelmezés szerint korlátozza vagy letiltja a push szolgáltatást.

Az ügyfelek teljesen letilthatják a push szolgáltatást a SETTINGS_ENABLE_PUSH = 0 beállításával a kapcsolat előszavában. Ha az ügyfélkapcsolat előszava azonnal letiltja a push-t, a kiszolgáló kapcsolat előszava nyugtázásból és megfelelésből áll.

Patakok rangsorolása

A folyamprioritás segítségével az ügyfelek jelezhetik az erőforrások fontosságát, ami segít a kiszolgálóknak a sávszélesség hatékony elosztásában. A mechanizmus a következőket használja:

Súlyok: 1-256 közötti értékek, amelyek a relatív fontosságot jelzik
Függőségek: Függőségi fát alkotva a folyamfüggőségi nyilatkozatokon keresztül.

Gyakorlati példa:

HTML stream (súly 256, nincs függőség) – legmagasabb prioritás
CSS stream (súly 200, HTML-től függ) – magas prioritás
Fold feletti képek (súly 100, a CSS-től függ)
Analytics JavaScript (súly 16, függ a HTML-től) – alacsony prioritás

Ez biztosítja, hogy a kritikus renderelési útvonal erőforrásai előbb érkezzenek meg, ami javítja az érzékelt betöltési sebességet, még akkor is, ha a teljes átviteli idő hasonló marad.

Fontos fenntartások:

A prioritások meghatározása tanácsadói, nem kötelező
A kiszolgáló implementációk nagymértékben eltérnek a prioritások tiszteletben tartását illetően.
A közvetítők (proxyk, CDN-ek) átrendezhetik a kereteket.
A hangoláshoz valós forgalommal való tesztelésre van szükség, nem feltételezésekre.

A meghirdetett párhuzamos folyam korlát azt befolyásolja, hogy hány folyamnak lehet egyszerre aktív prioritása.

Folyamszabályozás, hibakezelés és biztonsági megfontolások

A HTTP/2 saját folyamszabályozást és hibakezelést valósít meg a TCP felett, olyan forgatókönyveket kezelve, ahol az alkalmazási szintű intelligencia felülmúlja a szállítási szintű alapértelmezéseket.

Áramlásszabályozás

Az adatfolyam-szabályozás megakadályozza, hogy a gyors küldő felek túlterheljék a lassú vevőket. A HTTP/2 kredit alapú rendszert használ a WINDOW_UPDATE keretekkel:

Minden adatfolyamnak saját vevői áramlásvezérlő ablaka van
A kapcsolatnak van egy kapcsolatáramlás-ellenőrző ablaka is
Alapértelmezett ablakméret: 65,535 bájt (64 KB)
A küldő nem küldhet DATA kereteket a vevő rendelkezésre álló ablakát meghaladóan.
A vevők WINDOW_UPDATE kereteket küldenek, hogy több hitelt adjanak.

Főbb jellemzők:

Az adatáramlás-szabályozás hop-by-hop (minden egyes feladó/vevő pár között érvényes).
Nem lehet letiltani
Csak a DATA képkockák számítanak az ablakba; más kötelező képkocka adatok nem számítanak bele.
A folyamáramlás-szabályozás és a kapcsolatáramlás-szabályozás egymástól függetlenül működik.

Ez megakadályozza, hogy egyetlen gyors adatfolyam monopolizálja a kapcsolat erőforrásait, ami különösen fontos, ha proxyk vagy CDN-ek állnak az ügyfelek és az eredet között.

Hibakezelés

A HTTP/2 részletes hibajelzést biztosít:

Patakszintű hibák: Az RST_STREAM azonnal leállítja az egyik adatfolyamot anélkül, hogy a többit befolyásolná, és olyan hibakódokat tartalmaz, mint a PROTOCOL_ERROR vagy a FLOW_CONTROL_ERROR.
Csatlakozási szintű hibák: A GOAWAY méltóságteljesen leállítja a kapcsolatot, lehetővé téve a folyamatban lévő kérések befejezését, miközben megakadályozza az új kéréseket.

A protokoll hibakód-nyilvántartást határoz meg, amely a következőket tartalmazza:

PROTOCOL_ERROR (0x1): Általános protokollsértés
FLOW_CONTROL_ERROR (0x3): A folyamszabályozási szabályok megsértése
FRAME_SIZE_ERROR (0x6): SETTINGS_MAX_FRAME_SIZE túllépte a keret méretét
INADEQUATE_SECURITY (0xc): A szállítási réteg biztonsági konfigurációja elégtelen

Biztonsági megfontolások

Bár az RFC 7540 technikailag nem írja elő a titkosítást, minden nagyobb webböngésző megköveteli a HTTP/2-t a szállítási réteg biztonsága (TLS) felett. Ezáltal a TLS 1.2+ a de facto alapvonal:

A kapcsolat TLS kézfogással kezdődik, beleértve az ALPN-t (Application-Layer Protocol Negotiation – alkalmazási szintű protokolltárgyalás)
ALPN kiterjesztés tárgyalja a „h2” azonosítót a HTTP/2 számára
A kiszolgálóknak kerülniük kell a specifikáció által feketelistára tett gyenge titkosítási készleteket.
Az RC4-et vagy más elavult algoritmusokat használó titkosítási készletek INADEQUATE_SECURITY hibát váltanak ki.

Az adatvédelmi megfontolások közé tartoznak:

A BEÁLLÍTÁSOK és a prioritási minták ujjlenyomatot vehetnek az ügyfelekről.
Eredetenként egyetlen kapcsolat korrelálja az összes felhasználói tevékenységet az adott eredethez.
A bináris protokoll elrejti a forgalmat, de nem rejti el a hálózati megfigyelők elől

TCP Head-of-Line blokkolás

A HTTP/2 a multiplexelés révén megoldja a HTTP-szintű sorfejblokkolást, de a TCP-szintű blokkolás megmarad. Ha egy TCP-csomag elveszik, az adott kapcsolat összes adatfolyama leáll, amíg az újraküldés be nem fejeződik – még azok is, amelyek adatai sikeresen megérkeztek.

Ez a korlátozás motiválta a HTTP/3-at, amely a QUIC-en (UDP-alapú) fut, hogy valódi folyamfüggetlenséget biztosítson. Az egyik adatfolyamot érintő csomagvesztés nem blokkolja a többit.

A HTTP/2 telepítése és használata a gyakorlatban

2026-ban a HTTP/2 engedélyezése egyszerű. A legtöbb modern webkiszolgáló és CDN már alapból támogatja, elsősorban HTTPS-en keresztül. A HTTP frissítési mechanizmus átláthatóan kezeli a tárgyalásokat.

Ügyféloldali követelmények

A felhasználóknak nem kell semmi különöset tenniük:

Minden modern asztali webböngésző (Chrome, Firefox, Safari, Edge) alapértelmezés szerint támogatja a HTTP/2-t.
A mobil webböngészők (Chrome Androidon, Safari iOS-en) teljes támogatást nyújtanak.
A böngésző aktuális verzióinak használata biztosítja a kompatibilitást
A HTTP/2 automatikusan tárgyal, ha elérhető

Szerveroldali konfiguráció

Apache HTTP szerver (2.4.17+):

A mod_http2 modul engedélyezése (nem a régebbi mod_spdy)
Protokollok hozzáadása h2 http/1.1 a TLS virtuális hosztokhoz
Az OpenSSL verziójának ALPN támogatásának biztosítása

Nginx (1.9.5+):

server {
    listen 443 ssl http2;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    # ... rest of configuration
}

IIS (Windows Server 2016+):

A HTTP/2 alapértelmezés szerint engedélyezett HTTPS TLS 1.2+ esetén
Nincs szükség további konfigurációra

CDN szolgáltatók:

Cloudflare: HTTP/2 alapértelmezés szerint engedélyezve minden tervezetben
AWS CloudFront: HTTPS disztribúciók esetén alapértelmezés szerint engedélyezve.
Fastly: Támogatott és alapértelmezés szerint engedélyezett

Ellenőrzés és hibaelhárítás

Ellenőrizze, hogy a HTTP/2 működik-e ezzel az ellenőrző listával:

Böngésző DevTools: h2″: Nyissa meg a Hálózat lapot, engedélyezze a Protokoll oszlopot, keresse a „h2”-t.
Parancssor: curl –http2 -I https://example.com a HTTP/2-t mutatja a válaszban.
Online eszközök: HTTP/2 tesztszolgáltatások a konfiguráció ellenőrzésére
Ellenőrizze a közvetítőket: CDN-nek vagy fordított proxynek támogatnia kell a HTTP/2-t, nem csak az eredeti kiszolgálónak.

A HTTP/2-t akadályozó gyakori problémák:

OpenSSL verzió túl régi az ALPN támogatáshoz
Csak TLS 1.0/1.1 konfiguráció
Gyenge titkosítási készleteket kiváltó visszaesés
Rosszul konfigurált proxy, amely eltávolítja a HTTP/2 támogatást

HTTP/2 és azon túl

A HTTP/2 továbbra is a modern webes kommunikáció domináns protokollja marad, még akkor is, amikor a HTTP/3 (RFC 9114, 2022-ben jelent meg) bevezetése megkezdődik. A HTTP/3 a QUIC-en keresztül futó TCP head-of-line blokkolást kezeli, de a HTTP/2 egyetlen TCP-kapcsolati modellje továbbra is hatékonyan szolgálja ki a webes forgalom nagy részét.

A legtöbb webhely számára a HTTP/2 minimális konfigurációs erőfeszítéssel jelentős teljesítménynövekedést biztosít. Kezdje el még ma a HTTP/2-n keresztüli keretcserét, és a felhasználók – akár asztali, akár mobileszközökön – gyorsabb, hatékonyabb oldalbetöltést tapasztalhatnak.

A legfontosabb tudnivalók

A HTTP/2 forradalmasítja a webes teljesítményt a multiplexelés révén, amely több egyidejű adatcserét tesz lehetővé egyetlen kapcsolaton keresztül.
A HPACK fejléc tömörítés kiküszöböli a redundáns fejlécek továbbítását, ami különösen a mobil felhasználók számára előnyös.
A szerver push és a stream priorizálás optimalizálja az erőforrás-kiszolgálást, bár a megvalósítás eltérő lehet
A folyamszabályozás megakadályozza az erőforrás-hiányt több adatfolyam között
A telepítés egyszerű a modern szervereken, elsősorban HTTPS konfigurációt igényel.
Minden nagyobb böngésző támogatja a HTTP/2-t, így a végfelhasználók számára zökkenőmentes a bevezetés.

Következő lépések

Ha még nem ellenőrizte a HTTP/2-t a webszerverén, itt az ideje. Nyissa meg a böngésző fejlesztői eszközeit, töltse be a webhelyét, és ellenőrizze a Protokoll oszlopot. Ha „http/1.1”-t lát „h2” helyett, vizsgálja felül a kiszolgáló konfigurációját – jelentős teljesítménynövekedést hagyhat ki az asztalra.

Aki már használja a HTTP/2-t, fontolja meg a kiszolgáló HTTP/2-kapcsolati mérőszámainak nyomon követését. Annak megértése, hogyan viselkedik több egyidejű adatfolyam valós forgalom mellett, segít azonosítani az optimalizálási lehetőségeket, mielőtt a felhasználók észrevennék a problémákat.