IETF (Internet Engineering Task Force), mis tegeleb interneti protokollide ja arhitektuuri arendamisega, on lõpule viinud QUIC protokolli jaoks RFC-de koostamise ja avaldanud seotud spetsifikatsioonid identifikaatoritega RFC 8999 (protokolli versioonist sõltumatud omadused), RFC 9000 (transport UDP peal), RFC 9001 (QUIC ühenduse TLS-krüpteerimine) ja RFC 9002 (ülekande ajal ülekoormuse haldamine ja pakettide kaotuse määramine).
RFC-id said "Ettepaneku standardi" staatuse, pärast mida algab töö RFC-de mustandi standardi (Draft Standard) staatuse saavutamiseks, mis tegelikult tähendab protokolli täielikku stabiliseerimist ja kõigi väljendatud märkuste arvesse võtmist. Protokoll HTTP/3, mis määratleb QUIC protokolli kasutamise HTTP/2 transpordina, on praegu mustandi spetsifikatsiooni staadiumis, kuid peagi standardiseeritakse ka see IETF-is.
Oodatakse, et QUIC-i standardiseerimine kiirendab selle protokolli laiemat rakendamist ja arendamist, mille aluseks on laiendused nagu WebTransport (tehnoloogia andmete saatmiseks ja vastuvõtmiseks brauseri ja serverilt) ja MASQUE (ühenduste proksitehnoloogia, mis laiendab SOCKS-i ja HTTP CONNECT-i võimalusi ning kasutab HTTPS-i QUIC-i transpordina).
Tuletame meelde, et QUIC (Quick UDP Internet Connections) protokolli arendab alates 2013. aastast Google TCP+TLS alternatiivina veebis, lahendades TCP-s looma ja kokku leppima mineku ajaga seotud probleemid ning kõrvaldades viivitused andmete edastamisel paketikaotuse korral. QUIC on UDP protokolli peal struktuur, mis toetab mitme ühenduse mitmekordset ja tagab TLS/SSL-iga võrreldavad krüpteerimise meetodid. IETF-i standardi arendamise käigus tehti protokolli muudatusi, mis viis kahe paralleelselt eksisteeriva haru tekkeni, üks HTTP/3 jaoks, ja teine, mida toetab Google (Chrome toetab mõlemat varianti, Firefox toetab IETF-i varianti).
QUICi põhijooned:
- Kõrge turvalisus, võrreldav TLS'iga (QUIC pakub tegelikult võimalust kasutada TLS'i UDP peal);
- Voolu terviklikkuse jälgimine, mis takistab pakettide kaotust;
- Võimalus luua ühendus koheselt (0-RTT, umbes 75% juhtudel saab andmeid edastada kohe pärast ühenduse loomise paketi saatmist) ja tagada minimaalne viivitus päringu saatmise ja vastuse saamise vahel (RTT, Round Trip Time);
- Paketi uuesti edastamisel kasutatakse teistsugust järjestuse numbrit, mis võimaldab vältida mitmeti mõistetavust saadud pakettide määratlemisel ja kõrvaldada aegumise probleemid;
- Paketi kaotus mõjutab ainult selle kaasnevat voolu ja ei peata andmete edastamist samaaegselt praeguse ühenduse kaudu edastatavatest voogudest;
- Vigade parandusmeetmed, mis minimeerivad viivitusi kadunud pakettide uuesti edastamise tõttu. Eriliste vigade parandamise koodide kasutamine paketi tasemel, et vähendada olukordi, mis nõuavad kadunud paketi andmete uuesti edastamist.
- Krüptograafiliste plokkide piirid on joondatud QUIC pakettide piiridega, mis vähendab pakettide kaotuse mõju järgmiste pakettide sisu dekodeerimisele;
- TCP järjekorra ummistumise probleemide puudumine;
- Ühenduse identifikaatori tugi, mis võimaldab vähendada mobiilsete klientide uuesti ühendamise aega;
- Võime ühendada laienevaid ühenduse ülekande kontrolli mehhanisme;
- Igas suunas läbilaskevõime ennustamise tehnika kasutamine, et tagada pakkide edastamise optimaalne intensiivsus, vältides üleminekuid koormuse seisundisse, kus esineb pakettide kaotust;
- Tähtis jõudluse ja ribalaiuse kasv võrreldes TCP-ga. Video teenustes, nagu YouTube, on QUIC-i kasutamine vähendanud videote vaatamisel vahemälu operatsioone 30%.
Allikas: opennet.ru
