Skip to content

TLTR

La scelta è chiara:

  • Vuoi praticità vai con Apache
  • Se vuoi velocità scegli NGINX

Introduzione

NGINX vs Apache – quale web server è superiore in termini di prestazioni e sicurezza? Nelle guide per webmaster non poteva mancare questo argomento!

C’è stato un periodo in cui Apache deteneva il primo posto come diffusione tra i web server. Apache girava su più della metà dei server del mondo, tuttavia questo vantaggio è stato eroso fino a quasi un terzo, ed è ancora in calo.

Contemporaneamente, il web server IIS di Microsoft ha raggiunto una popolarità simile, per poi calare negli ultimi anni. Poi è arrivato NGINX (si legge “engine-x”) che, da quando fu sviluppato nel 2004 nella sua prima versione, cresce costantemente anno dopo anno e viene usato da un numero sempre maggiore di siti web.

Perché confrontare NGINX e Apache?

NGINX e Apache sono due software molto diffusi, hanno le medesime funzioni ma caratteristiche e logiche differenti. Ad esempio, il file .htaccess di Apache è comodo per chi ha bisogno di un hosting condiviso, mentre NGINX ha i superpoteri quando lavora con contenuti dinamici e funzionalità più elaborate. Per questo motivo molti webmaster che hanno siti su VPS dedicati preferiscono NGINX.

In questa guida analizzeremo feature-by-feature per valutare quale possa essere il migliore web server. Credo sia importante confrontarli in 6 aree cruciali: prestazioni per contenuti statici e dinamici, supporto del sistema operativo, sicurezza, flessibilità, documentazione e supporto.

Numeri attuali per NGINX e Apache

La quota di mercato può essere calcolata in diversi modi, quindi le cifre che seguono sono approssimative, ma le tendenze generali sono chiare. Se consideriamo solo i siti con il più alto traffico, al momento in cui scrivo Apache e NGINX sono i due leader di marcato. Per darti dei numeri – Apache fa girare il 40% dei siti web mentre NGINX il 33%.

Diffusione dei web server
Fonte: https://trends.builtwith.com/web-server

Come funziona Apache

In passato con Apache era possibile servire siti web dinamici solo attraverso i moduli. Ad esempio, per servire un sito web basato su PHP, Apache usava un modulo chiamato mod_php (modulo, che molti siti usano ancora oggi) e quel modulo usava molta memoria.

Il vero problema era che un processo httpd era in grado di gestire una sola connessione alla volta (pensa al processo httpd come a un programma separato sul vostro server a cui non piace condividere le risorse con altri programmi). Quindi, anche se il web server stava servendo solo file statici come file CSS, JavaScript o immagini, Apache usava processi separati per servirli e consumava tutta la memoria extra. Mentre Nginx utilizzava la cosiddetta architettura basata su eventi che consentiva a un singolo processo di gestire centinaia di connessioni.

Quello che forse non sai è che nella versione 2.4 (che esiste dal 2012), Apache può usare lo stesso metodo per gestire le connessioni, per le quali Nginx era famoso. Sì, ora un singolo processo Apache può gestire decine, centinaia o addirittura migliaia di connessioni.

LAMP (Linux, Apache, MySQL, PHP) è un popolare web stack al giorno d’oggi, e Apache ne è il componente server web. Sebbene ci siano diversi altri componenti dello stack Web (ad es. NodeJS, framework JS per i rich client, vari servizi cloud, ecc.), LAMP rimane il favorito per molti webmaster.

È possibile aggiungere 60 moduli ufficiali e vari moduli non ufficiali per potenziare il server Web Apache con una vasta gamma di nuove funzioni. Apache ha escogitato alcuni approcci diversi per soddisfare le richieste degli utenti. Negli ultimi anni infatti, le dimensioni delle pagine web sono cresciute ed anche gli utenti che navigano sono aumentati. Era critico per Apache potenziarsi per far fronte alle crescenti richieste dei client.

La metodologia di elaborazione delle richieste Apache può essere impostata in tre modi diversi. Ecco una spiegazione dei tre principali Multi-Processing Modules (MPM):

  • Processes (mpm_prefork): questo è il metodo originale “pre-fork”; non si adatta bene a un numero elevato di connessioni simultanee, poiché utilizza quantità elevate di RAM e può persino rifiutare le connessioni quando i carichi sono elevati. Questo metodo diventa problematico per siti di grandi dimensioni.
  • Events (mpm_event): assomiglia al “Worker model”, ma crea un thread listener che ascolta le connessioni e le passa a un thread di lavoro per l’elaborazione. Questo MPM si prende cura delle connessioni di lunga durata in modo molto più efficiente su un singolo thread grazie alla gestione del KeepAlive. Con Apache 2.4 questo modello di eventi è stato dichiarato stabile e ora è anche l’impostazione predefinita, se il sistema operativo può supportarlo. Puoi anche provare le opzioni compile-time e run-time per migliorare le prestazioni di Apache.
  • Worker model (mpm_worker): viene stabilito un processo di controllo che crea ulteriori sotto processi. Ognuno di questi genera un determinato numero di thread, insieme a un thread listener. Il thread listener ascolta le connessioni e le passa a un thread per l’elaborazione quando arrivano. Questo modello scala in modo più efficace rispetto al metodo pre-fork (Processes), ma può comunque incontrare problemi di ridimensionamento con siti ad alto traffico, poiché il singolo processo di controllo crea un collo di bottiglia.

Come funziona NGINX

NGINX è nato in seguito ad un estenuante test in cui un server doveva raggiungere e mantenere 10.000 connessioni client contemporaneamente. Per poter gestire un tale carico utilizza un’architettura non sincronizzata basata sugli eventi. Inoltre, per ottenere risultati più efficienti sfrutta le previsioni per l’utilizzo della RAM, l’utilizzo della CPU e la latenza.

NGINX si approccia ai modelli di eventi in modo leggermente diverso da Apache perché non imposta processi di lavoro aggiuntivi per ciascuna connessione. Di solito, NGINX è meglio configurato per eseguire un processo di lavoro per ogni CPU in modo da massimizzare l’efficienza dell’hardware.

Offre anche numerose funzioni che lo rendono adatto a diversi ruoli. Ad esempio, un server proxy inverso per i protocolli HTTP, HTTPS, SMTP, POP3 e IMAP, un load balancer e una cache HTTP. Inoltre, NGINX può essere usato assieme ad Apache come proxy di frontend, sposando la flessibilità di Apache con le eccellenti capacità di gestione dei contenuti statici di NGINX.

NGINX offre supporto a FastCGI e SCGI per la gestione degli script PHP e Python. Usa lo stack LEMP: una variazione di LAMP usando la grafia fonetica di NGINX (Linux, “En-juhn-ex”, MySQL, PHP).

Apache vs NGINX – confronto dettagliato

In questa sezione andrò a confrontare i comportamenti dei due web server in diverse condizioni e vedremo come Apache sia più adatto in certe circostanze mentre NGINX in altre.

Prestazioni

Confrontiamo le prestazioni dei due web server quando devono fornire contenuto sia statico che dinamico.

Contenuto statico

Secondo un benchmark, quando deve fornire contenuto statico e fino a 1.000 connessioni simultanee, NGINX esegue il compito 2,5 volte più velocemente di Apache.

Un altro benchmark con 512 connessioni simultanee, ha dimostrato che NGINX è circa il doppio più veloce e consuma un meno memoria (4%).

Senza dubbio, NGINX ha il vantaggio su Apache con il contenuto statico. Quindi, se hai bisogno di servire molti contenuti statici allo stesso momento, NGINX vince in questo segmento.

Contenuto dinamico

Un benchmark del 2015 che ha confrontato i contenuti dinamici serviti da Apache e NGINX ha rivelato che Apache event MPM, quando collegato con il modulo PHP-FPM, può gestire gli stessi volumi di richieste di NGINX con PHP.

In termini di PHP (e probabilmente anche di altri linguaggi), le prestazioni dinamiche dei due web server sono praticamente le stesse con una corretta configurazione del modulo Apache (PHP-FPM + FastCGI). Se è necessario ottenere maggiore velocità dalle pagine dinamiche, sono disponibili alcune opzioni: aggiungere un livello di memorizzazione nella cache Varnish o Memcached, passare a un runtime PHP più veloce (ad es. HHVM), eseguire il bilanciamento del carico (load balancer) o investire in hardware aggiuntivo.

Sfortunatamente per NGINX, fare un lavoro migliore nel servire pagine statiche non lo rende altrettanto efficiente con le pagine dinamiche. In effetti, entrambi i web server offrono prestazioni più o meno simili in quest’area.

Supporto del sistema operativo

Apache funziona con tutti i tipi di sistemi simili a Unix (come Linux o BSD) e supporta pienamente Microsoft Windows.

NGINX funziona sulle distribuzioni Linux e ha qualche supporto per Windows, ma le prestazioni non sono alte come su Linux. Apache ha il vantaggio di essere più performante su Windows, anche se web server targati Microsoft se ne vedono relativamente pochi.

Sicurezza

Entrambi i candidati hanno un eccellente livello di sicurezza per il loro codice basato su C. Il codice di NGINX è meno esteso, il che è un notevole vantaggio dal punto di vista della sicurezza.

NGINX mantiene un elenco di recenti avvisi di sicurezza e, sul suo blog, offre risorse per far fronte alle minacce DDoS.

Apache offre suggerimenti di configurazione per la gestione degli attacchi DDoS, incluso il modulo mod evasive per gestire attacchi DoS, DDoS o brute force HTTP.

Cache

Nginx è superiore ad Apache in quanto al sistema di caching, ovvero salvare in locale le pagine generate dinamicamente da ciascun URL del sito. Nginx usa nativamente fastCGI, mentre Apache deve usare l’acceleratore HTTP di Varnish, che ha prestazioni inferiori, oppure mod_cache, modulo che crea diverse incompatibilità con altri moduli.

Flessibilità

Il web server può essere personalizzato attraverso moduli. Apache ha offerto il caricamento dinamico dei moduli per anni, quindi tutti i moduli Apache possono essere caricati dinamicamente.

NGINX ha ottenuto il supporto per il caricamento dinamico dei moduli all’inizio del 2016. Prima di ciò, l’amministratore doveva compilare i moduli nel codice binario di NGINX. La maggior parte dei moduli non supporta ancora il caricamento dinamico, ma questo cambierà nel tempo.

Apache è ovviamente più avanti qui.

Apache e NGINX – moduli

Sia Apache che NGINX offrono molti moduli che aggiungono funzionalità specifiche.

Moduli Apache

  • Moduli ufficiali (li trovi nella sezione Moduli della documentazione di Apache)
  • Elenco dei moduli di Wikipedia

Al momento, non sembra esserci un elenco aggiornato di tutti i moduli di terze parti. NGINX e Apache hanno situazioni molto simili dato che entrambi offrono set di funzionalità ben strutturate e in continua espansione, ma ogni server Web eccelle per cose che l’altro non può eguagliare.

Moduli NGINX

È difficile stabilire quale web server sia migliore in questa sezione, la maggior parte delle funzionalità necessarie del modulo principale (ad es. Proxying, cache, bilanciamento del carico, ecc.) è presente in entrambi i web server.

NGINX è migliore come proxy inverso per le connessioni TCP ed e-mail (SMTP, IMAP, POP3). Per quanto riguarda i moduli di streaming multimediale, la versione commerciale NGINX Plus sembra essere ancora meglio.

Configurazione distribuita o centralizzata

Per gli amministratori, una delle differenze più evidenti tra questi due software è se la configurazione a livello di directory è consentita all’interno delle directory di contenuto.

Apache

Apache include un’opzione per consentire una configurazione aggiuntiva su base directory, esaminando e interpretando le direttive in file nascosti all’interno delle stesse directory di contenuto. Questi file sono noti come file .htaccess.

Poiché questi file risiedono all’interno delle stesse directory di contenuto, quando gestisce una richiesta, Apache controlla ogni componente del percorso del file richiesto e applica le direttive del file .htaccess. Ciò consente effettivamente una configurazione decentralizzata del server Web, che viene spesso utilizzata per implementare riscritture URL, restrizioni di accesso, autorizzazione e autenticazione, anche politiche di memorizzazione nella cache a livello di singole cartelle.

Mentre gli esempi sopra citati possono essere tutti configurati nel file di configurazione principale di Apache, i file .htaccess presentano alcuni importanti vantaggi. Innanzitutto, poiché vengono interpretati ogni volta che vengono trovati lungo un percorso di richiesta, vengono implementati immediatamente senza ricaricare il server (una modifica al file .htaccess non richiede di riavviare la macchina o il servizio Apache). In secondo luogo, consente agli utenti non privilegiati di controllare determinati aspetti del proprio contenuto senza dare loro il controllo dell’intero file di configurazione.

Ciò fornisce un modo semplice per determinati software Web, come i sistemi di gestione dei contenuti – CMS, per configurare il proprio ambiente senza fornire accesso al file di configurazione centrale. Questo è anche usato dai provider di hosting condiviso per mantenere il controllo della configurazione principale del web server mentre dà ai clienti il ​​controllo sulle loro directory specifiche.

NGINX

Nginx non interpreta i file .htaccess, né fornisce alcun meccanismo per valutare la configurazione per directory al di fuori del file di configurazione principale. Questo può essere meno flessibile del modello Apache, ma ha i suoi vantaggi.

Il miglioramento più notevole rispetto al sistema .htaccess della configurazione a livello di directory è il miglioramento delle prestazioni. Per una tipica configurazione di Apache che può consentire .htaccess in qualsiasi directory, il server controllerà questi file in ognuna delle directory madri che portano al file richiesto, per ogni richiesta. Se uno o più file .htaccess vengono trovati durante questa ricerca, devono essere letti e interpretati. Non consentendo l’override della directory, Nginx può servire le richieste più velocemente facendo una sola ricerca di directory e file letti per ogni richiesta.

Un altro vantaggio è legato alla sicurezza. La distribuzione dell’accesso alla configurazione a livello di directory distribuisce anche la responsabilità della sicurezza ai singoli utenti, che potrebbero non essere considerati affidabili per gestire bene questa attività. Garantire che l’amministratore mantenga il controllo dell’intero server può prevenire alcuni errori di sicurezza che possono verificarsi quando l’accesso viene dato ad altre parti.

Tieni presente che volendo è possibile disattivare l’interpretazione di .htaccess in Apache.

Come abbiamo visto quindi NGINX non supporta un equivalente del file .htaccess di Apache. I file .htaccess consentono agli utenti di aggirare le impostazioni di sistema per ogni directory specificata; ma per un funzionamento ottimale, le direttive .htaccess dovrebbero essere incluse nei file di configurazione principale se possibile. Questa cosa non si può fare con gli hosting condivisi, ma per gli utenti di hosting condiviso il file .htaccess offre una maggiore flessibilità.

Documentazione

Entrambe le documentazioni di Apache e NGINX sono eccellenti, incluso il wiki di NGINX. NGINX offre sessioni di formazione in loco e online che coprono molti argomenti e offrono anche esami e certificazioni.

Supporto di Apache vs NGINX

Apache offre supporto per l’utente tramite mailing list, IRC e Stack Overflow. Il supporto a pagamento di Apache viene fornito da società terze come OpenLogic, ma non esiste un elenco ufficiale di queste società tra cui scegliere.

Il supporto per NGINX è in linea con Apache e c’è anche un forum. La società dietro NGINX vende un prodotto commerciale chiamato NGINX Plus, che supporta una serie di funzionalità aggiuntive che coprono il bilanciamento del carico, lo streaming multimediale e il monitoraggio.

Quindi chi vince: Apache vs NGINX?

I due web server competono bene l’uno con l’altro nella maggior parte delle situazioni. Io preferisco NGINX, che uso con piacere dal 2012 per questo sito, quando abbandonai definitivamente l’hosting condiviso.

Apache httpd è un ottimo server web e il nuovo modulo mpm_event lo porta a livelli completamente nuovi.

NGINX è senza dubbio migliore nel fornire contenuti statici, ma per i contenuti dinamici è abbastanza simile ad Apache come prestazioni. NGINX si distingue per alcune delle sue funzionalità più avanzate come lo streaming multimediale, proxy inverso per protocolli non HTTP, insieme al supporto commerciale e alla formazione. NGINX è popolare per hosting VPS, hosting dedicati e cluster.

Gli utenti di hosting condiviso potrebbero trovare più comodo lavorare con il file .htaccess di Apache e Apache gestisce molti moduli dinamici. Qualcosa che NGINX ha aggiunto solo di recente.

I proprietari di siti Web che ottengono molto traffico e che forniscono molti contenuti statici e/o streaming multimediali preferiscono NGINX, ma entrambi i web server faranno un lavoro perfettamente accettabile nella maggior parte delle altre situazioni di utilizzo del sito web.

Indipendentemente dal web server che scegli, avrai comunque bisogno di un provider di hosting Linux affidabile per i tuoi server condivisi o virtuali.

Articoli correlati

Autore

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Ultimi articoli aggiornati

Richiedi un preventivo SEO e Google Ads

Porta il tuo sito web al livello successivo con l’expertise di EVE Milano. La nostra agenzia di Search Marketing ha ricevuto oltre 1123 richieste di preventivo, un segnale chiaro della fiducia che imprenditori e manager, come te, ripongono nella nostra specializzazione tecnica e verticale nella SEO e PPC. Se la tua organizzazione cerca competenze specifiche per emergere nei risultati di Google, noi siamo pronti a fornire quel valore aggiunto. Affidati alla nostra esperienza per fare la differenza.
Richiedi un preventivo

Non perderti altre guide, iscriviti per ricevere un avviso mensile con gli aggiornamenti del blog!

Iscriviti alla newsletter!

Informativa sui cookies

Noi e terze parti selezionate utilizziamo cookie o tecnologie simili per finalità tecniche e, con il tuo consenso, anche per le finalità di esperienza e misurazione come specificato nella cookie policy. Puoi liberamente prestare, rifiutare o revocare il tuo consenso, in qualsiasi momento, accedendo al pannello delle preferenze. Il rifiuto del consenso può rendere non disponibili le relative funzioni. Usa il pulsante “Accetta” per acconsentire. Usa il pulsante “Rifiuta” per continuare senza accettare.