Nginx? Scop, caracteristici, opțiuni de setări - acestea sunt lucruri cu care fiecare dezvoltator web ar trebui să fie familiarizat pentru a-și testa munca.

Să spunem un cuvânt despre nginx

Acest instrument are un proces principal și mai multe procese de lucru. Prima se ocupă de citirea și verificarea configurației. Managementul procesului de lucru este, de asemenea, sub controlul său. Sarcina acestuia din urmă este să proceseze cererile primite. Nginx folosește un model bazat pe evenimente. Mecanisme dependente de sistem de operare pentru a realiza distribuirea eficientă a cererilor direct între procesele lucrătorilor. Numărul lor este întotdeauna indicat în Fișier de configurare. Valoarea poate fi fie fixă, fie setată automat, în funcție de număr nuclee de procesor, cu care poți lucra. În nginx, sistemul și modulele sunt configurate folosind un fișier de configurare. Prin urmare, dacă trebuie să schimbați ceva, atunci trebuie să îl căutați. Este de obicei localizat în directiva /etc/nginx (dar calea se poate schimba atunci când utilizați alte sisteme) și are o extensie .conf.

Pornire, repornire și jurnalele

Pentru a face acest lucru, trebuie să faceți fișierul executabil să funcționeze. Configurarea serverului nginx este posibilă numai atunci când rulează. Controlat prin apelare fisier executabil cu parametrul -s. Pentru a face acest lucru, utilizați următoarea notație:

semnal nginx -s

ÎN în acest caz, Puteți înlocui următoarele comenzi (trebuie să provină de la utilizatorul care a lansat instrumentul):

1. Stop. Folosit pentru a opri rapid munca.
2. Reîncărcați. Comanda este necesară pentru a reîncărca fișierul de configurare. Ideea este că nicio modificare nu va fi aplicată în timp ce fișierul rulează. Și pentru ca acestea să aibă efect, este necesară o repornire. De îndată ce acest semnal este primit, procesul principal va începe să verifice corectitudinea sintaxei fișierului de configurare și să încerce să aplice instrucțiunile acolo. Dacă nu reușește, va anula modificările și va funcționa cu setările vechi. Dacă totul s-a întâmplat cu succes, atunci noi procese de lucru vor fi lansate, iar celor vechi li se va trimite o cerere de încetare.
3. Părăsi. Folosit pentru finalizarea fără probleme a lucrărilor. Folosit dacă trebuie să așteptați până când solicitările curente sunt finalizate de service.
4. Redeschide. Închideți și deschideți fișierele jurnal.

Utilizarea Utilităților

Procesele pot fi configurate și folosind instrumente Unix (utilitatea kill va fi considerată ca exemplu). Ei folosesc de obicei un mecanism pentru a trimite un semnal către proces direct cu date. Acestea sunt conectate folosind ID. Aceste date sunt stocate în fișierul nginx.pid. Să zicem că ne interesează procesul nr. 134. Apoi, pentru o finalizare fără probleme, trebuie să trimitem următoarele informații:

kill -s QUIT 1628

Să presupunem că vrem să vedem o listă cu toate fișierele care rulează. Folosim utilitarul ps pentru asta. Comanda va arăta astfel:

ps -ax | grep nginx

Adică, după cum puteți vedea, atunci când utilizați instrumente suplimentare, este indicat că este utilizat. Acum să ne concentrăm asupra modului în care se realizează configurarea nginx.

Structura fișierului de configurare

Instalarea și configurarea nginx implică lucrul cu module. Ele sunt configurate folosind directivele care sunt specificate în fișierul de configurare. Sunt simple și bloc. Primul tip de directivă constă dintr-un nume și parametri, care sunt separați prin spații și se termină cu punct și virgulă (;). Blocul are o structură similară. Dar în această directivă, în loc de un final, este plasat un set instructiuni aditionale, care sunt plasate în acolade ((instrucțiuni)). Dacă pot conține numele și parametrii altor procese, atunci astfel de construcții se numesc context. Exemplele includ http, locația și serverul.

Se difuzează conținut static

Aceasta este una dintre cele mai importante sarcini cu care se confruntă configurația nginx. Prin distribuirea de conținut statistic ne referim la imagini și pagini HTML (nu dinamice). Să presupunem că avem nevoie de o singură lucrare de configurare a unui cluster nix nginx. Este greu de făcut? Nu, și să ne uităm la un exemplu. Înainte de a o începe, este necesar să detaliați condițiile sarcinii. Deci, în funcție de solicitări, fișierele vor proveni din diferite directoare locale. Deci, în /data/www avem documente HTML. Și directorul /data/images conține imagini. Setare optimă nginx în acest caz necesită editarea fișierului de configurare, în care trebuie să configurați blocul serverului în http. Două locații vor fi, de asemenea, folosite pentru sprijin.

Implementare: server

Deci, mai întâi trebuie să creăm directoarele în sine și să plasăm fișiere în ele extensiile necesare(trebuie să adăugați conținut la html). Apoi deschideți fișierul de configurare. În mod implicit, conține deja mai multe blocuri de server, care sunt în mare parte comentate. Pentru a obține rezultate optime, acest proces trebuie efectuat pentru toate componentele implicite. Apoi adăugăm un nou bloc de server folosind următorul cod:

Fișierul de configurare poate funcționa cu mai multe astfel de blocuri. Dar trebuie să difere în ceea ce privește numele și porturile prin care sunt primite datele.

Implementare: locație

Definit în interiorul serverului:

Prezența semnului „/” este necesară pentru a compara datele primite și pentru a vedea dacă o astfel de adresă din cererea procesată este aici. Dacă nu există probleme, atunci specificați calea /data/www către fișierul necesar, ce este în asta sistem local. Dacă există o potrivire cu mai multe blocuri, atunci este selectat cel cu cel mai lung prefix. În exemplul dat, lungimea sa este egală cu unu, adică va fi folosit exclusiv dacă nu există „concurenți”. Acum să o îmbunătățim:

locație /imagini/ (

Cum poți să-ți dai seama dacă căutăm imagini? Acum să combinăm toate dezvoltările care au fost făcute anterior și configurația activată acest moment după cum urmează:

locație /imagini/ (

Aceasta este o opțiune de lucru, care este standard.Acest server poate fi accesat de pe computerul local fără probleme dacă mergeți la adresa: http://localhost/. Cum vor funcționa toate acestea?

Cum funcționează exemplul

Deci, când sosesc cereri care încep cu /images, serverul va trimite fișiere din directorul corespunzător către utilizator. Dacă lipsește, vor fi transmise informații care indică o eroare 404. Dacă nginx este configurat pe un computer local, atunci când solicităm http://localhost/images/example.png vom primi un fișier a cărui locație este /data/images/ exemplu.png. Dacă specificați un caracter „/”, căutarea va fi efectuată în directorul /data/www. Dar tocmai am schimbat configurația. Pentru ca acesta să înceapă să funcționeze, trebuie să fie repornit. Pentru a face acest lucru, utilizați comanda nginx -s reload. În cazul când operatie normala nu este posibil, atunci puteți căuta cauza problemei în fișierele error.log și access.log situate în directiva /usr/local/nginx/logs.

Crearea unui server proxy simplu

Se poate spune despre nginx - configurarea acestui obiect este una dintre utilizările comune (și destul de ușoară, de altfel). Folosește principiul unui server care primește cereri și apoi le redirecționează către site-urile necesare. După aceasta, se așteaptă un răspuns de la ei, care îi direcționează către cel care i-a atribuit sarcina. Deci, să ne uităm la un exemplu de creare a unui punct de bază. Acesta va gestiona solicitările utilizatorilor și le va furniza imagini din directorul local. Deci, la blocul http adăugăm un alt server cu următorul conținut:

Acum permiteți-mi să vă descifrez: se creează un server simplu. Va asculta. Dacă nu specificați ascultare, serverul va rula pe 80. Toate cererile din zona locală vor fi afișate Sistemul de fișiere, care sunt direcționate către directorul /data/up1 (desigur, va trebui creat înainte de aceasta). Pentru a putea verifica, trebuie să plasați fișierul index.html acolo. Prin plasarea directivei rădăcină în contextul serverului, putem folosi locația în orice condiții (deoarece aceasta elimină restricțiile de acces). Acum lucrăm la crearea unui server proxy. Pentru ca acesta să funcționeze, avem nevoie de directiva proxy_pass, pentru care protocolul, numele și portul obiect vor fi specificate ca parametri (dacă conexiune locală va arăta ca http://localhost:8080). Veți obține următorul rezultat:

proxy_pass http://localhost:8080;

locație /imagini/ (

Dacă te uiți la cod și îl analizezi, este posibil să observi că al doilea bloc de locație a fost schimbat. Deci, în acest caz, poate funcționa cu extensii de imagine tipice. Ar putea fi afișat puțin diferit, astfel:

locație ~ \.(gif|jpg|png)$ (

root /data/imagini;

Configurația finală a serverului proxy arată astfel:

proxy_pass http://localhost:8080/;

locație ~ \.(gif|jpg|png)$ (

root /data/imagini;

Va filtra interogările care se termină cu extensii specificateși trimiteți-le persoanei care a cerut fișierele. Nu uitați că, dacă doriți să verificați fișierul de configurare, va trebui să-l reîncărcați. Și credeți-mă, aceasta este cea mai simplă configurare nginx. Dacă deschideți fișierul de configurare a serverului VKontakte sau al unei alte companii mari, acestea vor avea mai mult cod decât cuvinte în acest articol.

Si altii). Versiune curentă,0.6.x, este considerat stabil din punct de vedere al fiabilității, iar lansările din ramura 0.7 sunt considerate instabile. Este important de remarcat faptul că funcționalitatea unor module se va modifica, drept urmare directivele se pot modifica și, prin urmare compatibilitate inversăîn nginx înainte de versiunea 1.0.0 nu este garantat.

De ce este nginx atât de bun și de ce administratorii proiectelor cu încărcare mare îl iubesc atât de mult? De ce să nu folosești Apache?

De ce este rău Apache?

Mai întâi trebuie să explicăm cum funcționează în general. servere de rețea. Cei familiarizați cu programarea în rețea știu că există în esență trei modele de funcționare a serverului:

1. Consistent. Serverul deschide o priză de ascultare și așteaptă să apară o conexiune (este într-o stare blocată în timp ce așteaptă). Când ajunge o conexiune, serverul o procesează în același context, închide conexiunea și așteaptă din nou conexiunea. Evident, acesta este departe de cel mai bun mod, mai ales când lucrul cu un client durează mult și există o mulțime de conexiuni. În plus, modelul serial are mult mai multe dezavantaje (de exemplu, incapacitatea de a utiliza mai multe procesoare), iar în conditii reale practic nu este folosit.
2. Multi-proces (multi-threaded). Serverul deschide o priză de ascultare. Când sosește o conexiune, o acceptă, după care creează (sau preia dintr-un grup de conexiuni pre-create) un nou proces sau fir care poate funcționa cu conexiunea atâta timp cât se dorește și, la terminarea lucrului, se încheie sau întoarce-te la piscină. Între timp, firul principal este gata să accepte o nouă conexiune. Acesta este cel mai mult model popular, deoarece este relativ ușor de implementat, permite efectuarea de calcule complexe și consumatoare de timp pentru fiecare client și utilizează toate procesoarele disponibile. Un exemplu de utilizare a acestuia - Web- server Apache. Cu toate acestea, această abordare are și dezavantaje: cu un număr mare de conexiuni simultane, se creează o mulțime de fire de execuție (sau, și mai rău, procese), iar sistemul de operare irosește o mulțime de resurse pe comutatoarele de context. Este deosebit de rău când clienții acceptă foarte încet conținutul. Acest lucru are ca rezultat sute de fire de execuție sau procese ocupate cu trimiterea de date către clienții lenți, ceea ce creează încărcare suplimentară pe planificatorul sistemului de operare, crește numărul de întreruperi și consumă destul de multă memorie.
3. Prize non-blocante/mașină de stat. Serverul operează într-un singur fir, dar folosește socket-uri neblocante și un mecanism de sondare. Acestea. server la fiecare iterație buclă nesfârșită Selectează din toate soclulurile pe cel care este gata să primească/trimite date folosind apelul select(). După ce socket-ul este selectat, serverul îi trimite date sau îl citește, dar nu așteaptă confirmarea, ci trece la starea inițială și așteaptă un eveniment pe alt socket sau îl prelucrează pe următorul în care a avut loc evenimentul în timpul procesării precedentul. Acest model folosește procesorul și memoria foarte eficient, dar este destul de complex de implementat. În plus, în cadrul acestui model, procesarea evenimentelor pe un socket trebuie să aibă loc foarte rapid - altfel multe evenimente se vor acumula în coadă și, în cele din urmă, se vor deborda. Acesta este exact modelul pe care lucrează nginx. În plus, vă permite să rulați mai multe procese de lucru (așa-numitele lucrători), de exemplu. poate folosi mai multe procesoare.

Deci, imaginați-vă următoarea situație: 200 de clienți cu un canal de 256 Kbit/s se conectează la un server HTTP cu un canal de 1 Gbit/s:

Ce se întâmplă în cazul Apache? Sunt create 200 de fire/procese care generează conținut relativ rapid (ar putea fi ceva de genul pagini dinamice, și fișierele statice citite de pe disc), dar le livrează încet clienților. Sistemul de operare este forțat să facă față unei mulțimi de fire și blocări I/O.

În această situație, Nginx cheltuiește cu un ordin de mărime mai puține resurse ale sistemului de operare și memorie pe fiecare conexiune. Cu toate acestea, există o limitare aici model de rețea nginx: nu poate genera continut dinamicîn interiorul tău, pentru că acest lucru va duce la blocaje în interiorul nginx. Desigur, există o soluție: nginx poate trimite astfel de solicitări (pentru generarea de conținut) către orice alt server web (de exemplu, același Apache) sau către un server FastCGI.

Să considerăm mecanismul de funcționare al combinației nginx ca server „principal” și Apache ca server pentru generarea de conținut dinamic:

Nginx acceptă conexiunea de la client și citește întreaga solicitare de la acesta. Trebuie remarcat aici că până când nginx nu a citit întreaga solicitare, nu o trimite pentru „procesare”. Din acest motiv, aproape toți indicatorii de progres al încărcării fișierelor se „rup” - totuși, este posibil să-i remediați folosind modulul upload_progress de la terț (acest lucru va necesita modificarea aplicației).

După ce nginx a citit întregul răspuns, deschide o conexiune la Apache. Acesta din urmă își face treaba (generează conținut dinamic), după care își trimite răspunsul către nginx, care îl tamponează în memorie sau fișier temporar. Între timp, Apache eliberează resurse. În continuare, nginx livrează lent conținutul clientului, în timp ce cheltuiește ordin de mărime mai puține resurse decât Apache.

Această schemă se numește frontend + backend și este folosită foarte des.

Instalare

Deoarece nginx abia începe să câștige popularitate, există unele probleme cu pachetele binare, așa că fiți pregătit să îl compilați singur. De obicei, nu există probleme cu aceasta, trebuie doar să citiți cu atenție rezultatul comenzii./configure --help și să selectați opțiunile de compilare de care aveți nevoie, de exemplu acestea:

./configure\
--prefix=/opt/nginx-0.6.x \ # prefix de instalare
--conf-path=/etc/nginx/nginx.conf \ # locația fișierului de configurare
—pid-path=/var/run/nginx.pid \ # ... și fișierul pid
—user=nginx \ # nume de utilizator sub care va rula nginx
—cu-http_ssl_module —cu-http_gzip_static_module —cu-http_stub_status_module \ # listă de necesare
—fără-http_ssi_module —fără-http_userid_module —fără-http_autoindex_module —fără-http_geo_module —fără-http_referer_module —fără-http_memcached_module —fără-http_limit_zone_module # ... și module inutile

După configurare, ar trebui să rulați instalarea standard make && make, după care puteți utiliza nginx.

În plus, în Gentoo puteți utiliza un ebuild din arborele standard de porturi; în RHEL/CentOS de către depozitul epel (care conține nginx 0.6.x) sau srpm pentru versiunea 0.7, care poate fi descărcat de aici: http://blogs.mail.ru/community/nginx; pe Debian puteți folosi pachetul nginx din ramura instabilă.

Fișier de configurare

Fișierul de configurare nginx este foarte convenabil și intuitiv. Se numește de obicei nginx.conf și se află în $prefix/conf/ dacă locația nu a fost suprascrisă în timpul compilării. Îmi place să îl pun în /etc/nginx/, la fel ca și dezvoltatorii tuturor pachetelor menționate mai sus.

Structura fișierului de configurare este următoarea:

utilizator nginx; # nume de utilizator cu ale cărui drepturi va rula nginx
lucrător_procese 1; # număr de procese de lucru
evenimente (
<…># acest bloc specifică mecanismul de interogare care va fi utilizat (vezi mai jos) și numărul maxim de conexiuni posibile
}

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

# descrierea serverelor (aceasta este ceea ce se numește VirtualHost în apache)
Server(
# adresa și numele serverului
asculta *:80;
nume_server aaa.bbb;

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

# și așa puteți defini o locație, pentru care puteți, de asemenea, să suprascrieți aproape toate directivele specificate la niveluri mai globale
locație /abcd/ (
<директивы>;
}
# În plus, puteți face locația folosind o expresie regulată, de exemplu, ca aceasta:
locație ~ \.php$ (
<директивы>;
}
}

# un alt server
Server(
asculta *:80;
nume_server ccc.bbb;

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

Vă rugăm să rețineți că fiecare directivă trebuie să se încheie cu punct și virgulă.
Reverse proxy și FastCGI

Deci, mai sus ne-am uitat la avantajele schemei frontend + backend, ne-am dat seama de instalarea, structura și sintaxa fișierului de configurare, iar acum ne vom uita la cum să implementăm reverse proxy în nginx.

Și este foarte simplu! De exemplu astfel:

Locație/(
proxy_pass http://1.2.3.4:8080;
}

În acest exemplu, toate cererile care se încadrează în locație / vor fi trimise proxy către serverul 1.2.3.4, portul 8080. Acesta poate fi fie apache, fie orice alt server http.

Cu toate acestea, există mai multe subtilități legate de faptul că aplicația va considera că, în primul rând, toate solicitările îi vin de la aceeași adresă IP (care poate fi privită, de exemplu, ca o încercare de atac DDoS sau de ghicire a parolei), și în al doilea rând, să presupunem că rulează pe gazda 1.2.3.4 și pe portul 8080 (în consecință, generați redirecționări incorecte și legături absolute). Pentru a evita aceste probleme fără a fi nevoie să rescrieți aplicația, găsesc la îndemână următoarea configurație:
Nginx ascultă interfața externă pe portul 80.

Dacă backend-ul (să spunem Apache) este situat pe aceeași gazdă ca nginx, atunci „ascultă” pe portul 80 pe 127.0.0.1 sau pe altă adresă IP internă.

Configurația nginx în acest caz arată astfel:

Server(
asculta 4.3.2.1:80;
# setați antetul Host și X-Real-IP: pentru fiecare solicitare trimisă către backend
proxy_set_header X-Real-IP $adresă_la distanță;
proxy_set_header Gazdă $gazdă:$proxy_port;
# sau „proxy_set_header Host $host;” dacă aplicația va adăuga:80 la toate linkurile
}

Pentru ca aplicația să distingă adresele IP ale vizitatorilor, trebuie fie să instalați modulul mod_extract_forwarded (dacă este executat de serverul Apache), fie să modificați aplicația astfel încât să preia informații despre adresa IP a utilizatorului de la X- Antet HTTP real-IP.

O altă opțiune de backend este utilizarea FastCGI. În acest caz, configurația nginx va arăta cam așa:

Server(
<…>

# locație unde vor merge cererile pentru scripturi php
locație ~ .php$ (
fastcgi_pass 127.0.0.1:8888; # determinați adresa și portul serverului fastcgi,
fastcgi_index index.php; # ...fișier index

# și câțiva parametri care trebuie să fie transferați serverului fastcgi, astfel încât acesta să înțeleagă ce script să execute și cu ce parametri:
fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # nume script
fastcgi_param QUERY_STRING $șir_interogare; # șir de interogare
# și parametrii de solicitare:
fastcgi_param REQUEST_METHOD $cerere_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}

# datorită faptului că locațiile cu expresii regulate au o „prioritate” mare, toate solicitările non-php vor cădea aici.

Locație/(
rădăcină /var/www/html/
}

Statică

Pentru a încărca mai puțin backend-ul, este mai bine să serviți fișiere statice numai prin nginx - face față mai bine acestei sarcini, deoarece cheltuiește mult mai puține resurse pentru fiecare solicitare (nu este nevoie să generați un nou proces, dar procesul nginx consumă de obicei mai putina memorie, și poate servi multe conexiuni).

În fișierul de configurare arată cam așa:

Server(
asculta *:80;
nume_server serverul meu.com;

Locație/(
proxy_pass


„>http://127.0.0.1:80;

}

# presupunem că toate fișierele statice sunt în /fișiere
locație /fișiere/ (
rădăcină /var/www/html/; # indica calea către fs
expiră 14d; # adăugați antetul Expires:
error_page 404 = @back; # iar dacă fișierul nu este găsit, îl trimitem la locația numită @back
}

# solicitările de la /fișiere pentru care nu a fost găsit niciun fișier sunt trimise la backend și poate fi generată fișierul necesar, sau spectacol mesaj frumos despre eroare
locație @back (
proxy_pass
"title="http://127.0.0.1:80;

„>http://127.0.0.1:80;

}

Dacă toate statisticile nu sunt plasate într-un anumit director, atunci utilizați o expresie regulată:

locație ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf |js)$ (
# similar cu ceea ce este mai sus, numai toate cererile care se termină cu unul dintre sufixele specificate vor merge în această locație
rădăcină /var/www/html/;
error_page 404 = @back;
}

Din păcate, nu este implementat în nginx lucru asincron cu dosare. Cu alte cuvinte, lucrătorul nginx este blocat la operațiunile I/O. Deci, dacă aveți o mulțime de fișiere statice și, mai ales dacă sunt citite de pe discuri diferite, este mai bine să creșteți numărul de procese de lucru (la un număr care este de 2-3 ori mai mare decât numărul total de capete de pe disc ). Acest lucru, desigur, crește încărcarea sistemului de operare, dar performanța generală crește. Pentru a lucra cu o cantitate tipică de conținut static (nu un număr foarte mare de fișiere relativ mici: CSS, JavaScript, imagini), unul sau două fluxuri de lucru sunt suficiente.

Va urma

Legături

Aici puteți găsi informații suplimentare despre nginx:

Nginx este un server web și un proxy de e-mail care este disponibil public din 2004. Dezvoltarea proiectului a început în 2002; în rusă numele sună ca engine-ex. Fiind creația celebrului programator Igor Sysoev, Nginx a fost inițial destinat companiei Rambler. Este conceput pentru sistemele de operare aparținând grupului Unix-like. Ansamblul a fost testat cu succes pe OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. Pe platformă Microsoft Windows Nginx a început să lucreze odată cu apariția versiunii de ansamblu binar 0.7.52.

Statisticile pentru martie 2011 indică faptul că numărul de site-uri deservite de Nginx a depășit deja pragul de 22 de milioane. Astăzi, Nginx este folosit de proiecte cunoscute precum Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru și altele. Alături de lighttpd, Nginx este folosit pentru a servi conținut static generat de o aplicație web „incomodă” care funcționează „sub autoritatea” unui alt server web.
Dar înainte de a pătrunde în jungla caracteristicilor funcționale ale lui Nginx, ar fi util să ne amintim ce este un server web în general și un server proxy în special.

Server web și server proxy

server web este un server care acceptă solicitări HTTP de la browsere web și alți clienți și emite răspunsuri HTTP la acestea. Acestea din urmă sunt de obicei reprezentate Pagina HTML, flux media, imagine, fișier, alte date. Un server web este înțeles ca software, efectuând funcții de server web și hardware. Schimbul de date și informații solicitate se realizează prin protocolul HTTP.

Adaugă la listă funcții suplimentare serverele web includ: autorizarea și autentificarea utilizatorilor, înregistrarea accesului acestora la resurse, suport HTTPS pentru comunicarea securizată cu clienții și altele. Cel mai des folosit server web pe sisteme de operare asemănătoare Unix este Apache. Nginx ocupă în prezent locul trei în lista preferințelor clienților.

Server proxy permite clienților să se ocupe de interogări de căutare La servicii de rețeaîntr-o formă indirectă. Adică este un server specializat în redirecționarea cererilor clienților către alte servere. Conectându-se la un server proxy și solicitând o resursă situată pe un alt server, clientul are posibilitatea de a păstra anonimatul și de a proteja computerul de atacurile de rețea. Serverul proxy furnizează clientului datele solicitate fie din propriul cache (dacă există), fie primind-o de la serverul specificat. În unele cazuri (pentru a atinge obiectivele de mai sus), răspunsul serverului, precum cererea clientului, poate fi schimbat de serverul proxy.

Cel mai simplu server proxy este Network Address Translator sau NAT. În 2000, a fost încorporat proxy NAT distribuție Windows. Serverele proxy, ca orice fenomen, au două fețe ale monedei, adică pot fi folosite atât pentru bine, cât și pentru rău. De exemplu, cu ajutorul lor, cei care se tem de sancțiuni pentru acțiunile lor nepotrivite online își ascund adresele IP...

Gama funcțională Nginx:

• întreținerea pe server a fișierelor index, interogări statice, generarea de descriptori cache a fișierelor deschise, listă de fișiere;
• proxy accelerat, distribuție elementară a sarcinii, toleranță la erori;
• suport pentru cache în timpul proxy-ului accelerat și FastCGI;
• suport pentru FastCGI (accelerat) și servere memcached;
• modularitate, filtre, inclusiv reluare (interval de octeți) și compresie (gzip);
• Autentificare HTTP, răspunsuri fragmentate, filtru SSI;
• executarea paralelă a mai multor subinterogări pe o pagină procesată prin FastCGI sau un proxy în filtrul SSI;
• Suport StartTLS și SSL;
• capacitatea de a suporta Perl încorporat;
• autentificare simplă (UTILIZATOR/PASS, LOGIN);
• redirecționarea serverului (proxy IMAP/POP3) a utilizatorului către backend-ul IMAP/POP3 utilizând un server de autentificare extern (HTTP).

Pentru cei care nu sunt familiarizați cu această terminologie, descrierea funcționalității Nginx poate părea foarte vagă. Dar când vorbim despre modalitățile specifice de utilizare a acestui server web, acesta va începe treptat să se disipeze.

Arhitectură și configurație

Procesele de lucru din Nginx servesc simultan mai multe conexiuni, oferindu-le apeluri cu OS (sistem de operare) epoll (Linux), select și kqueue (FreeBSD). Datele primite de la client sunt analizate folosind o mașină de stări. Cererea analizată este procesată de un lanț de module specificat de configurare. Răspunsul către client este generat în buffere, care pot indica o secțiune a unui fișier sau pot stoca date în memorie. Secvența transferului de date către client este determinată de lanțurile în care sunt grupate tampoanele.

Din punct de vedere structural, serverul HTTP Nginx este împărțit în servere virtuale, care la rândul lor sunt împărțite în locații. Un server virtual sau o directivă poate fi specificat cu porturi și adrese pentru primirea conexiunilor. Pentru locație, puteți specifica un URI exact, o parte a unui URI sau o expresie obișnuită. Pentru gestionarea memoriei online, se folosesc pool-uri, care sunt o secvență de blocuri de memorie preselectate. Un bloc, alocat inițial pentru pool, are o lungime de la 1 la 16 kilobytes. Este împărțit în zone - ocupate și neocupate. Pe măsură ce acesta din urmă se umple, alocarea unui nou obiect este asigurată de formarea unui nou bloc.

Clasificarea geografică a clienților după adresa lor IP se face în Nginx folosind modul special. Sistemul de arbore Radix vă permite să lucrați rapid cu adrese IP, ocupând un minim de memorie.

Beneficiile Nginx

Nginx este considerat foarte rapid server HTTP. În loc de Apache sau împreună cu acesta, Nginx este folosit pentru a accelera procesarea cererilor și pentru a reduce sarcina pe server. Adevărul este că oportunități uriașe, inerente arhitecturii modulare Apache, nu sunt solicitate de majoritatea utilizatorilor. Trebuie să plătiți pentru această funcționalitate nerevendicată cu un consum semnificativ de resurse de sistem. Site-urile obișnuite, de regulă, sunt caracterizate de o „dominare” clară a fișierelor statice (imagini, fișiere de stil, JavaScript), mai degrabă decât de scripturi. Nu este necesară nicio funcționalitate specială pentru a transfera aceste fișiere către un vizitator de resurse, deoarece sarcina este foarte simplă. Aceasta înseamnă că serverul web pentru procesarea unor astfel de solicitări trebuie să fie simplu și ușor, precum Nginx.

Modalități de utilizare a Nginx

Pe un port/IP separat. Dacă resursa este saturată cu imagini sau fișiere pentru descărcare, Nginx poate fi configurat pe un port sau IP separat și să distribuie conținut static prin intermediul acestuia. Pentru a face acest lucru, va trebui, totuși, să schimbați puțin link-urile de pe site. Dacă există un număr mare de solicitări către fișiere statice, este logic să creați un server separat și să instalați Nginx pe el.

Proxy accelerat. Cu această opțiune, toate solicitările vizitatorilor ajung mai întâi la Nginx. Solicitări de fișiere statice (de exemplu, imagini, HTML simplu, JavaScript sau fișier CSS) Nginx îl procesează independent. Dacă un utilizator accesează un anumit script, el va redirecționa solicitarea către departamentul Apache. Nu este nevoie să faceți nicio transformare cu codul site-ului.

Dacă canalul de la server la vizitator și invers este lent, această utilizare a Nginx poate da un efect suplimentar. Nginx trece cererea primită de la vizitator către Apache pentru procesare. După procesarea cererii, Apache redirecționează pagina către Nginx și închide conexiunea cu un sentiment de realizare. Nginx poate trimite acum o pagină unui utilizator atât timp cât dorește, practic fără a consuma resurse de sistem. Lucrarea Apache în locul său ar fi însoțită de o încărcare nerezonabilă a memoriei atunci când rulează aproape inactiv. Apropo, acest caz de utilizare pentru Nginx are alt nume: "frontend către Apache".

Nginx plus FastCGI. Apache poate să nu fie deloc necesar dacă interpretul limbii în care sunt scrise scripturile site-ului acceptă tehnologia FastCGI. Astfel de limbi includ, de exemplu, PHP, Perl și o serie de altele. Cu toate acestea, în acest caz, poate fi necesar să modificați codurile de script.

Există multe materiale detaliate despre cum să instalați și să configurați Nginx pe Internet. Puteți afla mai multe despre Nginx pe site-ul web al dezvoltatorului său Igor Sysoev.

În acest moment, două servere web au câștigat cea mai mare popularitate. Acestea sunt Apache și Ngnix. Fiecare dintre ele are propriile sale avantaje și dezavantaje. Apache a fost dezvoltat încă din 1995 și dezvoltarea sa nu a ținut cont de toate nevoile posibile ale utilizatorilor; consumă multă memorie și resurse de sistem, dar este ușor de configurat. Nginx a fost dezvoltat puțin mai târziu în 2002, ținând cont de erorile Apache și concentrându-se pe performanță maximă.

Nu vom intra în detalii despre avantajele și dezavantajele ambelor servere web. Fiecare dintre ele are propriul său domeniu de aplicare. Acest ghid va acoperi instalarea Nginx Ubuntu 16.04. Deși voi vorbi despre Ubuntu 16.04, toți pașii vor funcționa și pentru alte distribuții. Configurarea Nginx este aceeași peste tot, doar comanda de instalare este diferită.

Primul pas este să instalați serverul web în sine pe sistem. Programul se află în depozitele oficiale, dar versiunea sa este deja puțin învechită, așa că dacă doriți cea mai recentă versiune, trebuie să adăugați un PPA:

sudo apt-add-repository ppa:nginx/stable

În prezent, versiunea 1.10.0 este disponibilă în depozitele oficiale, iar 1.10.1 este deja disponibilă în PPA stabil. Dacă nu aveți nevoie de versiune, puteți face fără PPA. Apoi, actualizați listele de pachete din depozite:

Și instalează ngnix:

sudo apt install nginx

După instalare Serverul Nginx va fi finalizat, adăugați programul la pornire, astfel încât să pornească automat:

sudo systemctl enable nginx

Dacă deschideți browserul acum, veți vedea că nginx rulează, dar tot trebuie să îl configuram.

Configurarea Nginx Ubuntu

Configurarea Nginx Ubuntu este mult mai complicată decât Apache. Aici nu vom lua în considerare toate opțiunile și capacitățile programului, ci vom vorbi doar despre cele principale. Mânca diverse configurații, în care Nginx este folosit ca server proxy și serverul principal Apache, dar nu ne va interesa asta. Trebuie să instalăm Nginx ca server web autonom.

Setările Nginx sunt foarte diferite - există un singur fișier de configurare principal și fișiere pentru gazdele virtuale. Configurația din fiecare director, ca în Apache, nu este acceptată.

• /etc/nginx/nginx.conf- fișierul de configurare principal
• /etc/nginx/sites-available/*- fisiere de configurare pentru gazde virtuale, cu alte cuvinte, pentru fiecare site.
• /etc/nginx/sites-enabled/*- fișierele de configurare ale site-urilor activate.

De fapt, fișierele de configurare pentru gazde virtuale sunt citite numai din directorul site-uri activate, dar acesta conține link-uri către site-uri disponibile. Acest sistem a fost inventat pentru a face posibilă dezactivarea temporară a anumitor site-uri fără a le șterge configurația. Toate celelalte fișiere conțin doar declarații variabile și setări standard, care nu trebuie schimbate. În ceea ce privește nginx.conf, toate fișierele de la site-enables sunt incluse în acesta și, prin urmare, pot conține exact aceleași instrucțiuni. Acum să ne uităm la fișierul de configurare principal:

sudo vi /etc/nginx/nginx.conf

După cum puteți vedea, fișierul este împărțit în secțiuni. Structura generală este aceasta:

opțiuni globale
evenimente()
http(
Server(
Locație()
}
Server()
}
Poștă()

• opțiuni globale sunt responsabili pentru funcționarea întregului program.
• evenimente- această secțiune conține setări pentru lucrul cu rețeaua.
• http- conține setări de server web. Ar trebui să conțină o secțiune de server pentru reglarea fină a fiecărui site.
• Server- aceasta sectiune contine setarile pentru fiecare site gazduit pe serverul web.
• Locație- secțiunea de locație poate fi localizată doar în interiorul secțiunii de server și conține setări doar pentru o anumită solicitare.
• Poștă- conține setări de proxy de e-mail.

Înainte de a trece la opțiuni, trebuie să mai spunem câteva cuvinte despre sintaxa liniei din fișierul de configurare. Arata cam asa:

valoarea parametrului valoare_suplimentară...;

Linia trebuie să se termine cu „;” și toate parantezele deschise (trebuie să fie închise.

Acum că ați studiat puțin structura globală, puteți trece la analizarea parametrilor înșiși. Nu există multe opțiuni globale:

• utilizator- utilizatorul în numele căruia va rula programul.
• procese_lucrători- setează câte procese trebuie lansate pentru a paraleliza activitatea programului; nu trebuie să lansați mai multe procese decât aveți nuclee. Puteți seta parametrul autoși apoi programul va determina el însuși acest număr.
• pid= fișier pid program.
• worker_rlimit_nofile- indică numărul maxim de fișiere pe care programul le poate deschide. Calculat ca worker_processes * worker_connections* 2.

Am terminat cu opțiunile globale; nu erau multe și nu erau atât de interesante. Mult mai interesante din punct de vedere al optimizării sunt opțiunile din secțiunea evenimente:

• conexiuni_lucrători- numărul de conexiuni pe care programul le poate procesa simultan pe un proces. Dacă înmulțim worker_process cu acest parametru, obținem numărul maxim de utilizatori care se pot conecta la server în același timp. Se recomandă setarea valorii de la 1024 la 4048.
• multi_accept- permite acceptarea mai multor conexiuni în același timp, setați parametrul pornit sau dezactivat.
• utilizare- o modalitate de a lucra cu stiva de rețea. Valoarea implicită este poll, dar pe Linux este mai eficient să utilizați epoll.

• Trimite fișier- utilizați metoda de trimitere a datelor sendfile. Valoarea este activată.
• tcp_nodelay, tcp_nopush- trimiteți antetele și începutul fișierului într-un singur pachet. Valoarea este activată.
• keepalive_timeout- timeout de așteptare înainte ca conexiunea Keepalive să fie închisă, implicit este 65, dar poate fi redus la 10 secunde.
• keepalive_requests- numărul maxim de conexiuni keepalive de la un client, recomandat 100.
• reset_timedout_connection- întrerupeți conexiunile după un timeout. Valoarea este activată.
• open_file_cache- cache informații despre fișierele deschise. Linia de setare arată astfel: open_file_cache max=200000 inactive=20s; max - numărul maxim de fișiere în cache, timpul de stocare în cache.
• open_file_cache_valid- indică după ce oră trebuie ștearsă informațiile din cache. De exemplu: open_file_cache_valid 30s;
• open_file_cache_min_uses- cache informații despre fișierele care au fost deschise de cel puțin un anumit număr de ori.
• open_file_cache_errors- cache informații despre fișierele lipsă, valoarea activată.

Principalii parametri au fost revizuiți. Aceste setări vă vor ajuta să obțineți performanțe mai bune de la nginx. Ne vom uita la secțiunile server și locație în configurarea gazdelor virtuale.

Configurarea compresiei Gzip

Comprimarea conținutului este necesară pentru a reduce dimensiunea datelor descărcate de browser. Acest lucru accelerează încărcarea site-ului, dar adaugă încărcare suplimentară procesorului serverului. Pentru a activa compresia în secțiunea http, trebuie să adăugați următorul parametru:

Această directivă poate fi folosită și în secțiunea server, atunci va funcționa numai pentru domeniul virtual specificat. În continuare, configurăm parametrii de compresie folosind următoarele opțiuni:

• gzip_min_length- lungimea minimă a paginii în octeți la care trebuie utilizată compresia, de exemplu, 1000 (1 kb)
• gzip_proxied- dacă este necesar să comprimați cererile proxy, orice spune că totul trebuie comprimat.
• gzip_types- tipuri de fișiere care trebuie comprimate, de exemplu: text/plain application/xml application/x-javascript text/javascript text/css text/json;
• gzip_disable „msie6”- compresia nu este acceptată în IE 6, așa că o dezactivăm.
• gzip_comp_level- nivel de compresie, opțiuni disponibile de la 1 la 10. 1 - minim, 10 - compresie maximă.

Configurarea gazdelor virtuale

După cum știți, un server poate găzdui mai multe site-uri web. Toate cererile vin la IP-ul serverului, iar nginx determină deja, pe baza domeniului, ce conținut trebuie servit. Pentru ca nginx să știe ce aparține cărui domeniu trebuie configurat gazde virtuale. Fiecare gazdă este de obicei plasată într-un fișier separat. Configurația gazdei se află în secțiunea server, dar deoarece toate fișierele de pe site-uri activate sunt importate în secțiunea http, logica structurii fișierelor de configurare nu este întreruptă.

Să ne uităm la un exemplu de configurare:

vi /etc/nginx/sites-enabled/site.conf

• asculta 80- specifică că o conexiune ar trebui ascultată pe portul 80, poate conține și o opțiune server implicit, ceea ce înseamnă că acest domeniu va fi deschis dacă domeniul nu a fost specificat în cerere.
• rădăcină /var/www/html- directorul în care se află fișierele site-ului.
• index index.html- pagina care se va deschide implicit.
• numele serverului - Numele domeniului site-ul.
• access_log- un fisier pentru inregistrarea unui log al cererilor catre server, poate fi folosit atat global in sectiunea http cat si pentru un anumit tip de fisier in locatie.
• error_log- jurnalul erorilor serverului web, poate accepta un parametru suplimentar care indică detaliile jurnalului. warn - maxim, crit - numai erori critice.

Acestea sunt toate setările de bază pentru gazda virtuală, după care va funcționa deja. Dar există și o secțiune de locație, care vă permite să configurați comportamentul serverului pentru anumite directoare și fișiere. Sintaxa locației este:

adresa locatiei()

Atât o interogare directă cu privire la rădăcina serverului, cât și expresiile regulate pot fi folosite ca adresă. Pentru a utiliza expresii regulate, acesta este precedat de un caracter „~”. Să ne uităm la exemplele de mai jos, dar deocamdată să ne uităm la posibilele directive:

• permite- permite accesul la locație pentru utilizatori, toți - toată lumea, puteți specifica și un ip sau o subrețea.
• nega- interziceți accesul la locație, tuturor - pentru toată lumea.
• fișierele de încercare- încearcă să deschidă fișierele într-o anumită ordine, deschide primul fișier găsit. De exemplu, această construcție: $uri $uri/index.html $uri.html =404; mai întâi încearcă să deschidă $uri, apoi index.html, dacă $uri.html nu este găsit și apoi, dacă niciun fișier prepozițional nu există, dă o eroare 404.
• expiră- setează timpul de stocare în cache a browserului pentru elementul dat, de exemplu, 1d - o zi, 2h - două ore, 30s - 30 secunde.

Pe lângă aceste directive principale, aici pot fi utilizate și altele. Pentru mai multe detalii, consultați documentația oficială. Să ne uităm la câteva exemple:

Nu înregistrați favicon:

locație = /favicon.ico (
log_not_found off;
access_log off;
}

Interziceți accesul la fișierele care încep cu un punct:

locație ~ /\. (
nega totul;
}

Memorați în cache fișierele obișnuite timp de 90 de zile:

locație ~* ^.+\.(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 off; expiră 90d;

Nginx este un server web popular și puternic și un proxy invers.

Nginx are multe avantaje, dar setările sale sunt destul de complexe și nu întotdeauna clare pentru începători. Acest ghid vă va ajuta să înțelegeți parametrii de bază, sintaxa și fișierele de configurare ale lui Nginx.

Notă: Acest tutorial a fost realizat pe Ubuntu 12.04.

Ierarhia directorului Nginx

Nginx stochează fișierele de configurare în directorul /etc/nginx.

Acest director conține mai multe directoare și fișiere de configurare modulare.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf site-available/win-utf
koi-utf naxsi_core.rules proxy_params site-uri activate/

Utilizatorii Apache sunt deja familiarizați cu directoarele disponibile pentru site-uri și site-uri activate. Aceste directoare definesc configurațiile site-ului. Fișierele sunt de obicei create și stocate în site-uri disponibile; site-uri activate stochează numai configurațiile site-urilor activate. Pentru a face acest lucru, trebuie să creați un link simbolic de la site-uri disponibile la site-uri activate.

Directorul conf.d poate fi folosit și pentru a stoca configurații. Fiecare fișier cu o extensie .conf va fi citit când Nginx pornește. Sintaxa unor astfel de fișiere nu trebuie să conțină erori.

Aproape toate fișierele rămase sunt stocate în /etc/nginx, care conține informații de configurare pentru anumite procese sau componente suplimentare.

Fișierul principal de configurare Nginx este nginx.conf.

fișierul nginx.conf

Fișierul nginx.conf citește fișierele de configurare corespunzătoare și le combină într-un singur fișier de configurare atunci când serverul pornește.

Deschideți fișierul:

sudo nano /etc/nginx/nginx.conf

utilizator www-date;
lucrător_procese 4;
pid /var/run/nginx.pid;
evenimente (
conexiuni_muncitor 768;
#multi_accept on;
}
http(
. . .

Primele rânduri oferă informații generale despre Nginx. Utilizatorul de linie www-data specifică utilizatorul cu care este pornit serverul.

Directiva pid specifică unde să stocați PID-uri de proces Pentru uz intern. Linia worker_processes determină numărul de procese pe care Nginx le poate suporta simultan.

De asemenea, puteți specifica jurnalele în această parte a fișierului (de exemplu, jurnalul de erori este definit folosind directiva error_log).

Urmează informațiile generale despre server se află secțiunea de evenimente. Acesta gestionează gestionarea conexiunilor Nginx. Este urmat de blocul http. Înainte de a continua cu configurațiile serverului web, trebuie să înțelegem cum este formatat fișierul de configurare Nginx.

Structura fișierului de configurare Nginx

Fișierul de configurare Nginx este împărțit în blocuri.

Primul bloc este evenimente, urmat de http și începe ierarhia principală a configurațiilor.

Detaliile de configurare ale unui bloc http sunt stratificate folosind blocuri închise care moștenesc proprietăți de la blocul în care se află. Blocul http stochează majoritatea configurațiilor generale Nginx, care sunt împărțite în blocuri de server, care la rândul lor sunt împărțite în blocuri de locații.

Când configurați Nginx, este important să rețineți următoarea regulă: cu cât este mai mare nivelul de configurare, cu atât mai multe blocuri moștenesc această configurație; cu cât nivelul de configurare este mai scăzut, cu atât este mai „individual”. Adică, dacă parametrul X trebuie utilizat în fiecare bloc de server, atunci un astfel de parametru trebuie plasat în blocul http.

Dacă te uiți cu atenție la fișier, vei observa că acesta conține multe opțiuni care determină comportamentul programului în ansamblu.

De exemplu, pentru a configura compresia fișierelor, trebuie să setați următorii parametri:

gzip on;
gzip_disable „msie6”;

Acest lucru va activa suportul gzip pentru comprimarea datelor trimise către client și va dezactiva gzip pentru Internet Explorer 6 (deoarece acest browser nu acceptă compresia datelor).

Dacă vreun parametru ar trebui să aibă sens diferitîn mai multe blocuri de server, atunci un astfel de parametru poate fi activat nivel superiorși apoi suprascrieți-l în interiorul blocurilor serverului. Ca rezultat, Nginx va executa parametrul de cel mai jos nivel.

Această stratificare a configurațiilor evită nevoia de a gestiona mai multe fișiere identice. De asemenea, dacă ați uitat să definiți parametrii Cel mai mic nivel, Nginx va implementa pur și simplu opțiunile implicite.

Blocul http din fișierul nginx.conf se termină astfel:

includ /etc/nginx/conf.d/*.conf;
includ /etc/nginx/sites-enabled/*;

Aceasta înseamnă că blocurile de server și locație, care definesc setările pentru anumite site-uri și adrese URL, vor fi stocate în afara acestui fișier.

Acest lucru permite o arhitectură de configurare modulară în care pot fi create noi fișiere pentru a servi site-uri noi. De asemenea, vă permite să grupați fișiere similare.

Închideți fișierul nginx.conf. Acum trebuie să studiați setările site-urilor individuale.

Blocuri virtuale Nginx

Blocurile de server din Nginx sunt analoge cu gazdele virtuale Apache (dar pentru comoditate, ele sunt numite și gazde virtuale). În esență, blocurile de server sunt specificații site-uri web separate găzduite pe același server.

În directorul site-uri disponibile puteți găsi fișierul implicit de blocare a serverului care vine cu serverul. Acest fisier contine toate datele necesare intretinerii site-ului.

site-uri cd-disponibile
sudo nano implicit

root /usr/share/nginx/www;
index index.html index.htm;
nume_server gazdă locală;
Locație/(

}
locație /doc/ (

alias /usr/share/doc/;
autoindex activat;
permite 127.0.0.1;
nega totul;

Fișierul implicit este foarte bine comentat, dar în exemplul de mai sus comentariile sunt omise pentru simplitate și comoditate.

Blocul server include toate setările plasate între acolade:

Server(
. . .
}

Acest bloc este plasat în fișierul nginx.conf aproape de sfârșitul blocului http folosind directiva include.

Directiva rădăcină specifică directorul în care va fi stocat conținutul site-ului. Nginx va căuta în acest director fișierele solicitate de utilizator. În mod implicit, acesta este /usr/share/nginx/www.

Vă rugăm să rețineți: toate liniile se termină cu punct și virgulă. Acesta este modul în care Nginx separă o directivă de alta. Dacă nu există punct și virgulă, Nginx va citi cele două directive (sau mai multe directive) ca o singură directivă cu argumente suplimentare.

Directiva index specifică fișierele care vor fi folosite ca index. Serverul web va verifica fișierele în ordinea în care sunt listate. Dacă nu a fost solicitată nicio pagină, blocul serverului va găsi și va returna fișierul index.html. Dacă nu poate găsi acel fișier, va încerca să proceseze index.htm.

directiva nume_server

Directiva server_name conține o listă de nume de domenii care vor fi servite de acest bloc de server. Numărul de domenii este nelimitat; Domeniile din listă trebuie separate prin spații.

Un asterisc (*) la începutul sau la sfârșitul unui domeniu specifică un nume cu o mască, unde asteriscul se potrivește cu o parte (sau mai multe părți) din nume. De exemplu, numele *.example.com se potrivește cu numele forum.example.com și www.animals.example.com.

Dacă adresa URL solicitată se potrivește cu mai multe directive server_name, va răspunde mai întâi cu cea care se potrivește exact.

Dacă adresa nu găsește o potrivire, va căuta cel mai mult nume lung cu o mască care se termină cu un asterisc. Dacă nu găsește un astfel de nume, va returna prima potrivire a expresiei regulate.

Numele de server care folosesc expresii regulate încep cu un tilde (~). Din pacate, Acest subiect depășește domeniul de aplicare al acestui articol.

Blocuri de locație

Locația/linia indică faptul că directivele din paranteze se vor aplica tuturor resurselor solicitate care nu se potrivesc cu niciun alt bloc de locație.

Astfel de blocuri pot conține o cale uri (de exemplu /doc/). Pentru a stabili o potrivire completă între locație și uri, se folosește simbolul =. Caracterul ~ se potrivește cu expresiile regulate.

Un tilde activează modul diferențiat între majuscule și minuscule, în timp ce un tilde cu un asterisc activează modul care nu ține seama de majuscule.

Dacă cererea se potrivește pe deplin cu blocul de locație, atunci serverul oprește căutarea și folosește un astfel de bloc. Dacă serverul nu găsește un bloc de locație care se potrivește complet, compară URI-ul cu parametrii directivelor de locație. Nginx va selecta un bloc care folosește combinația de caractere ^~ și care se potrivește cu URI.

Dacă opțiunea ^~ nu este utilizată, Nginx va selecta cea mai apropiată potrivire și va efectua o căutare a expresiei regulate pentru a încerca să se potrivească cu unul dintre modelele disponibile. Dacă găsește o astfel de expresie, o folosește. Dacă nu există o astfel de expresie, atunci serverul utilizează potrivirea URI găsită anterior.

Ca o notă finală, Nginx preferă potrivirile exacte. Dacă nu există astfel de potriviri, caută o expresie regulată și apoi caută URI. Pentru a schimba prioritatea de căutare a unui URI, utilizați combinația de caractere ^~.

directiva try_files

Directiva try_files este foarte unealtă folositoare, care verifică fișierele într-o anumită ordine și utilizează primul fișier găsit pentru a procesa cererea.

Acest lucru vă permite să utilizați parametri suplimentari determina modul în care Nginx va servi cererile.

Fișierul de configurare implicit are linia:

try_files $uri $uri/ /index.html;

Aceasta înseamnă că atunci când se primește o solicitare care este servită de un bloc de locație, Nginx va încerca mai întâi să servească uri ca fișier (acest comportament este specificat de variabila $uri).

Dacă serverul nu găsește o potrivire pentru variabila $uri, va încerca să folosească uri ca director.

Folosind o bară oblică finală, serverul verifică existența unui director, de exemplu $uri/.

Dacă nu este găsit niciun fișier sau director, Nginx execută fișierul implicit (în acest caz index.html în directorul rădăcină al blocului server). Fiecare directivă try_files folosește ultimul parametru ca alternativă, deci fișierul trebuie să existe în sistem.

În cazul în care serverul web nu găsește o potrivire în parametrii anteriori, poate returna o pagină de eroare. Pentru a face acest lucru, utilizați semnul egal și codul de eroare.

De exemplu, dacă locația/blocul nu poate găsi resursa solicitată, ar putea returna o eroare 404 în loc de un fișier index.html:

try_files $uri $uri/ =404;

Pentru a face acest lucru, trebuie să puneți un semn egal și să setați codul de eroare ca ultimul parametru (=404).

Opțiuni suplimentare

Directiva alias permite Nginx să servească pagini de blocare a locației în afara unui director dat (de exemplu, în afara rădăcină).

De exemplu, fișierele solicitate din /doc/ vor fi difuzate din /usr/share/doc/.

Directiva autoindex on vă permite să activați listarea directoarelor Nginx pentru o anumită directivă de locație.

Liniile de autorizare și refuzare controlează accesul la directoare.

Concluzie

Serverul web Nginx este bogat în funcții și foarte puternic, dar terminologia și opțiunile sale pot fi confuze.

Odată ce înțelegeți configurațiile Nginx și învățați cum să lucrați cu ele, veți beneficia de toate beneficiile acestui instrument puternic și ușor.

Etichete: ,