Nginx je web poslužitelj i mail proxy poslužitelj koji je javno dostupan od 2004. godine. Razvoj projekta započeo je 2002. godine, na ruskom naziv zvuči kao engin-ex. Stvaranje ruku poznatog programera Igora Sysoeva, Nginx je izvorno bio namijenjen Rambleru. Dizajniran je za operativne sustave koji pripadaju skupini sličnih Unixu. Sklop je uspješno testiran na OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. Na platformi Microsoft Windows Nginx je počeo raditi s izdavanjem binarne verzije 0.7.52.

Statistike za ožujak 2011. pokazuju da je broj stranica koje opslužuje Nginx već prešao granicu od 22 milijuna. Danas Nginx koriste poznati projekti kao što su Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru i drugi. Uz lighttpd, Nginx se koristi za posluživanje statičkog sadržaja koji generira "nezgodna" web aplikacija koja radi pod drugim web poslužiteljem.
No prije nego što uđemo u džunglu funkcionalnih značajki Nginxa – korisno je prisjetiti se što je web poslužitelj općenito, a posebno proxy poslužitelj.

Web poslužitelj i proxy poslužitelj

Web poslužitelj je poslužitelj koji prihvaća HTTP zahtjeve od web preglednika i drugih klijenata i izdaje HTTP odgovore na njih. Potonji su obično predstavljeni HTML stranicom, medijskim streamom, slikom, datotekom i drugim podacima. Pod web poslužiteljem se podrazumijeva softver koji implementira funkcije web poslužitelja, kao i hardver. Razmjena podataka i traženih informacija obavlja se putem HTTP protokola.

Popis dodatne funkcije web poslužitelji uključuju: autorizaciju i autentifikaciju korisnika, evidentiranje njihovih zahtjeva na resurse, HTTPS podršku za sigurno prebacivanje s klijentima i drugo. Najčešće korišteni web poslužitelj u operativnim sustavima sličnim Unixu je Apache. Treći redak na popisu preferencija klijenata trenutno zauzima Nginx.

Proxy poslužitelj omogućuje kupcima rukovanje upite za pretraživanje Do mrežne usluge u neizravnom obliku. To jest, to je poslužitelj koji je specijaliziran za prosljeđivanje zahtjeva klijenata drugim poslužiteljima. Povezivanjem s proxy poslužiteljem i zahtjevom za resurs koji se nalazi na drugom poslužitelju, klijent ima mogućnost održati anonimnost i zaštititi računalo od mrežni napadi... Proxy poslužitelj izdaje tražene podatke klijentu ili iz vlastite predmemorije (ako postoji) ili ih prima od navedenog poslužitelja. U nekim slučajevima (da bi se postigli gore navedeni ciljevi), odgovor poslužitelja, kao i zahtjev klijenta, može promijeniti proxy poslužitelj.

Najjednostavniji proxy poslužitelj smatra se Prevoditelj mrežnih adresa ili NAT. Godine 2000. proxy NAT je ugrađen u distribuciju Windowsa. Proxy poslužitelji, kao i svaki fenomen, imaju dvije strane medalje, odnosno mogu se koristiti i za dobro i za zlo. Na primjer, uz njihovu pomoć oni koji se boje sankcija za svoje nepristojne radnje na mreži skrivaju svoje IP adrese ...

Funkcionalni raspon Nginxa:

• poslužiteljsko održavanje indeksnih datoteka, statički upiti, generiranje deskriptora predmemorije otvorite datoteke, popis datoteka;
• ubrzano proxy, elementarna raspodjela opterećenja, tolerancija grešaka;
• podrška za caching tijekom ubrzanog proxyinga i FastCGI;
• podrška za FastCGI (ubrzane) i memcached poslužitelje;
• modularnost, filtri, uključujući "nastavi" (bajt-rasponi) i kompresiju (gzip);
• HTTP provjera autentičnosti, podijeljeni odgovori, SSI filter;
• paralelno izvršavanje nekoliko podzahtjeva na stranici obrađenih kroz FastCGI ili proxy u SSI filteru;
• StartTLS i SSL podrška;
• mogućnost podrške ugrađenog Perla;
• jednostavna autentifikacija (USER / PASS, LOGIN);
• preusmjeravanje poslužitelja (IMAP / POP3 proxy) korisnika na IMAP / POP3 backend pomoću vanjskog poslužitelja za autentifikaciju (HTTP).

Za one koji nisu upoznati s ovom terminologijom, opis funkcionalnosti Nginxa može se činiti prilično neodređenim. No, kada je riječ o načinima konkretnog korištenja ovog web poslužitelja - on će malo po malo početi blijedjeti.

Arhitektura i konfiguracija

Radnički procesi Nginxa služe višestrukim vezama istovremeno, pružajući im OS (operativni sustav) pozive epoll (Linux), select i kqueue (FreeBSD). Podatke primljene od klijenta analizira državni stroj. Raščlanjenim zahtjevom upravlja konfiguracijski specificirani lanac modula. Formiranje odgovora klijentu događa se u međuspremnicima, koji mogu upućivati ​​na dio datoteke ili pohranjivati ​​podatke u memoriju. Redoslijed prijenosa podataka do klijenta određen je lancima u kojima su međuspremnici grupirani.

Strukturno, Nginx HTTP poslužitelj je podijeljen na virtualne poslužitelje, koji su pak podijeljeni na lokacije. Virtualni poslužitelj ili se direktiva može koristiti za određivanje portova i adresa za prihvaćanje veza. Lokacija se može navesti točnim URI-jem, dijelom URI-ja ili regularnim izrazom. Za upravljanje memorijom u hodu, skupovi su slijed unaprijed odabranih blokova memorije. Jedan blok koji je prvobitno dodijeljen za skup ima duljinu od 1 do 16 kilobajta. Dijeli se na područja - zauzeta i nenaseljena. Kako se potonji popunjava, odabir novog objekta osigurava se formiranjem novog bloka.

Geografska klasifikacija klijenata po njihovoj IP adresi se vrši u Nginxu pomoću poseban modul... Sustav stabla Radix omogućuje brz rad s IP adresama, zauzimajući minimalno memorije.

Prednosti Nginxa

Nginx se smatra vrlo brzim HTTP poslužitelj... Umjesto ili u kombinaciji s Apacheom, Nginx se koristi za ubrzavanje obrade zahtjeva i smanjenje opterećenja na poslužitelju. Činjenica je da goleme mogućnosti koje pruža modularna Apache arhitektura nisu potrebne većini korisnika. Plaćanje ove nezatražene funkcionalnosti značajno je trošenje resursa sustava. Za obične stranice, u pravilu, postoji jasna dominacija statičkih datoteka (slike, stilske datoteke, JavaScript), a ne skripti. Za prijenos ovih datoteka posjetitelju resursa nije potrebna nikakva posebna funkcionalnost, budući da je zadatak vrlo jednostavan. To znači da web poslužitelj za obradu takvih zahtjeva mora biti jednostavan i lagan, poput Nginxa.

Načini korištenja Nginxa

Na zasebnom portu / IP-u. Ako je resurs pun slika ili datoteka za preuzimanje, Nginx se može konfigurirati na zasebnom portu ili IP-u i putem njega posluživati ​​statički sadržaj. Međutim, da biste to učinili, morate se malo pozabaviti promjenom poveznica na stranici. Uz veliki broj zahtjeva za statičke datoteke, logično je stvoriti poseban poslužitelj i na njega instalirati Nginx.

Ubrzano proxying... Uz ovu opciju, svi zahtjevi posjetitelja prvo idu na Nginx. Nginx samostalno obrađuje zahtjeve za statičke datoteke (kao što su slika, obični HTML, JavaScript ili CSS datoteka). Ako korisnik kontaktira određenu skriptu, prosljeđuje zahtjev odjelu Apache. Ne morate raditi nikakve transformacije s kodom web-mjesta.

Ako je kanal od poslužitelja do posjetitelja i obrnuto spor, ova upotreba Nginxa može dati dodatni učinak. Zahtjev primljen od posjetitelja prosljeđuje se Nginxu na obradu od strane Apachea. Nakon obrade zahtjeva, Apache usmjerava Nginx stranicu i prekida vezu s osjećajem postignuća. Nginx sada može slati stranicu korisniku koliko god je potrebno, praktički bez trošenja resursa sustava. Apache koji radi umjesto njega bio bi popraćen nerazumno velikim opterećenjem memorije kada bi bio gotovo neaktivan. Usput, ovaj slučaj upotrebe za Nginx ima drugo ime: "Frontend to Apache".

Nginx plus FastCGI. Apache možda uopće neće biti potreban ako tumač jezika na kojem su napisane skripte stranice podržava FastCGI tehnologiju. Takvi jezici uključuju, na primjer, PHP, Perl i niz drugih. Međutim, u ovom slučaju možda ćete morati izmijeniti kodove skripte.

Postoji mnogo detaljnih materijala o tome kako instalirati i konfigurirati Nginx na mreži. Više o Nginxu možete saznati na web stranici njegovog programera Igora Sysoeva.

Namjenski web-poslužitelj temeljen na nginxu izvrstan je način za poboljšanje performansi vaših web stranica. U brzini obrade statičkog sadržaja jednostavno mu nema premca: lako podnosi nekoliko tisuća istovremenih veza i lako se može optimizirati i prilagoditi za bilo koju konfiguraciju. Ali? Kao prednji kraj za Apache, nginx se ispostavilo da je najranjivija točka cjelokupne web infrastrukture, stoga se posebna pozornost mora posvetiti sigurnosti nginxa.

Ovaj je članak svojevrsni obrazovni program, ili, ako želite, sažetak svih tehnika za povećanje sigurnosti nginxa. Neće biti teorije, opisa osnova postavljanja web poslužitelja ili bilo čega drugog. Umjesto toga, postajete iscrpni praktični materijal, koji opisuje sve osnovne korake koje trebate poduzeti da biste dobili uistinu siguran web poslužitelj.

Montaža

Paket nginx dostupan je prekompiliran za bilo koju distribuciju. Međutim, ako sami izgradite poslužitelj, možete ga učiniti kompaktnijim i pouzdanijim, a također možete promijeniti pozdravnu liniju web poslužitelja kako biste obeshrabrili neinteligentne klince skripte.

Promijenite liniju dobrodošlice web poslužitelja

Preuzmite nginx izvore, otvorite datoteku src / http / ngx_http_header_filter_module.c i pronađite sljedeća dva retka:

static char ngx_http_server_string = "Poslužitelj: nginx" CRLF;
static char ngx_http_server_full_string = "Poslužitelj:" NGINX_VER CRLF;

Zamijenite ih nečim poput ovoga:

static char ngx_http_server_string = "Poslužitelj:] [ Web poslužitelj"CRLF;
static char ngx_http_server_full_string = "Poslužitelj:] [Web poslužitelj" CRLF;

Uklonite sve nginx module koje ne koristite

Neki nginx moduli povezuju se s web poslužiteljem odmah u vrijeme kompajliranja i svaki od njih je potencijalno opasan. Možda će se u budućnosti u jednom od njih pronaći ranjivost, a vaš će poslužitelj biti u opasnosti. Onemogućavanjem nepotrebnih modula možete značajno smanjiti rizik od takve situacije.

Izgradite pomoću sljedećih naredbi:

# ./configure --bez-http_autoindex_module --bez-http_ssi_module
# napravi
# izvršite instalaciju

To će vam dati nginx s onemogućenim SSI (Server Side Includes) i Autoindex modulima (i u većini slučajeva beskorisnim). Da biste saznali koji se moduli mogu sigurno izbaciti s web poslužitelja, pokrenite skriptu za konfiguriranje s oznakom '-help'.

Seciranje nginx.conf

Nakon instalacije, nginx bi trebao biti konfiguriran. Na stranicama časopisa već je postojao materijal koji opisuje ovaj proces, no mi ćemo se zadržati na temi članka i govoriti o načinima poboljšanja sigurnosti poslužitelja.

Onemogući prikazivanje verzije poslužitelja na svim stranicama s pogreškama

Dodajte redak "server_tokens off" u datoteku nginx.conf. To će uzrokovati da nginx sakrije vrstu i verziju web poslužitelja na stranicama generiranim kao odgovor na pogrešan zahtjev klijenta.

Postavite zaštitu od prekida hrpa

Dodajte u odjeljak poslužitelja sljedeće redove:

# vi /etc/nginx/nginx.conf

# Maksimalna veličina međuspremnik za pohranjivanje tijela klijentovog zahtjeva
client_body_buffer_size 1K;
# Maksimalna veličina međuspremnika za pohranjivanje zaglavlja zahtjeva klijenta
client_header_buffer_size 1k;
# Maksimalna veličina tijela zahtjeva klijenta, kao što je navedeno u polju Content-Length u zaglavlju. Ako poslužitelj treba podržavati prijenos datoteka, ova vrijednost se mora povećati
klijent_max_body_size 1k;
# Broj i veličina međuspremnika za čitanje velikog zaglavlja zahtjeva klijenta
big_client_header_buffers 2 1k;

Obratite pažnju na direktivu large_client_header_buffers. Prema zadanim postavkama, nginx dodjeljuje četiri međuspremnika za pohranu URI niza, od kojih je svaki jednaka veličini memorijske stranice (za x86 je 4 KB). Međuspremnici se oslobađaju svaki put kada veza uđe u stanje održavanja nakon obrade zahtjeva. Dva međuspremnika od 1KB mogu pohraniti samo 2KB URI-je, što vam omogućuje borbu protiv botova i DoS napada.

Dodajte sljedeće retke za poboljšanje performansi:

# vi /etc/nginx/nginx.conf

# Istekanje tijekom čitanja tijela zahtjeva klijenta
client_body_timeout 10;
# Isteklo je tijekom čitanja zaglavlja zahtjeva klijenta
client_header_timeout 10;
# Istek nakon kojeg poslužitelj neće zatvoriti vezu održavanja u životu s klijentom
keepalive_timeout 5 5;
# Istek vremena prilikom slanja odgovora klijentu
send_timeout 10;

Kontrolirajte broj istodobnih veza

Da biste zaštitili web poslužitelj od preopterećenja i pokušaja DoS-a, dodajte sljedeće retke u konfiguraciju:

# vi /etc/nginx/nginx.conf

# Opišite (slimits) zonu u kojoj će se pohranjivati ​​stanja sesije. Zona od 1 MB može pohraniti oko 32000 stanja, postavili smo je na 5 MB
limit_zone limits $ binary_remote_addr 5m;
# Postavite maksimalni broj istodobnih veza za jednu sesiju. Zapravo, ovaj broj postavlja maksimalni broj veza s jedne IP adrese
limit_conn ograničava 5;

Prva direktiva treba biti u odjeljku HTTP, a druga u odjeljku lokacije. Kada broj veza prijeđe ograničenje, klijent će dobiti poruku "Usluga nedostupna" s kodom 503.

Dopustite veze samo na svoju domenu

Hakeri mogu koristiti botove za skeniranje podmreža i pronalaženje ranjivih web poslužitelja. Obično botovi jednostavno prolaze kroz IP raspone tražeći 80 otvorenih portova i šalju HEAD zahtjev za dobivanje informacija o web poslužitelju (ili početnu stranicu). Takvo skeniranje možete jednostavno spriječiti tako da onemogućite pristup poslužitelju putem IP adrese (dodajte u pododjeljak lokacije):

# vi /etc/nginx/nginx.conf

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

Ograničite broj dostupnih metoda za pristup web poslužitelju

Neki botovi koriste različite metode poziva poslužitelju da pokuša odrediti njegov tip i/ili penetraciju, međutim RFC 2616 jasno kaže da web poslužitelj ne mora implementirati sve te nepodržane metode možda jednostavno neće biti obrađene. Danas su u upotrebi samo metode GET (zahtjev za dokument), HEAD (zahtjev za zaglavlje poslužitelja) i POST (zahtjev za objavljivanje dokumenta), tako da se sve ostale mogu bezbolno onemogućiti postavljanjem sljedećih redaka u poslužiteljski dio konfiguracijske datoteke:

# vi /etc/nginx/nginx.conf

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

Chuck botovi

Drugi način blokiranja botova, skenera i drugih zlih duhova temelji se na određivanju vrste klijenta (korisnički agent). Nije baš učinkovito, jer većina botova oponaša potpuno legitimne preglednike, ali u nekim slučajevima ostaje korisno:

# vi /etc/nginx/nginx.conf

# Blokirajte upravitelje preuzimanja
if ($ http_user_agent ~ * LWP :: Simple | BBBike | wget) (
povratak 403;
}
# Blokirajte neke vrste botova
if ($ http_user_agent ~ * msnbot | scrapbot) (
povratak 403;
}

Blokirajte neželjenu poštu preporuke

Ako vaša stranica objavljuje web-zapise u javnoj domeni, lako možete postati žrtva neželjene pošte preporuke (kada spam botovi kontaktiraju vaš poslužitelj, navodeći adresu oglašene stranice u zaglavlju preporuke). Ova vrsta neželjene pošte može lako pokvariti SEO ljestvicu web stranice, stoga je imperativ blokirati je. Jedan od načina da to učinite je stavljanje na crnu listu najčešćih riječi koje se nalaze u URL-ovima oglašenih web-mjesta.

# vi /etc/nginx/nginx.conf

# Odjeljak poslužitelja
if ($ http_referer ~ * (babes | Forsale | djevojka | nakit | ljubav | nudit | organski | poker | porn | seks | tinejdžer))
{
povratak 403;
}

Blokirajte hotlink

Hotlink je uključivanje slike (ili drugog sadržaja) s druge stranice na stranicu. Zapravo se radi o krađi, jer sliku na koju ste potrošili više od jednog sata svog slobodnog vremena drugi ne samo da slobodno koriste, već i stvara opterećenje na vašem web poslužitelju bez dovođenja posjetitelja na njega. Za borbu protiv hotlinkova, dovoljno je osigurati da se slike daju klijentu samo ako ih je zatražio dok je već bio na stranici (drugim riječima, zaglavlje zahtjeva za preporuku mora sadržavati naziv vaše stranice). Dodajte sljedeće retke u odjeljak poslužitelja konfiguracijske datoteke nginx.conf (host.com je adresa vaše stranice):

# vi /etc/nginx/nginx.conf

lokacija / slike / (
valid_referers nijedan blokiran www.host.com host.com;
if ($ invalid_referer) (
povratak 403;
}
}

Alternativno, možete konfigurirati poslužitelj za posluživanje poseban banner s porukom o krađi umjesto tražene slike. Da biste to učinili, zamijenite redak "return 403" s redom:

prepiši ^ / slike / prijenose. * \. (gif | jpg | jpeg | png) $ http://www.host.com/banned.jpg zadnji

Zaštitite važne imenike od stranaca

Kao i svaki drugi web poslužitelj, nginx vam omogućuje reguliranje pristupa direktoriju na temelju IP adresa i lozinki. Ova se značajka može koristiti za zatvaranje nekih dijelova stranice znatiželjne oči... Na primjer, da uklonite URI iz vanjskog svijeta:

# vi /etc/nginx/nginx.conf

lokacija / prijenosi / (
# Dopusti pristup samo strojevima na lokalnoj mreži
dopustiti 192.168.1.0/24;
# Šivanje svih ostalih
zanijekati sve;
}

Sada će samo korisnici lokalne mreže imati pristup dokumentima direktorija za prijenose. Da biste postavili lozinku, morat ćete napraviti složenije korake. Prvo morate stvoriti privatnu datoteku lozinke za nginx i dodati joj potrebne korisnike (kao primjer, dodajmo administratorskog korisnika):

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

# vi /etc/nginx/nginx.conf

lokacija / admin / (
auth_basic "Ograničeno";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

Novi korisnici mogu se dodati pomoću sljedeće naredbe:

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

Koristite SSL

Ako vaša stranica radi s privatnim korisničkim podacima, kao što su brojevi kreditne kartice, lozinke s drugih usluga ili omogućuje pristup drugoj važna informacija, koji može postati poslastica za treće strane, pobrinite se za enkripciju. Nginx dobro radi sa SSL-om i ne treba ga zanemariti.

Da biste konfigurirali SSL enkripciju pomoću nginxa, trebate samo slijediti nekoliko jednostavnih koraka. Prvo morate stvoriti certifikat koristeći sljedeći niz naredbi:

# 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

Zatim opišite certifikat u nginx konfiguracijskoj datoteci:

# vi /etc/nginx/nginx.conf

poslužitelj (
ime servera host.com;
slušaj 443;
ssl uključen;
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;
}

Nakon toga možete ponovno pokrenuti web poslužitelj:

# /etc/init.d/nginx ponovno učitavanje

Naravno, bez podrške same web stranice, nema smisla to činiti.

druge metode

Postavite ispravne vrijednosti za varijable sustava

Otvorite datoteku /etc/sysctl.conf i stavite u nju sljedeće retke:

# vi /etc/sysctl.conf

# Zaštita od napada štrumfova
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Zaštita od netočnih ICMP poruka
net.ipv4.icmp_ignore_bogus_error_responses = 1
# SYN zaštita od poplava
net.ipv4.tcp_syncookies = 1
# Onemogućite izvorno usmjeravanje
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Zaštita od lažiranja
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Mi nismo ruter
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Uključite ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Proširite raspon dostupnih portova
net.ipv4.ip_local_port_range = 2000 65000
# Povećajte maksimalnu veličinu TCP međuspremnika
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

Postavite korijenski direktorij web poslužitelja na namjensku particiju

Postavljanjem korijenskog direktorija web-poslužitelja u namjensku particiju i onemogućavanjem svih izvršnih datoteka ili datoteka uređaja na njemu, možete zaštititi ostatak sustava od bilo koga tko može pristupiti korijenskom korijenu web-poslužitelja. U ovom slučaju, unos u datoteci / etc / fstab trebao bi izgledati otprilike ovako:

/ dev / sda5 / nginx ext4 zadane postavke, nosuid, noexec, nodev 1 2

Stavite nginx u chroot / jail okruženje

Svaki moderni * nix-sustav omogućuje vam zaključavanje aplikacije u izoliranom okruženju izvršavanja. Na Linuxu za to možete koristiti KVM, Xen, OpenVZ i VServer tehnologije, na FreeBSD-u - Jail, na Solarisu - Zone. Ako nijedna od ovih tehnologija nije dostupna, možete staviti nginx u klasični chroot, koji, iako je mnogo krhkiji, većina krekera može zaustaviti.

Postavite SELinux pravila za zaštitu nginxa

Dobra alternativa izolirane sredine izvršenja su lokalni sustavi za otkrivanje i prevenciju upada kao što su SELinux ili AppArmor. Kada su ispravno konfigurirani, mogu spriječiti pokušaje kompromitiranja web poslužitelja. Prema zadanim postavkama, nijedan od njih nije konfiguriran za rad u sprezi s nginxom, već unutar projekta SELinuxNginx(http://sf.net/projects/selinuxnginx/) stvorena su pravila za SELinux koja svatko može koristiti. Sve što ostaje je preuzeti i instalirati:

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

Konfigurirajte vatrozid

Obično se nginx instalira na namjenske strojeve koji su spremni za velika opterećenja, tako da često ostaje jedina mrežna usluga koja radi na poslužitelju. Za osiguranje poslužitelja dovoljno je stvoriti vrlo mali skup pravila koja će otvoriti portove 80, 110 i 143 (ako bi, naravno, nginx trebao raditi i kao IMAP/POP3 proxy) i zatvoriti sve ostalo iz vanjskog svijeta .

Ograničite broj veza s vatrozidom

Za laganu web stranicu, dobra je ideja ograničiti broj pokušaja povezivanja s jedne IP adrese u minuti. To vas može spasiti od nekih vrsta DoS napada i brute-force napada. Na Linuxu se to može učiniti pomoću standardnog modula stanja iptables / netfilter:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m država -- država NOVO -m nedavno --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m stanje --stanje NOVO -m nedavno --ažuriranje \
--sekundi 60 --broj pogodaka 15 -j DROP

Pravila smanjuju ograničenje broja veza s jednog IP-a u minuti na 15. Isto se može učiniti pomoću pf-a:

# vi /etc/pf.conf

webserver_ip = "1.1.1.1"
stol ustrajati
brzo blokirati iz
proslijediti na $ ext_if proto tcp u $ webserver_ip \
port www zastavice S / SA zadržati stanje \
(max-src-conn 100, max-src-conn-rate 15/60, \
preopterećenje ispiranje)

Uz ograničenje broja uzastopnih veza (15 u minuti), ovo pravilo postavlja dodatno ograničenje na broj istodobnih veza jednako 100.

PHP postavka

Ako koristite nginx zajedno s PHP-om, ne zaboravite ga također konfigurirati. Ovako bi trebala izgledati konfiguracijska datoteka sigurnog poslužitelja /etc/php/php.ini:

# vi /etc/php/php.ini

# Onemogućite opasne funkcije
disable_functions = phpinfo, system, mail, exec
# Maksimalno vrijeme izvršavanja skripte
maksimalno_vrijeme_izvršenja = 30
# Maksimalno vrijeme koje skripta može potrošiti na obradu podataka zahtjeva
max_input_time = 60
# Maksimalna količina memorije dodijeljena svakoj skripti
limit_memorije = 8M
# Maksimalna veličina podataka poslanih u skriptu pomoću POST metode
post_max_size = 8M
# Maksimalna veličina učitanih datoteka
upload_max_filesize = 2M
# Ne prikazuj pogreške PHP skripte korisnicima
display_errors = Isključeno
# Uključite Safe Mode
siguran_način = Uključeno
# Omogućite SQL siguran način rada
sql.safe_mode = Uključeno
# Dopusti izvršavanje vanjskih naredbi samo u ovom direktoriju
safe_mode_exec_dir = / put / do / zaštićenog / direktorija
# Zaštita od curenja PHP informacija
expose_php = Isključeno
# Čuvanje dnevnika
log_errors = Uključeno
# Zabrani otvaranje udaljenih datoteka
allow_url_fopen = Isključeno

zaključke

Primjenom smjernica navedenih u ovom članku, imat ćete mnogo sigurniji web poslužitelj. Ali imajte na umu da neće sve tehnike odgovarati vašoj konfiguraciji. Na primjer, zaštita od grube sile koja se temelji na rezanju veličine međuspremnika dodijeljenih od strane nginxa za obradu zahtjeva klijenta može dovesti do degradacije performansi i, u nekim slučajevima, do neuspjeha u obradi zahtjeva. Ograničavanje broja veza imat će veliki utjecaj na performanse čak i umjereno opterećene web stranice, ali će biti od koristi ako stranica ima nizak protok posjetitelja. Uvijek provjerite kako su promjene koje ste napravili utjecale na performanse i cjelokupno zdravlje vaše web stranice.

O junaku dana

Nginx je jedan od najmoćnijih i najpopularnijih web poslužitelja na svijetu. Prema Netcraftu, koristi se za napajanje više od 12 milijuna web-mjesta diljem svijeta, uključujući Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusek i Taba.ru. Kompetentna arhitektura koja se temelji na multipleksiranju veza pomoću poziva sustava select, epoll (Linux), kqueue (FreeBSD) i mehanizma upravljanja memorijom koji se temelji na skupovima (mali međuspremnici od 1 do 16 KB), omogućuje nginxu da ne propada čak i pod vrlo visokim opterećenjima , izdržava preko 10.000 istodobnih veza (tzv. C10K problem). Izvorno je napisao Igor Sysoev za Rambler i otvoren 2004. pod licencom sličnom BSD-u.

U kontaktu s

Nginx? Svrha, značajke, opcije prilagodbe stvari su s kojima bi svaki web developer trebao biti upoznat kako bi testirao svoje najbolje prakse.

Recimo koju riječ o nginxu

Ovaj alat ima jedan glavni i nekoliko radnih tokova. Prvi se bavi čitanjem i provjerom konfiguracije. Također kontrolira vođenje radnih procesa. Zadatak potonjeg je obrada dolaznih zahtjeva. Nginx koristi model koji se temelji na događajima. Također koristi mehanizme ovisne o operacijskom sustavu za postizanje učinkovite distribucije zahtjeva izravno između radnih procesa. Njihov je broj uvijek naveden u konfiguracijskoj datoteci. Vrijednost može biti fiksna ili postavljena automatski, vođena brojem jezgri procesora s kojima možete raditi. U nginxu se sustav i moduli konfiguriraju pomoću konfiguracijske datoteke. Stoga, ako je potrebno nešto promijeniti, onda je potrebno to tražiti. Obično se nalazi u direktivi / etc / nginx (ali put se može promijeniti kada se koriste drugi sustavi) i ima ekstenziju .conf.

Pokretanje, ponovno pokretanje i zapisnici

Da biste to učinili, morate pokrenuti izvršnu datoteku za rad. Nginx poslužitelj se može konfigurirati samo kada je pokrenut. Kontrola se provodi pozivanjem izvršne datoteke s parametrom -s. Da biste to učinili, koristite sljedeći unos:

nginx -s signal

V u ovom slučaju Možete zamijeniti sljedeće naredbe (moraju doći od korisnika koji je pokrenuo alat):

1. Stop. Koristi se za brz završetak raditi.
2. Ponovno učitati. Naredba je potrebna za ponovno učitavanje konfiguracijske datoteke. Poanta je da se promjene neće primijeniti dok je datoteka pokrenuta. A da bi stupili na snagu, potrebno je ponovno pokretanje. Čim se primi ovaj signal, glavni proces će početi provjeravati ispravnost sintakse konfiguracijske datoteke i pokušati primijeniti tamo dane upute. Ako ne uspije, poništit će promjene i raditi sa starim parametrima. Ako je sve prošlo kako treba, pokrenut će se novi radnički procesi, a starima će se poslati zahtjev za dovršetak.
3. Prestati. Koristi se za glatko isključivanje. Koristi se ako je potrebno pričekati do završetka servisiranja trenutnih zahtjeva.
4. Ponovo otvoriti. Zatvorite i otvorite datoteke dnevnika.

Korištenje uslužnih programa

Procesi se također mogu konfigurirati pomoću Unix alata (uslužni program kill će se uzeti u obzir kao primjer). Obično koriste mehanizam za slanje signala procesu izravno s podacima. Povezani su pomoću ID-a. Ovi podaci su pohranjeni u datoteci nginx.pid. Recimo da nas zanima proces #134. Zatim, za nesmetan završetak, moramo poslati sljedeće podatke:

kill -s NAPUSTI 1628

Recimo da želimo vidjeti popis svih pokrenute datoteke... Za to koristimo uslužni program ps. Naredba će izgledati ovako:

ps -sjekira | grep nginx

To jest, kao što možete vidjeti, kada se koriste dodatni alati, naznačeno je da se koristi. Sada se usredotočimo na to kako se radi nginx konfiguracija.

Struktura konfiguracijske datoteke

Instaliranje i konfiguriranje nginxa uključuje rad s modulima. Konfiguriraju se pomoću direktiva koje su navedene u konfiguracijskoj datoteci. Jednostavni su i blokovi. Prva vrsta direktive sastoji se od imena i parametara koji su odvojeni razmacima, a njihov je kraj označen točkom-zarezom - (;). Blok ima sličnu strukturu. Ali u ovoj direktivi umjesto kraja stavlja se skup dodatne upute koji se stavljaju u vitičaste zagrade ((smjerovi)). Ako se u njih mogu smjestiti imena i parametri drugih procesa, tada se takve konstrukcije nazivaju kontekstom. Primjeri uključuju http, lokaciju i poslužitelj.

Posluživanje statičkog sadržaja

Ovo je jedan od najvažnijih zadataka s kojima se suočava nginx konfiguracija. Posluživanje statističkog sadržaja znači slike i HTML stranice (ne dinamičke). Recimo da nam treba jednokratni posao na postavljanju nix nginx klastera. Je li to teško izvesti? Ne, i pogledajmo primjer. Prije nego što nastavite s tim, potrebno je detaljno opisati uvjete problema. Dakle, ovisno o zahtjevima, datoteke će dolaziti iz različitih lokalnih direktorija. Dakle, u / data / www imamo HTML dokumente. I direktorij / data / images sadrži slike. Optimalna konfiguracija nginxa u ovom slučaju zahtijeva uređivanje konfiguracijske datoteke, u kojoj je potrebno konfigurirati poslužiteljski blok unutar http. Dvije lokacije također će se koristiti za podršku.

Implementacija: poslužitelj

Dakle, prvo trebamo stvoriti same direktorije i u njih smjestiti datoteke s potrebnim nastavcima (sadržaj se mora dodati u html). Zatim otvaramo konfiguracijsku datoteku. Prema zadanim postavkama, već ima nekoliko blokova poslužitelja, koji su uglavnom komentirani. Da bi se postigao najbolji rezultat, ovaj se postupak mora provesti s obzirom na sve zadane komponente. Zatim dodajemo novi blok poslužitelja sa sljedećim kodom:

Konfiguracijska datoteka može raditi s nekoliko takvih blokova. Ali trebali bi se razlikovati po nazivima i portovima preko kojih se primaju podaci.

Izvedba: lokacija

Definirano unutar poslužitelja:

Prisutnost znaka "/" neophodna je za usporedbu primljenih podataka i vidjeti postoji li takva adresa iz obrađenog zahtjeva ovdje. Ako nema problema, tada označavamo put / podatke / www do potrebna datotekašto je u ovome lokalni sustav... Ako postoji podudaranje s nekoliko blokova, tada se odabire onaj s najdužim prefiksom. U navedenom primjeru njegova duljina je jednaka jedan, odnosno koristit će se isključivo ako nema "konkurenta". Sada ga poboljšajmo:

lokacija / slike / (

Kao što vidite, tražimo slike. Sada kombinirajmo sve razvoje koji su bili ranije, a konfiguracija u ovom trenutku izgleda ovako:

lokacija / slike / (

Ovo je radna verzija, koja je standardna. Ovom poslužitelju se može pristupiti bez problema lokalno računalo ako odete na adresu: http: // localhost /. Kako će sve ovo funkcionirati?

Kako primjer funkcionira

Dakle, kada dođu zahtjevi koji počinju s / slike, poslužitelj će poslati datoteke iz odgovarajućeg direktorija korisniku. Ako ga nema, bit će prenijete informacije koje ukazuju na pogrešku 404. Ako je nginx konfiguriran na lokalnom računalu, tada ćemo nakon zahtjeva za http: //localhost/images/example.png primiti datoteku čija je lokacija /data/images /primjer.png. Ako navedete jedan znak "/", pretraga će se izvršiti u imeniku / data / www. Ali promijenili smo samo konfiguraciju. Da bi počeo raditi, potrebno ga je ponovno pokrenuti. Da biste to učinili, koristite naredbu nginx -s reload. U slučaju kada normalan rad nije moguće, tada u datotekama error.log i access.log koje se nalaze u direktivi / usr / local / nginx / logs možete potražiti uzrok neuspjeha.

Izrada jednostavnog proxy poslužitelja

Što se nginxa tiče, konfiguriranje ovog objekta jedna je od najčešćih upotreba (i usput, prilično jednostavna). Koristi princip poslužitelja koji prihvaća zahtjev, a zatim ih preusmjerava na potrebna mjesta. Nakon toga se od njih očekuje odgovor koji ih upućuje onome tko je postavio zadatak. Pogledajmo primjer stvaranja bazne točke. Služit će zahtjeve korisnika i pružiti im slike iz lokalnog imenika. Dakle, dodajte još jedan poslužitelj u http blok sa sljedećim sadržajem:

Sada dešifrirajmo za vas: stvara se jednostavan poslužitelj. Slušat će Ne specificirati slušati, tada će poslužitelj raditi na 80. Svi zahtjevi unutar lokalnog područja bit će prikazani. sustav datoteka koji su usmjereni na / data / up1 direktorij (naravno, prije toga će ga trebati kreirati). Da biste to mogli provjeriti, morate tamo smjestiti datoteku index.html. Postavljanjem korijenske direktive u kontekst poslužitelja, moći ćemo koristiti lokaciju pod bilo kojim uvjetima (budući da se time uklanjaju ograničenja pristupa). Sada radimo na stvaranju proxy poslužitelja. Da bi funkcionirao, potrebna nam je direktiva proxy_pass, za koju će protokol, naziv i port objekta biti specificirani kao parametri (ako lokalna veza izgledat će kao http: // localhost: 8080). Dobivate sljedeći rezultat:

proxy_pass http: // localhost: 8080;

lokacija / slike / (

Ako pogledate kod i analizirate ga, primijetit ćete da je drugi blok lokacije promijenjen. Dakle, u ovom slučaju može raditi s tipičnim proširenjima slika. Malo drugačije, moglo bi se prikazati na ovaj način:

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

korijen / podaci / slike;

Konačna konfiguracija proxyja izgleda ovako:

proxy_pass http: // localhost: 8080 /;

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

korijen / podaci / slike;

Filtrirat će zahtjeve koji na kraju imaju navedene ekstenzije i poslati ih onome tko je zatražio datoteke. Ne zaboravite da ako želite provjeriti konfiguracijsku datoteku, morat ćete je ponovno učitati. I vjerujte mi, ovo je najjednostavniji nginx setup. Ako otvorite konfiguracijsku datoteku poslužitelja Vkontakte ili druge velike tvrtke, imat će više koda nego što ima riječi u ovom članku.

Jedan od najpopularnijih web poslužitelja

Nginx je vrlo popularan među korisnicima weba i proxy poslužitelja zbog svojih performansi. Poslužitelj ima mnoge prednosti, ali početniku može biti teško postaviti ga. Želimo vam pomoći da shvatite konfiguracijske datoteke, sintaksu i osnovne postavke Nginxa.

Hijerarhija imenika

Sve konfiguracijske datoteke poslužitelja nalaze se u direktoriju / etc / nginx. Osim toga, unutar direktorija postoji još nekoliko mapa, kao i modularne konfiguracijske datoteke.

cd / etc / nginx
ls -F
conf.d / koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf web-mjesta-dostupne / win-utf
koi-utf naxsi_core.rules proxy_params site-enabled /

Ako ste koristili Apache, trebali biste biti upoznati s direktorijima s omogućenim i dostupnim web lokacijama. Oni određuju konfiguraciju web-mjesta. Generirane datoteke pohranjuju se u zadnji direktorij. Mapa s omogućenim stranicama potrebna je za pohranu konfiguracija samo aktiviranih stranica. Da biste ih povezali, potrebna vam je simbolička veza između mapa. Konfiguracije se također mogu pohraniti u direktorij conf.d. Istodobno, tijekom pokretanja Nginxa, svaka datoteka s nastavkom .conf ponovno će se čitati. Kada pišete konfiguracijske datoteke, ispravno upišite kod i slijedite sintaksu. Sve ostale datoteke nalaze se u / etc / nginx. Konfigurator sadrži informacije o specifičnim procesima, kao i dodatne komponente.

Glavna konfiguracijska datoteka Nginxa je nginx.conf.

Čita sve konfiguracijske datoteke, spajajući ih u jednu, što se traži kada se poslužitelj pokrene. Otvorite datoteku sa:

sudo nano /etc/nginx/nginx.conf

Na ekranu će se pojaviti sljedeći redovi:

korisnik www-podaci;
radnički_procesi 4;
pid /var/run/nginx.pid;
događaji (
radničke_veze 768;
# multi_accept uključeno;
}
http (
. . .

Prvi je opće informacije o Nginxu. Izraz korisnik www-podaci odnosi se na korisnika koji pokreće poslužitelj. Direktiva pid pokazuje gdje se nalaze PID procesi. unutarnja upotreba... Redak worker_processes pokazuje koliko procesa Nginx može pokrenuti u isto vrijeme. Osim toga, ovdje možete specificirati zapisnike (na primjer, dnevnik pogrešaka definiran je pomoću direktive error_log). Ispod je odjeljak događaja. Potreban je za rukovanje poslužiteljskim vezama. Nakon toga je http blok.

Struktura konfiguracijske datoteke Nginxa

Razumijevanje strukture formatiranja datoteka pomoći će vam da bolje razumijete konfiguraciju vašeg web poslužitelja. Dijeli se na strukturni blokovi... Detalji konfiguracije http bloka su slojeviti pomoću privatnih blokova. Svojstva nasljeđuju od roditelja, t.j. onaj u kojem se nalaze. Ovaj blok pohranjuje većinu konfiguracija poslužitelja. Podijeljeni su na blokove poslužitelja, unutar kojih se nalazi lokacija.

Kada konfigurirate svoj Nginx poslužitelj, zapamtite da što je niži konfiguracijski blok, to će manje stavki naslijediti svojstva i obrnuto. Datoteka sadrži veliki broj opcije koje mijenjaju rad poslužitelja. Možete postaviti kompresiju datoteka koje se šalju klijentu, na primjer. Da biste to učinili, napišite parametre:

gzip na;
gzip_disable "msie6";

Imajte na umu da isti parametar može uzeti različita značenja v različiti blokovi... Prvo ga postavite na vrh, a zatim nadjačajte parametar na pravu razinu... Ako se posljednja radnja ne izvrši, program će postaviti vrijednosti u automatskom načinu rada.

Posljednji redovi datoteke nginx.conf su:

uključiti /etc/nginx/conf.d/*.conf;
uključiti / etc / nginx / sites-enabled / *;

Oni označavaju da su lokacija i blokovi poslužitelja pohranjeni izvan ove datoteke. Oni definiraju postavke za URL-ove i određene datoteke. Ova je struktura neophodna za održavanje modularne konfiguracijske strukture. Unutar njega ćete moći kreirati nove direktorije, datoteke za razne stranice. Štoviše, slične datoteke moći ćete se grupirati. Nakon pregleda, možete zatvoriti datoteku nginx.conf.

Virtualni blokovi

Oni su analogni virtualnim hostovima u Apacheu. Blokovi odjeljka poslužitelja uključuju karakteristike pojedinačnih stranica koje se nalaze na poslužitelju. U mapi "Sites-available" pronaći ćete zadanu datoteku bloka poslužitelja. Unutar njega možete izvana pronaći potrebne podatke koji mogu biti potrebni pri održavanju web-mjesta.

cd stranice-dostupne
sudo nano default
poslužitelj (
root / usr / share / nginx / www;
indeks index.html index.htm;
server_name localhost;
lokacija / (
try_files $ uri $ uri / /index.html;
}
lokacija / dokument / (
alias / usr / share / doc /;
autoindeks uključen;
dopustiti 127.0.0.1;
zanijekati sve;
}
}

U gornjem primjeru komentar je namjerno uklonjen. To je učinjeno radi čitljivosti. Unutar blokova poslužitelja nalaze se postavke zatvorene u vitičaste zagrade:

Ovaj blok se postavlja pomoću direktive uključivanja na kraj http navedenog u datoteci nginx.conf. Root direktiva definira direktorij u kojem će se nalaziti sadržaj stranice. U njemu će program tražiti datoteke koje će korisnik zatražiti. Zadana staza je / usr / share / nginx / www. Nginx odvaja redove ili direktive jedan od drugog točkom i zarezom. Ako ne stavite interpunkcijski znak, nekoliko redaka će se čitati kao jedan. Za pisanje pravila koja će se koristiti kao indeks, koristite direktivu indeksa. Poslužitelj će ih provjeriti redoslijedom kojim su navedeni. Ako korisnik nije zatražio nijednu od dostupnih stranica, bit će vraćen index.html. Ako ga nema, poslužitelj će tražiti index.htm.

Pravilo imena_poslužitelja

Sadrži popis naziva domena koje će obraditi blok poslužitelja. Možete ih napisati bilo koji broj, odvajajući ih razmacima. Ako stavite * na kraj ili početak domene, moći ćete odrediti naziv s maskom. Zvjezdica odgovara dijelu imena. Ako registrirate * .com.ua, tada sve adrese navedene domenska zona... Ako adresa odgovara opisu nekoliko direktiva, tada će odgovoriti onom koja se u potpunosti uklapa. Ako nema podudaranja, odgovor će biti najduži naziv koji ima masku. U suprotnom će se uskladiti regularni izrazi. Nazivi poslužitelja koji koriste regularne izraze počinju s tildom (~).

Lokacijski blokovi

Sljedeći u redu imat ćemo blok lokacije. Potrebno je odrediti način obrade određene zahtjeve... Ako resursi ne odgovaraju nijednom drugom bloku lokacije, tada će se na njih primijeniti direktive navedene u zagradama. Ovi blokovi mogu uključivati ​​put poput /doc /. Za uspostavljanje potpune korespondencije između uri-a i lokacije, koristi se znak =. Primjena tilde će odgovarati regularnim izrazima. Također možete postaviti osjetljivost na velika i mala slova unosom ~. Ako dodate zvjezdicu, velika i mala slova nisu bitna.

Imajte na umu: kada se zahtjev podudara s blokom lokacije, on će se koristiti i pretraživanje će se zaustaviti. Kada je podudaranje nepotpuno, URI će se usporediti s parametrima direktiva o lokaciji. Blok s kombinacijom ^ ~ koristi se za podudaranje URI-ja za odabir bloka. Ako ovu opciju ne koristite, poslužitelj odabire najbolje podudaranje i također traži pomoću regularnih izraza. To je potrebno za odabir jednog od prikladnih predložaka. Ako se pronađe odgovarajući izraz, on će se koristiti. U suprotnom će se primijeniti prethodno podudaranje URI-ja. Međutim, imajte na umu da Nginx više voli pune utakmice. Ako ih nema, počet će tražiti regularne izraze, a zatim po URI-ju. Paritet pretraživanja određen je kombinacijom znakova ^ ~.

Pravilo Try_files

To je vrlo koristan alat sposoban za provjeru datoteka određenim redoslijedom. Primjenjuje prvi podudarni kriterij za obradu zahtjeva. možeš koristiti Dodatne opcije definirati kako će poslužitelj posluživati ​​zahtjeve. Konfigurator ima zadanu liniju poput ove:

try_files $ uri $ uri / /index.html;

Što to znači? Ako dođe zahtjev koji poslužuje blok lokacije, poslužitelj će prvo pokušati obraditi uri kao datoteku. To osigurava varijabla $uri. Kada nema podudaranja, uri će se tretirati kao direktorij. Možete provjeriti njegovo postojanje dodavanjem kose crte na kraju: $ uri /. Postoje situacije kada ni datoteka ni direktorij neće biti pronađeni. U tom slučaju će se učitati zadana datoteka index.html. Primjenjuje se pravilo Try_files posljednji parametar kao rezervni. Iz tog razloga ovu datoteku mora biti u sustavu. Međutim, ako se uopće ne pronađu podudaranja, Nginx će vratiti stranicu s greškom. Da biste ga postavili, napišite = i kod pogreške:

Dodatne opcije

Ako primijenite pravilo aliasa, moći ćete, na primjer, posluživati ​​stranice u bloku lokacije izvan korijenskog direktorija. Kada su datoteke potrebne iz doc-a, bit će zatražene iz /usr/share/doc/. Osim toga, pravilo za autoindeks počinje s popisom direktorija poslužitelja za navedenu direktivu lokacije. Ako upišete retke zabrani i dopusti, moći ćete promijeniti pristup imenicima.

Kao zaključak treba reći da je Nginx vrlo moćan multifunkcionalni alat. Ali za dobro razumijevanje kako funkcionira trebat će vremena i truda. Ako razumijete kako funkcioniraju konfiguracije, možete u potpunosti uživati ​​u svim značajkama programa.

Ostalo). Trenutna verzija, 0.6.x se smatra stabilnim u smislu pouzdanosti, a izdanja iz grane 0.7 smatraju se nestabilnim. Važno je napomenuti da će se funkcionalnost nekih modula promijeniti, zbog čega se mogu promijeniti i direktive, stoga kompatibilnost unatrag u nginxu prije verzije 1.0.0 nije zajamčeno.

Zašto je nginx tako dobar i zašto ga administratori projekata s velikim opterećenjem toliko vole? Zašto jednostavno ne koristite Apache?

Zašto je Apache loš?

Prvo morate objasniti kako mrežni poslužitelji općenito rade. Oni koji su upoznati s mrežnim programiranjem znaju da u suštini postoje tri modela rada poslužitelja:

1. Dosljedan. Poslužitelj otvara utičnicu za slušanje i čeka da se pojavi veza (u blokiranom je stanju dok čeka). Kada veza stigne, poslužitelj je obrađuje u istom kontekstu, zatvara vezu i ponovno čeka vezu. Očito, ovo je daleko od najboljeg načina, pogotovo kada klijent radi duže vrijeme i ima puno veza. Osim toga, sekvencijalni model ima mnogo više nedostataka (na primjer, nemogućnost korištenja više procesora), au stvarnim uvjetima praktički se ne koristi.
2. Višeprocesni (višenitni). Poslužitelj otvara utičnicu za slušanje. Kada veza stigne, ona je prihvaća, nakon čega stvara (ili uzima iz skupa prethodno stvorenih) novi proces ili nit koja može raditi s vezom proizvoljno dugo, a na kraju rada izlazi ili se vraća u bazen. Glavna nit je u međuvremenu spremna prihvatiti novu vezu. Ovo je najpopularniji model jer je relativno jednostavan za implementaciju, omogućuje složene i dugotrajne izračune za svakog klijenta te koristi sve dostupnih procesora... Primjer njegove upotrebe - Apache web poslužitelj... Međutim, ovaj pristup ima i nedostatke: s velikim brojem istodobnih veza stvara se puno niti (ili, još gore, procesa), a operativni sustav troši mnogo resursa na preklapanje konteksta. Posebno je loše kada kupci jako sporo prihvaćaju sadržaj. Ispostavilo se da su stotine niti ili procesa zauzete samo slanjem podataka sporim klijentima, što stvara dodatno opterećenje na OS planeru, povećava broj prekida i troši puno memorije.
3. Neblokirajuće utičnice / State Machine. Poslužitelj radi unutar jedne niti, ali koristi neblokirajuće utičnice i mehanizam prozivanja. Oni. poslužitelj pri svakoj iteraciji beskrajna petlja odabire iz svih utičnica onu koja je spremna za primanje / slanje podataka pomoću poziva odabira (). Nakon što je utičnica odabrana, poslužitelj joj šalje podatke ili ih čita, ali ne čeka potvrdu, već prelazi u početno stanje i čeka događaj na drugoj utičnici ili obrađuje sljedeći u kojem se događaj dogodio tijekom obrada prethodnog. Ovaj model vrlo učinkovito korištenje procesora i memorije, ali prilično teško za implementaciju. Osim toga, u okviru ovog modela, obrada događaja na utičnici mora biti vrlo brza - inače će se mnogi događaji akumulirati u redu čekanja i na kraju će se on preliti. Ovako radi nginx. Osim toga, omogućuje vam pokretanje više radnih procesa (zvanih radnici), t.j. može koristiti više procesora.

Dakle, zamislite sljedeću situaciju: 200 klijenata s kanalom od 256 Kbps spojeno je na HTTP poslužitelj s kanalom od 1 Gbps:

Što se događa u slučaju Apachea? Stvara se 200 niti / procesa koji relativno brzo generiraju sadržaj (ovo može biti kao dinamičke stranice i statičke datoteke čitane s diska), ali ga polako predaju klijentima. Operacijski sustav mora se nositi s hrpom niti i I/O bravama.

U takvoj situaciji, Nginx troši red veličine manje OS i memorijskih resursa na svaku vezu. Međutim, ovdje dolazi do izražaja ograničenje mrežnog modela nginx: on ne može generirati dinamički sadržaj u sebi, jer to će dovesti do blokiranja unutar nginxa. Naravno, postoji rješenje: nginx može proxy takve zahtjeve (za generiranje sadržaja) na bilo koji drugi web poslužitelj (na primjer, isti Apache) ili na FastCGI poslužitelj.

Razmotrimo mehanizam rada paketa nginx kao "glavnog" poslužitelja i Apachea kao poslužitelja za generiranje dinamičkog sadržaja:

Nginx prihvaća vezu od klijenta i čita cijeli zahtjev s njega. Ovdje treba napomenuti da dok nginx ne pročita cijeli zahtjev, ne predaje ga na "obradu". Zbog toga se gotovo svi pokazatelji napretka prijenosa datoteka obično "lome" - međutim, moguće ih je popraviti pomoću modula upload_progress treće strane (to će zahtijevati izmjenu aplikacije).

Nakon što nginx pročita cijeli odgovor, otvara vezu s Apacheom. Potonji radi svoj posao (generira dinamički sadržaj), nakon čega svoj odgovor šalje nginxu, koji ga sprema u memoriju, ili privremena datoteka... U međuvremenu, Apache oslobađa resurse. Nadalje, nginx polako šalje sadržaj klijentu, trošeći redove veličine manje resursa od Apachea.

Ova shema se zove frontend + backend i koristi se vrlo često.

Montaža

Jer nginx tek počinje dobivati ​​popularnost, postoje neki problemi s binarnim paketima, stoga budite spremni sami ga sastaviti. To obično nije problem, samo trebate pažljivo pročitati izlaz naredbe. / Konfigurirajte --help i odaberite opcije kompilacije koje su vam potrebne, na primjer:

./konfiguriraj \
--Prefiks = / opt / nginx-0.6.x \ # instalacijski prefiks
--Conf-path = / etc / nginx / nginx.conf \ # lokacija konfiguracijske datoteke
-Pid-path = / var / run / nginx.pid \ # ... i pid datoteka
-Korisnik = nginx \ # korisničko ime pod kojim će se nginx pokrenuti
—S-http_ssl_module —sa-http_gzip_static_module —sa-http_stub_status_module \ # popis potrebnih
—Bez-http_ssi_module —bez-http_userid_module —bez-http_autoindex_module —bez-http_geo_module —bez-http_referer_module —bez-http_memcached_module —bez-http_limit_zone ... i_module nije potrebno

Nakon konfiguracije, trebali biste pokrenuti standardnu ​​make && make install, nakon čega možete koristiti nginx.

Alternativno, u Gentoou možete koristiti ebuild iz standardnog stabla portova; u RHEL / CentOS epel repozitorij (gdje se nalazi nginx 0.6.x) ili srpm za verziju 0.7, koji se može preuzeti ovdje: http://blogs.mail.ru/community/nginx; na Debianu, možete koristiti nginx paket iz nestabilne grane.

Konfiguracijska datoteka

Konfiguracijska datoteka nginx vrlo je zgodna i intuitivna. Obično se zove nginx.conf i nalazi se u $ prefiks / conf / ako mjesto nije redefinirano tijekom kompilacije. Volim ga staviti u / etc / nginx /, kao i programeri svih gore navedenih paketa.

Struktura konfiguracijske datoteke je sljedeća:

korisnik nginx; # korisničko ime pod kojim će se nginx pokrenuti
radnički_procesi 1; # broj radnih procesa
događaji (
<…># ovaj blok specificira mehanizam prozivanja koji će se koristiti (vidi dolje) i maksimalni broj mogućih veza
}

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

# opis poslužitelja (ovo je ono što apache naziva VirtualHost)
poslužitelj (
# adresa i naziv poslužitelja
slušaj *: 80;
ime_poslužitelja aaa.bbb;

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

# i ovako možete definirati lokaciju, za koju također možete nadjačati gotovo sve direktive navedene na globalnijim razinama
lokacija / abcd / (
<директивы>;
}
# Osim toga, možete napraviti lokaciju pomoću regularnog izraza, ovako:
mjesto ~ \ .php $ (
<директивы>;
}
}

# drugi poslužitelj
poslužitelj (
slušaj *: 80;
server_name ccc.bbb;

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

Imajte na umu da svaka direktiva mora završavati točkom i zarezom.
Obrnuti proxying i FastCGI

Dakle, gore smo ispitali prednosti frontend + backend sheme, shvatili instalaciju, strukturu i sintaksu konfiguracijske datoteke, razmotrite sada kako implementirati obrnuto proxy u nginx.

Vrlo je jednostavno! Na primjer ovako:

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

U ovom primjeru, svi zahtjevi za lokaciju / bit će proslijeđeni poslužitelju 1.2.3.4, port 8080. To može biti ili apache ili bilo koji drugi http poslužitelj.

Međutim, postoji nekoliko suptilnosti koje se odnose na činjenicu da će aplikacija pretpostaviti da joj, prvo, svi zahtjevi dolaze s jedne IP adrese (što se može protumačiti, na primjer, kao pokušaj DDoS napada ili brute-force napada) , i drugo, uzmite u obzir da radi na hostu 1.2.3.4 i portu 8080 (generira pogrešna preusmjeravanja i apsolutne veze). Kako bih izbjegao ove probleme bez ponovnog pisanja aplikacije, čini mi se prikladnom sljedeća konfiguracija:
Nginx sluša na vanjskom sučelju na portu 80.

Ako se pozadina (na primjer, Apache) nalazi na istom hostu kao nginx, tada "sluša" port 80 na 127.0.0.1 ili drugu internu IP adresu.

U ovom slučaju, nginx konfiguracija izgleda ovako:

poslužitelj (
slušaj 4.3.2.1:80;
# postavite zaglavlje Host i X-Real-IP: na svaki zahtjev poslan na pozadinu
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header Host $ host: $ proxy_port;
# ili "proxy_set_header Host $ host;" ako će aplikacija dodati: 80 svim vezama
}

Kako bi aplikacija razlikovala IP adrese posjetitelja, trebate ili instalirati modul mod_extract_forwarded (ako ga izvršava Apache poslužitelj) ili modificirati aplikaciju tako da preuzima informacije o IP adresi korisnika s X- Real-IP HTTP zaglavlje.

Druga pozadinska opcija je korištenje FastCGI. U ovom slučaju, nginx konfiguracija će izgledati otprilike ovako:

poslužitelj (
<…>

# mjesto gdje će se slati zahtjevi za php-skripte
lokacija ~ .php $ (
fastcgi_pass 127.0.0.1:8888; # definirajte adresu i port fastcgi poslužitelja,
fastcgi_index index.php; # ... indeksna datoteka

# i neke parametre koje je potrebno proslijediti fastcgi poslužitelju kako bi razumio koju skriptu i s kojim parametrima izvršiti:
fastcgi_param SCRIPT_FILENAME / usr / www / html $ fastcgi_script_name; # naziv skripte
fastcgi_param QUERY_STRING $ query_string; # niz upita
# i parametri zahtjeva:
fastcgi_param REQUEST_METHOD $ request_method;
fastcgi_param CONTENT_TYPE $ content_type;
fastcgi_param CONTENT_LENGTH $ content_length;
}

#zbog činjenice da su lokacije s regularni izrazi imaju visoki "prioritet", svi ne-php zahtjevi će ići ovdje.

lokacija / (
root / var / www / html /
}

Statika

Kako bi se smanjilo opterećenje pozadine, bolje je posluživati ​​statičke datoteke samo putem nginxa - on se bolje nosi s tim zadatkom, jer za svaki zahtjev troši znatno manje resursa (nema potrebe za stvaranjem novog procesa, a nginx proces obično troši manje memorije, i može poslužiti mnogim vezama).

U konfiguracijskoj datoteci to izgleda ovako:

poslužitelj (
slušaj *: 80;
ime servera myserver.com;

Lokacija / (
proxy_pass


"> Http://127.0.0.1:80;

}

# pretpostavimo da su sve statičke datoteke u / datotekama
lokacija / datoteke / (
root / var / www / html /; # odredite put do fs
istječe 14d; # dodajte zaglavlje Expires:
error_page 404 = @back; # i ako datoteka nije pronađena, pošaljite je na imenovanu lokaciju @back
}

# zahtjeva iz / datoteka, za koje nije pronađena datoteka, šalju se u pozadinu i može generirati željenu datoteku ili prikazati lijepa poruka o pogrešci
lokacija @natrag (
proxy_pass
"Naslov =" http://127.0.0.1:80;

"> Http://127.0.0.1:80;

}

Ako sva statika nije smještena u određeni direktorij, upotrijebite regularni izraz:

lokacija ~ * ^. + \. (jpg | jpeg | gif | png | ico | css | zip | tgz | gz | rar | bz2 | doc | xls | exe | pdf | ppt | txt | tar | wav | bmp | rtf | js) $ (
# slično gore navedenom, na ovu lokaciju bit će poslani samo svi zahtjevi koji završavaju jednim od navedenih sufiksa
root / var / www / html /;
error_page 404 = @back;
}

Nažalost, nginx ne podržava asinkrono rukovanje datotekama. Drugim riječima, nginx radnik je blokiran na I/O operacijama. Dakle, ako imate puno statičkih datoteka, a posebno ako se iz njih čitaju različiti diskovi, bolje je povećati broj radnih procesa (do broja koji je 2-3 puta veći od ukupnog broja glava na disku). To, naravno, dovodi do povećanja opterećenja OS-a, ali se ukupna izvedba povećava. Za rad s tipičnom količinom statike (ne baš velikim brojem relativno malih datoteka: CSS, JavaScript, slike), dovoljna su jedan ili dva tijeka rada.

Nastavit će se

Linkovi

Više informacija o nginxu možete pronaći ovdje: