La IETF (Internet Engineering Task Force), kiu respondecas pri la evoluo de Interretaj protokoloj kaj arkitekturo, kompletigis la formadon de RFC por la HTTP/3.0 protokolo kaj publikigis rilatajn specifojn sub la identigiloj RFC 9114 (protokolo) kaj RFC 9204 ( QPACK-kapa kunprema teknologio por HTTP/3). La specifo HTTP/3.0 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. la komentoj faritaj. En la sama tempo, ĝisdatigitaj versioj de la specifoj por la HTTP/1.1 (RFC 9112) kaj HTTP/2.0 (RFC 9113) protokoloj estis publikigitaj, same kiel dokumentoj difinantaj la semantikon de HTTP-petoj (RFC 9110) kaj HTTP-caching-kontrolkapoj. (RFC 9111).
La HTTP/3-protokolo difinas la uzon de la protokolo QUIC (Quick UDP Internet Connections) kiel transporton por HTTP/2. QUIC estas etendaĵo de la UDP-protokolo kiu subtenas multipleksadon de multoblaj ligoj kaj disponigas ĉifradmetodojn ekvivalentajn al TLS/SSL. La protokolo estis kreita en 2013 de Google kiel alternativo al la kombinaĵo TCP+TLS por la Reto, solvante problemojn kun longaj konekto-agordo kaj intertraktadotempoj en TCP kaj forigante prokrastojn kiam pakaĵetoj estas perditaj dum datumtransigo.
Nuntempe, subteno de QUIC kaj HTTP/3.0 jam estas efektivigita en ĉiuj popularaj retumiloj (en Chrome, Firefox kaj Edge, HTTP/3-subteno estas ebligita defaŭlte, kaj en Safaro ĝi postulas la agordon "Altnivelaj > Eksperimentaj Trajtoj > HTTP/3" esti ebligita). Ĉe servila flanko, HTTP/3-efektivigoj disponeblas por nginx (en aparta branĉo kaj en formo de aparta modulo), Caddy, IIS kaj LiteSpeed. HTTP/3-subteno ankaŭ estas provizita de la Cloudflare-enhava livera reto.
Ĉ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%.
Inter la ŝanĝoj en la HTTP/1.1-specifo, oni povas noti la malpermeson pri la izolita uzo de la kaleŝoreveno (CR) karaktero ekster la korpo kun enhavo, t.e. En protokolelementoj, la CR-karaktero povas nur esti uzita lige kun la linipaŝa signo (CRLF). La peta enpaĝigo-algoritmo estis plibonigita por simpligi la apartigon de kunigitaj kampoj kaj sekcioj kun kaplinioj. Aldonitaj rekomendoj por pritrakti ambiguan enhavon por bloki atakojn de "HTTP Request Smuggling", kiuj ebligas nin kojni nin en la enhavon de la petoj de aliaj uzantoj en la fluo inter la fasado kaj backend.
La ĝisdatigo de specifoj HTTP/2.0 eksplicite difinas subtenon por TLS 1.3. Malrekomendita la prioritatskemo kaj rilataj kapliniaj kampoj. La neuzata mekanismo por ĝisdatigi la konekton kun HTTP/1.1 estis deklarita malnoviĝinta. Reduktitaj postuloj por kontroli kamponomojn kaj valorojn. Kelkaj antaŭe rezervitaj kadrospecoj kaj parametroj estas proponitaj por uzo. La malpermesitaj kapkampoj rilataj al la konekto estas pli precize difinitaj.
fonto: opennet.ru