Protokol QUIC je dobil status predlaganega standarda.

IETF (Internet Engineering Task Force), ki razvija internetne protokole in arhitekturo, je dokončal RFC za protokol QUIC in objavil povezane specifikacije pod identifikatorji RFC 8999 (lastnosti protokola, neodvisne od različice), RFC 9000 (prenos prek UDP), RFC 9001 (TLS šifriranje komunikacijskega kanala QUIC) in RFC 9002 (nadzor zastojev in zaznavanje izgube paketov med prenosom podatkov).

RFC-ji so prejeli status "Predlagani standard", po katerem se bo začelo delo, da bi RFC dobil status osnutka standarda (Draft Standard), kar dejansko pomeni popolno stabilizacijo protokola in upoštevanje vseh podanih pripomb. Protokol HTTP/3, ki opredeljuje uporabo protokola QUIC kot transporta za HTTP/2, je še v fazi osnutka specifikacije, vendar ga bo IETF kmalu dokončno standardiziral.

Pričakovati je, da bo standardizacija QUIC-a spodbudila širšo uveljavitev tega protokola, pa tudi razvoj na njem temelječih razširitev, kot sta WebTransport (tehnologija za pošiljanje in prejemanje podatkov med brskalnikom in strežnikom) in MASQUE (tehnologija posredniškega povezovanja, ki razširja zmožnosti SOCKS in HTTP CONNECT ter uporablja HTTPS prek QUIC kot transport).

Spomnimo se, da Google od leta 2013 razvija protokol QUIC (Quick UDP Internet Connections) kot alternativo kombinaciji TCP+TLS za splet, ki rešuje težave z dolgimi nastavitvenimi in pogajalskimi časi povezav v TCP ter odpravlja zamude, ko se med prenosom podatkov izgubijo paketi. QUIC je razširitev protokola UDP, ki podpira multipleksiranje več povezav in zagotavlja metode šifriranja, enakovredne TLS/SSL. Med razvojem standarda IETF so bile narejene spremembe protokola, kar je vodilo do nastanka dveh vzporednih vej, ena za HTTP/3 in druga, ki jo podpira Google (Chrome podpira obe možnosti, Firefox pa različico IETF) .

Ključne lastnosti QUIC:

  • Visoka varnost, podobna TLS (v bistvu QUIC omogoča uporabo TLS prek UDP);
  • Nadzor celovitosti pretoka, preprečevanje izgube paketov;
  • Sposobnost takojšnje vzpostavitve povezave (0-RTT, v približno 75% primerov se lahko podatki prenesejo takoj po pošiljanju paketa za nastavitev povezave) in zagotavljanje minimalnih zamud med pošiljanjem zahteve in prejemom odgovora (RTT, Round Trip Time);
  • Uporaba druge zaporedne številke pri ponovnem pošiljanju paketa, s čimer se izognete dvoumnosti pri prepoznavanju prejetih paketov in odpravite časovne omejitve;
  • Izguba paketa vpliva samo na dostavo z njim povezanega toka in ne ustavi dostave podatkov v vzporednih tokovih, ki se prenašajo prek trenutne povezave;
  • Funkcije za popravljanje napak, ki zmanjšajo zamude zaradi ponovnega prenosa izgubljenih paketov. Uporaba posebnih kod za popravljanje napak na ravni paketa za zmanjšanje situacij, ki zahtevajo ponovno pošiljanje izgubljenih paketnih podatkov.
  • Meje kriptografskih blokov so poravnane z mejami paketov QUIC, kar zmanjša vpliv izgube paketov na dekodiranje vsebine naslednjih paketov;
  • Ni težav z blokiranjem čakalne vrste TCP;
  • Podpora za identifikator povezave, ki skrajša čas, potreben za vzpostavitev ponovne povezave za mobilne odjemalce;
  • Možnost priklopa naprednih mehanizmov za nadzor prezasedenosti povezav;
  • Uporablja tehnike napovedovanja prepustnosti po smeri, da zagotovi, da so paketi poslani z optimalnimi hitrostmi, kar preprečuje, da bi postali prezasedeni in povzročili izgubo paketov;
  • Znatno povečanje zmogljivosti in prepustnosti v primerjavi s TCP. Pri video storitvah, kot je YouTube, se je izkazalo, da QUIC zmanjša operacije vnovičnega medpomnjenja pri gledanju videoposnetkov za 30 %.

Vir: opennet.ru

Dodaj komentar