HTTP/2 i HTTP/3 w Angie: konfiguracja i wydajność

HTTP/2 i HTTP/3 w Angie: konfiguracja techniczna, pułapki i wydajność

Angie to nowoczesny serwer webowy o wysokiej wydajności z natywną obsługą HTTP/2 i HTTP/3. W przeciwieństwie do Nginx, jego implementacja tych protokołów obejmuje akcelerację BPF, optymalizacje QUIC na poziomie jądra oraz integrację z upstreamami za pomocą UDP. Niniejszy artykuł skupia się nie na teorii, ale na praktycznych aspektach włączania, precyzyjnej konfiguracji i usuwania typowych problemów w środowiskach produkcyjnych — od blokady HOL po podatności DoS w multiplexowanych połączeniach.

Dlaczego HTTP/2 i HTTP/3 wymagają specjalnego podejścia w Angie

Główna różnica między klasycznymi serwerami a Angie nie polega na obecności funkcji, lecz na ich architektonicznym przypisaniu do modelu przetwarzania. W HTTP/1.1 każdy socket TCP obsługiwany jest przez osobny proces roboczy, co naturalnie rozkłada obciążenie. HTTP/2 i HTTP/3 naruszają ten schemat: jeden klient tworzy jedno długotrwałe połączenie (połączenie QUIC lub sesję TLS z ALPN), które w całości obsługuje jeden proces worker. To zwiększa efektywność przy niskich opóźnieniach, ale stwarza „punkty gorące” przy dużej koncentracji potoków. Szczególnie krytycznie jest to w przypadku HTTP/2: jeśli http2_max_concurrent_streams ustawiono na 1024, a klient otworzy 900 strumieni — cały ruch tego klienta będzie przebiegał przez jeden proces, nawet przy 8 rdzeniach. W przypadku HTTP/3 sytuacja jest jeszcze trudniejsza: połączenie QUIC może migrować między interfejsami, ale w obecnej implementacji Angie migracja nie przekierowuje obciążenia pomiędzy worker’ami — pozostaje ona przywiązanym do pierwotnego procesu.

Ponadto Angie nie tylko włącza protokoły — stosuje również systemowe optymalizacje niedostępne w Nginx. Na przykład quic_bpf on aktywuje programy eBPF do filtrowania i wstępnej obróbki pakietów QUIC w przestrzeni jądra, redukując przełączanie kontekstów. Z kolei quic_gso on włącza Generic Segmentation Offload na poziomie stoku sieciowego — co jest kluczowe dla zmniejszenia obciążenia CPU podczas przesyłania dużych obiektów (np. fragmentów wideo czy paczek WebAssembly).

Kluczowe parametry HTTP/2: od bezpieczeństwa do wydajności

Konfiguracja HTTP/2 w Angie wykracza poza dyrektywę http2 on. Rzeczywisty wpływ na stabilność i bezpieczeństwo mają trzy grupy parametrów:

1. Ograniczenia potoków i zasobów

• http2_max_concurrent_streams — to nie tylko limit, ale czynnik rozkładu obciążenia. Domyślna wartość 128 jest odpowiednia dla aplikacji webowych o umiarkowanej dynamice. W przypadku bram API z wieloma połączeniami long-polling zaleca się obniżenie do 64, aby uniknąć przeciążenia jednego worker’a.
• http2_max_requests — maksymalna liczba żądań na jedno połączenie. Domyślna wartość to 1000. Przy wartości 0 ograniczenie jest wyłączone, ale to niebezpieczne: klient może utrzymywać połączenie w nieskończoność, osiągając limit worker_connections.
• http2_idle_timeout — czas życia nieaktywnego połączenia. Standardowa wartość 3m może być zwiększona do 5m dla klientów mobilnych z niestabilnym LTE, ale nie więcej — inaczej rośnie ryzyko DoS poprzez „połączenia zombie”.

2. Buforowanie i rozmiary chunków

• http2_chunk_size reguluje rozmiar fragmentów odpowiedzi. Wartość 8k stanowi kompromis między latencją a przepustowością. W przypadku treści multimedialnych (MSE/DASH) celowe jest zwiększenie do 64k, jednak wtedy traci się elastyczność priorytetyzacji.
• http2_recv_buffer_size — bufor danych przychodzących. Zwiększenie ponad 128k (domyślnie) rzadko daje wzrost, ale zwiększa zużycie pamięci na połączenie.
• http2_body_preread_size — objętość danych odczytywanych przed uruchomieniem procesora. Jest to kluczowe dla middleware sprawdzającego ciało żądania (np. filtrów WAF). Zalecana wartość to 64k dla JSON-API, 1m — dla przesyłania plików.

3. Wyłączenie zachowanych możliwości

Server Push został usunięty z kodu Angie — to nie błąd konfiguracji, lecz świadome decyzja. Wszelkie próby użycia http2_push lub http2_push_preload spowodują błąd parsowania konfiguracji. Dzięki temu eliminuje się klasyczny problem cachingu: zasoby push nie mogą być dostarczane warunkowo i często dublują już zwyczajowo zapamiętane przez klienta dane.

Konfiguracja HTTP/3: QUIC, TLS 1.3 i gotowość sieciowa

HTTP/3 w Angie wymaga trzystopniowej przygotowania: bibliotecznego, sieciowego i infrastruktury DNS.

Biblioteki i TLS

Obowiązkowym warunkiem jest OpenSSL ≥ 1.1.1 dla podstawowego HTTP/3 i ≥ 3.5.1 dla 0-RTT. Jednak wersja OpenSSL nie gwarantuje kompatybilności: w niektórych dystrybucjach (np. RHEL 9.3) używany jest fork openssl-fips, który nie wspiera rozszerzeń QUIC. Sprawdzanie wykonuje się komendą:

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

Jeśli wynik jest pusty — QUIC został wyłączony na etapie kompilacji.

Wymagania sieciowe

UDP/443 musi być otwarty nie tylko w firewallu, ale także na wszystkich urządzeniach pośrednich: balanserach L4, systemach ochrony przed DDoS, bramkach SD-WAN. QUIC korzysta z pakietów o zmiennej długości, a wiele stateful-filterów blokuje pakiet o rozmiarze > 1500 bajtów bez wyraźnego zezwolenia. Ponadto należy wyłączyć PMTU Discovery na poziomie jądra (net.ipv4.ip_no_pmtu_disc = 1) — inaczej fragmentacja po stronie klienta doprowadzi do utraty pakietów.

Mechanizmy deklaracji wsparcia

Angie wspiera dwa sposoby informowania klienta o HTTP/3:

• Zagłówek Alt-Svc — standardowy i najbardziej kompatybilny. Przykład konfiguracji:

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

Tu ma=86400 to czas życia deklaracji w sekundach. Nie zaleca się ustawiania ma=0 dla „wyłączenia” — klienci ignorują taki zagłówek.

• Zapisy HTTPS w DNS — wymagają wsparcia ze strony klienta (Chrome ≥ 117, Safari ≥ 17) i prawidłowej konfiguracji DNSSEC. Format zapisu:

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

Oba metody można łączyć: klienci obsługujący deklarację DNS korzystają z niej, pozostali — z Alt-Svc.

Co jest ważne

• HTTP/2 i HTTP/3 w Angie tworzą jedno połączenie na klienta, całkowicie przypięte do jednego procesu worker — wymaga to przewartościowania limitów worker_connections i events { use epoll; }.
• Server Push został usunięty z Angie na zawsze — wszelkie wzmianki w konfiguracji spowodują błąd parsowania.
• Dla HTTP/3 obowiązkowa jest obsługa TLS 1.3, ale nie wszystkie kompilacje OpenSSL ją zawierają — sprawdźcie angie -V.
• Połączenia QUIC wymagają otwarcia UDP/443 na wszystkich poziomach sieci, w tym na balanserach L4 i systemach ochrony przed DDoS.
• quic_bpf on i quic_gso on — kluczowe optymalizacje, które redukują obciążenie CPU o 15–22% przy transmisji powyżej 100 Mbit/s.

Wydajność i monitoring w warunkach bojowych

Ocena efektywności HTTP/2/3 nie jest możliwa bez metryk na poziomie połączeń. W Angie dostępne są następujące wewnętrzne zmienne w logach:

• $http2 — 1, jeśli połączenie używa HTTP/2, puste w innym przypadku;
• $http3 — 1 dla HTTP/3;
• $quic_version — wersja QUIC (np. ff00001d);
• $bytes_sent i $request_length — umożliwiają obliczenie nakładu na poziomie protokołu.

Aby analizować blokadę HOL, użyjcie wykresu zależności request_time od http2_stream_id: gwałtowny wzrost czasu przy wysokich ID wskazuje na blokadę w kolejce potoków. W przypadku HTTP/3 takiego efektu nie ma — tam każdy stream jest przetwarzany niezależnie.

Podczas testów obciążeniowych z użyciem wrk lub hey koniecznie podajcie flagę -H "Connection: keep-alive" i -H "Accept-Encoding: gzip, br", inaczej testy będą emulować zachowanie HTTP/1.1. Dla HTTP/3 potrzebny jest hey -h3 lub curl --http3.

Typowym błędem jest poleganie wyłącznie na ab (ApacheBench): nie obsługuje on HTTP/2 ani HTTP/3, więc wyniki będą zafałszowane.

— Editorial Team