Organizace Internet Engineering Task Force (IETF), která je odpovědná za vývoj internetových protokolů a architektury, dokončila RFC pro protokol QUIC a zveřejnila související specifikace pod identifikátory RFC 8999 (vlastnosti protokolu nezávislé na verzi), RFC 9000 (přepravní přes UDP), RFC 9001 (TLS šifrování komunikačního kanálu QUIC) a RFC 9002 (kontrola zahlcení a detekce ztráty paketů při přenosu dat).
RFC získaly status „Proposed Standard“, poté se začnou pracovat na tom, aby RFC získal status návrhu normy (Draft Standard), což vlastně znamená kompletní stabilizaci protokolu a zohlednění všech vznesených připomínek. Protokol HTTP/3, který definuje použití protokolu QUIC jako přenos pro HTTP/2, je stále ve fázi návrhu specifikace, ale brzy bude konečně standardizován IETF.
Očekává se, že standardizace QUIC dá impuls k širšímu přijetí tohoto protokolu a také k vývoji rozšíření na něm založených, jako je WebTransport (technologie pro odesílání a přijímání dat mezi prohlížečem a serverem) a MASQUE (technologie připojení proxy, která rozšiřuje možnosti SOCKS a HTTP CONNECT a jako přenos používá HTTPS přes QUIC).
Připomeňme, že protokol QUIC (Quick UDP Internet Connections) vyvíjí Google od roku 2013 jako alternativu ke kombinaci TCP+TLS pro web, řeší problémy s dlouhými časy nastavování a vyjednávání připojení v TCP a odstraňuje zpoždění při během přenosu dat dochází ke ztrátě paketů. QUIC je rozšíření protokolu UDP, které podporuje multiplexování více připojení a poskytuje metody šifrování ekvivalentní TLS/SSL. Během vývoje standardu IETF byly provedeny změny protokolu, které vedly ke vzniku dvou paralelních větví, jedné pro HTTP/3 a druhé podporované Googlem (Chrome podporuje obě možnosti a Firefox podporuje verzi IETF) .
Klíčové vlastnosti QUIC:
- Vysoká bezpečnost podobná TLS (v podstatě QUIC poskytuje možnost používat TLS přes UDP);
- Řízení integrity toku, zabraňující ztrátě paketů;
- Schopnost okamžitě navázat spojení (0-RTT, v přibližně 75 % případů lze data přenést ihned po odeslání paketu nastavení spojení) a poskytnout minimální prodlevy mezi odesláním požadavku a přijetím odpovědi (RTT, Round Trip Time);
- Použití jiného sekvenčního čísla při opakovaném přenosu paketu, což zabrání nejednoznačnosti při identifikaci přijatých paketů a zbaví se časových limitů;
- Ztráta paketu ovlivní pouze doručení s ním spojeného proudu a nezastaví doručování dat v paralelních proudech přenášených prostřednictvím aktuálního připojení;
- Funkce opravy chyb, které minimalizují zpoždění kvůli opakovanému přenosu ztracených paketů. Použití speciálních kódů pro opravu chyb na úrovni paketů ke snížení situací vyžadujících opakovaný přenos ztracených paketových dat.
- Hranice kryptografických bloků jsou zarovnány s hranicemi paketů QUIC, což snižuje dopad ztrát paketů na dekódování obsahu následujících paketů;
- Žádné problémy s blokováním fronty TCP;
- Podpora pro identifikátor připojení, který zkracuje dobu potřebnou k vytvoření opětovného připojení pro mobilní klienty;
- Možnost připojení pokročilých mechanismů řízení přetížení připojení;
- Využívá techniky předpovědi propustnosti v jednotlivých směrech, aby zajistil, že pakety budou odesílány optimální rychlostí, čímž se zabrání jejich zahlcení a ztrátě paketů;
- Výrazné zvýšení výkonu a propustnosti ve srovnání s TCP. U video služeb, jako je YouTube, bylo prokázáno, že QUIC snižuje operace opětovného vyrovnávací paměti při sledování videí o 30 %.
Zdroj: opennet.ru