Apache vs. Nginx: quale server scegliere?

Apache vs. Nginx: quale server scegliere?

Apache e Nginx sono le scelte più diffuse a livello di server web open source, tanto che – secondo varie stime – veicolano oltre la metà del traffico web mondiale. Entrambe sono soluzioni tecnicamente molto aggiornate e all’avanguardia, per cui, per molti versi, sono equivalenti: seppur differenti come sintassi delle direttive, ad esempio, è possibile per entrambi effettuare le più comuni operazioni necessarie ai siti web ed i web service (ad esempio, il mod_rewrite per ottenere URL SEO friendly di Apache esiste anche in Nginx, anche se ovviamente nel secondo caso il file .htaccess non potremo più utilizzarlo: ci sono ovviamente delle alternative disponibili).

Da sempre i server sono, silenziosamente (a parte quando danno errori) alla base del funzionamento del web, siti in WordPress inclusi: Apache da un lato ed NGINX dall’altro, le due principali opzioni (anche se non le uniche) in questo settore, che hanno fatto sì che si creasse una certa contrapposizione tra i due.

I rispettivi dettagli tecnici non sono da poco, ma cercheremo di chiarire similarità e differenze di prestazioni per entrambi, in modo comprensibile anche per i meno esperti, con questo articolo. Ogni sito o servizio web si basa infatti su uno dei due, e se ci troveremo nell’imbarazzo di dover optare per uno a vantaggio dell’altro questa guida potrebbe esserci di grande aiuto.

Cos’è NGINX

NGINX è un web server sviluppato da Igor Sysoev per il portale della Ramblermedia, distribuito come software open source: da qui la sua affermazione progressiva, negli ultimi anni, arrivando ad essere il terzo server al mondo, a livello di popolarità, subito dopo Apache e IIS. Un sito su cui ho lavorato qualche tempo fa – CNT – ne fa uso, ed è questo il motivo che mi ha spinto ad approfondire l’argomento.

Generalità sui server Apache e Nginx

Il compito di un web server, semplificando un po’ le cose, è quello di servire – per l’appunto – i contenuti e le richieste generati da un gruppo di client, secondo il modello client-server; in genere si interroga il web server, e tipicamente può farlo:

  • un browser (ad esempio il mio o il tuo);
  • un client REST (ovvero un’altra app);

A questo punto il webserver prende in carico la richiesta e restituisce un risultato (HTML nel prio caso, JSON nel secondo). Il webserver, sia esso Apache o Nginx, si occupa internamente delle modalità di restituzione del risultato, del tipo di cache utilizzata, delle prestazioni e delle risorse necessarie per eseguire la richiesta e così via.

Ovviamente per chi naviga sul web la differenza tra le due tecnologie è impercettibile: per rilevare se un sito stia usando uno o l’altro dovremmo interrogarlo con linea di comando mediante ad esempio per il nostro sito

(da Linux):

wget --save-headers trovalost.it

oppure (da Mac):

curl -I trovalost.it

oppure (sotto Windows Curl va scaricato da qui):

curl -I trovalost.it

oppure, ancora, dovremo fare uso di servizi esterni di generazione degli header HTTP.

La risposta che otterremo, tornando al nostro esempio, sarà qualcosa del tipo (guardate il secondo rigo, nello specifico):

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 18 Nov 2017 14:32:36 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 299
Connection: keep-alive
Location: https://www.trovalost.it/
Vary: Accept-Encoding
X-VHosting-Cache: MISS

Ecco qui: siamo su nginx, in questo caso (l’esempio è orientativo: l’architettura del sito è stata cambiata, nel frattempo). In genere, comunque, non è detto che l’indicazione fornita da questi comandi sia al 100% affidabile, ma è un’indicazione che può essere ritenuta tale – almeno per un’analisi qualitativo-orientativa iniziale.

Confronto in breve tra Nginx e Apache

Nginx e Apache seguono entrambi il modello client server, ma lo gestiscono in modo differente tra di loro: Nginx, sulla carta, si prefigge di superare alcuni limiti progettuali di Apache, risultando (sempre in teoria) più veloce del suo diretto concorrente. Proponiamo ora una tabella comparativa delle principali caratteristiche dei due server.

  Nginx Apache
OS supportati Linux, Unix, MacOS, Windows Linux, Unix, MacOS, Windows
Supporto Free sui forum Free sui forum, corporate support
Costi e sviluppo Free e open source Free e open source
Sicurezza Ottima Ottima
Documentazione Buone Ottime
Prestazioni Ottime Buone
Come funziona (molto in breve) Da' meno opzioni di Apache, ma è sensibilmente più veloce a servire i file statici. Da' molte opzioni ma può essere soggetto a rallentamenti, specie se mal configurato.

Questa tabella probabilmente non dice granchè di suo, ma serve ad introdurre all’argomento: Apache e Nginx sono concepiti per uso similare ma diverso nella politica strategica di gestione, e sono architetturati in modo molto diverso, le differenze tra loro sono abbastanza considerevoli nonostante possano sembrare identici dall’esterno.

Quale è meglio tra nginx e Apache? La risposta non è unica: dipende dai casi, dalle necessità e dalle competenze tecniche che avete a disposizione.

Generalità su Apache

Apache HTTP Server (per gli amici, più semplicemente, Apache, che dovrebbe leggersi “apaci“) è una creatura di Robert McCool risalente alla metà degli anni 90, per cui con un considerevole vissuto; la sua documentazione free e open source è parecchio estesa, e numerose sono state le versioni di questo software che si sono avvicendate. Il più delle volte lo usiamo senza rendercene conto perchè i vari Joomla!, WordPress e compagnia funzionano silenzionsamente mediante esso.

Alla base del funzionamento di Apache vi sono i moduli di multi-processing o MPM, che servono a stabilire proprio la politica di gestione delle richieste dei cliente. Esempi di MPM considerevoli sono ad esempio:

  • mpm_prefork (che gestisceogni richiesta, e non appena queste diventano molto numerose – in particolare oltre particolari soglie prestabilite – ciò si tradurrà in una progressiva saturazione o riempimento della RAM dell’hosting);
  • mpm_worker (simile al precedente ma più performante in certe situazioni);
  • mpm_event (predefinito in Apache 2.4, e che gestisce al meglio le connessioni di tipo keep-alive).

Generalità su nginx

Nginx è più giovane rispetto ad Apache, ma nasce nel 2002 in forma inizialmente sperimentale partendo da un requisito di innovazione ben preciso: la soluzione del problema C10K, ovvero (senza scendere in dettagli tecnici) la possibilità di gestire in modo automatico più di 10 connessioni alla volta da parte di un server.

Per poterlo fare, nginx ha scelto un approccio architetturale event-driven (ad eventi: significa che quando succede qualcosa il server agisce, diversamente rimane in idle) che ha consentito a Nginx di distinguersi per una particolare velocità, soprattutto nel servire rapidamente contenuti statici (mediante la tecnologia di reverse proxy). Nginx al momento vanta di riuscire a far funzionare siti famosi come ad esempio:

  • Netflix
  • Pinterest
  • WordPress.com
  • Airbnb

Nginx ha fatto molta strada fino ad oggi: come Apache, è free e open source e riesce a funzionare sotto qualsiasi sistema operativo. Non dispone, ad oggi, dell’enorme gamma di personalizzazioni di cui dispone Apache, ma viene comunque mantenuto attivo da una community di sviluppatori molto attiva. In generale offre ottime prestazioni evitando l’overload di risorse, ma questo vale soprattutto per i contenuti statici: può essere combinato con FastCGI e load-balanced per ottimizzarne le prestazioni.

Nginx sfrutta un approccio asincrono single-thread per la gestione delle richieste, al contrario di Apache che invece si basa sui multi-thread. Nginx non crea un singolo processo per ogni richiesta di client che gli arriva, e questo per evitare di avere una coda di processi che tendono a sovraffolare le risorse del server; al contrario, usa un singolo master thread e gestisce tutto da lì.

Per collegarsi a PHP e farlo funziona solitamente Nginx usa moduli come php-pfm, ma ce ne sono moltissimi altri e le varianti disponibili sono anche qui molto numerose e variegate.

Confronto in prima istanza tra le due tecnologie

Ad un livello un po’ più approfondito, Apache è fatto di moduli dinamici indipendenti tra loro ed attivabili/disattivabili a piacere; Nginx non usa questo approccio e si presenta come blocco monolitico in cui ogni componente va selezionata e compilata nel core.

Uno stereotipo tecnologico molto diffuso vuole che Apache sia più lento di Nginx, ma questa è solo una parte della storia: la potenza di Nginx esce fuori quando deve restituire contenuti statici, quindi file di grosse dimensioni oppure siti in WordPress che usino correttamente la cache per velocizzare il caricamento delle pagine.

Altro stereotipo riguarda il fatto che Apache consumi molta RAM, ma questo è vero soltanto in alcuni tipi di configurazioni che risultano essere più critiche di altre. Ad esempio, ci sono test sperimentali che mostrano come Apache con mod_php riesca a funzionare meglio di Nginx con php-fpm, per cui ogni configurazione tende a fare storia a sè, alla fine. Bisogna sempre essere ben consapevoli della tecnologia che si usa prima di dire che a prescindere X sia meglio di Y, ed è questo il presupposto su cui cercheremo di scrivere questo post.

Apache usa un approccio orientato ai processi nella gestione delle richieste, al contrario di Nginx che ne usa uno asincrono più moderno. Moltissime sono le funzionalità che Apache tende ad offrire per estendere le funzionalità, come ad esempio il supporto a PHP, Perl, Python, vari moduli di autenticazione e di supporto ad SSL, moduli per riscrivere gli URL e fornire alias facili da ricordare per utenti e motori di ricerca, moduli di log e di filtering, host virtuali (molto usati sugli hosting condivisi), compressione delle pagine con gzip, moduli di sicurezza.

Per collegarsi a PHP e farlo funziona solitamente Apache usa moduli come mod_php, ma ce ne sono moltissimi altri e le varianti disponibili sono molto, molto numerose. Ovviamente anche Nginx offre funzionalità analoghe per proxy, compressione, rate limiter, log, riscrittura degli URI, geolocalizzazione, autenticazione, crittografia, streaming audio/video ed email.

Apache è decentralizzato, Nginx è unificato: il file htaccess

Entriamo ancora un po’ nel dettaglio delle differenza tra queste due tecnologie di web server. Come molti già sapranno, il funzionamento di Apache è molto condizionato dalla presenza di file .htaccess, che sono file di direttive specifiche che possono funzionare per singole directory. Si possono usare per abilitare servizi specifici come il mod_rewrite oppure, ad esempio, per proteggere certe directory o abilitarne alla lettura altre, inserire eventuali password nelle cartelle e così via. Questo consente una gestione molto flessibile e sostanzialmente decentralizzata o distribuita dei nostri servizi web.

Inoltre la rilevazione di modifiche al file .htaccess non richiede di riavviare il server poichè il file di direttive viene interpretato “al volo”, per cui potete rendere effettive le vostre modifiche senza dover fare null’altro: basta caricare il file con le modifiche via SSH o FTP. Lo svantaggio di questo approccio è che ad ogni singola richiesta va controllato se ci sono più file htaccess nell’alberatura della directory, che in genere potrebbe essere incompatibili tra loro, per cui vanno dosati con cura – e soprattutto questo può comportare tempi di risposta sensibilmente più lunghi. Tecnicamente, quindi, per arrivare nel path di una directory via Apache come, ad esempio:

/wp-content/uploads/2017/01/trovalost-wondering_man_alpha_bg-copia.png

Apache deve leggere ogni singolo / (slash) come un cambio di directory (e deve verificare se ci sia un file htaccess all’interno di ognuno) e, di fatto, per questo motivo complica la configurazione e consuma risorse (in teoria) inutilmente. Per leggere quel path, ad esempio, è richiesto un overhead di ben 5 passaggi, per quanti sono il numero di slash.

Nginx al contrario non conosce i file htaccess e li ignora, e non dispone di un meccanismo equivalente analogo, in generale; tuttavia nello specifico permette comunque di disporre dell’equivalente del mod_rewrite detto ngx_http_rewrite_module (che dispone di una sintassi distinta e separata da htaccess). Il vantaggio è che stavolta la gestione è centralizzata e questo, per forza di cose, snellisce il processo di restituzione delle pagine HTML o delle response del server più in generale.

Il fatto che Nginx non “guardi” il proprio file system può sembrare una pecca, ma in realtà è un guadagno enorme in fatto di efficenza computazionale (quindi è effettivamente più veloce in questo senso).

File vs URI-Based Interpretation

Di default Apache tende ad interpretare le richieste come se fossero richieste di risorse fisiche del filesystem (quindi sostanzialmente file in una directory), mentre Nginx permette di implementare sia questo che una visione più orientata agli URI cioè più simile ad un web service moderno (e quindi mediamente più veloce).

Ovviamente resta vero che Apache è pensato come webserver puro mentre Nginx come webservice (web server, oppure server proxy) più evoluto, in cui non vi è conoscenza diretta del filesystem ma solo abilitazione di URI specifici già preconfigurati; ma questo significa anche che il confronto rischia di diventare falsato – e molte comparative sul web secondo me sbagliano a confrontarli in ottiche troppo ristrette e poco consone.

Chi vince il confronto?

A costo di passare per mediocre, credo sinceramente che nessuno dei due lo possa realmente vincere, ad oggi: se è vero che Nginx vince su molti fronti, Apache rimane una scelta sostanziale che in molti continueranno ad adottare, soprattutto per quello che riguarda l’uso massivo di blog in WordPress (già htaccess è difficile da far utilizzare ai meno esperti, figuriamoci toglierlo del tutto e sostituirlo con altro). Del resto la visione di Nginx è vincente sotto vari punti di vista, e lavora per un web veloce ed efficente, per cui rimane un must per la gestione di file statici e servizi di streaming avanzati. Di suo Apache resta una solida alternativa per chiunque volesse sfruttare al meglio le risorse del proprio sito, e specie per i principianti Nginx resta una scelta di nicchia che può essere problematica a lungo andare.

Per testare entrambi potete installare software come MAMP nel vostro Mac o analoghi LAMP per Windows e Linux per capire le differenze tra l’uno e l’altro, e rendervi conto da soli di cosa comporti fare uso dell’uno o dell’altro.

Perchè scegliere nginx e non Apache?

È una buona domanda, e per provare a rispondere proviamo a partire dalla criticità che ha dato a Sysoev, il creatore di NGINX, l’opportunità ed il desiderio di sviluppare un server nuovo. Partiamo da una cosa usatissima in Apache, che sono appunto i file .htaccess: si tratta di file di direttive in semplice formato testo (molto usati per il mod_rewrite, ad esempio), che vengono letti direttamente dalla cartella in cui si trovano. In teoria Apache potrebbe averne più di uno, ad esempio per ogni cartella, e per forza di cosa devono essere letti dal server stesso.

Questo avviene per OGNI SINGOLA RICHIESTA che fate ad Apache, quindi non esattamente uno scherzo: se leggete da un path complicato come quello di un’immagine, sarà necessario leggerlo per ogni singola sottocartella – e lo prova il fatto che se lo modifichiamo non è necessario riavviare il server come invece avverrebbe per il file php.ini, ad esempio.

Prendiamo di nuovo un esempio concreto, cioè l’immagine di copertina di questo articolo (che gira al momento su server Apache):

https://trovalost.it/wp-content/uploads/2014/06/Nginx_webserver.jpg

Abbiamo ben 5 sottocartelle, quindi altrettanti potenziali file .htaccess da cercare e leggere (o comunque almeno 3, nella media dei casi). Nel conto medio del numero di accessi giornalieri, un sito ad alto-medio traffico avrebbe qualcosa come 90 richieste al secondo, ovvero 324,000 accessi al filesystem ed un numero leggermente maggiore di carico di lavoro su NGINX rispetto ad Apache, come è possibile vedere dalla tabella (originale citato in fondo alla pagina):

Il tutto ha portato il creatore di NGINX ad eliminare del tutto i file .htaccess e a non mettere alcun equivalente degli stessi, proprio per non degradare le performance del server.

Per quanto sono riuscito a capire in prima istanza, quindi, un sito in questione ne trae un grosso giovamento in termini di prestazioni soprattutto in relazione a numerosi visitatori (da 40 richieste al secondo a salire, in pratica): è il caso di valutare, quindi, nel dettaglio cosa differenzi nginx dal più noto Apache, e perchè dovremmo scegliere l’uno o l’altro (e a che prezzo, soprattutto). Si tenga conto, inoltre, che nginx ha permesso a wordpress.com di aggirare un problema di sovraccarico di connessioni concorrenti, noto come C10k, che affliggeva il “cugino” Apache da tempo. Andiamo quindi a vedere alcune definizioni avanzate, per poi estendere il discorso nella maniera più semplice e chiara anche per i non esperti.

Apache, noto per esteso col nome Apache HTTP Server, ha storicamente giocato un ruolo chiave per lo sviluppo del World Wide Web: nel 2009 era il primo web server ad essere installato per oltre 100 milioni di siti web. Apache possiede, parlando in termini generali, maggiori funzionalità rispetto a nginx, ma questo non lo rende automaticamente migliore, anzi: esistono contesti nei quali nginx funziona meglio, qualora venga usato ad esempio per servire file statici. Apache possiede un enorme limite per quanto riguarda la gestione della memoria, ed nginx cerca quindi di sopperire questo aspetto. Quando paro di file statici, cmq, non mi riferisco in questo caso a siti web statici, almeno non esclusivamente, ma (per estensione) anche a quelli che utilizzino massivamente la cache: in effetti il sito sopracitato sfrutta in modo piuttosto “presente” un plugin di cache, mettendo il server in condizione (mediante nginx) di risparmiare tempo senza elaborare “a vuoto” lato server, e mandando i file (quando possibile) direttamente al client interessato.

Secondo il blog barryonwordpress, inoltre, nginx sembra essere l’unico webserver con un load balancer capace di gestire senza errori fino a 8000 richieste al secondo, il che confermerebbe che nginx sua perfetto se il vostro blog in WordPress o Drupal, per intenderci, abbia moltissimi visitatori ed altrettanti “picchi” di visite (tipici dei siti adult e di alcuni portali di news). Situazione che si verifica analogamente nel caso in cui possa servirvi un server – scusate per questo terribile gioco di parole – che faccia da reverse proxy (cioè da “filtro” tra il server ed il client, ad esempio per scansare attacchi informatici) oppure come load balancer: attenzione, pero’, che questa affermazione non deve essere fraintesa, perchè tali funzioni sono supportate anche da Apache.

Ma allora perchè non usare tutti nginx, salutando cordialmente Apache che tanto ha fatto per noi? Il problema, come vedremo tra un attimo, è che nginx non è compatibile con le funzioni di Apache che diamo usualmente per scontate (mod_pagespeed, mod_security, mod_rewrite, …), per cui costringe il sistemista ad un refactor notevole della configurazione del sito.

Una cosa importante da capire, comunque, è che Nginx possiede un’architettura event-based ovvero, detta in modo spartano, non necessita di effettuare la creazione di tanti processi per quante richieste siano in esecuzione, ottimizzando l’uso di memoria al contrario di Apache che, in certi casi, può provocare problemi di memoria su WordPress o altri CMS. Apache usa infatti un thread per connessione, mentre nginx lavora in modo asincrono con thread non bloccanti, il che riduce l’uso di RAM ed ottimizza l’esecuzione dei processi. nginx, comunque, ha una sintassi interna differente e non è adatto in ambienti di hosting condiviso, mentre è idealmente molto più agevole da gestire nel caso in cui esista un singolo accesso mediante FTP (VPS o dedicati).

A tal proposito, mentre molti frettolosi potrebbero persuadersi di cambiare Apache con nginx, esiste un controesempio piuttosto clamoroso: immaginiamo uno scenario in cui nginx debba far funzionare WordPress. Ebbene, qualsiasi impostazione del file htaccess sarà ignorata, perchè il server di Sysoev non legge i file htaccess, e per attivare i comunissimi permalink bisogna ricorrere alla seguente configurazione alternativa:

#######################
# Permalinks

if (!-e $request_filename) {
  rewrite ^.*$ /index.php last;
}

oppure

#######################
# Permalinks

try_files $uri $uri/ /index.php?$args;

dopo aver caricato nella home del vostro sito un file apposito tipo wordpress.conf.

Le differenze tra le due architetture server sono comunque, come è facile intuire, piuttosto tecniche, ed è bene non basarsi troppo sulla propria esperienza (se limitata soprattutto) e, come se non bastase, diffidare dalle guide che tendono a presentare questi due mondi come contrapposti o, peggio, nei quali uno è migliore dell’altro a prescindere.

Architetture server ibride: Apache + Nginx

Tutto questo ovviamente non vuol dire che in alcune architettura non sia possibile usarli assieme in soluzioni ibride,  come fa ad esempio V-Hosting , che nelle sue offerte commerciali di hosting condiviso usa un server Apache + un reverse proxy in Nginx abilitabile a piacere dal pannello Plesk. La classica configurazione in questi casi è un’accoppiata molto efficente: Nginx fa da reverse proxy e Apache continua a fare da server, garantendo il supporto ai file htaccess ad esempio. Nginx gestisce le richieste dei client, sfruttando la propria velocità, mentre resta disponibile Apache in sottofondo.

Fonti consultate: fonte, fonte, fonte, fonte, fonte

0 voti


Informazioni sull'autore

Salvatore Capolupo

Consulente SEO, ingegnere informatico e fondatore di Trovalost.it, Pagare.online, Lipercubo.it e tanti altri. Di solito passo inosservato e non ne approfitto.