Apache è in assoluto il server HTTP più diffuso al mondo. Dall'ultimo studio condotto da Netcraft (marzo 2012), risulta che oltre 420 milioni di siti web utilizzano Apache (65,24% del totale). A grande distanza si pongono altri produtti come IISdi Microsoft (13,81%) e nginx (10,15%).
Con l'annuncio di Apache 2.4, avvenuto alla fine di febbraio 2012, il web server si candida a consolidare il proprio primato. Oltre ad apportare miglioramenti significativi ad una nutrita serie di moduli esistenti, gli sviluppatori della Apache Software Foundation (ASF) hanno aggiunto nuovi moduli per renderlo molto più performante e pronto per il Cloud computing, così come dichiarato dal vice presidente della ASF, Eric Covener.
Uno degli aspetti di cui si è tenuto più conto durante lo sviluppo della nuova versione è quindi quello delle performance. Ad esempio, è ora possibile definire quali Multi-Processing Modules (MPMs) rendere disponibili già in fase di compilazione e quale utilizzare a runtime. Gli MPM sono i moduli responsabili del binding delle porte di rete sull'host: accettano richieste e le gestiscono relativamente ai servizi disponibili. Nella versione 2.4 esistono MPM specializzati per i vari ambienti operativi che vengono caricati di default.
Nel caso si volesse utilizzare un altro MPM, basta ricompilare utilizzando l'opzione --with-mpm=NAME, dove NAME è il nome dell'MPM. Ciò è significativo per le performance, perché consente ad Apache di supportare in modo nativo e, quindi, molto più efficiente, un'ampia varietà di sistemi operativi. È stato riscontrato in particolare che, in ambiente Windows, Apache 2.4 risulta essere molto più efficiente del passato, grazie proprio all'utilizzo del modulo mpm_winnt, che implementa lo stack di rete di Windows, piuttosto che quello generico basato su POSIX e utilizzato nella versione 1.3. Ciò significa anche che l'http server può essere customizzato secondo le specifiche esigenze di un particolare sito web. Ad esempio, siti che necessitano di grande scalabilità e quindi di una gestione dei processi di tipo multi-threaded, possono sfruttare direttamente il modulo mpm_worker oppure il modulo mpm_event.
Caching ottimizzato
Un altro miglioramento significativo rispetto alle precedenti versioni è rappresentato dalla gestione ottimizzata della cache che, in Apache, viene effettuata attraverso il modulo mod_cache. Tale modulo implementa un meccanismo di HTTP caching conforme alla RFC 2616, che standardizza il protocollo HTTP/1.1.
L'obiettivo del meccanismo di caching, come è noto, è quello ridurre al minimo l'invio di nuove richieste http per i contenuti desiderati, ottenendo quindi un miglioramento delle performance derivante dal fatto che tali contenuti sono già presenti nella cache del web server e possono quindi essere trasferiti direttamente al client. Ciò può però avvenire sotto determinate condizioni di expiration e validation. A tal proposito la RFC definisce un vero e proprio "expiration model", che specifica per filo e per segno come gestire, ad esempio, l'expiration time e come calcolare, di conseguenza, se un determinato contenuto presente in cache può essere considerato ancora sufficientemente "fresh" per poter essere fornito al client come risposta oppure no.
I miglioramenti al modulo mod_cache prevedono, ad esempio, la possibilità da parte dell'http server di rispondere anche con contenuti non aggiornati, in caso di indisponibilità del server originario di backend (errori 5xx). Questo comportamento viene gestito dalla direttiva CacheStaleOnError, disponibile appunto a partire dalla versione 2.3.9. Un'altra feature è rappresentata dalla possibilità di poter gestire diversi livelli di cache anche per singola directory, oltre che per tutto il server. In sostanza, il meccanismo diventa più granulare anche attraverso l'utilizzo di direttive "condizionali" come la CacheDetailHeader, che aggiunge un header di tipo X-Cache-Detail alla http-response: ciò fa sì che si possano ottenere informazioni aggiuntive circa il motivo del caching.
Proxy e Load Balancing
Tra i nuovi moduli sviluppati vanno segnalati certamente quelli di backend per mod_proxy. Il modulo mod_proxy è responsabile della gestione di un proxy/gateway per l'HTTP server di Apache e integra ora una serie di ulteriori moduli proxy, come ad esempio mod_proxy_fcgi per il protocollo FastCGI oppure mod_proxy_scgi per SCGI. Questi moduli possono essere sia inclusi staticamente in fase di compilazione che utilizzati dinamicamente a runtime, utilizzando la direttiva LoadModule. In figura 2 è mostrata una tabella che elenca i vari moduli di backend per mod_proxy.
Il proxy server di Apache supporta inoltre meccanismi di load balancig che nell'ultima versione sono stati ulteriormente ottimizzati grazie, ad esempio, all'evoluzione e miglioramento della direttiva ProxyPass, che effettua un mapping statico tra server remoti e l'URL-space del server locale. In questo modo, il server locale non agisce secondo lo schema classico del proxy server ma come un vero e proprio mirror dei server remoti mappati, implementando quello che viene chiamato un reverse proxy. Ad esempio, supponendo che il server locale abbia indirizzo http://example.com/, allora attraverso la direttiva ProxyPass possiamo definire:
<Location /mirror/foo/>
<ProxyPass http://backend.example.com/>
</Location>
Ciò fa sì che una richiesta locale alla URL http://example.com/mirror/foo/bar venga convertita in una proxy request del tipo http://backend.example.com/bar.
Sempre a proposito di load balancing, sono stati apportati alcuni miglioramenti al modulo mod_proxy_balancer come, ad esempio, la possibilità di cambiare "on-the-fly" la configurazione dei balancer members a runtime, utilizzando il Balancer Manager. I balancer members sono i server di back-end che devono essere posti in load balancing. Ecco, ad esempio, una tipica configurazione che comprende due server in load balancing:
<Proxy balancer://mycluster>
BalancerMember http://192.168.1.50:80
BalancerMember http://192.168.1.51:80
</Proxy>
ProxyPass /test balancer://mycluster
ProxyPassReverse /test balancer://mycluster
È possibile inoltre abilitare il Balancer Manager, che consente l'aggiornamento dinamico dei balancer members, ad esempio per cambiare il balance factor di un server o metterlo offline.
Sessioni persistenti e sicurezza
Apache 2.4 consente ora, attraverso il nuovo modulo mod_session, di gestire le sessioni utente tenendo traccia, ad esempio, del fatto che un utente abbia effettuato il login o di altri eventi e conservandone lo stato sia sul server che sul client. Come è noto, la sessione è una stringa del tipo application/x-www-form-urlencoded contenente coppie (chiave, valore) del tipo "Session ID = ACF3D35F216AAEFC" che vengono trasmessi in chiaro all'interno di un cookie.
In ambienti caratterizzati da un elevato traffico di rete è frequente che, per non appesantire ulteriormente i server, si decida che i cookie vengano conservati direttamente all'interno del browser client. Come è facile immaginare, ciò costituisce un problema per la privacy, poichè può costituire il mezzo per sferrare un attacco di tipo Session Hijacking, che consiste nell'intercettare (ad esempio attraverso un man-in-the-middle) il Session ID ed ottenere quindi un accesso non autorizzato al Web Server.
In figura 3 è visibile lo schema classico di un Session Hijacking.
Ecco perchè è stato introdotto anche un meccanismo di encryption/decryption automatico attraverso l'utilizzo del modulo mod_crypto. In questo modo, ogni sessione viene automaticamente criptata in fase di memorizzazione e decriptata in fase di loading.