Cloudflare Kompanio provizi subtenon por la HTTP/3 protokolo en NGINX. La modulo estas desegnita kiel aldonaĵo al la biblioteko disvolvita de Cloudflare kun la efektivigo de la transportprotokolo QUIC kaj HTTP/3. La quiche-kodo estas skribita en Rust, sed la NGINX-modulo mem estas skribita en C kaj aliras la bibliotekon per dinamika ligo. Evoluoj sub la permesilo BSD.
Por kunveni, simple elŝutu al nginx 1.16 kaj Quiche-bibliotekoj, tiam rekonstruu nginx kun la opcioj "—with-http_v3_module —with-quiche=../quiche". Dum konstruado, TLS-subteno devus baziĝi sur la BoringSSL-biblioteko ("--with-openssl=../quiche/deps/boringssl"), la uzo de OpenSSL ankoraŭ ne estas subtenata. Por akcepti konektojn, vi devas aldoni la direktivon aŭskulti kun la flago "quic" al la agordoj (ekzemple, "aŭskulti 443 rapida reuza raporto").
En klienta programaro, HTTP/3-subteno jam estis aldonita al eksperimentaj konstruoj de Chrome Canary kaj la bukla ilo. Ĉe la servilo, ĝis nun necesis uzi apartan, limigitan . La kapablo prilabori HTTP/3 en nginx signife simpligos la deplojon de serviloj kun HTTP/3-subteno kaj faros testan efektivigon de la nova protokolo pli alirebla. La apero de norma subteno por HTTP/3 en nginx en la branĉo 1.17.x dum 6-12 monatoj.
Memoru, ke HTTP/3 normigas la uzon de la QUIC-protokolo kiel transporto por HTTP/2. 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 intertraktadtempoj 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.
Ĉ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