Zum Inhalt springen 
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 Ladezeiten aus stark frequentierten Seiten.
Zentrale Punkte
- MPM-Event einsetzen und Keep‑Alive passend dimensionieren
- Protocols h2 http/1.1 mit ProtocolsHonorOrder On
- H2WindowSize moderat erhöhen und Streams limitieren
- Worker über H2MinWorkers/H2MaxWorkers steuern
- TLS/ALPN optimieren und Logging schärfen
mod_http2 aktivieren: Grundlagen und Voraussetzungen
Ich starte mit der Aktivierung von 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 Streams 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 HTTP/2 Multiplexing, der Prioritäten und Blockaden anschaulich erklärt.
Worker-Threads, Timeouts und Push
Ich dimensioniere 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 Beschleunigung.
TLS, ALPN und Cipher Suites richtig einstellen
Ich aktiviere TLS nur im HTTPS‑vHost und streiche alte Protokolle 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
Ich erhöhe das 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 Konfiguration, 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
Ich nutze diese Richtwerte 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.
| Direktive/Setting | Startwert | Tuning-Korridor | Hinweis |
|---|---|---|---|
| H2MaxSessionStreams | 100 | 120–200 | Nicht höher als das Worker‑Budget zulässt |
| H2WindowSize | 65535 B | 256 KB – 1 MB | Größer = weniger Window‑Updates, aber mehr RAM |
| H2MinWorkers | 10 | 10–25 | Kleine Systeme halten Grundlast bereit |
| H2MaxWorkers | 50 | 50–75+ | Lastspitzen abfedern, RAM im Blick behalten |
| KeepAliveTimeout | 15 s | 20–30 s | HTTP/2 profitiert von längeren Verbindungen |
| MaxKeepAliveRequests | 100 | 100–500 | Ressourcen regelmäßig freigeben |
| MPM event: MaxRequestWorkers | 150 | 150–300 | Gegen RAM‑Budget kalkulieren |
Realistische Lasttests und Messstrategie
Ich prüfe Antwortzeiten getrennt für HTML, statische Assets und dynamische API‑Routen. Anschließend bewerte ich Durchsatz und Fehlerraten bei wachsender Gleichzeitigkeit, um die Knickpunkte zu finden. Dann justiere ich H2WindowSize, Streams und Keep‑Alive schrittweise und vergleiche A/B‑Runs. Zusätzlich beobachte ich CPU, RAM, Netzwerk und TLS‑Handshake‑Zeiten, damit keine Verschiebung des Engpasses unentdeckt bleibt. So erreiche ich eine Konfiguration, die zur Applikation passt und Reserven für Spitzen hat.
Infrastruktur und Hosting-Setup mitdenken
Ich setze auf aktuelle Apache-Versionen, gepflegten TLS‑Stack und performante Hardware, damit Tuning‑Schrauben Wirkung zeigen. Für große Shops und WordPress‑Portale lohnt sich ein Anbieter, der Event‑MPM, HTTP/2 und zügige Zertifikatspflege standardmäßig anbietet. In Benchmarks hat sich webhoster.de für solche Setups als verlässliche Adresse gezeigt. Dort kombiniere ich moderne Konfigurationen mit fachkundigem Support. Diese Basis erlaubt mir, Richtwerte schneller zu verproben und sauber in den Betrieb zu tragen.
HTTP/2 hinter Loadbalancern und als Reverse Proxy
Ich prüfe, ob vor Apache ein Loadbalancer oder CDN terminiert. Entscheidend ist, dass ALPN korrekt ausgehandelt und HTTP/2 bis zur Edge aktiv bleibt. Hinter einer TLS‑Terminierung kann Apache als Backend weiterhin nur HTTP/1.1 sehen – das ist in Ordnung, solange der Client zur Edge per h2 bedient wird. Betreibe ich Apache selbst als Reverse Proxy zu Upstreams (z. B. App‑Servern), entscheide ich bewusst, ob ich HTTP/2 auch zum Backend nutze. Für viele Backends reicht HTTP/1.1 stabil und gut messbar; bei latenten oder weit entfernten Diensten kann HTTP/2 zum Upstream die Latenz durch Multiplexing senken. Wichtig ist, dass ich die Concurrency‑Budgets zwischen Frontend, Proxy‑Schicht und Backend abstimme, sonst wandert der Engpass nur eine Ebene weiter.
PHP‑FPM, App‑Server und Concurrency-Budgets
Ich stimme MaxRequestWorkers am Apache mit der Prozess/Thread‑Zahl im App‑Layer ab (z. B. pm.max_children bei PHP‑FPM, Worker‑Anzahl bei Node/Java). HTTP/2 kann pro Verbindung viele gleichzeitige Streams eröffnen. Wenn der Webserver deutlich mehr gleichzeitige Anfragen annimmt, als das Backend parallel abarbeiten kann, steigen Warteschlangen und Latenzen. Ich dimensioniere daher H2MaxSessionStreams, MaxRequestWorkers und die Backend‑Worker so, dass der Multiplex‑Gewinn nicht in Backend‑Blocking verpufft. Für dynamische Seiten lege ich eine harte Obergrenze fest, während ich statische Assets aggressiv aus dem Cache bediene.
Header-Ökonomie, HPACK und Asset-Strategie
HTTP/2 komprimiert Header mit HPACK. Dennoch kosten große Cookie‑Header, aufgeblähte User‑Agent‑Strings oder viele unnötige Custom‑Header CPU und Speicher. Ich entschlackle Cookies, reguliere Set‑Cookie‑Domains/Subdomains und bündele nur das, was wirklich gebraucht wird. Auf der Auslieferungsseite setze ich korrekte Cache‑Header, ETags oder Last‑Modified plus eine klare Versionierung der Assets. Unter HTTP/2 relativiere ich Domain‑Sharding und künstliches Bundling: Viele kleine Dateien sind dank Multiplexing kein Problem mehr – solange das Backend mithält. Ich behalte die Balance im Blick: Zu viele Requests pro Seite erhöhen Scheduling‑Overhead; zu große Bündel schmälern Cache‑Treffer und blockieren das Rendern.
Kompression, Größen und Response-Formate
Ich nutze für Textressourcen effiziente Kompression (gzip oder brotli) und achte auf sinnvolle Mindestgrößen, damit nicht jede winzige Datei komprimiert wird. Unter HTTP/2 bleiben komprimierte, kleinteilige Ressourcen performant, weil sie parallel gestreamt werden. Gleichzeitig minimiere ich übergroße HTML‑Antworten, da sie die First Byte‑Zeit dominieren. Bilder bediene ich in passenden Formaten und Größen; unnötige Re‑Encodes oder Server‑seitige Konvertierungen direkt im Requestpfad vermeide ich, um CPU‑Spitzen zu glätten.
Betrieb, Limits und Ressourcenplanung
Ich plane ausreichend Dateideskriptoren und Prozesslimits ein, damit viele gleichzeitige Verbindungen nicht an ulimit‑Grenzen scheitern. Das Event‑MPM hält Verbindungen effizient offen, doch jede Verbindung belegt etwas Speicher. Die Summe aus MaxRequestWorkers, Keep‑Alive‑Fenster und H2MaxSessionStreams bestimme ich so, dass das Gesamtsystem bei Lastspitzen nicht in Swap rutscht. Für Rolling‑Deploys setze ich auf graceful Reloads; MaxConnectionsPerChild hält Prozesse frisch und verhindert schleichende Lecks. Ich messe regelmäßig Heap‑Footprints der Worker und justiere die Lebensdauer entsprechend.
Fehlerbilder aus der Praxis und zielgerichtete Diagnose
Ich kenne typische HTTP/2‑Fehlerbilder: Viele GOAWAY‑Frames deuten auf Verbindungsabbrüche oder harte Limits hin. RST_STREAM‑Häufungen können auf Timeouts, Request‑Abbrüche durch den Client oder Upstream‑Fehler hindeuten. Sehe ich vermehrt 4xx/5xx in Lasttests, prüfe ich zuerst Backends und Datenbanken, bevor ich am Window oder den Streams drehe. Für die Diagnose erhöhe ich vorübergehend LogLevel http2 auf debug, isoliere Pfade mit auffälligem Verhalten und messe mit h2‑fähigen Tools. Wichtig: Ich ändere immer nur eine Stellschraube pro Testlauf, damit Ursache und Wirkung transparent bleiben.
Early Hints, Push und Priorisierung im Alltag
Ich setze auf Early Hints (103) als leichten Hinweis‑Pfad, bevor ich HTTP/2 Push erwäge. Early Hints geben dem Browser einen Vorsprung zum Laden kritischer Ressourcen, ohne Ressourcen dauerhaft zu duplizieren. Push bleibt gezielt und messgetrieben, etwa für sehr kleine, unveränderliche CSS‑Snippets oder Fonts, wenn der Nutzen in Metriken belegt ist. Für Priorisierung verlasse ich mich in erster Linie auf saubere HTML‑Reihenfolge, Preload‑Hinweise und eine klare Kritischer‑Pfad‑Strategie der Anwendung – das harmoniert robust mit modernen Browsern.
Timeouts, Retries und Benutzererlebnis
Ich kalibriere Timeouts so, dass legitime, aber langsame Clients nicht zu früh abgehängt werden, während hängende Streams zügig aufgeräumt werden. H2Timeout und H2KeepAliveTimeout stütze ich mit passenden Proxy‑ und Backend‑Timeouts, damit es keine widersprüchlichen Abbruchkriterien gibt. Beim Tuning achte ich darauf, dass Retries (Client oder Proxy) nicht kaskadieren – sonst entsteht mehr Last als Nutzen. Messbar gute Ladezeiten sind das Ziel, nicht maximale Roh‑Concurrency um jeden Preis.
Sicherheit, TLS-Feinschliff und Stabilität
Ich halte den TLS‑Stack schlank: 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
Ich plane regelmäßige Updates 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.
Mein Kurz-Resümee
Ich aktiviere 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.
