Nginx è un server web e un server proxy di posta disponibile pubblicamente dal 2004. Lo sviluppo del progetto è iniziato nel 2002, in russo il nome suona come engin-ex. La creazione delle mani del famoso programmatore Igor Sysoev, Nginx era originariamente destinata a Rambler. È progettato per sistemi operativi appartenenti al gruppo Unix-like. L'assembly è stato testato con successo su OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. Sulla piattaforma Microsoft Windows Nginx ha iniziato a lavorare con il rilascio della build binaria 0.7.52.

Le statistiche di marzo 2011 mostrano che il numero di siti serviti da Nginx ha già superato i 22 milioni. Oggi Nginx è utilizzato da progetti noti come Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru e altri. Insieme a lighttpd, Nginx viene utilizzato per servire contenuto statico generato da un'applicazione web "scomoda" in esecuzione su un altro server web.
Ma prima di addentrarci nella giungla delle caratteristiche funzionali di Nginx, è utile ricordare cos'è un server web in generale e un server proxy in particolare.

Server web e server proxy

server webè un server che accetta richieste HTTP da browser Web e altri client e invia loro risposte HTTP. Questi ultimi sono generalmente rappresentati da una pagina HTML, un flusso multimediale, un'immagine, un file e altri dati. Un server web è inteso come Software che implementa le funzioni del server web, oltre all'hardware. Lo scambio dei dati e delle informazioni richieste avviene tramite il protocollo HTTP.

La lista funzioni aggiuntive i server web includono: autorizzazione e autenticazione degli utenti, registrazione delle loro richieste alle risorse, supporto HTTPS per la commutazione sicura con client e altri. Il server web più comunemente usato nei sistemi operativi simili a Unix è Apache. La terza riga nell'elenco delle preferenze del client è attualmente occupata da Nginx.

Server proxy consente ai clienti di gestire query di ricerca Per servizi di rete in forma indiretta. Cioè, è un server specializzato nell'inoltro delle richieste dei client ad altri server. Collegandosi a un server proxy e richiedendo una risorsa situata su un altro server, il client ha la possibilità di mantenere l'anonimato e proteggere il computer da attacchi di rete... Il server proxy invia i dati richiesti al client dalla propria cache (se presente) o ricevendoli dal server specificato. In alcuni casi (per raggiungere gli obiettivi di cui sopra), la risposta del server, come la richiesta del client, può essere modificata dal server proxy.

Il server proxy più semplice è considerato il traduttore di indirizzi di rete o NAT. Nel 2000, il proxy NAT è stato integrato nella distribuzione di Windows. I server proxy, come ogni fenomeno, hanno due facce della medaglia, cioè possono essere usati sia nel bene che nel male. Ad esempio, con il loro aiuto coloro che temono sanzioni per le loro azioni sconvenienti sulla rete nascondono i loro indirizzi IP...

Gamma funzionale di Nginx:

• manutenzione del server di file di indice, query statiche, generazione di descrittori di cache file aperti, elenco file;
• proxy accelerato, distribuzione elementare del carico, tolleranza ai guasti;
• supporto per la memorizzazione nella cache durante il proxy accelerato e FastCGI;
• supporto per server FastCGI (accelerato) e memcached;
• modularità, filtri, inclusi "resume" (intervalli di byte) e compressione (gzip);
• Autenticazione HTTP, risposte in blocchi, filtro SSI;
• esecuzione parallela di più richieste secondarie sulla pagina elaborata tramite FastCGI o proxy nel filtro SSI;
• Supporto StartTLS e SSL;
• la capacità di supportare Perl integrato;
• autenticazione semplice (USER/PASS, LOGIN);
• reindirizzamento del server (proxy IMAP/POP3) dell'utente al backend IMAP/POP3 utilizzando un server di autenticazione esterno (HTTP).

Per chi non ha familiarità con questa terminologia, la descrizione delle funzionalità di Nginx può sembrare piuttosto vaga. Ma quando si tratta di modi di utilizzo concreto di questo server web, comincerà a svanire a poco a poco.

Architettura e configurazione

I processi di lavoro Nginx servono più connessioni contemporaneamente, fornendo loro chiamate del sistema operativo (sistema operativo) epoll (Linux), select e kqueue (FreeBSD). I dati ricevuti dal client vengono analizzati tramite una macchina a stati. La richiesta analizzata viene gestita dalla catena di moduli specificata dalla configurazione. La formazione di una risposta al client avviene in buffer, che possono puntare a una sezione di un file o memorizzare dati in memoria. La sequenza di trasmissione dei dati al client è determinata dalle catene in cui sono raggruppati i buffer.

Strutturalmente, il server HTTP Nginx è diviso in server virtuali, che a loro volta sono suddivisi in posizioni. Server virtuale oppure la direttiva può essere utilizzata per specificare porte e indirizzi per accettare connessioni. La posizione può essere specificata con un URI esatto, parte di un URI o un'espressione regolare Per la gestione della memoria al volo, i pool sono una sequenza di blocchi di memoria preselezionati. Un blocco inizialmente allocato per il pool ha una lunghezza da 1 a 16 kilobyte. È diviso in aree: occupate e non occupate. Man mano che quest'ultimo viene riempito, la selezione di un nuovo oggetto è fornita dalla formazione di un nuovo blocco.

La classificazione geografica dei client in base al loro indirizzo IP viene eseguita in Nginx utilizzando modulo speciale... Il sistema ad albero Radix consente di lavorare rapidamente con gli indirizzi IP, occupando un minimo di memoria.

Benefici di Nginx

Nginx è considerato molto veloce server HTTP... Invece di o insieme ad Apache, Nginx viene utilizzato per accelerare l'elaborazione delle richieste e ridurre il carico sul server. Il fatto è che le vaste capacità fornite dall'architettura modulare di Apache non sono richieste dalla maggior parte degli utenti. Pagare per questa funzionalità non reclamata è un notevole spreco di risorse di sistema. Per i siti ordinari, di regola, c'è una chiara dominanza di file statici (immagini, file di stile, JavaScript) e non di script. Non è richiesta alcuna funzionalità speciale per trasferire questi file al visitatore della risorsa, poiché l'attività è molto semplice. Ciò significa che il server web per l'elaborazione di tali richieste deve essere semplice e leggero, come Nginx.

Modi per usare Nginx

Su una porta/IP separata. Se la risorsa è piena di immagini o file per il download, Nginx può essere configurato su una porta o IP separato e servire contenuto statico attraverso di esso. Per fare ciò, tuttavia, devi armeggiare un po' con la modifica dei collegamenti sul sito. Con un gran numero di richieste a file statici, ha senso creare un server separato e installare Nginx su di esso.

Proxy accelerato... Con questa opzione, tutte le richieste dei visitatori vanno prima a Nginx. Nginx gestisce le richieste di file statici (come un'immagine, un semplice file HTML, JavaScript o CSS) da solo. Se l'utente contatta uno script particolare, inoltra la richiesta al reparto Apache. Non è necessario effettuare alcuna trasformazione con il codice del sito.

Se il canale dal server al visitatore e viceversa è lento, questo uso di Nginx può dare un effetto aggiuntivo. La richiesta ricevuta dal visitatore viene passata a Nginx per essere elaborata da Apache. Dopo aver elaborato la richiesta, Apache dirige la pagina Nginx e termina la connessione con un senso di realizzazione. Nginx ora può inviare una pagina a un utente per tutto il tempo necessario, praticamente senza consumare risorse di sistema. Apache in esecuzione al suo posto sarebbe accompagnato da un carico di memoria irragionevolmente alto quando era quasi inattivo. A proposito, questo caso d'uso per Nginx ha un altro nome: "Fronte di Apache".

Nginx più FastCGI. Apache potrebbe non essere affatto necessario se l'interprete della lingua in cui sono scritti gli script del sito supporta la tecnologia FastCGI. Tali linguaggi includono, ad esempio, PHP, Perl e molti altri. Tuttavia, in questo caso, potrebbe essere necessario modificare i codici script.

Ci sono molti materiali dettagliati su come installare e configurare Nginx sulla rete. Puoi saperne di più su Nginx sul sito web del suo sviluppatore Igor Sysoev.

Un server web dedicato basato su nginx è un ottimo modo per migliorare le prestazioni dei tuoi siti web. Nella velocità di elaborazione del contenuto statico, semplicemente non ha eguali: resiste facilmente a diverse migliaia di connessioni simultanee e può essere facilmente ottimizzato e regolato per qualsiasi configurazione. Ma? In quanto front-end per Apache, nginx risulta essere il punto più vulnerabile dell'intera infrastruttura Web, pertanto occorre prestare particolare attenzione alla sicurezza di nginx.

Questo articolo è una sorta di programma educativo, o, se preferisci, un riassunto di tutte le tecniche per aumentare la sicurezza di nginx. Non ci sarà alcuna teoria, nessuna descrizione delle basi della configurazione di un server Web o altro. Invece, diventi esaustivo materiale pratico, che delinea tutti i passaggi di base necessari per ottenere un server Web veramente sicuro.

Installazione

Il pacchetto nginx è disponibile precompilato per qualsiasi distribuzione. Tuttavia, costruendo il server da soli, è possibile renderlo più compatto e affidabile e modificare la riga di saluto del server Web per scoraggiare gli script kiddy poco intelligenti.

Cambia la linea di benvenuto del server web

Scarica i sorgenti di nginx, apri il file src / http / ngx_http_header_filter_module.c e trova le due righe seguenti:

static char ngx_http_server_string = "Server: nginx" CRLF;
static char ngx_http_server_full_string = "Server:" NGINX_VER CRLF;

Sostituiscili con qualcosa del genere:

static char ngx_http_server_string = "Server:] [ Server web"CRLF;
static char ngx_http_server_full_string = "Server:] [Server Web" CRLF;

Rimuovi tutti i moduli nginx che non stai utilizzando

Alcuni moduli nginx si connettono al server web proprio in fase di compilazione e ognuno di essi è potenzialmente pericoloso. Forse, in futuro, verrà rilevata una vulnerabilità in uno di essi e il tuo server sarà a rischio. Disabilitando i moduli non necessari, puoi ridurre significativamente il rischio di una situazione del genere.

Costruisci con i seguenti comandi:

# ./configure --senza-http_autoindex_module --senza-http_ssi_module
# fare
# fai installare

Questo ti darà nginx con i moduli SSI (Server Side Include) e Autoindex disabilitati (e nella maggior parte dei casi inutili). Per scoprire quali moduli possono essere eliminati in sicurezza dal server Web, eseguire lo script di configurazione con il flag '-help'.

Dissezione di nginx.conf

Dopo l'installazione, nginx dovrebbe essere configurato. Sulle pagine della rivista c'era già materiale che descrive questo processo, ma rimarremo sull'argomento dell'articolo e parleremo di modi per migliorare la sicurezza del server.

Disabilita la visualizzazione della versione del server su tutte le pagine di errore

Aggiungi la riga "server_tokens off" al file nginx.conf. Ciò farà sì che nginx nasconda il tipo e la versione del server Web nelle pagine generate in risposta a una richiesta errata del client.

Imposta la protezione contro le rotture dello stack

Aggiungi alla sezione server seguenti righe:

# vi /etc/nginx/nginx.conf

# Taglia massima un buffer per memorizzare il corpo della richiesta del cliente
client_body_buffer_size 1K;
# Dimensione massima del buffer per la memorizzazione delle intestazioni delle richieste del client
client_header_buffer_size 1k;
# La dimensione massima del corpo della richiesta del client, come specificato nel campo Content-Length dell'intestazione. Se il server deve supportare il caricamento di file, questo valore deve essere aumentato
client_max_body_size 1k;
# Numero e dimensione dei buffer per la lettura di intestazioni di richieste client di grandi dimensioni
large_client_header_buffers 2 1k;

Prestare attenzione alla direttiva large_client_header_buffers. Per impostazione predefinita, nginx alloca quattro buffer per memorizzare la stringa URI, ognuno dei quali è uguale alla taglia pagine di memoria (per x86 è 4 KB). I buffer vengono rilasciati ogni volta che la connessione entra nello stato keep-alive dopo l'elaborazione della richiesta. Due buffer da 1 KB possono memorizzare solo URI da 2 KB, il che consente di combattere bot e attacchi DoS.

Aggiungi le seguenti righe per migliorare le prestazioni:

# vi /etc/nginx/nginx.conf

# Timeout durante la lettura del corpo della richiesta del client
client_body_timeout 10;
# Timeout durante la lettura dell'intestazione della richiesta del client
client_header_timeout 10;
# Timeout dopo il quale la connessione keep-alive con il client non verrà chiusa dal server
keepalive_timeout 5 5;
# Timeout durante l'invio di una risposta al client
send_timeout 10;

Controlla il numero di connessioni simultanee

Per proteggere il server Web da sovraccarico e tentativi di DoS, aggiungere le seguenti righe alla configurazione:

# vi /etc/nginx/nginx.conf

# Descrivere la zona (limiti) in cui verranno memorizzati gli stati della sessione. Una zona da 1 MB può memorizzare circa 32000 stati, la impostiamo su 5 MB
limit_zone limita $ binary_remote_addr 5m;
# Imposta il numero massimo di connessioni simultanee per una sessione. In effetti, questo numero imposta il numero massimo di connessioni da un IP
limit_conn limita 5;

La prima direttiva dovrebbe essere nella sezione HTTP, la seconda nella sezione della posizione. Quando il numero di connessioni supera i limiti, il client riceverà un messaggio "Servizio non disponibile" con un codice 503.

Consenti connessioni solo al tuo dominio

Gli hacker possono utilizzare i bot per scansionare le sottoreti e trovare server Web vulnerabili. In genere, i bot passano semplicemente attraverso gli intervalli IP alla ricerca di 80 porte aperte e inviano una richiesta HEAD per ottenere informazioni sul server web (o home page). Puoi facilmente impedire tale scansione impedendo l'accesso al server tramite l'indirizzo IP (aggiungi alla sottosezione della posizione):

# vi /etc/nginx/nginx.conf

if ($ host! ~ ^ (host.com | www.host.com) $) (
ritorno 444;
}

Limita il numero di metodi disponibili per accedere al server web

Alcuni bot usano metodi diversi chiamate al server per provare a determinarne il tipo e/o la penetrazione, tuttavia RFC 2616 afferma chiaramente che il server Web non deve implementarli tutti e che i metodi non supportati potrebbero semplicemente non essere elaborati. Oggi restano in uso solo i metodi GET (richiesta documento), HEAD (richiesta intestazione server) e POST (richiesta pubblicazione documento), quindi tutti gli altri possono essere disabilitati senza problemi inserendo le seguenti righe nella sezione server del file di configurazione:

# vi /etc/nginx/nginx.conf

if ($ request_method! ~ ^ (GET | HEAD | POST) $) (
ritorno 444;
}

Chuck bot

Un altro modo per bloccare bot, scanner e altri spiriti maligni si basa sulla determinazione del tipo di client (user-agent). Non è molto efficace, perché la maggior parte dei bot imita browser completamente legittimi, ma in alcuni casi rimane utile:

# vi /etc/nginx/nginx.conf

# Blocca i gestori di download
if ($ http_user_agent ~ * LWP :: Simple | BBBike | wget) (
restituire 403;
}
# Blocca alcuni tipi di bot
if ($ http_user_agent ~ * msnbot | scrapbot) (
restituire 403;
}

Blocca lo spam dei referrer

Se il tuo sito pubblica Web log di dominio pubblico, puoi facilmente diventare vittima dello spam di referrer (quando i bot di spam contattano il tuo server, specificando l'indirizzo del sito pubblicizzato nell'intestazione del referrer). Questo tipo di spam può facilmente rovinare le classifiche SEO di una pagina web, quindi è imperativo bloccarlo. Un modo per farlo è inserire nella lista nera le parole più comuni trovate negli URL dei siti pubblicizzati.

# vi /etc/nginx/nginx.conf

# Sezione server
if ($ http_referer ~ * (babes | vendita | ragazza | gioielli | amore | nudit | organico | poker | porno | sesso | adolescenti))
{
restituire 403;
}

Blocca collegamento

Il collegamento è l'inclusione di un'immagine (o altro contenuto) da un altro sito in una pagina. In realtà, questo è un furto, perché l'immagine su cui hai trascorso più di un'ora del tuo tempo libero non solo viene utilizzata liberamente da altri, ma crea anche un carico sul tuo server Web senza portare visitatori ad esso. Per combattere gli hotlink è sufficiente assicurarsi che le immagini vengano date al cliente solo se le ha richieste mentre era già sul sito (in altre parole, l'intestazione della richiesta del referrer deve contenere il nome del tuo sito). Aggiungi le seguenti righe alla sezione server del file di configurazione nginx.conf (host.com è l'indirizzo del tuo sito):

# vi /etc/nginx/nginx.conf

posizione / immagini / (
valid_referers nessuno bloccato www.host.com host.com;
if ($ invalid_referer) (
restituire 403;
}
}

In alternativa, puoi configurare il server per servire striscione speciale con un messaggio di furto al posto dell'immagine richiesta. Per fare ciò, sostituire la riga "return 403" con la riga:

riscrivi ^ / immagini / caricamenti. * \. (gif | jpg | jpeg | png) $ http://www.host.com/banned.jpg last

Proteggi le directory importanti dagli estranei

Come qualsiasi altro server Web, nginx consente di regolare l'accesso alla directory in base a indirizzi IP e password. Questa funzione può essere utilizzata per chiudere alcune parti del sito da occhi indiscreti... Ad esempio, per rimuovere un URI dal mondo esterno:

# vi /etc/nginx/nginx.conf

posizione / caricamenti / (
# Consenti l'accesso solo alle macchine sulla rete locale
consentire 192.168.1.0/24;
# Cucire tutti gli altri
negare tutto;
}

Ora solo gli utenti della rete locale avranno accesso ai documenti della directory degli upload. Per impostare una password, dovrai eseguire passaggi più complessi. Innanzitutto, è necessario creare un file di password privato per nginx e aggiungervi gli utenti necessari (ad esempio, aggiungiamo l'utente amministratore):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin

# vi /etc/nginx/nginx.conf

posizione / amministratore / (
auth_basic "Limitato";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

È possibile aggiungere nuovi utenti utilizzando il seguente comando:

# htpasswd -s /etc/nginx/.htpasswd/passwd utente

Usa SSL

Se il tuo sito funziona con dati utente privati, come i numeri carte di credito, password di altri servizi o fornisce l'accesso a un altro Informazioni importanti, che può diventare un bocconcino per terzi, si occupano della crittografia. Nginx funziona bene con SSL e non dovrebbe essere trascurato.

Per configurare la crittografia SSL utilizzando nginx, devi solo seguire alcuni semplici passaggi. Innanzitutto, è necessario creare un certificato utilizzando la seguente sequenza di comandi:

# cd / etc / nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Quindi descrivi il certificato nel file di configurazione di nginx:

# vi /etc/nginx/nginx.conf

server (
nome_server host.com;
ascolta 443;
ssl acceso;
certificato_ssl /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

Successivamente, puoi riavviare il server web:

# /etc/init.d/nginx reload

Naturalmente, senza il supporto del sito Web stesso, non ha senso farlo.

altri metodi

Imposta i valori corretti per le variabili di sistema

Apri il file /etc/sysctl.conf e inserisci le seguenti righe:

# vi /etc/sysctl.conf

# Protezione contro gli attacchi dei puffi
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Protezione contro i messaggi ICMP errati
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Protezione dalle inondazioni SYN
net.ipv4.tcp_syncookies = 1
# Disabilita il routing della sorgente
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Protezione contro lo spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Non siamo un router
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Attiva ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Espandi la gamma di porte disponibili
net.ipv4.ip_local_port_range = 2000 65000
# Aumenta la dimensione massima dei buffer TCP
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

Posiziona la directory principale del server web su una partizione dedicata

Inserendo la directory principale del server Web in una partizione dedicata e non consentendo alcun file eseguibile o file di dispositivo su di essa, è possibile proteggere il resto del sistema da chiunque possa accedere alla radice del server Web. In questo caso, la voce nel file /etc/fstab dovrebbe essere simile a questa:

/ dev / sda5 / nginx ext4 default, nosuid, noexec, nodev 1 2

Metti nginx nell'ambiente chroot / jail

Qualsiasi moderno sistema * nix consente di bloccare un'applicazione in un ambiente di esecuzione isolato. Su Linux, puoi utilizzare le tecnologie KVM, Xen, OpenVZ e VServer per questo, su FreeBSD - Jail, su Solaris - Zones. Se nessuna di queste tecnologie è disponibile, puoi mettere nginx in un classico chroot, che, sebbene molto più fragile, può essere fermato dalla maggior parte dei cracker.

Imposta le regole SELinux per proteggere nginx

Una buona alternativa ambienti isolati le esecuzioni sono sistemi di rilevamento e prevenzione delle intrusioni locali come SELinux o AppArmor. Se configurati correttamente, possono impedire tentativi di compromettere il server Web. Per impostazione predefinita, nessuno di questi è configurato per funzionare insieme a nginx, ma all'interno del progetto SELinuxNginx(http://sf.net/projects/selinuxnginx/) sono state create regole per SELinux che chiunque può usare. Non resta che scaricare e installare:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10 / nginx
# fare
# / usr / sbin / semodule -i nginx.pp

Configura un firewall

In genere, nginx è installato su macchine dedicate pronte per carichi di lavoro pesanti, quindi spesso rimane l'unico servizio di rete in esecuzione sul server. Per mettere in sicurezza il server è sufficiente creare un piccolissimo set di regole che aprano le porte 80, 110 e 143 (se, ovviamente, nginx dovesse funzionare anche come proxy IMAP/POP3) e chiuda tutto il resto dal mondo esterno .

Limita il numero di connessioni con un firewall

Per un sito Web leggero, è una buona idea limitare il numero di tentativi di connessione da un indirizzo IP al minuto. Questo può salvarti da alcuni tipi di attacchi DoS e attacchi di forza bruta. Su Linux, questo può essere fatto usando il modulo standard iptables/netfilter state:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m stato --stato NUOVO -m recente --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recenti --update \
--secondi 60 --hitcount 15 -j DROP

Le regole riducono il limite al numero di connessioni da un IP al minuto a 15. Lo stesso può essere fatto usando pf:

# vi /etc/pf.conf

webserver_ip = "1.1.1.1"
tavolo persistere
blocco in rapido da
passa $ ext_if proto tcp a $ webserver_ip \
porta www flag S / SA mantieni stato \
(max-src-conn 100, max-src-conn-rate 15/60, \
sovraccarico sciacquone)

Oltre al limite al numero di connessioni consecutive (15 al minuto), questa regola pone un ulteriore limite al numero di connessioni simultanee pari a 100.

Configurazione PHP

Se stai usando nginx insieme a PHP, non dimenticare di configurarlo. Ecco come dovrebbe apparire il file di configurazione del server sicuro /etc/php/php.ini:

# vi /etc/php/php.ini

# Disabilita le funzioni pericolose
disable_functions = phpinfo, system, mail, exec
# Tempo massimo di esecuzione dello script
max_execution_time = 30
# Il tempo massimo che uno script può impiegare per elaborare i dati della richiesta
max_input_time = 60
# La quantità massima di memoria allocata a ogni script
memory_limit = 8M
# La dimensione massima dei dati inviati allo script utilizzando il metodo POST
post_max_size = 8M
# Dimensione massima dei file caricati
upload_max_filesize = 2M
# Non mostrare errori di script PHP agli utenti
display_errors = Off
# Attiva la modalità provvisoria
safe_mode = On
# Abilita la modalità provvisoria SQL
sql.safe_mode = On
# Consenti di eseguire comandi esterni solo in questa directory
safe_mode_exec_dir = / percorso / verso / protetto / directory
# Protezione contro la fuga di informazioni PHP
esporre_php = Disattivato
# Conservazione dei registri
log_errors = On
# Proibisci l'apertura di file remoti
allow_url_fopen = Disattivato

conclusioni

Applicando le linee guida delineate in questo articolo, avrai un server Web molto più sicuro. Ma tieni presente che non tutte le tecniche si adatteranno alla tua configurazione. Ad esempio, la protezione dalla forza bruta basata sulla riduzione delle dimensioni dei buffer allocati da nginx per l'elaborazione delle richieste dei client può portare a un degrado delle prestazioni e, in alcuni casi, a errori nell'elaborazione delle richieste. Limitare il numero di connessioni avrà un impatto maggiore sulle prestazioni di un sito Web anche con un carico moderato, ma sarà vantaggioso se la pagina ha un basso flusso di visitatori. Controlla sempre in che modo le modifiche apportate hanno influito sulle prestazioni e sullo stato di salute generale della tua pagina Web.

A proposito dell'eroe del giorno

Nginx è uno dei server Web più potenti e popolari al mondo. Secondo Netcraft, viene utilizzato per alimentare più di 12 milioni di siti Web in tutto il mondo, inclusi Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusek e Taba.ru. Un'architettura competente basata su connessioni multiplexing che utilizzano le chiamate di sistema select, epoll (Linux), kqueue (FreeBSD) e un meccanismo di gestione della memoria basato su pool (piccoli buffer da 1 a 16 KB), consente a nginx di non cedere anche sotto carichi molto elevati , resistendo a oltre 10.000 connessioni simultanee (il cosiddetto problema C10K). Originariamente scritto da Igor Sysoev per Rambler e aperto nel 2004 con una licenza simile a BSD.

In contatto con

Nginx? Scopo, funzionalità, opzioni di personalizzazione sono cose con cui ogni sviluppatore web dovrebbe avere familiarità per testare le proprie best practice.

Diciamo una parola su nginx

Questo strumento ha un flusso di lavoro principale e diversi. La prima riguarda la lettura e il controllo della configurazione. Inoltre controlla la gestione dei processi lavorativi. Il compito di quest'ultimo è quello di elaborare le richieste in arrivo. Nginx utilizza un modello basato sugli eventi. Utilizza inoltre meccanismi dipendenti dal sistema operativo per ottenere una distribuzione efficiente delle richieste direttamente tra i processi di lavoro. Il loro numero è sempre indicato nel file di configurazione. Il valore può essere fisso o impostato automaticamente, essendo guidato dal numero di core del processore con cui è possibile lavorare. In nginx, il sistema e i moduli sono configurati utilizzando un file di configurazione. Pertanto, se è necessario cambiare qualcosa, è necessario cercarlo. Di solito si trova nella direttiva / etc / nginx (ma il percorso può cambiare quando si usano altri sistemi) e ha un'estensione .conf.

Avvio, riavvio e log

Per fare ciò, è necessario che l'eseguibile funzioni. Il server nginx può essere configurato solo quando è in esecuzione. Il controllo viene effettuato chiamando il file eseguibile con il parametro -s. Per fare ciò, utilizzare la seguente voce:

nginx -s segnale

V in questo casoÈ possibile sostituire i seguenti comandi (devono provenire dall'utente che ha avviato lo strumento):

1. Fermare. È usato per completamento rapido opera.
2. Ricaricare. Il comando è necessario per ricaricare il file di configurazione. Il punto è che eventuali modifiche non verranno applicate mentre il file è in esecuzione. E affinché abbiano effetto, è necessario un riavvio. Non appena questo segnale viene ricevuto, il processo principale inizierà a verificare la correttezza della sintassi del file di configurazione e proverà ad applicare le istruzioni fornite lì. In caso di esito negativo, eseguirà il rollback delle modifiche e funzionerà con i vecchi parametri. Se tutto è andato bene, verranno avviati nuovi processi di lavoro e verrà inviata una richiesta ai vecchi da completare.
3. Uscire. Utilizzato per uno spegnimento regolare. Viene utilizzato se è necessario attendere fino a quando le richieste in corso non sono terminate.
4. Riaprire. Chiudi e apri i file di registro.

Utilizzo delle utilità

I processi possono anche essere configurati usando strumenti Unix (l'utility kill sarà considerata come un esempio). Di solito usano un meccanismo per inviare un segnale a un processo direttamente con i dati. Sono collegati tramite ID. Questi dati sono memorizzati nel file nginx.pid. Diciamo che siamo interessati al processo n. 134. Quindi, per un corretto completamento, dobbiamo inviare le seguenti informazioni:

kill -s ESCI 1628

Diciamo che vogliamo visualizzare un elenco di tutti file in esecuzione... Usiamo l'utility ps per questo. Il comando sarà simile a questo:

ps -ax | grep nginx

Cioè, come puoi vedere, quando si utilizzano strumenti aggiuntivi, viene indicato che viene utilizzato. Ora concentriamoci su come viene eseguita la configurazione di nginx.

Struttura del file di configurazione

L'installazione e la configurazione di nginx implica l'utilizzo dei moduli. Sono configurati utilizzando le direttive specificate nel file di configurazione. Sono semplici e a blocchi. Il primo tipo di direttiva consiste in un nome e parametri, che sono separati da spazi e la loro fine è indicata da un punto e virgola - (;). Il blocco ha una struttura simile. Ma in questa direttiva, invece della fine, viene posto il set istruzioni addizionali che sono inseriti tra parentesi graffe ((direzioni)). Se possono essere inseriti nomi e parametri di altri processi, tali costruzioni sono chiamate contesto. Gli esempi includono http, posizione e server.

Elaborazione di contenuti statici

Questo è uno dei compiti più importanti che deve affrontare la configurazione di nginx. Per servire contenuti statistici si intendono immagini e pagine HTML (non dinamiche). Diciamo che abbiamo bisogno di un lavoro una tantum sulla configurazione di un cluster nix nginx. È difficile farlo? No, e diamo un'occhiata a un esempio. Prima di procedere con esso, è necessario dettagliare le condizioni del problema. Quindi, a seconda delle richieste, i file proverranno da diverse directory locali. Quindi in /data/www abbiamo documenti HTML. E la directory /data/images contiene immagini. La configurazione ottimale di nginx in questo caso richiede la modifica del file di configurazione, in cui è necessario configurare il blocco del server all'interno di http. Saranno utilizzate anche due sedi per il supporto.

Implementazione: server

Quindi, per prima cosa, dobbiamo creare le directory stesse e inserire i file con le estensioni necessarie in esse (il contenuto deve essere aggiunto all'html). Quindi apriamo il file di configurazione. Per impostazione predefinita, ha già diversi blocchi di server, che sono per lo più commentati. Per ottenere il miglior risultato, questo processo deve essere eseguito rispetto a tutti i componenti predefiniti. Quindi aggiungiamo un nuovo blocco server con il seguente codice:

Il file di configurazione può funzionare con molti di questi blocchi. Ma dovrebbero differire nei nomi e nelle porte attraverso le quali vengono ricevuti i dati.

Attuazione: posizione

Definito all'interno del server:

La presenza del segno "/" è necessaria per confrontare i dati ricevuti e vedere se esiste un tale indirizzo dalla richiesta elaborata qui. Se non ci sono problemi, allora indichiamo il percorso/dati/www a file richiesto cosa c'è in questo? sistema locale... Se c'è una corrispondenza con più blocchi, viene selezionato quello con il prefisso più lungo. Nell'esempio dato, la sua lunghezza è uguale a uno, cioè verrà utilizzato esclusivamente se non ci sono "concorrenti". Ora miglioriamolo:

posizione / immagini / (

Come puoi vedere, stiamo cercando immagini. Ora combiniamo tutti gli sviluppi precedenti e la configurazione al momento è simile a questa:

posizione / immagini / (

Questa è una versione funzionante, che risulta essere standard. È possibile accedere a questo server senza problemi su computer locale se vai all'indirizzo: http: // localhost /. Come funzionerà tutto questo?

Come funziona l'esempio

Quindi, quando arrivano richieste che iniziano con / images, il server invierà i file dalla directory corrispondente all'utente. Se è assente, verranno trasmesse le informazioni che indicano un errore 404. Se nginx è configurato sul computer locale, richiedendo http: //localhost/images/example.png riceveremo un file la cui posizione è /data/images/ esempio.png. Se si specifica un carattere "/", la ricerca verrà effettuata nella directory /data/www. Ma abbiamo solo cambiato la configurazione. Affinché possa iniziare a funzionare, deve essere riavviato. Per fare ciò, usa il comando nginx -s reload. Nel caso in cui lavoro normale non è possibile, quindi nei file error.log e access.log che si trovano nella direttiva /usr/local/nginx/logs, è possibile cercare la causa dell'errore.

Creazione di un semplice server proxy

Per quanto riguarda nginx, la configurazione di questo oggetto è uno degli usi più comuni (e tra l'altro piuttosto semplice). Utilizza il principio di un server che accetta una richiesta e quindi li reindirizza ai siti necessari. Successivamente, ci si aspetta una risposta da loro, che li indirizza a colui che ha impostato l'attività. Quindi diamo un'occhiata a un esempio di creazione di un punto base. Servirà le richieste degli utenti e fornirà loro immagini dalla directory locale. Quindi, aggiungi un altro server al blocco http con il seguente contenuto:

Ora decifriamo per te: si sta creando un semplice server. Ascolterà Non specificare listen, quindi il server funzionerà sull'80°. Verranno visualizzate tutte le richieste all'interno dell'area locale. file system che sono diretti alla directory /data/up1 (ovviamente, dovrà essere creata prima). Per poterlo controllare, devi inserire il file index.html lì. Inserendo la direttiva root nel contesto del server, saremo in grado di utilizzare la posizione in qualsiasi condizione (poiché ciò rimuove le restrizioni di accesso). Ora stiamo lavorando alla creazione di un server proxy. Perché funzioni, abbiamo bisogno della direttiva proxy_pass, per la quale il protocollo, il nome e la porta dell'oggetto verranno specificati come parametri (se connessione locale sarà simile a http: // localhost: 8080). Ottieni il seguente risultato:

proxy_pass http: // localhost: 8080;

posizione / immagini / (

Se guardi il codice e lo analizzi, noterai che il secondo blocco di posizione è stato modificato. Quindi, in questo caso, può funzionare con le tipiche estensioni delle immagini. In modo leggermente diverso, potrebbe essere visualizzato in questo modo:

posizione ~ \. (gif | jpg | png) $ (

radice/dati/immagini;

La configurazione finale del proxy è simile a questa:

proxy_pass http: // host locale: 8080 /;

posizione ~ \. (gif | jpg | png) $ (

radice/dati/immagini;

Alla fine filtrerà le richieste che hanno le estensioni specificate e le invierà a chi ha chiesto i file. Non dimenticare che se vuoi controllare il file di configurazione, dovrai ricaricarlo. E credimi, questa è la configurazione nginx più semplice. Se apri il file di configurazione del server Vkontakte o di un'altra grande azienda, avranno più codice di quante parole ci siano in questo articolo.

Uno dei server web più popolari

Nginx è molto popolare tra gli utenti di server web e proxy grazie alle sue prestazioni. Il server ha molti vantaggi, ma può essere difficile da configurare per un principiante. Vogliamo aiutarti a capire i file di configurazione, la sintassi e le impostazioni di base di Nginx.

Gerarchia delle directory

Tutti i file di configurazione del server si trovano nella directory /etc/nginx. Inoltre, ci sono molte altre cartelle all'interno della directory, oltre a file di configurazione modulari.

cd / etc / nginx
ls -F
conf.d / koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available / win-utf
koi-utf naxsi_core.rules proxy_params abilitati per i siti /

Se hai utilizzato Apache, dovresti avere familiarità con le directory abilitate per i siti e disponibili per i siti. Determinano la configurazione dei siti. I file generati vengono memorizzati nell'ultima directory. La cartella dei siti abilitati è necessaria per memorizzare le configurazioni delle sole pagine attivate. Per collegarli, è necessario un collegamento simbolico tra le cartelle. Le configurazioni possono anche essere memorizzate nella directory conf.d. Allo stesso tempo, durante l'avvio di Nginx, ogni file con estensione .conf verrà riletto. Quando scrivi i file di configurazione, digita il codice correttamente e segui la sintassi. Tutti gli altri file si trovano in /etc/nginx. Il configuratore contiene informazioni su processi specifici e componenti aggiuntivi.

Il file di configurazione principale di Nginx è nginx.conf.

Legge tutti i file di configurazione, unendoli in uno, che viene richiesto all'avvio del server. Apri il file con:

sudo nano /etc/nginx/nginx.conf

Sullo schermo appariranno le seguenti righe:

dati www dell'utente;
processo_lavoratore 4;
pid /var/run/nginx.pid;
eventi (
connessioni_lavoratrici 768;
# multi_accetta attiva;
}
http (
. . .

Il primo è Informazione Generale su Nginx. La frase user www-data si riferisce all'utente che avvia il server. La direttiva pid mostra dove si trovano i processi PID. uso interno... La riga worker_processes mostra quanti processi Nginx può eseguire contemporaneamente. Inoltre, è possibile specificare qui i log (ad esempio, il log degli errori viene definito utilizzando la direttiva error_log). Di seguito la sezione eventi. È necessario per gestire le connessioni al server. Dopo è il blocco http.

Struttura del file di configurazione di Nginx

Comprendere la struttura di formattazione dei file ti aiuterà a capire meglio la configurazione del tuo server web. È diviso in blocchi strutturali... I dettagli di configurazione del blocco http sono stratificati utilizzando blocchi privati. Ereditano le proprietà dal genitore, ad es. quello in cui si trovano. Questo blocco memorizza la maggior parte delle configurazioni del server. Sono divisi in blocchi di server, all'interno dei quali si trova la posizione.

Quando configuri il tuo server Nginx, ricorda che più basso è il blocco di configurazione, meno elementi erediteranno le proprietà e viceversa. Il file contiene un gran numero di opzioni che modificano il funzionamento del server. È possibile impostare la compressione dei file inviati al client, ad esempio. Per fare ciò, scrivi i parametri:

gzip su;
gzip_disable "msie6";

Tieni presente che lo stesso parametro può assumere significati diversi v diversi blocchi... Prima impostalo in alto, quindi sovrascrivi il parametro su il livello giusto... Se l'ultima azione non viene eseguita, il programma imposterà i valori in modalità automatica.

Le ultime righe del file nginx.conf sono:

include /etc/nginx/conf.d/*.conf;
includi /etc/nginx/site-enabled/*;

Indicano che la posizione e i blocchi del server sono archiviati al di fuori di questo file. Definiscono le impostazioni per URL e file specifici. Questa struttura è necessaria per mantenere una struttura di configurazione modulare. Al suo interno, potrai creare nuove directory, file per vari siti. Oltretutto, file simili sarai in grado di raggruppare. Dopo la revisione, puoi chiudere il file nginx.conf.

Blocchi virtuali

Sono analoghi agli host virtuali in Apache. I blocchi di sezione del server includono le caratteristiche dei singoli siti che si trovano sul server. Nella cartella dei siti disponibili, troverai il file di blocco del server predefinito. Al suo interno, puoi trovare all'esterno i dati necessari che potrebbero essere richiesti durante la manutenzione dei siti.

cd siti disponibili
sudo nano predefinito
server (
root / usr / share / nginx / www;
indice index.html index.htm;
nome_server host locale;
Posizione / (
try_files $ uri $ uri //index.html;
}
posizione / documento / (
alias /usr/condivisione/doc/;
indice automatico attivo;
consentire 127.0.0.1;
negare tutto;
}
}

Nell'esempio sopra, i commenti sono stati deliberatamente rimossi. Questo è stato fatto per la leggibilità. All'interno dei blocchi del server ci sono le impostazioni racchiuse tra parentesi graffe:

Questo blocco viene posizionato utilizzando la direttiva include alla fine dell'http specificato nel file nginx.conf. La direttiva root definisce la directory in cui verrà posizionato il contenuto del sito. In esso, il programma cercherà i file che l'utente richiederà. Il percorso predefinito è /usr/share/nginx/www. Nginx separa le righe o le direttive l'una dall'altra con punti e virgola. Se non inserisci un segno di punteggiatura, diverse righe verranno lette come una sola. Per scrivere le regole che verranno utilizzate come indice, utilizzare la direttiva index. Il server li controllerà nell'ordine in cui sono elencati. Se nessuna delle pagine disponibili è stata richiesta dall'utente, verrà restituito index.html. Se non è presente, il server cercherà index.htm.

Regola nome_server

Include un elenco di nomi di dominio che devono essere elaborati dal blocco del server. Puoi scriverne un numero qualsiasi, separandoli con spazi. Se metti * alla fine o all'inizio di un dominio, sarai in grado di specificare un nome con una maschera. L'asterisco corrisponde a parte del nome. Se ti registri * .com.ua, quindi tutti gli indirizzi del specificato zona di dominio... Se l'indirizzo corrisponde alla descrizione di più direttive, risponderà con quella che si adatta perfettamente. Se non c'è corrispondenza, la risposta sarà il nome più lungo che ha una maschera. In caso contrario, le espressioni regolari verranno abbinate. I nomi dei server che utilizzano espressioni regolari iniziano con una tilde (~).

Blocchi di posizione

Il prossimo in linea avremo un blocco di posizione. È necessario per determinare il metodo di elaborazione certe richieste... Se le risorse non corrispondono ad altri blocchi di ubicazione, verranno applicate le direttive specificate tra parentesi. Questi blocchi possono includere un percorso come /doc/. Per stabilire una corrispondenza completa tra uri e location si usa il segno =. L'applicazione della tilde corrisponderà alle espressioni regolari. Puoi anche impostare la distinzione tra maiuscole e minuscole inserendo ~. Se aggiungi un asterisco, il caso non ha importanza.

Tieni presente: quando la richiesta corrisponde al blocco della posizione, verrà utilizzata e la ricerca si interromperà. Quando la corrispondenza è incompleta, l'URI verrà confrontato con i parametri delle direttive di localizzazione. Un blocco con la combinazione ^ ~ viene utilizzato per abbinare l'URI per la selezione del blocco. Se questa opzione non utilizzare, il server sceglie la corrispondenza migliore e cerca anche utilizzando le espressioni regolari. Questo è necessario per selezionare uno dei modelli adatti. Se viene trovata un'espressione corrispondente, verrà utilizzata. In caso contrario, verrà applicata la corrispondenza dell'URI precedente. Tuttavia, tieni presente che a Nginx piacciono di più le partite complete. Se non sono presenti, inizierà a cercare le espressioni regolari e quindi l'URI. La parità di ricerca è specificata dalla combinazione di caratteri ^ ~.

Regola Try_files

È molto attrezzo utile in grado di controllare i file in un ordine specificato. Applica i primi criteri di corrispondenza per elaborare la richiesta. Puoi usare Opzioni extra per definire come il server servirà le richieste. Il configuratore ha una riga predefinita come questa:

try_files $ uri $ uri //index.html;

Cosa significa? Se arriva una richiesta servita da un blocco di posizione, il server proverà prima a elaborare l'URI come file. Questo è fornito dalla variabile $ uri. Quando non c'è corrispondenza, l'URI verrà trattato come una directory. Puoi verificarne l'esistenza aggiungendo una barra alla fine: $ uri /. Ci sono situazioni in cui non verranno trovati né il file né la directory. In questo caso verrà caricato il file di default index.html. Si applica la regola Try_files ultimo parametro come ripiego. Ecco perchè questa vita deve essere nel sistema. Tuttavia, se non vengono trovate corrispondenze, Nginx restituirà una pagina di errore. Per impostarlo, scrivi = e il codice di errore:

Opzioni aggiuntive

Se applichi la regola dell'alias, sarai in grado di servire le pagine nel blocco della posizione al di fuori della directory principale, ad esempio. Quando i file sono necessari da doc, verranno richiesti da / usr / share / doc /. Inoltre, l'autoindex sulla regola inizia a elencare le directory del server per la direttiva di posizione specificata. Se scrivi le righe nega e consenti, sarai in grado di modificare l'accesso alle directory.

In conclusione, va detto che Nginx è uno strumento multifunzionale molto potente. Ma ottenere una buona comprensione di come funziona richiederà tempo e fatica. Se capisci come funzionano le configurazioni, puoi goderti appieno tutte le funzionalità del programma.

Altro). Versione corrente, 0.6.x è considerato stabile in termini di affidabilità e le versioni del ramo 0.7 sono considerate instabili. È importante notare che la funzionalità di alcuni moduli cambierà, per cui potrebbero cambiare anche le direttive, quindi retrocompatibilità in nginx prima della versione 1.0.0 non è garantito.

Perché nginx è così buono e perché gli amministratori di progetti ad alto carico lo adorano così tanto? Perché non usare semplicemente Apache?

Perché Apache è cattivo?

Innanzitutto, è necessario spiegare come funzionano generalmente i server di rete. Chi ha familiarità con la programmazione di rete sa che esistono essenzialmente tre modelli di funzionamento del server:

1. coerente. Il server apre un socket di ascolto e attende che venga visualizzata una connessione (è in uno stato bloccato durante l'attesa). Quando arriva una connessione, il server la elabora nello stesso contesto, chiude la connessione e attende nuovamente la connessione. Ovviamente, questo è tutt'altro che il modo migliore, soprattutto quando il cliente lavora da molto tempo e ci sono molte connessioni. Inoltre, il modello sequenziale presenta molti più svantaggi (ad esempio, l'impossibilità di utilizzare più processori) e in condizioni reali non viene praticamente utilizzato.
2. Multiprocesso (multithread). Il server apre un socket di ascolto. Quando arriva una connessione, la accetta, dopodiché crea (o prende da un pool di quelli precedentemente creati) nuovo processo oppure un thread che può lavorare con la connessione per un tempo arbitrariamente lungo, e alla fine del lavoro esce o torna al pool. Il thread principale, nel frattempo, è pronto per accettare una nuova connessione. Questo è il modello più popolare perché è relativamente facile da implementare, consente calcoli complessi e dispendiosi in termini di tempo per ogni cliente e utilizza tutti processori disponibili... Un esempio del suo utilizzo - Server web Apache... Tuttavia, questo approccio presenta anche degli svantaggi: con un numero elevato di connessioni simultanee, vengono creati molti thread (o, peggio ancora, processi) e il sistema operativo spreca molte risorse sui cambi di contesto. È particolarmente negativo quando i clienti sono molto lenti nell'accettare i contenuti. Risultano centinaia di thread o processi, occupati solo a inviare dati a client lenti, il che crea un carico aggiuntivo sullo scheduler del sistema operativo, aumenta il numero di interruzioni e consuma molta memoria.
3. Socket non bloccanti/macchina a stati. Il server funziona all'interno di un singolo thread, ma utilizza socket non bloccanti e un meccanismo di polling. Quelli. server ad ogni iterazione ciclo infinito seleziona da tutti i socket quello che è pronto a ricevere/inviare dati utilizzando la chiamata select(). Dopo aver selezionato un socket, il server gli invia i dati o li legge, ma non attende la conferma, ma passa allo stato iniziale e attende un evento su un altro socket, oppure elabora il successivo, in cui l'evento si è verificato durante l'elaborazione della precedente. Questo modello utilizza processore e memoria in modo molto efficiente, ma è piuttosto difficile da implementare. Inoltre, nell'ambito di questo modello, l'elaborazione di un evento su un socket deve essere molto veloce, altrimenti molti eventi si accumuleranno nella coda e alla fine traboccheranno. Ecco come funziona nginx. Inoltre, ti consente di avviare più processi di lavoro (chiamati lavoratori), ad es. può utilizzare più processori.

Quindi, immagina la seguente situazione: 200 client con un canale a 256 Kbps sono connessi a un server HTTP con un canale a 1 Gbps:

Cosa succede nel caso di Apache? Vengono creati 200 thread/processi che generano contenuti in tempi relativamente brevi (può essere come pagine dinamiche e file statici letti dal disco), ma passalo lentamente ai client. Sistema operativo ha a che fare con un mucchio di thread e blocchi di I/O.

In una situazione del genere, Nginx spende un ordine di grandezza in meno del sistema operativo e delle risorse di memoria su ciascuna connessione. Tuttavia, qui viene alla luce una limitazione del modello di rete nginx: non può generare contenuto dinamico dentro di te, perché questo porterà al blocco all'interno di nginx. Naturalmente, c'è una soluzione: nginx può delegare tali richieste (per la generazione di contenuti) a qualsiasi altro server web (ad esempio, lo stesso Apache) oa un server FastCGI.

Consideriamo il meccanismo di funzionamento del bundle nginx come server "principale" e Apache come server per la generazione di contenuto dinamico:

Nginx accetta la connessione dal client e legge l'intera richiesta da esso. Va notato qui che fino a quando nginx non ha letto l'intera richiesta, non la invia per "elaborazione". Per questo motivo, quasi tutti gli indicatori di avanzamento dei caricamenti di file di solito si "interrompono" - tuttavia, è possibile correggerli utilizzando il modulo upload_progress di terze parti (questo richiederà la modifica dell'applicazione).

Dopo che nginx ha letto l'intera risposta, apre una connessione ad Apache. Quest'ultimo fa il suo lavoro (genera contenuto dinamico), dopodiché invia la sua risposta a nginx, che lo memorizza nel buffer, oppure file temporaneo... Nel frattempo, Apache libera risorse. Inoltre, nginx invia lentamente il contenuto al client, spendendo ordini di grandezza in meno di risorse rispetto ad Apache.

Questo schema si chiama frontend + backend ed è usato molto spesso.

Installazione

Perché nginx sta appena iniziando a guadagnare popolarità, ci sono alcuni problemi con i pacchetti binari, quindi preparati a compilarlo da solo. Questo di solito non è un problema, devi solo leggere attentamente l'output del comando. / Configura --help e seleziona le opzioni di compilazione di cui hai bisogno, ad esempio:

./configura \
--Prefix = / opt / nginx-0.6.x \ # prefisso di installazione
--Conf-path = / etc / nginx / nginx.conf \ # posizione del file di configurazione
-Pid-path = / var / run / nginx.pid \ # ... e file pid
-User = nginx \ # nome utente sotto il quale verrà eseguito nginx
—With-http_ssl_module —with-http_gzip_static_module —with-http_stub_status_module \ # elenco di richieste
—Senza-http_ssi_module —senza-http_userid_module —senza-http_autoindex_module —senza-http_geo_module —senza-http_referer_module —senza-http_memcached_module —senza-http_limit_zone_module # ... e moduli non richiesti

Dopo la configurazione, dovresti eseguire lo standard make && make install, dopodiché puoi usare nginx.

In alternativa, in Gentoo puoi usare l'ebuild dall'albero dei port standard; in RHEL / CentOS il repository epel (dove si trova nginx 0.6.x) o srpm per la versione 0.7, che può essere scaricato da qui: http://blogs.mail.ru/community/nginx; su Debian, puoi usare il pacchetto nginx dal ramo unstable.

File di configurazione

Il file di configurazione di nginx è molto comodo e intuitivo. Di solito è chiamato nginx.conf e si trova in $ prefix / conf / se la posizione non è stata ridefinita durante la compilazione. Mi piace inserirlo in / etc / nginx /, e così fanno gli sviluppatori di tutti i pacchetti sopra menzionati.

La struttura del file di configurazione è la seguente:

utente nginx; # nome utente sotto il quale verrà eseguito nginx
processo_lavoratore 1; # numero di processi di lavoro
eventi (
<…># questo blocco specifica il meccanismo di polling che verrà utilizzato (vedi sotto) e il numero massimo di connessioni possibili
}

HTTP (
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# descrizione dei server (questo è ciò che Apache chiama VirtualHost)
server (
# indirizzo e nome del server
ascolta *: 80;
nome_server aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# ed è così che puoi definire la posizione, per la quale puoi anche sovrascrivere quasi tutte le direttive specificate a livelli più globali
posizione / abcd / (
<директивы>;
}
# Inoltre, puoi creare la posizione tramite un'espressione regolare, in questo modo:
posizione ~ \ .php $ (
<директивы>;
}
}

# un altro server
server (
ascolta *: 80;
nome_server ccc.bbb;

<директивы>
}
}

Notare che ogni direttiva deve terminare con un punto e virgola.
Reverse proxy e FastCGI

Quindi, sopra abbiamo esaminato i vantaggi dello schema frontend + backend, capito l'installazione, la struttura e la sintassi del file di configurazione, considera ora come implementare il proxy inverso in nginx.

È molto semplice! Ad esempio così:

Posizione / (
proxy_pass http://1.2.3.4:8080;
}

In questo esempio, tutte le richieste alla posizione / verranno inoltrate tramite proxy al server 1.2.3.4, porta 8080. Può essere apache o qualsiasi altro server http.

Tuttavia, ci sono diverse sottigliezze legate al fatto che l'applicazione assumerà che, in primo luogo, tutte le richieste gli arrivino dallo stesso indirizzo IP (che può essere interpretato, ad esempio, come un tentativo di attacco DDoS o attacco di forza bruta ), e in secondo luogo, considera che è in esecuzione sull'host 1.2.3.4 e sulla porta 8080 (rispettivamente, genera reindirizzamenti errati e link assoluti). Per evitare questi problemi senza dover riscrivere l'applicazione, mi sembra conveniente la seguente configurazione:
Nginx ascolta sull'interfaccia esterna sulla porta 80.

Se il backend (ad esempio, Apache) si trova sullo stesso host di nginx, "ascolta" la porta 80 su 127.0.0.1 o un altro indirizzo IP interno.

In questo caso, la configurazione di nginx è simile a questa:

server (
ascolta 4.3.2.1:80;
# imposta l'intestazione Host e X-Real-IP: ad ogni richiesta inviata al backend
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header Host $ host: $ proxy_port;
# o "proxy_set_header Host $ host;" se l'applicazione aggiungerà: 80 a tutti i collegamenti
}

Affinché l'applicazione possa distinguere gli indirizzi IP dei visitatori, è necessario installare il modulo mod_extract_forwarded (se eseguito dal server Apache) o modificare l'applicazione in modo che prenda le informazioni sull'indirizzo IP dell'utente dall'X- Intestazione HTTP Real-IP.

Un'altra opzione di backend sta usando FastCGI. In questo caso, la configurazione di nginx sarà simile a questa:

server (
<…>

# posizione in cui verranno inviate le richieste di script php
posizione ~ .php $ (
fastcgi_pass 127.0.0.1:8888; # definire l'indirizzo e la porta del server fastcgi,
fastcgi_index index.php; # ... file indice

# e alcuni parametri che devono essere passati al server fastcgi in modo che capisca quale script e con quali parametri eseguire:
fastcgi_param SCRIPT_FILENAME / usr / www / html $ fastcgi_script_name; # nome dello script
fastcgi_param QUERY_STRING $ query_string; # stringa della domanda
# e parametri di richiesta:
fastcgi_param REQUEST_METHOD $ request_method;
fastcgi_param CONTENT_TYPE $ content_type;
fastcgi_param CONTENT_LENGTH $ content_length;
}

#a causa del fatto che le posizioni con espressioni regolari hanno una "priorità" alta, tutte le richieste non php andranno qui.

Posizione / (
root /var/www/html/
}

statica

Per ridurre il carico sul back-end, è meglio servire file statici solo tramite nginx: affronta meglio questo compito, poiché per ogni richiesta, spende significativamente meno risorse (non è necessario generare un nuovo processo e il processo nginx di solito consuma meno memoria, e può servire molte connessioni).

Nel file di configurazione, appare così:

server (
ascolta *: 80;
nome_server mioserver.com;

Posizione / (
proxy_pass


"> Http://127.0.0.1:80;

}

# presuppone che tutti i file statici siano in / files
posizione / file / (
root /var/www/html/; # specifica il percorso di fs
scade 14d; # aggiungi l'intestazione Expires:
error_page 404 = @back; # e se il file non viene trovato, invialo alla posizione denominata @back
}

# richieste da / file, per le quali non è stato trovato alcun file, vengono inviate al backend e può generare il file desiderato o mostrare bel messaggio sull'errore
posizione @indietro (
proxy_pass
"Titolo =" http://127.0.0.1:80;

"> Http://127.0.0.1:80;

}

Se tutti i dati statici non sono inseriti in una directory specifica, usa un'espressione regolare:

location ~ * ^. + \. (jpg | jpeg | gif | png | ico | css | zip | tgz | gz | rar | bz2 | doc | xls | exe | pdf | ppt | txt | tar | wav | bmp | rtf | js) $ (
# simile a quanto sopra, solo tutte le richieste che terminano con uno dei suffissi specificati verranno inviate a questa posizione
root /var/www/html/;
error_page 404 = @back;
}

Sfortunatamente, nginx non supporta la gestione asincrona dei file. In altre parole, il lavoratore nginx è bloccato sulle operazioni di I/O. Quindi, se hai molti file statici e soprattutto se vengono letti da dischi diversi, è meglio aumentare il numero di processi di lavoro (fino a un numero 2-3 volte superiore al numero totale di testine sul disco). Questo, ovviamente, porta ad un aumento del carico sul sistema operativo, ma le prestazioni complessive aumentano. Per lavorare con una quantità tipica di statico (non un numero molto elevato di file relativamente piccoli: CSS, JavaScript, immagini), sono sufficienti uno o due flussi di lavoro.

Continua

Link

Maggiori informazioni su nginx possono essere trovate qui: