Radna skupina za internetsko inženjerstvo (IETF), koja je odgovorna za razvoj internetskih protokola i arhitekture, dovršila je RFC za QUIC protokol i objavila povezane specifikacije pod identifikatorima RFC 8999 (svojstva protokola neovisna o verziji), RFC 9000 (transport preko UDP-a), RFC 9001 (TLS enkripcija QUIC komunikacijskog kanala) i RFC 9002 (kontrola zagušenja i otkrivanje gubitka paketa tijekom prijenosa podataka).
RFC-ovi su dobili status “Proposed Standard” nakon čega će se krenuti s radom na tome da RFC dobije status nacrta standarda (Draft Standard), što zapravo znači potpunu stabilizaciju protokola i uvažavanje svih iznesenih komentara. HTTP/3 protokol, koji definira korištenje QUIC protokola kao prijenosa za HTTP/2, još uvijek je u fazi nacrta specifikacije, ali će ga IETF uskoro konačno standardizirati.
Očekuje se da će standardizacija QUIC-a dati poticaj širem usvajanju ovog protokola, kao i razvoju ekstenzija temeljenih na njemu, kao što su WebTransport (tehnologija za slanje i primanje podataka između preglednika i poslužitelja) i MASQUE (tehnologija proxyja veze koja proširuje mogućnosti SOCKS-a i HTTP CONNECT-a i korištenje HTTPS-a preko QUIC-a kao prijenosa).
Podsjetimo se da je protokol QUIC (Quick UDP Internet Connections) razvijao Google od 2013. godine kao alternativu kombinaciji TCP+TLS za web, rješavajući probleme s dugim vremenom postavljanja i pregovaranja veza u TCP-u i eliminirajući kašnjenja kada paketi se gube tijekom prijenosa podataka. QUIC je proširenje UDP protokola koji podržava multipleksiranje više veza i pruža metode šifriranja ekvivalentne TLS/SSL-u. Tijekom razvoja IETF standarda napravljene su promjene u protokolu, što je dovelo do pojave dvije paralelne grane, jedne za HTTP/3, a druge koju podržava Google (Chrome podržava obje opcije, a Firefox podržava IETF verziju) .
Ključne značajke QUIC-a:
- Visoka sigurnost slična TLS-u (u suštini QUIC pruža mogućnost korištenja TLS-a preko UDP-a);
- Kontrola integriteta protoka, sprječavanje gubitka paketa;
- Mogućnost trenutnog uspostavljanja veze (0-RTT, u otprilike 75% slučajeva podaci se mogu prenijeti odmah nakon slanja paketa za postavljanje veze) i pružanja minimalnih kašnjenja između slanja zahtjeva i primanja odgovora (RTT, Round Trip Time);
- Korištenje drugog sekvencijskog broja prilikom ponovnog slanja paketa, čime se izbjegava dvosmislenost u identifikaciji primljenih paketa i rješava se vremenskih ograničenja;
- Gubitak paketa utječe samo na isporuku toka koji je s njim povezan i ne zaustavlja isporuku podataka u paralelnim tokovima koji se prenose kroz trenutnu vezu;
- Značajke ispravljanja pogrešaka koje minimiziraju kašnjenja zbog ponovnog slanja izgubljenih paketa. Korištenje posebnih kodova za ispravljanje pogrešaka na razini paketa za smanjenje situacija koje zahtijevaju ponovni prijenos izgubljenih paketnih podataka.
- Granice kriptografskih blokova usklađene su s granicama QUIC paketa, što smanjuje utjecaj gubitaka paketa na dekodiranje sadržaja sljedećih paketa;
- Nema problema s blokiranjem TCP čekanja;
- Podrška za identifikator veze, što smanjuje vrijeme potrebno za uspostavljanje ponovne veze za mobilne klijente;
- Mogućnost povezivanja naprednih mehanizama kontrole zagušenja veze;
- Koristi tehnike predviđanja propusnosti po smjeru kako bi se osiguralo da se paketi šalju optimalnim brzinama, sprječavajući da postanu zagušeni i uzrokuju gubitak paketa;
- Značajno povećanje performansi i propusnosti u usporedbi s TCP-om. Za video usluge kao što je YouTube, pokazalo se da QUIC smanjuje operacije ponovnog međuspremnika prilikom gledanja videa za 30%.
Izvor: opennet.ru