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
In questo caso, puoi sostituire i seguenti comandi (devono provenire dall'utente che ha lanciato lo strumento):
- Fermare. Utilizzato per lo spegnimento rapido.
- 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.
- Esentato. Utilizzato per uno spegnimento regolare. Viene utilizzato se è necessario attendere fino a quando le richieste in corso non sono terminate.
- 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 vedere un elenco di tutti i 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 di una fine, viene inserita una serie di istruzioni aggiuntive, che sono poste tra parentesi graffe ((istruzioni)). 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 (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, indichiamo il percorso / dati / www al file richiesto che si trova su 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 sembra essere standard.Questo server è facilmente accessibile sul 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. Se il normale funzionamento non è possibile, nei file error.log e access.log che si trovano nella direttiva /usr/local/nginx/logs, è possibile cercare la causa del malfunzionamento.
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 del file system locale che sono dirette alla directory / data / up1 (ovviamente, dovrà essere creato 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 (con una 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.
Altro). La versione corrente, 0.6.x, è considerata stabile per l'affidabilità, mentre 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 la compatibilità con le versioni precedenti in nginx fino alla versione 1.0.0 non è garantita.
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:
- 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.
- Multiprocesso (multithread). Il server apre un socket di ascolto. Quando arriva una connessione, la accetta, e poi crea (o prende dal pool di quelli precedentemente creati) un nuovo processo o thread che può lavorare con la connessione per tutto il tempo necessario, e al termine del lavoro, esce o ritorna alla piscina. 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 client e utilizza tutti i processori disponibili. Un esempio del suo utilizzo è il 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.
- 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. il server ad ogni iterazione di un loop infinito seleziona da tutti i socket quello che è pronto a ricevere/inviare dati tramite 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 in modo molto efficiente il processore e la memoria, 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 contenuto in tempi relativamente brevi (possono essere sia pagine dinamiche che file statici letti dal disco), ma lo danno lentamente ai client. Il 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, questo rivela un limite del modello di rete nginx: non può generare contenuti dinamici al suo interno, poiché questo porterà al blocco all'interno di nginx. Naturalmente, c'è una soluzione: nginx è in grado di 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 salva in memoria o in un 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 presumerà che, in primo luogo, tutte le richieste gli arrivino da un 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 (genera rispettivamente reindirizzamenti e collegamenti assoluti errati). 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 un'alta "priorità", 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é spende significativamente meno risorse per ogni richiesta (non è necessario generare un nuovo processo e il processo nginx di norma 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 un bel messaggio di 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 si hanno 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 su il 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:
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 l'aspetto dell'assembly binario versione 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 sia come software che esegue funzioni di server Web sia come hardware. Lo scambio dei dati e delle informazioni richieste avviene tramite il protocollo HTTP.
L'elenco delle funzioni aggiuntive dei server Web include: autorizzazione e autenticazione degli utenti, registrazione delle loro chiamate alle risorse, supporto HTTPS per la commutazione sicura con i client e altro. 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 interrogare indirettamente i servizi online. 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 può mantenere l'anonimato e proteggere il computer dagli 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:
- servizio server di file di indice, query statiche, generazione di descrittori per cache aperta, elenco di 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. A un server virtuale oa una direttiva possono essere assegnate porte e indirizzi per ricevere 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 un 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 un server HTTP molto veloce. 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.
Al momento, due server web hanno guadagnato la massima popolarità. Questi sono Apache e Ngnix. Ognuno ha i suoi pro e contro. Apache è stato sviluppato nel 1995 e non ha tenuto conto di tutte le possibili esigenze degli utenti durante il suo sviluppo, consuma molta memoria e risorse di sistema, ma è facile da configurare. Nginx è stato sviluppato poco dopo, nel 2002, tenendo conto degli errori di Apache e concentrandosi sulle massime prestazioni.
Non approfondiremo in dettaglio i pro e i contro di entrambi questi server web. Ognuno di loro ha la propria area di applicazione. Questo tutorial ti guiderà attraverso l'installazione di Nginx Ubuntu 16.04. Anche se parlerò di Ubuntu 16.04, tutti i passaggi funzioneranno anche per altre distribuzioni. L'installazione di Nginx è la stessa ovunque, solo il comando di installazione è diverso.
Il primo passo è installare il server web stesso sul sistema. Il programma si trova nei repository ufficiali, ma la sua versione è già un po' datata, quindi se vuoi l'ultima versione, devi aggiungere il PPA:
sudo apt-add-repository ppa: nginx / stable
Ora la versione 1.10.0 è disponibile nei repository ufficiali e la 1.10.1 è già disponibile nel PPA stabile. Se non hai bisogno di una versione, puoi fare a meno di un PPA. Successivamente, aggiorna gli elenchi dei pacchetti dai repository:
E installa ngnix:
sudo apt install nginx
Al termine dell'installazione del server Nginx, aggiungi il programma all'avvio in modo che si avvii automaticamente:
sudo systemctl abilita nginx
Se apri il browser ora, vedrai nginx funzionare, ma dobbiamo ancora configurarlo.
Configurazione di Nginx Ubuntu
La configurazione di Nginx Ubuntu è molto più complessa di Apache. Qui non prenderemo in considerazione tutte le opzioni e le capacità del programma, ma parleremo solo delle basi. Esistono varie configurazioni in cui Nginx viene utilizzato come server proxy e il server principale è Apache, ma questo non ci interesserà. Dobbiamo installare Nginx come server web autonomo.
Le impostazioni di Nginx sono molto diverse qui c'è solo un file di configurazione principale e file per host virtuali. La configurazione da ogni directory come in Apache non è supportata.
- /etc/nginx/nginx.conf- file di configurazione principale
- /etc/nginx/siti-disponibili/*- file di configurazione per host virtuali, in altre parole, per ogni sito.
- /etc/nginx/site-enabled/*- file di configurazione dei siti attivati.
In effetti, i file di configurazione per gli host virtuali vengono letti solo dalla directory abilitata per i siti, ma ci sono collegamenti ai siti disponibili qui. Tale sistema è stato inventato per consentire di disabilitare temporaneamente alcuni siti senza cancellarne la configurazione. Tutti gli altri file contengono solo dichiarazioni di variabili e impostazioni standard che non devono essere modificate. Per quanto riguarda nginx.conf, include tutti i file dei siti abilitati e quindi possono contenere tutte le stesse identiche istruzioni. Ora diamo un'occhiata al file di configurazione principale:
sudo vi /etc/nginx/nginx.conf
Come puoi vedere il file è diviso in sezioni. La struttura generale è la seguente:
opzioni globali
eventi ()
http (
server (
Posizione ()
}
server ()
}
posta ()
- opzioni globali sono responsabili del funzionamento dell'intero programma.
- eventi- questa sezione contiene le impostazioni per lavorare con la rete.
- http- contiene le impostazioni del server web. Dovrebbe contenere una sezione del server per la messa a punto di ciascun sito.
- server- questa sezione contiene la configurazione di ogni sito ospitato sul server web.
- Posizione- la sezione location può essere solo all'interno della sezione server e contiene le impostazioni solo per una specifica richiesta.
- posta- contiene le impostazioni per un proxy di posta.
Prima di passare alle opzioni, ci sono ancora alcune parole da dire sulla sintassi della riga nel file di configurazione. Sembra così:
valore del parametro valore_extra ...;
La riga deve terminare con ";" e tutte le parentesi aperte (devono essere chiuse.
Ora che hai esplorato un po' la struttura globale, puoi passare a esaminare i parametri stessi. Non ci sono così tante opzioni globali:
- utente- l'utente per conto del quale verrà eseguito il programma.
- processo_lavoratore- imposta quanti processi devi avviare per parallelizzare il programma, non devi avviare più processi di quanti ne hai i core. Puoi impostare il parametro auto e quindi il programma determinerà questo numero stesso.
- pid= file pid del programma.
- worker_rlimit_nofile- indica il numero massimo di file che il programma può aprire. Calcolato come worker_processes * worker_connections * 2.
Con le opzioni globali terminate, non ce n'erano così tante e non sono così interessanti. Le opzioni della sezione eventi sono molto più interessanti in termini di ottimizzazione:
- connessioni_lavoratori- il numero di connessioni che il programma può gestire contemporaneamente su un processo. Se moltiplichiamo worker_process per questo parametro, otteniamo il numero massimo di utenti che possono connettersi contemporaneamente al server. Si consiglia di impostare un valore compreso tra 1024 e 4048.
- multi_accetta- consentire di accettare più connessioni contemporaneamente, impostare il parametro su on o off.
- uso- il modo di lavorare con lo stack di rete. L'impostazione predefinita è poll, ma per Linux è più efficiente usare epoll.
- inviare file- utilizzare il metodo sendfile di invio dei dati. Il su.
- tcp_nodelay, tcp_nopush- inviare le intestazioni e l'inizio del file in un unico batch. Il su.
- keepalive_timeout- timeout di attesa prima che la connessione keepalive venga terminata, per impostazione predefinita 65, ma può essere ridotto a 10 secondi.
- keepalive_requests- si consiglia il numero massimo di connessioni keepalive da un client, 100.
- reset_timedout_connection- disconnettersi dopo il timeout. Il su.
- open_file_cache- informazioni sulla cache sui file aperti. La riga di configurazione ha questo aspetto: open_file_cache max = 200000 inactive = 20s; max - il numero massimo di file nella cache, tempo di memorizzazione nella cache.
- open_file_cache_valid- indica dopo quanto tempo è necessario eliminare le informazioni dalla cache. Ad esempio: open_file_cache_valid 30s;
- open_file_cache_min_uses- cache informazioni sui file che sono stati aperti almeno il numero di volte specificato.
- open_file_cache_errors- informazioni sulla cache sui file mancanti, valore su.
Vengono presi in considerazione i parametri principali. Queste impostazioni ti aiuteranno a ottenere prestazioni migliori da nginx. Esamineremo la sezione server e posizione nella configurazione degli host virtuali.
Configurazione della compressione Gzip
La compressione del contenuto è necessaria per ridurre la dimensione dei dati caricati dal browser. Ciò accelera il caricamento del sito, ma aggiunge ulteriore carico al processore del server. Per abilitare la compressione nella sezione http, aggiungi il parametro:
Questa direttiva può essere utilizzata anche nella sezione server, quindi funzionerà solo per il dominio virtuale specificato. Successivamente, impostiamo i parametri di compressione utilizzando le seguenti opzioni:
- gzip_min_length- la lunghezza minima della pagina in byte, alla quale è necessario utilizzare la compressione, ad esempio 1000 (1 kb)
- gzip_proxied- se le richieste proxy devono essere compresse, any dice che tutto deve essere compresso.
- gzip_types- tipi di file che devono essere compressi, ad esempio: testo / applicazione semplice / applicazione xml / testo x-javascript / testo javascript / testo css / json;
- gzip_disable "msie6"- La compressione non è supportata in IE 6, quindi disabilitala.
- gzip_comp_level- livello di compressione, sono disponibili le opzioni da 1 a 10. 1 - minima, 10 - massima compressione.
Configurazione degli host virtuali
Come sai, un server può ospitare più siti. Tutte le richieste arrivano all'ip del server e nginx determina già quale contenuto deve essere visualizzato in base al dominio. Affinché nginx sappia a quale dominio appartiene, è necessario configurare gli host virtuali. È consuetudine posizionare ciascun host in un file separato. La configurazione dell'host si trova nella sezione server, ma poiché tutti i file dai siti abilitati vengono importati nella sezione http, la logica della struttura del file di configurazione non viene interrotta.
Diamo un'occhiata a un'impostazione di esempio:
vi /etc/nginx/sites-enabled/site.conf
- ascolta 80- indica di attendere una connessione sulla porta 80, può contenere anche un'opzione default-server, il che significa che questo dominio verrà aperto se il dominio non è stato specificato nella richiesta.
- root / var / www / html- la directory in cui si trovano i file del sito.
- index index.html- la pagina che si aprirà di default.
- nome del server- il nome a dominio del sito.
- access_log- un file per la registrazione di un log delle richieste al server, utilizzabile sia globalmente nella sezione http, sia per una specifica tipologia di file in locazione.
- error_log- il log degli errori del server web, può assumere un parametro aggiuntivo che specifica i dettagli del log. warning - massimo, crit - solo errori critici.
Queste sono tutte le impostazioni di base dell'host virtuale, dopodiché funzionerà già. Ma c'è anche una sezione sulla posizione, che ti permette di configurare il comportamento del server per directory e file specifici. La sintassi per la posizione è:
indirizzo di posizione ()
Poiché l'indirizzo può essere utilizzato come richiesta diretta per la radice del server e le espressioni regolari. Per utilizzare le espressioni regolari, precederlo con il carattere "~". Prenderemo in considerazione degli esempi di seguito, ma per ora prenderemo in considerazione le possibili direttive:
- permettere- consentire l'accesso alla posizione per gli utenti, tutti - per tutti, è anche possibile specificare l'ip o la sottorete.
- negare- negare l'accesso alla posizione, tutti - per tutti.
- file di prova- tenta di aprire i file in un ordine specifico, apre il primo file trovato. Ad esempio, una costruzione del genere: $ uri $ uri / index.html $ uri.html = 404; prima prova ad aprire $ uri, poi index.html, se $ uri.html non viene trovato, e poi, se nessuno dei file preposizionali esiste, dà un errore 404.
- scade- imposta il tempo di memorizzazione nella cache del browser per l'elemento dato, ad esempio 1d - un giorno, 2h - due ore, 30s - 30 secondi.
Oltre a queste direttive principali, se ne possono utilizzare altre. Per maggiori dettagli consultare la documentazione ufficiale. Vediamo un paio di esempi:
Non accedere alla favicon:
posizione = /favicon.ico (
log_not_found spento;
access_log off;
}
Nega l'accesso ai file che iniziano con un punto:
posizione ~ / \. (
negare tutto;
}
Memorizza nella cache i file regolari per 90 giorni:
location ~ * ^. + \. (ogg | ogv | svg | svgz | eot | otf | woff | mp4 | ttf | rss | atom | jpg | jpeg | gif | png | ico | zip | tgz | gz | rar | bz2 | doc | xls | exe | ppt | tar | mid | midi | wav | bmp | rtf) $ (
access_log off; log_not_found spento; scade 90d;
Nginx è un server web popolare e performante e un server proxy inverso.
Nginx ha molti vantaggi, ma le sue impostazioni sono piuttosto complesse e non sempre chiare ai principianti. Questa guida ti aiuterà a comprendere i parametri di base, la sintassi e i file di configurazione per Nginx.
Nota: Tutorial realizzato su Ubuntu 12.04.
Gerarchia di directory Nginx
Nginx memorizza i file di configurazione nella directory / etc / nginx.
Questa directory contiene molte altre directory e 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 /
Gli utenti di Apache hanno già familiarità con le directory dei siti disponibili e abilitate per i siti. Queste directory definiscono le configurazioni del sito. I file vengono solitamente creati e archiviati in siti disponibili; sites-enabled memorizza solo le configurazioni dei siti abilitati. Per fare ciò, è necessario creare un collegamento simbolico da siti disponibili a siti abilitati.
La directory conf.d può essere utilizzata anche per memorizzare le configurazioni. Ogni file .conf verrà letto all'avvio di Nginx. La sintassi di tali file dovrebbe essere priva di errori.
Quasi tutti i file rimanenti sono archiviati in / etc / nginx, che contiene informazioni di configurazione per processi specifici o componenti aggiuntivi.
Il file di configurazione principale di Nginx è nginx.conf.
File Nginx.conf
Il file nginx.conf legge i file di configurazione appropriati e li unisce in un unico file di configurazione all'avvio del server.
Apri il file:
sudo nano /etc/nginx/nginx.conf
dati www dell'utente;
processo_lavoratore 4;
pid /var/run/nginx.pid;
eventi (
connessioni_lavoratrici 768;
# multi_accetta attiva;
}
http (
. . .
Le prime righe forniscono informazioni generali su Nginx. La stringa di dati www dell'utente specifica l'utente con cui viene avviato il server.
La direttiva pid specifica dove verranno archiviati i PID dei processi per uso interno. La riga worker_processes definisce il numero di processi che Nginx può supportare contemporaneamente.
Inoltre, in questa parte del file, è possibile specificare i log (ad esempio, il log degli errori viene definito utilizzando la direttiva error_log).
Le informazioni generali sul server sono seguite dalla sezione degli eventi. Gestisce la gestione delle connessioni Nginx. È seguito dal blocco http. Prima di continuare con le configurazioni del tuo server web, devi capire come è formattato il file di configurazione di Nginx.
Struttura del file di configurazione di Nginx
Il file di configurazione di Nginx è diviso in blocchi.
Il primo blocco è costituito da eventi, seguito da http e inizia la gerarchia di configurazione principale.
I dettagli di configurazione del blocco http sono stratificati utilizzando blocchi privati che ereditano le proprietà dal blocco in cui si trovano. Il blocco http memorizza la maggior parte delle configurazioni generali di Nginx, che sono suddivise in blocchi server, che a loro volta sono divisi in blocchi di posizione.
Quando si configura Nginx, è importante ricordare la seguente regola: più alto è il livello di configurazione, più blocchi erediteranno quella configurazione; più basso è il livello di configurazione, più "individuale" è. Cioè, se il parametro X deve essere utilizzato in ogni blocco del server, allora tale parametro deve essere inserito nel blocco http.
Se osservi attentamente il file, noterai che contiene molte opzioni che determinano il comportamento del programma nel suo insieme.
Ad esempio, per configurare la compressione dei file, è necessario impostare i seguenti parametri:
gzip su;
gzip_disable "msie6";
Ciò abiliterà il supporto gzip per la compressione dei dati inviati al client e disabiliterà gzip per Internet Explorer 6 (poiché questo browser non supporta la compressione dei dati).
Se un parametro deve avere un valore diverso in più blocchi server, tale parametro può essere impostato al livello più alto e quindi ridefinito all'interno dei blocchi server stessi. Di conseguenza, Nginx eseguirà il parametro di livello più basso.
Questa suddivisione in livelli delle configurazioni evita la necessità di gestire più file identici. Inoltre, se hai dimenticato di definire i parametri di basso livello, Nginx eseguirà semplicemente i parametri predefiniti.
Il blocco http nel file nginx.conf finisce così:
include /etc/nginx/conf.d/*.conf;
includi /etc/nginx/site-enabled/*;
Ciò significa che il server e i blocchi di posizione che definiscono le impostazioni per siti e URL specifici verranno archiviati all'esterno di questo file.
Ciò consente di mantenere un'architettura di configurazione modulare in cui è possibile creare nuovi file per servire nuovi siti. Ti consente anche di raggruppare file simili insieme.
Chiudi il file nginx.conf. Ora è necessario esaminare le impostazioni per i singoli siti.
Blocchi virtuali Nginx
I blocchi server in Nginx sono analoghi agli host virtuali Apache (ma per comodità sono anche chiamati host virtuali). In sostanza, i blocchi server sono le caratteristiche tecniche dei singoli siti web ospitati su un singolo server.
Nella directory dei siti disponibili, puoi trovare il file di blocco del server predefinito fornito con il server. Questo file contiene tutti i dati necessari per mantenere il sito.
cd siti disponibili
sudo nano predefinito
root / usr / share / nginx / www;
indice index.html index.htm;
nome_server host locale;
Posizione / (
}
posizione / documento / (
alias /usr/condivisione/doc/;
indice automatico attivo;
consentire 127.0.0.1;
negare tutto;
Il file è commentato molto bene per impostazione predefinita, ma nell'esempio sopra i commenti sono stati omessi per semplicità e comodità.
Il blocco del server include tutte le impostazioni, poste tra parentesi graffe:
server (
. . .
}
Questo blocco viene posizionato nel file nginx.conf vicino alla fine del blocco http utilizzando la direttiva include.
La direttiva root definisce la directory in cui verrà archiviato il contenuto del sito. In questa directory, Nginx cercherà i file richiesti dall'utente. Per impostazione predefinita, questa directory è / usr / share / nginx / www.
Si prega di notare che tutte le righe terminano con un punto e virgola. Questo è il modo in cui Nginx disaccoppia una direttiva dall'altra. Se non è presente il punto e virgola, Nginx leggerà le due direttive (o più direttive) come una direttiva con argomenti aggiuntivi.
La direttiva index definisce i file da utilizzare come indice. Il server web controllerà i file nell'ordine in cui sono elencati. Se non è stata richiesta alcuna pagina, il blocco del server troverà e restituirà il file index.html. Se non riesce a trovare questo file, proverà ad analizzare index.htm.
Direttiva nome_server
La direttiva server_name contiene un elenco di nomi di dominio che verranno serviti da questo blocco di server. Il numero di domini è illimitato; Separare i domini nell'elenco con spazi.
Un asterisco (*) all'inizio o alla fine di un dominio specifica un nome con una maschera, dove l'asterisco corrisponde a parte (o più parti) del nome. Ad esempio, * .example.com corrisponderà a forum.example.com e www.animals.example.com.
Se l'URL richiesto corrisponde a più direttive server_name, risponderà prima con quella che corrisponde esattamente.
Se l'indirizzo non trova una corrispondenza, cercherà il nome mascherato più lungo che termina con un asterisco. Se non trova tale nome, restituirà la prima corrispondenza dell'espressione regolare.
I nomi dei server che utilizzano espressioni regolari iniziano con una tilde (~). Sfortunatamente, questo argomento esula dallo scopo di questo articolo.
Blocchi di posizione
La posizione/riga specifica che le direttive tra parentesi verranno applicate a tutte le risorse richieste che non corrispondono ad altri blocchi di posizione.
Tali blocchi possono contenere un percorso uri (es. /doc/). Per stabilire una corrispondenza completa tra posizione e uri, viene utilizzato il simbolo =. Il simbolo ~ corrisponde alle espressioni regolari.
La tilde abilita la modalità con distinzione tra maiuscole e minuscole e la tilde con un asterisco abilita la modalità con distinzione tra maiuscole e minuscole.
Se la richiesta corrisponde completamente al blocco della posizione, il server interrompe la ricerca e utilizza tale blocco. Se il server non trova un blocco di posizione completamente corrispondente, confronta l'URI con i parametri delle direttive di posizione. Nginx selezionerà un blocco che utilizza la combinazione di caratteri ^ ~ e corrisponde all'URI.
Se l'opzione ^ ~ non viene utilizzata, Nginx sceglierà la corrispondenza più vicina ed eseguirà una ricerca di espressioni regolari per cercare di abbinare uno dei modelli disponibili. Se trova un'espressione del genere, la usa. Se non esiste tale espressione, il server utilizza la corrispondenza URI trovata in precedenza.
In conclusione, va notato che Nginx preferisce le corrispondenze esatte. Se non esiste tale corrispondenza, cerca un'espressione regolare e quindi cerca l'URI. Per modificare la priorità delle ricerche URI, utilizzare la combinazione di caratteri ^ ~.
Direttiva Try_files
La direttiva try_files è uno strumento molto utile che verifica l'esistenza di file in un determinato ordine e utilizza il primo file trovato per elaborare la richiesta.
Ciò consente di utilizzare parametri aggiuntivi per definire come Nginx servirà le richieste.
C'è una riga nel file di configurazione predefinito:
try_files $ uri $ uri //index.html;
Ciò significa che quando arriva una richiesta servita da un blocco di posizione, Nginx proverà prima a servire l'uri come file (questo comportamento è impostato dalla variabile $ uri).
Se il server non trova una corrispondenza per la variabile $ uri, proverà a utilizzare l'uri come directory.
Il server utilizza una barra alla fine per verificare l'esistenza della directory, ad esempio $ uri /.
Se non viene trovato alcun file o directory, Nginx esegue il file predefinito (in questo caso index.html nella directory principale del blocco del server). Ogni direttiva try_files utilizza l'ultimo parametro come fallback, quindi questo file deve esistere nel sistema.
Nel caso in cui il server web non abbia trovato corrispondenze nei parametri precedenti, può restituire una pagina di errore. Per questo, vengono utilizzati un segno di uguale e un codice di errore.
Ad esempio, se la posizione/blocco non riesce a trovare la risorsa richiesta, potrebbe restituire un errore 404 invece del file index.html:
try_files $ uri $ uri / = 404;
Per fare ciò, è necessario inserire un segno di uguale e impostare il codice di errore come ultimo parametro (= 404).
Opzioni extra
La direttiva alias consente a Nginx di servire pagine nel blocco di posizione al di fuori della directory specificata (ad esempio, al di fuori di root).
Ad esempio, i file richiesti da /doc/ verranno serviti da /usr/share/doc/.
La direttiva autoindex on abilita l'elenco delle directory Nginx per la direttiva location data.
Le righe Consenti e Nega controllano l'accesso alle directory.
Conclusione
Il server web Nginx è ricco di funzionalità e molto performante, ma la sua terminologia e i suoi parametri possono creare confusione.
Comprendendo e lavorando con le configurazioni di Nginx, puoi sfruttare appieno questo strumento potente e leggero.
tag:,
