Nginx este un server web și un server proxy de e-mail care este disponibil public din 2004. Dezvoltarea proiectului a început în 2002, în limba rusă numele sună ca engin-ex. Crearea mâinilor celebrului programator Igor Sysoev, Nginx a fost inițial destinată lui 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 platforma Microsoft Windows, Nginx a început să lucreze cu apariția versiunii de ansamblu binar 0.7.52.

Statisticile pentru martie 2011 arată 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 difuza conținut static generat de o aplicație web „incomodă” care rulează sub alt server web.
Dar înainte de a pătrunde în jungla caracteristicilor funcționale ale lui Nginx - este 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 de o pagină HTML, flux media, imagine, fișier și alte date. Un server web este înțeles ca atât software care îndeplinește funcții de server web, cât și hardware. Schimbul de date și informații solicitate se realizează prin protocolul HTTP.

Lista de funcții suplimentare ale serverelor web include: autorizarea și autentificarea utilizatorilor, înregistrarea apelurilor acestora către resurse, suport HTTPS pentru comutarea securizată cu clienții și altele. Cel mai frecvent folosit server web în sistemele de operare asemănătoare Unix este Apache. A treia linie din lista de preferințe ale clienților este ocupată în prezent de Nginx.

Server proxy permite clienților să interogheze serviciile online în mod 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 poate păstra anonimatul și poate proteja computerul de atacurile de rețea. Serverul proxy emite datele solicitate către client fie din propriul cache (dacă există), fie le primește de la serverul specificat. În unele cazuri (pentru a atinge obiectivele de mai sus), răspunsul serverului, precum solicitarea clientului, poate fi schimbat de serverul proxy.

Cel mai simplu server proxy este considerat a fi Network Address Translator sau NAT. În 2000, proxy NAT a fost integrat în distribuția 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 în rețea își ascund adresele IP...

Gama funcțională a lui Nginx:

• Serviciu de server pentru fișiere index, interogări statice, generare de descriptori pentru cache deschis, listă de fișiere;
• proxy accelerat, distribuție elementară a sarcinii, toleranță la erori;
• suport pentru stocarea în cache în timpul proxy-ului accelerat și FastCGI;
• suport pentru FastCGI (accelerat) și servere memcache;
• modularitate, filtre, inclusiv „reluare” (interval de octeți) și compresie (gzip);
• Autentificare HTTP, răspunsuri fragmentate, filtru SSI;
• executarea paralelă a mai multor subcereri pe pagină procesate prin FastCGI sau 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 folosind un server de autentificare extern (HTTP).

Pentru cei care nu sunt familiarizați cu această terminologie, descrierea funcționalității lui Nginx poate părea destul de vagă. Dar când vine vorba de modalități de utilizare concretă a acestui server web - va începe să se estompeze încetul cu încetul.

Arhitectură și configurație

Procesele de lucru Nginx servesc mai multe conexiuni simultan, oferindu-le OS (sistem de operare) apeluri epoll (Linux), select și kqueue (FreeBSD). Datele primite de la client sunt analizate prin intermediul unei mașini de stări. Cererea analizată este gestionată de lanțul de module specificat de configurare. Formarea unui răspuns către client are loc în buffere, care pot indica o secțiune a unui fișier sau pot stoca date în memorie. Secvența transmiterii datelor 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ă pot fi atribuite porturi și adrese pentru a primi conexiuni. Locația poate fi specificată cu un URI exact, o parte a unui URI sau o expresie regulată. Pentru gestionarea rapidă a memoriei, pool-urile sunt o secvență de blocuri de memorie preselectate. Un bloc alocat inițial pentru pool are o lungime de la 1 la 16 kiloocteți. Este împărțit în zone - ocupate și neocupate. Pe măsură ce acesta din urmă este umplut, selectarea unui nou obiect este asigurată de formarea unui nou bloc.

Clasificarea geografică a clienților după adresa lor IP se realizează în Nginx folosind un 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 un server HTTP foarte rapid. În loc de sau împreună cu Apache, Nginx este folosit pentru a accelera procesarea cererilor și pentru a reduce sarcina pe server. Faptul este că vastele capabilități oferite de arhitectura modulară Apache nu sunt cerute de majoritatea utilizatorilor. Plata pentru această funcționalitate nerevendicată este o risipă semnificativă de resurse de sistem. Pentru site-urile obișnuite, de regulă, există o dominantă clară a fișierelor statice (imagini, fișiere de stil, JavaScript) și nu a scripturilor. Nu este necesară nicio funcționalitate specială pentru a transfera aceste fișiere către vizitatorul resursei, 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 plină de imagini sau fișiere pentru descărcare, Nginx poate fi configurat pe un port sau IP separat și poate servi conținut static prin intermediul acestuia. Pentru a face acest lucru, totuși, trebuie să modificați puțin cu schimbarea link-urilor de pe site. Cu 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. Nginx gestionează cererile de fișiere statice (cum ar fi o imagine, un fișier HTML simplu, JavaScript sau CSS) pe cont propriu. Dacă utilizatorul contactează un anumit script, el trimite cererea către departamentul Apache. Nu trebuie să faceți transformări cu codul site-ului.

Dacă canalul de la server la vizitator și invers este lent, această utilizare a Nginx poate da un efect suplimentar. Solicitarea primită de la vizitator este transmisă către Nginx pentru procesare de către Apache. După procesarea cererii, Apache direcționează pagina Nginx și încheie conexiunea cu un sentiment de realizare. Nginx poate trimite acum o pagină unui utilizator atâta timp cât este necesar, practic fără a consuma resurse de sistem. Apache care rulează în locul său ar fi însoțit de o încărcare nerezonabilă a memoriei atunci când era aproape inactiv. Apropo, acest caz de utilizare pentru Nginx are un 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 în rețea. Puteți afla mai multe despre Nginx pe site-ul web al dezvoltatorului său Igor Sysoev.

Un server web dedicat bazat pe nginx este o modalitate excelentă de a îmbunătăți performanța site-urilor dvs. web. În viteza de procesare a conținutului static, pur și simplu nu are egal: rezistă cu ușurință la câteva mii de conexiuni simultane și poate fi ușor optimizat și ajustat pentru orice configurație. Dar? Ca front-end pentru Apache, nginx se dovedește a fi cel mai vulnerabil punct al întregii infrastructuri Web, prin urmare, trebuie acordată o atenție deosebită securității nginx.

Acest articol este un fel de program educațional sau, dacă doriți, un rezumat al tuturor tehnicilor de creștere a securității nginx. Nu va exista nicio teorie, nicio descriere a elementelor de bază ale instalării unui server web sau orice altceva. În schimb, veți primi un material cuprinzător, practic, care prezintă toți pașii de bază pe care trebuie să-i faceți pentru a obține un server Web cu adevărat sigur.

Instalare

Pachetul nginx este disponibil precompilat pentru orice distribuție. Cu toate acestea, construind singur serverul, îl puteți face mai compact și mai fiabil și, de asemenea, puteți modifica linia de întâmpinare a serverului web pentru a descuraja copiii neinteligenti.

Schimbați linia de bun venit a serverului web

Descărcați sursele nginx, deschideți fișierul src / http / ngx_http_header_filter_module.c și găsiți următoarele două rânduri:

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

Înlocuiește-le cu ceva de genul acesta:

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

Eliminați toate modulele nginx pe care nu le utilizați

Unele module nginx se conectează la serverul web chiar în timpul compilării și oricare dintre ele este potențial periculos. Poate că, în viitor, la unul dintre ele se va găsi o vulnerabilitate, iar serverul tău va fi în pericol. Prin dezactivarea modulelor inutile, puteți reduce semnificativ riscul unei astfel de situații.

Construiți cu următoarele comenzi:

# ./configure --without-http_autoindex_module --without-http_ssi_module
# face
# face instalarea

Acest lucru vă va oferi nginx cu modulele SSI (Server Side Includes) și Autoindex dezactivate (și în cele mai multe cazuri inutile). Pentru a afla ce module pot fi aruncate în siguranță din serverul web, rulați scriptul de configurare cu steag-ul „-help”.

Disecare nginx.conf

După instalare, nginx ar trebui configurat. Pe paginile revistei exista deja material care descrie acest proces, dar vom rămâne la subiectul articolului și vom vorbi despre modalități de îmbunătățire a securității serverului.

Dezactivați afișarea versiunii serverului pe toate paginile de eroare

Adăugați linia „server_tokens off” în fișierul nginx.conf. Acest lucru va face ca nginx să ascundă tipul și versiunea serverului web pe paginile generate ca răspuns la o solicitare eronată a clientului.

Configurați protecția împotriva ruperii stivei

Adăugați următoarele linii la secțiunea server:

# vi /etc/nginx/nginx.conf

# Dimensiunea maximă a memoriei tampon pentru stocarea corpului solicitării clientului
client_body_buffer_size 1K;
# Dimensiunea maximă a memoriei tampon pentru stocarea antetelor cererilor clientului
client_header_buffer_size 1k;
# Dimensiunea maximă a corpului cererii clientului, așa cum este specificat în câmpul Content-Length din antet. Dacă serverul trebuie să accepte încărcări de fișiere, această valoare trebuie mărită
client_max_body_size 1k;
# Numărul și dimensiunea bufferelor pentru citirea antetului de solicitare mare a clientului
large_client_header_buffers 2 1k;

Acordați atenție directivei large_client_header_buffers. În mod implicit, nginx alocă patru buffere pentru a stoca șirul URI, fiecare dintre acestea fiind egal cu dimensiunea unei pagini de memorie (pentru x86, aceasta este de 4 KB). Bufferele sunt eliberate de fiecare dată când conexiunea intră în starea de menținere în viață după procesarea cererii. Două buffer-uri de 1 KB pot stoca doar URI-uri de 2 KB, ceea ce vă permite să luptați împotriva roboților și a atacurilor DoS.

Adăugați următoarele linii pentru a îmbunătăți performanța:

# vi /etc/nginx/nginx.conf

# Timeout în timp ce citiți corpul solicitării clientului
client_body_timeout 10;
# Timeout la citirea antetului solicitării clientului
client_header_timeout 10;
# Timeout după care conexiunea keep-alive cu clientul nu va fi închisă de către server
keepalive_timeout 5 5;
# Timeout la trimiterea unui răspuns către client
send_timeout 10;

Controlați numărul de conexiuni simultane

Pentru a proteja serverul web de supraîncărcare și încercări DoS, adăugați următoarele linii la config:

# vi /etc/nginx/nginx.conf

# Descrieți zona (limită) în care vor fi stocate stările sesiunii. O zonă de 1 MB poate stoca aproximativ 32000 de stări, noi o setăm la 5 MB
limit_zone slimits $ binary_remote_addr 5m;
# Setați numărul maxim de conexiuni simultane pentru o sesiune. De fapt, acest număr setează numărul maxim de conexiuni de la un IP
limit_conn slimits 5;

Prima directivă ar trebui să fie în secțiunea HTTP, a doua în secțiunea locație. Când numărul de conexiuni depășește limitele, clientul va primi un mesaj „Service indisponibil” cu un cod 503.

Permite conexiuni numai la propriul domeniu

Hackerii pot folosi boți pentru a scana subrețele și pentru a găsi servere Web vulnerabile. De obicei, roboții trec pur și simplu prin intervalele IP căutând 80 de porturi deschise și trimit o solicitare HEAD pentru a obține informații despre serverul web (sau pagina de pornire). Puteți preveni cu ușurință o astfel de scanare prin interzicerea accesului la server prin adresa IP (adăugați la subsecțiunea locație):

# vi /etc/nginx/nginx.conf

dacă ($ gazdă! ~ ^ (gazdă.com | www.gazdă.com) $) (
întoarcere 444;
}

Limitați numărul de metode disponibile pentru accesarea serverului web

Unii roboți folosesc diferite metode pentru a contacta serverul pentru a încerca să-i determine tipul și/sau penetrarea, dar RFC 2616 clarifică faptul că serverul web nu trebuie să le implementeze pe toate, iar metodele neacceptate pot pur și simplu să nu fie procesate. Astăzi, doar metodele GET (cerere de document), HEAD (cerere antet server) și POST (cerere de publicare a documentului) rămân în uz, astfel încât toate celelalte pot fi dezactivate fără durere prin plasarea următoarelor linii în secțiunea server a fișierului de configurare:

# vi /etc/nginx/nginx.conf

dacă ($ request_method! ~ ^ (GET | HEAD | POST) $) (
întoarcere 444;
}

Chuck bots

O altă modalitate de a bloca roboții, scanerele și alte spirite rele se bazează pe determinarea tipului de client (user-agent). Nu este foarte eficient, deoarece majoritatea roboților imită browsere complet legitime, dar în unele cazuri rămâne util:

# vi /etc/nginx/nginx.conf

# Blocați managerii de descărcare
if ($ http_user_agent ~ * LWP :: Simplu | BBBike | wget) (
întoarce 403;
}
# Blocați unele tipuri de roboți
dacă ($ http_user_agent ~ * msnbot | scrapbot) (
întoarce 403;
}

Blocați spamul referitor

Dacă site-ul dvs. publică jurnalele web în domeniul public, puteți deveni cu ușurință o victimă a spam-ului referitor (când roboții de spam vă contactează serverul, specificând adresa site-ului anunțat în antetul referitor). Acest tip de spam poate strica cu ușurință clasamentele SEO ale unei pagini web, așa că este imperativ să o blocați. O modalitate de a face acest lucru este să puneți pe lista neagră cele mai comune cuvinte găsite în adresele URL ale site-urilor promovate.

# vi /etc/nginx/nginx.conf

# Secțiunea Server
dacă ($ http_referer ~ * (babe | vanzare | fată | bijuterii | dragoste | nud | organic | poker | porno | sex | adolescent))
{
întoarce 403;
}

Blocați legătura rapidă

Hotlink este includerea unei imagini (sau a unui alt conținut) dintr-un alt site într-o pagină. De fapt, acesta este un furt, deoarece imaginea pe care ați petrecut mai mult de o oră din timpul liber nu este doar folosită în mod liber de către alții, ci creează și o încărcare pe serverul dvs. Web fără a aduce vizitatori la acesta. Pentru a combate hotlink-urile, este suficient să vă asigurați că imaginile sunt date clientului doar dacă acesta le-a solicitat deja pe site (cu alte cuvinte, antetul cererii de referință trebuie să conțină numele site-ului dvs.). Adăugați următoarele rânduri la secțiunea server a fișierului de configurare nginx.conf (host.com este adresa site-ului dvs.):

# vi /etc/nginx/nginx.conf

locație / imagini / (
valid_referers nici unul blocat www.host.com host.com;
dacă ($ invalid_referer) (
întoarce 403;
}
}

Alternativ, puteți configura serverul să difuzeze un mesaj special de furt în locul imaginii solicitate. Pentru a face acest lucru, înlocuiți linia „return 403” cu linia:

rescrie ^ / imagini / încărcări. * \. (gif | jpg | jpeg | png) $ http://www.host.com/banned.jpg ultimul

Protejați directoarele importante de străini

La fel ca orice alt server Web, nginx vă permite să reglați accesul la director pe baza adreselor IP și a parolelor. Această caracteristică poate fi folosită pentru a închide unele părți ale site-ului de la privirile indiscrete. De exemplu, pentru a elimina un URI din lumea exterioară:

# vi /etc/nginx/nginx.conf

locație / încărcări / (
# Permite accesul numai la mașinile din rețeaua locală
permite 192.168.1.0/24;
# Cusutul pe toți ceilalți
nega totul;
}

Acum doar utilizatorii rețelei locale vor avea acces la documentele directorului de încărcări. Pentru a seta o parolă, va trebui să faceți pași mai complexi. Mai întâi, trebuie să creați un fișier cu parolă privată pentru nginx și să adăugați utilizatorii necesari la acesta (de exemplu, să adăugăm utilizatorul admin):

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

# vi /etc/nginx/nginx.conf

locație / admin / (
auth_basic „Restricționat”;
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

Utilizatori noi pot fi adăugați folosind următoarea comandă:

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

Utilizați SSL

Dacă site-ul dvs. funcționează cu date private ale utilizatorilor, cum ar fi numere de card de credit, parole de la alte servicii sau oferă acces la alte informații importante care pot deveni o informație pentru terți, aveți grijă de criptare. Nginx funcționează bine cu SSL și nu trebuie trecut cu vederea.

Pentru a configura criptarea SSL folosind nginx, trebuie doar să urmați câțiva pași simpli. Mai întâi, trebuie să creați un certificat utilizând următoarea secvență de comenzi:

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

Apoi descrieți certificatul în fișierul de configurare nginx:

# vi /etc/nginx/nginx.conf

Server (
nume_server gazdă.com;
asculta 443;
ssl activat;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

După aceea, puteți reporni serverul web:

# /etc/init.d/nginx reîncărcare

Desigur, fără sprijinul site-ului web în sine, nu are sens să faci asta.

alte metode

Setați valorile corecte pentru variabilele de sistem

Deschideți fișierul /etc/sysctl.conf și puneți următoarele linii în el:

# vi /etc/sysctl.conf

# Protecție împotriva atacurilor ștrumfilor
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Protecție împotriva mesajelor ICMP incorecte
net.ipv4.icmp_ignore_bogus_error_responses = 1
# SYN protecție împotriva inundațiilor
net.ipv4.tcp_syncookies = 1
# Dezactivează rutarea sursei
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Protecție împotriva falsificării
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Nu suntem un router
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Activați ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Extindeți gama de porturi disponibile
net.ipv4.ip_local_port_range = 2000 65000
# Măriți dimensiunea maximă a bufferelor TCP
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

Plasați directorul rădăcină al serverului web pe o partiție dedicată

Prin plasarea directorului rădăcină al serverului Web pe o partiție dedicată și interzicerea oricăror fișiere executabile sau dispozitiv de pe acesta, puteți proteja restul sistemului de oricine poate accesa rădăcina serverului Web. În acest caz, intrarea din fișierul / etc / fstab ar trebui să arate cam așa:

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

Puneți nginx în mediul chroot / jail

Orice sistem * nix modern vă permite să blocați o aplicație într-un mediu de execuție izolat. Pe Linux, puteți folosi tehnologiile KVM, Xen, OpenVZ și VServer pentru asta, pe FreeBSD - Jail, pe Solaris - Zones. Dacă niciuna dintre aceste tehnologii nu este disponibilă, puteți pune nginx într-un chroot clasic, care, deși mult mai fragil, poate fi oprit de majoritatea crackerilor.

Configurați regulile SELinux pentru a proteja nginx

Sistemele locale de detectare și prevenire a intruziunilor, cum ar fi SELinux sau AppArmor, sunt alternative bune la timpii de execuție în sandbox. Când sunt configurate corect, acestea pot preveni încercările de a compromite serverul Web. În mod implicit, niciunul dintre ele nu este configurat să funcționeze împreună cu nginx, ci în cadrul proiectului SELinuxNginx(http://sf.net/projects/selinuxnginx/) au fost create reguli pentru SELinux pe care oricine le poate folosi. Tot ce rămâne este să descărcați și să instalați:

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

Configurați un firewall

În mod obișnuit, nginx este instalat pe mașini dedicate care sunt gata pentru sarcini grele de lucru, așa că rămâne adesea singurul serviciu de rețea care rulează pe server. Pentru a securiza serverul, este suficient să creați un set foarte mic de reguli care să deschidă porturile 80, 110 și 143 (dacă, desigur, nginx ar trebui să funcționeze și ca un proxy IMAP / POP3) și să închidă orice altceva din lumea exterioară .

Limitați numărul de conexiuni cu un firewall

Pentru un site Web ușor, este o idee bună să limitați numărul de încercări de conectare de la o adresă IP pe minut. Acest lucru vă poate salva de anumite tipuri de atacuri DoS și atacuri de forță brută. Pe Linux, acest lucru se poate face folosind modulul standard iptables / netfilter state:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m stare --state NOU -m recent --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m stare --state NOU -m recent --actualizare \
--seconds 60 --hitcount 15 -j DROP

Regulile reduc limita numărului de conexiuni de la un IP pe minut la 15. Același lucru se poate face folosind pf:

# vi /etc/pf.conf

webserver_ip = "1.1.1.1"
masa persista
blocați rapid din
transmiteți $ ext_if proto tcp la $ webserver_ip \
port www steaguri S / SA păstrează starea \
(max-src-conn 100, max-src-conn-rate 15/60, \
suprasarcina culoare)

Pe lângă limita privind numărul de conexiuni consecutive (15 pe minut), această regulă stabilește o limită suplimentară pentru numărul de conexiuni simultane egală cu 100.

Configurare PHP

Dacă utilizați nginx împreună cu PHP, nu uitați să îl configurați și pe acesta. Iată cum ar trebui să arate fișierul de configurare a serverului securizat /etc/php/php.ini:

# vi /etc/php/php.ini

# Dezactivează funcțiile periculoase
disable_functions = phpinfo, system, mail, exec
# Timp maxim de execuție a scriptului
max_execution_time = 30
# Timpul maxim pe care un script îl poate petrece procesând datele cererii
max_input_time = 60
# Cantitatea maximă de memorie alocată fiecărui script
limita_memorie = 8M
# Dimensiunea maximă a datelor trimise către script folosind metoda POST
dimensiune_max_post = 8M
# Dimensiunea maximă a fișierelor încărcate
upload_max_filesize = 2M
# Nu afișați utilizatorilor erori de script PHP
display_errors = Dezactivat
# Activați modul sigur
safe_mode = Activat
# Activați modul sigur SQL
sql.safe_mode = Activat
# Permite executarea comenzilor externe numai în acest director
safe_mode_exec_dir = / calea / către / protected / director
# Protejarea împotriva scurgerilor de informații PHP
expose_php = Dezactivat
# Păstrarea jurnalelor
log_errors = Activat
# Interziceți deschiderea fișierelor de la distanță
allow_url_fopen = Dezactivat

concluzii

Aplicând instrucțiunile prezentate în acest articol, veți avea un server Web mult mai sigur. Dar rețineți că nu toate tehnicile se vor potrivi configurației dvs. De exemplu, protecția brute bazată pe reducerea dimensiunii buffer-urilor alocate de nginx pentru procesarea cererilor clienților poate duce la degradarea performanței și, în unele cazuri, la eșecuri în procesarea cererilor. Limitarea numărului de conexiuni va avea un impact major asupra performanței chiar și a unui site Web încărcat moderat, dar va fi benefică dacă pagina are un flux redus de vizitatori. Verificați întotdeauna modul în care modificările efectuate au afectat performanța și sănătatea generală a paginii dvs. Web.

Despre eroul zilei

Nginx este unul dintre cele mai puternice și populare servere web din lume. Potrivit Netcraft, este folosit pentru a alimenta peste 12 milioane de site-uri web din întreaga lume, inclusiv Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusek și Taba.ru. O arhitectură competentă bazată pe multiplexarea conexiunilor utilizând apelurile de sistem select, epoll (Linux), kqueue (FreeBSD) și un mecanism de gestionare a memoriei bazat pe pool-uri (buffer-uri mici de la 1 la 16 KB), permite nginx să nu se lade chiar și la sarcini foarte mari. , rezistând peste 10.000 de conexiuni concurente (așa-numita problemă C10K). Scris inițial de Igor Sysoev pentru Rambler și deschis în 2004 sub o licență asemănătoare BSD.

In contact cu

Nginx? Scopul, caracteristicile, opțiunile de personalizare sunt lucruri cu care fiecare dezvoltator web ar trebui să fie familiarizat pentru a-și testa cele mai bune practici.

Să spunem un cuvânt despre nginx

Acest instrument are un flux de lucru principal și mai multe. Prima se ocupă de citirea și verificarea configurației. De asemenea, controlează managementul proceselor de lucru. Sarcina acestuia din urmă este să proceseze cererile primite. Nginx folosește un model bazat pe evenimente. De asemenea, utilizează mecanisme dependente de sistemul de operare pentru a realiza o distribuție eficientă a cererilor direct între procesele de lucru. Numărul lor este întotdeauna indicat în fișierul de configurare. Valoarea poate fi fie fixată, fie setată automat, fiind ghidată de numărul de nuclee de procesor cu care puteți lucra. În nginx, sistemul și modulele sunt configurate folosind un fișier de configurare. Prin urmare, dacă este necesar să schimbați ceva, atunci este necesar să îl căutați. Se găsește de obicei în directiva / etc / nginx (dar calea se poate schimba când se utilizează alte sisteme) și are extensia .conf.

Pornire, repornire și jurnalele

Pentru a face acest lucru, trebuie să faceți executabilul să funcționeze. Serverul nginx poate fi configurat numai când rulează. Controlul se realizează prin apelarea fișierului executabil cu parametrul -s. Pentru a face acest lucru, utilizați următoarea intrare:

semnal nginx -s

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

1. Stop. Folosit pentru oprire rapidă.
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 furnizate acolo. Dacă nu reușește, va anula modificările și va funcționa cu vechii parametri. Dacă totul a mers bine, atunci vor fi lansate noi procese de lucru, iar celor vechi vor fi trimise o solicitare pentru finalizare.
3. Părăsi. Folosit pentru oprire lină. Este utilizat dacă este necesar să așteptați până când cererile curente sunt finalizate de a fi deservite.
4. Redeschide. Închideți și deschideți fișierele jurnal.

Folosind utilitare

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 unui proces direct cu date. Acestea sunt conectate folosind ID. Aceste date sunt stocate în fișierul nginx.pid. Să spunem că ne interesează procesul #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. Acestea sunt configurate folosind directivele care sunt specificate în fișierul de configurare. Sunt simple și blocate. Primul tip de directivă constă dintr-un nume și parametri, care sunt separați prin spații, iar sfârșitul lor este indicat prin punct și virgulă - (;). Blocul are o structură similară. Dar în această directivă, în loc de un final, este plasat un set de instrucțiuni suplimentare, care sunt așezate între acolade ((instrucțiuni)). Dacă în ele pot fi plasați nume și parametri ai 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. Servirea de conținut statistic înseamnă imagini și pagini HTML (nu dinamice). Să presupunem că avem nevoie de o lucrare unică pentru configurarea unui cluster nix nginx. Este greu să o faci? Nu, și să ne uităm la un exemplu. Înainte de a continua cu aceasta, este necesar să detaliați condițiile problemei. 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. Configurarea optimă a nginx în acest caz necesită editarea fișierului de configurare, în care este necesară configurarea blocului de server în interiorul http. Două locații vor fi folosite și pentru sprijin.

Implementare: server

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

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

Implementare: locatie

Definit în interiorul serverului:

Prezența semnului „/” este necesară pentru a compara datele primite și pentru a vedea dacă există o astfel de adresă din cererea procesată aici. Dacă nu există probleme, atunci indicăm calea / date / www către fișierul necesar care se află pe acest 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 / (

După cum vă puteți da seama, căutăm imagini. Acum să combinăm toate evoluțiile care au fost mai devreme, iar configurația în acest moment arată astfel:

locație / imagini / (

Aceasta este o versiune de lucru, care se întâmplă să fie standard.Acest server poate fi accesat cu ușurință pe computerul local dacă accesați adresa: http: // localhost /. Cum vor funcționa toate acestea?

Cum funcționează exemplul

Deci, atunci când vin solicitări care încep cu / imagini, 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 computerul local, atunci la solicitarea 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 am schimbat doar 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. Dacă funcționarea normală nu este posibilă, atunci în fișierele error.log și access.log situate în directiva / usr / local / nginx / logs, puteți căuta cauza defecțiunii.

Crearea unui server proxy simplu

În ceea ce privește nginx, configurarea acestui obiect este una dintre cele mai comune utilizări (și destul de ușoară, de altfel). Folosește principiul unui server care acceptă o solicitare și apoi le redirecționează către site-urile necesare. După aceea, se așteaptă un răspuns de la ei, care îi direcționează către cel care a stabilit sarcina. Deci, să ne uităm la un exemplu de creare a unui punct de bază. Acesta va servi cererile utilizatorilor și le va oferi imagini din directorul local. Deci, adăugați un alt server la blocul http cu următorul conținut:

Acum să descifrăm pentru tine: se creează un server simplu. Va asculta Nu specificați ascultare, atunci serverul va funcționa pe 80th. Toate cererile din sistemul de fișiere local care sunt direcționate către directorul / data / up1 vor fi afișate (desigur, va trebui creat înainte de asta). Pentru a putea verifica, trebuie să plasați fișierul index.html acolo. Prin plasarea directivei rădăcină în contextul serverului, vom putea 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 obiectului vor fi specificate ca parametri (cu o conexiune locală, va arăta ca http: // localhost: 8080). Obtii urmatorul rezultat:

proxy_pass http: // localhost: 8080;

locație / imagini / (

Dacă te uiți la cod și îl analizezi, vei observa că al doilea bloc de locație a fost schimbat. Deci, în acest caz, poate funcționa cu extensii tipice de imagine. Puțin diferit, ar putea fi afișat în acest fel:

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

rădăcină / date / imagini;

Configurația finală a proxy-ului arată astfel:

proxy_pass http: // localhost: 8080 /;

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

rădăcină / date / imagini;

Va filtra cererile care au extensiile specificate la sfârșit și le va trimite celui 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 al serverului Vkontakte sau al unei alte companii mari, acestea vor avea mai mult cod decât cuvintele din acest articol.

Unul dintre cele mai populare servere web

Nginx este foarte popular printre utilizatorii de servere web și proxy datorită performanței sale. Serverul are multe avantaje, dar poate fi dificil de configurat pentru un începător. Vrem să vă ajutăm să aflați fișierele de configurare, sintaxa și setările de bază Nginx.

Ierarhia directoarelor

Toate fișierele de configurare a serverului se află în directorul / etc / nginx. În plus, există mai multe foldere în interiorul directorului, precum ș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-uri disponibile / win-utf
koi-utf naxsi_core.rules proxy_params site-uri activate /

Dacă ați folosit Apache, ar trebui să vă familiarizați cu directoarele cu site-uri activate și site-uri disponibile. Ele determină configurația site-urilor. Fișierele generate sunt stocate în ultimul director. Dosarul activat pentru site-uri este necesar pentru a stoca configurațiile numai ale paginilor activate. Pentru a le lega, aveți nevoie de o legătură simbolică între dosare. Configurațiile pot fi stocate și în directorul conf.d. În același timp, în timpul pornirii Nginx, fiecare fișier cu extensia .conf va fi citit din nou. Când scrieți fișierele de configurare, introduceți codul corect și urmați sintaxa. Toate celelalte fișiere sunt localizate în / etc / nginx. Configuratorul conține informații despre procese specifice, precum și despre componente suplimentare.

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

Citește toate fișierele de configurare, îmbinându-le într-unul singur, care este solicitat la pornirea serverului. Deschideți fișierul cu:

sudo nano /etc/nginx/nginx.conf

Următoarele linii vor apărea pe ecran:

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

Prima este o prezentare generală a Nginx. Expresia user www-data se referă la utilizatorul care pornește serverul. Directiva pid indică unde sunt localizate procesele interne PID. Linia worker_processes arată câte procese poate rula Nginx în același timp. În plus, puteți specifica aici jurnalele (de exemplu, jurnalul de erori este definit folosind directiva error_log). Mai jos este secțiunea evenimente. Este necesar pentru a gestiona conexiunile la server. După ce este blocul http.

Structura fișierului de configurare Nginx

Înțelegerea structurii de formatare a fișierelor vă va ajuta să înțelegeți mai bine configurația serverului dvs. web. Este împărțit în blocuri de construcție. Detaliile de configurare ale blocului http sunt stratificate folosind blocuri private. Ei moștenesc proprietăți de la părintele lor, adică cel în care se află. Acest bloc stochează majoritatea configurațiilor serverului. Ele sunt împărțite în blocuri de server, în interiorul cărora se află locația.

Când vă configurați serverul Nginx, rețineți că cu cât blocul de configurare este mai jos, cu atât mai puține elemente vor moșteni proprietăți și invers. Fișierul conține un număr mare de opțiuni care modifică funcționarea serverului. Puteți seta compresia fișierelor trimise către client, de exemplu. Pentru a face acest lucru, scrieți parametrii:

gzip on;
gzip_disable „msie6”;

Rețineți că același parametru poate lua valori diferite în blocuri diferite. Mai întâi, setați-l în partea de sus, apoi suprascrieți parametrul la nivelul necesar. Dacă ultima acțiune nu este efectuată, programul va seta valorile în modul automat.

Ultimele rânduri ale fișierului nginx.conf sunt:

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

Ele indică faptul că locația și blocurile de server sunt stocate în afara acestui fișier. Ei definesc setările pentru adrese URL și fișiere specifice. Această structură este necesară pentru a menține o structură de configurare modulară. În interiorul acestuia, veți putea crea noi directoare, fișiere pentru diverse site-uri. În plus, puteți grupa fișiere similare. După examinare, puteți închide fișierul nginx.conf.

Blocuri virtuale

Sunt analoge cu gazdele virtuale din Apache. Blocurile secțiunii server includ caracteristicile site-urilor individuale care se află pe server. În folderul site-available, veți găsi fișierul implicit de blocare a serverului. În interiorul acestuia, puteți găsi în exterior datele necesare care pot fi necesare la întreținerea site-urilor.

site-uri cd-disponibile
sudo nano implicit
Server (
root / usr / share / nginx / www;
index index.html index.htm;
nume_server gazdă locală;
Locație / (
try_files $ uri $ uri / /index.html;
}
locație / document / (
alias / usr / share / doc /;
autoindex activat;
permite 127.0.0.1;
nega totul;
}
}

În exemplul de mai sus, comentariul a fost eliminat în mod deliberat. Acest lucru a fost făcut pentru lizibilitate. În interiorul blocurilor serverului se află setările cuprinse între acolade:

Acest bloc este plasat folosind directiva include la sfârșitul http specificat în fișierul nginx.conf. Directiva rădăcină definește directorul în care va fi localizat conținutul site-ului. În acesta, programul va căuta fișiere pe care utilizatorul le va solicita. Calea implicită este / usr / share / nginx / www. Nginx separă liniile sau directivele unele de altele cu punct și virgulă. Dacă nu puneți semn de punctuație, mai multe rânduri vor fi citite ca unul singur. Pentru a scrie regulile care vor fi folosite ca index, utilizați directiva index. Serverul le va verifica în ordinea în care sunt listate. Dacă niciuna dintre paginile disponibile nu a fost solicitată de utilizator, va fi returnat index.html. Dacă nu este acolo, serverul va căuta index.htm.

Regula nume_server

Include o listă de nume de domenii care urmează să fie procesate de blocul serverului. Puteți scrie orice număr dintre ele, separându-le cu spații. Dacă puneți * la sfârșitul sau începutul unui domeniu, veți putea specifica un nume cu o mască. Asteriscul se potrivește cu o parte a numelui. Dacă vă înregistrați * .com.ua, atunci toate adresele zonei de domeniu specificate vor fi incluse aici. Dacă adresa se potrivește cu descrierea mai multor directive, atunci va răspunde cu cea care se potrivește complet. Dacă nu există nicio potrivire, răspunsul va fi cel mai lung nume care are o mască. În caz contrar, expresiile regulate vor fi potrivite. Numele de server care folosesc expresii regulate încep cu un tilde (~).

Blocuri de locație

Următorul în rând vom avea un bloc de locație. Este folosit pentru a determina modul în care sunt tratate anumite cereri. Dacă resursele nu corespund altor blocuri de locație, atunci li se vor aplica directivele specificate între paranteze. Aceste blocuri pot include o cale ca / ​​doc /. Pentru a stabili o corespondență completă între uri și locație, se folosește semnul =. Aplicarea tildei se va potrivi cu expresiile regulate. Puteți, de asemenea, să setați sensibilitatea majusculelor punând ~. Dacă adăugați un asterisc, cazul nu contează.

Rețineți: atunci când solicitarea se potrivește cu blocul de locație, aceasta va fi folosită și căutarea se va opri. Când potrivirea este incompletă, URI-ul va fi comparat cu parametrii directivelor de locație. Un bloc cu combinația ^ ~ este folosit pentru a potrivi URI-ul pentru selecția blocului. Dacă această opțiune nu este activată, serverul selectează cea mai bună potrivire și efectuează, de asemenea, o căutare cu expresii regulate. Acest lucru este necesar pentru a selecta unul dintre șabloanele potrivite. Dacă se găsește o expresie care se potrivește, aceasta va fi folosită. În caz contrar, potrivirea anterioară a URI va fi aplicată. Cu toate acestea, rețineți că lui Nginx îi plac mai mult meciurile complete. Dacă nu sunt acolo, va începe să caute expresii regulate și apoi după URI. Paritatea de căutare este specificată de combinația de caractere ^ ~.

Regula Try_files

Este un instrument foarte util care poate verifica fișierele într-o ordine specificată. Se aplică primele criterii de potrivire pentru a procesa cererea. Puteți utiliza parametrii avansați pentru a controla modul în care serverul va servi cererile. Configuratorul are o linie implicită ca aceasta:

try_files $ uri $ uri / /index.html;

Ce înseamnă? Dacă vine o solicitare care este servită de un bloc de locație, serverul va încerca mai întâi să proceseze uri-ul ca fișier. Aceasta este furnizată de variabila $ uri. Când nu există nicio potrivire, uri-ul va fi tratat ca un director. Îi puteți verifica existența adăugând o bară oblică la sfârșit: $ uri /. Există situații în care nici fișierul, nici directorul nu vor fi găsite. În acest caz, fișierul implicit index.html va fi încărcat. Regula try_files aplică ultimul parametru ca alternativă. De aceea, acest fișier trebuie să fie în sistem. Cu toate acestea, dacă nu se găsesc potriviri, Nginx va returna o pagină de eroare. Pentru a-l seta, scrieți = și codul de eroare:

Opțiuni suplimentare

Dacă aplicați regula alias, veți putea servi pagini în blocul de locații în afara directorului rădăcină, de exemplu. Când sunt necesare fișiere de la doc, acestea vor fi solicitate de la / usr / share / doc /. În plus, regula de autoindexare începe să listeze directoarele serverului pentru directiva de locație specificată. Dacă scrieți liniile deny și permiteți, veți putea schimba accesul la directoare.

Ca o concluzie, trebuie spus că Nginx este un instrument multifuncțional foarte puternic. Dar obținerea unei bune înțelegeri a modului în care funcționează va necesita timp și efort. Dacă înțelegeți cum funcționează configurațiile, vă puteți bucura pe deplin de toate caracteristicile programului.

Alte). Versiunea actuală, 0.6.x, este considerată stabilă pentru fiabilitate, în timp ce versiunile din ramura 0.7 sunt considerate instabile. Este important de reținut că funcționalitatea unor module se va modifica, drept urmare directivele se pot modifica și, astfel încât compatibilitatea inversă în nginx până la 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?

În primul rând, trebuie să explicați cum funcționează în general serverele 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, aceasta este departe de cea mai bună cale, mai ales când clientul lucrează de mult timp și există o mulțime de conexiuni. În plus, modelul secvenţial are mult mai multe dezavantaje (de exemplu, incapacitatea de a folosi mai multe procesoare), iar în condiţii reale practic nu este folosit.
2. Multiproces (multithreaded). Serverul deschide o priză de ascultare. Când sosește o conexiune, o acceptă, după care creează (sau preia din pool-ul celor create anterior) un nou proces sau fir care poate funcționa cu conexiunea atâta timp cât este necesar, iar la terminarea lucrării, ieșire sau retur la piscina. Între timp, firul principal este gata să accepte o nouă conexiune. Acesta este cel mai popular model deoarece este relativ ușor de implementat, permite calcule complexe și consumatoare de timp pentru fiecare client și utilizează toate procesoarele disponibile. Un exemplu de utilizare a acestuia este serverul web Apache. Cu toate acestea, această abordare are și dezavantaje: cu un număr mare de conexiuni concurente, 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 mai ales rău când clienții acceptă foarte încet conținutul. Rezultă sute de fire de execuție sau procese, ocupate doar să trimită date către clienții lenți, ceea ce creează o încărcare suplimentară pe planificatorul OS, crește numărul de întreruperi și consumă multă memorie.
3. Prize neblocante/Mașină de stat. Serverul funcționează într-un singur fir, dar folosește socket-uri neblocante și un mecanism de sondare. Acestea. serverul la fiecare iterație a unei bucle infinite îl selectează din toate prizele pe cel care este gata să primească/trimite date folosind apelul select (). După ce un socket este selectat, serverul îi trimite date sau îl citește, dar nu așteaptă confirmarea, ci intră în starea inițială și așteaptă un eveniment pe un alt socket, sau îl prelucrează pe următorul, în care evenimentul a avut loc în timpul prelucrarea celui precedent. Acest model folosește foarte eficient procesorul și memoria, dar este destul de dificil de implementat. În plus, în cadrul acestui model, procesarea unui eveniment pe un socket trebuie să fie foarte rapidă - în caz contrar, multe evenimente se vor acumula în coadă și în cele din urmă se vor deborda. Acesta este modul în care funcționează nginx. În plus, vă permite să începeți mai multe procese de lucru (numite lucrători), adică poate folosi mai multe procesoare.

Deci, imaginați-vă următoarea situație: 200 de clienți cu un canal de 256 Kbps sunt conectați la un server HTTP cu un canal de 1 Gbps:

Ce se întâmplă în cazul Apache? Se creează 200 de fire/procese care generează conținut relativ rapid (pot fi atât pagini dinamice, cât și fișiere statice citite de pe disc), dar încet-încet îl dau clienților. Sistemul de operare trebuie să se ocupe de o grămadă de fire și de blocări I/O.

Într-o astfel de situație, Nginx cheltuiește cu un ordin de mărime mai puține resurse de sistem de operare și memorie pentru fiecare conexiune. Cu toate acestea, acest lucru dezvăluie o limitare a modelului de rețea nginx: nu poate genera conținut dinamic în sine, deoarece acest lucru va duce la blocarea î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 pachetului 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 spre „procesare”. Din această cauză, aproape toți indicatorii de progres ai încărcărilor de fișiere se „rup” de obicei - cu toate acestea, 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 într-un fișier temporar. Între timp, Apache eliberează resurse. Mai mult, nginx trimite lent conținut către client, cheltuind în același timp ordin de mărime mai puține resurse decât Apache.

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

Instalare

pentru că 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, aceasta nu este o problemă, trebuie doar să citiți cu atenție rezultatul comenzii. / Configure --help și selectați opțiunile de compilare de care aveți nevoie, de exemplu:

./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
-Utilizator = nginx \ # nume de utilizator sub care va rula nginx
—With-http_ssl_module —with-http_gzip_static_module —with-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 modulele necesare

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

Alternativ, în Gentoo puteți utiliza ebuild-ul din arborele standard de porturi; în RHEL / CentOS depozitul epel (unde se află 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 redefinită în timpul compilării. Îmi place să îl pun în / etc / nginx /, la fel și dezvoltatorii tuturor pachetelor menționate mai sus.

Structura fișierului de configurare este următoarea:

utilizator nginx; # nume de utilizator sub care 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 (asta este ceea ce apache numește VirtualHost)
Server (
# adresa și numele serverului
asculta *: 80;
nume_server aaa.bbb;

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

# și așa puteți defini locația, 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 prin expresie regulată, astfel:
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 am examinat avantajele schemei frontend + backend, ne-am dat seama de instalarea, structura și sintaxa fișierului de configurare, luați în considerare acum cum să implementați proxy inversă în nginx.

E foarte simplu! De exemplu astfel:

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

În acest exemplu, toate solicitările către 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.

Există însă mai multe subtilități legate de faptul că aplicația va presupune că, în primul rând, toate solicitările îi vin de la aceeași adresă IP (care poate fi interpretată, de exemplu, ca o încercare de atac DDoS sau atac de forță brută). ), și în al doilea rând, luați în considerare că rulează pe gazda 1.2.3.4 și pe portul 8080 (generați redirecționări incorecte și, respectiv, legături absolute). Pentru a evita aceste probleme fără a fi nevoie să rescrieți aplicația, următoarea configurație mi se pare convenabilă:
Nginx ascultă pe interfața externă pe portul 80.

Dacă backend-ul (de exemplu, Apache) se află pe aceeași gazdă cu nginx, atunci „ascultă” portul 80 la 127.0.0.1 sau o altă adresă IP internă.

În acest caz, configurația nginx arată astfel:

Server (
asculta 4.3.2.1:80;
# setați antetul Host și X-Real-IP: la fiecare cerere trimisă către backend
proxy_set_header X-Real-IP $ remote_addr;
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 din 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 fi trimise solicitările pentru scripturi php
locație ~ .php $ (
fastcgi_pass 127.0.0.1:8888; # definiț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 și cu ce parametri să execute:
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 $ request_method;
fastcgi_param CONTENT_TYPE $ tip_conținut;
fastcgi_param CONTENT_LENGTH $ content_length;
}

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

Locație / (
root / var / www / html /
}

Statică

Pentru a reduce sarcina pe backend, este mai bine să serviți fișierele 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, iar procesul nginx, de regulă, consumă mai puțină memorie și poate servi multe conexiuni).

În fișierul de configurare, arată astfel:

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

Locație / (
proxy_pass


„> Http://127.0.0.1:80;

}

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

# solicitări de la / fișiere, pentru care nu a fost găsit niciun fișier, sunt trimise către backend și poate fie să genereze fișierul dorit, fie să afișeze un mesaj de eroare frumos
locație @back (
proxy_pass
„Titlu =" 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 cele de mai sus, numai toate cererile care se termină cu unul dintre sufixele specificate vor fi trimise la această locație
root / var / www / html /;
error_page 404 = @back;
}

Din păcate, nginx nu acceptă gestionarea asincronă a fișierelor. 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 (până la un număr care este de 2-3 ori mai mare decât numărul total de capete de pe discul). Acest lucru, desigur, duce la o creștere a încărcării sistemului de operare, dar performanța generală crește. Pentru a lucra cu o cantitate tipică de 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

Mai multe informații despre nginx pot fi găsite aici: