Passer au contenu 
Je configure Apache mod_http2 de manière à ce que les performances HTTP/2 soient immédiatement effectives : négociation de protocole correcte, threads MPM adaptés et paramètres TLS bien configurés. Grâce à des valeurs de référence claires pour les flux, la taille des fenêtres et le Keep-Alive, j'obtiens une connexion stable Temps de chargement provenant de pages très fréquentées.
Points centraux
- Événement MPM mettre en place et dimensionner correctement le Keep-Alive
- Protocoles h2 http/1.1 avec ProtocolsHonorOrder activé
- H2WindowSize augmenter modérément et limiter les flux
- Travailleur contrôler via H2MinWorkers/H2MaxWorkers
- TLS/ALPN Optimiser et affiner la journalisation
Activer mod_http2 : principes de base et conditions préalables
Je commence par activer mod_http2 et la négociation du protocole. Le chargement du module s'effectue via LoadModule, puis je définis les protocoles h2 http/1.1 afin que HTTP/2 soit priorisé et que HTTP/1.1 continue d'être proposé. Pour la mise en production, je vérifie la validité de TLS, les suites de chiffrement actuelles ainsi que les anciennes versions désactivées telles que SSLv2/SSLv3. Sans TLS et ALPN correctement configurés, les navigateurs modernes ne tirent pas pleinement parti du protocole. Pour une forte simultanéité, je prévois le MPM à l’avance, car le prefork ralentit considérablement HTTP/2.
LoadModule http2_module modules/mod_http2.so
Protocols h2 http/1.1
Activer correctement HTTP/2 dans les VirtualHosts
J'active HTTP/2 de manière ciblée dans le vHost sur le port 443 et définis l'ordre de manière fixe. Je force ainsi Apache à proposer d'abord HTTP/2 et à ne basculer vers HTTP/1.1 qu'en cas de besoin. Un test rapide avec Curl confirme ce comportement avec „ HTTP/2 200 “. La directive Protocoles d'honneur Je le règle sur « On » afin que l'ordre des protocoles soit contraignant. Cela me permet d'obtenir une distribution claire et prévisible par hôte.
Protocols h2 http/1.1
ProtocolsHonorOrder On
SSLEngine on
# certificats, algorithmes de chiffrement, OCSP, etc.
Réglage fin du choix MPM et du Keep-Alive
Pour garantir une haute simultanéité, je mise sur mpm_event, car les threads et les événements gèrent efficacement un grand nombre de connexions. Je calcule les valeurs de StartServers, ThreadsPerChild et MaxRequestWorkers en fonction de la mémoire vive disponible, afin d’éviter tout risque de pagination. Pour HTTP/2, j’augmente la valeur de KeepAliveTimeout afin que les connexions persistantes disposent de suffisamment de temps pour plusieurs requêtes. Parallèlement, je limite la valeur de MaxKeepAliveRequests afin de libérer cycliquement des ressources. Si vous souhaitez approfondir les différences entre les MPM, vous trouverez des détails dans ma note sur MPM « event » vs « worker », qui facilite le choix dans la pratique.
Flux, multiplexage et contrôle de flux
Je contrôle des flux avec H2MaxSessionStreams pour empêcher un client de monopoliser trop de ressources. Des valeurs comprises entre 100 et 200 conviennent souvent bien, en fonction du nombre d'éléments et du comportement du backend. Pour optimiser le débit, je règle H2WindowSize et j’augmente modérément la taille de la fenêtre de flux, souvent à 256 Ko. Cela me permet de réduire les mises à jour de la fenêtre sans solliciter excessivement la mémoire. Si vous souhaitez comprendre le mécanisme, consultez mon article sur Multiplexage HTTP/2, qui explique clairement les priorités et les obstacles.
Threads de travail, délais d'attente et push
Je dimensionne H2MinWorkers et H2MaxWorkers en fonction du matériel et du MPM, afin que les pics de charge n’entraînent pas de pics de latence. De plus, je configure H2Timeout et H2KeepAliveTimeout de manière à ce que les sessions bloquées ne mobilisent pas inutilement les ressources pendant trop longtemps. Je désactive la directive H2Direct sur les sites publics, car h2c avec Prior Knowledge n’y joue pratiquement aucun rôle. En ce qui concerne le Push, je reste prudent et n’active H2Push qu’après des mesures rigoureuses. Dans de nombreuses configurations, une mise en cache efficace, les feuilles de style CSS critiques et les scripts asynchrones offrent la solution la plus fiable Accélération.
Configurer correctement les paramètres TLS, ALPN et les suites de chiffrement
Je n'active le TLS que dans le vHost HTTPS et je supprime les anciens Protocoles De manière cohérente. Pour une négociation propre, j’utilise ALPN afin que le client passe directement à HTTP/2 sans étapes supplémentaires. Une chaîne de certificats courte, l’OCSP Stapling et la reprise de session réduisent la surcharge lors de la poignée de main. Je gagne ainsi des millisecondes qui ont un impact notable sur le temps de chargement et le débit. Je donne plus de détails dans mon guide sur ALPN et HTTP/2 ensemble, afin que le choix des algorithmes de chiffrement et des options soit effectué avec précision.
Journalisation, tests et dépannage
Je relance LogLevel Pour HTTP/2, je commence par « info » afin d'observer l'établissement de la connexion, les flux et le contrôle de débit. Cela me permet de détecter rapidement les goulots d'étranglement et d'ajuster les paramètres progressivement. Avec curl, je vérifie les en-têtes, le protocole et les réponses du serveur directement depuis la console. Lors des tests de charge, je mesure les temps de réponse, le débit et les taux d’erreur séparément pour les routes statiques et dynamiques. Je documente chaque modification à l’aide de données de mesure afin de garantir la fiabilité des optimisations.
LogLevel http2:info
Test rapide # :
# curl -v --http2 -I https://example.com/
Exemple : configuration HTTP/2 compacte
Je vais vous montrer une Configuration, qui a fait ses preuves dans de nombreux projets et offre un point de départ clair. L'Event-MPM prend en charge un grand nombre de connexions simultanées sans saturer les processus. Les directives HTTP/2 limitent les flux, augmentent modérément la fenêtre et maintiennent un nombre suffisant de workers disponibles. Keep-Alive reste généreux, mais MaxKeepAliveRequests assure une libération cyclique. Le réglage fin dépend de la mémoire vive, du processeur, de la pile d’applications et du profil de trafic ; c’est pourquoi je procède à de nouvelles mesures après chaque modification.
Événement MPM #
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 1000
Noyau HTTP/2 #
Protocols h2 http/1.1
ProtocolsHonorOrder On
Réglage mod_http2 #
H2MaxSessionStreams 150
H2WindowSize 262144
H2MinWorkers 10
H2MaxWorkers 75
H2KeepAliveTimeout 30
H2Timeout 60
# H2Push désactivé Laisser # en option
# TLS (exemple)
SSLProtocol all -SSLv2 -SSLv3
# Choisir une suite de chiffrement SSL moderne et compatible avec les navigateurs
# Activer l'OCSP Stapling / la reprise de session
Tableau des valeurs indicatives pour l'optimisation de mod_http2
Je l'utilise Valeurs indicatives Commencez par ces valeurs, puis ajustez-les en fonction des mesures du trafic, du matériel et de l'application. Le tableau récapitule les valeurs de départ types et les fourchettes recommandées. Des fenêtres ou des nombres de flux trop élevés consomment de la mémoire vive, tandis que des valeurs trop faibles limitent le débit. Tout l’art réside dans l’équilibre entre MaxRequestWorkers et la capacité du backend. Je teste chaque niveau séparément afin d’identifier clairement les causes et les effets.
| Directive/Paramètre | valeur initiale | Plage de réglage | Remarque |
|---|---|---|---|
| H2MaxSessionStreams | 100 | 120–200 | Pas plus que ne le permet le budget alloué aux travailleurs |
| H2WindowSize | 65535 B | 256 Ko – 1 Mo | Plus grand = moins de mises à jour Windows, mais plus de RAM |
| H2MinWorkers | 10 | 10–25 | Les petits systèmes assurent la charge de base |
| H2MaxWorkers | 50 | 50–75+ | Amortir les pics de charge, surveiller la mémoire RAM |
| KeepAliveTimeout | 15 s | 20 à 30 s | HTTP/2 tire parti de connexions plus longues |
| MaxKeepAliveRequests | 100 | 100–500 | Partager régulièrement des ressources |
| Événement MPM : MaxRequestWorkers | 150 | 150–300 | Établir un devis en fonction du budget RAM |
Tests de charge réalistes et stratégie de mesure
Je vérifie Temps de réponse séparément pour le HTML, les ressources statiques et les routes API dynamiques. J’évalue ensuite le débit et les taux d’erreur à mesure que la charge simultanée augmente, afin d’identifier les points de rupture. J’ajuste ensuite progressivement la taille de la fenêtre H2 (H2WindowSize), les flux (Streams) et le Keep-Alive, puis je compare les tests A/B. De plus, je surveille l’utilisation du processeur, de la mémoire vive, du réseau et les temps de handshake TLS afin qu’aucun déplacement du goulot d’étranglement ne passe inaperçu. Je parviens ainsi à une configuration adaptée à l’application et disposant de réserves pour les pics de trafic.
Prendre en compte l'infrastructure et la configuration de l'hébergement
Je mise sur l'actualité Apache- Des versions à jour, une pile TLS bien entretenue et du matériel performant, pour que les réglages optimisation portent leurs fruits. Pour les grandes boutiques en ligne et les portails WordPress, il est préférable de choisir un hébergeur proposant par défaut Event-MPM, HTTP/2 et une gestion rapide des certificats. Lors de tests de performance, webhoster.de s’est révélé être une référence fiable pour ce type de configurations. J’y combine des configurations modernes avec une assistance technique compétente. Cette base me permet de tester plus rapidement les paramètres de référence et de les intégrer proprement dans l’environnement de production.
HTTP/2 derrière des équilibreurs de charge et en tant que proxy inverse
Je vérifie s'il y a un Équilibreur de charge ou via un CDN. L'essentiel est que le protocole ALPN soit correctement négocié et que HTTP/2 reste actif jusqu'à la périphérie. Derrière une terminaison TLS, Apache, en tant que backend, ne peut toujours voir que HTTP/1.1 – ce qui n'est pas un problème tant que le client est servi via h2 jusqu'à la périphérie. Si j'exploite moi-même Apache en tant que Proxy inverse vers les serveurs en amont (par exemple, les serveurs d'applications), je décide délibérément si je souhaite également utiliser HTTP/2 à J'utilise un backend. Pour de nombreux backends, HTTP/1.1 est suffisant et permet une bonne mesurabilité ; pour les services lents ou éloignés, HTTP/2 peut réduire la latence en amont grâce au multiplexage. Il est important que j’équilibre les budgets de concurrence entre le front-end, la couche proxy et le backend, sinon le goulot d’étranglement ne fera que se déplacer d’un niveau plus haut.
PHP-FPM, serveurs d'applications et budgets de concurrence
Je vote MaxRequestWorkers dans Apache, cela dépend du nombre de processus/threads au niveau de la couche applicative (par exemple, pm.max_children pour PHP-FPM, nombre de workers pour Node/Java). HTTP/2 permet d’ouvrir de nombreux flux simultanés par connexion. Si le serveur web accepte nettement plus de requêtes simultanées que le backend ne peut en traiter en parallèle, les files d’attente et les latences augmentent. Je dimensionne donc les paramètres H2MaxSessionStreams, MaxRequestWorkers et les workers du backend de manière à ce que le gain de multiplexage ne soit pas gâché par un blocage du backend. Pour les pages dynamiques, je fixe une limite maximale stricte, tandis que je serve les ressources statiques de manière intensive à partir du cache.
Optimisation des en-têtes, HPACK et stratégie de gestion des ressources
HTTP/2 compresse les en-têtes à l'aide de HPACK. Néanmoins, les en-têtes de cookies volumineux, les chaînes User-Agent surchargées ou les nombreux en-têtes personnalisés inutiles mobilisent des ressources CPU et mémoire. Je simplifie les cookies, je régule les domaines/sous-domaines Set-Cookie et je ne regroupe que ce qui est vraiment nécessaire. Côté diffusion, je définis des en-têtes de cache, des ETags ou des Last-Modified corrects, ainsi qu’une versionnage clair des ressources. Sous HTTP/2, je relativise le partitionnement par domaine et le regroupement artificiel : grâce au multiplexage, les nombreux petits fichiers ne posent plus de problème – tant que le backend suit le rythme. Je veille à maintenir l’équilibre : un nombre trop élevé de requêtes par page augmente la charge de planification ; des paquets trop volumineux réduisent les coups de cache et bloquent le rendu.
Compression, tailles et formats de réponse
Pour les ressources textuelles, j'utilise des outils efficaces Compression (gzip ou brotli) et je veille à définir des tailles minimales raisonnables afin d’éviter que chaque fichier, aussi petit soit-il, ne soit compressé. Sous HTTP/2, les ressources compressées et de petite taille restent performantes, car elles sont diffusées en parallèle. Parallèlement, je réduis au minimum les réponses HTML trop volumineuses, car elles pèsent lourdement sur le temps de réponse « First Byte ». Je fournis les images dans des formats et des tailles adaptés ; j’évite les réencodages inutiles ou les conversions côté serveur directement dans le chemin de requête afin de lisser les pics d’activité du processeur.
Exploitation, limites et planification des ressources
Je prévois suffisamment Descripteurs de fichiers et des limites de processus afin d’éviter que de nombreuses connexions simultanées ne soient bloquées par les limites d’`ulimit`. Le MPM Event maintient efficacement les connexions ouvertes, mais chaque connexion occupe un peu de mémoire. Je détermine la somme de MaxRequestWorkers, de la fenêtre Keep-Alive et de H2MaxSessionStreams de manière à ce que le système dans son ensemble ne bascule pas en swap lors des pics de charge. Pour les déploiements progressifs, j'opte pour graceful Rechargements ; MaxConnectionsPerChild permet de renouveler les processus et d'éviter les fuites insidieuses. Je mesure régulièrement l'empreinte mémoire des workers et j'ajuste leur durée de vie en conséquence.
Exemples de dysfonctionnements rencontrés dans la pratique et diagnostic ciblé
Je connais les cas typiques Images d'erreurs HTTP/2: La présence de nombreux frames GOAWAY indique des ruptures de connexion ou des limites strictes. Une accumulation de frames RST_STREAM peut indiquer des délais d'attente dépassés, des interruptions de requêtes par le client ou des erreurs en amont. Si je constate une augmentation des codes d'erreur 4xx/5xx lors des tests de charge, je vérifie d'abord les backends et les bases de données avant de modifier les paramètres de Windows ou des flux. Pour le diagnostic, j'augmente temporairement le niveau de journalisation http2 à « debug », j'isole les chemins présentant un comportement suspect et j'effectue des mesures à l'aide d'outils compatibles h2. Important : je ne modifie jamais que a Un paramètre à ajuster par cycle de test, afin que la relation de cause à effet reste claire.
Signaux précoces, incitations et hiérarchisation au quotidien
Je mise sur Early Hints (103) comme une légère piste d'indication avant d'envisager le Push HTTP/2. Les « Early Hints » donnent au navigateur une longueur d'avance pour le chargement des ressources critiques, sans dupliquer ces ressources de manière permanente. Le Push reste ciblé et fondé sur des mesures, par exemple pour de très petits extraits de CSS immuables ou des polices, lorsque les métriques démontrent son utilité. Pour la hiérarchisation, je m’appuie avant tout sur un ordre HTML clair, des indications de préchargement et une stratégie claire de « chemin critique » de l’application – cela s’harmonise parfaitement avec les navigateurs modernes.
Délais d'expiration, tentatives de reconnexion et expérience utilisateur
Je calibre Timeouts de manière à ce que les clients légitimes mais lents ne soient pas déconnectés trop tôt, tandis que les flux bloqués sont rapidement supprimés. Je complète les paramètres H2Timeout et H2KeepAliveTimeout par des délais d’expiration adaptés au niveau du proxy et du backend, afin d’éviter toute contradiction dans les critères d’interruption. Lors du réglage, je veille à ce que les tentatives de reconnexion (client ou proxy) ne se multiplient pas en cascade, sous peine de générer plus de charge que d’avantages. L’objectif est d’obtenir des temps de chargement mesurables satisfaisants, et non une concurrence brute maximale à tout prix.
Sécurité, optimisation du protocole TLS et stabilité
Je considère que la pile TLS mince: chaînes courtes, OCSP cumulatif, reprise de session et algorithmes de chiffrement modernes utilisant l'ECDHE. La renégociation est proscrite ; je limite délibérément la taille des en-têtes (par exemple pour les cookies). Cela contribue à la stabilité et à la prévisibilité, car je minimise la surcharge lors de la poignée de main. Pour répondre aux exigences de conformité, je planifie la durée de vie des tickets, les caches de session et les suites de chiffrement de manière à trouver un juste équilibre entre sécurité et performances. Je justifie les modifications par des données de mesure recueillies auprès de la clientèle cible, et pas uniquement en conditions de laboratoire.
Suivi, indicateurs et optimisation continue
J'observe au travail Part h2, les distributions de latence (p50/p95/p99), les taux d'erreur, les connexions ouvertes et la consommation de RAM par processus. Mod_status et les métriques externes indiquent si les fenêtres Keep-Alive et les flux sont correctement dimensionnés. Si les latences p95 varient, je vérifie d'abord le backend et les chemins réseau, puis seulement les fenêtres/flux. Je vérifie également les temps de handshake TLS ; s’ils augmentent, le goulot d’étranglement se situe souvent en amont d’Apache (état du certificat, entropie, cryptographie matérielle). Grâce à ce cycle de rétroaction, je maintiens la configuration proche de la réalité et je l’adapte aux modèles de trafic et aux nouvelles versions.
Aspects liés à la mise à niveau et à la compatibilité
Je prévois mises à jour régulières d'Apache et de mod_http2, car les améliorations en matière de stabilité, de contrôle du flux et de gestion des erreurs peuvent être directement mesurables. Avant toute mise à niveau, je réalise des tests sous charge avec des données représentatives et je compare les courbes à celles de l'environnement de production. En présence de populations de clients hétérogènes (navigateurs anciens, bots, appareils), je laisse volontairement HTTP/1.1 actif comme solution de secours, mais je vérifie si les bots établissent un nombre excessif de connexions et mobilisent ainsi les workers. Dans ces cas-là, je fixe des limites ou je sépare le trafic afin que utilisateurs réels ont la priorité.
Piste de développement et modèles d'exploitation
Je définis un trajectoire de mise à l'échelle: verticalement (plus de RAM/CPU, des pools de workers plus importants) ou horizontalement (plus de front-ends derrière un équilibreur de charge). HTTP/2 s'adapte bien à l'évolutivité horizontale tant que l'affinité de session n'est pas obligatoire. Pour les composants avec état (par exemple, les sessions côté serveur), je détermine le nombre raisonnable de flux parallèles par nœud et si j'ai réellement besoin de sessions persistantes. Cela me permet d'éviter qu'un nœud ne soit surchargé de manière disproportionnée par un trop grand nombre de flux de longue durée, tandis que d'autres restent inactifs.
Mon bref résumé
J'active HTTP/2 Dans le vHost, sélectionnez Event-MPM, augmentez la valeur Keep-Alive et configurez clairement les protocoles. Ensuite, je calibre les flux, la taille des fenêtres et le nombre de workers de manière à ce que la RAM et le CPU restent équilibrés. Le TLS avec ALPN, des chaînes courtes et la reprise de connexion permet de gagner de précieuses millisecondes lors de l’établissement de la connexion. La journalisation sur http2:info et les tests de charge systématiques permettent de justifier chaque modification de manière traçable. Ainsi, les performances s'améliorent progressivement et les utilisateurs bénéficient de pages rapides sans interruption.
