Webservers
Apache httpd: de originele webserver, die nog steeds zijn plaats verdient
Apache httpd dreef drie decennia van het web aan, en het Apache Running After Maturity-tijdperk is reëel: de gebeurtenis MPM maakte mod_php-class workloads gelijktijdig, modules omvatten alles van authenticatie tot caching op de server, en .htaccess houdt shared hosting beheersbaar. Het stereotype is achterhaald in termen van prestaties, maar accuraat in termen van handel, en als je de afwegingen kent, blijft Apache een legitieme optie in plaats van een verontschuldiging.
Kernpunten
- De gebeurtenis MPM is het moderne platform: een vaste pool van werkthreads voedt de keep-alive-verbindingen asynchroon, wat de reden is dat de huidige Apache niet langer bezwijkt onder gelijktijdigheid zoals oude prefork-benchmarks; prefork is alleen geschikt voor niet-thread-safe modules en blijft een bewuste uitzondering.
- Het moduleoppervlak is de functie: mod_ssl, mod_security (de standaard WAF), mod_rewrite, mod_proxy plus balancer-fans en authenticatiemodules voor elk tijdperk; modules kunnen worden gecompileerd in of geladen met a2enmod-class tooling met overschrijvingen per host, wat de reden is dat gedeelde hosting Apache nog steeds als eerste uitvoert.
- .htaccess is een cultureel kenmerk met twee kanten: het overschrijven op mapniveau geeft gebruikers de volledige configuratiekracht (omleidingen per site, PHP-vlaggen, beveiligingsgekte), maar voor elk verzoek worden de kosten voor het opzoeken en parseren van het bestandssysteem betaald; waar prestaties belangrijk zijn en regels stabiel zijn, verplaatst u htaccess-regels naar de serverconfiguratie.
- Reverse proxying is reëel maar secundair: mod_proxy/AJP en mod_pagespeed-class opties bestaan, hoewel voor edge-werk nginx/caddy/traefik-class proxy's meestal winnen; de gebruikelijke moderne vorm is Apache achter een sneller front voor oudere app-domeinen (en gedeelde WordPress-hosting, waar htaccess draagkrachtig is).
- In de praktijk geteste configuratiediscipline: apachectl configtest na wijzigingen, afzonderlijke virtuele hosts per site, modsecurity niet alleen geïnstalleerd maar op regels ingesteld (standaardwaarden Paranoia Level 1), mod_evasive/limitreq-stijl modules voor het afhandelen van overstromingen, en logfouten plus toegang met tariefvelden voor de loganalyselagen.
- Het eerlijke oordeel in 2026: Apache is een uitstekende applicatieserver en een middelmatige edge-proxy; voer het uit waar de modules en mapoverschrijvingen de werklast dragen, voer het uit met een lean reverse proxy wanneer de schaal dit nodig heeft, en laat htaccess-scans nooit ongecontroleerd voorbijgaan (ze vormen een persistent exploitatieoppervlak op gedeelde hosting).
Notitie uit de praktijk
Een WordPress-hostingdomein dat we hebben overgenomen draaide Apache met 1.700 .htaccess-bestanden op verschillende sites, waarvan sommige tegenstrijdig waren. We hebben stabiele regels naar vhost-configuraties verplaatst, overschrijvingen per site gehandhaafd waar eigenaren ze nodig hadden, en de p99-latentie van de gedeelde host daalde met een derde zonder iets te kopen.
Veelgestelde vragen
Draaien we Apache überhaupt nog in 2026?
Ja, en om goede redenen: het .htaccess-ecosysteem (WordPress/Drupal-klasse shared hosting), mod_security volwassenheid en moduledekking voor oudere stacks. Het in het groot vervangen ervan is een beslissing over de werklast, geen modebeslissing.
Welke MPM moeten we uitvoeren?
Evenement voor alles wat modern is, prefork opzettelijk voor oudere niet-thread-safe modules (sommige PHP-extensiestacks en oudere bibliotheken); arbeider is op dit moment grotendeels geschiedenis. Meet uw eigen verkeer na elke MPM-switch.
Is .htaccess slecht?
Niet 'slecht', het kost prestatie per verzoek en vergroot het aanvalsoppervlak bij shared hosting, maar het is de hele reden waarom shared hosting überhaupt werkt; de discipline verplaatst stabiele regels naar vhost-configuratie en kijkt naar overschrijvingen op mapniveau.
Hoe past mod_security in de beveiligingsstack?
Het is de meest gebruikte open WAF-laag, uitstekend in het filteren van voor de hand liggende exploitatieklassen (SQLi-patronen, padtraversal, beheerdersondes) maar luidruchtig zonder afstemming; combineer het met logboeken en regeluitzonderingen per site (zie ons firewallconfiguratieartikel voor de aanvulling op de server).
Hoe Kinetikatech helpt bij webservers
Dit is ons dagelijks werk: Configuration, optimization and security of web servers in production and development environments. Onze dienst Website-snelheid en Serverbeheer dekt het volledige traject: beoordeling, implementatie, 24/7-monitoring en noodrespons binnen 30 minuten.