La Internet Engineering Task Force (IETF), kiu respondecas pri la evoluo de Interretaj protokoloj kaj arkitekturo, finpretigis la RFC por la QUIC-protokolo kaj publikigis rilatajn specifojn sub la identigiloj RFC 8999 (version-sendependaj protokolaj trajtoj), RFC 9000 (transporto). super UDP), RFC 9001 (TLS-ĉifrado de la QUIC-komunika kanalo) kaj RFC 9002 (obstrukciĝokontrolo kaj pakaĵetodetekto dum datumtranssendo).
La RFC-oj ricevis la statuson de "Proponita Normo", post kiu laboro komencos doni al la RFC la statuson de skiza normo (Draft Standard), kio fakte signifas kompletan stabiligon de la protokolo kaj konsiderante ĉiujn komentojn faritajn. La HTTP/3-protokolo, kiu difinas la uzon de la QUIC-protokolo kiel transporton por HTTP/2, estas ankoraŭ en la skiza specifstadio, sed ĝi baldaŭ estos finfine normigita de la IETF.
Estas atendite, ke la normigado de QUIC donos impulson al pli larĝa adopto de ĉi tiu protokolo, same kiel al la disvolviĝo de etendaĵoj bazitaj sur ĝi, kiel WebTransport (teknologio por sendi kaj ricevi datumojn inter retumilo kaj servilo) kaj MASQUE. (konekto prokura teknologio kiu etendas la kapablojn de SOCKS kaj HTTP CONNECT, kaj uzante HTTPS super QUIC kiel transporto).
Ni rememoru, ke la protokolo QUIC (Rapidaj UDP-Interretaj Konektoj) estas evoluigita de Google ekde 2013 kiel alternativo al la kombinaĵo TCP+TLS por la Reto, solvante problemojn kun la longaj aranĝoj kaj intertraktadoj de konektoj en TCP kaj forigante prokrastojn kiam pakoj estas perditaj dum transdono de datumoj. QUIC estas etendaĵo de la UDP-protokolo kiu subtenas multipleksadon de multoblaj ligoj kaj disponigas ĉifradmetodojn ekvivalentajn al TLS/SSL. Dum la evoluo de la IETF-normo, ŝanĝoj estis faritaj al la protokolo, kio kaŭzis la aperon de du paralelaj branĉoj, unu por HTTP/3, kaj la dua subtenata de Guglo (Chrome subtenas ambaŭ opciojn, kaj Fajrovulpo subtenas la IETF-version) .
Ĉefaj trajtoj de QUIC:
- Alta sekureco simila al TLS (esence QUIC disponigas la kapablon uzi TLS super UDP);
- Flua integreco-kontrolo, malhelpante pakaĵetperdon;
- La kapablo tuj establi konekton (0-RTT, en proksimume 75% de kazoj datumoj povas esti transdonitaj tuj post sendado de la konekto-aranĝpako) kaj disponigi minimumajn prokrastojn inter sendado de peto kaj ricevado de respondo (RTT, Round Trip Time);
- Uzante malsaman sekvencnumeron dum retranssendo de pakaĵeto, kiu evitas ambiguecon en identigado de ricevitaj pakaĵetoj kaj seniĝas de tempoperdoj;
- Perdo de pakaĵeto influas nur la liveron de la rivereto asociita kun ĝi kaj ne ĉesigas la liveron de datenoj en paralelaj riveretoj elsenditaj tra la nuna konekto;
- Erarkorektaj funkcioj, kiuj minimumigas prokrastojn pro retranssendo de perditaj pakaĵoj. Uzo de specialaj erarĝustigkodoj ĉe la pakaĵetnivelo por redukti situaciojn postulantajn retranssendon de perditaj pakaĵetdatenoj.
- Kriptografiaj bloklimoj estas vicigitaj kun QUIC pakaĵetlimoj, kiu reduktas la efikon de pakaĵetperdoj sur malkodado de la enhavo de postaj pakaĵetoj;
- Neniuj problemoj kun TCP-vostoblokado;
- Subteno por konekto-identigilo, kiu reduktas la tempon necesan por establi rekonekton por moveblaj klientoj;
- Eblo konekti altnivelajn kongestajn kontrolmekanismojn de konekto;
- Uzas laŭdirektajn trairajn prognozajn teknikojn por certigi, ke pakaĵetoj estas senditaj ĉe optimumaj tarifoj, malhelpante ilin iĝi ŝtopita kaj kaŭzante pakaĵetperdon;
- Signifa pliiĝo en rendimento kaj trairo kompare kun TCP. Por videoservoj kiel ekzemple Jutubo, QUIC pruviĝis redukti rebuferoperaciojn dum spektado de videoj je 30%.
fonto: opennet.ru