Výbor IETF (Internet Engineering Task Force), který se zabývá rozvojem protokolů a architektury internetu, dokončil formování RFC pro protokol QUIC a zveřejnil s ním související specifikace pod identifikátory RFC 8999 (na verzi nezávislé vlastnosti protokolu), RFC 9000 (transport nad UDP), RFC 9001 (TLS šifrování komunikačního kanálu QUIC) a RFC 9002 (řízení přetížení a určení ztráty paketů během přenosu dat).
RFC získaly status „Navrhovaného standardu“, po čemž začne práce na přidělení RFC statusu návrhového standardu (Draft Standard), což fakticky znamená úplnou stabilizaci protokolu a zohlednění všech vznesených připomínek. Protokol HTTP/3, který určuje použití protokolu QUIC jako transportu pro HTTP/2, je zatím ve stádiu návrhové specifikace, ale brzy bude také konečně standardizován v IETF.
Očekává se, že standardizace QUIC podpoří širší zavedení tohoto protokolu, stejně jako rozvoj na něm založených rozšíření, jako je WebTransport (technologie pro odesílání a přijímání dat mezi prohlížečem a serverem) a MASQUE (technologie pro proxy připojení, která rozšiřuje možnosti SOCKS a HTTP CONNECT a používá HTTPS nad QUIC jako transport).
Připomeňme, že protokol QUIC (Quick UDP Internet Connections) se od roku 2013 vyvíjí firmou Google jako alternativa kombinace TCP+TLS pro Web, která řeší problémy s dlouhou dobou navazování a jednání spojení v TCP a eliminuje zpoždění při ztrátě paketů během přenosu dat. QUIC představuje nadstavbu nad protokolem UDP, podporující multiplexování několika připojení a poskytující metody šifrování, ekvivalentní TLS/SSL. Během vývoje standardu v IETF byly do protokolu provedeny změny, což vedlo k vzniku dvou paralelně existujících větví, jedna pro HTTP/3 a druhá, kterou podporuje Google (Chrome podporuje obě varianty, zatímco Firefox podporuje variantu IETF).
Hlavní vlastnosti QUIC:
- Vysoká bezpečnost, srovnatelná s TLS (v podstatě QUIC poskytuje možnost použití TLS nad UDP);
- Kontrola integrity toku, která zabraňuje ztrátě paketů;
- Možnost okamžitého navázání připojení (0-RTT, v přibližně 75 % případů lze data odesílat ihned po odeslání balíčku pro navázání připojení) a zajištění minimálních zpoždění mezi odesláním žádosti a příjmem odpovědi (RTT, Round Trip Time);
- Použití při opětovném přenosu paketu jiného pořadového čísla, což umožňuje vyhnout se nejasnostem při určení přijatých paketů a zbavit se časových limitů;
- Ztráta paketu ovlivňuje doručení pouze souvisejícího toku a nezastavuje doručení dat v paralelně přenášených tocích přes aktuální spojení;
- Nástroje pro opravu chyb, které minimalizují zpoždění způsobené opětovným přenosem ztracených paketů. Využití speciálních chybových kódů na úrovni paketů pro snížení situací, které vyžadují opětovný přenos dat ztraceného paketu.
- Hranice kryptografických bloků jsou sladěny s hranicemi paketů QUIC, což snižuje dopad ztráty paketů na dekódování obsahu následujících paketů;
- Žádné problémy s blokováním front TCP;
- Podpora identifikátoru spojení, která snižuje čas potřebný k opětovnému navázání spojení pro mobilní klienty;
- Možnost připojení rozšířených mechanismů řízení přetížení spojení;
- Použití techniky predikce šířky pásma v každém směru pro zajištění optimální intenzity odesílání paketů, což zabraňuje přechodu do stavu přetížení, ve kterém dochází ke ztrátě paketů;
- Výrazný nárůst výkonu a propustnosti ve srovnání s TCP. Pro video služby, jako je YouTube, použití QUIC ukázalo snížení operací opětovného buffrování při sledování videa o 30%.
Zdroj: opennet.ru
