Nginx Verso Apache: La resa dei Conti dei Server Web

Internet, come lo conosciamo oggi, ha iniziato la sua “conquista” globale negli anni ’90. L’intero protocollo “Web” può essere schematizzato così: un visitatore richiede un documento da un certo indirizzo web e il sistema DNS e IP inoltra le richiesta al computer giusto. Questo computer, che ospita la pagina web richiesta, “serve” la pagina web al visitatore.

Le pagine web sono essenzialmente documenti HTML. Per essere in grado di servire diverse pagine web ai visitatori, la macchina “servente” ha bisogno di un programma server. Software come Nginx e Apache gestiscono le richieste, le analizzano e quindi restituiscono i documenti corrispondenti da visualizzare nel browser del visitatore.

Apache

Esploreremo prima Apache, dato che è stato rilasciato per primo.

Dopo il CERN httpd di Tim Berners-Lee e l’NCSA HTTPd, nei primi anni di Internet, Apache – il cui primo rilascio risale al 1995 – conquistò rapidamente il mercato e divenne il server web più popolare al mondo. Al giorno d’oggi, è ancora in quella posizione di mercato, ma soprattutto per motivi legacy. Apache è stato sviluppato e gestito dalla Apache Foundation, con licenza Apache.

Ci sono due storie diverse su come sia nato il nome Apache. La prima versione dice che il nome deriva dall’eredità culturale dei nativi americani, mentre l’altra versione dice che il nome è un gioco di parole su “a patchy server”, che seguì una serie di patch software.

Linux

L’enorme quota di mercato di Apache è in parte dovuta al fatto che è preinstallato su tutte le principali distribuzioni Linux, come Red Hat/Centos e Ubuntu.

Un esempio dell’importante ruolo di Apache nel mondo Linux è che il suo nome di processo del server è HTTPd, cosa che rende Apache sinonimo di software per server web.

Oltre ad essere il primo importante player nel mercato dei server web, parte del successo di Apache è dovuto al suo sistema di configurazione e al suo file .htaccess.

.htaccess

Apache usa .htaccess per la sua configurazione. Ci sono un sacco di tutorial su come configurare, modificare e lavorare con questo file, dato che permette di avere una grande flessibilità nella configurazione della gestione delle richieste in entrata da parte di Apache. Alcuni esempi: varie regole di redirect, dimensioni massime di caricamento dei file, rewrite degli URL, limiti di memoria, protezione delle directory (htpasswd), intestazioni expires, intestazioni cache-control, intestazioni di encoding, cookie, manipolazione delle query string.

D’altra parte, Kinsta utilizza Nginx, che non supporta i file .htaccess. Tuttavia, le impostazioni e le regole dei file .htaccess possono essere facilmente “tradotte” nella sintassi delle regole di rewrite proprie di Nginx.

Uno dei principali “Pro” di Apache è che, nella root del server, cioè la directory principale del sito web, ogni livello o directory nell’albero delle directory può avere il proprio file .htaccess con la propria configurazione.

Per i provider di hosting condiviso, questo è un sogno perché possono permettere a centinaia di utenti sulla stessa macchina di configurare il modo in cui sono serviti i loro siti web, senza che ciò influisca sugli altri. I clienti possono impostare molti dettagli in un ambiente di hosting condiviso limitato, senza mai toccare la configurazione del server globale.

Come dice la documentazione ufficiale:

“In generale, dovreste usare i file .htaccess solo quando non avete accesso al file di configurazione del server principale.”

Questa flessibilità, però, viene offerta a discapito delle prestazioni “permettendo che i file .htaccess causino un calo di prestazioni, anche se non li doveste nemmeno utilizzate!”

Ogni volta che i file .htaccess sono abilitati, Apache deve attraversare l’intero albero delle directory dall’URL o dal file richiesto attraverso tutti i livelli superiori fino alla directory root del server e quindi caricarli, per ogni singola richiesta. Apache deve quindi processare questi file e riconfigurarsi per ciascuna delle directory configurate in questo modo.

Con i siti web WordPress, le cose possono diventare davvero complesse. Un tipico sito WordPress può avere centinaia di richieste da diverse directory.

Dal tipo di directory /wp-content/uploads/yyyy/mm, di solito avrà più richieste su un singolo caricamento di pagina, spesso da diverse directory di mese. Quindi ci saranno risorse statiche di /wp-content/themes/parent-theme, risorse di /wp-content/themes/child-theme: queste includeranno javascript, file css, immagini.

Poi ci sarà anche /wp-content/plugins, con file statici caricati da decine di sottodirectory dei plugin. Per ciascuna di queste risorse, Apache deve attraversare l’intero albero per cercare la configurazione.

Un’analisi ha dimostrato che una tipica configurazione di WordPress, piuttosto comune per i siti web su host condivisi, includerà 42 distinte esecuzioni di .htaccess e 249 ricerche del file .htaccess.

Questo è solo a livello di server web. Il visitatore deve ancora aspettare che il processo PHP esegua l’intero stack di chiamate di WordPress per creare la query del database e passarla a MySQL per assemblare la pagina web e inviarla al visitatore.

Moduli

Un’altra cosa che ha reso popolare Apache è il suo sistema di moduli dinamici.

I moduli – come elementi che consentono agli utenti di estendere le funzionalità del server – esistono sia in Nginx che in Apache. Apache consente agli utenti di installare i moduli una volta che il server è già stato installato e distribuito e quindi abilitato/disabilitato in base alle necessità. Le distribuzioni Debian hanno comandi che consentono di abilitare e disabilitare questi moduli senza dover modificare alcun file di configurazione: a2enmod e a2dismod.

L’elenco ufficiale dei moduli che fanno parte della distribuzione standard di Apache è qui e tra questi ci sono cose che vanno da compressione, crittografia, registrazione e reindirizzamenti a cose più avanzate come richieste di modifica e risposte con sintassi avanzata.

Nginx

Nginx (scritto anche nginx o NGINX), è entrato sulla scena nel 2004, quando è stato rilasciato per la prima volta dallo sviluppatore russo Igor Sysoev. Come Owen Garrett, il project manager di Nginx, ha detto:

“Nginx è stato sviluppato specificamente per risolvere i limiti delle prestazioni dei server Apache.”

Il server è stato inizialmente creato come strumento per lo scaling del sito rambler.ru nel 2002. È disponibile in due versioni: open source, con licenza di tipo BSD e Nginx Plus, con supporto e funzionalità enterprise aggiuntivi.

Dopo il suo rilascio, Nginx è stato utilizzato principalmente per servire file statici e come bilanciaore di carico o reverse proxy sul fronte di installazioni di Apache. Con l’evolversi del web e la necessità di spremere fino all’ultima goccia di velocità e di efficienza di utilizzo dell’hardware, un numero maggiore di siti web hanno iniziato a sostituire interamente Apache con Nginx, grazie anche a un software più maturo.

A marzo 2019, Nginx Inc è stata acquisita da F5 Networks per 670 milioni di dollari. In quel momento, come riporta Techcrunch, il server Nginx alimentava “375 milioni di siti web con circa 1.500 clienti paganti”.

Secondo i dati di w3techs, la quota di mercato di Nginx è cresciuta costantemente, spingendo fuori Apache e facendogli perdere il primo posto:

Questi dati riguardano server web a livello globale, ma se prendiamo esempio del primo milione di siti, vediamo che Nginx è lì già da un po’ di tempo:

Anche Google Search Trends sembra riflettere questo fatto:

L’indagine di Netcraft suggerisce che Apache è stato superato da Nginx nell’aprile del 2019.

Configurazione di Nginx

Nginx non ha un sistema di configurazione come Apache quindi, nonostante sia molto più efficiente e veloce, non è ampiamente utilizzato dai provider di hosting al dettaglio. Non splende negli ambienti condivisi come accade con Apache.

D’altra parte, come abbiamo detto, non consentendo configurazioni a livello di directory, Nginx ha un vantaggio significativo rispetto ad Apache. C’è un articolo sul wiki di Nginx che confronta l’impatto sulle prestazioni:

Moduli di Nginx

Il sistema di moduli di Nginx è un’altra cosa che lo caratterizza come scelta più professionale. Generalmente i moduli Nginx devono essere abilitati in fase di compilazione, il che significa che è necessaria una competenza tecnica, e l’aggiunta post-installazione dei moduli è un po’ più complicata.

Nel 2016, con la versione 1.9.11, le cose sono cambiate e il repository ufficiale/verificato dei moduli dinamici è riservato agli utenti paganti. A partire da maggio 2019, hanno annunciato l’avvio dello sviluppo del supporto per QUIC e HTTP/3.

La Questione della Cache: Nginx verso Apache

Il caching – se vogliamo metterla in modo molto semplice – può essere descritto come qualcosa che prepara il contenuto per i visitatori del sito prima che avvenga la visita, in modo che, quando “bussano alla porta”, non è necessario andare alla ricerca del contenuto che questi stanno cercando. L’avete già preparato e lo consegnate senza alcuna attesa da parte del visitatore.

Come Apache, la tipica configurazione di Nginx consisteva nel collocarsi tra i server e l’utente finale per ridurre il calo di prestazioni del resto dell’infrastruttura. In questi casi, Nginx può memorizzare nella cache il contenuto statico senza doverlo recuperare ogni volta dal server di origine protetto.

Se utilizziamo Nginx come server web standalone, come facciamo con i container LXC di Kinsta, questo non è necessario. Nginx è molto efficiente nel servire da solo il contenuto statico.

Poi c’è il problema della cache dinamica o della page cache. Nello scenario di un sito WordPress, ciò significa memorizzare tutte le pagine di WordPress generate per ogni URL in memoria o su disco.

Il caching FastCGI è disponibile nativamente in un’installazione Nginx standard. È semplice, molto potente ed è una delle funzionalità di Nginx meno utilizzate.

Per confrontare questo con gli equivalenti di Apache, dovresti sapere che Apache ha un modulo mod_cache che, secondo quanto riportato, tende ad essere difettoso e ad andare in conflitto con altri moduli. Quindi la soluzione di caching standard distribuita con Apache è l’acceleratore HTTP di Varnish. Sebbene Varnish sia la soluzione industriale dedicata, alcuni recenti test danno al caching di Nginx un chiaro margine di vantaggio rispetto a Varnish.

Da Kinsta utilizziamo Nginx per il caching dinamico di WordPress, con un plugin proprietario di caching che consente il controllo granulare delle pagine memorizzate nella cache e delle risorse statiche memorizzate nella cache dal CDN di Kinsta.

La Gestione delle Richieste: Nginx verso Apache

La più grande differenza tra Apache e Nginx è nell’architettura alla base della gestione delle richieste.

Apache elabora le richieste con MPM-s o Multi-Processing-Modules, che è “responsabile dell’associazione alle porte di rete sulla macchina, dell’accettazione di richieste e dell’invio di children per gestire le richieste”.

Il più vecchio MPM, che risale agli inizi di Apache, è il modulo prefork. Questo modulo da solo può essere considerato il colpevole della cattiva reputazione di Apache riguardo alle prestazioni. In questa modalità, Apache genera un nuovo processo con un thread su ogni richiesta.

Questo modulo, utilizzato con mod_php, faceva sì che il server Apache includesse un interprete PHP in ogni singolo processo, anche se doveva servire file o immagini CSS.

Questo era inefficiente. Il modulo Prefork viene fornito come modulo predefinito di Apache. E limita anche le connessioni a HTTP/1.

Negli ultimi anni, Apache ha sviluppato l’mpm worker a thread multipli e, successivamente, l’event mpm. Entrambi eliminano molti dei problemi di prestazioni di Apache. Passare a php-fpm rende Apache ancora oggi una soluzione competitiva, eliminando l’utilizzo di .htaccess, ma questo oltrepassa il suo scopo.

Nginx utilizza un’architettura basata sugli eventi asincrona e non bloccante.

Per spiegare la differenza: nel mondo Linux/Unix, i processi eseguono programmi.

I thread sono un sottoinsieme di processi e possono esserci più thread durante l’esecuzione di un processo. Pensate a questo come a più schede in una sola finestra del browser. In questo modo un programma può sfruttare più CPU e CPU multi-core e multi-thread per essere eseguiro più velocemente. Potete leggere Linus Torvalds che analizza le differenze.

In breve, Apache utilizza processi per ogni connessione (e con il worker mpm utilizza i thread). Con l’aumento del traffico, diventa rapidamente troppo costoso.

Possiamo immaginare la creazione di nuovi processi o thread come l’avvio di un computer o l’avvio di programmi. Anche nei computer più veloci, ci vuole sempre un po’ di tempo. Con i siti web di oggi, che fanno centinaia di richieste su una singola pagina, queste si accumulano rapidamente.

L’event mpm va un po’ oltre in termini di ottimizzazione, ma alcuni test dimostrano che non può superare Nginx. Soprattutto quando parliamo di file statici, in cui Nginx serve il doppio delle richieste di Apache.

In teoria Nginx ha un processo di lavoro per CPU/core. La differenza tra i processi di lavoro di Nginx è che ognuno di questi può gestire centinaia di migliaia di connessioni di rete in entrata per worker. Non è necessario creare nuovi thread o processi per ciascuna connessione.

Questo è il motivo per cui i principali Content Delivery Network, come Cloudflare, MaxCDN, e il nostro partner KeyCDN – o siti web come Netflix – trovano Nginx cruciale per la consegna dei contenuti.

L’elenco delle aziende che sfruttano Nginx è troppo lungo per elencarle tutte, quindi concluderemo con Automattic, l’azienda privata dietro a WordPress.com.

Automattic ha convertito tutti i suoi bilanciatori di carico in Nginx per WordPress.com nel 2008 (potete leggere qui al riguardo) e ha eseguito la migrazione completa dello stack dei server su Nginx.

La Verifica nella Vita Reale

Se vogliamo ispezionare ciò che viene utilizzato dal sito in produzione, lo troviamo indicato di solito nelle intestazioni delle risposte HTTP. Ciò significa che dovremo fare clic con il pulsante destro del mouse su un sito Web > Ispeziona. Nel developer tools, sceglieremo il pannello di rete e quindi ricaricheremo il sito web. Vedremo tutte le risorse che il sito sta caricando. Se scegliamo una particolare risorsa e la sua scheda Headers, di solito vedremo le informazioni sul server. Se il sito web utilizza un CDN, potremmo vedere qualcosa come Cloudflare nella linea del server o qualcosa come Varnish se il sito web utilizza l’acceleratore HTTP.

Questo è un esempio di un sito WordPress che utilizza una tipica configurazione di hosting condiviso con cPanel, Apache e PHP:

Questo è un sito Web su Nginx:

Sul lato sinistro, se lo espandiamo, saremo anche in grado di analizzare il tempo di ogni risorsa e di vedere il suo impatto sul tempo di caricamento complessivo della pagina.

Riepilogo

In questo articolo, mi incentrato la mia attenzione sul confronto tra Nginx e Apache e ho spiegato le principali differenze di architettura che hanno permesso a Nginx di acquisire maggiore trazione e attenzione nel mercato dei server web. Questi sono i tratti chiave che gli conferiscono il margine di vantaggio nel nostro settore così affamato di risorse.

Naturalmente, non tutti i casi d’uso hanno le stesse priorità e Apache o altri strumenti come Lighttpd, IIS, LiteSpeed, Caddy potrebbero essere buone soluzioni.

Da Kinsta utilizziamo Nginx come parte delle nostre soluzioni di hosting ottimizzate per le prestazioni di WordPress e WooCommerce. Ogni sito WordPress è ospitato in un proprio container isolato, che ha tutte le risorse software necessarie per la sua esecuzione (Nginx, Linux, PHP, MySQL). Le risorse sono private al 100% e non sono condivise con altri siti.

Assicuratevi di controllare Nginx e tutti i nostri componenti aggiuntivi premium. Inoltre, date un’occhiata ai nostri servizi di Hosting di applicazioni e Hosting di database per ulteriori opportunità di hosting.

Tonino Jankov

Tonino er en iværksætter, Linux & OSS entusiast, udvikler og teknisk underviser. Han har over ti års erfaring med udvikling og har været i blockchain-området i 3+ år. Når han ikke koder, skriver han for SitePoint og Alibaba Cloud, overvåger de nyeste skønlitterære værker på Netflix og udforsker nye rejsedestinationer.

• Twitter