Komiteti IETF (Internet Engineering Task Force), i cili merret me zhvillimin e protokolleve dhe arkitekturës së internetit, ka përfunduar formimin e RFC për protokollin QUIC dhe ka publikuar specifikimet përkatëse me identifikuesit RFC 8999 (vlera të pavarura nga versioni të protokollit), RFC 9000 (transport mbi UDP), RFC 9001 (kriptimi TLS i lidhjes QUIC) dhe RFC 9002 (menaxhimi i mbingarkesës dhe identifikimi i humbjes së paketave gjatë transferimit të të dhënave).
RFC e morën statusin "Standardi i Propozuar", pas së cilës do të fillojë puna për t'i dhënë RFC statusin Draft Standard, i cili faktikisht do të thotë stabilizimin e plotë të protokollit dhe marrjen parasysh të të gjitha vërejtjeve të shprehura. Protokolli HTTP/3, i cili përcakton përdorimin e protokollit QUIC si transport për HTTP/2, aktualisht ndodhet në fazën e specifikimit draft, por shpejt do të standardizohet gjithashtu në IETF.
Pritet që standardizimi i QUIC të sjellë një nxitje për adoptyimin më të gjerë të këtij protokolli, si dhe për zhvillimin e zgjerimeve të bazuara në të, të tilla si WebTransport (teknologji për dërgimin dhe marrjen e të dhënave midis shfletuesit dhe serverin) dhe MASQUE (teknologji e prokurimit të lidhjeve, e cila zgjeron mundësitë e SOCKS dhe HTTP CONNECT, dhe përdor HTTPS mbi QUIC si transport).
Kujtojmë se protokolli QUIC (Quick UDP Internet Connections) është zhvilluar nga kompania Google që nga viti 2013 si një alternativë ndaj TCP+TLS për Web, duke zgjidhur problemet me kohën e gjate të vendosjes dhe pajtimit të lidhjeve në TCP dhe duke eliminuar vonesat gjatë humbjes së paketimeve në procesin e transfertës së të dhënave. QUIC është një shtresë mbi protokollin UDP, që mbështet shumë lidhje dhe siguron metoda kriptuese, ekuivalente me TLS/SSL. Gjatë zhvillimit të standardit në IETF, janë bërë ndryshime në protokoll, të cilat kanë rezultuar në ekzistencën e dy degëve paralele, një për HTTP/3 dhe tjetra e mbështetur nga Google (Chrome mbështet të dyja variantet, ndërsa Firefox mbështet variantin IETF).
Karakteristikat kryesore të QUIC:
- Siguri e lartë, e ngjashme me TLS (në thelb, QUIC ofron mundësinë e përdorimit të TLS mbi UDP);
- Kontrolli i integritetit të rrjedhës, duke parandaluar humbjen e paketave;
- Mundësia për të vendosur menjëherë një lidhje (0-RTT, në rreth 75% të rasteve të dhënat mund të transmetohen menjëherë pas dërgimit të paketës së vendosjes së lidhjes) dhe për të siguruar vonesa minime midis dërgimit të kërkesës dhe marrjes së përgjigjes (RTT, Koha e Rrethit);
- Përdorimi i një numri tjetër renditje për ripërsëritjen e paketës, çka lejon evitimin e paqartësisë në përcaktimin e paketimeve të pranuara dhe heqjen e vonesave;
- humbja e paketave ndikon vetëm në dërgesën e lidhur me grupe të caktuara dhe nuk ndalon dërgimin e të dhënave në grupe paralelisht të transferuara përmes këtij lidhjeje;
- Mjetet për korrektionin e gabimeve, të cilat minimizojnë vonesat për shkak të ripërsëritjes së paketimeve të humbura. Përdorimi i kodeve speciale të korrekcioni të gabimeve në nivelin e paketës për të reduktuar situatat që kërkojnë ripërsëritjen e të dhënave të paketave të humbura.
- Kufijtë e blloqeve kriptografike janë rreshtuar me kufijtë e pakove QUIC, duke zvogëluar ndarjen e humbjeve të pakove në dekodimin e përmbajtjes së pakove të ardhshme;
- Mungesa e problemeve me bllokimin e radhës TCP;
- Mbështetje për identifikimin e lidhjes, që lejon të shkurtohet koha e vendosjes së lidhjes së re për klientët e lëvizshëm;
- Aftësia për të lidhur mekanizma të avancuar të kontrollit të mbingarkesës së lidhjes;
- Përdorimi i teknikave të parashikimit të kapacitetit në çdo drejtim për të garantuar intensitetin optimal të dërgimit të paketeve, duke parandaluar rënien në një gjendje mbipopullimi, ku vërehet humbja e paketeve;
- Rritje e dukshme e performancës dhe kapacitetit në krahasim me TCP. Për shërbimet video, si YouTube, përdorimi i QUIC ka treguar një reduktim të 30% në operacionet e rifillimit gjatë shikimit të videos.
Burimi: opennet.ru
