Videre til indhold 
Jeg konfigurerer Apache mod_http2 således at HTTP2-ydeevnen træder i kraft med det samme: korrekt protokolforhandling, passende MPM-tråde og korrekte TLS-indstillinger. Med klare retningslinjer for streams, vinduesstørrelser og Keep-Alive opnår jeg stabil Indlæsningstider fra sider med mange besøgende.
Centrale punkter
- MPM-arrangement Indsæt og dimensioner Keep-Alive korrekt
- Protokoller h2 http/1.1 med ProtocolsHonorOrder aktiveret
- H2WindowSize øge det moderat og begrænse strømme
- Arbejder styres via H2MinWorkers/H2MaxWorkers
- TLS/ALPN optimere og forbedre logningen
Aktivering af mod_http2: Grundlæggende oplysninger og forudsætninger
Jeg starter med at aktivere mod_http2 og forhandling af protokoller. Modulet indlæses via LoadModule, hvorefter jeg indstiller Protocols til h2 http/1.1, så HTTP/2 prioriteres, mens HTTP/1.1 fortsat tilbydes. Til produktiv drift kontrollerer jeg, at TLS, aktuelle krypteringssuiter samt deaktiverede ældre versioner som SSLv2/SSLv3. Uden korrekt TLS og ALPN udnytter moderne browsere ikke protokollen fuldt ud. Ved høj samtidighed planlægger jeg MPM på forhånd, da prefork bremser HTTP/2 kraftigt.
LoadModule http2_module modules/mod_http2.so
Protocols h2 http/1.1
Sådan aktiveres HTTP/2 korrekt i VirtualHosts
Jeg aktiverer HTTP/2 specifikt i vHost på port 443 og fastlægger rækkefølgen. På den måde sikrer jeg, at Apache først tilbyder HTTP/2 og kun skifter til HTTP/1.1, hvis det er nødvendigt. En hurtig Curl-test bekræfter dette med „HTTP/2 200“. Direktiven Protokoller, Æresordener Jeg sætter den til »On«, så rækkefølgen af logfilerne er fastlagt. På den måde opnår jeg en klar og forudsigelig udlevering pr. vært.
Protocols h2 http/1.1
ProtocolsHonorOrder On
SSLEngine on
# Certifikater, krypteringsalgoritmer, OCSP osv.
Finjustering af MPM-valg og Keep-Alive
For at opnå høj samtidighed satser jeg på mpm_event, fordi tråde og begivenheder håndterer mange forbindelser effektivt. Jeg tilpasser værdierne for StartServers, ThreadsPerChild og MaxRequestWorkers i forhold til RAM-kapaciteten, så der ikke er risiko for, at data bliver flyttet til swap-området. For HTTP/2 hæver jeg KeepAliveTimeout, så vedvarende forbindelser har tilstrækkelig tid til flere anmodninger. Samtidig begrænser jeg MaxKeepAliveRequests for at frigive ressourcer cyklisk. Hvis du vil fordybe dig i forskellen mellem MPM’erne, kan du finde detaljer i min note om event vs. worker MPM, som gør valget lettere i praksis.
Strømme, multiplexing og flowkontrol
Jeg styrer parallelle Streams med H2MaxSessionStreams og forhindrer, at en klient binder for mange ressourcer. Værdier mellem 100 og 200 fungerer ofte godt, afhængigt af antallet af assets og backend-adfærd. For at øge gennemstrømningen justerer jeg H2WindowSize og øger strømvinduet moderat, ofte til 256 KB. På den måde reducerer jeg vinduesopdateringerne uden at belaste hukommelsen unødigt. Hvis du vil forstå, hvordan det fungerer, kan du læse mit indlæg om HTTP/2 multiplexing, der på en overskuelig måde forklarer prioriteter og hindringer.
Arbejdstråde, timeouts og push
Jeg dimensionerer H2MinWorkers og H2MaxWorkers, der passer til hardwaren og MPM, så belastningsspidser ikke fører til forsinkelsesspidser. Derudover indstiller jeg H2Timeout og H2KeepAliveTimeout, så hængende sessioner ikke binder ressourcer unødigt længe. Direktiven H2Direct udelader jeg på offentlige websteder, da h2c med Prior Knowledge næppe spiller nogen rolle der. Når det gælder push, forbliver jeg konservativ og aktiverer H2Push kun efter grundige målinger. I mange opsætninger sikrer korrekt caching, kritisk CSS og asynkrone scripts den mest pålidelige Acceleration.
Indstilling af TLS, ALPN og krypteringssuiter korrekt
Jeg aktiverer kun TLS i HTTPS-vHost og sletter gamle Protokoller Konsekvent. For at sikre en velfungerende forhandling bruger jeg ALPN, så klienten skifter direkte til HTTP/2 uden ekstra runder. En kort certifikatkæde, OCSP-stapling og session-resumption reducerer overheadet ved håndtrykket. På den måde sparer jeg millisekunder, hvilket har en mærkbar effekt på indlæsningstiden og gennemstrømningen. Jeg går mere i dybden med dette i min vejledning om ALPN og HTTP/2 sammen, så valget af krypteringsalgoritmer og indstillinger sker præcist.
Logning, test og fejlfinding
Jeg forhøjer LogLevel For HTTP/2 starter jeg med »info« for at overvåge opbygning, streams og flowkontrol. På den måde opdager jeg flaskehalse tidligt og kan justere værdierne trin for trin. Med curl tjekker jeg headere, protokol og serverresponser direkte fra konsollen. I belastningstests måler jeg responstider, gennemstrømning og fejlrater separat for statiske og dynamiske ruter. Jeg dokumenterer hver ændring med måledata, så optimeringerne virker pålideligt.
LogLevel http2:info
#-hurtigtest:
# curl -v --http2 -I https://example.com/
Eksempel: Kompakt HTTP/2-konfiguration
Jeg viser en Konfiguration, som har vist sig at fungere godt i mange projekter og giver et godt udgangspunkt. Event-MPM håndterer mange samtidige forbindelser uden at overbelaste processerne. HTTP/2-direktiverne begrænser streams, øger vinduet moderat og holder tilstrækkeligt med workere klar. Keep-Alive forbliver generøst, men MaxKeepAliveRequests sørger for cyklisk frigivelse. Finjusteringen afhænger af RAM, CPU, app-stack og trafikprofil, derfor måler jeg igen efter hver ændring.
# MPM-begivenhed
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 1000
# HTTP/2-kerne
Protocols h2 http/1.1
ProtocolsHonorOrder On
# mod_http2-optimering
H2MaxSessionStreams 150
H2WindowSize 262144
H2MinWorkers 10
H2MaxWorkers 75
H2KeepAliveTimeout 30
H2Timeout 60
# H2Push slået fra # lad det være valgfrit
# TLS (eksempel)
SSLProtocol all -SSLv2 -SSLv3
# Vælg SSLCipherSuite, der er moderne og browserkompatibel
# Aktiver OCSP Stapling / Session Resumption
Tabel med vejledende værdier til optimering af mod_http2
Jeg bruger denne Standardværdier Brug dem som udgangspunkt og juster dem ud fra målinger af trafik, hardware og app. Tabellen opsummerer typiske startværdier og fornuftige intervaller. For store vinduer eller for mange streams belaster RAM’en, mens for små begrænser gennemstrømningen. Kunsten ligger i at finde den rette balance mellem MaxRequestWorkers og backend-kapaciteten. Jeg tester hvert trin separat for tydeligt at kunne se årsag og virkning.
| Retningslinje/Indstilling | Startværdi | Tuning-korridor | Hint |
|---|---|---|---|
| H2MaxSessionStreams | 100 | 120–200 | Ikke højere end det, som arbejdsbudgetet tillader |
| H2WindowSize | 65535 B | 256 KB – 1 MB | Større = færre Windows-opdateringer, men mere RAM |
| H2MinWorkers | 10 | 10–25 | Små anlæg sikrer grundbelastningen |
| H2MaxWorkers | 50 | 50–75+ | Udjævne belastningsspidser, holde øje med RAM’en |
| KeepAliveTimeout | 15 sek. | 20–30 sekunder | HTTP/2 drager fordel af længere forbindelser |
| MaxKeepAliveRequests | 100 | 100–500 | Del ressourcer regelmæssigt |
| MPM-begivenhed: MaxRequestWorkers | 150 | 150–300 | Beregne ud fra RAM-budgettet |
Realistiske belastningstests og måleplan
Jeg tjekker Svartider adskilt for HTML, statiske ressourcer og dynamiske API-ruter. Derefter vurderer jeg gennemstrømning og fejlprocenter ved stigende samtidighed for at finde knækpunkterne. Så justerer jeg H2WindowSize, streams og Keep-Alive trin for trin og sammenligner A/B-tests. Derudover overvåger jeg CPU, RAM, netværk og TLS-håndtrykstider, så ingen forskydning af flaskehalsen forbliver uopdaget. På den måde opnår jeg en konfiguration, der passer til applikationen og har reserver til spidsbelastninger.
Medtænk infrastruktur og hostingopsætning
Jeg satser på aktuelle Apache-versioner, en velvedligeholdt TLS-stack og højtydende hardware, så optimeringsjusteringerne virker. For store webshops og WordPress-portaler er det en fordel at vælge en udbyder, der som standard tilbyder Event-MPM, HTTP/2 og hurtig certifikatvedligeholdelse. I benchmarks har webhoster.de vist sig at være en pålidelig udbyder til sådanne opsætninger. Her kombinerer jeg moderne konfigurationer med kompetent support. Dette grundlag giver mig mulighed for hurtigere at afprøve retningslinjer og implementere dem problemfrit i driften.
HTTP/2 bag load balancere og som reverse proxy
Jeg tjekker, om der foran Apache er en Load balancer eller CDN-terminering. Det afgørende er, at ALPN forhandles korrekt, og at HTTP/2 forbliver aktivt helt ud til edge-serveren. Bag en TLS-terminering kan Apache som backend fortsat kun se HTTP/1.1 – det er i orden, så længe klienten betjenes via h2 ud til edge-serveren. Hvis jeg selv kører Apache som Omvendt proxy til upstreams (f.eks. app-servere) beslutter jeg bevidst, om jeg også vil bruge HTTP/2 til Jeg bruger backend. For mange backends er HTTP/1.1 stabilt og let at måle; ved tjenester med høj latenstid eller langt væk kan HTTP/2 reducere latenstiden i opstrømsretningen ved hjælp af multiplexing. Det er vigtigt, at jeg afstemmer kapacitetsbudgettet mellem frontend, proxylaget og backend, ellers flytter flaskehalsen sig blot et niveau videre.
PHP-FPM, app-server og parallelitetsbudgetter
Jeg stemmer for MaxRequestWorkers afhænger i Apache af antallet af processer/tråde i app-laget (f.eks. pm.max_children ved PHP-FPM, antallet af arbejdere ved Node/Java). HTTP/2 kan åbne mange samtidige streams pr. forbindelse. Hvis webserveren modtager betydeligt flere samtidige anmodninger, end backend'et kan behandle parallelt, stiger køerne og ventetiderne. Derfor dimensionerer jeg H2MaxSessionStreams, MaxRequestWorkers og backend-arbejderne således, at multiplex-gevinsten ikke går tabt i backend-blokering. For dynamiske sider fastsætter jeg en fast øvre grænse, mens jeg aggressivt serverer statiske ressourcer fra cachen.
Header-økonomi, HPACK og aktivstrategi
HTTP/2 komprimerer headere med HPACK. Alligevel belaster store cookie-headere, oppustede user-agent-strenge eller mange unødvendige brugerdefinerede headere CPU og hukommelse. Jeg renser cookies, regulerer Set-Cookie-domæner/underdomæner og samler kun det, der virkelig er brug for. På leveringssiden indstiller jeg korrekte cache-headere, ETags eller Last-Modified samt en klar versionering af ressourcerne. Under HTTP/2 relativerer jeg domænesharding og kunstig bundling: Mange små filer er takket være multiplexing ikke længere et problem – så længe backendet kan følge med. Jeg holder øje med balancen: For mange anmodninger pr. side øger planlægningsomkostningerne; for store bundter mindsker cache-hits og blokerer rendering.
Komprimering, størrelser og responsformater
Jeg bruger effektive Kompression (gzip eller brotli) og sørger for at fastsætte fornuftige minimumsstørrelser, så ikke hver eneste lille fil komprimeres. Under HTTP/2 bevarer komprimerede, små ressourcer deres ydeevne, fordi de streames parallelt. Samtidig minimerer jeg overdimensionerede HTML-svar, da de dominerer First Byte-tiden. Jeg leverer billeder i passende formater og størrelser; jeg undgår unødvendige omkodninger eller serverbaserede konverteringer direkte i anmodningsstien for at udjævne CPU-spidsbelastninger.
Drift, grænser og ressourceplanlægning
Jeg planlægger tilstrækkeligt Filbeskrivelser og indstiller procesgrænser, så mange samtidige forbindelser ikke går i stå på grund af ulimit-grænser. Event-MPM holder forbindelserne åbne på en effektiv måde, men hver forbindelse optager lidt hukommelse. Jeg fastlægger summen af MaxRequestWorkers, Keep-Alive-vinduet og H2MaxSessionStreams således, at det samlede system ikke glider over i swap ved belastningsspidser. Til rullende implementeringer satser jeg på yndefuld Genindlæsninger; MaxConnectionsPerChild holder processerne opdaterede og forhindrer snigende hukommelseslækager. Jeg måler regelmæssigt arbejdsprocessernes heap-footprint og justerer levetiden i overensstemmelse hermed.
Eksempler på fejl fra praksis og målrettet diagnose
Jeg kender typiske HTTP/2-fejlmeddelelser: Mange GOAWAY-frames tyder på forbindelsesafbrydelser eller hårde begrænsninger. Hyppige RST_STREAM-hændelser kan tyde på timeouts, afbrudte anmodninger fra klienten eller upstream-fejl. Hvis jeg ser flere 4xx/5xx-fejl i belastningstests, tjekker jeg først backends og databaser, før jeg justerer Window eller streams. Til diagnosticering hæver jeg midlertidigt LogLevel http2 til debug, isolerer stier med mistænkelig adfærd og måler med h2-kompatible værktøjer. Vigtigt: Jeg ændrer altid kun en Justeringsskrue pr. testkørsel, så årsag og virkning forbliver tydelige.
Tidlige tegn, push og prioritering i hverdagen
Jeg stoler på Tidlige hints (103) som en let hint-metode, inden jeg overvejer HTTP/2 Push. Early Hints giver browseren et forspring til at indlæse kritiske ressourcer uden at duplikere ressourcerne permanent. Push forbliver målrettet og datadrevet, f.eks. til meget små, uforanderlige CSS-uddrag eller skrifttyper, når fordelen er dokumenteret i målinger. Når det gælder prioritering, stoler jeg først og fremmest på en ren HTML-rækkefølge, preload-henvisninger og en klar strategi for applikationens kritiske sti – det fungerer robust sammen med moderne browsere.
Timeouts, gentagne forsøg og brugeroplevelse
Jeg kalibrerer Timeouts således at legitime, men langsomme klienter ikke afbrydes for tidligt, mens fastlåste streams hurtigt ryddes op. Jeg understøtter H2Timeout og H2KeepAliveTimeout med passende proxy- og backend-timeouts, så der ikke opstår modstridende afbrydelseskriterier. Ved finjusteringen sørger jeg for, at gentagne forsøg (fra klient eller proxy) ikke udløser en kaskadeeffekt – ellers skaber det mere belastning end nytte. Målet er målbart gode indlæsningstider, ikke maksimal rå samtidighed for enhver pris.
Sikkerhed, finjustering af TLS og stabilitet
Jeg anser TLS-stakken for slank: korte kæder, stakbaseret OCSP, genoptagelse af sessioner og moderne krypteringsalgoritmer med ECDHE. Genforhandling er udelukket, og jeg begrænser bevidst overskrifters størrelse (f.eks. for cookies). Det bidrager til stabilitet og forudsigelighed, fordi jeg minimerer overheadet ved håndtrykket. Med henblik på compliance-krav planlægger jeg ticket-levetider, session-caches og krypteringssuiter, så de skaber en fornuftig balance mellem sikkerhed og ydeevne. Ændringer underbygger jeg med måledata fra målklienterne, ikke kun fra laboratoriesituationer.
Overvågning, målinger og løbende optimering
Jeg observerer i virksomheden h2-andel, latenstidsfordelinger (p50/p95/p99), fejlrater, åbne forbindelser og RAM-forbrug pr. proces. Mod_status og eksterne målinger viser, om Keep-Alive-vinduer og -strømme er korrekt dimensioneret. Hvis p95-latenser afviger, tjekker jeg først backend og netværksstier og først derefter vinduer/strømme. Derudover ser jeg på TLS-håndtrykstider; hvis de stiger, ligger flaskehalsen ofte før Apache (certifikatstatus, entropi, hardwarekryptering). Med denne feedback-cyklus holder jeg konfigurationen tæt på virkeligheden og tilpasser den til trafikmønstre og nye versioner.
Opgraderings- og kompatibilitetsaspekter
Jeg planlægger Regelmæssige opdateringer fra Apache og mod_http2, da forbedringer inden for stabilitet, flowkontrol og fejlhåndtering kan måles direkte. Før opgraderinger tester jeg under belastning med repræsentative data og sammenligner kurverne med produktionsmiljøet. Ved blandede klientpopulationer (ældre browsere, bots, enheder) lader jeg bevidst HTTP/1.1 være aktivt som fallback, men kontrollerer dog, om bots opretter et uforholdsmæssigt stort antal forbindelser og dermed binder arbejdsprocesser. I disse tilfælde indfører jeg begrænsninger eller adskiller trafikken, så ægte brugere Har forrang.
Skaleringsstrategi og driftsmodeller
Jeg definerer en Skaleringsforløb: vertikalt (mere RAM/CPU, større worker-puljer) eller horisontalt (flere frontends bag en load balancer). HTTP/2 skalerer godt horisontalt, så længe session-affinity ikke er et krav. For stateful komponenter (f.eks. serversidede sessioner) planlægger jeg, hvor mange parallelle streams pr. node der er fornuftigt, og om jeg virkelig har brug for sticky sessions. På den måde undgår jeg, at en node bliver uforholdsmæssigt belastet af for mange langvarige streams, mens andre keder sig.
Min korte opsummering
Jeg aktiverer HTTP/2 Målrettet i vHost: Vælg Event-MPM, øg Keep-Alive og konfigurer logfilerne korrekt. Derefter kalibrerer jeg streams, vinduesstørrelser og workers, så RAM og CPU forbliver i balance. TLS med ALPN, korte kæder og genoptagelse sparer værdifulde millisekunder ved opkoblingen. Logning på http2:info og systematiske belastningstests dokumenterer hver ændring på en overskuelig måde. På den måde øges ydeevnen trin for trin, og brugerne oplever hurtige sider uden afbrydelser.
