Inleiding
Nginx is een krachtige webserver die ook wordt gebruikt als reverse proxy, mailproxy, load balancer en HTTP-cache. Nginx is gratis en open-source, waardoor iedereen het kan downloaden en gebruiken in hun serveromgeving.
Mogelijk hebt u Nginx al gebruikt om websites te hosten. In deze handleiding bespreken we de andere mogelijkheden van Nginx. De HTTP-proxying functionaliteit van Nginx stelt het in staat om verzoeken door te sturen naar backend HTTP-servers voor verwerking. Met deze functie kunt u meerdere backend-servers instellen. Hiermee kunt u uw infrastructuur naar behoefte schalen om pieken in clientverzoeken op te vangen.
Naarmate we vorderen met de handleiding, leert u over het schalen van uw infrastructuur met behulp van Nginx load balancing eigenschappen, buffering, en caching van antwoorden om uw serverprestaties te verbeteren en een betere ervaring voor clients te garanderen. Laten we beginnen!
Allereerst, om aan de slag te gaan met Nginx, bekijkt u onze handleiding over het installeren van Nginx op uw Ubuntu-server.
Algemene informatie over proxying
Als uw kennis over webservers alleen gaat over het verwerken van websiteverzoeken en het serveren van webpagina's, vraagt u zich misschien af waarom we verzoeken moeten proxyen. Hieronder leggen we de redenen hiervoor uit.
Een reden om verzoeken van Nginx naar andere servers te proxyen, is om de schaalbaarheid van uw infrastructuur te ondersteunen. Nginx verwerkt standaard veel verbindingen gelijktijdig. Dit maakt het perfect om het eerste aanspreekpunt voor clients te zijn. Vervolgens kan het de verzoeken doorsturen naar verschillende backend-servers om de daadwerkelijke verwerking van de clientverzoeken af te handelen. Dit is wat de belasting spreidt. Hierdoor zorgt het ervoor dat u uw infrastructuur zo veel mogelijk kunt schalen. Het stelt u ook in staat om andere servers offline te halen voor onderhoud, terwijl andere verzoeken blijven verwerken.
De tweede reden waarom u verzoeken naar andere servers wilt proxyen, is wanneer u applicatieservers gebruikt die niet geschikt zijn om verzoeken rechtstreeks van clients af te handelen in live productieomgevingen. Verschillende frameworks, waaronder webservers, zijn niet geschikt voor hoge prestaties zoals Nginx. Door Nginx het toegangspunt te laten zijn en verzoeken naar deze minder presterende servers te proxyen, kunt u ervoor zorgen dat uw gebruikers een betere ervaring hebben. Bovendien kan het een verhoogde beveiliging voor uw applicatie garanderen.
Het proces van het proxyen van verzoeken in Nginx omvat het manipuleren van een verzoek van de Nginx-server en het doorsturen naar andere backend-servers voor de daadwerkelijke verwerking. Zodra de andere backend-servers het verzoek hebben verwerkt, sturen ze het resultaat terug naar Nginx. Deze stuurt het resultaat vervolgens als antwoord naar de client. De client is in dit geval een webbrowser of zelfs een mobiele web-app. De andere backend-servers kunnen lokale servers zijn die niet openbaar toegankelijk zijn op internet, externe servers of zelfs andere virtuele servers binnen de serverblokconfiguraties van Nginx. Deze andere servers waarnaar Nginx verzoeken proxyt, worden aangeduid als upstream-servers.
Nginx kan verzoeken proxyen naar servers die communiceren via verschillende protocollen, waaronder HTTP(S), Memcached, SCGI, FastCGI, en uWSGI. Voor elk type protocol zijn er sets richtlijnen. Onze focus voor deze handleiding ligt op het HTTP-protocol. Nginx ontleedt de verzoeken en berichtcomponenten in een formaat dat de upstream-server kan interpreteren en verwerken.
Een basis HTTP Proxy Pass analyseren
Het eenvoudigste type proxy omvat het doorsturen van een verzoek naar een enkele server die via HTTP communiceert. Dit type proxy staat over het algemeen bekend als 'proxy pass' en wordt afgehandeld door de toepasselijk genaamde proxy_pass-richtlijn binnen Nginx-configuratiebestanden.
De proxy_pass-richtlijn verschijnt binnen location-blokken. Deze bevindt zich ook binnen blokken van een location-context en in limit_except-contexten. Wanneer een verzoek overeenkomt met een locatie met een proxy_pass-richtlijn erin, gaat het verzoek naar de URL die de richtlijn specificeert. Hieronder vindt u een voorbeeld van een configuratiefragment:
|
1 2 3 4 |
listen 80; location / { proxy_pass http://127.0.0.1:3000; } |
In het bovenstaande voorbeeld gaan de verzoeken naar poort 80 naar localhost:3000:
De bovenstaande schermafbeelding toont de standaard Nginx-pagina wanneer u localhost probeert te bereiken. Na het herstarten van de Nginx-server met de proxy_pass-richtlijn actief, gaan alle verzoeken naar poort 3000. Er draait een demo-applicatie op poort 3000, wat u kunt zien op de onderstaande afbeelding, en u kunt deze rechtstreeks bereiken vanaf localhost zonder de poort op te geven:
In het volgende voorbeeld is er geen URI gespecificeerd aan het einde van de server in de proxy_pass-definitie. Voor definities die aan dit patroon voldoen, wordt de URI die de client opvraagt ongewijzigd doorgegeven aan de upstream-server.
|
1 2 3 |
location /match/url/hier { proxy_pass http://example.com; } |
Bijvoorbeeld, wanneer dit blok een verzoek voor /match/url/here afhandelt, gaat de verzoek-URI naar de example.com-server als http://example.com/match/url/here.
Hieronder staat een voorbeeld van een alternatief configuratiefragment:
|
1 2 3 |
location /match/url/hier { proxy_pass http://example.com/new/url/prefix; } |
Zoals u in het bovenstaande fragment kunt zien, hebben we een URI-segment gedefinieerd aan het einde van de proxyserver als new/url/prefix. Wanneer u een URI definieert in de proxy_pass-definitie, wordt het deel van het verzoek dat overeenkomt met de location-definitie vervangen door deze URI wanneer het naar de upstream-server gaat voor verwerking.
Bijvoorbeeld, een verzoek voor /match/url/here op de Nginx-server wordt doorgegeven aan de upstream-server als http://example.com/new/url/here. De /match/url wordt vervangen door /new/url. Houd dit punt in gedachten.
In sommige gevallen is het doorgeven van URI's zoals hierboven niet mogelijk. In dergelijke gevallen negeert Nginx de URI aan het einde van de proxy_pass-definitie. Uiteindelijk wordt ofwel de originele URI van de client of de URI die door andere richtlijnen is gewijzigd, doorgegeven aan de upstream-server.
Een voorbeeld is wanneer reguliere expressies overeenkomen met de locatie. Nginx is dan mogelijk niet in staat om te bepalen welk deel van de URI overeenkwam met de expressie. Daarom stuurt het de originele URI van het clientverzoek. Dit zorgt voor het herschrijven en afhandelen van de client-URI in hetzelfde blok. In een dergelijk geval wordt de herschreven URI doorgegeven.
Hoe verwerkt Nginx headers?
Headers zijn cruciaal voor de manier waarop een server een verzoek verwerkt. Sommige headers kunnen authenticatie-informatie bevatten. Daarom moeten we begrijpen hoe Nginx-proxying de headers verwerkt. Het proxyverzoek van Nginx naar de upstream-server zal er anders uitzien dan het verzoek dat rechtstreeks van de client kwam. Sommige van deze verschillen zijn het gevolg van de headers die met het proxyverzoek meegaan.
Tijdens het proxyen van een verzoek zal Nginx aanpassingen aanbrengen in de verzoekheaders die het van de client ontvangt. Enkele van die aanpassingen zijn:
-
Het verwijderen van alle lege headers. Lege headers maken het verzoek alleen maar onnodig groot, dus het heeft geen zin om ze door te geven aan de upstream-server.
-
Alle headers die underscores bevatten, worden standaard als ongeldig beschouwd en daarom uit het verzoek verwijderd. Als u dit gedrag wilt wijzigen en Nginx headers met underscores als geldig wilt laten interpreteren, kunt u de richtlijn underscores_in_headers op “on” instellen. Als u dat niet doet, zullen dergelijke headers van de client de upstream-server nooit bereiken.
-
De “Host”-header wordt herschreven naar de waarde die is gespecificeerd door de variabele $proxy_host. Dit is het IP-adres of de naam en het poortnummer van de upstream-server, zoals gespecificeerd door de proxy_pass-richtlijn.
-
De waarde van de “Connection”-header verandert in “close”. De Connection-header bevat informatie over een specifieke verbinding die tussen twee partijen tot stand is gebracht. Wanneer Nginx de waarde instelt op close, geeft dit aan de upstream-server aan dat de verbinding wordt gesloten zodra het oorspronkelijke verzoek is beantwoord, en dat er dus geen persistente verbinding hoeft te worden verwacht.
Hier zijn enkele punten die we kunnen opmaken uit de hierboven beschreven aanpassingen van de proxyverzoekheaders:
-
Als u niet wilt dat een header wordt doorgegeven aan de upstream-server, kunt u deze instellen op een lege string om deze volledig uit het verzoek te verwijderen.
-
Als de applicatie in uw upstream-server niet-standaard headers verwerkt, zorg er dan voor dat de headers geen underscore bevatten. Optioneel kunt u de richtlijn underscores_in_headers op “on” instellen in uw configuratie (geldig in de context van de standaard serverdeclaratie voor de IP-adres/poort-combinatie of in de HTTP-context). Dit zorgt ervoor dat de headers niet als ongeldig worden gemarkeerd en dus daadwerkelijk worden doorgegeven aan de upstream-server.
-
De “Host”-header is erg belangrijk in de meeste proxy-situaties. Deze is standaard ingesteld op de waarde van $proxy_host, een variabele die de domeinnaam of het IP-adres en de poort bevat die zijn opgehaald uit de proxy_pass-specificatie. Dit adres wordt standaard geselecteerd en rechtstreeks uit de verbindingsinformatie gehaald. Het is het enige adres waarvan Nginx de garantie heeft dat de upstream-server erop zal reageren.
Hieronder staan de meest voorkomende waarden voor de “Host”-header:
-
$host – een variabele die in volgorde van voorkeur wordt ingesteld op de hostnaam uit de verzoekregel zelf, de “Host”-header uit het clientverzoek, of de servernaam die overeenkomt met het verzoek.
-
$http_host – een variabele die de “Host”-header instelt op de “Host”-header uit het clientverzoek. De headers in het verzoek van de client zijn altijd beschikbaar voor Nginx als variabelen. Deze variabelen beginnen met een $http_-voorvoegsel, gevolgd door de headernaam in kleine letters. Hoewel de variabele $http_host meestal prima werkt, kan het ontbreken van een geldige “Host”-header in het clientverzoek ertoe leiden dat de doorvoer mislukt.
-
$proxy_host – een variabele die de “Host”-header instelt op de domeinnaam of IP-adres- en poortcombinatie die is opgehaald uit de specificatie van de proxy_pass. Dit is het standaardgedrag vanuit het oogpunt van Nginx en wordt daarom als veilig beschouwd. Het is echter mogelijk niet wat de server nodig heeft om het verzoek correct te verwerken.
De meeste configuraties omvatten het instellen van de “Host”-header op de variabele $host. Dit is zeer flexibel en zorgt voor nauwkeurig ingevulde headers naar de upstream-server.
Headers instellen en wijzigen
Met de richtlijn proxy_set_header kunnen we headers voor proxyverbindingen instellen of wijzigen. In de eerder besproken “Host”-header kunnen we het volgende doen om veelvoorkomende aanvullende headers bij geproxiede verzoeken te wijzigen en toe te voegen:
|
1 2 3 4 5 6 7 8 |
location /match/hier { proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $schema; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://example.com/new/prefix; } |
In het bovenstaande configuratiefragment stellen we de “Host”-header in op de variabele $host die informatie bevat over de oorspronkelijk aangevraagde host. We stellen de X-Forwarded-Proto-header in met informatie over het schema van het oorspronkelijke verzoek van de client (dit kan een HTTP- of een HTTPS-verzoek zijn).
We geven het daadwerkelijke IP-adres van de client door aan de X-Real-IP. Dit stelt de upstream-server in staat om op de juiste manier beslissingen te nemen of logs op te slaan op basis van de IP-oorsprong van de client. De X-Forwarded-For-header bevat een lijst met alle IP-adressen van servers waarlangs de client is geproxied voordat dit punt werd bereikt. In het bovenstaande codefragment stellen we deze in op de variabele $proxy_add_x_forwarded_for. Deze variabele neemt de waarde van de originele X-Forwarded-For-header die van de client is overgenomen en voegt het IP-adres van de Nginx-proxyserver aan het einde toe.
Als u wilt dat de proxy_set_header-richtlijnen op meer dan één locatie worden aangeroepen, kunt u deze verplaatsen naar de server- of http-context. Bekijk het onderstaande configuratiefragment:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location /match/here { proxy_pass http://example.com/new/prefix; } location /different/match { proxy_pass http://example.com; } |
Een upstream-context definiëren om geproxiede verbindingen te load-balancen
Tot nu toe begrijpt u hoe u een eenvoudige http-proxy naar een enkele backend upstream-server opzet. Gelukkig kunt u met Nginx een dergelijke configuratie schalen door pools van backend-servers te definiëren waarnaar de verzoeken ter verwerking worden doorgestuurd.
Nginx biedt een richtlijn genaamd upstream die wordt gebruikt om een pool van servers te definiëren. Binnen de configuratie van de richtlijn mag u alleen servers specificeren die in staat zijn om het verzoek van een client af te handelen. Nginx als proxyserver maakt het schalen van infrastructuur met minimale inspanning mogelijk. De upstream-richtlijn moet worden opgegeven binnen de http-context van uw Nginx-configuratie.
Hier is een voorbeeld dat de upstream-richtlijn toont:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
upstream several_backend_hosts { server host1.example.com; server host2.example.com; server host3.example.com; } server { listen 80; server_name example.com; location /proxy-me { proxy_pass http://several_backend_hosts; } } |
In het bovenstaande configuratiecodefragment hebben we een upstream-context gedefinieerd genaamd several_backend_hosts. De gedefinieerde contextnaam is nu beschikbaar binnen proxy-passes. Deze kan worden gebruikt alsof het een gewoon domein is, zoals in het voorbeeld wordt getoond. Binnen het serverblok sturen we alle verzoeken aan example.com/proxy-me/… door naar de pool die we hebben gedefinieerd met behulp van de upstream-richtlijn, in dit geval several_backend_hosts. Er wordt een host binnen de pool geselecteerd om inkomende verzoeken af te handelen door een configureerbaar algoritme toe te passen. Standaard volgt de selectie een round-robin (circulair) proces – elk verzoek wordt om de beurt naar een andere host geleid.
Hoe u het upstream-balanceringsalgoritme kunt wijzigen
Zoals hierboven aangegeven, volgt het selectieproces een round-robin-proces. In dit gedeelte zullen we zien hoe we het balanceringsalgoritme dat door de upstream-pool wordt gebruikt, kunnen aanpassen. Om het algoritme aan te passen, neemt u andere richtlijnen of vlaggen op binnen de upstream-context, zoals hieronder gedefinieerd:
-
(round-robin) – als er geen andere upstream-balanceringsrichtlijn is opgegeven, worden verzoeken standaard opeenvolgend en om de beurt doorgegeven aan elke server die in de upstream-context is gedefinieerd.
-
least_conn – deze richtlijn instrueert de upstream om de backend-server te selecteren met het minste aantal actieve verbindingen. Dit is van toepassing in situaties waarin verbindingen met één backend-server een tijdje kunnen aanhouden.
-
hash – deze richtlijn is gebruikelijk voor memcached-proxying. Verbindingen worden doorgegeven aan de backend-servers op basis van de waarde van een willekeurig verstrekte hash-sleutel. De waarde van de hash-sleutel kan bestaan uit variabelen, tekst of een combinatie van beide. hash is toevallig de enige balanceringsmethode die invoer van gebruikers vereist om te dienen als de sleutel die voor de hash wordt gebruikt.
-
ip_hash – deze richtlijn instrueert de upstream om verzoeken over verschillende servers te verdelen op basis van het IP-adres van de client. De eerste drie octetten van het IP-adres zijn de sleutel om te bepalen welke server een verzoek moet verwerken. Een voordeel van deze richtlijn is dat clients meestal telkens dezelfde server toegewezen krijgen, wat de consistentie van de sessie waarborgt.
Hier is een voorbeeld van hoe we de richtlijn voor het balanceringsalgoritme kunnen toevoegen aan de upstream-context:
|
1 2 3 4 5 6 7 8 |
upstream several_backend_hosts { least_conn; server host1.example.com; server host2.example.com; server host3.example.com; } |
In het bovenstaande fragment zal Nginx een van de servers met de minste verbindingen selecteren om een binnenkomend verzoek te verwerken. De ip_hash-richtlijn volgt dezelfde syntaxis. Voor de hash-richtlijn moet u een zelfgekozen sleutel opgeven om tegen te hashen, hier is een voorbeeld:
|
1 2 3 4 5 6 7 8 |
upstream several_backend_hosts { hash $remote_addr$remote_port consistent; server host1.example.com; server host2.example.com; server host3.example.com; } |
De hier gebruikte hash is het resultaat van het IP-adres en de poort van de client. De optionele parameter consistent implementeert het ketama consistent hashing-algoritme. Dit zorgt voor een minimale impact op uw cache mocht u uw upstream-servers wijzigen.
Hoe u het servergewicht voor balancering specificeert
Standaard heeft elke server hetzelfde gewicht wanneer u backend-servers declareert. De aanname is dat elke server de bronnen en capaciteiten heeft om dezelfde hoeveelheid belasting te verwerken, uiteraard rekening houdend met het balanceringsalgoritme dat u in de upstream-context specificeert. Om dit standaardgedrag te wijzigen, kunt u tijdens de declaratie een alternatief gewicht aan elke server toewijzen. Laten we een voorbeeld bekijken:
|
1 2 3 4 5 |
upstream backend_hosts { server host1.example.com weight=2; server host2.example.com; server host3.example.com; } |
In dit voorbeeld ontvangt host1.example.com twee keer zoveel verkeer als de andere twee servers. Het gewicht voor elke server is standaard één.
Backend-servers vrijmaken met buffers
Tijdens het configureren van proxying in uw serverconfiguratie maakt u zich misschien zorgen over de prestatie-impact van het toevoegen van meer servers aan het proces. Gelukkig beschikt Nginx over buffer- en cachingfuncties die deze prestatieproblemen kunnen helpen verminderen.
De snelheid van twee verschillende verbindingen zal zeker invloed hebben op de ervaring van een client bij het proxyen naar een andere server:
-
De eerste verbinding is van de client naar de Nginx-proxy.
-
De tweede verbinding is van de Nginx-proxy naar de backend upstream-server.
Nginx kan zijn gedrag aanpassen om een van beide verbindingen te optimaliseren indien nodig.
Als we buffers verwijderen, begint de overdracht van gegevens van de upstream-backend naar de client onmiddellijk bij de Nginx-proxy. Als u weet dat uw clients snel zijn, kunt u buffering volledig uitschakelen om ervoor te zorgen dat gegevens snel genoeg bij de client aankomen. Wanneer u buffers hebt ingeschakeld, slaat de Nginx-proxy de responsgegevens die zijn ontvangen van de backend upstream-server tijdelijk op. Vervolgens verzendt deze de gegevens naar de client, afhankelijk van hun snelheid. Zodra Nginx de respons in zijn buffers heeft, kan het de verbinding met de backend-server sluiten. Het zal de gegevens vervolgens naar de client distribueren met een snelheid die de client ondersteunt. Tegelijkertijd stelt dit de backend-server in staat om door te gaan met het verwerken van andere binnenkomende verzoeken.
Standaard heeft Nginx buffering ingeschakeld. Dit komt omdat we de verbindingssnelheden van clients niet kunnen weten. Clients hebben vaak verschillende verbindingen die langzamer kunnen zijn. Hieronder definiëren we de verschillende richtlijnen die we kunnen specificeren om het buffergedrag van Nginx aan te passen. De richtlijnen kunnen worden gedefinieerd in de http-, server- of location-contexten, maar u moet er rekening mee houden dat de grootterichtlijnen per verzoek worden geconfigureerd. Daarom kan het verhogen ervan tot meer dan wat absoluut noodzakelijk is de prestaties van uw server beïnvloeden wanneer er te veel binnenkomende clientverzoeken zijn. Hier zijn de richtlijnen:
-
proxy_buffering – de richtlijn die bepaalt of buffering actief is voor een specifieke context en onderliggende contexten. De standaardconfiguratie voor proxy_buffering is “on”.
-
proxy_buffer_size – de richtlijn die de grootte specificeert van de buffer voor het opslaan van headers in een antwoord van een backend-server. Headers vormen het eerste deel van het antwoord van een backend-server. Het bufferen van deze headers staat los van de rest van het antwoord. Standaard is de ingestelde grootte van deze buffer gelijk aan die van proxy_buffers. Als de header-informatie echter klein is, kunt u de grootte op een lagere waarde instellen.
-
proxy_buffers – de richtlijn die het aantal (eerste argument) en de grootte (tweede argument) regelt van buffers voor geproxiede antwoorden. De standaardconfiguratie specificeert 8 buffers met een grootte die gelijk is aan één geheugenpagina (ofwel 4k of 8k). U kunt het bufferen van meer informatie toestaan door het aantal buffers te verhogen.
-
proxy_max_temp_file_size – de richtlijn die de maximale grootte, per verzoek, specificeert voor een tijdelijk bestand op de schijf. Tijdelijke bestanden worden aangemaakt wanneer het upstream-antwoord te groot is om in een buffer te passen.
-
proxy_busy_buffers_size – de richtlijn die de maximale grootte specificeert van buffers die als “client-ready” en dus bezet kunnen worden gemarkeerd. Een client kan de gegevens van slechts één buffer tegelijk lezen. Buffers staan echter in een wachtrij om in batches naar de client te worden verzonden. U kunt de grootte van de bufferruimte die zich in deze status mag bevinden specificeren door deze richtlijn aan te passen.
-
proxy_temp_file_write_size – de richtlijn die de hoeveelheid gegevens specificeert die Nginx in één keer naar het tijdelijke bestand schrijft wanneer het antwoord van de backend upstream-server te groot is om in de geconfigureerde buffers te passen.
-
proxy_temp_path – de richtlijn die het pad specificeert naar de locatie op de schijf waar Nginx tijdelijke bestanden moet opslaan wanneer het antwoord van de upstream backend-server te groot is om in de geconfigureerde buffers te passen.
Nginx is zeer aanpasbaar en biedt verschillende richtlijnen om het buffergedrag aan te passen. In de meeste gevallen werken de standaardwaarden prima. Tegelijkertijd is het goed om te weten dat u sommige van deze waarden kunt aanpassen voor uw aangepaste implementatie. Meestal zult u de richtlijnen proxy_buffers en proxy_buffer_size willen aanpassen.
Hieronder staat een voorbeeld dat het aantal beschikbare proxy-buffers voor elk upstream-verzoek verhoogt. Dit gebeurt terwijl de grootte van de buffer die de headers opslaat, wordt verkleind:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
server { proxy_buffering on; proxy_buffer_size 1k; proxy_buffers 24 4k; proxy_busy_buffers_size 8k; proxy_max_temp_file_size 2048m; proxy_temp_file_write_size 32k; location / { proxy_pass http://example.com; } } |
Laten we eens kijken hoe u gegevens sneller kunt leveren aan snelle clients door buffering volledig uit te schakelen. Mocht het zo zijn dat uw client niet snel genoeg is, dan zal Nginx automatisch buffers gebruiken. Het zal de gegevens echter eerst naar de client flushen in plaats van te wachten op bufferpools. Deze configuratie heeft een nadeel. Deze configuratie zorgt ervoor dat de verbinding met de upstream-server open blijft voor trage clients totdat de client alle antwoordgegevens heeft ontvangen. Als buffering is ingesteld op “off”, wordt alleen de buffer gebruikt die is gedefinieerd door de richtlijn proxy_buffer_size. Hier is een fragment dat laat zien hoe u buffering uitschakelt:
|
1 2 3 4 5 6 7 8 9 |
server { proxy_buffering off; proxy_buffer_size 4k; location / { proxy_pass http://example.com; } } |
-
Een Highly Available (HA) infrastructuur configureren (optionele installatie)
U kunt een redundante set load balancers toevoegen aan de Nginx-proxyconfiguratie om ervoor te zorgen dat deze robuuster en dus zeer beschikbaar is. Een high availability (HA)-configuratie is een infrastructuur zonder single point of failure. Load balancers maken deel uit van deze configuratie. Met meer dan één load balancer kunt u potentiële downtime voorkomen als één load balancer uitvalt of offline gaat voor onderhoud.
Nginx-proxycaching implementeren om responstijden te verkorten
In de vorige sectie hebben we besproken hoe u buffering kunt gebruiken om de backend-servers vrij te maken voor het verwerken van meer verzoeken. Nginx wordt geleverd met een andere functie waarmee we responsgegevens van de backend kunnen cachen. Dit elimineert de noodzaak om verbinding te maken met de upstream voor alle inkomende verzoeken volledig.
Een proxy-cache implementeren
De proxy_cache_path-richtlijn stelt ons in staat om een cache in te stellen door een gebied op de schijf op te geven dat moet worden gebruikt voor het opslaan van geproxiede inhoud. De proxy_cache_path-richtlijn krijgt een definitie in de http-context.
Het onderstaande configuratiecodefragment is een voorbeeld van hoe u een cachingsysteem kunt implementeren:
|
1 2 3 4 5 6 |
http { proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backendcache:8m max_size=50m; proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args"; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; } |
In dit codefragment hebben we de proxy_cache_path-richtlijn gebruikt om een map op het bestandssysteem te definiëren die onze cache zal bevatten. De /var/lib/nginx/cache is de map die we in dit geval hebben ingesteld. Het staat u vrij om een mappad naar keuze te definiëren. Gebruik de volgende commando's om de door u gekozen mappen aan te maken, met de juiste machtigingen en eigendom:
|
1 2 3 |
sudo mkdir -p /var/lib/nginx/cache sudo chown www-data /var/lib/nginx/cache sudo chmod 700 /var/lib/nginx/cache |
In het codefragment specificeert de parameter levels= de organisatie van de cache. Nginx maakt een cache-sleutel door de waarde van een sleutel te hashen (gespecificeerd met de proxy_cache_key-richtlijn). De niveaus die we hebben opgegeven (1:2) geven aan dat er een map met één teken (d.w.z. het laatste teken van de gehashte waarde) met een submap van twee tekens (genomen van de volgende twee tekens vanaf het einde van de gehashte waarde) wordt gemaakt. In de meeste gevallen zal dit u niet aangaan. Het is echter goed om te weten hoe het Nginx helpt bij het snel vinden van de relevante waarden.
De parameter keys_zone= definieert de naam voor een cachezone, in ons geval hebben we deze backendcache genoemd. Hier definiëren we ook hoeveel metadata we willen opslaan. In dit voorbeeld slaan we 8 MB aan sleutels op. Nginx kan ongeveer 8000 vermeldingen opslaan voor elke megabyte. De parameter max_size specificeert de maximale grootte van de daadwerkelijke gecachte gegevens, 50 MB in ons voorbeeld.
U moet ook letten op de gebruikte proxy_cache_key-richtlijn. Deze richtlijn specificeert de sleutel die we zullen gebruiken om gecachte waarden op te slaan. We zullen dezelfde sleutel gebruiken om te controleren of het verzoek in de cache bestaat. We hebben gespecificeerd dat die sleutel een combinatie is van het schema (http of https), the HTTP-verzoekmethode en de opgevraagde host en URI.
Daarnaast hebben we de proxy_cache_valid-richtlijn gebruikt. Deze richtlijn kan meerdere keren worden opgegeven voor verschillende statuscodes. Hiermee kunnen we specificeren hoe lang waarden moeten worden opgeslagen, afhankelijk van de statuscode. In het codefragment hebben we 10 minuten opgegeven voor succesvolle codes en 1 minuut voor 404-reacties.
Nu we de cachezone hebben geconfigureerd, is de volgende stap om de configuratie in werking te stellen door Nginx te vertellen wanneer de cache moet worden gebruikt. Hieronder vindt u een configuratiefragment dat laat zien hoe we het gebruik van deze cache kunnen implementeren:
|
1 2 3 4 5 6 7 8 9 |
server { location /proxy-me { proxy_cache backendcache; proxy_cache_bypass $http_cache_control; add_header X-Proxy-Cache $upstream_cache_status; proxy_pass http://backend; } } |
In de proxy_cache-richtlijn hebben we gespecificeerd dat de backendcache-cachezone voor deze context moet worden gebruikt. Als u een andere naam hebt gekozen in de cacheconfiguratie, is dit de plaats waar u deze vervangt. Voor elke geldige invoer controleert Nginx de cache voordat een verzoek wordt doorgestuurd naar de backend upstream-server.
We definiëren de proxy_cache_bypass-richtlijn om de variabele $http_cache_control te gebruiken. Deze variabele vertelt de server of deze moet reageren met een gecachte reactie of een nieuwe, niet-gecachte versie van de bron. Door deze richtlijn op de juiste manier in te stellen, kan Nginx verschillende soorten inkomende verzoeken van clients correct verwerken.
Er is ook een extra header genaamd X-Proxy-Cache gespecificeerd. Deze header heeft de waarde van de variabele $upstream_cache_status. Het geeft ons informatie over of het verzoek heeft geresulteerd in een cache hit, een cache miss, of dat de cache expliciet is omzeild. Dergelijke informatie kan nuttig zijn voor de client en cruciaal tijdens het debuggen van applicaties.
Belangrijke punten over het cachen van resultaten
Hoewel caching de prestaties van uw proxyserver aanzienlijk zal verbeteren, moet u rekening houden met het volgende bij het implementeren van caching:
Gegevens die verband houden met de persoonlijke gegevens van een gebruiker mogen niet worden gecacht, om scenario’s te voorkomen waarin de gegevens van de ene gebruiker zichtbaar zijn voor een andere gebruiker.
Uw backend-servers moeten rekening houden met alle dynamische elementen van uw website. We hebben verschillende Cache-Control-headers die we in onze reactie kunnen specificeren om verschillende doelen te dienen. Laten we ze bespreken:
-
no-cache – specificeert dat de proxy moet controleren of de gegevens op de backend zijn gewijzigd voordat een reactie wordt verzonden. Dit is van toepassing op dynamische en belangrijke gegevens. Bij elk verzoek wordt een ETag-gehashte metadata-header gecontroleerd en als de backend dezelfde hashwaarde retourneert, wordt de vorige waarde verzonden.
-
no-store – specificeert dat er geen caching plaatsvindt voor ontvangen gegevens, waardoor elk verzoek naar de server gaat voor nieuwe gegevens. Dit is het veiligst voor gevoelige gegevens.
-
private – specificeert dat geen enkele gedeelde cacheruimte de gegevens mag cachen. U kunt deze header gebruiken om caching in de browser van de gebruiker te specificeren, maar ook om de proxyserver te informeren de gegevens als ongeldig te beschouwen voor volgende verzoeken.
-
public – specificeert een openbare reactie en staat caching toe op elk punt in de verbinding.
U kunt met de max-age-header in seconden specificeren hoe lang de cache moet meegaan. De verschillende hierboven gedefinieerde headers kunnen u helpen bij het implementeren van caching, terwijl gevoelige gegevens veilig blijven, dynamische gegevens vers blijven en, het allerbelangrijkste, de prestaties van uw server worden verbeterd.
Als uw backend-servers Nginx-servers draaien, kunt u binnen de serverblokken specificeren hoe lang een cache geldig moet zijn. U kunt dit doen door de expires-richtlijn aan de configuratie toe te voegen, zoals hieronder weergegeven:
|
1 2 3 4 5 6 7 |
location / { expires 59m; } location /check-me { expires -1; } |
Het eerste blok staat caching van inhoud toe gedurende 59 minuten, terwijl het tweede blok aangeeft dat er geen caching plaatsvindt. Deze instellingen zijn van toepassing op de opties voor Cache-Control-headers, bijvoorbeeld “no-cache” voor het tweede blok.
U kunt de add-header-richtlijn gebruiken om aanvullende waarden in te stellen:
|
1 2 3 4 |
location /private { expires -1; add_header Cache-Control "no-store"; } |
Conclusie
In deze handleiding hebben we geleerd over de krachtige functies van Nginx. Nginx is zowel een webserver als, belangrijker nog, een reverse proxy. Het ontwerp van Nginx maakt het in staat om duizenden gelijktijdige verbindingen te verwerken. Dit maakt het perfect voor load balancing. Vanwege het ontwerp is het doorsturen van verzoeken naar andere backend-servers voor verwerking vrij eenvoudig.
Met de kennis uit deze handleiding zou je in staat moeten zijn om complexe proxy's en load balancers te implementeren, dankzij de flexibiliteit van Nginx.
Hier zijn enkele bronnen die je kunt vinden op onze blog die je verder kunnen laten kennismaken met Nginx:
Veel computerplezier!
Reacties
Nog geen reacties. Wees de eerste.