Al eksperimentaj konstruoj subteno por la HTTP/3-protokolo, kiu efektivigas aldonaĵon por ebligi HTTP funkcii super la QUIC-protokolo. La QUIC-protokolo mem estis aldonita al la retumilo antaŭ kvin jaroj kaj poste estis uzata por optimumigi laboron kun Google-servoj. Samtempe, la QUIC-versio de Guglo uzata en Chrome diferencis en kelkaj detaloj de la versio de IETF, sed nun la efektivigoj estas sinkronigitaj.
HTTP/3 normigas la uzon de QUIC kiel transporto por HTTP/2. Por ebligi HTTP/3 kaj QUIC-opcion de La specifoj de IETF postulas, ke Chrome estu lanĉita kun la opcioj "-enable-quic -quic-version=h3-23" kaj poste kiam oni malfermas la testejon. En reto-inspekta reĝimo en programistaj iloj, HTTP/3-agado estos montrata kiel "http/2+quic/99".
Memoru ke la protokolo (Rapidaj UDP-Interretaj Konektoj) estas evoluigita de Google ekde 2013 kiel alternativo al la TCP+TLS-kombinaĵo por la Reto, solvante problemojn kun longaj aranĝoj kaj intertraktadoj por konektoj en TCP kaj forigante prokrastojn kiam pakaĵetoj estas perditaj dum datumtransigo. QUIC estas etendaĵo de la UDP-protokolo kiu subtenas multipleksadon de multoblaj ligoj kaj disponigas ĉifradmetodojn ekvivalentajn al TLS/SSL. La koncerna protokolo jam estas integrita en la infrastrukturon de la servilo de Guglo kaj estas parto de Chrome. por inkluziviĝo en Fajrovulpo kaj estas aktive uzata por servi klientajn petojn sur Google-serviloj.
Ĉefa RAPIDA:
- 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ĝa pako) kaj disponigi minimumajn prokrastojn inter sendado de peto kaj ricevado de respondo (RTT, Round Trip Time);
- Ne uzanta la saman sinsekvon dum retranssendo de pakaĵeto, kio evitas ambiguecon en identigado de ricevitaj pakaĵetoj kaj forigas tempodemortojn;
- 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;
- Perceptebla 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