A Firefox éjszakai verzióiban, valamint a béta változatban alapértelmezés szerint engedélyezve van a HTTP/3 protokoll támogatása. A stabil verzióban a HTTP/3 engedélyezésének tervezett időpontja a Firefox 88, amelyre április 20-án kerül sor. A Chrome-ban a HTTP/3 szelektív aktiválása 2020 októberében kezdődött.
A Firefox HTTP/3 támogatása a Mozilla által fejlesztett neqo projektre épül, amely egy kliens implementációt biztosít a a szerver QUIC protokollhoz. A HTTP/3 és QUIC támogatására szolgáló komponensek kódja Rust nyelven íródott. A HTTP/3 engedélyezésének kezelésére az about:config alatt található az "network.http.http3.enabled" beállítás. A kliens szoftverrel együtt már kísérleti támogatást kapott a HTTP/3 a Chrome-ban és a curl-ben, valamint szerverek elérhető az nginx-ben, valamint az nginx modul és a Cloudflare tesztszerver formájában. A HTTP/3 kliens működésének ellenőrzésére több tesztoldal is elindult.
A HTTP/3 protokoll még mindig tervezet formájában van, és véglegesen nem lett szabványosítva az IETF által. A HTTP/3 a QUIC protokoll használatát határozza meg szállítóként az HTTP/2-höz. A QUIC (Quick UDP Internet Connections) protokollt a Google 2013 óta fejleszti, mint alternatívát a TCP+TLS kombinációra a Web számára, megoldva a TCP kapcsolatok hosszú telepítési és egyeztetési idejét, valamint kiküszöbölve a csomagvesztés miatti késleltetéseket. A QUIC egy UDP-re épülő protokoll, amely támogatja a több kapcsolaton történő multiplexelést, és TLS/SSL-nak megfelelő titkosítási módszereket biztosít. Az IETF standardjának fejlesztése során a protokollban változások történtek, ami két párhuzamosan létező ága keletkezett, az egyik a HTTP/3 számára, a másik a Google által támogatott (a Chrome mindkét verziót támogatja).
A QUIC főbb jellemzői:
- Magas biztonság, amely hasonló a TLS-hez (lényegében a QUIC lehetővé teszi a TLS használatát az UDP-n üstökölve);
- A folyam integritásának ellenőrzése, amely megakadályozza a csomagok elvesztését;
- A kapcsolat azonnali létrehozásának lehetősége (0-RTT, körülbelül 75%-os esetekben az adatokat közvetlenül a kapcsolati csomag elküldése után lehet átkonvertálni) és minimalizálva a késleltetést a kérés küldése és a válasz megérkezése között (RTT, Round Trip Time);
- A csomagok új seq. számmal való újraküldésének lehetősége, amely lehetővé teszi a megkapott csomagok pontos azonosítását és megszünteti az időtúllépéseket;
- Csomag elvesztése csak az ahhoz kapcsolódó folyamat szállítását befolyásolja, és nem állítja le az adatokat a párhuzamosan átkonvertált folyamatok szállításában;
- Hibaellenőrző eszközök, amelyek minimalizálják a késéseket az elveszett csomagok újraküldése miatt. Speciális hibaellenőrző kódok használata csomagszinten a vesztes csomagok újraküldésének szükségességének csökkentésére.
- A kriptográfiai blokkok határai a QUIC csomagok határaival össze vannak hangolva, ezáltal csökkenti a csomagvesztések hatását a következő csomagok tartalmának dekódolására;
- Nincsenek problémák a TCP sorok blokkolásával;
- Támogatja a kapcsolati azonosítót, amely lehetővé teszi a mobil kliensek számára a visszakapcsolódási idő csökkentését;
- A kapcsolati túlterhelés-ellenőrzési mechanizmusok kiterjesztett lehetőségeinek csatlakoztatása;
- Sávszélesség-előrejelzési technikák használata mindkét irányban a csomagok optimális küldési intenzitásának biztosítása érdekében, elkerülve a túlterheltségi állapotba való kerülést, amely csomagvesztést eredményez;
- Figyelemre méltó teljesítménynövekedés és szélessávú kapacitás a TCP-hez képest. Videószolgáltatások esetén, mint a YouTube, a QUIC alkalmazása 30%-os csökkenést mutatott a videómegjelenítés közbeni újratárazás műveleteiben.
Forrás: opennet.ru
