Hallo! Vandaag gaan we het hierover hebben het juiste concept, hoe virtuele hosts(Virtuele hosts) in de nginx-webserver. We gebruiken het Ubuntu-besturingssysteem als voorbeeld. Voor andere Linux-systemen zal de installatie erg op elkaar lijken. Dit instructieartikel is vooral interessant voor beginnende webmasters en beheerders, omdat: deze vraag hebben ze het vaakst.

Een virtuele host is...

Laten we eerst een virtuele host definiëren. Dus, virtuele host is het delen van de adresruimte van een webserver, bijvoorbeeld op sitenaam, waardoor meerdere websites/applicaties op één fysieke server kunnen draaien. In de terminologie van nginx-documentatie wordt de virtuele host ook wel "Serverblok", maar voor meer gelijkenis met Apache, zal ik het uniform noemen, aangezien hun doel is hetzelfde. En nog een conventie - laten we noemen wat we een site gaan configureren voor eenvoud.

Een virtuele host maken

Veel van de commando's in deze handleiding vereisen dat je gebruiker sudoer-rechten heeft op de VPS. Daarom, als je ze niet hebt, zul je helaas nauwelijks virtuele hosts kunnen configureren.

Vooraf ingesteld

Nu zal ik iets zeggen dat iedereen moet weten! Om een ​​virtuele host in nginx te configureren, moet de nginx-webserver op uw machine zijn geïnstalleerd. Kapitein Duidelijk is bij ons! Als je nginx al hebt geïnstalleerd, kun je deze stap veilig overslaan en de instructies volgen. Als je het om de een of andere reden nog steeds niet op je computer hebt, voer dan de opdracht in de console in:

Sudo apt-get install -y nginx

Optie "-J" we voegen toe aan het apt-get-commando om geen ja-ja-ja te antwoorden op de vervelende vragen van het installatieprogramma, omdat we er zeker van zijn dat we dit pakket willen installeren en akkoord gaan met het gebruik van de schijfruimte die het in beslag neemt. Als je nog steeds niet zeker weet of je het met alles eens bent, voeg deze optie dan niet toe.

Een sitemap maken

Laten we dus, voordat we een virtuele host maken, een sitemap maken waarin we alle bestanden zullen plaatsen waarmee onze webserver zal werken.

Het pad naar deze map in de configuratie van de host die wordt gemaakt, is: Documenthoofdmap, een soort context, een isolatiepunt, waarboven het onmogelijk is om van buitenaf te stijgen zonder voorafgaande configuratie-instellingen, en relatief ten opzichte van welke paden naar de gevraagde bestanden zijn gebouwd. Met optie "-P" voor het mkdir-commando hoeven we ons geen zorgen te maken over het maken van bovenliggende mappen, deze worden automatisch gemaakt:

Sudo mkdir -p /var/www/mysite.ru/public_html

Hier gebruiken we een echt geverifieerd DNS-domein met correcte records die naar onze machine verwijzen. Als u een virtuele host wilt maken met een niet-geregistreerd domein, bijvoorbeeld voor lokale ontwikkeling, moet u een overeenkomstige vermelding maken in het bestand / etc / hosts. Meer hierover aan het einde van het artikel.

Toegangsrechten

Nu heeft alleen de rootgebruiker rechten op onze aangemaakte map. We moeten machtigingen verlenen aan de map voor: de gewenste gebruiker, om niet constant met haar in de supergebruikersmodus te werken. U kunt de gebruiker "www-data" die hieronder wordt gebruikt, vervangen door een andere, maar standaard wordt nginx uitgevoerd als deze specifieke gebruiker.

Sudo chown -R www-data: www-data /var/www/mysite.ru/public_html

Laten we het nu zo maken dat alle gebruikers onze nieuwe bestanden kunnen lezen:

Sudo chmod 755 / var / www

Hiermee bedoelen we dat we werken met een VPS waarop alle gebruikers niets slechts doen of waar alleen jij op staat. Daarom kunnen we 755 rechten geven aan de map / var / www. Als het in uw geval onmogelijk is om alle systeemgebruikers het recht te geven om deze directory te lezen, bestudeer dan het probleem met de differentiatie van rechten en configureer het zelf.

Nu heb je alles met de rechten klaar!

Maak een pagina

Nu moeten we enkele statische bestanden (HTML-pagina's, afbeeldingen, scripts, stijlen, enz.) in onze map plaatsen die onze server zal distribueren. Laten we een HTML-pagina index.htm maken, die de hoofdpagina op onze site zal zijn:

Sudo nano /var/www/mysite.ru/public_html/index.htm

En laten we er wat opmaak aan toevoegen die aan de gebruiker wordt getoond:

Hoera! Je kon Virtual Host configureren in nginx!

Opslaan en afsluiten.

Een virtuele hostconfiguratie maken

We zijn gekomen tot het maken van een configuratiebestand voor onze nieuwe virtuele host, dat alle informatie zal bevatten over de site die nodig is voor de webserver.

In nginx, in de map / etc / nginx / sites-available, is er een sjabloon voor de gegenereerde configuraties. Laten we het kopiëren voor onze site:

Sudo cp / etc / nginx / sites-available / default /etc/nginx/sites-available/mysite.ru

Virtuele hostconfiguratie

Open een nieuw configuratiebestand en je ziet alle benodigde informatie die je moet invullen.

Sudo nano /etc/nginx/sites-available/mysite.ru

We moeten wijzigingen aanbrengen in: huidige configuratie... Als gevolg hiervan zou u voor ons eenvoudige geval zoiets als het volgende moeten krijgen:

Server (luister 80; root /var/www/mijnsite.ru/public_html; index index.html index.htm; servernaam mijnsite.ru www.mijnsite.ru;)

Hier moet u het pad correct specificeren naar de map met de statica van de site en de naam van de server waarmee u toegang krijgt tot uw site. Als u het pad onjuist of helemaal niet opgeeft, kunt u de virtuele host niet configureren. V als server _name, kunt u ook een IP-adres of meerdere namen opgeven, gescheiden door een spatie, waardoor de host beschikbaar zal zijn, zoals wij deden.

Dat is het, we zijn klaar met dit bestand. Sla het op en sluit het.

Virtuele host-activering

Nginx heeft sites-beschikbare en sites-enabled mappen. De eerste slaat de configuraties op van ALLE virtuele hosts die aan kunnen staan deze server, en in de sites-enabled directory zijn er symbolische links naar active. Niemand verbiedt op sites die geschikt zijn om het originele configuratiebestand te plaatsen, maar niet de link, maar het zal minder handig zijn, omdat als het nodig is om het uit te schakelen, moet je ofwel het bestand verwijderen (dan zal het problematisch zijn om het terug op te nemen), of het naar een andere map verplaatsen (dan moeten we onthouden waar we naartoe zijn verhuisd). Het is veel gemakkelijker om een ​​symbolische link te slaan!

Daarom moeten we nu, om onze virtuele host te activeren, een symbolische link maken tussen de sites-beschikbare map, waar ons configuratiebestand zich bevindt, en sites-enabled. Apache heeft speciaal team a2ensite. Er is geen dergelijk commando in nginx, dus laten we het volgende uitvoeren:

Sudo ln -s /etc/nginx/sites-available/mysite.ru /etc/nginx/sites-enabled/mysite.ru

Om "conflicterende servernaamfout" te voorkomen en ervoor te zorgen dat uw site wordt weergegeven: Nodige informatie, kunt u de standaard verwijderen uit het aantal actieve hosts:

Sudo rm / etc / nginx / sites ingeschakeld / standaard

Opnieuw opstarten

We hebben al veel stappen doorlopen en bijna alles is ingesteld. Laten we nu onze webserver opnieuw laden om te solliciteren nieuwe configuratie, maar voordat u dit doet, is het een goede gewoonte om te controleren of alles met de configuratie correct is en nginx het correct begrijpt. Voer hiervoor nginx diagnostics uit met de volgende opdracht:

Sudo nginx -t

Een dergelijke controle is uiterst noodzakelijk bij het configureren op productieservers, zodat het niet gebeurt dat we het herstartcommando nginx hebben aangeroepen, maar het niet kon starten vanwege een onjuiste configuratie en al onze virtuele hosts niet reageren.

Als je zoiets als dit krijgt:

Nginx: het configuratiebestand /etc/nginx/nginx.conf syntaxis is ok nginx: configuratiebestand /etc/nginx/nginx.conf test is succesvol

Dan is alles in orde met jou en kun je de server veilig herstarten met het commando:

Sudo-service nginx opnieuw opstarten

V anders je moet naar het hostconfiguratiebestand kijken. Iets wat je daar niet hebt aangegeven.

Lokale hosts configureren

Als u een IP-adres als servernaam hebt opgegeven, kunt u deze stap overslaan, aangezien: u hebt geen lokale hostconfiguratie nodig, uw virtuele host werkt zonder. Maar als u met uw virtuele host wilt werken zonder een echte domeinnaam, kunt u lokale hosts op uw machine instellen. Zoals ik hierboven al zei, is dit erg handig, bijvoorbeeld bij het ontwikkelen. Ik kan mysite.dev maken en de lokale onstabiele versie van de site zal erop worden uitgevoerd. Voer voor macOS- en Linux-systemen de volgende opdracht uit:

Sudo nano / etc / hosts

Als u onder Windows werkt, dan zou het bestand van lokale hosts ongeveer langs dit pad moeten liggen C: \ Windows \ System32 \ drivers \ etc \ hosts.

Voeg een item over de nieuwe lokale host toe aan het bestand. In ons geval moeten we twee vermeldingen toevoegen, aangezien we hebben twee domeinen gespecificeerd in servernaam.

12.34.56.789 mijnsite.ru 12.34.56.789 www.mijnsite.ru

Nu, totdat deze record is verwijderd, zullen oproepen naar mijnsite.ru informatie over deze host ontvangen van dit bestand en u doorverwijzen naar uw externe server. Als de server lokaal is geïmplementeerd, moet u "127.0.0.1" schrijven in plaats van "12.34.56.789".

Het is een goede gewoonte om hostrecords te verwijderen nadat ze hun taak hebben voltooid om toekomstige problemen te voorkomen.

resultaten

Nu kunnen we de resultaten van ons werk zien! Voer het adres http://mysite.ru of http://www.mysite.ru in de browser in en bewonder de hoofdpagina die we hebben gemaakt op basis van index.htm. Beide adressen moeten onze . tonen Startpagina... Dat is alles! Onze virtuele host werkt prima.

Nginx is een populaire en goed presterende webserver en reverse proxyserver.

Nginx heeft veel voordelen, maar de instellingen zijn behoorlijk complex en niet altijd duidelijk voor beginners. Deze handleiding zal je door de basisparameters, syntaxis en configuratiebestanden van Nginx leiden.

Opmerking: Zelfstudie gemaakt op Ubuntu 12.04.

Nginx-directoryhiërarchie

Nginx slaat configuratiebestanden op in de map / etc / nginx.

Deze map bevat nog een aantal mappen en modulaire configuratiebestanden.

cd / etc / nginx
ls -F

conf.d / koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-beschikbaar / win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled /

Apache-gebruikers zijn al bekend met de sites-beschikbare en sites-enabled directories. Deze mappen definiëren siteconfiguraties. Bestanden worden meestal gemaakt en opgeslagen op beschikbare sites; sites-enabled slaat alleen configuraties van ingeschakelde sites op. Om dit te doen, moet u een symbolische link maken van sites-beschikbaar naar sites-enabled.

De map conf.d kan ook worden gebruikt om configuraties op te slaan. Elk .conf-bestand wordt gelezen wanneer Nginx start. De syntaxis van dergelijke bestanden moet vrij zijn van fouten.

Bijna alle overgebleven bestanden worden opgeslagen in / etc / nginx, dat configuratie-informatie bevat voor specifieke processen of aanvullende componenten.

Het belangrijkste Nginx-configuratiebestand is nginx.conf.

Nginx.conf-bestand

Het bestand nginx.conf leest de juiste configuratiebestanden en voegt ze samen tot een enkel configuratiebestand wanneer de server start.

Open het bestand:

sudo nano /etc/nginx/nginx.conf

gebruiker www-gegevens;
werknemer_processen 4;
pid /var/run/nginx.pid;
evenementen (
werknemer_verbindingen 768;
# multi_accept aan;
}
http (
. . .

De eerste regels zijn ingesteld algemene informatie over Nginx. De user www-data string geeft aan met welke gebruiker de server wordt gestart.

De pid-richtlijn specificeert waar de PID's van processen worden opgeslagen voor intern gebruik. De regel worker_processes definieert het aantal processen dat Nginx gelijktijdig kan ondersteunen.

In dit deel van het bestand kunt u ook logboeken opgeven (het foutenlogboek wordt bijvoorbeeld gedefinieerd met de instructie error_log).

Algemene informatie over de server wordt gevolgd door het gedeelte evenementen. Het zorgt voor de afhandeling van Nginx-verbindingen. Het wordt gevolgd door het http-blok. Voordat u doorgaat met uw webserverconfiguraties, moet u begrijpen hoe het Nginx-configuratiebestand is geformatteerd.

Nginx-configuratiebestandsstructuur

Het Nginx-configuratiebestand is verdeeld in blokken.

Het eerste blok is events, gevolgd door http, en de hoofdconfiguratiehiërarchie begint.

De configuratiedetails van het http-blok zijn gelaagd met behulp van privéblokken die eigenschappen erven van het blok waarin ze zich bevinden. Het http-blok slaat de meeste gemeenschappelijke configuraties Nginx, die zijn onderverdeeld in serverblokken, die op hun beurt zijn onderverdeeld in locatieblokken.

Bij het configureren van Nginx is het belangrijk om de volgende regel te onthouden: hoe hoger het configuratieniveau, hoe meer blokken die configuratie zullen erven; hoe lager het configuratieniveau, hoe "individueel" het is. Dat wil zeggen, als de X-parameter in elk serverblok moet worden gebruikt, dan moet een dergelijke parameter in het http-blok worden geplaatst.

Als je goed naar het bestand kijkt, zul je merken dat het veel opties bevat die het gedrag van het programma als geheel bepalen.

Om bijvoorbeeld bestandscompressie te configureren, moet u de volgende parameters instellen:

gzip aan;
gzip_disable "msie6";

Dit zal gzip-ondersteuning inschakelen voor het comprimeren van gegevens die naar de client zijn verzonden en gzip uitschakelen voor Internet Explorer 6 (aangezien deze browser geen datacompressie ondersteunt).

Als een parameter in meerdere serverblokken een andere waarde moet hebben, dan kan zo'n parameter op het hoogste niveau worden ingesteld en vervolgens binnen de serverblokken zelf opnieuw worden gedefinieerd. Als resultaat zal Nginx de parameter op het laagste niveau uitvoeren.

Deze gelaagdheid van configuraties vermijdt de noodzaak om meerdere identieke bestanden te beheren. Als je vergeten bent om low-level parameters te definiëren, zal Nginx ook gewoon de standaard parameters uitvoeren.

Het http-blok in het nginx.conf-bestand eindigt als volgt:

inclusief /etc/nginx/conf.d/*.conf;
include / etc / nginx / sites-enabled / *;

Dit betekent dat de server- en locatieblokken die de instellingen voor specifieke sites en URL's definiëren, buiten dit bestand worden opgeslagen.

Hierdoor kan een modulaire configuratie-architectuur worden gehandhaafd waarin nieuwe bestanden kunnen worden aangemaakt om nieuwe sites te bedienen. Het stelt je ook in staat om gelijkaardige bestanden te groeperen.

Sluit het nginx.conf-bestand. Nu moet u de instellingen voor afzonderlijke sites onderzoeken.

Nginx virtuele blokken

Serverblokken in Nginx zijn analoog aan Apache virtuele hosts (maar voor het gemak worden ze ook virtuele hosts genoemd). In wezen zijn serverblokkeringen de technische kenmerken van individuele websites die op een enkele server worden gehost.

In de directory 'sites-available' vindt u het standaard serverblokbestand dat bij de server wordt geleverd. Dit bestand bevat alle gegevens die nodig zijn om de site te onderhouden.

cd-sites-beschikbaar
sudo nano standaard

root / usr / delen / nginx / www;
index index.html index.htm;
servernaam localhost;
plaats / (

}
locatie / doc / (

alias / usr / delen / doc /;
autoindex aan;
127.0.0.1 toestaan;
alles ontkennen;

Het bestand is standaard zeer goed becommentarieerd, maar in het bovenstaande voorbeeld zijn opmerkingen weggelaten voor eenvoud en gemak.

Het serverblok bevat alle instellingen, geplaatst tussen accolades:

server (
. . .
}

Dit blok bevindt zich in het bestand nginx.conf aan het einde van het http-blok met behulp van richtlijnen opnemen.

De root-richtlijn definieert de map waarin de site-inhoud wordt opgeslagen. In deze map zoekt Nginx naar bestanden die door de gebruiker zijn aangevraagd. Standaard is deze map / usr / share / nginx / www.

Houd er rekening mee dat alle regels eindigen met een puntkomma. Zo ontkoppelt Nginx de ene richtlijn van de andere. Als er geen puntkomma is, zal Nginx de twee richtlijnen (of meerdere richtlijnen) lezen als één richtlijn met aanvullende argumenten.

De index-richtlijn definieert de bestanden die als index moeten worden gebruikt. De webserver controleert de bestanden in de volgorde waarin ze worden vermeld. Als er geen pagina is opgevraagd, zal het serverblok het bestand index.html vinden en retourneren. Als het dit bestand niet kan vinden, zal het proberen index.htm te ontleden.

Instructie servernaam

De server_name-instructie bevat een lijst met domeinnamen die door dit serverblok worden bediend. Het aantal domeinen is onbeperkt; Scheid domeinen in de lijst met spaties.

Een asterisk (*) aan het begin of einde van een domein specificeert een naam met een masker, waarbij de asterisk overeenkomt met een deel (of meer delen) van de naam. Bijvoorbeeld * .example.com komt overeen met forum.example.com en www.animals.example.com.

Als de gevraagde url overeenkomt met meerdere server_name-richtlijnen, zal deze eerst reageren met degene die exact overeenkomt.

Als het adres geen overeenkomst vindt, zoekt het naar de langste gemaskeerde naam die eindigt met een asterisk. Als het zo'n naam niet vindt, retourneert het de eerste overeenkomst met normale uitdrukkingen.

Servernamen die reguliere expressies gebruiken, beginnen met een tilde (~). Helaas valt dit onderwerp buiten het bestek van dit artikel.

Locatie blokken

De locatie / regel geeft aan dat de instructies tussen haakjes van toepassing zijn op alle aangevraagde bronnen die niet overeenkomen met andere locatieblokken.

Dergelijke blokken kunnen een uri-pad bevatten (bijv. / doc /). Om een ​​volledige match tussen locatie en uri tot stand te brengen, wordt het =-symbool gebruikt. Het ~-symbool komt overeen met reguliere expressies.

De tilde maakt de hoofdlettergevoelige modus mogelijk en de tilde met een asterisk maakt de hoofdlettergevoelige modus mogelijk.

Als het verzoek volledig overeenkomt met het locatieblok, stopt de server het zoeken en gebruikt zo'n blok. Als de server geen volledig overeenkomend locatieblok vindt, vergelijkt hij de URI met de parameters van de locatierichtlijnen. Nginx selecteert een blok dat de ^ ~-tekencombinatie gebruikt en overeenkomt met de URI.

Als de ^ ~-optie niet wordt gebruikt, kiest Nginx de dichtstbijzijnde overeenkomst en voert een zoekopdracht naar reguliere expressies uit om te proberen een van de beschikbare patronen te matchen. Als hij zo'n uitdrukking vindt, gebruikt hij die. Als een dergelijke uitdrukking niet bestaat, gebruikt de server de eerder gevonden URI-overeenkomst.

Als conclusie moet worden opgemerkt dat Nginx de voorkeur geeft aan exacte matches. Als er geen overeenkomst is, zoekt het naar een reguliere expressie en zoekt het vervolgens naar de URI. Gebruik de tekencombinatie ^ ~ om de prioriteit van URI-zoekopdrachten te wijzigen.

Try_files richtlijn

De instructie try_files is erg nuttig instrument die controleert op het bestaan ​​van bestanden in de gegeven volgorde en het eerste gevonden bestand gebruikt om het verzoek te verwerken.

Dit stelt je in staat om aanvullende parameters te gebruiken om te definiëren hoe Nginx verzoeken zal behandelen.

Er is een regel in het standaardconfiguratiebestand:

try_files $ uri $ uri / /index.html;

Dit betekent dat wanneer een verzoek binnenkomt dat wordt bediend door een locatieblok, Nginx eerst zal proberen de uri als een bestand te serveren (dit gedrag wordt ingesteld door de $ uri-variabele).

Als de server geen overeenkomst vindt voor de variabele $ uri, zal hij proberen de uri als directory te gebruiken.

De server gebruikt een schuine streep aan het einde om het bestaan ​​van de map te controleren, bijvoorbeeld $ uri /.

Als er geen bestand of map wordt gevonden, voert Nginx het standaardbestand uit (in dit geval index.html in de hoofdmap van het serverblok). Elke instructie try_files gebruikt de laatste parameter als een fallback, dus dit bestand moet op het systeem aanwezig zijn.

Als de webserver geen overeenkomsten heeft gevonden in de vorige parameters, kan deze een foutpagina retourneren. Hiervoor wordt een gelijkteken en een foutcode gebruikt.

Als de locatie / het blok bijvoorbeeld de gevraagde bron niet kan vinden, kan het een 404-fout retourneren in plaats van het index.html-bestand:

try_files $ uri $ uri / = 404;

Om dit te doen, moet u een gelijkteken plaatsen en de foutcode instellen als de laatste parameter (= 404).

Extra opties

Met de alias-richtlijn kan Nginx pagina's in het locatieblok buiten de opgegeven map weergeven (bijvoorbeeld buiten root).

Bestanden die zijn aangevraagd vanuit / doc / worden bijvoorbeeld geleverd vanuit / usr / share / doc /.

De autoindex op richtlijn maakt het mogelijk om Nginx-directories voor de gegeven locatierichtlijn op te sommen.

De regels voor toestaan ​​en weigeren bepalen de toegang tot mappen.

Conclusie

De Nginx-webserver is rijk aan functies en zeer performant, maar de terminologie en parameters kunnen verwarrend zijn.

Door Nginx-configuraties te begrijpen en ermee te werken, kunt u optimaal profiteren van deze krachtige en lichtgewicht tool.

Een van de meest populaire webservers

Nginx is erg populair onder gebruikers van web- en proxyservers vanwege de prestaties. De server heeft veel voordelen, maar het kan voor een beginner moeilijk zijn om op te zetten. We willen je helpen de configuratiebestanden, syntaxis en basis Nginx-instellingen te achterhalen.

Directory hiërarchie

Alle serverconfiguratiebestanden bevinden zich in de map / etc / nginx. Daarnaast zijn er nog verschillende mappen in de map, evenals modulaire configuratiebestanden.

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

Als je Apache hebt gebruikt, zou je bekend moeten zijn met de mappen die zijn ingeschakeld en beschikbaar zijn voor sites. Zij bepalen de configuratie van de sites. De gegenereerde bestanden worden opgeslagen in de laatste directory. De site-enabled map is nodig om configuraties van alleen geactiveerde pagina's op te slaan. Om ze te koppelen heb je een symbolische link tussen de mappen nodig. Configuraties kunnen ook worden opgeslagen in de map conf.d. Tegelijkertijd wordt tijdens het opstarten van Nginx elk bestand met de extensie .conf opnieuw gelezen. Typ bij het schrijven van configuratiebestanden de code correct en volg de syntaxis. Alle andere bestanden bevinden zich in / etc / nginx. De configurator bevat informatie over specifieke processen en aanvullende componenten.

Het belangrijkste Nginx-configuratiebestand is nginx.conf.

Het leest alle configuratiebestanden en voegt ze samen tot één, wat wordt gevraagd wanneer de server start. Open het bestand met:

sudo nano /etc/nginx/nginx.conf

De volgende regels verschijnen op het scherm:

gebruiker www-gegevens;
werknemer_processen 4;
pid /var/run/nginx.pid;
evenementen (
werknemer_verbindingen 768;
# multi_accept aan;
}
http (
. . .

De eerste is een overzicht van Nginx. De term user www-data verwijst naar de gebruiker die de server start. De pid-richtlijn geeft aan waar de interne PID-processen zich bevinden. De regel worker_processes laat zien hoeveel processen Nginx tegelijkertijd kan uitvoeren. Bovendien kunt u hier logboeken opgeven (het foutenlogboek wordt bijvoorbeeld gedefinieerd met behulp van de instructie error_log). Hieronder vindt u de rubriek evenementen. Het is nodig om serververbindingen af ​​te handelen. Nadat het het http-blok is.

Nginx-configuratiebestandsstructuur

Als u de structuur van de bestandsindeling begrijpt, krijgt u een beter inzicht in uw webserverconfiguratie. Het is opgedeeld in bouwstenen. De configuratiedetails van het http-blok zijn gelaagd met behulp van privéblokken. Ze erven eigenschappen van hun ouder, d.w.z. waarin ze zich bevinden. dit blok slaat de meeste serverconfiguraties op. Ze zijn onderverdeeld in serverblokken, waarbinnen de locatie zich bevindt.

Houd er bij het configureren van je Nginx-server rekening mee dat hoe lager het configuratieblok is, hoe minder items eigenschappen zullen erven en vice versa. Het bestand bevat een groot aantal opties die de werking van de server veranderen. U kunt bijvoorbeeld de compressie instellen van bestanden die naar de client worden verzonden. Schrijf hiervoor de parameters:

gzip aan;
gzip_disable "msie6";

Houd er rekening mee dat dezelfde parameter in verschillende blokken verschillende waarden kan aannemen. Stel deze eerst bovenaan in en overschrijf vervolgens de parameter op het vereiste niveau. Indien laatste actie niet uitvoeren, zal het programma de waarden in de automatische modus instellen.

De laatste regels van het bestand nginx.conf zijn:

inclusief /etc/nginx/conf.d/*.conf;
include / etc / nginx / sites-enabled / *;

Ze geven aan dat de locatie- en serverblokken buiten dit bestand worden opgeslagen. Ze definiëren de instellingen voor url's en specifieke bestanden. Deze structuur is nodig om een ​​modulaire configuratiestructuur te behouden. Daarin kun je nieuwe mappen, bestanden voor verschillende sites maken. Bovendien kunt u vergelijkbare bestanden groeperen. Na het bekijken kunt u het bestand nginx.conf sluiten.

Virtuele blokken

Ze zijn analoog aan virtuele hosts in Apache. De serversectieblokken bevatten de kenmerken van individuele sites die zich op de server bevinden. In de map 'sites-available' vindt u het standaard serverblokbestand. Binnenin vindt u buiten de noodzakelijke gegevens die nodig kunnen zijn bij het onderhouden van sites.

cd-sites-beschikbaar
sudo nano standaard
server (
root / usr / delen / nginx / www;
index index.html index.htm;
servernaam localhost;
plaats / (
try_files $ uri $ uri / /index.html;
}
locatie / doc / (
alias / usr / delen / doc /;
autoindex aan;
127.0.0.1 toestaan;
alles ontkennen;
}
}

In het bovenstaande voorbeeld is de opmerking opzettelijk verwijderd. Dit is gedaan voor de leesbaarheid. Binnen de serverblokken staan ​​de instellingen tussen accolades:

Dit blok wordt geplaatst met behulp van de include-instructie aan het einde van de http die is opgegeven in het bestand nginx.conf. De root-richtlijn definieert de map waarin de site-inhoud zich zal bevinden. Daarin zoekt het programma naar bestanden die de gebruiker zal opvragen. Het standaardpad is / usr / share / nginx / www. Nginx scheidt regels of richtlijnen van elkaar met puntkomma's. Als u geen leesteken plaatst, worden meerdere regels als één geheel gelezen. Gebruik de index-richtlijn om de regels te schrijven die als index zullen worden gebruikt. De server controleert ze in de volgorde waarin ze worden vermeld. Als geen van de beschikbare pagina's door de gebruiker is opgevraagd, wordt index.html geretourneerd. Als het er niet is, zoekt de server naar index.htm.

Regel voor servernaam

Het bevat een lijst met domeinnamen die door het serverblok moeten worden verwerkt. U kunt een willekeurig aantal van hen schrijven, gescheiden door spaties. Als u * aan het einde of aan het begin van een domein plaatst, kunt u een naam met een masker opgeven. Het sterretje komt overeen met een deel van de naam. Als u * .com.ua registreert, dan zijn alle adressen van de opgegeven domeinzone... Als het adres overeenkomt met de beschrijving van meerdere richtlijnen, dan zal het reageren met degene die volledig past. Als er geen overeenkomst is, is het antwoord de langste naam met een masker. Anders worden reguliere expressies gematcht. Servernamen die reguliere expressies gebruiken, beginnen met een tilde (~).

Locatie blokken

De volgende in de rij hebben we een locatieblok. Het wordt gebruikt om te bepalen hoe bepaalde verzoeken worden afgehandeld. Als de resources niet overeenkomen met andere locatieblokken, worden de richtlijnen die tussen haakjes zijn vermeld daarop toegepast. Deze blokken kunnen een pad bevatten zoals / doc /. Om een ​​volledige overeenkomst tussen uri en locatie tot stand te brengen, wordt het =-teken gebruikt. Het toepassen van de tilde komt overeen met de reguliere expressies. U kunt de hoofdlettergevoeligheid ook instellen door ~ te plaatsen. Als u een asterisk toevoegt, maakt de zaak niet uit.

Houd er rekening mee: wanneer het verzoek overeenkomt met het locatieblok, wordt het gebruikt en stopt het zoeken. Wanneer de match onvolledig is, wordt de URI vergeleken met de parameters van de locatierichtlijnen. Een blok met de combinatie ^ ~ wordt gebruikt om de URI voor de blokselectie te matchen. Indien deze optie niet gebruikt, kiest de server de beste match en zoekt ook met reguliere expressies. Dit is nodig om een ​​van de geschikte sjablonen te selecteren. Als een overeenkomende uitdrukking wordt gevonden, wordt deze gebruikt. Anders wordt de vorige URI-overeenkomst toegepast. Houd er echter rekening mee dat Nginx meer van volledige matches houdt. Als ze er niet zijn, begint het te zoeken naar reguliere expressies en vervolgens op URI. De zoekpariteit wordt gespecificeerd door de tekencombinatie ^ ~.

Try_files regel

Het is een zeer handige tool die bestanden in een bepaalde volgorde kan controleren. Het past de eerste matchingscriteria toe om het verzoek te verwerken. je kunt gebruiken Extra opties om te definiëren hoe de server verzoeken zal behandelen. De configurator heeft een standaardregel zoals deze:

try_files $ uri $ uri / /index.html;

Wat betekent het? Als er een verzoek binnenkomt dat wordt bediend door een locatieblok, zal de server eerst proberen de uri als bestand te verwerken. Dit wordt geleverd door de variabele $ uri. Als er geen overeenkomst is, wordt de uri behandeld als een map. Je kunt het bestaan ​​ervan controleren door een schuine streep aan het einde toe te voegen: $ uri /. Er zijn situaties waarin noch het bestand, noch de directory kan worden gevonden. In dit geval wordt het standaardbestand index.html geladen. De regel try_files past de laatste parameter toe als een fallback. Dat is waarom dit bestand moet in het systeem zitten. Als er echter helemaal geen overeenkomsten worden gevonden, retourneert Nginx een foutpagina. Om het in te stellen, schrijft u = en de foutcode:

Toegevoegde opties

Als u de aliasregel toepast, kunt u bijvoorbeeld pagina's in het locatieblok buiten de hoofdmap weergeven. Wanneer bestanden van doc nodig zijn, worden deze opgevraagd bij /usr /share /doc /. Bovendien begint de regel voor auto-index aan de serverdirectory's voor de opgegeven locatierichtlijn weer te geven. Als u de regels 'weigeren' en 'toestaan' schrijft, kunt u de toegang tot mappen wijzigen.

Als conclusie moet gezegd worden dat Nginx een zeer krachtige multifunctionele tool is. Maar om een ​​goed begrip te krijgen van hoe het werkt, kost tijd en moeite. Als u begrijpt hoe configuraties werken, kunt u ten volle genieten van alle functies van het programma.

Ander). Huidige versie, 0.6.x wordt als stabiel beschouwd in termen van betrouwbaarheid en releases van de 0.7-tak worden als onstabiel beschouwd. Het is belangrijk op te merken dat de functionaliteit van sommige modules zal veranderen, waardoor de richtlijnen ook kunnen veranderen, dus achterwaartse compatibiliteit in nginx tot versie 1.0.0 is niet gegarandeerd.

Waarom is nginx zo goed en waarom zijn beheerders van high-load projecten er zo dol op? Waarom gebruik je niet gewoon Apache?

Waarom is Apache slecht?

Eerst moet je uitleggen hoe ze over het algemeen werken. netwerkservers... degenen die bekend zijn met netwerk programmering weet dat er in wezen drie modellen van serverwerking zijn:

1. Consequent. De server opent een luister-socket en wacht tot er een verbinding verschijnt (deze is geblokkeerd tijdens het wachten). Wanneer een verbinding binnenkomt, verwerkt de server deze in dezelfde context, sluit de verbinding en wacht opnieuw op de verbinding. Het is duidelijk dat dit verre van het meest is De beste manier Zeker wanneer het werk met de opdrachtgever lang duurt en er veel connecties zijn. Bovendien heeft het sequentiële model nog veel meer nadelen (bijvoorbeeld het onvermogen om meerdere processors te gebruiken) en wordt het in reële omstandigheden praktisch niet gebruikt.
2. Multiprocess (multithreaded). De server opent een luisterende socket. Wanneer een verbinding arriveert, accepteert het deze, waarna het een nieuw proces of thread maakt (of uit de pool van eerder gemaakte verbindingen) die zo lang als nodig met de verbinding kan werken, en na voltooiing van het werk, afsluiten of terugkeren naar het zwembad. De rode draad is ondertussen klaar om een ​​nieuwe verbinding te accepteren. Dit is het meeste populair model, omdat het relatief eenvoudig te implementeren is, complexe en tijdrovende berekeningen voor elke klant mogelijk maakt en alles gebruikt beschikbare processors... Een voorbeeld van het gebruik ervan is de Apache-webserver. Deze benadering heeft echter ook nadelen: wanneer? een groot aantal gelijktijdige verbindingen creëren veel threads (of erger nog, processen) en het besturingssysteem verspilt veel bronnen aan context-switches. Het is vooral erg als klanten content erg traag accepteren. Het blijkt dat honderden threads of processen bezig zijn met het verzenden van gegevens naar langzame clients, wat een extra belasting voor de OS-planner creëert, het aantal interrupts verhoogt en veel geheugen verbruikt.
3. Niet-blokkerende stopcontacten / staatsmachine. De server werkt binnen een enkele thread, maar gebruikt niet-blokkerende sockets en een polling-mechanisme. Die. de server selecteert bij elke iteratie van een oneindige lus uit alle sockets degene die klaar is om gegevens te ontvangen / verzenden met behulp van de select () -aanroep. Nadat een socket is geselecteerd, verzendt de server er gegevens naar of leest deze, maar wacht niet op bevestiging, maar gaat naar de beginstatus en wacht op een gebeurtenis op een andere socket, of verwerkt de volgende waarin de gebeurtenis plaatsvond tijdens de verwerking van de vorige. Dit model gebruikt zeer efficiënt processor en geheugen, maar is nogal moeilijk te implementeren. Bovendien moet in het kader van dit model de verwerking van een gebeurtenis op een socket erg snel zijn - anders zullen veel gebeurtenissen zich in de wachtrij ophopen en uiteindelijk overlopen. Dit is hoe nginx werkt. Bovendien kunt u hiermee meerdere werkprocessen starten (werknemers genoemd), d.w.z. kan meerdere processors gebruiken.

Stel je dus de volgende situatie voor: 200 clients met een 256 Kbps-kanaal zijn verbonden met een HTTP-server met een 1 Gbps-kanaal:

Wat gebeurt er in het geval van Apache? Er worden 200 threads / processen gemaakt die relatief snel inhoud genereren (het kunnen zowel dynamische pagina's als statische bestanden zijn die van schijf worden gelezen), maar deze langzaam aan klanten geven. Het besturingssysteem heeft te maken met een heleboel threads en I/O-locks.

In een dergelijke situatie besteedt Nginx een orde van grootte minder OS- en geheugenbronnen aan elke verbinding. Hier wordt echter de beperking onthuld netwerkmodel nginx: het kan geen dynamische inhoud in zichzelf genereren, omdat dit zal leiden tot blokkering van nginx. Natuurlijk is er een oplossing: nginx kan dergelijke verzoeken (voor het genereren van inhoud) proxyen naar elke andere webserver (bijvoorbeeld dezelfde Apache) of naar een FastCGI-server.

Laten we eens kijken naar het werkingsmechanisme van de nginx-bundel als de "hoofd" server en Apache als de server voor het genereren van dynamische inhoud:

Nginx accepteert de verbinding van de client en leest het volledige verzoek ervan. Hier moet worden opgemerkt dat totdat nginx het volledige verzoek heeft gelezen, het het niet voor "verwerking" indient. Hierdoor "breken bijna alle voortgangsindicatoren van bestandsuploads" - het is echter mogelijk om ze te repareren met behulp van de upload_progress-module van derden (dit vereist een aanpassing van de applicatie).

Nadat nginx het volledige antwoord heeft gelezen, wordt een verbinding met Apache geopend. De laatste doet zijn werk (genereert dynamische inhoud), waarna hij zijn antwoord naar nginx stuurt, die het in het geheugen of een tijdelijk bestand buffert. Ondertussen maakt Apache bronnen vrij. Verder stuurt nginx langzaam inhoud naar de klant, terwijl het orden van grootte minder middelen uitgeeft dan Apache.

Dit schema heet frontend + backend en wordt veel gebruikt.

Installatie

Omdat nginx begint net aan populariteit te winnen, er zijn enkele problemen met binaire pakketten, dus wees voorbereid om het zelf te compileren. Dit is meestal geen probleem, je hoeft alleen maar de uitvoer van de opdracht aandachtig te lezen. / Configure --help en selecteer de compilatie-opties die je nodig hebt, bijvoorbeeld:

./configureren \
--Prefix = / opt / nginx-0.6.x \ # installatievoorvoegsel
--Conf-path = / etc / nginx / nginx.conf \ # locatie van configuratiebestand
-Pid-pad = / var / run / nginx.pid \ # ... en pid-bestand
-User = nginx \ # gebruikersnaam waaronder nginx zal draaien
—Met-http_ssl_module —met-http_gzip_static_module —met-http_stub_status_module \ # lijst met vereiste
—Zonder-http_ssi_module —zonder-http_userid_module —zonder-http_autoindex_module —zonder-http_geo_module —zonder-http_referer_module —zonder-http_memcached_module —zonder-http_limit_zone_module # ... en niet vereiste modules

Na de configuratie moet u de standaard make && make install uitvoeren, waarna u nginx kunt gebruiken.

Als alternatief kan je in Gentoo de ebuild van de standaard ports tree gebruiken; in RHEL / CentOS de epel-repository (waar nginx 0.6.x zich bevindt) of srpm voor versie 0.7, die hier kan worden gedownload: http://blogs.mail.ru/community/nginx; op Debian kunt u het nginx-pakket van de onstabiele tak gebruiken.

configuratiebestand

Het nginx-configuratiebestand is erg handig en intuïtief. Het wordt meestal nginx.conf genoemd en bevindt zich in $ prefix / conf / als de locatie niet opnieuw is gedefinieerd tijdens het compileren. Ik plaats het graag in / etc / nginx /, en dat doen de ontwikkelaars van alle bovengenoemde pakketten ook.

De structuur van het configuratiebestand is als volgt:

gebruiker nginx; # gebruikersnaam waaronder nginx zal draaien
werknemer_processen 1; # aantal werkprocessen
evenementen (
<…># dit blok specificeert het polling-mechanisme dat zal worden gebruikt (zie hieronder) en maximaal aantal mogelijke verbindingen
}

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

# beschrijving van servers (dit is wat apache VirtualHost noemt)
server (
# serveradres en naam
luister *: 80;
servernaam aaa.bbb;

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

# en dit is hoe je een locatie kunt definiëren, waarvoor je ook bijna alle richtlijnen kunt negeren die zijn gespecificeerd op meer globale niveaus
locatie / abcd / (
<директивы>;
}
# Bovendien kun je een locatie maken met een reguliere expressie, zoals deze:
locatie ~ \ .php $ (
<директивы>;
}
}

# een andere server
server (
luister *: 80;
servernaam ccc.bbb;

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

Houd er rekening mee dat elke richtlijn moet eindigen met een puntkomma.
Omgekeerde proxy en FastCGI

Dus hierboven hebben we de voordelen van het frontend + backend-schema onderzocht, de installatie, structuur en syntaxis van het configuratiebestand bedacht, en nu overwegen hoe reverse proxying in nginx kan worden geïmplementeerd.

Het is heel simpel! Bijvoorbeeld als volgt:

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

In dit voorbeeld worden alle verzoeken naar locatie / geproxyd naar server 1.2.3.4, poort 8080. Dit kan apache zijn of een andere http-server.

Er zijn echter verschillende subtiliteiten die verband houden met het feit dat de toepassing ervan uitgaat dat ten eerste alle verzoeken van één IP-adres binnenkomen (wat bijvoorbeeld kan worden geïnterpreteerd als een poging tot een DDoS-aanval of brute-force-aanval) , en ten tweede, bedenk dat het draait op host 1.2.3.4 en poort 8080 (respectievelijk onjuiste omleidingen en absolute links). Om deze problemen te voorkomen zonder de applicatie te hoeven herschrijven, lijkt mij de volgende configuratie handig:
Nginx luistert voorkant op poort 80.

Als de backend (bijvoorbeeld Apache) zich op dezelfde host als nginx bevindt, "luistert" het naar poort 80 op 127.0.0.1 of een ander intern IP-adres.

In dit geval ziet de nginx-configuratie er als volgt uit:

server (
luister 4.3.2.1:80;
# stel de Host-header en X-Real-IP: in op elk verzoek dat naar de backend wordt verzonden
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header Host $ host: $ proxy_port;
# of "proxy_set_header Host $ host;" als de applicatie zal toevoegen: 80 aan alle links
}

Om ervoor te zorgen dat de toepassing onderscheid kan maken tussen de IP-adressen van bezoekers, moet u ofwel de module mod_extract_forwarded installeren (als deze wordt uitgevoerd Apache-server), of wijzig de toepassing zodat deze informatie over het IP-adres van de gebruiker uit de X-Real-IP HTTP-header haalt.

Een andere backend-optie is het gebruik van FastCGI. In dit geval nginx-configuratie zal er ongeveer zo uitzien:

server (
<…>

# locatie waar aanvragen voor php-scripts naartoe worden gestuurd
locatie ~ .php $ (
fastcgi_pass 127.0.0.1:8888; # definieer het adres en de poort van de fastcgi-server,
fastcgi_index index.php; # ... indexbestand

# en enkele parameters die moeten worden doorgegeven aan de fastcgi-server zodat deze begrijpt welk script en met welke parameters moet worden uitgevoerd:
fastcgi_param SCRIPT_FILENAME / usr / www / html $ fastcgi_script_name; # scriptnaam
fastcgi_param QUERY_STRING $ query_string; # queryreeks
# en verzoekparameters:
fastcgi_param REQUEST_METHOD $ request_method;
fastcgi_param CONTENT_TYPE $ content_type;
fastcgi_param CONTENT_LENGTH $ content_length;
}

# vanwege het feit dat locaties met reguliere expressies een hoge "prioriteit" hebben, komen alle niet-php-verzoeken hierheen.

plaats / (
root / var / www / html /
}

Statica

Om de belasting van de backend te verminderen, is het beter om statische bestanden alleen via nginx te serveren - het kan deze taak beter aan, omdat voor elk verzoek besteedt het aanzienlijk minder middelen (het is niet nodig om een ​​nieuw proces te spawnen, en het nginx-proces verbruikt gewoonlijk minder geheugen, en kan vele verbindingen dienen).

In het configuratiebestand ziet het er als volgt uit:

server (
luister *: 80;
servernaam mijnserver.com;

Plaats / (
proxy_pass


"> Http://127.0.0.1:80;

}

# neem aan dat alle statische bestanden zich in / bestanden bevinden
locatie / bestanden / (
root / var / www / html /; # specificeer het pad naar fs
vervalt 14d; # voeg de Expires header toe:
error_page 404 = @terug; # en als het bestand niet wordt gevonden, stuur het dan naar de genoemde locatie @back
}

# verzoeken van / bestanden, waarvoor geen bestand is gevonden, worden naar de backend gestuurd en deze kan het gewenste bestand genereren of tonen leuk bericht over de fout
locatie @terug (
proxy_pass
"Titel =" http://127.0.0.1:80;

"> Http://127.0.0.1:80;

}

Als alle statica niet in een specifieke map zijn geplaatst, gebruik dan een reguliere expressie:

locatie ~ * ^. + \. (jpg | jpeg | gif | png | ico | css | zip | tgz | gz | rar | bz2 | doc | xls | exe | pdf | ppt | txt | tar | wav | bmp | rtf | js) $ (
# vergelijkbaar met het bovenstaande, alleen alle verzoeken die eindigen op een van de opgegeven achtervoegsels worden naar deze locatie verzonden
root / var / www / html /;
error_page 404 = @terug;
}

Helaas is nginx niet geïmplementeerd asynchroon werk met bestanden. Met andere woorden, de nginx-worker wordt geblokkeerd op I / O-bewerkingen. Dus als je veel statische bestanden hebt en vooral als ze van verschillende schijven worden gelezen, is het beter om het aantal werkprocessen te verhogen (tot een aantal dat 2-3 keer meer is dan het totale aantal koppen op de schijf). Dit leidt natuurlijk tot een toename van de belasting van het besturingssysteem, maar de algehele prestaties nemen toe. Om met een typische hoeveelheid statische gegevens te werken (niet een heel groot aantal relatief kleine bestanden: CSS, JavaScript, afbeeldingen), zijn een of twee workflows voldoende.

Wordt vervolgd

Links

Meer informatie over nginx vind je hier:

Nginx is een webserver en mailproxyserver die sinds 2004 publiekelijk beschikbaar is. De ontwikkeling van het project begon in 2002, in het Russisch klinkt de naam als engin-ex. De creatie van de handen van de beroemde programmeur Igor Sysoev, Nginx, was oorspronkelijk bedoeld voor Rambler. Het is ontworpen voor besturingssystemen die tot de Unix-achtige groep behoren. De assembly is met succes getest op OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. Op Microsoft-platform Windows Nginx begon te werken met de release van de 0.7.52 binaire build.

Statistieken voor maart 2011 laten zien dat het aantal sites dat door Nginx wordt bediend, de grens van 22 miljoen al heeft overschreden. Tegenwoordig wordt Nginx gebruikt door bekende projecten als Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru en anderen. Samen met lighttpd wordt Nginx gebruikt om statische inhoud weer te geven die wordt gegenereerd door een "onhandige" webtoepassing die onder een andere webserver draait.
Maar voordat we dieper de wildernis in gaan functionele kenmerken Nginx - het is handig om te onthouden wat een webserver in het algemeen en een proxyserver in het bijzonder is.

Webserver en proxyserver

web Server is een server die HTTP-verzoeken van webbrowsers en andere clients accepteert en HTTP-antwoorden daarop afgeeft. De laatste worden meestal gepresenteerd HTML-pagina, mediastream, afbeelding, bestand, andere gegevens. Onder een webserver wordt zowel software verstaan ​​die webserverfuncties uitvoert als hardware. De uitwisseling van gegevens en gevraagde informatie vindt plaats via het HTTP-protocol.

De lijst extra functies webservers omvatten: autorisatie en authenticatie van gebruikers, logboekregistratie van hun verzoeken aan bronnen, HTTPS-ondersteuning voor veilig schakelen met clients en anderen. De meest gebruikte webserver in Unix-achtige besturingssystemen is Apache. De derde regel in de lijst met klantvoorkeuren wordt momenteel ingenomen door Nginx.

Proxy server stelt klanten in staat om zoekopdrachten Tot netwerkdiensten in een indirecte vorm. Dat wil zeggen, het is een server die gespecialiseerd is in het doorsturen van clientverzoeken naar andere servers. Door verbinding te maken met een proxyserver en een bron op een andere server op te vragen, kan de client de anonimiteit behouden en de computer beschermen tegen netwerkaanvallen. De proxyserver geeft de gevraagde gegevens uit aan de client, hetzij vanuit zijn eigen cache (indien aanwezig) of ontvangt deze van de opgegeven server. In sommige gevallen (om de bovenstaande doelen te bereiken) kan het antwoord van de server, zoals het verzoek van de client, worden gewijzigd door de proxyserver.

De eenvoudigste proxyserver wordt beschouwd als de Network Address Translator of NAT. In 2000 werd proxy NAT ingebouwd in de Windows-distributie. Proxyservers hebben, zoals elk fenomeen, twee kanten van de medaille, dat wil zeggen dat ze zowel ten goede als ten kwade kunnen worden gebruikt. Met hun hulp verbergen bijvoorbeeld degenen die bang zijn voor sancties voor hun onbetamelijke acties op het netwerk hun IP-adressen ...

Functioneel bereik van Nginx:

• serverservice van indexbestanden, statische zoekopdrachten, genereren van descriptors voor open cache, lijst met bestanden;
• versnelde proxying, elementaire belastingsverdeling, fouttolerantie;
• ondersteuning voor caching tijdens versnelde proxying en FastCGI;
• ondersteuning voor FastCGI (versnelde) en memcached-servers;
• modulariteit, filters, inclusief "resume" (bytebereiken) en compressie (gzip);
• HTTP-authenticatie, gesegmenteerde antwoorden, SSI-filter;
• parallelle uitvoering van meerdere subverzoeken op de pagina verwerkt via FastCGI of proxy in het SSI-filter;
• StartTLS en SSL-ondersteuning;
• de mogelijkheid om embedded Perl te ondersteunen;
• eenvoudige authenticatie (USER / PASS, LOGIN);
• serveromleiding (IMAP / POP3-proxy) gebruiker naar IMAP / POP3-backend met behulp van externe server authenticatie (HTTP).

Voor degenen die niet bekend zijn met deze terminologie, lijkt de beschrijving van de functionaliteit van Nginx misschien nogal vaag. Maar als het gaat om manieren om deze webserver concreet te gebruiken, zal het beetje bij beetje beginnen te vervagen.

Architectuur en configuratie

Werkprocessen in Nginx bedienen tegelijkertijd veel verbindingen, waardoor ze OS-aanroepen krijgen ( besturingssysteem) epoll (Linux), selecteer en kqueue (FreeBSD). De gegevens die van de client worden ontvangen, worden geparseerd door een statusmachine. Het geparseerde verzoek wordt afgehandeld door de door de configuratie gespecificeerde moduleketen. De vorming van een reactie op de client vindt plaats in buffers, die kunnen verwijzen naar een gedeelte van een bestand of gegevens in het geheugen kunnen opslaan. De volgorde van gegevensoverdracht naar de klant wordt bepaald door de ketens waarin de buffers zijn gegroepeerd.

Structureel is de Nginx HTTP-server verdeeld in virtuele servers, die op hun beurt zijn onderverdeeld in locaties. Virtuele server of de richtlijn kan worden gebruikt om poorten en adressen op te geven voor het accepteren van verbindingen. Locatie kan worden gespecificeerd met een exacte URI, een deel van een URI of een reguliere expressie.Voor on-the-fly geheugenbeheer zijn pools een reeks vooraf geselecteerde geheugenblokken. Een blok dat aanvankelijk voor de pool is toegewezen, heeft een lengte van 1 tot 16 kilobyte. Het is verdeeld in gebieden - bezet en onbezet. Als de laatste is gevuld, wordt de selectie van een nieuw object verzorgd door de vorming van een nieuw blok.

Geografische classificatie van klanten op basis van hun IP-adres wordt uitgevoerd in Nginx met behulp van een speciale module. Met het Radix tree-systeem werkt u snel met IP-adressen en neemt minimaal geheugen in beslag.

Voordelen van Nginx

Nginx wordt beschouwd als een zeer snelle HTTP-server. In plaats van of in combinatie met Apache wordt Nginx gebruikt om de verwerking van verzoeken te versnellen en de belasting van de server te verminderen. Feit is dat de meeste gebruikers de enorme mogelijkheden van de modulaire Apache-architectuur niet nodig hebben. Het betalen voor deze niet-geclaimde functionaliteit is een aanzienlijke kostenpost. systeembronnen... Voor gewone sites is er in de regel een duidelijke dominantie van statische bestanden (afbeeldingen, stijlbestanden, JavaScript) en niet van scripts. Er is geen speciale functionaliteit vereist om deze bestanden naar de bronbezoeker over te brengen, aangezien de taak heel eenvoudig is. Dit betekent dat de webserver voor het verwerken van dergelijke verzoeken eenvoudig en lichtgewicht moet zijn, zoals Nginx.

Manieren om Nginx te gebruiken

Op een aparte poort/IP. Als de bron vol staat met afbeeldingen of bestanden om te downloaden, kan Nginx worden geconfigureerd op een aparte poort of IP en er statische inhoud doorheen serveren. Hiervoor moet je wel een beetje sleutelen aan wisselende links op de site. Met een groot aantal verzoeken aan statische bestanden is het logisch om een ​​aparte server aan te maken en Nginx daarop te installeren.

Versnelde proxy... Met deze optie gaan alle bezoekersverzoeken eerst naar Nginx. Nginx handelt zelfstandig aanvragen voor statische bestanden (zoals een afbeelding, gewoon HTML-, JavaScript- of CSS-bestand) af. Als de gebruiker contact opneemt met een bepaald script, stuurt hij het verzoek door naar de Apache-afdeling. U hoeft geen transformaties te maken met de sitecode.

Als het kanaal van de server naar de bezoeker en vice versa traag is, kan dit gebruik van Nginx een extra effect geven. Het verzoek dat van de bezoeker wordt ontvangen, wordt doorgegeven aan Nginx voor verwerking door Apache. Na het verwerken van het verzoek stuurt Apache de Nginx-pagina en verbreekt de verbinding met een gevoel van voldoening. Nginx kan nu een pagina naar een gebruiker sturen zolang als nodig is, praktisch zonder systeembronnen te verbruiken. Apache werk in plaats daarvan zou gepaard gaan met een onredelijk hoge belasting van het geheugen bij bijna inactiviteit. Trouwens, deze use case voor Nginx heeft een andere naam: "Frontend naar Apache".

Nginx plus FastCGI. Apache is misschien helemaal niet nodig als de tolk van de taal waarin de sitescripts zijn geschreven FastCGI-technologie ondersteunt. Dergelijke talen zijn bijvoorbeeld PHP, Perl en een aantal andere. In dit geval moet u echter mogelijk de scriptcodes wijzigen.

Er zijn veel gedetailleerde materialen over het installeren en configureren van Nginx op het netwerk. U kunt meer over Nginx te weten komen op de website van de ontwikkelaar Igor Sysoev.