A febbraio 2001 il Netcraft Web Server Survey conta 16.871.744 siti serviti da Apache, il 59,99% di quelli rilevati; Microsoft-IIS si ferma al 19,64%. Il mese prima Apache era al 58,75%: la quota sale mentre IIS arretra. Sono numeri che fanno di un server Open Source un pezzo ordinario dell’infrastruttura del Web. Conviene guardare come è fatto e come viene tenuto in piedi, perché le due cose si tengono.

Contesto

Apache nasce nel 1995 da un gruppo di amministratori che mantenevano patch sparse per NCSA HTTPd, il server il cui sviluppo si era fermato. Raccogliere quelle patch in una distribuzione coerente — “a patchy server” — è l’origine del nome e del progetto. La versione stabile in produzione oggi è la 1.3, con la 1.3.17 rilasciata a gennaio 2001; gira su Unix, Linux e Windows. In parallelo procede la 2.0, ancora allo stadio alpha.

Per chi lo installa e per chi lo studia è lo stesso oggetto: un binario che ascolta su una porta TCP, parla HTTP/1.1 (RFC 2616, giugno 1999) e mappa le richieste su file o handler. A distinguerlo sono due cose: come gestisce la concorrenza e come si decide il codice.

Architettura prefork

Apache 1.3 usa un modello prefork. All’avvio il processo padre apre il socket di ascolto, poi genera un gruppo di processi figli; ogni figlio segue una connessione alla volta, dall’accept() alla chiusura, e poi torna in attesa. Il padre non serve richieste: sorveglia i figli e ne aggiusta il numero a seconda del carico, dentro i limiti fissati da MinSpareServers, MaxSpareServers e MaxClients in httpd.conf.

La scelta ha conseguenze precise. Ogni figlio è un processo separato con il proprio spazio di indirizzamento: un segmentation fault in un handler uccide quel figlio e nient’altro, e il padre lo rimpiazza. È la ragione principale per cui la 1.3 regge bene i moduli di terze parti scritti in C, dove un puntatore sbagliato ci scappa sempre. Il prezzo è la memoria: con qualche centinaio di figli, ognuno con la sua copia delle strutture e dei moduli caricati, il consumo cresce in proporzione alla concorrenza. Per molti carichi web — richieste brevi, tanti file statici, picchi che MaxClients tiene a bada — il compromesso regge. Dove le connessioni sono migliaia, lente e tenute aperte, un processo per connessione costa caro.

I moduli estendono il core senza ricompilarlo, linkati staticamente o caricati come oggetti condivisi via mod_so. mod_rewrite riscrive le URL con espressioni regolari; mod_ssl aggiunge TLS appoggiandosi a OpenSSL; mod_proxy fa da proxy diretto e inverso; i virtual host lasciano che un solo host fisico serva centinaia di domini distinti, ognuno con la sua document root. La configurazione vive in httpd.conf e nei file .htaccess, letti per directory a ogni richiesta — comodi per delegare regole senza riavviare, ma con un costo di accesso al filesystem da non dimenticare.

Il punto critico

La 2.0 in sviluppo riscrive proprio lo strato che la 1.3 dà per scontato. Due pezzi.

Il primo sono i Multi-Processing Module (MPM): il modello di concorrenza diventa un modulo intercambiabile invece di una scelta cablata nel core. Su Unix questo apre la strada a un MPM ibrido a processi e thread — un pool di processi, ognuno con più thread che seguono una connessione a testa — che taglia il numero di processi, e quindi la memoria, a parità di connessioni servite. Su Windows un MPM dedicato sostituisce gli adattamenti che la 1.3 era costretta a fare su un sistema senza fork().

Il secondo è l’Apache Portable Runtime (APR), lo strato che astrae socket, memoria, file e thread dietro una sola API, così che i moduli non chiamino direttamente le system call del sistema operativo. Il board dell’ASF ha costituito l’APR come progetto a sé il 20 dicembre 2000: la portabilità smette di essere un effetto collaterale del server e diventa una libreria con vita propria. È la differenza fra “Apache gira anche su Windows” e “c’è una base portabile su cui Apache, e non solo, può girare”.

Implicazioni: licenza e consenso

Il codice è una parte. L’altra è come si decide cosa ci entra, e con quali vincoli viene distribuito.

La licenza è la Apache Software License, nella versione 1.1 adottata nel 2000. Rispetto alla 1.0 ha una clausola in meno: la 1.0 imponeva una frase di attribuzione nei materiali pubblicitari di ogni prodotto derivato — la stessa “advertising clause” che rendeva attritosa la licenza BSD originale quando si mettevano insieme molti componenti. La 1.1 sposta l’attribuzione nella documentazione e la toglie dalla pubblicità. È una licenza permissiva: si può inserire Apache in un prodotto proprietario senza obbligo di rilasciare il sorgente, al contrario della GPL. È in parte il motivo per cui tanti vendor hanno costruito sopra Apache senza attriti legali.

La governance è quella della Apache Software Foundation, costituita nel 1999 come ente non-profit nel Delaware. Il modello è esplicito: i diritti di commit si guadagnano con contributi continui che i pari valutano, le decisioni si prendono per consenso sulla mailing list degli sviluppatori, e dove il consenso non arriva si vota con regole note. Un veto a una modifica al codice va motivato sul piano tecnico, esprimerlo non basta. Il procedimento costa in lentezza ma produce continuità: il progetto non dipende da una sola persona né da una sola azienda, e ha potuto portare avanti la riscrittura profonda della 2.0 senza spaccarsi. La stessa impalcatura l’ASF l’ha estesa ad altri progetti — da Jakarta agli strumenti XML — e ne ha fatto un metodo riusabile più che un caso isolato.

Limiti

I numeri di Netcraft contano nomi di host che rispondono, non macchine né traffico: un 60% sui siti rilevati non si traduce in altrettanto traffico o altrettanti server fisici, e gli host parcheggiati pesano sul totale. Il prefork della 1.3 va misurato sul proprio carico, non in astratto: dove le connessioni sono molte e lente conviene già guardare alla 2.0 in sviluppo, mettendo in conto lo stato alpha. E una licenza permissiva è una scelta, non un assoluto: chi vuole che le modifiche restino aperte trova nella GPL garanzie che la Apache License non dà. Concorrenza, licenza e governance vanno decise insieme: insieme dicono se un server regge in produzione e nel tempo.

https://httpd.apache.org/ https://www.netcraft.com/survey/ https://www.apache.org/licenses/LICENSE-1.1 https://www.apache.org/foundation/ https://www.ietf.org/rfc/rfc2616.txt https://www.noze.it/insights/apache-httpd-open-source/

Immagine di copertina: Roy Fielding, con barba e occhiali, parla a un microfono durante una conferenza open source — foto di Phil Whitehouse, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Roy_Fielding.jpg