HTTP/2 et HTTP/3 dans Angie : configuration et performances

HTTP/2 et HTTP/3 dans Angie : configuration technique, pièges et performances

Angie est un serveur web moderne et haute performance avec une prise en charge native de HTTP/2 et HTTP/3. Contrairement à Nginx, son implémentation de ces protocoles inclut l’accélération BPF, des optimisations QUIC au niveau du noyau et une intégration avec les serveurs en amont via UDP. Cet article ne se concentre pas sur la théorie, mais sur les aspects pratiques de l’activation, du réglage fin et du dépannage des problèmes courants en production — allant du blocage HOL aux vulnérabilités DoS dans les connexions multiplexées.

Pourquoi HTTP/2 et HTTP/3 nécessitent une approche spéciale dans Angie

La principale différence entre les serveurs traditionnels et Angie n’est pas seulement la présence de fonctionnalités — c’est la manière dont elles sont conçues autour du modèle de traitement. Dans HTTP/1.1, chaque socket TCP est géré par un processus worker distinct, ce qui répartit naturellement la charge. Avec HTTP/2 et HTTP/3, ce schéma est rompu : un seul client établit une connexion longue durée (une connexion QUIC ou une session TLS avec ALPN), entièrement traitée par un seul processus worker. Cela augmente l’efficacité à faible latence, mais crée des points chauds lorsque le trafic est très concentré. C’est particulièrement critique pour HTTP/2 : si http2_max_concurrent_streams est fixé à 1024 et qu’un client ouvre 900 flux, tout le trafic de ce client passera par un seul processus — même avec 8 cœurs CPU. Dans HTTP/3, la situation est encore plus complexe : bien qu’une connexion QUIC puisse migrer entre les interfaces, l’implémentation actuelle d’Angie ne redistribue pas la charge entre les workers lors de cette migration — elle maintient la connexion liée au processus d’origine.

De plus, Angie ne se contente pas d’activer ces protocoles ; il applique des optimisations au niveau système inaccessibles dans Nginx. Par exemple, quic_bpf on active des programmes eBPF pour filtrer et prétraiter les paquets QUIC dans l’espace noyau, réduisant ainsi les commutations de contexte. Et quic_gso on permet le Generic Segmentation Offload au niveau de la pile réseau — essentiel pour diminuer la charge CPU lors de la transmission de gros objets (comme des fragments vidéo ou des bundles WebAssembly).

Paramètres clés de HTTP/2 : de la sécurité à la performance

Configurer HTTP/2 dans Angie va bien au-delà de la simple activation de http2 on. Trois groupes de paramètres ont un impact réel sur la stabilité et la sécurité :

1. Limites de flux et de ressources

• http2_max_concurrent_streams n’est pas seulement une limite — c’est un facteur de répartition de la charge. La valeur par défaut de 128 convient bien aux applications web modérément dynamiques. Pour les passerelles API avec de nombreuses connexions long-polling, il est recommandé de la réduire à 64 afin d’éviter de surcharger un seul worker.
• http2_max_requests définit le nombre maximal de requêtes par connexion. La valeur par défaut est de 1000. Si on la met à 0, la limite est désactivée, mais cela est risqué : un client pourrait maintenir une connexion indéfiniment, épuisant ainsi la limite de worker_connections.
• http2_idle_timeout détermine combien de temps une connexion inactive reste active. La valeur standard de 3 minutes peut être portée à 5 minutes pour les clients mobiles avec une LTE instable, mais pas plus — sinon le risque d’attaques DoS via des « connexions zombies » augmente.

2. Mise en tampon et tailles de chunk

• http2_chunk_size contrôle la taille des chunks de réponse. Une valeur de 8 KB offre un bon compromis entre latence et débit. Pour le contenu média (MSE/DASH), il est logique de l’augmenter à 64 KB, bien que cela réduise la flexibilité en matière de priorisation.
• http2_recv_buffer_size ajuste le tampon pour les données entrantes. L’augmenter au-delà de la valeur par défaut de 128 KB améliore rarement les performances, mais augmente la consommation de mémoire par connexion.
• http2_body_preread_size spécifie la quantité de données lues avant que le handler ne commence. C’est crucial pour les middleware qui inspectent les corps de requête (par exemple, le filtrage WAF). Il est recommandé de la régler à 64 KB pour les API JSON et à 1 MB pour les uploads de fichiers.

3. Désactivation des fonctionnalités héritées

Le Server Push a été retiré de la base de code d’Angie — non pas à cause d’une erreur de configuration, mais comme décision délibérée. Toute tentative d’utiliser http2_push ou http2_push_preload entraînera une erreur d’analyse de la configuration. Cela élimine le problème classique de mise en cache : les ressources push ne peuvent pas être livrées de manière conditionnelle et dupliquent souvent des données déjà mises en cache par le client.

Configuration de HTTP/3 : QUIC, TLS 1.3 et préparation du réseau

Activer HTTP/3 dans Angie nécessite trois niveaux de préparation : bibliothèques, réseau et infrastructure DNS.

Bibliothèques et TLS

Une exigence obligatoire est OpenSSL ≥ 1.1.1 pour le HTTP/3 de base et ≥ 3.5.1 pour le 0-RTT. Toutefois, la version d’OpenSSL ne garantit pas la compatibilité : certaines distributions (par exemple, RHEL 9.3) utilisent un fork openssl-fips qui ne prend pas en charge les extensions QUIC. Vous pouvez vérifier cela avec la commande :

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

Si la sortie est vide, QUIC a été désactivé lors de la compilation.

Exigences réseau

UDP/443 doit être ouvert non seulement dans le pare-feu, mais aussi sur tous les équipements intermédiaires : équilibrages de charge L4, systèmes de protection contre les DDoS et passerelles SD-WAN. QUIC utilise des paquets de longueur variable, et de nombreux filtres étatiques bloquent les paquets de plus de 1500 octets sans autorisation explicite. Il faut également désactiver la découverte PMTU au niveau du noyau (net.ipv4.ip_no_pmtu_disc = 1) — sinon, la fragmentation côté client entraînera des pertes de paquets.

Mécanismes d’annonce

Angie prend en charge deux façons d’informer les clients de l’existence de HTTP/3 :

• En-tête Alt-Svc — l’option standard et la plus compatible. Voici un exemple de configuration :

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

Ici, ma=86400 est la durée de vie de l’annonce en secondes. Il n’est pas recommandé de mettre ma=0 pour « désactiver » l’annonce — le client ignorera alors cet en-tête.

• Enregistrements HTTPS dans le DNS — nécessite la prise en charge du client (Chrome ≥ 117, Safari ≥ 17) et une configuration DNSSEC appropriée. Le format de l’enregistrement est :

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

Les deux méthodes peuvent être combinées : les clients qui prennent en charge les annonces DNS les utiliseront, tandis que les autres s’appuieront sur Alt-Svc.

Ce qui compte

• HTTP/2 et HTTP/3 dans Angie créent une seule connexion par client, entièrement liée à un seul processus worker — cela exige de revoir les limites de worker_connections et de events { use epoll; }.
• Le Server Push a été définitivement retiré d’Angie — toute mention dans la config provoquera une erreur d’analyse.
• Pour HTTP/3, la prise en charge de TLS 1.3 est obligatoire, mais toutes les compilations d’OpenSSL ne l’incluent pas — vérifiez avec angie -V.
• Les connexions QUIC exigent que UDP/443 soit ouvert à tous les niveaux du réseau, y compris les équilibrages de charge L4 et les systèmes anti-DDoS.
• quic_bpf on et quic_gso on sont des optimisations clés qui réduisent la charge CPU de 15 à 22 % lors de transferts supérieurs à 100 Mbps.

Performance et surveillance en production

Évaluer l’efficacité de HTTP/2/3 est impossible sans métriques au niveau de la connexion. Angie fournit les variables de journal interne suivantes :

• $http2 — 1 si la connexion utilise HTTP/2, sinon vide ;
• $http3 — 1 pour HTTP/3 ;
• $quic_version — la version QUIC (par exemple, ff00001d) ;
• $bytes_sent et $request_length — permettent de calculer la surcharge au niveau du protocole.

Pour analyser le blocage HOL, utilisez un graphique montrant la relation entre request_time et http2_stream_id : une forte hausse du temps à des IDs de flux élevés indique des retards dans la file d’attente. Dans HTTP/3, cet effet ne se produit pas — chaque flux est traité indépendamment.

Lorsque vous effectuez des tests de charge avec wrk ou hey, spécifiez toujours les drapeaux -H "Connection: keep-alive" et -H "Accept-Encoding: gzip, br" ; sinon, les tests imiteront le comportement de HTTP/1.1. Pour HTTP/3, utilisez hey -h3 ou curl --http3.

Une erreur courante consiste à se fier uniquement à ab (ApacheBench) : il ne prend pas en charge HTTP/2 ni HTTP/3, donc les résultats seront biaisés.

— Editorial Team