Komitet IETF (Internet Engineering Task Force), ktorý sa zaoberá rozvojom protokolov a architektúry internetu, dokončil formovanie RFC pre protokol QUIC a publikoval s ním súvisiace špecifikácie s identifikátormi RFC 8999 (nezávislé od verzie vlastnosti protokolu), RFC 9000 (prenos cez UDP), RFC 9001 (TLS šifrovanie komunikačného kanála QUIC) a RFC 9002 (riadenie preťaženia a určenie straty paketov pri prenose dát).
RFC získali status „Navrhnutého štandardu“, po ktorom sa začne práca na pridelení RFC statusu návrhového štandardu (Draft Standard), čo v podstate znamená úplnú stabilizáciu protokolu a zohľadnenie všetkých vyjadrených pripomienok. Protokol HTTP/3, ktorý určuje použitie protokolu QUIC ako prenosu pre HTTP/2, sa momentálne nachádza na úrovni návrhovej špecifikácie, ale aj jeho konečná standardizácia v IETF sa očakáva v blízkej budúcnosti.
Očakáva sa, že standardizácia QUIC prispeje k širšiemu zavádzaniu tohto protokolu, ako aj k rozvoju na ňom založených rozšírení, ako sú WebTransport (technológia na odosielanie a prijímanie dát medzi prehliadačom a serverom) a MASQUE (technológia proxy pripojení, ktorá rozširuje možnosti SOCKS a HTTP CONNECT a využíva HTTPS cez QUIC ako prenos).
Pripomeňme, že protokol QUIC (Quick UDP Internet Connections) sa od roku 2013 vyvíja spoločnosťou Google ako alternatíva ku kombinácii TCP+TLS pre Web, ktorá sa zaoberá problémami s dlhým časom vytvárania a dohadovania spojení v TCP a eliminuje oneskorenia pri strate paketov počas prenosu dát. QUIC predstavuje nadstavbu nad protokolom UDP, podporujúcu multiplexovanie viacerých pripojení a zabezpečujúcu metódy šifrovania, ekvivalentné TLS/SSL. V procese vývoja štandardu IETF boli do protokolu vykonané zmeny, čo viedlo k vzniku dvoch paralelne existujúcich vetiev, jedna pre HTTP/3 a druhá podporovaná Googlom (Chrome podporuje obe varianty, zatiaľ čo Firefox podporuje variant IETF).
Hlavné vlastnosti QUIC:
- Vysoká bezpečnosť, podobná TLS (v skutočnosti QUIC poskytuje možnosť použitia TLS nad UDP);
- Kontrola integrity toku, zabraňujúca strate paketov;
- Možnosť okamžite ustanoviť spojenie (0-RTT, približne v 75% prípadoch je možné prenášať dáta hneď po odoslaní paketu na ustanovenie spojenia) a zabezpečiť minimálne oneskorenia medzi odoslaním požiadavky a prijatím odpovede (RTT, Round Trip Time);
- Použitie pri opätovnom prenose пакета s iným poradovým číslom umožňuje vyhnúť sa nejednoznačnosti pri určovaní prijatých balíkov a zbaviť sa timeoutov;
- Strata пакeta ovplyvňuje doručovanie iba súvisiacich prúdov a nezastavuje doručovanie údajov v súbežne prenášaných prúdoch cez aktuálne spojenie;
- Prostriedky na opravu chýb minimalizujúce oneskorenia spôsobené opätovným prenosom stratených balíkov. Použitie špeciálnych kódov na opravu chýb na úrovni пакета na zníženie situácií, ktoré si vyžadujú opätovný prenos údajov strateného пакeta.
- Hranice kryptografických blokov sú vyrovnané s hranicami пакetov QUIC, čo zmenšuje vplyv strát paketov na dekódovanie obsahu nasledujúcich paketov;
- Neexistujú žiadne problémy s blokovaním frontu TCP;
- Podpora identifikátora spojenia, ktorý umožňuje skrátiť čas potrebný na obnovenie spojenia pre mobilných klientov;
- Možnosť pripojenia rozšírených mechanizmov riadenia preťaženia spojenia;
- Použitie techniky predpovedania priepustnosti v každom smere na zabezpečenie optimálnej intenzity odosielania paketov, čím sa zabraňuje prechodu do stavu preťaženia, pri ktorom dochádza k strate paketov;
- Výrazný nárast výkonu a priepustnosti v porovnaní s TCP. Pre video služby, ako je YouTube, použitie QUIC preukázalo 30% zníženie opätovného vyrovnávania pri prehrávaní videa.
Zdroj: opennet.ru
