Mi az a HTTP/3? És miért lehet számodra is hasznos? (Frissítve, 2022.08.29.)

Tartalomjegyzék
Bővített tartalomjegyzék

Míg régen az internet chatfórumokat és blogokat jelentett, mára már 4K-s videókat nézünk rajta, képeket szerkesztünk, játszunk, vásárolunk, bankolunk, home office-ban használjuk munkára, stb. Ahogy egyre komplexebbé váltak a webes alkalmazások, úgy nőtt az igény egy hatékonyabb és biztonságosabb internetprotokollra. Ez lett a HTTP/3. (Frissítés, 2022.08.29. – Több ponton is bővítettük a bejegyzést, így ezzel a fejezettel is: Mennyivel gyorsabb a gyakorlatban a HTTP/3?)

A HTTP protokoll – mely a kliens és a szerver közötti adattovábbításról szól -, az elmúlt években több fejlődési fokozaton ment át. Annak idején mi is írtunk a HTTP/2-ről, mára azonban eljutottunk a HTTP/3-ig, melynél további javítások történtek a fájlátvitelek kezelésében, és új funkciók jelentek meg.

A HTTP/3 a legújabb HTTP-generáció. Ez az internetprotokoll abban az alkalmazási rétegben működik, ahol a felhasználók interakcióba lépnek a webbel és annak erőforrásaival. Célja, hogy gyorsabb és hatékonyabb internetes élményt kínáljon megfelelő biztonság mellett.

Egyrészt elmozdult a TCP-től (Transmission Control Protocol) az UDP-hez (User Datagram Protocol), így letudva néhány TCP miatti korlátot, illetve tovább javult a teljesítmény és a felhasználói biztonság. És habár a végső közzététel még nem történt meg, a böngészők 75 százaléka (2022 júliusában) már támogatja. Ha a Safarinak is sikerül megoldani, ez a 75 százalék nagyot fog ugrani felfelé.

Emellett érdemes tudni, hogy az úgynevezett top 10 millió weboldalnak a 25 százaléka – többek között a Google és a Facebook – már használja a HTTP/3 protokollt. Tulajdonképpen, ha használsz olyan eszközöket, mint a Google Analytics, a Tag Manager vagy a Google Fonts, akkor már részben Te is használtad a protokollt.

De mi is a HTTP/3 és milyen előnyei vannak?

Mint a régebbi, HTTP/2-ről szóló bejegyzésünkben is olvashattad, a HTTP/1.1 úgy működött, hogy minden egyes fájlnak meg volt a maga kapcsolata. A weboldalak azonban elég bonyolultak kezdtek lenni, és elég sok fájlt kellett átvinni egy weboldal betöltéséhez. A böngészők korlátozták a párhuzamos kapcsolatokat, így pedig lassult a betöltési idő. A HTTP/2 ezt a problémát oldotta meg úgy, hogy lehetővé tette egyetlen kapcsolaton több fájl átvitelét. Ez persze még nem oldott meg minden nehézséget, melyet a TCP protokoll okozott.

A TCP ugyanis kronologikus sorrendben szállítja a csomagokat, ami azt is jelenti, hogy ha egy csomag hiányzik, akkor az egész kapcsolat leáll, egészen addig, amíg meg nem érkezik az adott csomag. Emiatt pedig hiába történhetett egyszerre több fájl átvitele, ha a TCP miatt megállt időnként a folyamat.

De volt egy másik probléma is a TCP-vel. Ez pedig az, hogy nincs összekapcsolva a TLS protokoll használatával. Ez azt jelenti, hogy weboldalak lehetnek egyszerre biztonságosak és nem biztonságosak. Eredményeként pedig a szerver és kliens között bonyolultabbá válik a kommunikáció az adatok továbbítása előtt.

A HTTP/3 ezt úgy oldja meg, hogy a TCP helyett UDP-t használ és ezáltal három olyan funkcióval találkozhatunk, ami megkülönbözteti a HTTP/1.1-től és a HTTP/2-től. Egyrészt  független bytefolyamokat használ az egyes fájlokhoz, ami azt jelenti, hogy az elveszett csomagok miatt nem az egész kapcsolat áll le, csak egy bizonyos folyam, egészen addig, amíg a csomag újraküldésre nem kerül.

A HTTP/2 és HTTP/3 közötti különbség leegyszerűsítve

A másik dolog a TLS integráció, vagyis a TLS 1.3 beépítése a HTTP/3-ba. Tehát itt már nem két külön protokoll egymástól független működéséről van szó, hanem egyetlen gyors és biztonságos kézfogás elegendő a QUIC protokoll segítségével, vagyis az utak számának csökkenése történik kettőről (illetve TLS 1.2 esetén háromról) egyre. Ez gyorsabb és biztonságosabb kapcsolatot jelent a felhasználók számára. A kéréseket és a fejléceket pedig a QPACK tömöríti a HPACK helyett.

Az eltérés a két megoldás között

Persze ennek következménye az is, hogy a HTTP/3 csak biztonságos weboldalakon használható, hiszen a TLS és az UDP szorosan összefonódik. Technikailag a HTTP/2 használható lett volna nem biztonságos oldalakon is, azonban ez azért nem történt meg mégsem, mert egyetlen nagyobb böngésző sem tette lehetővé.

A HTTP/3 tehát gyors UDP kapcsolatot használ. Az UDP megbízhatatlanságát küszöböli ki a QUIC, mely natív multiplexeléssel, csomagellenőrzési és helyreállítási protokollokkal megbízható kapcsolatot hoz létre. Ugyanakkor a HTTP/3 automatikus TLS-protokollja megoldja a titkosítást anélkül, hogy újabb körökre lenne szükség a kliens és a szerver között. Így jön létre a gyors, megbízható és biztonságos kapcsolat, mely megteremti a jó felhasználói élményt.

Egy további nagy változás, hogy IP-k használata helyett a HTTP/3 kapcsolati ID-ket használ a csomagok irányítására. Ez azt jelenti, hogy kezelni tudja a hálózati változásokat anélkül, hogy újra kellene építeni a kapcsolatot. Ez pedig rendkívül hasznos dolog a mobilos netezés korában, amikor a felhasználók gyakran váltanak például wifi és mobilhálózat között.

Mennyivel gyorsabb a gyakorlatban a HTTP/3?

Mint láttuk, a HTTP/3 a gyorsabb és hatékonyabb internetkapcsolat révén javítja a felhasználói élményt. De számokban ez miként mutatkozik meg? A Request Metrics megvizsgálta a kérdést, vagyis azt, hogy mennyivel gyorsabban töltődnek be a weboldalak HTTP/2, illetve HTTP/3 használatával, mégpedig három különböző méretű weboldal esetében. Azt tapasztalták, hogy míg egy kisméretű weboldalnál HTTP/2 esetében 500 ms alatt történt meg az adatok továbbítása, addig HTTP/3-nál ez 100 ms-ra gyorsult. Ugyanez nagyobb oldal esetében 1000 ms > 675 ms, míg egy egyoldalas weboldal esetében 600 ms > 300 ms.

Ebből az látszik, hogy a HTTP/3 azért jelentősen gyorsabb minden esetben, mint a HTTP/2, de különösen kisebb oldalaknál. Egyes vélemények szerint ugyanakkor a HTTP/3 nem igazán fog jelentős előnyt kínálni az egyébként is gyors kapcsolatot használó felhasználóknak. Akik számára érezhető lesz a gyorsulás, azok a leglassabb 1-10 százalék közé tartoznak.

Ez ugyanakkor a webes vitals mutatókat illetően hasznos lehet. Mármint olyan szempontból, hogy mivel a webes vitals mutatók globálisak, így előfordulhat, hogy egy távoli földrajzi helyen lévő felhasználói csoport miatt gyenge a szám. De persze a mobilos netezés korában akár a földrajzilag közel lévő és gyors eszközökkel rendelkező felhasználókat is elérhetnek hálózati problémák, amik nem jók a webes vitals mutatók szempontjából.

Hogyan alkalmazhatod a legegyszerűbben HTTP/3-at?

A HTTP/3-ra váltás egyik nagy problémája, hogy jelentősebb szerverfrissítést igényel, hiszen alapvetően változtatja meg a szállítási réteg működését. Ráadásul az UDP használata komolyabb CPU-igényeket is hoz, mely további nyomás alá helyezi a szervereket. CDN használatával azonban ez a probléma áthidalható.

A legegyszerűbb módja a HTTP/3 beállításának egy weboldalon CDN-en keresztül történik. Az olyan nagy szolgáltatók, mint például a Cloudflare, a Google Cloud vagy a Fastly már támogatják a protokollt. A W3Techs szerint a top 10 millió weboldal 22 százaléka például a Cloudflare-t használja, ahol már engedélyezhető a HTTP/3 az irányítópulton.

Persze, amennyiben a CDN-en keresztüli használat a Te weboldaladnál nem lehetséges, akkor valószínűleg szerverfejlesztésre lesz szükséged. Ezzel kapcsolatban nem árt tudni, hogy egyelőre nem minden szoftver támogatja egyelőre a HTTP/3-at. Például a szerverek kb. harmada használja az Apache-t, ami még nem támogatja, ahogy szintén gond lesz a Node.Js esetében is.

Hogyan állapítsd meg, hogy egy weboldal támogatja-e a HTTP/3-at?

Ha bizonytalan vagy abban, hogy egy weboldal támogatja-e a HTTP/3-at, akkor a legegyszerűbb a HTTP/3 Check nevű eszközzel megvizsgálni.

De a Firefox és a Chrome is megjelenít a protokollt minden kérés esetén a fejlesztői eszközöknél. A mező ugyan alapértelmezetten nem jelenik meg a “Hálózat” fül alatt, azonban a táblázatnál jobb gombbal kattintva kiválaszthatod a protokoll megjelenítését is külön oszlopban. A HTTP/3 lekéréseket a h3 fogja jelezni a táblázatban.

Címkék: , ,

A Webshark.hu a hozzászólásoknál előzetes moderálást alkalmaz. Moderálási szabályaink itt olvashatók.

Hozzászólás jelenleg nem lehetséges.

Széchenyi 2020