Az Internet Engineering Task Force (IETF), amely az internetes protokollok és architektúrák fejlesztéséért felelős, véglegesítette a QUIC protokoll RFC-jét, és közzétette a kapcsolódó specifikációkat RFC 8999 (verziófüggetlen protokolltulajdonságok), RFC 9000 (szállítás) azonosítókkal. UDP-n keresztül), RFC 9001 (a QUIC kommunikációs csatorna TLS-titkosítása) és RFC 9002 (torlódásvezérlés és csomagvesztés-észlelés az adatátvitel során).
Az RFC-k megkapták a „Javasolt szabvány” státuszt, ezt követően megkezdődik a munka annak érdekében, hogy az RFC szabványtervezet státuszba kerüljön (Draft Standard), ami tulajdonképpen a protokoll teljes stabilizálását jelenti, és figyelembe véve az összes megjegyzést. A HTTP/3 protokoll, amely a QUIC protokoll használatát a HTTP/2 átviteleként határozza meg, még a specifikáció tervezetének szakaszában van, de hamarosan végre szabványosítja az IETF.
A QUIC szabványosítása várhatóan lendületet ad majd ennek a protokollnak a szélesebb körű elterjedéséhez, valamint az arra épülő bővítmények kifejlesztéséhez, mint például a WebTransport (a böngésző és a szerver közötti adatküldési és -fogadási technológia) és a MASQUE. (egy kapcsolat-proxy technológia, amely kiterjeszti a SOCKS és a HTTP CONNECT képességeit, és a HTTPS-t QUIC-on keresztül használja szállításként).
Emlékezzünk vissza, hogy a QUIC (Quick UDP Internet Connections) protokollt a Google 2013 óta fejlesztette ki a TCP+TLS webes kombináció alternatívájaként, amely megoldja a TCP-kapcsolatok hosszú beállítási és egyeztetési idejével kapcsolatos problémákat, és kiküszöböli a késéseket csomagok elvesznek az adatátvitel során. A QUIC az UDP protokoll kiterjesztése, amely támogatja több kapcsolat multiplexelését, és a TLS/SSL-lel egyenértékű titkosítási módszereket biztosít. Az IETF szabvány fejlesztése során a protokollban változások történtek, ami két párhuzamos ág kialakulásához vezetett, az egyik a HTTP/3-hoz, a másik pedig a Google által támogatott (a Chrome mindkét opciót támogatja, a Firefox pedig az IETF verziót) .
A QUIC főbb jellemzői:
- Magas biztonság, hasonlóan a TLS-hez (valójában a QUIC lehetővé teszi a TLS használatát UDP-n keresztül);
- Az adatfolyam integritásának ellenőrzése a csomagvesztés megelőzése érdekében;
- Azonnali kapcsolat létrehozásának képessége (0-RTT, az esetek körülbelül 75%-ában az adatok a kapcsolatbeállító csomag elküldése után azonnal továbbíthatók), és minimális késleltetést biztosít a kérés elküldése és a válasz fogadása között (RTT, Round Trip Time) ;
- Eltérő sorszám használata egy csomag újraküldésekor, ami elkerüli a kétértelműséget a fogadott csomagok azonosítása során, és megszabadul az időtúllépésektől;
- A csomagvesztés csak a hozzá tartozó adatfolyam kézbesítését érinti, és nem akadályozza meg az adatok kézbesítését az aktuális kapcsolaton keresztül párhuzamosan továbbított folyamokban;
- Hibajavító eszközök, amelyek minimalizálják az elveszett csomagok újraküldése miatti késéseket. Speciális hibajavító kódok használata csomagszinten az elveszett csomagadatok újraküldését igénylő helyzetek csökkentése érdekében.
- A kriptográfiai blokkhatárok igazodnak a QUIC csomaghatárokhoz, ami csökkenti a csomagvesztések hatását a következő csomagok tartalmának dekódolására;
- Nincs probléma a TCP-sor blokkolásával;
- Connection ID támogatás a mobil kliensek újracsatlakozási idejének csökkentése érdekében;
- Speciális mechanizmusok csatlakoztatásának lehetősége a csatlakozás túlterhelés-szabályozására;
- Sávszélesség-előrejelzési technikák alkalmazása minden irányban a csomagok küldésének optimális intenzitásának biztosítására, megakadályozva a torlódásos állapotba gurulást, amelyben a csomagok elvesznek;
- Jelentős teljesítménynövekedés és átviteli sebesség a TCP-hez képest. Az olyan videoszolgáltatások esetében, mint a YouTube, a QUIC 30%-kal csökkenti az újrapufferelési műveleteket videók megtekintése közben.
Forrás: opennet.ru