Hoppa till innehåll 
Jag konfigurerar Apache mod_http2 så att HTTP/2-prestandan ger omedelbar effekt: korrekt protokollförhandling, lämpliga MPM-trådar och korrekta TLS-inställningar. Med tydliga riktvärden för strömmar, fönsterstorlekar och Keep-Alive uppnår jag stabil Laddningstider från sidor med hög besöksfrekvens.
Centrala punkter
- MPM-evenemang konfigurera och dimensionera Keep-Alive på lämpligt sätt
- Protokoll h2 http/1.1 med ProtocolsHonorOrder aktiverat
- H2WindowSize öka gradvis och begränsa strömmarna
- Arbetare styra via H2MinWorkers/H2MaxWorkers
- TLS/ALPN optimera och förbättra loggningen
Aktivera mod_http2: Grunder och förutsättningar
Jag börjar med aktiveringen av mod_http2 och förhandlingen om protokoll. Modulen laddas med LoadModule, därefter anger jag Protocols h2 http/1.1 så att HTTP/2 prioriteras och HTTP/1.1 fortfarande erbjuds. För produktionstjänster kontrollerar jag att TLS, aktuella krypteringssviter samt inaktiverade äldre versioner som SSLv2/SSLv3. Utan korrekt konfigurerade TLS och ALPN kan moderna webbläsare inte utnyttja protokollet fullt ut. För hög samtidighet planerar jag in MPM i förväg, eftersom prefork bromsar upp HTTP/2 kraftigt.
LoadModule http2_module modules/mod_http2.so
Protocols h2 http/1.1
Aktivera HTTP/2 på ett korrekt sätt i VirtualHosts
Jag aktiverar HTTP/2 specifikt i vHost på port 443 och fastställer ordningen. På så sätt tvingar jag Apache att först erbjuda HTTP/2 och endast övergå till HTTP/1.1 vid behov. En snabb Curl-kontroll bekräftar beteendet med „HTTP/2 200“. Direktiven Protokoll, hedersordning Jag ställer in den på ”On” så att protokollens ordning blir bindande. På så sätt får jag en tydlig och förutsägbar leverans per värd.
Protocols h2 http/1.1
ProtocolsHonorOrder On
SSLEngine on
# Certifikat, krypteringsalgoritmer, OCSP m.m.
Finjustera MPM-val och Keep-Alive
För att uppnå hög samtidighet satsar jag på mpm_händelse, eftersom trådar och händelser hanterar många anslutningar på ett effektivt sätt. Jag beräknar värdena för StartServers, ThreadsPerChild och MaxRequestWorkers utifrån RAM-budgeten för att undvika att minnet överbelastas. För HTTP/2 höjer jag KeepAliveTimeout så att bestående anslutningar får tillräckligt med tid för flera förfrågningar. Samtidigt begränsar jag MaxKeepAliveRequests för att cykaliskt frigöra resurser. Den som vill fördjupa sig i skillnaderna mellan MPM:erna hittar detaljer i min anmärkning om event vs worker MPM, som underlättar valet i praktiken.
Strömmar, multiplexering och flödeskontroll
Jag styr parallella Strömmar med H2MaxSessionStreams och förhindrar att en klient binder upp för många resurser. Värden mellan 100 och 200 fungerar ofta bra, beroende på antalet tillgångar och backend-beteendet. För att öka genomströmningen justerar jag H2WindowSize och ökar flödesfönstret måttligt, ofta till 256 KB. På så sätt minskar jag antalet fönsteruppdateringar utan att belasta minnet i onödan. Den som vill förstå hur detta fungerar kan läsa mitt inlägg om HTTP/2-multiplexering, som tydligt förklarar prioriteringar och hinder.
Arbetstrådar, tidsgränser och push
Jag dimensionerar H2MinWorkers och H2MaxWorkers anpassade efter hårdvaran och MPM, så att belastningstoppar inte leder till latenstoppar. Dessutom ställer jag in H2Timeout och H2KeepAliveTimeout så att fastnade sessioner inte binder upp resurser i onödigt lång tid. Direktivet H2Direct utelämnar jag på offentliga webbplatser, eftersom h2c med Prior Knowledge knappast spelar någon roll där. När det gäller push är jag försiktig och aktiverar H2Push endast efter noggranna mätningar. I många konfigurationer ger ren caching, kritisk CSS och asynkrona skript den mest tillförlitliga Acceleration.
Ställa in TLS, ALPN och krypteringssviter korrekt
Jag aktiverar TLS endast i HTTPS-vHost och tar bort gamla Protokoll Konsekvent. För en smidig förhandling använder jag ALPN så att klienten direkt går över till HTTP/2 utan extra steg. En kort certifikatkedja, OCSP-stapling och session-resumption minskar overheaden vid handskakningen. På så sätt sparar jag millisekunder, vilket märks tydligt på laddningstiden och genomströmningen. Mer bakgrundsinformation finns i min guide till ALPN och HTTP/2 tillsammans, så att valet av krypteringsalgoritmer och alternativ blir så träffsäkert som möjligt.
Loggning, tester och felsökning
Jag höjer det LogLevel För HTTP/2 börjar jag med ”info” för att övervaka uppkoppling, strömmar och flödeskontroll. På så sätt upptäcker jag flaskhalsar tidigt och kan justera värdena steg för steg. Med curl kontrollerar jag rubriker, protokoll och serversvar direkt från konsolen. I belastningstester mäter jag svarstider, genomströmning och felfrekvenser separat för statiska och dynamiska rutter. Varje ändring dokumenterar jag med mätdata så att optimeringarna ger tillförlitliga resultat.
LogLevel http2:info
#-snabbtest:
# curl -v --http2 -I https://example.com/
Exempel: Kompakt HTTP/2-konfiguration
Jag visar en Konfiguration, som har visat sig fungera väl i många projekt och ger en bra utgångspunkt. Event-MPM hanterar många samtidiga anslutningar utan att överbelasta processerna. HTTP/2-direktiven begränsar strömmar, ökar fönstret måttligt och håller tillräckligt många arbetare tillgängliga. Keep-Alive förblir generöst, men MaxKeepAliveRequests säkerställer cyklisk frigöring. Finjusteringen beror på RAM, CPU, app-stack och trafikprofil, därför mäter jag om efter varje ändring.
# MPM-händelse
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 1000
# HTTP/2-kärna
Protocols h2 http/1.1
ProtocolsHonorOrder On
# mod_http2-optimering
H2MaxSessionStreams 150
H2WindowSize 262144
H2MinWorkers 10
H2MaxWorkers 75
H2KeepAliveTimeout 30
H2Timeout 60
# H2Push av # lämna som valfritt
# TLS (exempel)
SSLProtocol all -SSLv2 -SSLv3
# Välj en modern och webbläsarkompatibel SSLCipherSuite
# Aktivera OCSP Stapling / Session Resumption
Tabell med riktvärden för optimering av mod_http2
Jag använder den här Standardvärden som utgångspunkt och justera dem utifrån mätningar av trafik, hårdvara och app. Tabellen sammanfattar typiska startvärden och lämpliga intervall. För stora fönster eller för många strömmar förbrukar RAM-minne, medan för små begränsar genomströmningen. Konsten ligger i att hitta rätt balans mellan MaxRequestWorkers och backend-kapaciteten. Jag testar varje nivå separat för att tydligt se orsak och verkan.
| Riktlinje/Inställning | Startvärde | Tuning-korridor | Ledtråd |
|---|---|---|---|
| H2MaxSessionStreams | 100 | 120–200 | Inte högre än vad arbetstagarbudgeten tillåter |
| H2WindowSize | 65535 B | 256 KB – 1 MB | Större = färre Windows-uppdateringar, men mer RAM-minne |
| H2MinWorkers | 10 | 10–25 | Små system säkerställer grundbelastningen |
| H2MaxWorkers | 50 | 50–75+ | Dämpa belastningstoppar, håll koll på RAM-minnet |
| KeepAliveTimeout | 15 sekunder | 20–30 sekunder | HTTP/2 drar nytta av längre anslutningar |
| MaxKeepAliveRequests | 100 | 100–500 | Dela resurser regelbundet |
| MPM-inställning: MaxRequestWorkers | 150 | 150–300 | Beräkna utifrån RAM-budgeten |
Realistiska belastningstester och mätstrategi
Jag kontrollerar Svarstider separat för HTML, statiska tillgångar och dynamiska API-rutter. Därefter utvärderar jag genomströmning och felfrekvenser vid ökande samtidighet för att hitta brytpunkterna. Sedan justerar jag H2WindowSize, strömmar och Keep-Alive stegvis och jämför A/B-tester. Dessutom övervakar jag CPU, RAM, nätverk och TLS-handshake-tider så att ingen förskjutning av flaskhalsen förblir oupptäckt. På så sätt uppnår jag en konfiguration som passar applikationen och har reserver för toppbelastningar.
Att ta hänsyn till infrastruktur och hostingkonfiguration
Jag satsar på aktuella Apache-versioner, en välskött TLS-stack och högpresterande hårdvara, så att optimeringsåtgärderna ger resultat. För stora webbutiker och WordPress-portaler lönar det sig att välja en leverantör som som standard erbjuder Event-MPM, HTTP/2 och snabb certifikathantering. I prestandatester har webhoster.de visat sig vara en pålitlig leverantör för sådana konfigurationer. Där kombinerar jag moderna konfigurationer med kompetent support. Denna grund gör det möjligt för mig att snabbare testa riktvärden och smidigt implementera dem i driften.
HTTP/2 bakom lastbalanserare och som omvänd proxy
Jag kontrollerar om det finns en Lastbalanserare eller CDN-avslutning. Det avgörande är att ALPN förhandlas fram korrekt och att HTTP/2 förblir aktivt ända fram till kanten. Bakom en TLS-avslutning kan Apache som backend fortfarande endast se HTTP/1.1 – det är inget problem så länge klienten betjänas via h2 till kanten. Om jag själv kör Apache som Omvänd proxy när det gäller uppströms (t.ex. app-servrar) väljer jag medvetet om jag även ska använda HTTP/2 till Använd backend. För många backends räcker det med HTTP/1.1, som är stabilt och lätt att mäta; vid tjänster med hög latens eller som ligger långt bort kan HTTP/2 minska latensen uppströms genom multiplexering. Det är viktigt att jag samordnar samtidighetsbudgetarna mellan frontend, proxylagret och backend, annars flyttas flaskhalsen bara en nivå längre bort.
PHP-FPM, app-server och samtidighetsbudgetar
Jag röstar för MaxRequestWorkers i Apache beror det på antalet processer/trådar i applikationslagret (t.ex. pm.max_children för PHP-FPM, antalet arbetare för Node/Java). HTTP/2 kan öppna många samtidiga strömmar per anslutning. Om webbservern tar emot betydligt fler samtidiga förfrågningar än vad backend-systemet kan bearbeta parallellt, ökar köerna och latensen. Därför dimensionerar jag H2MaxSessionStreams, MaxRequestWorkers och backend-arbetarna så att multiplexvinsten inte går förlorad i backend-blockering. För dynamiska sidor sätter jag en strikt övre gräns, medan jag aggressivt serverar statiska tillgångar från cachen.
Header-ekonomi, HPACK och tillgångsstrategi
HTTP/2 komprimerar rubriker med HPACK. Stora cookie-rubriker, uppblåsta user-agent-strängar eller många onödiga anpassade rubriker belastar dock CPU och minne. Jag rensar bort onödiga cookies, reglerar Set-Cookie-domäner/underdomäner och grupperar endast det som verkligen behövs. På leveranssidan sätter jag korrekta cache-headers, ETags eller Last-Modified samt en tydlig versionering av tillgångarna. Under HTTP/2 relativiserar jag domänsharding och artificiell sammanbundling: många små filer är tack vare multiplexing inget problem längre – så länge backenden hänger med. Jag håller balansen i sikte: För många förfrågningar per sida ökar schemaläggningsöverheaden; för stora buntar minskar cacheträffarna och blockerar renderingen.
Komprimering, storlekar och responsformat
Jag använder effektiva Kompression (gzip eller brotli) och ser till att det finns rimliga minimistorlekar så att inte varje liten fil komprimeras. Med HTTP/2 behåller komprimerade, små resurser sin prestanda eftersom de strömmas parallellt. Samtidigt minimerar jag överdimensionerade HTML-svar, eftersom de dominerar First Byte-tiden. Jag levererar bilder i lämpliga format och storlekar; jag undviker onödiga omkodningar eller serverbaserade konverteringar direkt i begärandevägen för att jämna ut CPU-toppar.
Drift, gränsvärden och resursplanering
Jag planerar tillräckligt Filbeskrivningar och processgränser för att undvika att många samtidiga anslutningar stöter på ulimit-gränser. Event-MPM håller anslutningarna öppna på ett effektivt sätt, men varje anslutning tar upp en viss mängd minne. Jag bestämmer summan av MaxRequestWorkers, Keep-Alive-fönstret och H2MaxSessionStreams så att hela systemet inte hamnar i swap vid belastningstoppar. För rullande driftsättningar satsar jag på graciös Omstart; MaxConnectionsPerChild håller processerna uppdaterade och förhindrar smygande läckor. Jag mäter regelbundet arbetsprocessernas heap-avtryck och justerar livslängden därefter.
Felbilder från praktiken och målinriktad diagnos
Jag känner till typiska HTTP/2-felmeddelanden: Många GOAWAY-ramar tyder på avbrutna anslutningar eller hårda gränser. Förekomster av RST_STREAM kan tyda på timeouts, avbrutna förfrågningar från klienten eller uppströmsfel. Om jag ser fler 4xx/5xx-fel i belastningstester kontrollerar jag först backends och databaser innan jag justerar fönstret eller strömmarna. För att diagnostisera problemet höjer jag tillfälligt loggnivån http2 till debug, isolerar vägar med onormalt beteende och mäter med h2-kompatibla verktyg. Viktigt: Jag ändrar alltid endast en Justeringsskruv per testkörning, så att orsak och verkan förblir tydliga.
Tidiga signaler, påtryckningar och prioritering i vardagen
Jag förlitar mig på Tidiga tips (103) som en lätt vägledning innan jag överväger HTTP/2 Push. Early Hints ger webbläsaren ett försprång vid laddningen av kritiska resurser, utan att resurserna dupliceras permanent. Push används målinriktat och mätningsbaserat, till exempel för mycket små, oföränderliga CSS-snippets eller teckensnitt, när nyttan bevisas i mätvärden. När det gäller prioritering förlitar jag mig främst på en ren HTML-ordning, preload-indikatorer och en tydlig strategi för applikationens kritiska väg – detta fungerar väl tillsammans med moderna webbläsare.
Timeouts, omförsök och användarupplevelse
Jag kalibrerar Tidsfrister så att legitima men långsamma klienter inte kopplas bort för tidigt, samtidigt som fastnade strömmar snabbt rensas bort. Jag kompletterar H2Timeout och H2KeepAliveTimeout med lämpliga proxy- och backend-timeouts så att det inte uppstår motstridiga avbrottskriterier. Vid finjusteringen ser jag till att omförsök (från klient eller proxy) inte skapar en kaskad – annars blir belastningen större än nyttan. Mätbart bra laddningstider är målet, inte maximal rå samtidighet till varje pris.
Säkerhet, finjustering av TLS och stabilitet
Jag anser att TLS-stacken smal: korta kedjor, staplande OCSP, återupptagning av sessioner och moderna krypteringsalgoritmer med ECDHE. Omförhandling är tabu, och jag begränsar medvetet storleken på överskridande rubriker (t.ex. för cookies). Detta bidrar till stabilitet och förutsägbarhet, eftersom jag minimerar overhead vid handskakningen. För att uppfylla efterlevnadskraven planerar jag biljetters livslängd, sessionscacher och krypteringssviter så att de uppnår en rimlig balans mellan säkerhet och prestanda. Jag underbygger ändringar med mätdata från målklienterna, inte bara från laboratoriemiljöer.
Övervakning, nyckeltal och kontinuerlig optimering
Jag observerar på arbetsplatsen h2-andel, latensfördelningar (p50/p95/p99), felfrekvenser, öppna anslutningar och RAM-förbrukning per process. Mod_status och externa mätvärden visar om Keep-Alive-fönster och strömmar är korrekt dimensionerade. Om p95-latenserna avviker kontrollerar jag först backend- och nätverksvägarna, och först därefter fönster/strömmar. Dessutom tittar jag på TLS-handshake-tider; om de ökar ligger ofta orsaken före Apache (certifikatstatus, entropi, hårdvarukryptering). Med denna återkopplingscykel håller jag konfigurationen nära verkligheten och anpassar den efter trafikmönster och releaser.
Uppgraderings- och kompatibilitetsaspekter
Jag planerar att Regelbundna uppdateringar från Apache och mod_http2, eftersom förbättringar i stabilitet, flödeskontroll och felhantering kan mätas direkt. Innan uppgraderingar testar jag under belastning med representativa data och jämför kurvorna med produktionsmiljön. Vid blandade klientgrupper (äldre webbläsare, bots, enheter) låter jag medvetet HTTP/1.1 vara aktivt som fallback, men kontrollerar om bots upprättar ett överdrivet stort antal anslutningar och därmed binder upp arbetare. I dessa fall sätter jag gränser eller separerar trafiken så att verkliga användare Har företräde.
Skalningsstrategi och driftsmodeller
Jag definierar en Skalningsväg: vertikalt (mer RAM/CPU, större arbetspooler) eller horisontellt (fler frontend-instanser bakom en lastbalanserare). HTTP/2 skalar bra horisontellt så länge sessionsaffinitet inte är ett krav. För stateful komponenter (t.ex. serversidiga sessioner) planerar jag hur många parallella strömmar per nod som är rimligt och om jag verkligen behöver sticky sessions. På så sätt undviker jag att en nod belastas oproportionerligt mycket av för många långvariga strömmar, medan andra står stilla.
Min korta sammanfattning
Jag aktiverar HTTP/2 Gör en målinriktad inställning i vHost, välj Event-MPM, öka Keep-Alive och ställ in protokollen tydligt. Därefter kalibrerar jag strömmar, fönsterstorlekar och arbetare så att RAM och CPU hålls i balans. TLS med ALPN, korta kedjor och återupptagning sparar värdefulla millisekunder vid uppkopplingen. Loggning på http2:info och systematiska belastningstester dokumenterar varje ändring på ett överskådligt sätt. På så sätt ökar prestandan steg för steg, och användarna får snabba sidor utan avbrott.
