HTTP/2 und HTTP/3 in Angie: Konfiguration und Leistung

HTTP/2 und HTTP/3 in Angie: Technische Konfiguration, Fallstricke und Performance

Angie ist ein moderner, leistungsstarker Webserver mit nativer Unterstützung für HTTP/2 und HTTP/3. Im Gegensatz zu Nginx umfasst seine Implementierung dieser Protokolle BPF-Beschleunigung, Kernel-Level-QUIC-Optimierungen sowie die Integration mit Upstream-Servern über UDP. Dieser Artikel konzentriert sich nicht auf Theorie, sondern auf praktische Aspekte der Aktivierung, Feinabstimmung und Fehlerbehebung bei häufigen Problemen in Produktionsumgebungen – von HOL-Blocking bis hin zu DoS-Schwachstellen in multiplexierten Verbindungen.

Warum HTTP/2 und HTTP/3 in Angie einen speziellen Ansatz erfordern

Der entscheidende Unterschied zwischen traditionellen Servern und Angie liegt nicht nur in der Verfügbarkeit bestimmter Funktionen, sondern darin, wie sie um das Verarbeitungsmodell herum architektonisch aufgebaut sind. Bei HTTP/1.1 wird jeder TCP-Socket von einem separaten Worker-Prozess bearbeitet, was die Last natürlich gleichmäßig verteilt. HTTP/2 und HTTP/3 brechen dieses Muster: Ein einzelner Client stellt eine langfristige Verbindung (eine QUIC-Verbindung oder eine TLS-Sitzung mit ALPN) her, die vollständig von einem einzigen Worker-Prozess verarbeitet wird. Dies erhöht die Effizienz bei niedrigen Latenzzeiten, führt jedoch zu Hotspots, wenn der Datenverkehr stark konzentriert ist. Besonders kritisch ist dies bei HTTP/2: Wenn http2_max_concurrent_streams auf 1024 gesetzt ist und ein Client 900 Streams öffnet, wird der gesamte Datenverkehr dieses Clients durch einen einzigen Prozess geleitet – selbst bei 8 CPU-Kernen. Bei HTTP/3 ist die Situation noch komplexer: Zwar kann eine QUIC-Verbindung zwischen Schnittstellen migrieren, doch die aktuelle Implementierung von Angie verteilt die Last während der Migration nicht auf mehrere Worker – die Verbindung bleibt weiterhin dem ursprünglichen Prozess zugeordnet.

Darüber hinaus aktiviert Angie diese Protokolle nicht nur; es werden auch systemweite Optimierungen angewendet, die in Nginx nicht verfügbar sind. Zum Beispiel aktiviert quic_bpf on eBPF-Programme zur Filterung und Vorverarbeitung von QUIC-Paketen im Kernelbereich, wodurch Kontextwechsel reduziert werden. Und quic_gso on ermöglicht Generic Segmentation Offload auf Netzwerkstapel-Ebene – entscheidend, um die CPU-Last beim Übertragen großer Objekte (wie Videofragmente oder WebAssembly-Bundles) zu senken.

Wichtige HTTP/2-Parameter: Von Sicherheit bis Performance

Die Konfiguration von HTTP/2 in Angie geht über das bloße Setzen von http2 on hinaus. Drei Gruppen von Parametern haben einen echten Einfluss auf Stabilität und Sicherheit:

1. Stream- und Ressourcenlimits

• http2_max_concurrent_streams ist nicht nur ein Limit – es beeinflusst auch die Lastverteilung. Der Standardwert von 128 funktioniert gut für moderat dynamische Webanwendungen. Für API-Gateways mit vielen Long-Polling-Verbindungen empfiehlt es sich, diesen Wert auf 64 zu reduzieren, um eine Überlastung eines einzelnen Workers zu vermeiden.
• http2_max_requests legt die maximale Anzahl von Anfragen pro Verbindung fest. Der Standardwert beträgt 1000. Setzt man ihn auf 0, wird das Limit deaktiviert – doch das ist riskant: Ein Client könnte eine Verbindung unbefristet halten und so das Limit für worker_connections erschöpfen.
• http2_idle_timeout definiert, wie lange eine Leerlaufverbindung aktiv bleibt. Der Standardwert von 3 Minuten kann für mobile Clients mit instabilem LTE auf 5 Minuten erhöht werden, aber nicht darüber – sonst steigt das Risiko von DoS-Angriffen über „Zombie-Verbindungen“.

2. Pufferung und Chunk-Größen

• http2_chunk_size steuert die Größe der Antwort-Chunks. Ein Wert von 8 KB bietet ein Gleichgewicht zwischen Latenz und Durchsatz. Für Medieninhalte (MSE/DASH) macht es Sinn, diesen Wert auf 64 KB zu erhöhen, obwohl dies die Flexibilität bei der Priorisierung verringert.
• http2_recv_buffer_size passt den Puffer für eingehende Daten an. Eine Erhöhung über den Standardwert von 128 KB verbessert die Leistung selten, erhöht jedoch den Speicherverbrauch pro Verbindung.
• http2_body_preread_size legt fest, wie viel Daten vor Beginn des Handlers gelesen werden. Dies ist entscheidend für Middleware, die Request-Bodys inspiziert (z. B. WAF-Filterung). Es wird empfohlen, diesen Wert auf 64 KB für JSON-APIs und 1 MB für Dateiuploads einzustellen.

3. Deaktivierung alter Funktionen

Server Push wurde aus dem Codebase von Angie entfernt – nicht wegen einer Konfigurationsfehler, sondern als bewusste Entscheidung. Jeder Versuch, http2_push oder http2_push_preload zu verwenden, führt zu einem Konfigurations-Parsing-Fehler. Dadurch wird das klassische Caching-Problem eliminiert: Push-Ressourcen können nicht bedingt bereitgestellt werden und duplizieren oft bereits vom Client zwischengespeicherte Daten.

Konfiguration von HTTP/3: QUIC, TLS 1.3 und Netzwerkvorbereitung

Die Aktivierung von HTTP/3 in Angie erfordert drei Ebenen der Vorbereitung: Bibliothek, Netzwerk und DNS-Infrastruktur.

Bibliotheken und TLS

Eine zwingende Voraussetzung ist OpenSSL ≥ 1.1.1 für grundlegendes HTTP/3 und ≥ 3.5.1 für 0-RTT. Allerdings garantiert die OpenSSL-Version keine Kompatibilität: Einige Distributionen (z. B. RHEL 9.3) verwenden einen openssl-fips-Fork, der QUIC-Erweiterungen nicht unterstützt. Dies kann man mit dem Befehl überprüfen:

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

Wenn die Ausgabe leer ist, wurde QUIC bei der Kompilierung deaktiviert.

Netzwerkanforderungen

UDP/443 muss nicht nur in der Firewall, sondern auch auf allen Zwischenstationen offen sein: L4-Load-Balancer, DDoS-Schutzsysteme und SD-WAN-Gateways. QUIC verwendet Pakete variabler Länge, und viele stateful Filter blockieren Pakete größer als 1500 Byte ohne explizite Erlaubnis. Außerdem sollte PMTU Discovery auf Kernel-Ebene deaktiviert werden (net.ipv4.ip_no_pmtu_disc = 1) – sonst führt Fragmentierung auf Client-Seite zu Paketverlust.

Ankündigungsmechanismen

Angie unterstützt zwei Möglichkeiten, Clients über HTTP/3 zu informieren:

• Alt-Svc-Header – die standardmäßige und am weitesten kompatible Option. Hier ist ein Beispielkonfiguration:

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

Hier ist ma=86400 die Lebensdauer der Ankündigung in Sekunden. Es wird nicht empfohlen, ma=0 zu setzen, um sie zu „deaktivieren“ – der Client ignoriert dann solche Header.

• HTTPS-Einträge im DNS – erfordert Client-Unterstützung (Chrome ≥ 117, Safari ≥ 17) und korrekte DNSSEC-Konfiguration. Das Eintragsformat lautet:

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

Beide Methoden können kombiniert werden: Clients, die DNS-Ankündigungen unterstützen, nutzen sie, während andere auf Alt-Svc zurückgreifen.

Was wichtig ist

• HTTP/2 und HTTP/3 in Angie schaffen eine einzige Verbindung pro Client, die vollständig an einen Worker-Prozess gebunden ist – dies erfordert eine Neubetrachtung der Limits für worker_connections und events { use epoll; }.
• Server Push wurde dauerhaft aus Angie entfernt – jede Erwähnung in der Konfiguration führt zu einem Parsing-Fehler.
• Für HTTP/3 ist die Unterstützung von TLS 1.3 zwingend erforderlich, doch nicht alle OpenSSL-Builds enthalten sie – prüfen Sie dies mit angie -V.
• QUIC-Verbindungen erfordern, dass UDP/443 auf jeder Netzwerkebene offen ist, einschließlich L4-Load-Balancern und DDoS-Systemen.
• quic_bpf on und quic_gso on sind wichtige Optimierungen, die die CPU-Last beim Übertragen von >100 Mbps um 15–22 % senken.

Performance und Monitoring in der Produktion

Die Bewertung der Wirksamkeit von HTTP/2/3 ist ohne Metriken auf Verbindungsebene unmöglich. Angie stellt folgende interne Log-Variablen zur Verfügung:

• $http2 – 1, wenn die Verbindung HTTP/2 nutzt, sonst leer;
• $http3 – 1 für HTTP/3;
• $quic_version – die QUIC-Version (z. B. ff00001d);
• $bytes_sent und $request_length – ermöglichen die Berechnung des protokollbezogenen Overheads.

Um HOL-Blocking zu analysieren, verwendet man ein Diagramm, das den Zusammenhang zwischen request_time und http2_stream_id zeigt: Ein starker Anstieg der Zeit bei hohen Stream-IDs deutet auf Warteschlangenverzögerungen hin. Bei HTTP/3 tritt dieser Effekt nicht auf – jeder Stream wird unabhängig verarbeitet.

Bei Loadtests mit wrk oder hey sollten immer die Flags -H "Connection: keep-alive" und -H "Accept-Encoding: gzip, br" angegeben werden; sonst ahmen die Tests HTTP/1.1-Verhalten nach. Für HTTP/3 verwendet man hey -h3 oder curl --http3.

Ein häufiger Fehler ist, sich ausschließlich auf ab (ApacheBench) zu verlassen: Es unterstützt weder HTTP/2 noch HTTP/3, sodass die Ergebnisse verzerrt sind.

— Editorial Team