Společnost Cloudflare pro zajištění podpory protokolu HTTP/3 v NGINX. Modul je navržen jako nadstavba nad rozvíjenou knihovnou Cloudflare s implementací transportního protokolu QUIC a HTTP/3. Kód quiche je napsán v jazyce Rust, avšak samotný modul pro NGINX je napsán v jazyce C a interaguje s knihovnou pomocí dynamického linkování. Vývoj na základě licence BSD.
Pro sestavení stačí stáhnout k nginx 1.16 a knihovny quiche, poté je nutné přebudovat nginx s volbami „—with-http_v3_module —with-quiche=../quiche“. Při sestavení by podpora TLS měla vycházet z knihovny BoringSSL („—with-openssl=../quiche/deps/boringssl“), použití OpenSSL zatím není podporováno. Pro příjem spojení je třeba do nastavení přidat direktivu listen s flagem „quic“ (například „listen 443 quic reuseport“).
Podpora HTTP/3 byla již přidána do experimentálních sestavení Chrome Canary a do nástroje curl. Na straně serveru bylo stále potřeba používat omezené, izolované . Možnost zpracování HTTP/3 v nginx výrazně usnadní nasazení serverů s podporou HTTP/3 a učiní testovací implementaci nového protokolu dostupnější. Očekává se, že standardní podpora HTTP/3 v nginx bude dostupná ve verzi 1.17.x během 6–12 měsíců.
Připomínáme, že HTTP/3 standardizuje použití protokolu QUIC jako transportu pro HTTP/2. Protokol (Quick UDP Internet Connections) se od roku 2013 vyvíjí společností Google jako alternativa k kombinaci TCP+TLS pro web, řešící problémy s dlouhým časem na nastavení a vyjednávání spojení v TCP a odstranění zpoždění při ztrátě paketů během přenosu dat. QUIC je nadstavbou nad protokolem UDP, podporující multiplexování několika spojení a poskytující metody šifrování, ekvivalentní TLS/SSL.
Hlavní QUIC:
- Vysoká bezpečnost, srovnatelná s TLS (v podstatě QUIC poskytuje možnost použití TLS nad UDP);
- Kontrola integrity toku, která zabraňuje ztrátě paketů;
- Možnost okamžitého navázání spojení (0-RTT, v přibližně 75% případů lze data přenášet ihned po odeslání prvního paketu) a zajištění minimálních zpoždění mezi odesláním požadavku a obdržením odpovědi (RTT, doba zpětné cesty);
- Nepoužití stejného čísla sekvence při opětovném odeslání paketu, což eliminuje nejednoznačnost při určování přijatých paketů a zbavuje se časových limitů;
- Ztráta paketu ovlivňuje doručení pouze souvisejícího toku a nezastavuje doručení dat v paralelně přenášených tocích přes aktuální spojení;
- Nástroje pro opravu chyb, které minimalizují zpoždění způsobené opětovným přenosem ztracených paketů. Využití speciálních chybových kódů na úrovni paketů pro snížení situací, které vyžadují opětovný přenos dat ztraceného paketu.
- Hranice kryptografických bloků jsou sladěny s hranicemi paketů QUIC, což snižuje dopad ztráty paketů na dekódování obsahu následujících paketů;
- Žádné problémy s blokováním front TCP;
- Podpora identifikátoru spojení, která snižuje čas potřebný k opětovnému navázání spojení pro mobilní klienty;
- Možnost připojení rozšířených mechanismů řízení přetížení spojení;
- Použití techniky predikce šířky pásma v každém směru pro zajištění optimální intenzity odesílání paketů, což zabraňuje přechodu do stavu přetížení, ve kterém dochází ke ztrátě paketů;
- Výrazný výkonu a propustnosti ve srovnání s TCP. Pro video služby, jako je YouTube, prokázal QUIC snížení operací znovu vyrovnání během sledování videa o 30%.
Zdroj: opennet.ru
