Passer au contenu 
Ich konfiguriere Apache mod_http2 so, dass die HTTP2 Performance sofort greift: korrekte Protokollverhandlung, passende MPM‑Threads und saubere TLS‑Settings. Mit klaren Richtwerten für Streams, Fenstergrößen und Keep‑Alive hole ich stabile Temps de chargement aus stark frequentierten Seiten.
Points centraux
- MPM-Event einsetzen und Keep‑Alive passend dimensionieren
- Protocols h2 http/1.1 mit ProtocolsHonorOrder On
- H2WindowSize moderat erhöhen und Streams limitieren
- Travailleur über H2MinWorkers/H2MaxWorkers steuern
- TLS/ALPN optimieren und Logging schärfen
mod_http2 aktivieren: Grundlagen und Voraussetzungen
Je commence par activer mod_http2 und der Protokoll-Aushandlung. Der Modul‑Load erfolgt über LoadModule, danach setze ich Protocols h2 http/1.1, damit HTTP/2 priorisiert und HTTP/1.1 weiter angeboten wird. Für produktive Auslieferung prüfe ich gültiges TLS, aktuelle Cipher Suites sowie deaktivierte Altfälle wie SSLv2/SSLv3. Ohne sauberes TLS und ALPN schöpfen moderne Browser das Protokoll nicht aus. Für hohe Gleichzeitigkeit plane ich das MPM im Vorfeld, denn prefork bremst HTTP/2 hart aus.
LoadModule http2_module modules/mod_http2.so
Protocols h2 http/1.1
HTTP/2 in VirtualHosts sauber einschalten
Ich aktiviere HTTP/2 gezielt im vHost auf Port 443 und stelle die Reihenfolge fest ein. So erzwinge ich, dass Apache zuerst HTTP/2 anbietet und nur bei Bedarf auf HTTP/1.1 fällt. Ein schneller Curl‑Check bestätigt das Verhalten mit „HTTP/2 200“. Die Direktive ProtocolsHonorOrder setze ich auf On, damit die Reihenfolge der Protokolle bindend ist. Damit erreiche ich eine klare, vorhersehbare Auslieferung pro Host.
<VirtualHost *:443>
Protocols h2 http/1.1
ProtocolsHonorOrder On
SSLEngine on
# Zertifikate, Cipher, OCSP etc.
</VirtualHost>
MPM-Wahl und Keep-Alive fein abstimmen
Ich setze für hohe Gleichzeitigkeit auf mpm_event, weil Threads und Events viele Verbindungen effizient handhaben. Die Werte für StartServers, ThreadsPerChild und MaxRequestWorkers rechne ich gegen RAM‑Budget, damit keine Auslagerung droht. Für HTTP/2 hebe ich das KeepAliveTimeout an, damit persistente Verbindungen genügend Zeit für mehrere Requests haben. Gleichzeitig begrenze ich MaxKeepAliveRequests, um Ressourcen zyklisch frei zu geben. Wer den Unterschied der MPMs vertiefen will, findet Details in meinem Hinweis zu event vs worker MPM, der die Wahl praxisnah erleichtert.
Streams, Multiplexing und Flow-Control
Ich steuere parallele flux mit H2MaxSessionStreams und verhindere, dass ein Client zu viele Ressourcen bindet. Werte zwischen 100 und 200 passen oft gut, abhängig von Asset‑Zahl und Backend‑Verhalten. Für den Durchsatz drehe ich an H2WindowSize und erhöhe das Flussfenster moderat, häufig auf 256 KB. So reduziere ich Window‑Updates, ohne den Speicher über Gebühr zu beanspruchen. Wer die Wirkmechanik verstehen will, schaut in meinen Beitrag zu Multiplexage HTTP/2, der Prioritäten und Blockaden anschaulich erklärt.
Worker-Threads, Timeouts und Push
Je dimensionne H2MinWorkers und H2MaxWorkers passend zur Hardware und zum MPM, damit Lastspitzen nicht zu Latenzspitzen führen. Zusätzlich setze ich H2Timeout und H2KeepAliveTimeout so, dass hängende Sessions nicht unnötig lange Ressourcen binden. Die Direktive H2Direct lasse ich auf Public‑Sites aus, denn h2c mit Prior Knowledge spielt dort kaum eine Rolle. Beim Thema Push bleibe ich konservativ und schalte H2Push nur nach harten Messungen ein. In vielen Setups liefern sauberes Caching, kritisches CSS und asynchrone Skripte die verlässlichere Accélération.
TLS, ALPN und Cipher Suites richtig einstellen
Ich aktiviere TLS nur im HTTPS‑vHost und streiche alte Protocoles konsequent. Für saubere Aushandlung nutze ich ALPN, damit der Client ohne Extra‑Runden direkt auf HTTP/2 wechselt. Eine kurze Zertifikatskette, OCSP‑Stapling und Session‑Resumption verringern den Overhead beim Handshake. So spare ich Millisekunden, die auf Ladezeit und Durchsatz spürbar wirken. Mehr Hintergründe fasse ich in meinem Leitfaden zu ALPN und HTTP/2 zusammen, damit die Auswahl der Cipher und Optionen zielgenau erfolgt.
Logging, Tests und Fehlersuche
Je relance LogLevel für http2 zunächst auf info, um Aufbau, Streams und Flow‑Control zu beobachten. So erkenne ich Engpässe früh und kann Werte Schritt für Schritt nachziehen. Mit curl prüfe ich Header, Protokoll und Serverantworten direkt von der Konsole. In Lasttests messe ich Antwortzeiten, Durchsatz und Fehlerraten getrennt für statische und dynamische Routen. Jede Änderung belege ich mit Messdaten, damit Optimierungen verlässlich tragen.
<IfModule http2_module>
LogLevel http2:info
</IfModule>
# Kurztest:
# curl -v --http2 -I https://example.com/
Beispiel: Kompakte HTTP/2-Konfiguration
Ich zeige eine Configuration, die sich in vielen Projekten bewährt hat und einen sauberen Startpunkt liefert. Das Event‑MPM deckt viele gleichzeitige Verbindungen ab, ohne Prozesse zu fluten. Die HTTP/2‑Direktiven begrenzen Streams, erhöhen das Fenster moderat und halten genug Worker bereit. Keep‑Alive bleibt großzügig, doch MaxKeepAliveRequests sorgt für zyklische Freigabe. Feintuning hängt von RAM, CPU, App‑Stack und Trafficprofil ab, daher messe ich nach jeder Änderung erneut.
# MPM event
<IfModule mpm_event_module>
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 1000
</IfModule>
# HTTP/2 Kern
Protocols h2 http/1.1
ProtocolsHonorOrder On
# mod_http2 Tuning
H2MaxSessionStreams 150
H2WindowSize 262144
H2MinWorkers 10
H2MaxWorkers 75
H2KeepAliveTimeout 30
H2Timeout 60
# H2Push off # optional lassen
# TLS (Beispiel)
SSLProtocol all -SSLv2 -SSLv3
# SSLCipherSuite modern und browser-kompatibel wählen
# OCSP Stapling / Session Resumption aktivieren
Richtwerte-Tabelle für mod_http2-Tuning
Je l'utilise Valeurs indicatives als Start und passe sie nach Messungen an Traffic, Hardware und App an. Die Tabelle fasst typische Startwerte und sinnvolle Korridore zusammen. Zu große Fenster oder Stream‑Zahlen kosten RAM, zu kleine drosseln den Durchsatz. Die Kunst liegt im Abgleich mit MaxRequestWorkers und Backend‑Kapazität. Ich teste jede Stufe separat, um Ursache und Wirkung klar zu sehen.
| 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é
Ich halte den TLS‑Stack mince: kurze Ketten, stapelndes OCSP, Session Resumption und moderne Cipher mit ECDHE. Renegotiation ist tabu, Header‑Übergrößen begrenze ich bewusst (z. B. für Cookies). Das zahlt auf Stabilität und Planbarkeit ein, weil ich den Overhead beim Handshake minimiere. Für Compliance‑Anforderungen plane ich Ticket‑Lebenszeiten, Session‑Caches und Cipher‑Suiten so, dass sie sowohl Sicherheit als auch Performance vernünftig balancieren. Änderungen belege ich mit Messdaten auf dem Ziel‑Klientel, nicht nur in Laborsituationen.
Monitoring, Metriken und kontinuierliche Optimierung
Ich beobachte im Betrieb h2‑Anteil, Latenzverteilungen (p50/p95/p99), Fehlerraten, offene Verbindungen und RAM‑Verbrauch pro Prozess. Mod_status und externe Metriken zeigen, ob Keep‑Alive‑Fenster und Streams richtig dimensioniert sind. Driften p95‑Latenzen, prüfe ich zuerst Backend und Netzpfade, dann erst Fenster/Streams. Zusätzlich schaue ich auf TLS‑Handshake‑Zeiten; steigen sie, liegt die Bremse oft vor Apache (Zertifikatsstatus, Entropie, Hardware‑Crypto). Mit diesem Feedback‑Kreislauf halte ich die Konfiguration nah an der Realität und passe sie an Traffic‑Muster und Releases an.
Upgrade- und Kompatibilitätsaspekte
Je prévois mises à jour régulières von Apache und mod_http2 ein, da Verbesserungen bei Stabilität, Flow‑Control und Fehlerbehandlung direkt messbar sein können. Vor Upgrades teste ich unter Last mit repräsentativen Daten und vergleiche die Kurven zu Produktion. Bei gemischten Client‑Populationen (ältere Browser, Bots, Geräte) lasse ich HTTP/1.1 bewusst als Fallback aktiv, prüfe jedoch, ob Bots übermäßig viele Verbindungen anlegen und damit Worker binden. Für diese Fälle setze ich Limits oder separiere Traffic, damit echte Nutzer Vorrang haben.
Skalierungspfad und Betriebsmodelle
Ich definiere einen Skalierungspfad: vertikal (mehr RAM/CPU, größere Worker‑Pools) oder horizontal (mehr Frontends hinter einem Loadbalancer). HTTP/2 skaliert gut horizontal, solange Session‑Affinity nicht zwingend ist. Für stateful Komponenten (z. B. Server‑seitige Sessions) plane ich ein, wie viele parallele Streams pro Node sinnvoll sind und ob ich Sticky Sessions wirklich brauche. Damit vermeide ich, dass ein Knoten durch zu viele langlaufende Streams überproportional belastet wird, während andere sich langweilen.
Mon bref résumé
J'active HTTP/2 gezielt im vHost, wähle Event‑MPM, erhöhe Keep‑Alive und stelle Protokolle klar ein. Danach kalibriere ich Streams, Fenstergrößen und Worker so, dass RAM und CPU im Lot bleiben. TLS mit ALPN, kurzen Ketten und Resumption spart wertvolle Millisekunden beim Aufbau. Logging auf http2:info und systematische Lasttests belegen jede Änderung nachvollziehbar. So wächst die Leistung Schritt für Schritt, und Nutzer erleben schnelle Seiten ohne Brüche.
