Mozilo anoncis sian intencon komenci enfazigi HTTP/3 kaj QUIC kun la ĵeto de Fajrovulpo 88, planita por la 19-a de aprilo (originale atendite aperigi la 20-an de aprilo, sed se juĝante laŭ la horaro, ĝi estos repuŝita de unu tago). HTTP/3-subteno estos ebligita por nur malgranda procento de uzantoj komence kaj, krom neatenditaj problemoj, estos lanĉita al ĉiuj antaŭ la fino de majo. En noktaj konstruoj kaj beta-versioj, HTTP/3 estis ebligita defaŭlte fine de marto.
Ni rememoru, ke la efektivigo de HTTP/3 en Fajrovulpo baziĝas sur la neqo-projekto evoluigita de Mozilla, kiu disponigas klientan kaj servilan efektivigon por la QUIC-protokolo. La komponentkodo por HTTP/3 kaj QUIC-subteno estas skribita en Rust. Por kontroli ĉu HTTP/3 estas ebligita, about:config disponigas la opcion "network.http.http3.enabled". De klienta programaro, eksperimenta subteno por HTTP/3 ankaŭ estis aldonita al Chrome kaj curl, kaj por serviloj ĝi haveblas en nginx, same kiel en la formo de nginx-modulo kaj testa servilo de Cloudflare. Ĉe la retejo, HTTP/3-subteno jam estas provizita en serviloj de Google kaj Facebook.
La HTTP/3-protokolo daŭre estas en la skiza specifstadio kaj ankoraŭ ne estis plene normigita fare de la IETF. HTTP/3 postulas klientan kaj servilan subtenon por la sama versio de la QUIC-skizo-normo kaj HTTP/3, kiu estas specifita en la Alt-Svc-kapo (Firefox subtenas specifskizojn 27 ĝis 32).
HTTP/3 difinas la uzon de la QUIC-protokolo kiel transporton por HTTP/2. 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 longaj aranĝoj kaj intertraktadoj por konektoj en TCP kaj forigante prokrastojn kiam pakaĵetoj estas perditaj dum datumoj. translokigo. 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).
Ĉ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