Komiteti IETF (Internet Engineering Task Force), i cili merret me zhvillimin e protokollëve dhe arkitekturës së internetit, përfundoi përgatitjen e RFC për protokollin QUIC dhe publikoi specifikimet e lidhura me të me identifikuesit RFC 8999 (tipare të protokollit të pavarura nga versioni), RFC 9000 (transport mbi UDP), RFC 9001 (kriptimi TLS i kanalit të komunikimit QUIC) dhe RFC 9002 (menaxhimi i ngarkesës dhe përcaktimi i humbjes së paketave gjatë transmetimit të të dhënave).
RFC mori statusin "Standart i Propozimit", pas së cilës do të fillojë puna për t'i dhënë RFC statusin e standartit bërë (Draft Standard), që në fakt do të thotë stabilizimin e plotë të protokollit dhe marrjen e parasysh të gjithë komenteve të shprehura. Protokolli HTTP/3, i cili përcakton përdorimin e protokollit QUIC si transport për HTTP/2, aktualisht është në fazën e specifikimit të bërë, por së shpejti do të standardizohet gjithashtu në IETF.
Pritet që standardizimi i QUIC të japë një shtysë për adoptimin më të gjerë të këtij protokolli, si dhe për zhvillimin e zgjerimeve të bazuara mbi të, si WebTransport (teknologji për dërgimin dhe marrjen e të dhënave midis shfletuesit dhe server) dhe MASQUE (teknologji për proxy të lidhjeve, që zgjeron mundësitë e SOCKS dhe HTTP CONNECT, duke përdorur HTTPS mbi QUIC si transport).
Kujtojmë, protokolli QUIC (Quick UDP Internet Connections) është zhvilluar që nga viti 2013 nga kompania Google si një alternativë për lidhjen TCP+TLS për Web, që zgjidh problemet me kohën e gjatë të krijimit dhe rregullimit të lidhjeve në TCP dhe eleminon vonesat gjatë humbjes së paketave në procesin e transmetimit të të dhënave. QUIC është një shtresë mbi protokollin UDP, që mbështet shumë lidhje dhe ofron metoda kriptimi, ekuivalente me TLS/SSL. Gjatë zhvillimit të standartit në IETF, janë bërë ndryshime në protokoll, duke çuar në ekzistencën e dy degëve paralele, një për HTTP/3, dhe tjetra e mbështetur nga Google (Chrome mbështet të dy 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 mbi integritetin e rrjedhës, që parandalon humbjen e pacakove;
- 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 minimale midis dërgimit të kërkesës dhe marrjes së përgjigjes (RTT, Round Trip Time);
- Përdorimi i një numri tjetër sekonda për dërgimin e paketave përsëritëse, gjë që lejon shmangien e dyshimeve në përcaktimin e paketave të pranuara dhe eliminon vonesat;
- Humorja e paketës ndikon vetëm në dërgesën e fluksit lidhur me të dhe nuk ndalon dërgimin e të dhënave në flukset që dërgohen paralelisht nëpërmjet lidhjes aktuale;
- Mjetet për korrigjimin e gabimeve, që minimizojnë vonesat për shkak të dërgimit përsëritës të paketave të humbura. Përdorimi i kodeve speciale për korrigjimin e gabimeve në nivelin e paketës për të reduktuar situatat që kërkojnë dërgim përsëritës të të dhënave të paketës së humbur.
- Kufijtë e bllokave kriptografikë janë përputhur me kufijtë e paketave QUIC, duke zvogëluar ndikimin e humbjeve të paketave në dekodimin e përmbajtjes së paketave të ardhshme;
- Mungesa e problemeve me bllokimin e radhës TCP;
- Mbështetje për identifikuesin e lidhjes, që lejon zvogëlimin e kohës për vendosjen e lidhjes përsëritëse për klientët mobilë;
- Mundësia e lidhjes së mekanizmave të zgjeruar të kontrollit të ngarkesës së lidhjes;
- Përdorimi i teknikave të parashikimit të kapacitetit në çdo drejtim për të siguruar intensitetin optimal të dërgimit të paketave, duke parandaluar rënien në një gjendje ngarkese, ku humbjet e paketave vërehen;
- Rritje e dukshme e performancës dhe kapacitetit krahasuar me TCP. Për shërbimet video si YouTube, aplikimi i QUIC ka treguar një reduktim prej 30% të operacioneve të ri-buffering gjatë shikimit të videove.
Burimi: opennet.ru
