Više od 50% prometa diljem svijeta opslužuje Apache i Nginx tehnologija.– web poslužitelji koji su otvoreni izvor. Nginx obavlja funkciju frontenda, a Apache obavlja funkciju backenda. Nginx je prvi koji prihvaća zahtjeve korisnika i na njih odgovara potrebnim sadržajem – slikama, datotekama, skriptama. Heavy Apache se pak time ne bavi, već obrađuje dinamiku. Nginx proxy zahtjevi i povratni odgovori. Ova kombinacija je izvrsna za velike stranice koje posjećuje veliki broj korisnika. Za male stranice ova gomila neće povećati produktivnost. Apache i Nginx općenito smanjuju opterećenje poslužitelja zbog činjenice da Nginx obrađuje statični sadržaj, dok Apache obrađuje dinamički sadržaj.

Apache i Nginx ne bi se trebali smatrati međusobno zamjenjivim tehnologijama, iako imaju mnogo sličnih značajki. Svaki web poslužitelj ima svoje prednosti i njegova upotreba ovisi o zadatku koji se radi. U ovom članku Pogledajmo svaku tehnologiju ovisno o opsegu primjene.Članak će biti koristan vlasnicima virtualnih i namjenskih fizičkih poslužitelja.

Funkcionalan i brz, Nginx je izdan 2004. godine i nakon ovog izdanja počeo je dobivati ​​svoju popularnost. Zbog svoje male težine i skalabilnosti, dobro radi na bilo kojem hardveru. Nginx se koristi na dva načina: kao web poslužitelj ili kao proxy.

Što Nginx radi kao web poslužitelj?

• automatski stvara deskriptore predmemorije i popise datoteka, održava indeksne datoteke i statički upiti;
• ubrzava toleranciju na pogreške, proxy i balansiranje opterećenja;
• predmemorira s FastCGI i ubrzava proxy;
• podržava SSL;
• podržava Perl;
• ima filtere i modularnost;
• autentificira HTTP i filtrira SSL.

Kao Nginx proxy:

• potpuno pružanje StartTLS i SSL;
• jednostavnost autentifikacije (USER/PASS, LOGIN);
• koristi vanjski HTTP poslužitelj za preusmjeravanje na POP3/IMAP pozadinu.

Kao što vidite, Nginx obavlja mnoge funkcije bez preopterećenja sustava. Prema službenim podacima, tehnologiju koristi više od 56 milijuna stranica diljem svijeta (na primjer, Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), ali Nginx je inferioran Apache u popularnosti. Zašto je Apache toliko popularan?

Apache web poslužitelj – više platformi softver, koja je nastala 1995. godine. Zahvaljujući opsežnoj dokumentaciji i dobroj integraciji sa softverom trećih strana, Apache je stekao ogromnu popularnost. Podržava sljedeće OS - Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .

Prednosti Apache web poslužitelja:

• podrška programski jezici PHP, Python, Ruby, Perl, ASP, Tcl;
• jednostavnost povezivanja vanjskih modula;
• tehnološka podrška CGI i FastCGI;
• prisutnost mehanizama koji osiguravaju sigurnost i razlikovanje pristupa podacima;
• mogućnost korištenja DBMS-a za autentifikaciju korisnika;
• fleksibilna i pouzdana konfiguracija sustava;
• pogodan za primjene koje zahtijevaju snažan kriptografska zaštita podaci;
• mogućnost stvaranja imenici korisnika za web stranicu;
• mogućnost konfiguriranja virtualnih hostova, uz pomoć kojih na jednoj fizički poslužitelj možete stvoriti nekoliko virtualnih;
• vodi evidenciju o tome što se događa na vašem poslužitelju;
• aktivan Povratne informacije s programerima i pravovremeno rješavanje softverskih grešaka.

Ali unatoč svim prednostima Apache web poslužitelj donekle težak za postavljanje i rukovanje, tako da se neće svaki početnik moći nositi s njim. Ali ako vaš projekt treba ovaj poseban softver, onda ćete to učiniti pravi izbor u korist Apača.

Želite li osigurati PHP rad na serveru? Više detalja o ovome.

Nakon što upoznate prednosti i nedostatke Apachea i Nginxa, možete odabrati korisna rješenja za vašu web stranicu, ovisno o ciljevima kojima težite. Ali Možda će vam trebati kombinacija Apache+Nginx za postignuće najbolji rezultat. Na primjer, Nginx se često koristi prije Apachea kao obrnuti proxy. Ova vam kombinacija omogućuje rješavanje mnogih konkurentskih zahtjeva i razvrstava ih. Oni zahtjevi koje Nginx ne može obraditi šalju se Apacheu, čime se smanjuje opterećenje potonjeg. U ovom slučaju povećava se otpornost na pogreške. Prije odabira web poslužitelja potrebno je provesti obvezna testiranja performansi i mogućnosti svakog rješenja.

Za više informacija o svim tehnologijama koje HyperHost hosting podržava, posjetite.

Ovaj je članak namijenjen općem upoznavanju s mogućnostima kombiniranja Apache i Nginx web poslužitelja. Više više informacija V .

Ako trebate našu pomoć, kontaktirajte nas!

Rado ćemo odgovoriti na sva vaša pitanja o postavljanju web poslužitelja. Također uvijek možete dobiti besplatnu administraciju kod nas. Je li sve tehnička podrška hosteri su isti? O značajkama besplatne i plaćene administracije u posebnom.

17247 puta 8 puta pregledano danas

• Prijevod

NGINX je zasluženo jedan od najboljih poslužitelja po pitanju performansi, a sve to zahvaljujući svojim unutarnja struktura. Dok mnogi web i aplikacijski poslužitelji koriste jednostavan model s više niti, NGINX se izdvaja iz gomile svojom netrivijalnom arhitekturom temeljenom na događajima, koja mu omogućuje jednostavno skaliranje na stotine tisuća istodobnih veza.

Stroj stanja u NGINX-u u biti je skup uputa za obradu zahtjeva. Većina web poslužitelja obavlja istu funkciju, ali razlika je u implementaciji.

Uređaj državnog stroja

Konačni stroj može se smatrati pravilima za igranje šaha. Svaka HTTP transakcija je partija šaha. S jedne strane šahovske ploče web poslužitelj je velemajstor koji vrlo brzo donosi odluke. S druge strane je udaljeni klijent, preglednik, koji zahtijeva web mjesto ili aplikaciju preko relativno spore mreže.

Međutim, pravila igre mogu biti vrlo složena. Na primjer, web-poslužitelj će možda trebati komunicirati s drugim resursima (proxy zahtjevi za pozadinu) ili kontaktirati poslužitelj za provjeru autentičnosti. Moduli trećih strana mogu dodatno zakomplicirati obradu.

Blokiranje državnog stroja

Prisjetite se naše definicije procesa ili niti kao samostalnog skupa instrukcija koje operativni sustav može dodijeliti izvršenje određenoj procesorskoj jezgri. Većina web poslužitelja i web aplikacija koristi model u kojem igra šah s jednim procesom ili niti po vezi. Svaki proces ili nit sadrži upute za igranje jedne igre do kraja. Sve to vrijeme, proces koji se izvodi na poslužitelju provodi većinu svog vremena blokiran, čekajući sljedeći potez klijenta.

1. Proces web poslužitelja čeka nove veze (nove serije koje pokreću klijenti) na utičnicama za slušanje.
2. Nakon što je primio novu vezu, on igra igru, blokirajući nakon svakog poteza, čekajući odgovor klijenta.
3. Kada se igra igra, proces web poslužitelja možda čeka da klijent započne sljedeću igru ​​(ovo odgovara dugotrajnim vezama za održavanje). Ako je veza zatvorena (klijent je napustio ili je isteklo), proces se vraća na upoznavanje novih klijenata na utičnicama za slušanje.

Važno je napomenuti da svaka aktivna HTTP veza (svaka serija) zahtijeva poseban proces ili nit (grandmaster). Ova je arhitektura jednostavna i lako proširiva moduli trećih strana(nova “pravila”). Međutim, postoji velika neravnoteža: prilično lagana HTTP veza, predstavljena deskriptorom datoteke i malom količinom memorije, korelira s odvojeni proces ili potok, dovoljno težak predmet u operacijski sustav. Ovo je zgodno za programiranje, ali vrlo rasipno.

NGINX kao pravi velemajstor

Vjerojatno ste čuli za sesije simultane igre, kada jedan velemajstor igra na više šahovskih polja s desecima protivnika odjednom?

Kiril Georgiev je na turniru u Bugarskoj paralelno odigrao 360 utakmica. Konačni rezultat mu je bio: 284 pobjede, 70 remija i 6 poraza.

Na isti način, NGINX radni proces igra šah. Svaki radni proces (zapamtite - obično samo jedan po računalnoj jezgri) je velemajstor, sposoban igrati stotine (zapravo stotine tisuća) igara istovremeno.

1. Radnički proces osluškuje događaje na utičnicama za slušanje i utičnicama za povezivanje.
2. Događaji se događaju na utičnicama i proces ih obrađuje:
   • Događaj na utičnici za slušanje to znači novi klijent za početak igre. Radnički proces stvara novu priključnu utičnicu.
   • Događaj na konekcijskoj utičnici signalizira da je klijent napravio potez. Tijek rada odmah mu odgovara.

Obrada tijeka rada mrežni promet, nikada ne blokira, čekajući sljedeći potez protivnika (klijenta). Nakon što je proces napravio svoj potez, odmah se premješta na druge ploče gdje igrači čekaju potez ili susreću nove na vratima.

Zašto je ovo brže od blokirajuće višenitne arhitekture?

Svaka nova veza stvara deskriptor datoteke i troši malu količinu memorije u procesu rada. Ovo je vrlo nisko opterećenje veze. NGINX procesi mogu ostati vezani za određene jezgre procesora. Promjene konteksta događaju se prilično rijetko i uglavnom kada nema više posla.

Pristup blokiranja, s odvojenim procesom po vezi, zahtijeva relativno veliku količinu dodatna sredstva, a prebacivanje konteksta s jednog procesa na drugi događa se mnogo češće.

Dodatne informacije o ovoj temi također se mogu pronaći u članku o NGINX arhitekturi od Andreya Alekseeva, potpredsjednika razvoja i suosnivača NGINX, Inc.

Uz odgovarajuću konfiguraciju sustava, NGINX se dobro skalira na stotine tisuća paralelnih HTTP veza po radnom procesu i pouzdano apsorbira nalete prometa (mnoštvo novih igrača).

Ažuriranje konfiguracije i izvršnog koda

NGINX-ova arhitektura s malim brojem radnika omogućuje mu da ažurira svoju konfiguraciju, pa čak i vlastiti izvršni kod prilično učinkovito u hodu.

Ažuriranje NGINX konfiguracije vrlo je jednostavan, lagan i pouzdan postupak. Sastoji se od jednostavnog slanja SIGHUP signala glavnom procesu.

Kada radni proces primi SIGHUP, on izvodi nekoliko operacija:

1. Ponovno učitava konfiguraciju i pokreće se novi set procesi rada. Ovi novi radnički procesi odmah počinju prihvaćati veze i obrađivati ​​promet (pomoću novih postavki).
2. Signalizira stari radni proces da se elegantno završi. Prestaju prihvaćati nove veze. Čim se trenutni HTTP zahtjevi dovrše, veze se zatvaraju (nema dugotrajnih održavajućih veza). Kada se zatvore sve veze, radni proces završava.

Ovaj postupak može uzrokovati malo povećanje opterećenja procesora i memorije, ali općenito je to gotovo neprimjetno u usporedbi s troškovima obrade aktivnih veza. Konfiguraciju možete ponovno učitati nekoliko puta u sekundi (i ima dosta korisnika NGINX-a koji to rade). U rijetkim slučajevima mogu se pojaviti problemi kada previše generacija NGINX radnih procesa čeka na zatvaranje veza, ali oni se brzo rješavaju.

Ažuriraj izvršni kod NGINX je sveti gral visoka dostupnost usluge. Poslužitelj možete ažurirati u hodu, bez gubitka veze, prekida resursa ili bilo kakvog prekida u korisničkoj službi.

Nginx je popularan i moćan web poslužitelj i obrnuti proxy.

Nginx ima mnogo prednosti, ali njegove postavke su prilično složene i nisu uvijek jasne početnicima. Ovaj priručnik pomoći će vam razumjeti osnovne parametre, sintaksu i konfiguracijske datoteke Nginxa.

Bilješka: Ovaj vodič je napravljen na Ubuntu 12.04.

Nginx hijerarhija imenika

Nginx pohranjuje konfiguracijske datoteke u /etc/nginx direktorij.

Ovaj direktorij sadrži još nekoliko direktorija i modularne konfiguracijske datoteke.

cd /etc/nginx
je -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/

Korisnici Apachea već su upoznati s direktorijima dostupnih i omogućenih web-mjesta. Ovi imenici definiraju konfiguracije stranice. Datoteke se obično stvaraju i pohranjuju na dostupnim mjestima; sites-enabled pohranjuje samo konfiguracije omogućenih web stranica. Da biste to učinili, morate stvoriti simbolička veza od web-mjesta-dostupnih do web-mjesta-omogućenih.

Direktorij conf.d također se može koristiti za pohranu konfiguracija. Svaka datoteka s nastavkom .conf bit će pročitana kada se Nginx pokrene. Sintaksa takvih datoteka ne smije sadržavati pogreške.

Gotovo sve preostale datoteke pohranjene su u /etc/nginx, koji sadrži informacije o konfiguraciji za određene procese ili dodatne komponente.

Glavna Nginx konfiguracijska datoteka je nginx.conf.

nginx.conf datoteku

Datoteka nginx.conf čita odgovarajuće konfiguracijske datoteke i kombinira ih u jedna datoteka konfiguracije prilikom pokretanja poslužitelja.

Otvori datoteku:

sudo nano /etc/nginx/nginx.conf

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

Prvi redovi daju opće informacije o Nginxu. Redak korisnik www-data specificira korisnika s kojim je poslužitelj pokrenut.

Direktiva pid navodi gdje treba pohraniti Obradite PID-ove Za unutarnju upotrebu. Redak worker_processes određuje broj procesa koje Nginx može podržavati istovremeno.

Također možete navesti zapisnike u ovom dijelu datoteke (na primjer, dnevnik pogrešaka je definiran pomoću direktive error_log).

Iza opće informacije o poslužitelju slijedi odjeljak s događajima. Upravlja rukovanjem Nginx vezama. Nakon njega slijedi blok http. Prije nego što nastavimo s konfiguracijama web poslužitelja, moramo razumjeti kako je Nginx konfiguracijska datoteka formatirana.

Struktura Nginx konfiguracijske datoteke

Nginx konfiguracijska datoteka podijeljena je u blokove.

Prvi blok su događaji, zatim slijedi http i počinje glavna hijerarhija konfiguracija.

Pojedinosti o konfiguraciji http bloka slojevito su upotrebom zatvorenih blokova koji nasljeđuju svojstva od bloka u kojem se nalaze. http blok pohranjuje većinu općih Nginx konfiguracija, koje su podijeljene u blokove poslužitelja, koji su opet podijeljeni u blokove lokacije.

Tijekom Nginx postavke važno zapamtiti sljedeće pravilo: što je viša razina konfiguracije, više blokova nasljeđuje ovu konfiguraciju; što je niža razina konfiguracije, to je više "individualna". To jest, ako se parametar X mora koristiti u svakom bloku poslužitelja, tada se takav parametar mora staviti u blok http.

Ako pažljivo pogledate datoteku, primijetit ćete da sadrži mnogo opcija koje određuju ponašanje programa u cjelini.

Na primjer, da biste konfigurirali kompresiju datoteke, trebate postaviti sljedeće parametre:

gzip uključen;
gzip_onemogući "msie6";

Ovo će omogućiti gzip podršku za komprimiranje podataka poslanih klijentu i onemogućiti gzip za Internet Explorer 6 (jer ovaj preglednik ne podržava kompresiju podataka).

Ako neki parametar treba imati drugačije značenje u nekoliko blokova poslužitelja, tada se takav parametar može postaviti na vrhunska razina a zatim ga nadjačati unutar samih blokova poslužitelja. Kao rezultat toga, Nginx će izvršiti parametar najniže razine.

Ovo slojevitost konfiguracija izbjegava potrebu za upravljanjem više identičnih datoteka. Također, ako ste zaboravili definirati parametre na najniža razina, Nginx će jednostavno implementirati zadane opcije.

http blok u datoteci nginx.conf završava ovako:

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

To znači da će blokovi poslužitelja i lokacije, koji definiraju postavke za određene stranice i URL-ove, biti pohranjeni izvan ove datoteke.

To omogućuje modularnu konfiguracijsku arhitekturu u kojoj se mogu stvarati nove datoteke za posluživanje novih stranica. Također vam omogućuje grupiranje sličnih datoteka.

Zatvorite datoteku nginx.conf. Sada morate proučiti postavke pojedinačnih stranica.

Nginx virtualni blokovi

Blokovi poslužitelja u Nginxu analogni su virtualnim Apache hostovi(ali zbog praktičnosti se također nazivaju virtualni hostovi). U biti, blokovi poslužitelja jesu tehnički podaci odvojene web stranice smještene na istom poslužitelju.

U imeniku dostupnih stranica možete pronaći zadanu datoteku bloka poslužitelja koja dolazi s poslužiteljem. Ova datoteka sadrži sve potrebne podatke za održavanje stranice.

cd stranice-dostupne
sudo nano zadano

korijen /usr/share/nginx/www;
indeks indeks.html indeks.htm;
server_name localhost;
mjesto/(

}
mjesto /doc/ (

alias /usr/share/doc/;
automatsko indeksiranje uključeno;
dopusti 127.0.0.1;
zanijekati sve;

Zadana datoteka je vrlo dobro komentirana, ali u gornjem primjeru komentari su izostavljeni radi jednostavnosti i praktičnosti.

Blok poslužitelja uključuje sve postavke smještene između vitičastih zagrada:

poslužitelj (
. . .
}

Ovaj se blok postavlja u datoteku nginx.conf blizu kraja http bloka pomoću direktive include.

Korijenska direktiva određuje direktorij u koji će biti pohranjen sadržaj stranice. Nginx će u ovom direktoriju tražiti datoteke koje traži korisnik. Prema zadanim postavkama ovo je /usr/share/nginx/www.

Napomena: svi redovi završavaju točkom i zarezom. Ovo je način na koji Nginx odvaja jednu direktivu od druge. Ako nema točke sa zarezom, Nginx će pročitati dvije direktive (ili više direktiva) kao jednu direktivu s dodatnim argumentima.

Direktiva indeksa navodi datoteke koje će se koristiti kao indeks. Web poslužitelj će provjeriti datoteke redoslijedom kojim su navedene. Ako stranica nije zatražena, blok poslužitelja će pronaći i vratiti datoteku index.html. Ako ne može pronaći tu datoteku, pokušat će obraditi index.htm.

server_name direktiva

Direktiva server_name sadrži popis naziva domena koje će posluživati ​​ovaj blok poslužitelja. Broj domena je neograničen; Domene na popisu trebaju biti odvojene razmacima.

Zvjezdica (*) na početku ili kraju domene označava ime s maskom, pri čemu zvjezdica odgovara dijelu (ili više dijelova) imena. Na primjer, naziv *.example.com odgovarao bi imenima forum.example.com i www.animals.example.com.

Ako traženi url odgovara više od jedne direktive server_name, prvo će odgovoriti onom koja se točno podudara.

Ako adresa ne pronađe podudaranje, tražit će najviše dugo ime s maskom koja završava zvjezdicom. Ako ne pronađe takvo ime, vratit će prvi podudaranje regularnog izraza.

Nazivi poslužitelja koji koriste regularne izraze počinju tildom (~). Nažalost, ova tema je izvan opsega ovog članka.

Lokacijski blokovi

Lokacija/redak označava da će se direktive u zagradama primijeniti na sve tražene resurse koji ne odgovaraju nijednom drugom bloku lokacije.

Takvi blokovi mogu sadržavati uri put (na primjer /doc/). Za uspostavljanje potpunog podudaranja između lokacije i URI-ja koristi se simbol =. Znak ~ odgovara regularnim izrazima.

Tilda omogućuje način rada koji razlikuje velika i mala slova, dok tilda sa zvjezdicom omogućuje način rada koji nije osjetljiv na velika i mala slova.

Ako zahtjev u potpunosti odgovara bloku lokacije, tada poslužitelj zaustavlja pretragu i koristi takav blok. Ako poslužitelj ne pronađe potpuno odgovarajući blok lokacije, uspoređuje URI s parametrima direktiva lokacije. Nginx će odabrati blok koji koristi kombinaciju znakova ^~ i koji odgovara URI-ju.

Ako se opcija ^~ ne koristi, Nginx će odabrati najbliže podudaranje i izvršiti pretraživanje regularnog izraza kako bi pokušao pronaći podudaranje s jednim od dostupni predlošci. Ako nađe takav izraz, upotrijebi ga. Ako ne postoji takav izraz, tada poslužitelj koristi prethodno pronađeno URI podudaranje.

Kao posljednja napomena, Nginx preferira točna podudaranja. Ako nema takvih podudaranja, traži se regularni izraz a zatim pretražuje prema URI-ju. Za promjenu prioriteta pretraživanja URI-ja, koristite kombinaciju znakova ^~.

try_files direktiva

Direktiva try_files je vrlo koristan alat, koji provjerava datoteke zadanim redoslijedom i koristi prvu pronađenu datoteku za obradu zahtjeva.

To vam omogućuje korištenje dodatni parametri odrediti kako će Nginx posluživati ​​zahtjeve.

U konfiguracijska datoteka prema zadanim postavkama postoji redak:

try_files $uri $uri/ /index.html;

To znači da kada se primi zahtjev koji poslužuje blok lokacije, Nginx će prvo pokušati poslužiti uri kao datoteku (ovo ponašanje je određeno varijablom $uri).

Ako poslužitelj ne pronađe podudaranje za varijablu $uri, pokušat će koristiti uri kao direktorij.

Koristeći kosu crtu na kraju, poslužitelj provjerava postojanje direktorija, na primjer $uri/.

Ako nije pronađena datoteka ili direktorij, Nginx izvršava zadanu datoteku (u u ovom slučaju ovo je index.html u korijenskom direktoriju bloka poslužitelja). Svaka direktiva try_files koristi posljednji parametar kao zamjenu, tako da datoteka mora postojati na sustavu.

U slučaju da web poslužitelj ne pronađe podudaranje u prethodnim parametrima, može vratiti stranicu s pogreškom. Da biste to učinili, upotrijebite znak jednakosti i šifru pogreške.

Na primjer, ako lokacija/blok ne može pronaći traženi resurs, može vratiti pogrešku 404 umjesto datoteke index.html:

try_files $uri $uri/ =404;

Da biste to učinili, morate staviti znak jednakosti i postaviti šifru pogreške kao zadnji parametar (=404).

Dodatne mogućnosti

Direktiva aliasa omogućuje Nginxu posluživanje stranica bloka lokacije izvan zadanog direktorija (na primjer, izvan korijena).

Na primjer, datoteke zatražene iz /doc/ bit će poslužene iz /usr/share/doc/.

Direktiva autoindex on omogućuje vam da omogućite popis Nginx direktorija za danu direktivu lokacije.

Redovi za dopuštanje i zabranu kontroliraju pristup imenicima.

Zaključak

Web poslužitelj Nginx bogat je značajkama i vrlo je moćan, ali njegova terminologija i opcije mogu biti zbunjujuće.

Nakon što se pozabavio Nginx konfiguracije i kada naučite kako raditi s njima, dobit ćete sve prednosti ovog snažnog i laganog alata.

Oznake: ,