HTTP/2 a HTTP/3 v Angie: nastavení a výkon

HTTP/2 a HTTP/3 v Angie: technická konfigurace, podvodní kamínky a výkon

Angie je moderní vysoce zatěžovaný webový server s nativní podporou HTTP/2 a HTTP/3. Na rozdíl od Nginxu jeho implementace těchto protokolů zahrnuje BPF-zrychlení, QUIC-optimalizace na úrovni jádra a integraci s upstreamy přes UDP. Tento článek se nezaměřuje na teorii, ale na praktické aspekty zapnutí, jemného nastavení a odstraňování typických problémů v ostrém provozu — od HOL-blockingu až po DoS zranitelnosti v multiplexovaných spojeních.

Proč HTTP/2 a HTTP/3 vyžadují speciální přístup v Angie

Hlavní rozdíl mezi klasickými servery a Angie není v dostupnosti funkcí, ale v jejich architektonické vazbě na model zpracování. V HTTP/1.1 je každý TCP-soket obsluhován samostatným pracovním procesem, což přirozeně rozloží zátěž. HTTP/2 a HTTP/3 tento vzorec narušují: jeden klient vytvoří jedno dlouhotrvající spojení (QUIC- spojení nebo TLS-sesii s ALPN), které je kompletně zpracováváno jedním worker-procesem. To zvyšuje efektivitu při malých latencích, ale vytváří „horké body“ při vysoké koncentraci toků. Zvláště to platí pro HTTP/2: pokud je http2_max_concurrent_streams nastaven na 1024 a klient otevře 900 toků — celý datový proud tohoto klienta bude procházet jedním procesem, i přesto, že má 8 jader. U HTTP/3 je situace složitější: QUIC-spojení může migrovat mezi rozhraními, ale v současné implementaci Angie migrace zatím nepřerozděluje zátěž mezi workery — zůstává vázána na původní proces.

Kromě toho Angie protokoly nejenom zapíná — používá systémové optimalizace, které nejsou dostupné v Nginxu. Například quic_bpf on aktivuje eBPF-programy pro filtraci a předběžnou manipulaci s QUIC-pakety v prostoru jádra, čímž snižuje kontextové přepínání. A quic_gso on zapíná Generic Segmentation Offload na úrovni síťového stohu — což je klíčové pro snížení zátěže CPU při přenosu velkých objektů (například videofragmentů nebo WebAssembly balíčků).

Klíčové parametry HTTP/2: od bezpečnosti až po výkon

Nastavení HTTP/2 v Angie přesahuje rámec direktivy http2 on. Skutečný vliv na stabilitu a bezpečnost mají tři skupiny parametrů:

1. Omezení toků a zdrojů

• http2_max_concurrent_streams — není to jen limit, ale faktor rozložení zátěže. Standardní hodnota 128 je vhodná pro webové aplikace s mírnou dynamikou. Pro API brány s mnoha long-polling připojeními se doporučuje snížit na 64, aby se zabránilo přetížení jednoho workera.
• http2_max_requests — maximální počet požadavků na jedno spojení. Standardní hodnota je 1000. Při hodnotě 0 je omezení vypnuto, ale to je nebezpečné: klient může držet spojení donekonečna a vyčerpat limit worker_connections.
• http2_idle_timeout — doba životnosti neaktivního spojení. Standardní hodnota 3m může být zvýšena na 5m pro mobilní klienty s nestabilním LTE, ale ne více — jinak roste riziko DoS prostřednictvím „zombie spojení“.

2. Bufferování a velikosti chunků

• http2_chunk_size řídí velikost fragmentů odpovědi. Hodnota 8k je kompromis mezi latencí a propustností. Pro mediální obsah (MSE/DASH) je vhodné zvýšit na 64k, ale pak se ztrácí flexibilita prioritizace.
• http2_recv_buffer_size — buffer přijímaných dat. Zvýšení nad standardních 128k (default) zřídka přináší zlepšení, ale zvyšuje spotřebu paměti na jedno spojení.
• http2_body_preread_size — objem dat, které jsou přečteny před spuštěním zpracovatele. Je to kriticky důležité pro middleware, který kontroluje tělo požadavku (například WAF-filtraci). Doporučuje se 64k pro JSON-API, 1m pro souborové uploady.

3. Vypnutí zděděných možností

Server Push byl odstraněn z kódu Angie — to není chyba konfigurace, ale záměrné řešení. Jakékoli pokusy o použití http2_push nebo http2_push_preload vyvolají chybu parsingu konfigurace. Tím se eliminuje klasický problém kešování: push-resourcy nemohou být podmíněně doručeny a často duplikují již kešované data u klienta.

Nastavení HTTP/3: QUIC, TLS 1.3 a síťová připravenost

HTTP/3 v Angie vyžaduje tříúrovňovou přípravu: knihovní, síťovou a DNS-infrastrukturní.

Knihovny a TLS

Nezbytnou podmínkou je OpenSSL ≥ 1.1.1 pro základní HTTP/3 a ≥ 3.5.1 pro 0-RTT. Nicméně verze OpenSSL nezaručuje kompatibilitu: v některých distribucích (například RHEL 9.3) se používá fork openssl-fips, který nepodporuje QUIC rozšíření. Kontrola se provádí příkazem:

angie -V 2>&1 | grep -i quic

Pokud výstup je prázdný — QUIC je vypnutý již při buildu.

Síťové požadavky

UDP/443 musí být otevřeno nejen v firewallu, ale i na všech mezistupeňových zařízeních: L4-balancerech, DDoS ochranách, SD-WAN bránách. QUIC používá proměnnou délku paketu a mnoho stateful-filtérů blokuje pakety > 1500 bajtů bez explicitního povolení. Také je třeba vypnout PMTU Discovery na úrovni jádra (net.ipv4.ip_no_pmtu_disc = 1) — jinak fragmentace na straně klienta povede k ztrátě paketů.

Mechanismy oznamování podpory

Angie podporuje dva způsoby informování klienta o HTTP/3:

• Záhlaví Alt-Svc — standardní a nejkompatibilnější. Příklad konfigurace:

add_header Alt-Svc 'h3=":443"; ma=86400, h3-29=":443"; ma=86400';

Zde ma=86400 je doba životnosti oznamení v sekundách. Nedoporučuje se nastavit ma=0 pro „vypnutí“ — klienti takové záhlaví ignorují.

• HTTPS záznamy v DNS — vyžaduje podporu klienta (Chrome ≥ 117, Safari ≥ 17) a správné nastavení DNSSEC. Formát záznamu:

_https.example.com. IN HTTPS 1 . alpn="h3,h3-29" port=443

Oba metody lze kombinovat: klienti, kteří podporují DNS-oznamování, ho použijí, ostatní — Alt-Svc.

Co je důležité

• HTTP/2 a HTTP/3 v Angie vytvářejí jedno spojení na klienta, plně vázané na jedno worker-proces — to vyžaduje přehodnocení limitů worker_connections a events { use epoll; }.
• Server Push byl navždy odstraněn z Angie — jakékoli zmínky v konfiguraci vyvolají chybu parsingu.
• Pro HTTP/3 je nutná podpora TLS 1.3, ale ne všechny buildy OpenSSL ji obsahují — kontrolujte angie -V.
• QUIC spojení vyžadují otevření UDP/443 na všech úrovních sítě, včetně L4-balancerů a DDoS systémů.
• quic_bpf on a quic_gso on — klíčové optimalizace, které snižují zátěž CPU o 15–22% při přenosu >100 Mbit/s.

Výkon a monitoring v ostrém provozu

Posouzení efektivity HTTP/2/3 je nemožné bez metrik na úrovni spojení. V Angie jsou dostupné následující interní proměnné v logech:

• $http2 — 1, pokud spojení používá HTTP/2, jinak prázdné;
• $http3 — 1 pro HTTP/3;
• $quic_version — verze QUIC (například ff00001d);
• $bytes_sent a $request_length — umožňují vypočítat overhead na úrovni protokolu.

Pro analýzu HOL-blockingu použijte graf závislosti request_time na http2_stream_id: prudký nárůst času při vysokých ID ukazuje na blokování ve frontě toků. U HTTP/3 takový efekt není — tam je každý stream zpracováván nezávisle.

Při zátěžovém testování pomocí wrk nebo hey je nutné uvést flag -H "Connection: keep-alive" a -H "Accept-Encoding: gzip, br", jinak testy budou emulovat behavior HTTP/1.1. Pro HTTP/3 je třeba hey -h3 nebo curl --http3.

Typická chyba je spoléhat pouze na ab (ApacheBench): ten nepodporuje HTTP/2 ani HTTP/3 a výsledky budou zkreslené.

— Editorial Team