Nginx: Come Funziona per il Tuo Sito

Nginx è un web server di tipo open source che in un primo momento è stato impiegato come server, mentre ora viene adoperato, fra l’altro, come bilanciatore di carico, come cache http e come proxy inverso.

Sono numerose le aziende di profilo elevato che si servono di Nginx, come per esempio Microsoft e DuckDuckGo, ma anche Atlassian e Autodesk, senza dimenticare Cisco e Xerox.

Non solo: Nginx viene utilizzato anche da Intel, da Apple, da Twitter, da Citrix Systems, da Target, da Facebook, da LinkedIn, da VMWare, da Salesforce, da Adobe, da Google, da IBM, da GitLab e da Intuit.

Quali sono le origini di Nginx?

Le origini di Nginx vanno fatte risalire addirittura al 2004: fu in quell’anno, infatti, che la creatura di Igor Sysoev venne per la prima volta rilasciata al pubblico. Sysoev in un primo momento aveva ideato il programma come soluzione per il problema C10k, relativo alle anomalie delle performance per la gestione di 10mila connessioni nello stesso momento.

Proprio perché inizialmente Nginx era stato concepito allo scopo di ottimizzare le prestazioni su scala, questo web server oggi nei test di benchmark è in grado di offrire prestazioni migliori di quelli di altri server web che magari sono più famosi, in modo particolare per situazioni che prevedono più richieste in contemporanea o che sono caratterizzate da contenuto statico.

Come funziona Nginx?

Ma entriamo più nel dettaglio e scopriamo da vicino qual è il principio di funzionamento di Nginx, che è stato concepito per assicurare una concorrenza elevata e al tempo stesso un consumo di memoria ridotto.

Nginx, infatti, non dà vita a processi nuovi per tutte le richieste web, ma fa riferimento a un approccio asincrono, che si fonda sugli eventi, nel quale la gestione delle richieste avviene in un thread singolo.

Un processo master tramite Nginx è in grado di gestire diversi processi worker, i quali vengono mantenuti dal master, mentre l’elaborazione effettiva viene eseguita dai worker.

Dal momento che Nginx è asincrono, il worker può eseguire tutte le richieste nello stesso momento non dovendo bloccare altre richieste. Il bilanciamento del carico e la gestione di file statici sono due delle caratteristiche più importanti di Nginx, il cui utilizzo si avvicina a quello di Apache.

Meglio Apache o Nginx?

Come noto, Apache è un celebre web server di tipo open source: a livello numerico, è senza dubbio il più famoso, usato da poco meno della metà dei siti web che hanno un server conosciuto, in base ai dati forniti da W3Techs.

A circa il 42% si colloca, invece, Nginx. Un sondaggio realizzato da Netcraft su oltre 230 milioni di domini ha permesso di rilevare che l’uso di Nginx è di poco superiore al 26%, a fronte di un uso di Apache che invece va oltre il 31%.

In sostanza, Apache si presenta come la soluzione che nel complesso gode di maggior popolarità, anche se a ben vedere Nginx si rivela il server web che viene utilizzato di più per i siti web a traffico elevato.

Nel momento in cui si prendono in esame i tassi di utilizzo a seconda del traffico, si scopre che Nginx alimenta oltre il 62% dei mille siti più popolari, oltre il 67% dei 10mila siti più popolari e quasi il 61% dei 100mila siti più popolari.

Fra l’altro, Nginx viene impiegato da WordPress, NASA e Netflix, siti che consumano una grande quantità di risorse. Apache, d’altro canto, alimenta meno del 17% dei mille siti più popolari, meno del 19% dei 10mila siti più popolari e il 24% dei 100mila siti più popolari.

Nginx o Apache: tutto quel che c’è da sapere

Ma come si fa a scoprire se il sito di cui si è titolari gira su Apache o su Nginx? Quasi sempre non si deve far altro che controllare le intestazioni http server: è possibile farlo, in Chrome Devtools, lanciando la scheda di rete. In alternativa si può fare riferimento a uno strumento come GTmetrix o Pingdom e controllare le intestazioni.

C’è, però, un aspetto che vale la pena di prendere in considerazione, e cioè il fatto che non sempre l’intestazione http consente di conoscere il server web sottostante. È il caso dei siti WordPress che sono dietro server proxy come Cloudflare, per esempio.

In ogni caso, se si presta attenzione ai termini di ricerca di Google a partire dal 2004 in avanti, si scopre che Apache è protagonista suo malgrado di un calo continuo, a fronte di un lieve rialzo da parte di Nginx; dal 2018, inoltre, Apache ha perso quota fra i siti popolari.

Una configurazione reale da reverse proxy

L'uso più frequente che facciamo di Nginx sui progetti dei clienti non è come web server a sé stante, ma come reverse proxy davanti a un application server (Node.js, un backend Java, un'app Python su Gunicorn o uWSGI). Un esempio minimo funzionante, in /etc/nginx/sites-available/app.conf:

server {
    listen 80;
    server_name app.esempio.it;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nginx resta in ascolto sulla porta pubblica e inoltra ogni richiesta all'applicazione in esecuzione su una porta interna; le righe proxy_set_header sono quelle che permettono al backend di vedere il vero IP del client e il protocollo usato, invece di vedere ogni richiesta come proveniente da 127.0.0.1. La configurazione si attiva con un symlink dentro sites-enabled e si ricarica con nginx -t && systemctl reload nginx: lanciare prima nginx -t per validare la sintassi evita di ricaricare una configurazione rotta.

Gli errori che si incontrano davvero

• 502 Bad Gateway — Nginx ha ricevuto la richiesta ma il backend a cui la sta inoltrando non ha risposto correttamente, il più delle volte perché l'applicazione non è attiva, è andata in crash, oppure è in ascolto su una porta diversa da quella indicata in proxy_pass.
• 504 Gateway Timeout — il backend è attivo ma ha impiegato troppo tempo a rispondere; conviene verificare se è l'applicazione a essere lenta (per esempio una query al database che dura troppo) prima di alzare proxy_read_timeout.
• "too many open files" nel log degli errori sotto carico — Nginx (e il sistema operativo) hanno un limite di file descriptor aperti; su un server che gestisce molte connessioni contemporanee va alzato sia in worker_rlimit_nofile sia a livello di sistema operativo (ulimit).
• Le modifiche ai contenuti statici non si vedono — la cache interna della configurazione di Nginx e gli header di cache del browser (o una CDN davanti) sono le due cause più frequenti; un refresh forzato e il controllo degli header Cache-Control di solito chiariscono quale delle due sia la responsabile.

Quando ha senso mettere Nginx davanti a un'applicazione

Mettere Nginx davanti a un application server esistente conviene principalmente per tre motivi: terminare il TLS in un unico punto invece di configurare i certificati su ogni singolo servizio backend, servire i file statici (immagini, CSS, JS) direttamente invece di farli passare dall'applicazione, e distribuire il traffico su più istanze backend tramite la direttiva upstream. Per una piccola applicazione interna con traffico limitato, questo strato aggiuntivo spesso non vale la complessità in più che introduce: diventa utile quando c'è più di un backend su cui instradare il traffico, oppure quando TLS e cache vanno gestiti in modo centralizzato.

La soluzione a portata di click!

Hai difficoltà nell’utilizzo di Nginx o vuoi saperne di più? Contattaci subito: il team di TN Solutions è a tua disposizione per offrirti tutta l’assistenza informatica che ti serve per aiutarti a trovare una soluzione, per questo e per qualsiasi altra necessità di natura IT!

Articoli Correlati

Se vuoi saperne di più, ecco delle guide tematiche di approfondimento:

• RAID 0, 1, 5, 6, 10: Guida alla Scelta Giusta

• Come pulire la cache del Browser

• Assistenza, riparazione e configurazione server

• NAS aziendale: come sceglierlo

• Wamp: cos'è e a cosa serve

• Processori Amd e Intel: guida alla scelta

• Nuova versione del firewall pfSense: tutto quello che devi sapere

• Varnish Cache: cos'è come funziona

• SSH e OpenSSH Server

• Progettazione di una rete informatica

• Il ruolo del sistemista Linux in azienda