Ga naar de inhoud 
Ik stel Apache in mod_http2 zodat de HTTP/2-prestaties onmiddellijk merkbaar zijn: correcte protocolonderhandelingen, geschikte MPM-threads en correcte TLS-instellingen. Met duidelijke richtlijnen voor streams, venstergroottes en Keep-Alive zorg ik voor stabiele Laadtijden van drukbezochte pagina’s.
Centrale punten
- MPM-evenement invoeren en Keep-Alive op de juiste manier instellen
- Protocollen h2 http/1.1 met ProtocolsHonorOrder ingeschakeld
- H2WindowSize gematigd verhogen en streams beperken
- Werknemer instellen via H2MinWorkers/H2MaxWorkers
- TLS/ALPN optimaliseren en de logboekregistratie verfijnen
mod_http2 inschakelen: basisprincipes en vereisten
Ik begin met de activering van mod_http2 en de protocolonderhandelingen. De module wordt geladen via LoadModule, waarna ik Protocols h2 http/1.1 instel, zodat HTTP/2 voorrang krijgt en HTTP/1.1 nog steeds wordt aangeboden. Voor de productieve omgeving controleer ik of het geldig is TLS, actuele cipher suites en uitgeschakelde verouderde versies zoals SSLv2/SSLv3. Zonder een goed werkende TLS en ALPN kunnen moderne browsers het protocol niet optimaal benutten. Voor een hoge gelijktijdigheid plan ik de MPM van tevoren, want prefork remt HTTP/2 flink af.
LoadModule http2_module modules/mod_http2.so
Protocols h2 http/1.1
HTTP/2 netjes inschakelen in VirtualHosts
Ik schakel HTTP/2 specifiek in in de vHost op poort 443 en stel de volgorde vast. Zo zorg ik ervoor dat Apache eerst HTTP/2 aanbiedt en alleen indien nodig terugvalt op HTTP/1.1. Een snelle Curl-check bevestigt dit gedrag met „HTTP/2 200“. De richtlijn ProtocollenEreorde Ik zet deze op ‘Aan’, zodat de volgorde van de logbestanden vastligt. Zo zorg ik voor een duidelijke, voorspelbare aflevering per host.
Protocols h2 http/1.1
ProtocolsHonorOrder On
SSLEngine on
# certificaten, cipher, OCSP enz.
MPM-selectie en Keep-Alive nauwkeurig afstemmen
Voor een hoge mate van gelijktijdigheid vertrouw ik op mpm_gebeurtenis, omdat threads en events een groot aantal verbindingen efficiënt kunnen verwerken. Ik stem de waarden voor StartServers, ThreadsPerChild en MaxRequestWorkers af op het beschikbare RAM-geheugen, zodat er geen risico op paginering ontstaat. Voor HTTP/2 verhoog ik de KeepAliveTimeout, zodat persistente verbindingen voldoende tijd hebben voor meerdere verzoeken. Tegelijkertijd beperk ik MaxKeepAliveRequests om resources cyclisch vrij te maken. Wie zich verder wil verdiepen in het verschil tussen de MPM’s, vindt details in mijn opmerking over event versus worker MPM, die de keuze in de praktijk vergemakkelijkt.
Streams, multiplexing en flowcontrole
Ik stuur parallelle Streams met H2MaxSessionStreams en voorkom dat een client te veel bronnen in beslag neemt. Waarden tussen 100 en 200 werken vaak goed, afhankelijk van het aantal assets en het gedrag van de backend. Voor de doorvoer pas ik H2WindowSize aan en vergroot ik het stroomvenster gematigd, vaak tot 256 KB. Zo verminder ik vensterupdates zonder het geheugen onnodig te belasten. Wie de werking hiervan wil begrijpen, kan mijn artikel over HTTP/2-multiplexing, waarin prioriteiten en knelpunten duidelijk worden uitgelegd.
Werkthreads, time-outs en push
Ik dimensioner H2MinWorkers en H2MaxWorkers afgestemd op de hardware en het MPM, zodat pieken in de belasting niet leiden tot pieken in de latentie. Daarnaast stel ik H2Timeout en H2KeepAliveTimeout zo in dat vastgelopen sessies niet onnodig lang resources in beslag nemen. De richtlijn H2Direct laat ik op openbare sites achterwege, omdat h2c met Prior Knowledge daar nauwelijks een rol speelt. Wat Push betreft, blijf ik conservatief en schakel ik H2Push pas in na grondige metingen. In veel opstellingen zorgen nette caching, kritieke CSS en asynchrone scripts voor de betrouwbaardere Versnelling.
TLS, ALPN en cipher suites correct instellen
Ik schakel TLS alleen in de HTTPS-vHost in en verwijder oude Protocollen Consequent. Voor een soepele onderhandeling gebruik ik ALPN, zodat de client zonder extra stappen direct overschakelt naar HTTP/2. Een korte certificaatketen, OCSP-stapling en sessiehervatting verminderen de overhead bij de handshake. Zo bespaar ik milliseconden, wat merkbaar invloed heeft op de laadtijd en de doorvoersnelheid. Meer achtergrondinformatie vind je in mijn handleiding over ALPN en HTTP/2 samen, zodat de keuze van de versleutelingsalgoritmen en opties doelgericht verloopt.
Logboekregistratie, tests en foutopsporing
Ik verhoog dat LogLevel Voor HTTP/2 begin ik eerst met ‘info’ om de verbinding, streams en flow-control te observeren. Zo kan ik knelpunten vroegtijdig herkennen en de waarden stap voor stap bijwerken. Met curl controleer ik headers, het protocol en serverantwoorden rechtstreeks vanuit de console. In belastingstests meet ik responstijden, doorvoer en foutpercentages afzonderlijk voor statische en dynamische routes. Elke wijziging onderbouw ik met meetgegevens, zodat optimalisaties betrouwbaar resultaat opleveren.
LogLevel http2:info
#-korttest:
# curl -v --http2 -I https://example.com/
Voorbeeld: compacte HTTP/2-configuratie
Ik laat een Configuratie, die zich in veel projecten heeft bewezen en een goed uitgangspunt biedt. De Event-MPM kan veel gelijktijdige verbindingen aan zonder dat processen overbelast raken. De HTTP/2-richtlijnen beperken streams, vergroten het venster gematigd en houden voldoende workers beschikbaar. Keep-Alive blijft ruim, maar MaxKeepAliveRequests zorgt voor cyclische vrijgave. De fijnafstemming hangt af van RAM, CPU, app-stack en verkeersprofiel, daarom meet ik na elke wijziging opnieuw.
# MPM-event
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 1000
# HTTP/2-kern
Protocols h2 http/1.1
ProtocolsHonorOrder On
# mod_http2-afstemming
H2MaxSessionStreams 150
H2WindowSize 262144
H2MinWorkers 10
H2MaxWorkers 75
H2KeepAliveTimeout 30
H2Timeout 60
# H2Push uit # optioneel laten
# TLS (voorbeeld)
SSLProtocol all -SSLv2 -SSLv3
# Kies een moderne en browsercompatibele SSLCipherSuite
# OCSP Stapling / Session Resumption inschakelen
Tabel met richtwaarden voor het afstemmen van mod_http2
Ik gebruik deze Standaardwaarden Gebruik dit als uitgangspunt en pas de instellingen aan op basis van metingen van het verkeer, de hardware en de app. De tabel geeft een overzicht van typische startwaarden en zinvolle marges. Te grote vensters of te veel streams verbruiken RAM, te kleine vensters beperken de doorvoer. De kunst zit hem in het afstemmen op MaxRequestWorkers en de backend-capaciteit. Ik test elke stap afzonderlijk om oorzaak en gevolg duidelijk te kunnen zien.
| Richtlijn/Instelling | Startwaarde | Tuning-corridor | Tip |
|---|---|---|---|
| H2MaxSessionStreams | 100 | 120–200 | Niet hoger dan het werknemersbudget toestaat |
| H2WindowSize | 65535 B | 256 KB – 1 MB | Groter = minder Windows-updates, maar meer RAM |
| H2MinWorkers | 10 | 10–25 | Kleine systemen zorgen voor de basislast |
| H2MaxWorkers | 50 | 50–75+ | Piekbelastingen opvangen, RAM in de gaten houden |
| KeepAliveTimeout | 15 s | 20–30 s | HTTP/2 profiteert van langere verbindingen |
| MaxKeepAliveRequests | 100 | 100–500 | Regelmatig bronnen vrijgeven |
| MPM-event: MaxRequestWorkers | 150 | 150–300 | Berekeningen maken op basis van het RAM-budget |
Realistische belastingstests en meetstrategie
Ik controleer Reactietijden afzonderlijk voor HTML, statische assets en dynamische API-routes. Vervolgens evalueer ik de doorvoersnelheid en foutpercentages bij toenemende gelijktijdigheid om de knelpunten te vinden. Daarna pas ik H2WindowSize, streams en Keep-Alive stapsgewijs aan en vergelijk ik A/B-tests. Daarnaast houd ik de CPU, het RAM-geheugen, het netwerk en de TLS-handshake-tijden in de gaten, zodat geen enkele verschuiving van de bottleneck onopgemerkt blijft. Zo kom ik tot een configuratie die bij de applicatie past en reserves biedt voor pieken.
Meedenken over infrastructuur en hostingconfiguratie
Ik vertrouw op actuele Apache-versies, een goed onderhouden TLS-stack en krachtige hardware, zodat optimalisaties daadwerkelijk effect sorteren. Voor grote webwinkels en WordPress-portalen loont het de moeite om te kiezen voor een provider die standaard Event-MPM, HTTP/2 en snelle certificaatbeheer aanbiedt. In benchmarks heeft webhoster.de zich voor dergelijke opstellingen bewezen als een betrouwbare partner. Daar combineer ik moderne configuraties met deskundige ondersteuning. Deze basis stelt mij in staat om richtwaarden sneller te testen en soepel in de praktijk te brengen.
HTTP/2 achter loadbalancers en als reverse proxy
Ik controleer of er vóór Apache een Laadbalancer of via CDN wordt beëindigd. Het is van cruciaal belang dat ALPN correct wordt onderhandeld en dat HTTP/2 tot aan de edge actief blijft. Achter een TLS-beëindiging kan Apache als backend nog steeds alleen HTTP/1.1 zien – dat is geen probleem, zolang de client via h2 vanaf de edge wordt bediend. Als ik Apache zelf draai als Omgekeerde proxy naar upstreams (bijv. app-servers), beslis ik bewust of ik HTTP/2 ook naar Ik gebruik een backend. Voor veel backends is HTTP/1.1 stabiel en goed meetbaar; bij trage of verafgelegen diensten kan HTTP/2 de latentie in de upstream-richting verlagen door middel van multiplexing. Het is belangrijk dat ik de concurrency-budgetten tussen frontend, proxylaag en backend op elkaar afstem, anders verschuift de bottleneck gewoon een niveau verder.
PHP-FPM, app-servers en concurrency-budgetten
Ik stem MaxRequestWorkers hangt bij Apache af van het aantal processen/threads in de applicatielaag (bijv. pm.max_children bij PHP-FPM, het aantal workers bij Node/Java). HTTP/2 kan per verbinding veel gelijktijdige streams openen. Als de webserver aanzienlijk meer gelijktijdige verzoeken ontvangt dan de backend parallel kan verwerken, nemen wachtrijen en latenties toe. Daarom stel ik H2MaxSessionStreams, MaxRequestWorkers en de backend-workers zo in dat het voordeel van multiplexing niet verloren gaat door backend-blocking. Voor dynamische pagina’s stel ik een strikte bovengrens in, terwijl ik statische assets agressief uit de cache lever.
Header-economie, HPACK en asset-strategie
HTTP/2 comprimeert headers met HPACK. Toch kosten grote cookie-headers, opgeblazen user-agent-strings of veel onnodige aangepaste headers CPU en geheugen. Ik schrap overbodige cookies, beperk het aantal Set-Cookie-domeinen/subdomeinen en bundel alleen wat echt nodig is. Aan de serverzijde stel ik correcte cache-headers, ETags of Last-Modified in, plus een duidelijke versiebeheer van de assets. Onder HTTP/2 relativeer ik domeinsharding en kunstmatige bundeling: dankzij multiplexing zijn veel kleine bestanden geen probleem meer – zolang de backend het maar bij kan houden. Ik houd het evenwicht in de gaten: te veel verzoeken per pagina verhogen de planningsoverhead; te grote bundels verminderen het aantal cache-treffers en blokkeren het renderen.
Compressie, formaten en responsformaten
Voor tekstbronnen maak ik gebruik van efficiënte Compressie (gzip of brotli) en let ik op zinvolle minimumgroottes, zodat niet elk minuscuul bestand wordt gecomprimeerd. Onder HTTP/2 blijven gecomprimeerde, kleine bronnen goed presteren, omdat ze parallel worden gestreamd. Tegelijkertijd minimaliseer ik te grote HTML-antwoorden, omdat deze de First Byte-tijd domineren. Afbeeldingen lever ik aan in geschikte formaten en groottes; onnodige hercoderingen of server-side conversies direct in het verzoekpad vermijd ik om CPU-pieken af te vlakken.
Bedrijfsvoering, limieten en resourceplanning
Ik plan voldoende Bestandsdescriptors en proceslimieten in, zodat veel gelijktijdige verbindingen niet stranden op ulimit-limieten. De Event-MPM houdt verbindingen efficiënt open, maar elke verbinding neemt wat geheugen in beslag. De som van MaxRequestWorkers, het keep-alive-venster en H2MaxSessionStreams stel ik zo in dat het totale systeem bij piekbelastingen niet in swap terechtkomt. Voor rolling deployments vertrouw ik op sierlijk Reloads; MaxConnectionsPerChild houdt processen up-to-date en voorkomt sluipende geheugenlekken. Ik meet regelmatig de heap-footprints van de workers en pas de levensduur daarop aan.
Praktijkvoorbeelden van storingen en doelgerichte diagnose
Ik ken typische HTTP/2-foutmeldingen: Veel GOAWAY-frames duiden op verbroken verbindingen of harde limieten. Een opeenstapeling van RST_STREAM-frames kan wijzen op time-outs, door de client afgebroken verzoeken of upstream-fouten. Als ik tijdens belastingstests vaker 4xx/5xx-codes zie, controleer ik eerst de backends en databases voordat ik aan de Window of de streams ga sleutelen. Voor de diagnose verhoog ik tijdelijk het LogLevel http2 naar debug, isoleer ik paden met opvallend gedrag en voer ik metingen uit met h2-compatibele tools. Belangrijk: ik wijzig altijd slechts a Eén verstelschroef per testrun, zodat oorzaak en gevolg duidelijk blijven.
Vroege signalen, stimuleren en prioriteren in het dagelijks leven
Ik vertrouw op Vroege hints (103) als een lichte hint-route, voordat ik HTTP/2 Push overweeg. Early Hints geven de browser een voorsprong bij het laden van kritieke bronnen, zonder dat bronnen permanent worden gedupliceerd. Push blijft doelgericht en op statistieken gebaseerd, bijvoorbeeld voor zeer kleine, onveranderlijke CSS-fragmenten of lettertypen, wanneer het nut in statistieken wordt aangetoond. Voor het stellen van prioriteiten vertrouw ik in de eerste plaats op een nette HTML-volgorde, preload-aanwijzingen en een duidelijke ‘kritieke pad’-strategie van de applicatie – dat sluit robuust aan bij moderne browsers.
Time-outs, herhalingspogingen en gebruikerservaring
Ik kalibreer Time-outs zodat legitieme, maar trage clients niet te vroeg worden losgekoppeld, terwijl vastgelopen streams snel worden opgeruimd. Ik ondersteun H2Timeout en H2KeepAliveTimeout met bijpassende proxy- en backend-time-outs, zodat er geen tegenstrijdige afbrekingscriteria zijn. Bij het afstemmen let ik erop dat herhalingspogingen (van de client of de proxy) niet in een cascade ontstaan – anders levert dit meer belasting dan voordeel op. Het doel is meetbaar goede laadtijden, niet maximale ruwe gelijktijdigheid tegen elke prijs.
Beveiliging, TLS-fijnafstemming en stabiliteit
Ik beschouw de TLS-stack slank: korte ketens, stapelbaar OCSP, hervatting van sessies en moderne versleutelingsalgoritmen met ECDHE. Heronderhandeling is uit den boze; ik beperk de grootte van headers bewust (bijvoorbeeld voor cookies). Dit draagt bij aan stabiliteit en voorspelbaarheid, omdat ik de overhead bij de handshake minimaliseer. Voor compliance-eisen plan ik de levensduur van tickets, sessiecaches en cipher-suites zo dat ze een redelijke balans bieden tussen zowel beveiliging als prestaties. Wijzigingen onderbouw ik met meetgegevens bij de doelgroep, niet alleen in laboratoriumomstandigheden.
Monitoring, statistieken en voortdurende optimalisatie
Ik houd toezicht op de werkzaamheden h2-aandeel, latentieverdelingen (p50/p95/p99), foutpercentages, open verbindingen en RAM-gebruik per proces. Mod_status en externe statistieken laten zien of Keep-Alive-vensters en streams correct zijn gedimensioneerd. Als p95-latenties afwijken, controleer ik eerst de backend- en netwerkpaden, en pas daarna de vensters/streams. Daarnaast kijk ik naar de TLS-handshake-tijden; als deze stijgen, ligt de bottleneck vaak vóór Apache (certificaatstatus, entropie, hardware-cryptografie). Met deze feedbackloop houd ik de configuratie dicht bij de realiteit en pas ik deze aan aan verkeerspatronen en releases.
Upgrade- en compatibiliteitsaspecten
Ik ben van plan Regelmatige updates van Apache en mod_http2, aangezien verbeteringen op het gebied van stabiliteit, flow-control en foutafhandeling direct meetbaar kunnen zijn. Voorafgaand aan upgrades test ik onder belasting met representatieve gegevens en vergelijk ik de grafieken met die van de productieomgeving. Bij gemengde clientpopulaties (oudere browsers, bots, apparaten) laat ik HTTP/1.1 bewust als fallback actief, maar controleer ik of bots buitensporig veel verbindingen tot stand brengen en daarmee workers bezetten. In deze gevallen stel ik limieten in of scheid ik het verkeer, zodat echte gebruikers hebben voorrang.
Schaalbaarheidstraject en bedrijfsmodellen
Ik definieer een schaalbaarheidstraject: verticaal (meer RAM/CPU, grotere workerpools) of horizontaal (meer frontends achter een load balancer). HTTP/2 schaalt goed horizontaal, zolang sessie-affiniteit niet absoluut noodzakelijk is. Voor stateful componenten (bijv. sessies aan de serverzijde) bepaal ik hoeveel parallelle streams per node zinvol zijn en of ik sticky sessions echt nodig heb. Zo voorkom ik dat één node onevenredig zwaar wordt belast door te veel langlopende streams, terwijl andere zich vervelen.
Mijn korte samenvatting
Ik activeer HTTP/2 Stel de vHost doelgericht in, kies Event-MPM, verhoog de Keep-Alive-waarde en configureer de protocollen nauwkeurig. Vervolgens stem ik streams, venstergroottes en workers zo af dat het RAM-geheugen en de CPU in balans blijven. TLS met ALPN, korte kettingen en hervatting bespaart kostbare milliseconden bij het opbouwen van de verbinding. Logboekregistratie op http2:info en systematische belastingstests maken elke wijziging traceerbaar. Zo neemt de prestatie stap voor stap toe en ervaren gebruikers snelle pagina’s zonder haperingen.
