Die Internet Engineering Task Force (IETF), wat verantwoordelik is vir die ontwikkeling van internetprotokolle en argitektuur, het die RFC vir die QUIC-protokol gefinaliseer en verwante spesifikasies gepubliseer onder die identifiseerders RFC 8999 (weergawe-onafhanklike protokol eienskappe), RFC 9000 (vervoer) oor UDP), RFC 9001 (TLS-enkripsie van die QUIC-kommunikasiekanaal) en RFC 9002 (opeenhopingsbeheer en opsporing van pakkieverlies tydens data-oordrag).
Die RFC's het die status van 'n "Voorgestelde Standaard" ontvang, waarna werk sal begin om die RFC die status van 'n konsepstandaard (Draft Standard) te gee, wat eintlik 'n volledige stabilisering van die protokol beteken en met inagneming van al die kommentaar wat gemaak is. Die HTTP/3-protokol, wat die gebruik van die QUIC-protokol as 'n vervoer vir HTTP/2 definieer, is nog in die konsepspesifikasiestadium, maar dit sal binnekort finaal deur die IETF gestandaardiseer word.
Daar word verwag dat die standaardisering van QUIC stukrag sal gee aan groter aanvaarding van hierdie protokol, sowel as die ontwikkeling van uitbreidings wat daarop gebaseer is, soos WebTransport ('n tegnologie vir die stuur en ontvang van data tussen 'n blaaier en 'n bediener) en MASQUE ('n verbinding proxy-tegnologie wat die vermoëns van SOCKS en HTTP CONNECT uitbrei en HTTPS oor QUIC as vervoer gebruik).
Laat ons onthou dat die QUIC (Quick UDP Internet Connections) protokol sedert 2013 deur Google ontwikkel is as 'n alternatief vir die TCP+TLS-kombinasie vir die web, wat probleme oplos met die lang opstel- en onderhandelingstye van verbindings in TCP en om vertragings uit te skakel wanneer pakkies gaan verlore tydens data-oordrag. QUIC is 'n uitbreiding van die UDP-protokol wat multipleksing van veelvuldige verbindings ondersteun en enkripsiemetodes bied gelykstaande aan TLS/SSL. Tydens die ontwikkeling van die IETF-standaard is veranderinge aan die protokol aangebring, wat gelei het tot die ontstaan van twee parallelle takke, een vir HTTP/3, en die tweede wat deur Google ondersteun word (Chrome ondersteun beide opsies, en Firefox ondersteun die IETF-weergawe) .
Sleutel kenmerke van QUIC:
- Hoë sekuriteit, soortgelyk aan TLS (in werklikheid bied QUIC die vermoë om TLS oor UDP te gebruik);
- Stroomintegriteitsbeheer om pakkieverlies te voorkom;
- Die vermoë om onmiddellik 'n verbinding te bewerkstellig (0-RTT, in ongeveer 75% van die gevalle kan data onmiddellik versend word nadat die konneksie-opstellingpakket gestuur is) en minimale vertragings verskaf tussen die stuur van 'n versoek en die ontvangs van 'n antwoord (RTT, Round Trip Time);
- Die gebruik van 'n ander volgordenommer wanneer 'n pakkie herversend word, wat onduidelikheid in die identifisering van ontvangde pakkies vermy en ontslae raak van time-outs;
- Pakkieverlies beïnvloed slegs die aflewering van die stroom wat daarmee geassosieer word en stop nie die aflewering van data in strome wat parallel oor die huidige verbinding versend word nie;
- Foutregstellingnutsgoed wat vertragings as gevolg van herversending van verlore pakkies verminder. Gebruik van spesiale foutkorreksiekodes op die pakkievlak om situasies te verminder wat heruitsending van verlore pakkiedata vereis.
- Die grense van die kriptografiese blokke is in lyn met die grense van die QUIC-pakkies, wat die impak van pakkieverlies op die dekodering van die inhoud van die volgende pakkies verminder;
- Geen probleme met die blokkering van die TCP-tou nie;
- Verbindings-ID-ondersteuning om heraansluitingstyd vir mobiele kliënte te verminder;
- Moontlikheid om gevorderde meganismes vir verbinding oorlading beheer te koppel;
- Die gebruik van bandwydte-voorspellingstegnieke in elke rigting om die optimale intensiteit van die stuur van pakkies te verseker, wat voorkom dat dit in 'n toestand van opeenhoping inrol, waarin daar 'n verlies aan pakkies is;
- Aansienlike toename in werkverrigting en deurset in vergelyking met TCP. Vir videodienste soos YouTube, is daar getoon dat QUIC die terugstootbewerkings met 30% verminder wanneer na video's gekyk word.
Bron: opennet.ru