Task Forca e Inxhinierisë së Internetit (IETF), e cila është përgjegjëse për zhvillimin e protokolleve dhe arkitekturës së internetit, ka finalizuar RFC-në për protokollin QUIC dhe ka publikuar specifikimet përkatëse nën identifikuesit RFC 8999 (vetitë e protokollit të pavarura nga versioni), RFC 9000 (transport mbi UDP), RFC 9001 (kriptimi TLS i kanalit të komunikimit QUIC) dhe RFC 9002 (kontrolli i mbingarkesës dhe zbulimi i humbjes së paketave gjatë transmetimit të të dhënave).
RFC-të morën statusin e një "Standardi i propozuar", pas së cilës do të fillojë puna për t'i dhënë RFC statusin e një draft standardi (Draft Standard), që në fakt nënkupton një stabilizim të plotë të protokollit dhe duke marrë parasysh të gjitha komentet e bëra. Protokolli HTTP/3, i cili përcakton përdorimin e protokollit QUIC si një transport për HTTP/2, është ende në fazën e specifikimit të draftit, por së shpejti do të standardizohet përfundimisht nga IETF.
Pritet që standardizimi i QUIC t'i japë shtysë miratimit më të gjerë të këtij protokolli, si dhe zhvillimit të shtesave të bazuara në të, si WebTransport (një teknologji për dërgimin dhe marrjen e të dhënave midis një shfletuesi dhe një serveri) dhe MASQUE (një teknologji proxying lidhjeje që zgjeron aftësitë e SOCKS dhe HTTP CONNECT, dhe duke përdorur HTTPS mbi QUIC si transport).
Le të kujtojmë se protokolli QUIC (Quick UDP Internet Connections) është zhvilluar nga Google që nga viti 2013 si një alternativë ndaj kombinimit TCP+TLS për ueb, duke zgjidhur problemet me kohën e gjatë të konfigurimit dhe negocimit të lidhjeve në TCP dhe eliminimin e vonesave kur paketat humbasin gjatë transferimit të të dhënave. QUIC është një zgjatim i protokollit UDP që mbështet multipleksimin e lidhjeve të shumta dhe ofron metoda të kriptimit të barasvlershme me TLS/SSL. Gjatë zhvillimit të standardit IETF, u bënë ndryshime në protokoll, të cilat çuan në shfaqjen e dy degëve paralele, njëra për HTTP/3 dhe e dyta e mbështetur nga Google (Chrome mbështet të dy opsionet, dhe Firefox-i mbështet versionin IETF) .
Karakteristikat kryesore të QUIC:
- Siguri e lartë e ngjashme me TLS (në thelb QUIC ofron mundësinë për të përdorur TLS mbi UDP);
- Kontrolli i integritetit të rrjedhës, duke parandaluar humbjen e paketave;
- Aftësia për të vendosur menjëherë një lidhje (0-RTT, në afërsisht 75% të rasteve të dhënat mund të transmetohen menjëherë pas dërgimit të paketës së konfigurimit të lidhjes) dhe të sigurojë vonesa minimale midis dërgimit të një kërkese dhe marrjes së një përgjigje (RTT, Koha e udhëtimit vajtje-ardhje);
- Përdorimi i një numri të ndryshëm të sekuencës gjatë ritransmetimit të një pakete, gjë që shmang paqartësitë në identifikimin e paketave të marra dhe shpëton nga afatet kohore;
- Humbja e një pakete ndikon vetëm në shpërndarjen e rrymës së lidhur me të dhe nuk ndalon dërgimin e të dhënave në rrjedhat paralele të transmetuara përmes lidhjes aktuale;
- Karakteristikat e korrigjimit të gabimeve që minimizojnë vonesat për shkak të ritransmetimit të paketave të humbura. Përdorimi i kodeve speciale të korrigjimit të gabimeve në nivel pakete për të reduktuar situatat që kërkojnë ritransmetim të të dhënave të paketave të humbura.
- Kufijtë e blloqeve kriptografike janë në linjë me kufijtë e paketave QUIC, gjë që zvogëlon ndikimin e humbjeve të paketave në dekodimin e përmbajtjes së paketave pasuese;
- Nuk ka probleme me bllokimin e radhës TCP;
- Mbështetje për identifikuesin e lidhjes, i cili redukton kohën që duhet për të vendosur një rilidhje për klientët celularë;
- Mundësia e lidhjes së mekanizmave të avancuar të kontrollit të kongjestionit të lidhjeve;
- Përdor teknikat e parashikimit të xhiros për drejtim për të siguruar që paketat të dërgohen me ritme optimale, duke i parandaluar ato të mbingarkohen dhe të shkaktojnë humbje të paketave;
- Rritje e ndjeshme e performancës dhe xhiros në krahasim me TCP. Për shërbimet e videove të tilla si YouTube, QUIC është treguar se redukton operacionet e rebufferimit kur shikoni video me 30%.
Burimi: opennet.ru