Il mondo dei web server: Apache vs. Nginx

Introduzione ad Apache e Nginx

I server web e i protocolli sono progettati per consentire agli utenti di visualizzare le pagine web. Inviano una richiesta di visualizzazione di un documento che viene accettata dal server. L'host quindi, in sostanza, serve il documento o le informazioni al visitatore. Il server web svolge un ruolo centrale nel consentire la visualizzazione e l'accesso alle pagine web sul browser.

Ci sono molti server web che puoi utilizzare a questo scopo. Tra i più popolari ci sono Nginx e Apache. Di fatto, questi server ospitano la maggior parte dei siti web attualmente disponibili su Internet.

Apache e Nginx sono piuttosto simili sotto molti aspetti. Per cominciare, entrambi i server web sono open-source. Questo significa che chiunque al mondo può utilizzarli a costo zero. Ma ci sono molte caratteristiche uniche per ciascuno dei server. Queste caratteristiche speciali li rendono ideali per varie applicazioni e scopi.

Per aiutarti a decidere quale server web sia superiore o ideale per te, confronteremo Nginx e Apache. Il confronto verrà effettuato sulla base di una serie di parametri essenziali che sono critici per gli utenti dei server web. Cominciamo!

Panoramica di base

Inizieremo con una panoramica generale dei due server web. Sia Apache che Nginx si sono costruiti un'ottima reputazione nella community. Sono acclamati per le loro prestazioni e utilizzati da diverse organizzazioni di spicco in tutto il mondo.

Apache

Apache è uscito nel 1995. Robert McCool ha sviluppato questo server HTTP sotto la Apache Software Foundation, da cui il nome. Fin dal suo rilascio, centinaia di migliaia di persone in tutto il mondo utilizzano Apache.

La sua enorme popolarità fa sì che molti software e fonti di terze parti collaborino frequentemente con esso. Pertanto, se stai cercando una buona rete di supporto con molte integrazioni, Apache è quello che fa per te. Apache è preferibile per molte persone anche perché è più dinamico e flessibile. Offre inoltre una gamma più ampia di linguaggi che può interpretare.

Nginx

Nginx è un server web relativamente più recente, uscito nel 2004. È il risultato degli sforzi di Igor Syosev per affrontare quello che oggi è noto come il problema C10K. Questo problema è sorto quando ha iniziato a diventare difficile per i server gestire grandi quantità di traffico. Man mano che sempre più persone iniziavano a usare Internet, i server dei siti web hanno iniziato a essere sovraccaricati. L'incapacità di questi server di gestire diverse migliaia di connessioni contemporaneamente causava il crash e il malfunzionamento dei siti.

Nginx è stato rilasciato nel tentativo di risolvere questo problema. Ecco perché la sua architettura ha un design incredibilmente leggero, in grado di funzionare con risorse e hardware limitati. Sebbene sia più adatto a funzionare con contenuti statici, può integrarsi anche con software in grado di gestire adeguatamente i contenuti dinamici.

Capacità di gestione del traffico

Ora che abbiamo un'idea di base di ciascuno dei server, possiamo entrare più nel dettaglio. La prima caratteristica con cui inizieremo sono le capacità di gestione del traffico dei singoli server. Questo è uno dei punti principali che differenzia queste due piattaforme. Le loro architetture funzionano su principi diversi quando si tratta di gestire più connessioni contemporaneamente.

Apache

Apache utilizza qualcosa chiamato MPM- Multi-Processing ModulesGli amministratori utilizzano una varietà di MPM per manipolare e modificare l'architettura di gestione delle connessioni. Parte dell'attrattiva del server web Apache è la flessibilità offerta dalla sua architettura. Un'infrastruttura basata su moduli di questo tipo, che suddivide l'elaborazione in thread singoli e di gruppo, rende più facile la scalabilità e l'adattamento a diversi tipi di connessioni.

Diamo un’occhiata ad alcuni dei singoli moduli utilizzati in Apache:

• mpm_prefork

Il primo è mpm_prefork. Questo è un modulo di elaborazione responsabile della gestione delle richieste in arrivo dai visitatori. Crea un thread o processo figlio per gestire una connessione in qualsiasi momento. Ciò significa che se il numero di richieste è inferiore al numero di processi, mpm_prefork è piuttosto efficiente nella sua funzione.

Le richieste vengono elaborate rapidamente poiché un processo figlio separato gestisce ciascuna di esse singolarmente. Ma questo significa anche che se il numero di richieste supera il numero di processi, le cose possono rallentare notevolmente. Di conseguenza, la fase di elaborazione delle richieste consuma molta RAM.

• mpm_worker

Come già sappiamo, un thread è responsabile di una connessione. Questo modulo fa un passo avanti e consente di gestire più thread contemporaneamente. Si tratta di un modulo molto più scalabile rispetto a mpm_prefork, che fatica oltre una certa soglia. Le nuove connessioni possono collegarsi immediatamente a un thread invece di dover attendere.

• mpm_event

Mpm_event è responsabile del mantenimento delle connessioni keep-alive. Lo scopo principale di questo modulo è evitare che il sistema si blocchi a causa delle richieste keep-alive. Lo fa assegnando un thread a una connessione anche in assenza di una richiesta attiva. Il thread rimarrà dedicato finché la connessione è attiva. Eventuali richieste in arrivo vengono trasferite a thread liberi.

Nginx

A differenza di Apache, Nginx è stato creato con uno scopo ben preciso. Conoscevamo già i problemi che stavano sorgendo con la connessione e la scalabilità a questo livello. Ecco perché utilizza un algoritmo asincrono e non bloccante. Non dedica singoli thread a ciascuna connessione. Al contrario, Nginx produce numerosi processi worker in grado di gestire migliaia di connessioni contemporaneamente.

Il principio di funzionamento alla base dell'architettura di Nginx è il meccanismo di loop rapido. Questo algoritmo elabora costantemente gli eventi e li monitora. Ciò significa che i processi sono guidati dagli eventi e ogni processo worker è dedicato solo alle proprie connessioni. Tutte le connessioni di un processo worker si trovano in un ciclo di eventi. Qui coesistono e vengono elaborate in modo asincrono rispetto alle altre connessioni gestite da questo specifico worker.

Il vantaggio principale di una tale architettura è che consente una grande capacità di scalabilità. Questo diventa particolarmente applicabile se si dispone di risorse limitate o si desidera lavorare con un hardware minimo. Anche in presenza di grandi volumi di traffico, l'impatto sull'utilizzo della RAM sarà minimo. Questo perché non si generano thread individuali per ogni connessione.

Gestione dei contenuti statici e dinamici

Un altro parametro che possiamo utilizzare per confrontare i due server web è il modo in cui gestiscono i contenuti statici e dinamici.

Apache

Apache utilizza un metodo basato su file per gestire i contenuti statici. Il suo sistema di elaborazione MPM gli consente di lavorare con questo metodo convenzionale.

Quando si tratta di elaborare contenuti dinamici, Apache può farlo senza bisogno di assistenza da parte di componenti esterni. È possibile abilitare i processori dinamici caricando un modulo. Questo modulo elaborerà il contenuto analizzando il linguaggio e quindi integrando il processore pertinente nel worker.

Il vantaggio principale di non dover utilizzare componenti esterni per elaborare i contenuti dinamici è evidente durante la configurazione e il coordinamento. È molto più semplice coordinare solo i componenti interni tra loro.

Nginx

La differenza più grande tra il modo in cui Apache e Nginx gestiscono i contenuti è che Nginx è semplicemente incapace di elaborare contenuti dinamici internamente. Deve essere associato a un componente esterno per elaborare le richieste di contenuti dinamici. Ciò significa che sarà necessario utilizzare il server Nginx in combinazione con un processore esterno. Il componente riceverà la richiesta di PHP/contenuti dinamici, la elaborerà e poi la invierà nuovamente al server.

Poiché le informazioni devono essere trasmesse tra i due componenti, sarà necessario coordinare la comunicazione tra di essi. Dovrai determinare quante connessioni consentire e configurare il protocollo. Dovrai utilizzare il protocollo che può essere letto e compreso da Nginx, come HTTP, FastCGI, SCGI, uWSGI o memcache, tra gli altri.

D'altra parte, Nginx si comporta davvero bene con la gestione dei contenuti statici. Ha bisogno di aiuto da fonti esterne per farlo. Inoltre, attiverà l'interprete solo quando ne avrà bisogno. Questo è uno dei vantaggi dell'utilizzo di Nginx. L'interprete non è integrato nel processo. Ciò significa che sarà presente solo per l'elaborazione dei contenuti dinamici.

Directory dei contenuti: configurazione distribuita vs centralizzata

Ogni web server ha la propria directory dei contenuti. Uno dei parametri più critici su cui giudicare Apache e Nginx è se consentano o meno la configurazione a livello di directory.

Apache

Ci sono alcuni file nascosti nelle directory dei contenuti che contengono direttive. Questi sono i file .htaccess. Con Apache, puoi interpretare queste direttive per singola directory. Pertanto, quando invii una richiesta, Apache esaminerà il percorso del file per trovare un file .htaccess. Quando lo trova, interpreterà e applicherà immediatamente le direttive al suo interno. Apache non riavvierà il server per implementare queste direttive.

Il processo sopra definito consente una configurazione decentralizzata delle directory nel web server. La configurazione decentralizzata è utile per le riscrutture degli URL, l'implementazione di restrizioni di accesso, la conferma delle autorizzazioni e l'impostazione delle politiche di caching.

Uno dei vantaggi del file .htaccess è che l'utente, che non dispone di autenticazione, può controllare e modificare almeno alcuni aspetti del contenuto che sta visualizzando nel proprio browser. Ecco perché Apache viene frequentemente utilizzato dai provider di hosting condiviso. I fornitori di servizi hanno l'accesso autorizzato alla configurazione centrale. I clienti sono in grado di esercitare il controllo su determinate directory senza avere accesso alla configurazione principale.

Se lo desideri, è possibile disattivare l'interpretazione di .htaccess in Apache.

Nginx

A differenza di Apache, Nginx non funziona con i file .htaccess. Questo lo rende comparativamente meno flessibile. Tuttavia, Nginx introduce invece una serie di miglioramenti nel suo stile di configurazione. Per cominciare, è in grado di elaborare le richieste a una velocità molto superiore rispetto ad Apache. Questo perché non cerca, legge, interpreta e quindi applica ogni file .htaccess che trova nel suo percorso. Invece di cercare in ogni directory genitore, Nginx esegue solo una ricerca di directory per singola richiesta.

Inoltre, Nginx presenta un importante vantaggio in termini di sicurezza rispetto ad Apache. Nginx non cede alcuna parte della configurazione delle directory dei contenuti ai singoli utenti, a differenza di Apache. Sebbene tu possa mantenere rigide misure di sicurezza, chi dice che i singoli utenti siano in grado di fare lo stesso? Con Nginx, mantieni il controllo sullo stato di sicurezza e sulla configurazione dell'intera rete di directory.

Interpretazione della richiesta

Un altro modo per differenziare i due server è il modo in cui interpretano le richieste.

Apache

Quando il server riceve una richiesta, la interpreta e poi la collega alle risorse di sistema pertinenti. Interpreta la richiesta come una risorsa fisica sul filesystem o come una URI posizione.

Quando viene interpretata come risorsa fisica, utilizza i blocchi <Directory> o <Files>  . Questo è il metodo di interpretazione predefinito per il server. Prende la radice del documento. Quindi, segue l'host e il numero di porta nella richiesta per trovare il file pertinente nell'albero dei documenti.

La posizione URI, d'altra parte, richiede una valutazione astratta. Quindi Apache impiega i blocchi <Location> per le risorse astratte invece di lavorare con il filesystem.

Oltre all'URI, esistono diverse altre alternative all'uso del sistema predefinito basato su file. Ad esempio, è possibile utilizzare la direttiva Alias per trovare una posizione alternativa a cui mappare. È inoltre possibile utilizzare varianti di espressione per rendere più flessibile la configurazione del file system.

Nginx

Mentre Apache è nato per essere un server web, Nginx svolge un duplice ruolo sia come server web che come proxy server. Ecco perché, invece di orientarsi verso il file system, Nginx preferisce lavorare con gli URI. È possibile visualizzare questa preferenza dal fatto che in Nginx non c'è modo di specificare la configurazione per una directory del file system. Tuttavia, può tradurla nel file system se e quando richiesto.

Server e location sono i blocchi di configurazione utilizzati principalmente in Nginx. Il primo interpreta l'host richiesto. Il secondo fa corrispondere le parti dell'URI successive all'host e alla porta. Di conseguenza, il server interpreta la richiesta come una posizione URI anziché come un file effettivo sul sistema.

Grazie al suo sistema di interpretazione basato su URI, Nginx è in grado di svolgere il suo ruolo di server web, proxy server e server di posta. Poiché non fa riferimento al file system durante l'interpretazione della richiesta, è comprensibile perché non implementi nemmeno i file .htaccess.

Sistemi di moduli

Sebbene sia Apache che Nginx offrano sistemi di moduli di supporto per l'estensione, vi sono alcune differenze sostanziali nel loro funzionamento interno.

Apache

Con Apache, è possibile caricare e scaricare dinamicamente i moduli durante l'esecuzione del server. Il core rimane al centro dei processi e i moduli servono a estendere le funzionalità. È possibile utilizzare questi moduli collegabili per eseguire una serie di attività. Le opzioni sono praticamente infinite grazie alla vasta libreria di Apache.

In effetti, è persino possibile modificare la funzione del core del server utilizzando moduli come mod_php. Come abbiamo accennato in precedenza, questo modulo consente di incorporare un interprete PHP nei singoli processi worker. Questo è utile quando è necessario elaborare contenuti dinamici.

Ma la storia non finisce qui. È inoltre possibile aggiungere moduli per abilitare funzioni quali l'autenticazione dei client, l'hardening del server, la memorizzazione nella cache, la riscrittura degli URL, i proxy, il rate limiting, la compressione e la crittografia.

Nginx

Il sistema di moduli di Nginx è diverso nel senso che non è possibile caricare dinamicamente i moduli sul server principale. Devono invece essere raccolti e compilati sul software core. Questo lascia molto a desiderare in termini di flessibilità e facilità d'uso. Sebbene i pacchetti di distribuzione contengano alcuni moduli comuni, per altri moduli sarà necessario compilare il server. Pertanto, è necessario sapere come gestire il software compilato al di fuori del sistema di pacchetti tradizionale.

In ogni caso, il vantaggio di questo sistema di moduli non standard è che offre un elevato grado di specificità. È possibile personalizzare i moduli incorporando solo le funzionalità necessarie. Ciò consente di tralasciare i componenti non necessari, evitando al contempo rischi per la sicurezza nel processo. Allo stesso tempo, con i moduli di Nginx è possibile eseguire le stesse attività di Apache. Queste includono la riscrittura degli URL, la registrazione (logging), l'autenticazione e così via.

Ecosistema e supporto

Le integrazioni e il supporto software sono molto importanti quando si parla di server web. Successivamente, esploreremo la compatibilità e il supporto disponibili per Apache e Nginx.

Apache

Apache è una piattaforma più vecchia e più popolare. Di conseguenza, è comprensibile che disponga di una gamma più ampia di strumenti e software di supporto rispetto a Nginx. C'è una gran quantità di documentazione di terze parti a disposizione per supportare il server core. Non solo, ma è anche possibile abbinarlo ad altri software per svolgere compiti specifici. È possibile aggiungere questi strumenti al proprio progetto o al proprio pacchetto. Sono in grado di eseguire facilmente il bootstrap all'interno dell'ecosistema Apache.

Nginx

Sebbene Nginx sia dietro ad Apache sotto questo aspetto, sta sicuramente facendo del suo meglio per recuperare terreno. Sempre più persone stanno adottando Nginx man mano che ne comprendono appieno il potenziale. Il supporto per la piattaforma continua a crescere insieme alla sua crescita organica come server web utile e ad elaborazione rapida.

Uno dei principali ostacoli di supporto che Nginx ha dovuto superare è stato trovare la documentazione in lingua inglese. Questo perché la maggior parte di Nginx è stata originariamente scritta in lingua russa, compresa gran parte della sua documentazione. Tuttavia, man mano che il server si è diffuso ed è diventato più rinomato, sono ora disponibili numerose risorse di terze parti nella lingua universale.

Una soluzione collaborativa?

Ora hai una comprensione molto migliore dei componenti essenziali e del funzionamento interno di Apache e Nginx. Sebbene siano piuttosto diversi tra loro, alcuni utenti sfruttano questo fatto per ottenere il meglio dall’uno e dall’altro. Proprio così: è possibile utilizzare Apache e Nginx insieme.

Convenzionalmente, gli utenti tendono a utilizzare Nginx come reverse proxy e a posizionarlo davanti ad Apache. Ciò consente di compensare la mancanza di velocità di Apache nella gestione e nell'elaborazione delle richieste. Nginx riceve e gestisce tutte le richieste mentre è al massimo della sua velocità. Consente inoltre di gestire rapidamente un gran numero di richieste simultanee senza dover investire molte risorse.

Un'altra caratteristica di Nginx che gli utenti sfruttano è la sua capacità di gestire i contenuti statici in modo efficiente. Per compensare il fatto che Nginx necessita di un componente esterno per elaborare i contenuti dinamici, possiamo reindirizzare PHP e altre richieste pertinenti ad Apache tramite un proxy. Apache tradurrà la richiesta in una pagina web e la invierà nuovamente a Nginx in modo che possa servirla al client.

Ecco alcune risorse che puoi trovare sul nostro blog che possono aiutarti a iniziare con entrambi i server web:

Apache

• Installazione del server Apache su Ubuntu 18.04: una guida pratica
• Configurazione di Apache Virtual Host su Ubuntu 20.04
• Come installare lo stack Linux, Apache, MySQL, PHP (LAMP) su CentOS 7
• Proteggere Apache con Let’s Encrypt su Ubuntu 18.04

Nginx

• Installazione di Nginx su Ubuntu 18.04
• Automatizzare i rinnovi dei certificati SSL di LetsEncrypt per Nginx
• Come proteggere Nginx con Let’s Encrypt su Ubuntu 20.04
• Come installare lo stack LEMP (Linux, Nginx, MySQL PHP) su Ubuntu 20.04

Conclusione

Alla fine dei conti, sia Apache che Nginx hanno i loro punti di forza e di debolezza. Non esistono regole rigide o raccomandazioni su quale server utilizzare per il proprio progetto. Sei tu a poter valutare al meglio ciò che funziona meglio per la tua applicazione in base alle tue esigenze specifiche.

Devi individuare gli aspetti e le funzionalità a cui non puoi rinunciare e scegliere di conseguenza. Se è difficile prendere una decisione, puoi sempre optare per l'utilizzo combinato di entrambi i server in una soluzione personalizzata.

Buon computing!