Nginx je web server i mail proxy server koji je javno dostupan od 2004. godine. Razvoj projekta započeo je 2002. godine, na ruskom naziv zvuči kao engin-ex. Kreiranje ruku poznatog programera Igora Sysoeva, Nginx je prvobitno bio namijenjen Rambleru. Dizajniran je za operativne sisteme koji pripadaju Unix-sličnoj grupi. Sklop je uspješno testiran na OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. Na Microsoft Windows platformi, Nginx je počeo da radi pojavom binarnog sklopa verzije 0.7.52.

Statistike za mart 2011. pokazuju da je broj sajtova koje Nginx opslužuje već prešao granicu od 22 miliona. 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 generiranog od strane "nezgodne" web aplikacije koja radi pod drugim web serverom.
Ali prije nego što uđemo u džunglu funkcionalnih karakteristika Nginxa - korisno je podsjetiti se što je web server općenito, a posebno proxy server.

Web server i proxy server

Web server je server koji prihvata HTTP zahtjeve od web pretraživača i drugih klijenata i izdaje HTTP odgovore na njih. Potonji su obično predstavljeni HTML stranicom, medijskim tokom, slikom, datotekom i drugim podacima. Pod web serverom se podrazumijeva i softver koji obavlja funkcije web servera i hardver. Razmjena podataka i traženih informacija vrši se putem HTTP protokola.

Lista dodatnih funkcija web servera uključuje: autorizaciju i autentifikaciju korisnika, evidentiranje njihovih poziva na resurse, HTTPS podršku za bezbedno prebacivanje sa klijentima i druge. Najčešće korišteni web server u operativnim sistemima sličnim Unixu je Apache. Treći red na listi preferencija klijenata trenutno zauzima Nginx.

Proxy server omogućava klijentima da indirektno traže online usluge. To jest, to je server koji je specijaliziran za prosljeđivanje zahtjeva klijenata drugim serverima. Povezivanjem na proxy server i traženjem resursa koji se nalazi na drugom serveru, klijent može održati anonimnost i zaštititi računar od mrežnih napada. Proxy server izdaje tražene podatke klijentu ili iz vlastite keš memorije (ako postoji) ili ih prima od navedenog servera. U nekim slučajevima (da bi se postigli gore navedeni ciljevi), odgovor servera, kao i zahtjev klijenta, može biti promijenjen od strane proxy servera.

Najjednostavniji proxy server se smatra Translator mrežnih adresa ili NAT. Godine 2000, proxy NAT je ugrađen u Windows distribuciju. Proxy serveri, 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 plaše sankcija za svoje nepristojne radnje na mreži skrivaju svoje IP adrese...

Funkcionalni raspon Nginxa:

• serversko servisiranje indeksnih datoteka, statičkih upita, generiranje deskriptora za otvorenu keš memoriju, lista datoteka;
• ubrzano proxy, elementarna raspodjela opterećenja, tolerancija grešaka;
• podrška za keširanje tokom ubrzanog proxyja i FastCGI;
• podrška za FastCGI (ubrzane) i memcached servere;
• modularnost, filteri, uključujući "resume" (bajt-opsezi) i kompresiju (gzip);
• HTTP autentifikacija, odgovori u komadima, 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 servera (IMAP/POP3 proxy) korisnika na IMAP/POP3 backend koristeći vanjski autentifikacijski server (HTTP).

Za one koji nisu upoznati s ovom terminologijom, opis funkcionalnosti Nginxa može izgledati prilično nejasan. Ali kada su u pitanju načini konkretnog korišćenja ovog web servera - on će početi da bledi malo po malo.

Arhitektura i konfiguracija

Radni procesi Nginxa služe višestrukim vezama istovremeno, pružajući im OS (operativni sistem) pozive epoll (Linux), select i kqueue (FreeBSD). Podaci primljeni od klijenta se analiziraju od strane državnog stroja. Raščlanjenim zahtjevom upravlja konfiguracijski specificirani lanac modula. Formiranje odgovora klijentu događa se u baferima, koji mogu ukazivati ​​na dio datoteke ili pohranjivati ​​podatke u memoriju. Redoslijed prijenosa podataka do klijenta određen je lancima u kojima su baferi grupirani.

Strukturno, Nginx HTTP server je podeljen na virtuelne servere, koji su zauzvrat podeljeni na lokacije. Virtuelnom serveru ili direktivi se mogu dodijeliti portovi i adrese za primanje veza. Lokacija se može specificirati sa tačnim URI-jem, dijelom URI-ja ili regularnim izrazom.Za upravljanje memorijom u hodu, spremišta su niz unaprijed odabranih blokova memorije. Jedan blok koji je prvobitno dodijeljen za skup ima dužinu od 1 do 16 kilobajta. Podijeljena je 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 posebnog modula. Radix sistem stabla vam omogućava brz rad sa IP adresama, zauzimajući minimum memorije.

Prednosti Nginxa

Nginx se smatra veoma brzim HTTP serverom. Umjesto ili u kombinaciji s Apacheom, Nginx se koristi za ubrzanje obrade zahtjeva i smanjenje opterećenja na serveru. Činjenica je da ogromne mogućnosti koje pruža modularna Apache arhitektura nisu potrebne većini korisnika. Plaćanje za ovu nezatraženu funkcionalnost je značajno gubljenje sistemskih resursa. Za obične stranice, u pravilu, postoji jasna dominacija statičkih datoteka (slike, stilski fajlovi, JavaScript), a ne skripti. Za prijenos ovih datoteka posjetitelju resursa nije potrebna nikakva posebna funkcionalnost, jer je zadatak vrlo jednostavan. To znači da web server 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 preko njega posluživati ​​statički sadržaj. Međutim, da biste to učinili, morate se malo pozabaviti promjenom linkova na stranici. Uz veliki broj zahtjeva za statičke datoteke, ima smisla kreirati poseban server i na njemu 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 fajl). Ako korisnik kontaktira određenu skriptu, on prosljeđuje zahtjev Apache odjelu. Ne morate praviti nikakve transformacije sa kodom stranice.

Ako je kanal od servera do posjetitelja i obrnuto spor, ova upotreba Nginxa može dati dodatni efekat. Zahtjev primljen od posjetitelja prosljeđuje se Nginx-u na obradu od strane Apache-a. Nakon obrade zahtjeva, Apache usmjerava Nginx stranicu i prekida vezu s osjećajem postignuća. Nginx sada može slati stranicu korisniku onoliko dugo koliko je potrebno, praktično bez trošenja sistemskih resursa. Apache koji radi na njegovom mjestu bio bi prać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 ćete možda 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 server zasnovan na nginx-u odličan je način da poboljšate performanse vaših web stranica. U brzini obrade statičkog sadržaja jednostavno nema premca: lako izdržava nekoliko hiljada istovremenih veza i lako se može optimizirati i prilagoditi za bilo koju konfiguraciju. Ali? Kao front-end za Apache, nginx se ispostavlja kao najranjivija tačka cjelokupne web infrastrukture, stoga se posebna pažnja mora posvetiti sigurnosti nginxa.

Ovaj članak je neka vrsta obrazovnog programa, ili, ako želite, sažetak svih tehnika za povećanje sigurnosti nginxa. Neće biti teorije, opisa osnova postavljanja web servera ili bilo čega drugog. Umjesto toga, dobićete sveobuhvatan, praktični materijal koji opisuje sve osnovne korake koje trebate poduzeti da biste dobili istinski siguran web server.

Instalacija

Paket nginx dostupan je prekompajliran za bilo koju distribuciju. Međutim, ako sami napravite server, možete ga učiniti kompaktnijim i pouzdanijim, a možete i promijeniti pozdravnu liniju web servera kako biste obeshrabrili neinteligentne klince skripte.

Promijenite liniju dobrodošlice web servera

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

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

Zamijenite ih nečim poput ovoga:

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

Uklonite sve nginx module koje ne koristite

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

Izgradite sa sljedećim naredbama:

# ./configure --bez-http_autoindex_module --bez-http_ssi_module
# make
# izvrši instalaciju

Ovo će vam dati nginx sa onemogućenim SSI (Server Side Includes) i Autoindex modulima (i u većini slučajeva beskorisnim). Da biste saznali koji moduli se mogu bezbedno izbaciti sa Web servera, pokrenite skriptu za konfigurisanje sa oznakom '-help'.

Seciranje nginx.conf

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

Onemogućite prikazivanje verzije servera na svim stranicama s greškama

Dodajte red “server_tokens off” u datoteku nginx.conf. Ovo će uzrokovati da nginx sakrije tip i verziju web servera na stranicama generiranim kao odgovor na pogrešan zahtjev klijenta.

Postavite zaštitu od loma steka

Dodajte sljedeće linije u odjeljak servera:

# vi /etc/nginx/nginx.conf

# Maksimalna veličina bafera za pohranjivanje tijela zahtjeva klijenta
client_body_buffer_size 1K;
# Maksimalna veličina bafera 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 server treba da podržava otpremanje datoteka, ova vrijednost se mora povećati
client_max_body_size 1k;
# Broj i veličina bafera za čitanje velikog zaglavlja zahtjeva klijenta
large_client_header_buffers 2 1k;

Obratite pažnju na direktivu large_client_header_buffers. Podrazumevano, nginx dodeljuje četiri bafera za skladištenje URI niza, od kojih je svaki jednak veličini memorijske stranice (za x86, ovo je 4 KB). Baferi se oslobađaju svaki put kada veza uđe u stanje održavanja nakon obrade zahtjeva. Dva bafera od 1KB mogu pohraniti samo 2KB URI-je, što vam omogućava da se borite protiv botova i DoS napada.

Dodajte sljedeće linije za poboljšanje performansi:

# vi /etc/nginx/nginx.conf

# Isteklo vrijeme za čitanje tijela zahtjeva klijenta
client_body_timeout 10;
# Isteklo je tokom čitanja zaglavlja zahtjeva klijenta
client_header_timeout 10;
# Istek nakon kojeg server neće zatvoriti vezu sa klijentom
keepalive_timeout 5 5;
# Vremensko ograničenje prilikom slanja odgovora klijentu
send_timeout 10;

Kontrolirajte broj istovremenih veza

Da biste zaštitili web server od preopterećenja i pokušaja DoS-a, dodajte sljedeće linije 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 istovremenih veza za jednu sesiju. U stvari, ovaj broj postavlja maksimalan broj konekcija sa jedne IP adrese
limit_conn limits 5;

Prva direktiva bi trebala biti u odjeljku HTTP, a druga u odjeljku lokacija. Kada broj konekcija premaši ograničenja, klijent će dobiti poruku "Usluga nedostupna" sa kodom 503.

Dozvolite veze samo na svoju domenu

Hakeri mogu koristiti botove da skeniraju podmreže i pronađu ranjive web servere. Tipično, botovi jednostavno prolaze kroz IP opsege tražeći 80 otvorenih portova i šalju HEAD zahtjev da dobiju informacije o web serveru (ili početnoj stranici). Takvo skeniranje možete lako spriječiti tako što ćete onemogućiti pristup serveru putem IP adrese (dodajte u pododjeljak lokacija):

# vi /etc/nginx/nginx.conf

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

Ograničite broj dostupnih metoda za pristup web serveru

Neki botovi koriste različite metode za kontaktiranje servera kako bi pokušali odrediti njegov tip i/ili penetraciju, ali RFC 2616 jasno daje do znanja da web server ne mora implementirati sve njih, a 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 servera) i POST (zahtjev za objavljivanje dokumenta), tako da se sve ostale mogu bezbolno onemogućiti postavljanjem sljedećih redova u serverski 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 baziran je na određivanju tipa klijenta (korisnički agent). Nije baš efikasan, jer većina botova oponaša potpuno legitimne pretraživače, ali u nekim slučajevima ostaje koristan:

# vi /etc/nginx/nginx.conf

# Blokirajte menadžere 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 upućivača

Ako vaša stranica objavljuje web dnevnike u javnom domenu, lako možete postati žrtva neželjene pošte Referrera (kada spam botovi kontaktiraju vaš server, navodeći adresu oglašene stranice u zaglavlju upućivača). Ova vrsta neželjene pošte može lako pokvariti SEO rangiranje web stranice, pa 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 lokacija.

# vi /etc/nginx/nginx.conf

# Server odjeljak
if ($ http_referer ~ * (bebe | na prodaju | djevojka | nakit | ljubav | nudit | organski | poker | porn | seks | tinejdžeri))
{
povratak 403;
}

Blokirajte hotlink

Hotlink je uključivanje slike (ili drugog sadržaja) sa druge stranice na stranicu. U stvari, ovo je krađa, jer sliku na koju ste potrošili više od jednog sata svog slobodnog vremena ne samo da slobodno koriste drugi, već i stvara opterećenje na vašem web serveru 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 upućivanje mora sadržavati naziv vaše stranice). Dodajte sljedeće redove u odjeljak servera 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 server da služi posebnu poruku o krađi umjesto tražene slike. Da biste to učinili, zamijenite red "return 403" sa redom:

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

Zaštitite važne direktorije od stranaca

Kao i svaki drugi web server, nginx vam omogućava da regulišete pristup direktorijumu na osnovu IP adresa i lozinki. Ova funkcija se može koristiti za zatvaranje nekih dijelova stranice od znatiželjnih očiju. Na primjer, da uklonite URI iz vanjskog svijeta:

# vi /etc/nginx/nginx.conf

lokacija / uploads / (
# Dozvoli pristup samo mašinama na lokalnoj mreži
dozvoli 192.168.1.0/24;
# Šivanje svih ostalih
poricati sve;
}

Sada će samo korisnici lokalne mreže imati pristup dokumentima direktorija za otpremanje. Da biste postavili lozinku, morat ćete uraditi složenije korake. Prvo morate kreirati 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 se mogu 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 kreditnih kartica, lozinke sa drugih servisa, ili pruža pristup drugim važnim informacijama koje mogu postati poslastica za treće strane, pobrinite se za šifriranje. 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 kreirati 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

server (
server_name host.com;
slušaj 443;
ssl on;
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 ponovo pokrenuti web server:

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

Naravno, bez podrške same web stranice, nema smisla ovo raditi.

druge metode

Postavite ispravne vrijednosti za sistemske varijable

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

# 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ći izvorno rutiranje
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 bafera
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 servera na namjensku particiju

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

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

Stavite nginx u chroot / jail okruženje

Svaki moderni * nix sistem vam omogućava da zaključate aplikaciju u izolovanom 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 mnogo krhkiji, može zaustaviti većina krekera.

Postavite SELinux pravila za zaštitu nginxa

Lokalni sistemi za detekciju i prevenciju upada kao što su SELinux ili AppArmor su dobre alternative za izvođenje u zaštićenom okruženju. Kada su ispravno konfigurisani, mogu spriječiti pokušaje kompromitiranja web servera. Prema zadanim postavkama, nijedan od njih nije konfiguriran da radi u sprezi sa nginxom, već unutar projekta SELinuxNginx(http://sf.net/projects/selinuxnginx/) pravila su kreirana za SELinux koja svako 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
# make
# / usr / sbin / semodule -i nginx.pp

Konfigurišite zaštitni zid

Obično se nginx instalira na namenske mašine koje su spremne za velika opterećenja, tako da često ostaje jedina mrežna usluga koja radi na serveru. Da biste osigurali server, dovoljno je kreirati vrlo mali skup pravila koja će otvoriti portove 80, 110 i 143 (ako, naravno, nginx treba da radi i kao IMAP/POP3 proxy) i zatvoriti sve ostalo iz vanjskog svijeta .

Ograničite broj veza sa zaštitnim zidom

Za laganu web lokaciju, dobra je ideja ograničiti broj pokušaja povezivanja s jedne IP adrese u minuti. Ovo 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 stanje --stanje NOVO -m nedavno --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m stanje --stanje NOVO -m nedavno --ažuriranje \
--sekunde 60 --broj pogodaka 15 -j DROP

Pravila smanjuju ograničenje broja konekcija sa jednog IP-a u minuti na 15. Isto se može učiniti koristeći pf:

# vi /etc/pf.conf

webserver_ip = "1.1.1.1"
sto uporno
blokiraj brzo iz
proslijediti na $ ext_if proto tcp na $ webserver_ip \
port www zastavice S / SA zadrži stanje \
(max-src-conn 100, max-src-conn-rate 15/60, \
preopterećenja flush)

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

PHP setup

Ako koristite nginx zajedno sa PHP-om, ne zaboravite da ga konfigurišete. Ovako bi trebao izgledati konfiguracijski fajl sigurnog servera /etc/php/php.ini:

# vi /etc/php/php.ini

# Onemogućite opasne funkcije
disable_functions = phpinfo, system, mail, exec
# Maksimalno vrijeme izvršavanja skripte
max_execution_time = 30
# Maksimalno vrijeme koje skripta može potrošiti na obradu podataka zahtjeva
max_input_time = 60
# Maksimalna količina memorije dodijeljena svakoj skripti
memory_limit = 8M
# Maksimalna veličina podataka poslatih skripti pomoću POST metode
post_max_size = 8M
# Maksimalna veličina učitanih fajlova
upload_max_filesize = 2M
# Ne prikazuj greške PHP skripte korisnicima
display_errors = Isključeno
# Uključite Safe Mode
safe_mode = Uključeno
# Omogućite SQL siguran način rada
sql.safe_mode = Uključeno
# Dozvoli izvršavanje vanjskih naredbi samo u ovom direktoriju
safe_mode_exec_dir = / putanja / 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čci

Primjenom smjernica navedenih u ovom članku, imat ćete mnogo sigurniji web server. Ali imajte na umu da sve tehnike neće odgovarati vašoj konfiguraciji. Na primjer, brute force zaštita zasnovana na smanjenju veličine bafera dodijeljenih od strane nginxa za obradu zahtjeva klijenata 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 heroju dana

Nginx je jedan od najmoćnijih i najpopularnijih web servera na svijetu. Prema Netcraftu, koristi se za napajanje više od 12 miliona web stranica širom svijeta, uključujući Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusek i Taba.ru. Kompetentna arhitektura zasnovana na multipleksiranju konekcija koristeći sistemske pozive select, epoll (Linux), kqueue (FreeBSD) i mehanizam za upravljanje memorijom baziran na skupovima (mali baferi od 1 do 16 KB), omogućava nginx-u da ne pada čak i pod vrlo velikim opterećenjem , izdržava preko 10.000 istovremenih veza (tzv. C10K problem). Originalno je napisao Igor Sysoev za Rambler i otvoren 2004. pod licencom sličnom BSD-u.

U kontaktu sa

Nginx? Svrha, karakteristike, opcije prilagođavanja su stvari s kojima bi svaki web programer trebao biti upoznat kako bi testirao svoje najbolje prakse.

Recimo koju riječ o nginxu

Ovaj alat ima jedan glavni i nekoliko tokova rada. Prvi se bavi čitanjem i provjerom konfiguracije. Takođe kontroliše vođenje radnih procesa. Zadatak potonjeg je da obradi dolazne zahtjeve. Nginx koristi model zasnovan na događajima. Takođe koristi mehanizme zavisne od operativnog sistema za postizanje efikasne distribucije zahteva direktno između radnih procesa. Njihov broj je uvijek naveden u konfiguracijskoj datoteci. Vrijednost može biti fiksna ili postavljena automatski, vođena brojem procesorskih jezgara s kojima možete raditi. U nginxu, sistem i moduli se konfigurišu pomoću konfiguracione datoteke. Stoga, ako je potrebno nešto promijeniti, onda je potrebno to tražiti. Obično se nalazi u direktivi / etc / nginx (ali putanja se može promijeniti kada se koriste drugi sistemi) i ima ekstenziju .conf.

Pokretanje, ponovno pokretanje i evidencija

Da biste to učinili, morate pokrenuti izvršni fajl da radi. Nginx server se može konfigurisati samo kada je pokrenut. Kontrola se vrši pozivanjem izvršne datoteke s parametrom -s. Da biste to učinili, koristite sljedeći unos:

nginx -s signal

U ovom slučaju, možete zamijeniti sljedeće naredbe (moraju doći od korisnika koji je pokrenuo alat):

1. Stani. Koristi se za brzo gašenje.
2. Ponovo učitaj. Komanda je potrebna za ponovno učitavanje konfiguracijske datoteke. Poenta je da se nikakve 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 konfiguracijskog fajla i pokušati primijeniti upute koje se tamo nalaze. Ako ne uspije, poništit će promjene i raditi sa starim parametrima. Ako je sve prošlo kako treba, onda će se pokrenuti novi radni procesi, a starim će se poslati zahtjev da završe.
3. Prestani. Koristi se za glatko gašenje. Koristi se ako je potrebno čekati dok se trenutni zahtjevi ne završe sa servisiranjem.
4. Ponovo otvori. Zatvorite i otvorite datoteke dnevnika.

Korištenje uslužnih programa

Procesi se također mogu konfigurirati korištenjem Unix alata (uslužni program kill će se uzeti u obzir kao primjer). Obično koriste mehanizam za slanje signala procesu direktno sa 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 informacije:

kill -s NAPUSTI 1628

Recimo da želimo vidjeti listu svih pokrenutih datoteka. Za ovo koristimo uslužni program ps. Naredba će izgledati ovako:

ps -ax | grep nginx

Odnosno, kao što vidite, kada se koriste dodatni alati, naznačeno je da se koristi. Sada se fokusirajmo na to kako se radi nginx konfiguracija.

Struktura konfiguracijske datoteke

Instalacija i konfiguracija nginx-a uključuje rad sa modulima. Konfiguriraju se pomoću direktiva koje su navedene u konfiguracijskoj datoteci. Jednostavni su i blokovi. Prvi tip direktive sastoji se od imena i parametara, koji su razdvojeni razmacima, a njihov kraj je označen tačkom i zarezom - (;). Blok ima sličnu strukturu. Ali u ovoj direktivi, umjesto završetka, stavlja se skup dodatnih instrukcija, koje se stavljaju u vitičaste zagrade ((uputstva)). Ako se u njih mogu smjestiti imena i parametri drugih procesa, onda se takve konstrukcije nazivaju kontekstom. Primjeri uključuju http, lokaciju i server.

Posluživanje statičkog sadržaja

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

Implementacija: server

Dakle, prvo trebamo kreirati same direktorije i u njih smjestiti datoteke sa potrebnim ekstenzijama (sadržaj se mora dodati u html). Zatim otvaramo konfiguracijski fajl. Podrazumevano, već ima nekoliko serverskih blokova, koji su uglavnom komentarisani. Da bi se postigao najbolji rezultat, ovaj proces se mora obaviti s obzirom na sve zadane komponente. Zatim dodajemo novi blok servera sa sljedećim kodom:

Konfiguracijski fajl može raditi s nekoliko takvih blokova. Ali treba da se razlikuju po nazivima i portovima preko kojih se primaju podaci.

Realizacija: lokacija

Definirano unutar servera:

Prisustvo znaka "/" je neophodno da bismo uporedili primljene podatke i videli da li postoji takva adresa iz obrađenog zahteva ovde. Ako nema problema, tada ukazujemo na putanju / podatke / www do potrebne datoteke koja se nalazi na ovom lokalnom sistemu. Ako postoji podudaranje s nekoliko blokova, tada se odabire onaj s najdužim prefiksom. U datom primjeru njegova dužina je jednaka jedan, odnosno koristit će se isključivo ako nema "konkurenta". A sada da ga poboljšamo:

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 serveru se lako može pristupiti na lokalnom računalu ako odete na adresu: http: // localhost /. Kako će sve ovo funkcionirati?

Kako primjer funkcionira

Dakle, kada stignu zahtjevi koji počinju sa / slike, server će poslati fajlove iz odgovarajućeg direktorija korisniku. Ako ga nema, bit će proslijeđene informacije koje ukazuju na grešku 404. Ako je nginx konfiguriran na lokalnom računalu, tada ćemo na zahtjev http: //localhost/images/example.png dobiti datoteku čija je lokacija /data/images/ primjer.png. Ako navedete jedan znak "/", pretraga će se izvršiti u / data / www direktoriju. Ali promijenili smo samo konfiguraciju. Da bi počeo da radi, potrebno ga je ponovo pokrenuti. Da biste to učinili, koristite naredbu za ponovno učitavanje nginx -s. Ako normalan rad nije moguć, tada u datotekama error.log i access.log koje se nalaze u direktivi /usr / local / nginx / logs možete potražiti uzrok kvara.

Kreiranje jednostavnog proxy servera

Što se nginxa tiče, konfigurisanje ovog objekta je jedna od najčešćih upotreba (i prilično jednostavna, usput rečeno). Koristi princip servera koji prihvata zahtjev, a zatim ih preusmjerava na potrebne stranice. Nakon toga se od njih očekuje odgovor koji ih upućuje na onoga ko je postavio zadatak. Pogledajmo primjer kreiranja bazne tačke. Služit će zahtjeve korisnika i pružiti im slike iz lokalnog direktorija. Dakle, dodajte još jedan server u http blok sa sljedećim sadržajem:

Sada da dešifrujemo za vas: kreira se jednostavan server. Slušaće Ne specificirajte slušanje, tada će server raditi na 80. Svi zahtjevi unutar lokalnog sistema datoteka koji su usmjereni na /data /up1 direktorij će biti prikazani (naravno, morat će biti kreiran prije toga). Da biste to mogli provjeriti, morate tamo postaviti datoteku index.html. Postavljanjem root direktive u kontekst servera, moći ćemo koristiti lokaciju pod bilo kojim uvjetima (pošto ovo uklanja ograničenja pristupa). Sada radimo na kreiranju proxy servera. Da bi to funkcioniralo, potrebna nam je proxy_pass direktiva, za koju će protokol, ime i port objekta biti specificirani kao parametri (sa lokalnom vezom, ovo će izgledati kao http: // localhost: 8080). Dobijate 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 sa tipičnim ekstenzijama slika. Malo drugačije, moglo bi se prikazati na ovaj način:

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

root / podaci / slike;

Konačna konfiguracija proxyja izgleda ovako:

proxy_pass http: // localhost: 8080 /;

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

root / podaci / slike;

Filtrirat će zahtjeve koji imaju specificirane ekstenzije na kraju i poslati ih onome tko je tražio datoteke. Ne zaboravite da ako želite provjeriti konfiguracijsku datoteku, morat ćete je ponovo učitati. I vjerujte mi, ovo je najjednostavnija nginx postavka. Ako otvorite konfiguracijsku datoteku Vkontakte servera ili druge velike kompanije, oni će imati više koda nego što ima riječi u ovom članku.

Jedan od najpopularnijih web servera

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

Hijerarhija imenika

Sve konfiguracijske datoteke servera nalaze se u direktoriju / etc / nginx. Osim toga, postoji još nekoliko foldera unutar direktorija, kao i modularni konfiguracijski fajlovi.

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

Ako ste koristili Apache, trebali biste biti upoznati sa direktorijumima za koje su omogućene i dostupne stranice. Oni određuju konfiguraciju lokacija. Generirane datoteke se pohranjuju u zadnji direktorij. Fascikla sa omogućenim lokacijama potrebna je za pohranjivanje konfiguracija samo aktiviranih stranica. Da biste ih povezali, potrebna vam je simbolička veza između foldera. Konfiguracije se također mogu pohraniti u conf.d direktorij. Istovremeno, tokom pokretanja Nginxa, svaki fajl sa ekstenzijom .conf će se ponovo čitati. Prilikom pisanja konfiguracijskih datoteka, upišite ispravno kod i slijedite sintaksu. Svi ostali fajlovi se nalaze u / etc / nginx. Konfigurator sadrži informacije o specifičnim procesima, kao i dodatne komponente.

Glavni Nginx konfiguracijski fajl je nginx.conf.

Čita sve konfiguracijske datoteke, spajajući ih u jednu, koja se zahtijeva kada se server pokrene. Otvorite fajl sa:

sudo nano /etc/nginx/nginx.conf

Na ekranu će se pojaviti sljedeće linije:

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

Prvi je pregled Nginxa. Izraz korisnik www-data odnosi se na korisnika koji pokreće server. Direktiva pid označava gdje se nalaze interni PID procesi. Red worker_processes pokazuje koliko procesa Nginx može pokrenuti u isto vrijeme. Osim toga, ovdje možete specificirati dnevnike (na primjer, dnevnik grešaka je definiran korištenjem error_log direktive). Ispod je odjeljak o događajima. Potreban je za rukovanje serverskim vezama. Nakon toga je http blok.

Struktura Nginx konfiguracijske datoteke

Razumijevanje strukture formatiranja datoteka pomoći će vam da bolje razumijete konfiguraciju vašeg web servera. Podijeljen je na blokove. Detalji konfiguracije http bloka su slojeviti pomoću privatnih blokova. Oni nasljeđuju svojstva od svog roditelja, tj. onaj u kojem se nalaze. Ovaj blok pohranjuje većinu konfiguracija servera. Podijeljeni su na blokove servera, unutar kojih se nalazi lokacija.

Prilikom konfigurisanja vašeg Nginx servera, zapamtite da što je niži blok konfiguracije, to će manje stavki naslijediti svojstva, i obrnuto. Datoteka sadrži veliki broj opcija koje mijenjaju rad servera. Možete podesiti kompresiju datoteka koje se šalju klijentu, na primjer. Da biste to učinili, upišite parametre:

gzip on;
gzip_disable "msie6";

Imajte na umu da isti parametar može poprimiti različite vrijednosti u različitim blokovima. Prvo ga postavite na vrh, a zatim nadjačajte parametar na potrebnom nivou. Ako se posljednja radnja ne izvrši, program će postaviti vrijednosti u automatskom načinu rada.

Posljednji redovi datoteke nginx.conf su:

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

Oni ukazuju na to da su lokacija i blokovi servera pohranjeni izvan ove datoteke. Oni definiraju postavke za URL-ove i određene datoteke. Ova struktura je neophodna za održavanje modularne konfiguracijske strukture. Unutar njega, moći ćete kreirati nove direktorije, datoteke za različite stranice. Osim toga, možete grupirati slične datoteke. Nakon pregleda, možete zatvoriti datoteku nginx.conf.

Virtuelni blokovi

Oni su analogni virtuelnim hostovima u Apache-u. Blokovi sekcije servera uključuju karakteristike pojedinačnih lokacija koje se nalaze na serveru. U fascikli „Sites-available“ pronaći ćete zadanu datoteku bloka servera. Unutar njega, izvan njega možete pronaći potrebne podatke koji mogu biti potrebni pri održavanju stranica.

cd stranice-dostupne
sudo nano default
server (
root / usr / share / nginx / www;
index index.html index.htm;
server_name localhost;
lokacija / (
try_files $ uri $ uri / /index.html;
}
lokacija / doc / (
alias / usr / share / doc /;
autoindex on;
dozvoli 127.0.0.1;
poricati sve;
}
}

U gornjem primjeru, komentar je namjerno uklonjen. Ovo je urađeno radi čitljivosti. Unutar blokova servera 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 razdvaja redove ili direktive jednu od druge tačkom i zarezom. Ako ne stavite znak interpunkcije, nekoliko redova će se čitati kao jedan. Da biste napisali pravila koja će se koristiti kao indeks, koristite direktivu indeksa. Server ć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, server će tražiti index.htm.

Pravilo imena_servera

Sadrži listu imena domena koje će obraditi blok servera. Možete ih napisati bilo koji broj, odvajajući ih razmacima. Ako stavite * na kraj ili početak domene, moći ćete navesti ime sa maskom. Zvjezdica odgovara dijelu imena. Ako registrujete * .com.ua, tada će sve adrese navedene domenske zone biti uključene ovdje. Ako adresa odgovara opisu nekoliko direktiva, onda će odgovoriti onom koja se u potpunosti uklapa. Ako nema podudaranja, odgovor će biti najduže ime koje ima masku. U suprotnom, regularni izrazi će biti upareni. Imena servera koji koriste regularne izraze počinju sa tildom (~).

Lokacijski blokovi

Sljedeći u redu imat ćemo blok lokacije. Koristi se za određivanje načina na koji se postupa s određenim zahtjevima. Ako resursi ne odgovaraju nijednom drugom bloku lokacije, tada će se direktive navedene u zagradama primijeniti na njih. Ovi blokovi mogu uključivati ​​putanju kao što je /doc /. Za uspostavljanje potpune korespondencije između uri i lokacije, koristi se znak =. Primjena tilde će odgovarati regularnim izrazima. Također možete podesiti osjetljivost velikih i malih 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 pretraga će se zaustaviti. Kada je podudaranje nepotpuno, URI će se uporediti s parametrima lokacijskih direktiva. Blok s kombinacijom ^ ~ koristi se za podudaranje URI-ja za odabir bloka. Ako ova opcija nije omogućena, server bira najbolje podudaranje i također vrši pretragu regularnog izraza. Ovo je neophodno za odabir jednog od odgovarajućih 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čeće da traži regularne izraze, a zatim po URI-ju. Paritet pretraživanja je specificiran kombinacijom znakova ^ ~.

Pravilo Try_files

To je vrlo koristan alat koji može provjeriti da li postoje datoteke određenim redoslijedom. Primjenjuje prvi odgovarajući kriterij za obradu zahtjeva. Možete koristiti napredne parametre da kontrolirate kako će server posluživati ​​zahtjeve. Konfigurator ima zadanu liniju poput ove:

try_files $ uri $ uri / /index.html;

Šta to znači? Ako dođe zahtjev koji se opslužuje od strane bloka lokacije, server će prvo pokušati obraditi uri kao datoteku. Ovo 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 ovom slučaju će se učitati zadana datoteka index.html. Pravilo try_files primjenjuje posljednji parametar kao rezervni. Zato ovaj fajl mora biti na sistemu. 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 greške:

Dodatne opcije

Ako primijenite pravilo alias-a, moći ćete, na primjer, posluživati ​​stranice u bloku lokacije izvan korijenskog direktorija. Kada su fajlovi potrebni iz doc-a, oni će biti zatraženi iz /usr/share/doc/. Osim toga, pravilo autoindeksa počinje ispisivati ​​serverske direktorije za navedenu direktivu lokacije. Ako upišete redove zabrani i dozvolite, moći ćete promijeniti pristup direktorijima.

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

Ostalo). Trenutna verzija, 0.6.x, smatra se stabilnom zbog pouzdanosti, dok se izdanja iz grane 0.7 smatraju nestabilnim. Važno je napomenuti da će se funkcionalnost nekih modula promijeniti, zbog čega se mogu promijeniti i direktive, tako da kompatibilnost unatrag u nginx-u do verzije 1.0.0 nije zagarantovana.

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

Zašto je Apache loš?

Prvo, morate objasniti kako mrežni serveri općenito rade. Oni koji su upoznati sa mrežnim programiranjem znaju da u suštini postoje tri modela rada servera:

1. Dosljedno. Server otvara utičnicu za slušanje i čeka da se pojavi veza (u blokiranom je stanju dok čeka). Kada veza stigne, server je obrađuje u istom kontekstu, zatvara vezu i ponovo čeka vezu. Očigledno, 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). Server otvara utičnicu za slušanje. Kada veza stigne, ona je prihvata, a zatim kreira (ili uzima iz grupe prethodno kreiranih) novi proces ili nit koja može raditi sa vezom koliko god je potrebno, a po završetku posla izlazi ili se vraća do bazena. Glavna nit je u međuvremenu spremna da prihvati novu vezu. Ovo je najpopularniji model jer je relativno jednostavan za implementaciju, omogućava složene i dugotrajne proračune za svakog klijenta i koristi sve dostupne procesore. Primjer njegove upotrebe je Apache web server. Međutim, ovaj pristup ima i nedostatke: sa velikim brojem istovremenih veza, stvara se mnogo niti (ili, još gore, procesa), a operativni sistem troši mnogo resursa na prebacivanje konteksta. Posebno je loše kada kupci jako sporo prihvataju 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. Server radi unutar jedne niti, ali koristi neblokirajuće utičnice i mehanizam prozivanja. One. server pri svakoj iteraciji beskonačne petlje bira iz svih soketa onaj koji je spreman za primanje/slanje podataka pomoću poziva select (). Nakon što je socket odabran, server mu šalje podatke ili ih čita, ali ne čeka potvrdu, već prelazi u početno stanje i čeka događaj na drugom soketu, ili obrađuje sljedeći, u kojem se događaj dogodio tokom obrada prethodnog. Ovaj model vrlo efikasno koristi procesor i memoriju, ali je prilično težak za implementaciju. Osim toga, u okviru ovog modela, obrada događaja na soketu mora biti vrlo brza - u suprotnom će se mnogi događaji akumulirati u redu čekanja i na kraju će se on preliti. Ovako radi nginx. Osim toga, omogućava vam pokretanje više radnih procesa (zvanih radnici), tj. može koristiti više procesora.

Dakle, zamislite sledeću situaciju: 200 klijenata sa 256 Kbps kanalom je povezano na HTTP server sa 1 Gbps kanalom:

Šta se dešava u slučaju Apača? Kreira se 200 niti/procesa koji relativno brzo generišu sadržaj (mogu biti i dinamičke stranice i statički fajlovi koji se čitaju sa diska), ali ga polako daju klijentima. Operativni sistem mora da se nosi sa gomilom niti i I/O zaključavanjima.

U takvoj situaciji, Nginx troši red veličine manje OS i memorijskih resursa na svaku vezu. Međutim, ovo otkriva ograničenje nginx mrežnog modela: on ne može generirati dinamički sadržaj unutar sebe, budući da ovo ć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 server (na primjer, isti Apache) ili na FastCGI server.

Razmotrimo mehanizam rada nginx bundle-a kao "glavnog" servera i Apache-a kao servera 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 indikatori napretka učitavanja datoteka obično "lome" - međutim, moguće ih je popraviti pomoću modula upload_progress treće strane (to će zahtijevati modifikaciju 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 nginx-u, koji ga baferuje u memoriju ili privremenu datoteku. U međuvremenu, Apache oslobađa resurse. Nadalje, nginx polako šalje sadržaj klijentu, trošeći redove veličine manje resursa nego Apache.

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

Instalacija

Jer nginx tek počinje da dobija na popularnosti, postoje neki problemi sa binarnim paketima, pa budite spremni da ga sami prevedete. Ovo obično nije problem, samo trebate pažljivo pročitati izlaz naredbe. / Konfigurirajte --help i odaberite opcije kompilacije koje su vam potrebne, na primjer:

./configure \
--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
—Sa-http_ssl_module —sa-http_gzip_static_module —sa-http_stub_status_module \ # lista 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 Gentoo-u možete koristiti ebuild iz standardnog stabla portova; u RHEL / CentOS epel repozitorijum (gde se nalazi nginx 0.6.x) ili srpm za verziju 0.7, koji se može preuzeti odavde: http://blogs.mail.ru/community/nginx; na Debianu, možete koristiti nginx paket iz nestabilne grane.

Konfiguracijski fajl

Nginx konfiguracioni fajl je veoma zgodan i intuitivan. Obično se zove nginx.conf i nalazi se u $ prefiks /conf / ako lokacija nije redefinisana tokom kompilacije. Volim da ga stavim u / etc / nginx /, kao i programeri svih gore navedenih paketa.

Struktura konfiguracijskog fajla je sljedeća:

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

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

# opis servera (ovo je ono što apache naziva VirtualHost)
server (
# adresa i ime servera
slušaj *: 80;
server_name aaa.bbb;

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

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

# drugi server
server (
slušaj *: 80;
server_name ccc.bbb;

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

Imajte na umu da se svaka direktiva mora završavati tačkom i zarezom.
Reverse proxying i FastCGI

Dakle, gore smo ispitali prednosti frontend + backend šeme, shvatili instalaciju, strukturu i sintaksu konfiguracijskog fajla, 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 / biće proksi serveru 1.2.3.4, port 8080. Ovo može biti ili apache ili bilo koji drugi http server.

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 (generirajte pogrešne preusmjeravanja i apsolutne veze, respektivno). Da biste izbjegli ove probleme bez ponovnog pisanja aplikacije, čini mi se da je sljedeća konfiguracija zgodna:
Nginx sluša eksterni interfejs na portu 80.

Ako se backend (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:

server (
slušaj 4.3.2.1:80;
# postavite zaglavlje Host i X-Real-IP: za svaki zahtjev koji se šalje backendu
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
}

Da bi aplikacija razlikovala IP adrese posjetitelja, potrebno je ili instalirati modul mod_extract_forwarded (ako ga izvršava Apache server) ili modificirati aplikaciju tako da preuzima informacije o IP adresi korisnika sa X- Real-IP HTTP zaglavlje.

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

server (
<…>

# lokacija na koju će se slati zahtjevi za php-skripte
lokacija ~ .php $ (
fastcgi_pass 127.0.0.1:8888; # definirajte adresu i port fastcgi servera,
fastcgi_index index.php; # ... indeksni fajl

# i neke parametre koje treba proslediti fastcgi serveru da bi razumeo koju skriptu i sa kojim parametrima da izvrši:
fastcgi_param SCRIPT_FILENAME / usr / www / html $ fastcgi_script_name; # ime skripte
fastcgi_param QUERY_STRING $ query_string; # string 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 lokacije sa regularnim izrazima imaju visok "prioritet", svi ne-php zahtjevi će ići ovdje.

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

Statika

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

U konfiguracionom fajlu to izgleda ovako:

server (
slušaj *: 80;
server_name myserver.com;

Lokacija / (
proxy_pass


"> Http://127.0.0.1:80;

}

# pretpostavimo da su svi statički fajlovi u / fajlovima
lokacija / fajlovi / (
root / var / www / html /; # odredite putanju do fs
ističe 14d; # dodajte zaglavlje Expires:
error_page 404 = @back; # i ako datoteka nije pronađena, pošaljite je na imenovanu lokaciju @back
}

# zahtjevi iz / fajlova, za koje nije pronađena datoteka, šalju se na pozadinu i može ili generirati željeni fajl ili prikazati lijepu poruku o grešci
lokacija @pozadi (
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, onda koristite 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, samo svi zahtjevi koji završavaju na jedan od navedenih sufiksa bit će poslani na ovu lokaciju
root / var / www / html /;
error_page 404 = @back;
}

Nažalost, nginx ne podržava asinhrono rukovanje datotekama. Drugim riječima, nginx worker je blokiran na I/O operacijama. Dakle, ako imate puno statičnih datoteka i, posebno, ako se čitaju sa različitih diskova, bolje je povećati broj radnih procesa (do broja koji je 2-3 puta veći od ukupnog broja glava na disk). To, naravno, dovodi do povećanja opterećenja na OS-u, ali ukupne performanse se povećavaju. Za rad sa tipičnom količinom statičnosti (ne baš velikim brojem relativno malih datoteka: CSS, JavaScript, slike), dovoljna su jedan ili dva toka posla.

Nastavlja se

Linkovi

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